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)
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)
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
