<html><head></head><body bgcolor="#FFFFFF"><div>Excelente post, gostei.<br><br>-- enviado via US Robotics 9600bps</div><div><br>Em 06/07/2012, às 16:29, Noilson Caio <<a href="mailto:caiogore@gmail.com">caiogore@gmail.com</a>> escreveu:<br><br></div><div></div><blockquote type="cite"><div><p>Retirado de: <a href="https://titanous.com/posts/security-disclosure-policy-best-practices">https://titanous.com/posts/security-disclosure-policy-best-practices</a> 6/07/2012<br></p><p><br></p><p><br></p><p>Every company with public-facing web applications needs a clear security
          disclosure policy. This policy serves three main purposes. First it tells people
          who discover a vulnerability how to proceed and what your response will be so
          they can report problems easily. Secondly it tells your employees exactly how to
          process and respond to these reports. Most importantly, a clear public security
          policy lets your users know in advance how you will respond to recently
          discovered vulnerabilities.</p>
          
          <p>As I discovered last week when notifying Heroku of <a href="https://titanous.com/posts/vulnerabilities-in-heroku-build-system">a vulnerability in their
          build system</a>, even the most
          progressive, respected companies don’t always get it 100% right.</p>
          
          <p>No matter how well designed your application, users will find bugs. When (not
          if) that happens, it is vital that the person who discovers the vulnerability
          knows how to report it.</p>
          
          <p>Bug reporting is a funnel, just like every other part of your web application.
          If users get confused or decide you are not worth their time, they will leave
          the site without converting. In this case your “users” may be curious hackers,
          security researchers, or even your own customers. It’s your job to make
          reporting as easy, painless, and rewarding as possible. If you fail, you risk
          not finding out about the vulnerability, which could endanger your users’ data
          and the company’s future. Remember, the person reporting a security flaw is
          being friendly and doing you a big favor. Treat them accordingly.</p>
          
          <p>Here’s how:</p>
          
          <h2 id="security-page">Security Page</h2>
          
          <p>At some point, someone will need to report a security vulnerability. You don’t
          want to have that conversation you in public or in the clear. It is also not
          a problem you want to outsource to Twitter, Facebook, or a forum. The first
          thing on your security page should be a link to <em><a href="mailto:security@yourawesomeapp.com">security@yourawesomeapp.com</a></em>.
          The second is a PGP public key, which can be used to send you encrypted
          messages. This page should <em>always</em> be served over HTTPS.  Only by encrypting
          each step in the communication process can the sender be sure the person they
          are emailing is who they claim to be without being intercepted.  If the PGP key
          is not posted already, a responsible hacker might email a request for one to be
          posted which wastes valuable time. The person discovering the vulnerability
          might become unavailable by the time the key is posted, causing further delays.</p>
          
          <h2 id="policies">Policies</h2>
          
          <p>The policies listed on this page should be clear, concise, and friendly. The
          person who discovers a vulnerability is already in a difficult position and it
          is important they understand your policies.</p>
          
          <h3 id="indemnification">Indemnification</h3>
          
          <p>A person who accidentally discovers a vulnerability may need to experiment
          further to see how far the problem goes, and even if it is in fact
          a vulnerability. Often it is not possible to determine the nature of
          a vulnerability without trying to do something that should not normally be
          possible or allowed. Unfortunately parts of this process often necessarily run
          afoul of the law in some jurisdictions, meaning that if the hacker wants to
          report a problem to a company, s/he needs to admit to participating in
          a possibly illegal activity. Some companies make this difficult situation worse
          by threatening legal action outright or if the disclosing hackers refuse to
          sign a retroactive NDA. Minor penetration is a routine part of security testing
          and user exploration. Regardless of the legal threats available to your company,
          using them against users, hackers, or researchers who acted without malicious
          intent is never advisable.</p>
          
          <p>For these reasons it is vital that you indemnify and hold blameless anyone who
          penetrates your site, and in the process of exploring or experimenting, extracts
          a small amount of sensitive data and promptly notifies you then destroys any
          data collected. Without a clear and binding promise of immunity from future
          prosecution, those who discover vulnerabilities may not notify you at all.
          Publishing a clear policy that protects the party disclosing an exploit is the
          first, and most important step in building trust.</p>
          
          <h3 id="bounties">Bounties</h3>
          
          <p>Details about a vulnerability are worth a great deal of money. This kind of
          information is valuable not only to your competitors, but also on growing black
          and grey markets. Many other parties would pay for the details of
          a vulnerability in order to exploit it themselves. This means that anyone
          discovering a vulnerability on your site could sell it easily. Knowledge of
          a vulnerability will always be worth more to your company than any of these
          others. However, a hacker asking for money either before or after making
          a disclosure can make everyone uncomfortable. Avoid this situation entirely by
          advertising generous bounties ahead of time. Here’s what some companies are
          currently offering:</p>
          
          <table><tbody>
          <tr>
          <td><a href="https://www.facebook.com/whitehat/bounty/">Facebook</a></td>
                <td>Starting at $500</td>
              </tr>
          <tr>
          <td><a href="https://www.mozilla.org/security/bug-bounty.html">Mozilla</a></td>
                <td>$3,000 flat fee</td>
              </tr>
          <tr>
          <td><a href="http://www.google.com/about/company/rewardprogram.html">Google</a></td>
                <td>$500-$20,000 depending on severity</td>
              </tr>
          </tbody></table><p>The free market determines how much a vulnerability in your system is worth. For
          products with large user bases, the <a href="http://www.forbes.com/sites/andygreenberg/2012/03/23/shopping-for-zero-days-an-price-list-for-hackers-secret-software-exploits/">prices can get very
          high</a>.</p>
          
          <p>The best companies also make their pre-release code or a staging server with
          dummy data available for testing with even higher rewards. In this case exploits
          can be found and remedied before users’ data is ever compromised.</p>
          
          <h2 id="disclosure">Disclosure</h2>
          
          <blockquote>
            <p>Without the threat of full disclosure, responsible disclosure would not work,
          and vendors would go back to ignoring security vulnerabilities.
          <cite><a href="https://www.schneier.com/blog/archives/2012/06/on_securing_pot.html">Bruce Schenier</a></cite></p>
          </blockquote>
          
          <p>Do not ever try to get hackers or researchers to take a bounty in exchange for
          not publishing their discovery (and it is <em>their</em> discovery). Unfortunately some
          companies offer bounties only in exchange for silence. Don’t attach strings to
          bounties. Many hackers prize recognition higher than remuneration, and there’s
          no need to deprive them of both. Similarly, security researchers make their
          living off of their reputation for discovering holes. A great policy is to
          offer a reasonable no-strings-attached bounty and then double for responsible
          disclosure.</p>
          
          <blockquote>
            <p><em>Responsible Disclosure</em>
          is when the researcher who discovered a vulnerability notifies the creator of
          the product and allows them a reasonable amount of time to fix it. After that
          time, the researcher publishes the details publicly regardless of whether the
          users have been officially notified.</p>
          </blockquote>
          
          <p>No matter what, remember that someone disclosing a vulnerability to you directly
          is usually trying to do the right thing.</p>
          
          <h2 id="timing">Timing</h2>
          
          <p>Respond very quickly. When the crisis ends, the discussion will be about how
          your company handled the situation. It is crucial that the relevant team began
          work immediately instead of waiting until the next day, or for a lawyer’s
          permission to talk to the person who reported the problem. Any delay will look
          like either incompetence or a conspiracy to cover up the vulnerability. You
          can’t afford for customers or the press to think either. Your customers will be
          busy checking their own data and then decide if they should change providers.
          The timing of your response should not be its own reason to leave.</p>
          
          <p>Emails to <em><a href="mailto:security@yourawesomeapp.com">security@yourawesomeapp.com</a></em> are your company’s highest priority,
          period. Your lawyer, investors, and mother can all wait. Messages to that
          address should be forwarded to the highest ranking member of your
          security/ops/engineering team on call <em>and</em> the CEO. If you don’t have a 24-hour
          on-call rotation, create a script with Twilio, Tropo, or Adhearsion that wakes
          up the CEO or founders. Whoever needs to respond to the problem gets woken up
          and/or called back from vacation. You asked your customers trust you with their
          data (and often their own customers’ as well). Many of those affected would
          gladly wake up themselves to fix it if they were able. You have an obligation to
          respond as quickly as you are physically able.</p>
          
          <h2 id="employees">Employees</h2>
          
          <p>Hearing about a vulnerability is a high stress time for your team. Try not to
          make it worse. They already feel like they screwed up no matter what caused the
          vulnerability. Don’t have a blame culture–make it clear you’re all on the same
          team and share a single mission: doing the best you can for your customers.</p>
          
          <p>Your security team needs to be in direct contact immediately with the person who
          discovered the vulnerability. Any attempts at legal maneuvering will slow down
          their response and distract the only people who can fix the problem(s). Make it
          clear that your team’s responsibility is to patch the application, not manage
          your company’s strategic communications. If developers are free to treat each
          other as peers without a lawyer leaning over their shoulders, the patch will
          come sooner.</p>
          
          <h2 id="customers">Customers</h2>
          
          <p>Customers need to know about a problem after it has been patched. Public
          disclosure means you get caught with your pants down. Discovery without
          disclosure means someone has a backdoor to your users’ lives and businesses.
          Which do you think they would prefer? Your obligation to your customers comes
          first, regardless of any embarrassment it might cause. If world governments are
          not able to keep their embarrassing secrets, it is unlikely you will be able to
          either (for long). Honest and direct communication builds user loyalty, hiding
          the failures that affect your users causes far bigger problems.</p>
          
          <h2 id="outcomes">Outcomes</h2>
          
          <ol><li>All vulnerabilities caught in pre-release stage.</li><li>Vulnerabilities in production code caught and responsibly disclosed.</li><li>Vulnerabilities caught and disclosed to users and company simultaneously.</li>

<li>Vulnerabilities discovered by malicious party and exploited without company or user knowledge.</li></ol><p>Always remember when you are dealing with disclosure of a security issue that
          things could be much worse–you could not know about it.</p>
          
          <p>I’ll cover best practices for hackers disclosing the vulnerability next week in
          part Ⅱ, and how to break the news to users in part Ⅲ.</p><br clear="all"><br>-- <br><div style="margin-left:40px">Noilson Caio Teixeira de Araújo<br>Linux Professional Institute Certification  2 - LPI000182893<br>

Novell Certified Linux Administrator (CLA) - 10111916<br>Novell Data Center Technical Specialist<br><br><a href="http://ncaio.ithub.com.br" target="_blank">http://ncaio.ithub.com.br</a><br><a href="http://br.linkedin.com/in/ncaio" target="_blank">http://br.linkedin.com/in/ncaio</a><br>

<a href="http://www.commandlinefu.com/commands/by/ncaio" target="_blank">http://www.commandlinefu.com/commands/by/ncaio</a><br><a href="http://www.dicas-l.com.br/autores/noilsoncaioteixeiradearaujo.php" target="_blank">http://www.dicas-l.com.br/autores/noilsoncaioteixeiradearaujo.php</a><br>

</div> <br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Owasp-natal mailing list</span><br><span><a href="mailto:Owasp-natal@lists.owasp.org">Owasp-natal@lists.owasp.org</a></span><br><span><a href="https://lists.owasp.org/mailman/listinfo/owasp-natal">https://lists.owasp.org/mailman/listinfo/owasp-natal</a></span><br></div></blockquote></body></html>