1. CSSLP Deconstructed The And other topics related to Software Security
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.
Alexander J. Fry
Founder, Strong Crypto

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

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
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.
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
Auditors
Business Unit Heads
Client Side PM
IT Manager
Security Specialists
Industry Group
Delivery Heads
Software Lifecycle Stakeholders
Application Owners
Business
Analysts
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 staff
Primary Target – are the most likely candidates for this education and certification program and would meet qualifications
Secondary 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.
Developers/
Coders
Quality
Assurance
Managers
Project Managers/
Team Leads
Influencers
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
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.

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

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.
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.”

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

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

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

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

14. Software Deployment, Operations, Maintenance, Disposal
is concerned with maintaining information assurance during installation, deployment, operation, maintenance, and disposal of secure software systems.
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.

15. Where is the CSSLP? First Attempt.
Information Assurance
Software Assurance
CSSLP CBK
CISSP CBK
CISSP Application Development Security Domain
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.

16. Where is the CSSLP? Second Attempt.
Information Assurance
CSSLP
CISSP
ISSEP
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.

17. CSSLP Certification Requirements
Roughly:
Examination registration form
Signed candidate agreement and adherence to (ISC)2 Code of ethics
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
$599
Candidate will have to pass the official (ISC)2 CSSLP certification examination and complete the endorsement process
An Associate of (ISC)2 Program will apply to those who have passed the exam but still need to acquire the necessary minimum experience requirements
See for updated requirements
Here are the CSSLP Certification Requirements. There are updated requirements on the ISC2 Web site.

18. Key Players
While there is no indication that other organizations in this space are addressing the knowledge areas in the same manner as the CSSLP, the following are addressing software development and/or security in the software lifecycle:
IEEE: CSDA and CSDP (Software Development)
SANS: GSSP-C, GSSP-J (Language specific secure coding)
ISSECO: CSSE (Entry level education program with certificate of completion)
DHS: Software Assurance Initiative (Awareness Program/Forum)
Vendor-Specific: Sun Microsystems SCJP, Microsoft MCSD, Symantec - based on internal lifecycle process or technology specific
This is another slide from the ISC2 CSSLP Launch Presentation. These key players are shown on the following slide.
Source: (ISC)2 – CSSLP Launch Presentation

19. Professional Certification
CSSLP CBK Overlap with other Certifications/Programs
GSSP-C
(SANS)
Software Coder
Certification Program
GSSP-J
(SANS)
Software Coder
Certification Program
CSSLP
(ISC)²
Professional Certification
Program
CSSE
(ISSECO)
Entry-level
Education Program
Certificate of Completion
Software
Assurance
Initiative
(DHS)
Awareness Effort
Vendor- Specific Credentials
CSDA
(IEEE)
Associate Level
Status
CSDP
(IEEE)
Professional
Certification Program
Source: (ISC)2 – CSSLP Launch Presentation

20. State of the CSSLP International Marketing Efforts
ANSI/ISO/IEC accreditation
DoD 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.
*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 apply
DoD : I heard some discussion about the CSSLP being included in or another mandate by the DoD
Of course, ISC2 is holding education seminars based on demand and my prep guide is for sale.

21. 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 -
“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?
Not everyone agrees that certification is necessary. For example, The Legion Against Meaningless Certifications or (LAMN) LinkedIn group, which began as an thread on the Secure Coding Mailing List, states that “Not a CISSP? Or a CCNA, MCSE, OCP, or any of the other certifications that show you know how to cram for an exam but not much else? And don't feel the least bit shamed by it? Here's a group where the only qualification is that you NOT have any of those meaningless certifications after your name.” A lot of the people who signed up on this list were already experts in computer security or software security. Some of them already have a PhD or a specialized degree in Secure Software Systems like that offered by JMU. I have a different opinion because I came out of the IT world. Technology was moving at such a fast pace, well ahead of the curriculum in university courses. I pursued certifications to validate my skills, experience, and knowledge and they became stepping stones on my life-long learning plan. Of course, not all credentials are created equal. For example, the Red Hat Certified Engineer (RHCE) exam requires hands-on troubleshooting of a broken Linux installation as well as configuration of many different services without benefit of an admin guide – it is very challenging. And ISC2 credentials like the CISSP and CSSLP require that the credential holder acquires CPEs. Therefore, it is also part of a lifelong learning program. There was another quote on this thread by Paco Hope that I thought was relevant to this point, He said, "Although point entry is tedious, it keeps the cert honest. You can't spend 3 years converting oxygen into CO2 and remain certified. You actually have to do a few things. A CISSP person who has renewed once or twice is quite different from someone who has passed the exam after a cram session. Someone who certified once and lets their certification lapse is indistinguishable from the marginally-qualified candidate who crammed, passed, but ultimately couldn't maintain their cert. To reject certifications altogether is (to me) to endorse a continuation of the wild, wild west attitude towards security. Hire the best gunslinger you can get, and figure out who that is by word of mouth, rumor, and wanted posters at the post office. Like it or not, the citizens of this wild west are going to demand governance by a recognizable authority.”
And something else I should mention, I have seen that human resources has already started to write the CSSLP into job requirements in the Washington post, dice, etc.

22. 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 er_Management-Lee_Kushner.pdf
I think it is also important to mention how you should market yourself and the CSSLP, and even how it is pronounced. Credit for the title of this slide goes to Lee Kushner, who gave a great presentation at OWASP App Sec DC 2009 entitled, “CEO of You Inc.” I prefer C-SLIP because it seems like the easiest to pronounce. However, I think the credential could have been named C-SWAP as well, because it emphasizes software security assurance. Lee Kushner’s slides are available on the OWASP Web site at the URL above.

23. 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
I co-authored the CSSLP Prep Guide with Ronald Krutz, who you may also know as the co-author of the CISSP Prep Guide. The strengths of the prep guide are broad coverage of all of the subject areas in the seven domains of the CSSLP.

24. Software Security Risk Recent Threats 3rd Party Software
Additional Topics
Software Security Risk
Recent Threats
3rd Party Software
Addressing Risk for 3rd Party Software
It was hard to prioritize which topics to cover in this presentation because there are many good and important areas to discuss. What I selected was software security risk, to discuss some recent threats that have something to do with software security, and addressing software risk for 3rd party software.

25. 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.

26. Recent Threats
“Symantec is grappling with a date-stamp problem that has seen all its security updates dated 2010 rejected by its own servers.” -
“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.
“NIST-certified USB Flash drives with hardware encryption cracked” – FIPS Level 2 drives AES 256-bit.
Once you start studying software assurance, you will realize that IT security was always about software; operating system patches are software and so is router firmware. Software is in every part of the TCP/IP stack.
With regard to this Symantec security problem, the bug is actually a code quality issue with security implications and might have been caught early in the software life cycle during a manual code review or automated static analysis. This is the same type of bug that was fixed for Y2K, and is still a problem!
Adobe Reader/PDF is pervasive on computer desktops and it has been a frequent target of attack and exploit in the last few years. This particular vulnerability is critical and is being used in targeted attacks to hijack data from compromised computers. As of January 12th, there was no patch or update available that completely protects against this exploit. There is little or no detection of these malicious PDF files from most of the major antivirus vendors. The vulnerability is in the JavaScript function within the Reader itself. And the JavaScript is obfuscated inside a zlib stream making universal detection and intrusion detection signatures much more difficult to craft.
In general, scripting languages like JavaScript are a big problem. For example, Cross-site scripting carried out on websites were roughly 80% of all security vulnerabilities documented by Security vendors as of The Samy worm used XSS for propagation on MySpace in XSS is not going anywhere. And XSS can facilitate powerful and emerging threats like Cross-Site Request Forgery or the exfiltration of data from internal networks.
The third recent event concerns USB drives with AES 256-bit hardware encryption. These drives encrypt stored data via the very strong AES 256-bit encryption system. The main security mechanism on these drives is therefore the authentication mechanism, where the user supplies a master password to decrypt the plaintext data stored on the drive. When analyzing the Windows client software for a number of drives from Kingston, SanDisk, and Verbatim; a security firm called SySS found an authentication bypass flaw. It turns out the the Windows client software, irrespective of the password supplied by the user, always sends the same character string to the drive after performing various crypto operations. How could these drives ever have been FIPS certified? The lesson here is that compliance does not equal security. Should the government review the security testing procedures and results for FIPS compliant hardware before making a purchasing decision?

27. Unknown level of software assurance.
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.
I chose to discuss 3rd party software because this is an area where you can make a big impact right away. Your choices will affect your organization and all of your vendors.

28. 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.
The end result of this practice is that your organization uses highly assured 3rd party frameworks, third-party libraries, and software.

29. 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:
Has monthly meetings like ISSA and hosts worldwide conferences like OWASP App Sec DC 2009 – slides from the presentations are available at
I wanted to mention that OWASP is a resource for ISSA members. I find it valuable to participate in both ISSA and OWASP organizations and I’m on the Global Industry Committee at OWASP. One important thing that we do is outreach to sector-specific critical infrastructures worldwide. Please contact me if you think your organization could benefit from working with OWASP.

30. Communications Web Site: http://strongcrypto.com
Twitter:
Facebook:
LinkedIn: