Recomendados
Más contenido relacionado
Destacado
Destacado (16)
The CSSLP Deconstructed and other topics related to Software Security
- 1. The CSSLP Deconstructed And other topics related to Software Security Alexander J. Fry Founder, Strong Crypto www.strongcrypto.com
- 2. Who am I? Founder – Strong Crypto, a software security consultancy (ISC)2 SME – question writer for the CSSLP examination Member – OWASP Global Industry Committee Co-author - The CSSLP Prep Guide
- 3. Introduction I’m a hands-on security professional. I perform code reviews and security testing, work with software developers, and train personnel. I’m here to share my perspectives on the CSSLP and other topics in software security. This is an informal presentation. Feel free to contribute to the discussion while it is underway. Just raise your hand and I’ll call on you when I get to a stopping point. All of the opinions expressed in this presentation are my own, but some of the CSSLP introductory material is from (ISC)2.
- 4. What is the CSSLP? Certified Secure Software Lifecycle Professional (CSSLP) It is a top-level (base) credential just like the CISSP Professional certification program Takes a holistic approach to security in the software lifecycle Tests candidates competency; knowledge, skill, and abilities (KSAs); to significantly mitigate the security concerns Source: (ISC)2 – CSSLP Launch Presentation
- 5. Purpose The purpose of the Certification is to provide a credential that speaks to the individual’s understanding of and ability to deliver secure software through the use of best practices. The target professionals for this Certification would be anyone who is directly and in some cases indirectly involved in the Software Lifecycle. Source: (ISC)2 – CSSLP Launch Presentation
- 6. Software Lifecycle Stakeholder Chart Top Management Business Unit Heads Auditors IT Manager Client Side PM Security Specialists Industry Group Delivery Heads Software LifecycleStakeholders Application Owners Business Analysts Developers/ Coders Influencers Quality Assurance Managers Project Managers/ Team Leads Technical Architects Primary Target Secondary Target Source: (ISC)2 – CSSLP Launch Presentation
- 7. (ISC)2 CSSLP CBK Domains Secure Software Concepts Secure Software Requirements Secure Software Design Secure Software Implementation/Coding Secure Software Testing Software Acceptance Software Deployment, Operations, Maintenance, and Disposal
- 8. Secure Software Concepts fundamental knowledge for understanding the security implications of software development, and the mechanisms to impose security constraints on the behavior, use, and content of a software system. This includes security design and information assurance principles, risk management, software architectures, legal issues, standards, acquisition methods, information security and software maturity models.
- 9. Secure Software Requirements the overall software specification should include both functional and nonfunctional requirements. The nonfunctional requirements of secure software address issues such as how the software application will: remain dependable under hostile operating conditions; resist compromise by an attacker through the exploitation of vulnerabilities or insertion of malicious code; and be resilient enough to recover quickly, containing damage to itself, data, resources, and external components on which it relies.
- 10. Secure Software Design fundamental activities that approach the definition of the software from a security perspective in order to decrease the likelihood that the design specification will contain flaws. These activities include identifying and minimizing the software's attack surface, performing threat modeling, and following security design principles.
- 11. Secure Software Implementation/Coding software developers should follow secure coding best practices and standards, understand and avoid common vulnerabilities and implement countermeasures, and use tools and techniques such as static analysis and code review to avoid introducing flaws that can lead to security vulnerabilities.
- 12. Secure Software Testing activities for evaluating a software application in a runtime environment that most closely resembles its production environment. Many testing activities require the application to be functionally complete and follow standards and methodologies such as ISO 9126, the SSE-CMM, and the Open Source Security Testing Methodology Manual (OSSTMM). Security testing should assess the security properties and behaviors of the software application as it interacts with external entities and as its own components interact with each other. An analysis of test results forms the basis for assessing risk and means of remediation.
- 13. Software Acceptance is concerned with ensuring that the software is ready to be released. This involves pre-release or pre-deployment activities such as generating test data that shows that all prescribed tests have been executed and accepted; and post-release activities such as an independent review of the software conducted by a third-party or by an independent security team of the organization.
- 14. Software Deployment, Operations, Maintenance, Disposal is concerned with maintaining information assurance during installation, deployment, operation, maintenance, and disposal of secure software systems.
- 15. Where is the CSSLP? First Attempt. Information Assurance Software Assurance CSSLP CBK CISSP CBK CISSP Application Development Security Domain
- 16. Where is the CSSLP? Second Attempt. Information Assurance
- 18. Signed candidate agreement and adherence to (ISC)2 Code of ethics
- 19. Proof of 4 years of FT experience in the Software Development Life Cycle (SDLC) process or 3 years plus 1 year waiver of experience for degree in an IT related field
- 20. $599
- 21. Candidate will have to pass the official (ISC)2 CSSLP certification examination and complete the endorsement process
- 22. An Associate of (ISC)2 Program will apply to those who have passed the exam but still need to acquire the necessary minimum experience requirementsSee http://www.isc2.org/csslp-certification.aspx for updated requirements
- 24. SANS: GSSP-C, GSSP-J (Language specific secure coding)
- 25. ISSECO: CSSE (Entry level education program with certificate of completion)
- 26. DHS: Software Assurance Initiative (Awareness Program/Forum)
- 27. Vendor-Specific: Sun Microsystems SCJP, Microsoft MCSD, Symantec - based on internal lifecycle process or technology specificSource: (ISC)2 – CSSLP Launch Presentation
- 28. GSSP-C (SANS) Software Coder Certification Program GSSP-J (SANS) Software Coder Certification Program CSSE (ISSECO) Entry-level Education Program Certificate of Completion Software Assurance Initiative (DHS) Awareness Effort CSDA (IEEE) Associate Level Status CSDP (IEEE) Professional Certification Program Vendor-Specific Credentials CSSLP CBK Overlap with other Certifications/Programs CSSLP (ISC)² Professional Certification Program Source: (ISC)2 – CSSLP Launch Presentation
- 29. State of the CSSLP International Marketing Efforts ANSI/ISO/IEC 17024 accreditation DoD 8570.1 directive CSSLP Education Seminars: (ISC)2 held one from January 11-15, 2010 in Ashburn, VA The first prep guide is for sale: The CSSLP Prep Guide.
- 30. Do you need the CSSLP? Certification vs. Legion Against Meaningless Certifications (LAMN) “Anyone who believes that a credential automatically conveys some magical knowledge that you didn't have before is just as overly-simplistic as someone who disparages all credentials equally. It just isn't a black and white world. – Paco Hope“ “Because academia can't produce enough surgeons to satisfy all security demands (and indeed because entire armies of less specialized `healthcare professionals’ are necessary), the idea of a certification makes plenty of practical sense. – Gary McGraw” In reference to the CISSP - http://www.darkreading.com/document.asp?doc_id=123606 “A second term CISSP demonstrates more value than a first year CISSP” Are you a stakeholder in the SDLC? Is the CSSLP going to be part of your lifelong learning program? Is it important to your career to be recognized as a CSSLP?
- 31. You are the CEO of YOU INC How should the CSSLP be pronounced? C.SLIP; C.S.S.L.P, CIS.LIP (sis-lip) Where is the (ISC)2 guidance? Why not the Certified Software (Security) Assurance Professional C.SWAP? Building Security In is Implied “Effective career management is going to be critical to your personal success and attainment of your individual career goals.” – Lee Kushner http://www.owasp.org/images/a/af/The_Entrepreneurs_Guide_to_Career_Management-Lee_Kushner.pdf
- 32. The CSSLP Prep Guide The first and only (for a few more months) prep guide for the CSSLP Broad coverage of all seven domains of the CSSLP CBK A software security assurance text book disguised as a certification prep guide Uses the attacker’s perspective to teach some of the security concepts Almost 700 pages, lots of references to other tools and resources, end of chapter practice questions, testing engine on CD, comprehensive glossary
- 33. Additional Topics Software Security Risk Recent Threats 3rd Party Software Addressing Risk for 3rd Party Software
- 34. Software Security Risk Need to follow a risk-driven approach to improving the security of software. Applications come from: in-house, outsourced, commercial, open source or a combination, e.g., commercial but customized in-house, open source libraries in in-house applications For existing legacy applications, do you deploy real-time protections or take off-line and fix? Compliance should be leveraged to build/acquire more secure applications Use the attacker’s perspective to determine risk, e.g., threat modeling, understanding the deployment environment(s) Security problems will emerge! To keep up with emerging threats, you need to perform regular maintenance, periodically test, and continuously monitor applications.
- 35. Recent Threats “Symantec is grappling with a date-stamp problem that has seen all its security updates dated 2010 rejected by its own servers.” - http://news.zdnet.co.uk/security/ “Adobe Zero-Day Attack Solution: Disable JavaScript” – No patch available: Many corporate applications use JavaScript in PDFs for important functions like forms processing and it’s used by Google Docs for printing support. http://www.shadowserver.org/wiki/pmwiki.php/Calendar/20091214 “NIST-certified USB Flash drives with hardware encryption cracked” – FIPS 140-2 Level 2 drives AES 256-bit. http://bit.ly/6X281y
- 36. 3rd Party Software Lack of visibility into the third party software development lifecycle. Unknown level of software assurance. Little or no access to source code. Limited internal resources to address this risk. Don’t want to introduce vulnerabilities into the organization. Want to be proactive instead of reactive.
- 37. Addressing Risk for 3rd Party Software “Contract language should specify that security assurance will be provided as a condition for accepting deliverable applications.” – Gartner DHS Build Security In Web Site: “Software Assurance (SwA) in Acquisition: Mitigating Risks to the Enterprise” OWASP Legal Project: Contract Annex For a commercial vendor that does not have the required assurance evidence, use an expert consultant or a Software as a service (SaaS) solution that supports static and dynamic testing: Fortify on Demand: any 3rd party development team can test and score the security of their application, review results, and then publish a report back to their customer. Veracode: uses binary analysis (doesn’t require source code) to allow transparency into the security of COTS or outsourced applications. Open source software: Fortify Open Review Project identifies and reports bugs and security vulnerabilities in widely used open source software. Have the developers submit the software. https://opensource.fortify.com
- 38. Open Web Application Security Project Focused on improving the security of application software. Mission is to make application security visible, so that people and organizations can make informed decisions about true application security risks. All materials are available under a free and open software license I’m a member of the Global Industry Committee at OWASP: http://www.owasp.org/index.php/Global_Industry_Committee Has monthly meetings like ISSA and hosts worldwide conferences like OWASP App Sec DC 2009 – slides from the presentations are available at http://www.owasp.org
- 39. Communications Web Site: http://strongcrypto.com Twitter: http://twitter.com/alexanderjfry Facebook: http://facebook.com/alexander.j.fry LinkedIn: http://linkedin.com/in/alexanderfry
Notas del editor
- ISSA-NOVA has had a lot of recent exposure to software security themes. For example, the November 2009 issue of the ISSA Journal has an excellent article on “What You Don’t Know, Can Hurt You: Security Professionals and Applications by John Dickson of the Denim Group. The article brings up a good point that most security managers lack a background in software development and rarely, if ever, have control over internal development. Unfortunately, these same people may be responsible for the security of internally developed applications and will likely be held accountable, should a data breach occur. Last month, Kenneth Fritzsche gave a presentation to ISSA-NOVA called Perspectives on Application Security that sets the groundwork for a lot of the stuff I’m going to talk about today.ISC2 held a CSSLP Education Seminar last week in Ashburn, VA. You may also have attended ISC2’s CSSLP Launch Presentation. I also have a few slides from that presentation to go over today, but my intent is to cover material that ISC2 has not already discussed so I will probably move through those slides quickly.
- It was difficult to choose what to include in this presentation and what to leave out, considering you could write a whole book on this subject. So, I’d like to keep the presentation as informal as possible. Feel free to ask questions as we go along and if I can answer the questions between slides, I’ll do so. If not, we can discuss after the presentation in a Q&A.
- The title of this slide is also the most common question I’m asked. In addition to all of the above, the CSSLP represents an acknowledgement by industry that attackers are shifting to software; they have always targeted widely distributed software like Microsoft Windows and Internet Explorer, and in recent years they have focused on public facing interconnected and custom software like Web and mobile applications. All of the latest trends in computing from smart phone technology like the iPhone to Cloud computing have software components that have been the target of attack. As the vendors and application owners patch the software, the attackers move on to easier vulnerabilities to exploit. The CSSLP is about addressing the root cause of these vulnerabilities, by integrating integrating security throughout the software life cycle so the software produced has fewer obvious vulnerabilities or known risks and is capable of defending itself from attack.
- Influencers – are those stakeholders that would not necessarily be qualified or targeted for certification but have the influence over ensuring that a security mindset is established as part of the business practice and would support or make decisions about spending the money to train and certify the staffPrimary Target – are the most likely candidates for this education and certification program and would meet qualificationsSecondary Targets – are those who are less likely to meet qualifications but could benefit from the education and aspire to obtaining the CSSLP as they move up in their career path.
- These are the seven domains of the CSSLP. They also mirror the typical software life cycle processes. Let’s review these domains in the following slides.
- Secure Software Concepts include risk management and software assurance activities in the Software Development Lifecycle, regulations, privacy, and compliance like PCI, FISMA, or HIPAA, International standards like ISO, security enhanced software development methodologies, intellectual property, privacy, and legal issues, capability maturity models, software assurance maturity models, acquisition assurance issues, and many other knowledge areas where software security should be emphasized. This domain has a lot of crossover with CISSP domains.
- The most common Web application security weakness is the failure to properly validate input from the client or the environment. The best strategy for input validation is called “whitelist” or “positive” validation. The idea is to check the input data against a set of tightly constrained good values. For example, when writing the requirements for the Web application, one of the requirements might be: “The application shall validate all input with a positive specification of data type, length, range, if a numeric, and allowed characters.”
- Many software security vulnerabilities are not coding issues, but design issues. Security issues in design and semantic flaws (ones that are not syntactic or code related), such as business logic flaws, cannot be detected in code and need to be discovered by performing threat modeling, and applying abuse cases. Threat modeling is an iterative-structured technique used to identify threats to the software being built. It starts by generating a software context that includes data flow diagrams, and end-to-end deployment scenarios, identifying entry and exit points, protocols, components, identities, and services. Attack surface are the entry and exit points of the application that are accessible to users and attackers. Threat modeling is performed during the design stage so that necessary security controls that counter the identified threats and vulnerabilities, can be implemented during the coding stage.
- Developers also write critical applications that depend on open source and third-party libraries and APIs. These components should not be trusted until they have been subjected to rigorous security testing. For another example, developers should not build enterprise Web applications with unmanaged languages, e.g., scripting languages like PHP, which is difficult to secure properly.
- Software can be tested as soon as the first few lines of code compile by incorporating automated static analysis tools into the build process. As soon as the software is deployable, dynamic analysis of the software components can begin. Security testing should use both automated and manual means to ensure full code coverage and address all areas of the attack surface. Security tests should be documented and repeated as the software is being built, similar to how functional tests are run on the software as soon as a functional area has been completed.
- No software application should be accepted, if the vendor can not prove software security assurance. If the software application is being built in-house and the development team lacks a security assessment capability, they should work with an independent party to have the software vetted. I discuss third-party verification towards the end of this presentation.
- There is still much work to be done after software has been deployed. Take a Java Web application for example. Once a Java Web application has been deployed, it still needs to be maintained. Maybe there is an update to the JRE, Web Application Server, or Web Server. These are typically operating system components but they affect the security of the Web application itself. These runtime components should first be updated in a staging environment that duplicates production. And after these components are updated, parts of the code may be become deprecated and should probably be re-written because safer and better API calls have replaced them. The application then has to go through security testing again before the new version of the software is deployed. Also, the operating environment is part of the software system. It is important to understand how the software configures itself, its dependencies on environment variables, how those variables are secured, the registry, etc. But the concern isn’t just with a single application, but other applications that might live in the same environment. For example, one application is locked down, but the other application allows path traversal and upload into the document root of the locked down application. This type of problem is just as prevalent if not more prevalent on the desktop, where one application introduces vulnerability in the way it interacts with its environment.
- If the CISSP is a mile wide and an inch deep, then the CSSLP it is at least a mile wide and a foot deep. Software assurance is about creating better software; security is one aspect of it, so is safety and quality. Building more secure software will have a positive influence on safety and quality to increase overall software assurance. I liken this to innovations in the automotive industry. Cars that have safety and protection mechanisms and are reliable are considered better cars than those that don’t. Better software assurance will increase overall information assurance.
- In this diagram, the ISSEP overlaps with both the CSSLP and the CISSP. Software Assurance is not outlined separately but is implied to be part of overall Information Assurance.
- Here are the CSSLP Certification Requirements. There are updated requirements on the ISC2 Web site.
- This is another slide from the ISC2 CSSLP Launch Presentation. These key players are shown on the following slide.
- *ISC2 is conducting international marketing efforts.*ANSI: They are likely seeking ANSI certification this year because the program needs to be running at least 1 year before they can applyDoD 8570.1: I heard some discussion about the CSSLP being included in 8570.1 or another mandate by the DoDOf course, ISC2 is holding education seminars based on demand and my prep guide is for sale.