• Like
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.




Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 2. Luis Enriquez (IT/IP Lawyer. LLM, CEH, CHFI) luis.enriquez@owasp.org https://www.owasp.org/index.php/OWASP_Security_Labeling_System_Project
  • 3. • In 2010, Jeff Williams proposed a wonderful idea: A labeling system for disclosing vulnerabilities in Software. It was a great dropped idea. You can get that presentation here: http://www.slideshare.net/DinisCruz/2010-11-owaspsoftwarelabels • After joining the OWASP community in my local chapter, I got a very similar idea. I wrote to Jeff, and we think we can revive it. PRESENTATION
  • 4. • Luis Enriquez (IT Lawyer). • Jeff Williams (Security Expert). • Jorge Lara (Graphical dessigner). Would you like to join?? CONTRIBUTORS
  • 5. • The labeling system is a legal security program with technical implications. It is integrated by 4 labels: Security (Secure code), Privacy(Trust), Ingredients(Transparency), and Openness(Open security). • We need an attractive and easy going labeling system. Users will benefit because they want security, and to know what are they getting within a software. Developers will also benefit because OWASP labeled software would be preferred by users and other developers, in terms of technical and legal security. • We need transnational solutions. There are many jurisdictions, and applicable laws around the planet. The labeling system has to be transnational, so it can be easily applied. WHAT IS IT?
  • 6. • Security is invisible. We cannot know if any Application is 'good enough' in terms of security. The OWASP labels will make security visible. • In security there is not perfect, just “good enough”. Vulnerabilities will always exist. But the OWASP labeling system could at least certify that certain application is following basic security practices and respecting user's privacy. • Legal Liability 'by default' does not solve the problem. It does not incentive development, and it is more likely that developers hide vulnerabilities instead of sharing them. A labeling system is the alternative. WHY?
  • 7. (1) Create and Distribute opinion polls to different sides involved in the IT environment. (such as software developers, e-commerce agents, IT security firms, Cyber communities, Internet rights Associations, lawyers, and of course, users). This stage has already begun, and results are helping us to shape the model. • (2) Create the most suitable methodology for the security labeling system. The labeling system provides 4 logos and 4 clauses (1 for each badge). They should be incorporated as a “license exception” before the copyright license or license terms(for public licenses), or included into the custom copyright licenses, custom license contracts, terms of service, or privacy policies. • (3) Application of the labeling system. The OWASP labeling system volunteers will contribute to check that the system is working properly. The label can always be removed. ROAD MAP
  • 9. • Security criterion label (S). Security starts with SECURE CODING, and secure maintenance. This label certifies that the software is 'good enough' because it follows good security practices in its development life cycle, regular updates, and so forth. 1. SECURITY LABEL(S)
  • 10. • Inputs: OWASP projects and security guides. Such as OWASP Top Ten (scan policy), OWASP security coding principles, Open SAMM, and so on. • Inputs: Security Tools: Such as Zed Attack Proxy, SAINT, Dependency checker, and so on. • Implementation. Including the 'security clause' into your license contract, public license contract(as a 'license exception'), and a link to the report of all security guides, tools and standards used for security. 1. SECURITY LABEL(S)
  • 11. 2. PRIVACY LABEL(P)
  • 12. • Privacy(P). Security is also about TRUST. This label certifies that your software does not come with non-authorized spyware, and web applications follow ethical principles of data protection. 2. PRIVACY LABEL(P)
  • 13. • Privacy is not possible without security. We are all concerned about security. Non authorized spyware is not ethical, and ilegal in most jurisdictions. • Privacy is about TRUST. Users should trust in the IT industry. Software 'hacked by default' harms the industry. • Purpose of this label. The software producer declares in their contract that the package does not come with non authorized spyware. • Implementation. Include the 'privacy clause' in your license contract, public license(as a 'license exception'), terms of service, or privacy policy. Users must verify the hashsum of the packages. 2. PRIVACY LABEL(P)
  • 15. • Ingredients(I). Security is also about TRANSPARENCY. It certifies that all the ingredients of a computer program or Web application, are disclosed to the public. 3. INGREDIENTS LABEL(I)
  • 16. • Making software components public. This label certifies that the software reveals all its ingredients (eg. Shared libraries, APIs, plug-ins, and so on). It is very suitable for FOSS software. • Third party ingredients. With the ingredients label, it will be a lot easier to identify third party code. Identifying third party code will have a positive impact for developers and users in areas such as Warranties, contractual legal liability(if any), and Copyright licenses. • Easy Implementation. Including the 'ingredients clause' into your license contract, public license(as a 'license exception'), or terms of use, and a link to the report of all software components will be the only requirements. 3. INGREDIENTS LABEL(I)
  • 17. 4. OPENNESS LABEL(O)
  • 18. • Openness(O). This label consists about the open disclosure of vulnerabilities of Web Applications Software, to the public. 4. OPENNESS LABEL(O)
  • 19. • For the highest security. This label is dedicated to high security environments. Applications must be scanned in a regular basis (E.g. every week). The public would have access to the last vulnerability scanning report. • A fast security team. The security team will have to patch their vulnerabilities ( if any) before the next scanning date. • Implementation. Including the 'openness clause' into your license contract, or terms of use, and a regular report of your application vulnerabilities to the public. 4.OPENNESS LABEL(O)
  • 20. SPECIFICATIONS • Purpose of labels. Each label has its own purpose. There is not hierarchy between them. Any software or Web application can hold all of them, or just the ones they prefer. • A mutual compromise. Using the security labels means that there is a compromise between software developers and OWASP. The goals: SECURITY, TRUST, TRANSPARENCY, AND OPENNESS. • Prize of labels. In order to avoid unfair competition, labels would not have a prize. But donations are always welcome in order to cover logistic costs.
  • 21. • Applying for a label. The applicant will submit a registration into the labeling system site. Download the required logo and the labeling contracting clause. The 'logo' must be copied into the software distribution(or web site). • About the Clauses. The contract clauses make official the compromise of the software developer with the users. They must be added to the contract, license, terms of use, or privacy policy. When software is copyrighted under public licenses, it could be added as an additional term, or a declaration distributed within the license. • Just an automated process? No. the OWASP project team volunteers can always verify if the provided information is real. Violations to the labeling system can be reported by users. • Specifications and Labels can change. This is an open project, so please take all these proposals just as a departure point. We need to get the best out of it, so we are searching for better and new ideas. SPECIFICATIONS
  • 22. • If you want to become a team member, or just provide ideas and suggestions, please send them to: luis.enriquez@owasp.org • Or connect to our mailing list at: https://lists.owasp.org/mailman/listinfo/owasp_security_labeling_system_project Project Page: https://www.owasp.org/index.php/OWASP_Security_Labeling_System_Project FEEDBACK IS VERY IMPORTANT! GET INVOLVED