1. Software Development: The Next Security Frontier
Glenn Johnson
Certification Consultant
(ISC)2 Americas
James E. Molini, CISSP, CSSLP
Microsoft
Member, (ISC)² Advisory Board of the Americas
This presentation is intended to discuss software development security from a general perspective, talking primarily about the need for more secure software and the common concepts in use today. The presentation takes a methodologically agnostic approach and focuses on broad concepts and issues of interest to software developers. It also attempts to introduce some concepts included in the Common Body of Knowledge for the new CSSLP Certification.
As a way to describe common concepts, the presentation discusses 4 steps to improved software security. This allows us to provide an overview of core principles and activities that are important to any software security program. The presentation tries to stay away from proprietary methods and focuses exclusively on those things that are generally available in the community.
Software Development: The Next Security Frontier

2. More than 60,000 certified professionals in over 130 countries.
Global leaders in certifying and educating information security professionals with the CISSP® and related concentrations, CSSLPCM, CAP®, and SSCP®.
Celebrating our 20th Anniversary – not-for-profit consortium of industry leaders.
More than 60,000 certified professionals in over 130 countries.
Board of Directors - top information security professionals worldwide.
All of our information security credentials are accredited ANSI/ISO/IEC Standard with the CISSP being the first technology-related credential to receive this accreditation.
CSSLP is not yet ANSI certified.

3. Over 70% of security vulnerabilities exist at the application layer*
*Source: Gartner Group, 2005

4. Malware increased by 200-300% over the past year
De-perimiterization of networks places more burden on the security of individual machines and applications
Malware increased by % over the past year
More incidents of data loss could result in greater government oversight and regulation
38 out of 50 states in US have now enacted breach disclosure laws
2008 (ISC)² Global Information Security Workforce Study (GISWS) report found significant costs result from data breaches
US $50 to $200 per record lost (not including reputation damage and loss of trust or loss of contracts)
‘IT Management can’t rely on minimal security efforts’ (IT Compliance Institute’s ‘10 Big Predictions’ for 2008)-
Most analysts predict more malware and more misuse of authority.
Government may start making rules for software vendors. NYS is now proposing a law that requires vendors to implement security controls on delivered software (based around OWASP Top 10).
Breach disclosure now requires you to tell everyone when you have been hacked (TJX, Heartland, etc.)

5. Software Vulnerabilities:
Opening the Door to Criminals
XSS Attacks (Ongoing)
Cross Site Scripting (XSS) is becoming the new “buffer overflow”
In 2007, XSS accounted for 80% of documented vulnerabilities
Proper web site coding practices reduce the risk from XSS
SQL Injection Attacks (Ongoing)
Recently several security sites were attacked using this technique
Data entry fields on websites are loaded with SQL commands
Bypasses the firewall and many web gateways
Input validation reduces the exposure from this attack
Recent worms exploit patching latency
Conflicker worm released 1 month after the patch from Microsoft
This exposes a flaw in patch management practices
In the industry, we’ve done a pretty good job of keeping vulnerabilities from being exploited, but they still have to be patched and that takes more people and more money.
The largest Credit Card breach on record is the Heartland Systems breach of It was conducted ostensibly through use of key logging software, installed on the payment card processor’s internal networks, through an unsecured Wi-Fi connection. See:
The Privacy Rights Clearinghouse reported that there have been at least 246 million payment card records stolen since 2005.
In 2008, most security experts agreed that XSS had replaced the Buffer Overflow as the most common form of system breaking attack on the Internet. See:
SQL Slammer-started at 05:30 UTC on January 25, The worm was based on proof of concept code demonstrated at the Black Hat Briefings by David Litchfield, who had initially discovered the buffer overflow vulnerability that the worm exploited.[1] It is a small piece of code that does little other than generate random IP addresses and send itself out to those addresses. If a selected address happens to belong to a host that is running an unpatched copy of Microsoft SQL Server Resolution Service, the host immediately becomes infected and begins spraying the Internet with more copies of the worm. First reported by Microsoft on July 24, From Wikipedia.org.
Code Red-July 13, Although the worm had been released on July 13, the largest group of infected computers was seen on July 19, On this day, the number of infected hosts reached 359,000.[1] The worm exploited a vulnerability in the indexing software distributed with IIS, described in MS01-033, for which a patch had been available a month earlier. The worm spread itself using a common type of vulnerability known as a buffer overflow. It did this by using a long string of the repeated character 'N' to overflow a buffer, allowing the worm to execute arbitrary code and infect the machine. From Wikipedia.org.
Nimda-isolated in September It quickly spread, eclipsing the economic damage caused by past outbreaks such as Code Red. Multiple propagation vectors allowed Nimda to become the Internet’s most widespread virus/worm within 22 minutes. Nimda was so effective partially because it—unlike other famous malware like the Morris worm or Code Red—uses five different infection vectors:
via
via open network shares
via browsing of compromised web sites
exploitation of various Microsoft IIS 4.0 / 5.0 directory traversal vulnerabilities. (Both Code Red, and Nimda were hugely successful exploiting well known and long solved vulnerabilities in the Microsoft IIS server.[1])
via back doors left behind by the "Code Red II" and "sadmind/IIS" worms
From Wikipedia.org

6. What Is Software Security?
Security is a distinct property of a software system or application. It is composed of Confidentiality, Integrity, Availability, Authenticity, and other related attributes*.
Software Security vs. Secure Software
Secure software can be delivered by rigorously applying all the techniques of a software security plan
Software Security vs. Secure Coding
Secure coding is one aspect of an overall software security plan
Software Security vs. Software Quality
High quality software can also be insecure
Security requires specialized skills
Let’s talk about what software security is and what it is not.
Some people argue that insecure software is not necessarily high quality software. However, as a counter example, much of the life safety software deployed around the world is not secure. For example, there are no security controls built into the Space Shuttle’s Operating System, but it operated in a restricted environment.
*Definition derived from description provided in Software Assurance BoK from DHS.

7. Can’t We Just Learn How to Write Secure Code?
Common misconception that writing secure code is the only answer
Many eyeballs won’t solve the security problem. (e.g. recent DNS bug took 10 years to discover)
Software security requires:
1) Policy -- pertinent and enforceable
2) Process -- formal and structured
3) People -- trained and qualified (first line of defense and organization’s most critical asset)
Secure Coding does not answer the following questions:
Who wrote the requirement defining the required level of security?
Who allocates the security functionality?
Who identifies the areas needing protection inside the threat model?
Who ensures security for the patching process?

8. Can Secure Systems Really Prevent Intrusions?
Two Firewalls. Two manufacturers. Two development methodologies.
One was based on a Trusted OS & Security Development Lifecycle.
One was not.
1999
2000
2001
2002
Total
Firewall-A 3 15 10 4 32
Firewall-B
This is an example of secure development making a difference. The coding practices described here are provided only as historical examples.
Example FW-A Vulnerability:
User Defined Keywords Access
Firewall-A could allow a remote attacker to gain unauthorized access to restricted services, caused by a vulnerability that occurs when certain reserved keywords are used in user-defined objects. If one of the affected reserved keywords is used to represent any user-defined object in a rule, the default "ANY" address may be used in the rule, which could cause unexpected denied access to certain services, or could allow unauthorized access to those services.
A vulnerability in the Fast Mode (or FASTPATH) option for TCP services could allow a remote attacker to bypass preset TCP rules. If Fast Mode is enabled for a rule, a remote attacker can use a series of malformed TCP packet fragments to connect to a system behind the firewall. The attacker must know the IP address of the system to attempt a connection.
Check Point FireWall-1 could allow a local attacker to overwrite .log files and create symbolic links to corrupt root owned files. Check Point Firewall-1 fails to properly check for the existence of .log files when saving files using the Log Viewer function. A local attacker with administrative privileges can use this vulnerability to overwrite .log files and launch a symlink attack to corrupt root owned files, which would deny service to legitimate users.
Vulnerabilities listed by US Natl. Vulnerability Database:
To perform your own search, visit:

9. Common Elements of a Software Security Program

10. Overview What does it take to build secure software?
Developing a professional standard in software development.
Elements of effective software security programs.
Security programs are valuable both for commercial software and in-house development

11. Secure Software Concepts
Confidentiality, Integrity, Availability Authentication, Authorization, and Auditing
Security Design Principles
Risk Management (e.g., vulnerabilities, threats and controls)
Regulations, Privacy, and Compliance
Software Architecture (e.g., layers)
Software Development Methodologies
Legal (e.g., Copyright, IP and trademark)
Standards (e.g., ISO 2700x, OWASP)
Security Models (e.g., Bell-LaPadula, Clark-Wilson & Brewer-Nash)
Trusted Computing (e.g., TPM, TCB)
Acquisition (e.g., contracts, SLAs and specifications)

12. Getting Started Training and Awareness Appoint or hire a Security Lead
Start with basic concepts
Train developers and testers first
Appoint or hire a Security Lead
Becomes local authority on software security
Coordinates security activities and drive SDL
Establishes risk management process

13. Secure Software Requirements
Policy Decomposition
Confidentiality, Integrity, Availability Requirements
Authentication, Authorization, and Auditing Requirements
Internal and External Requirements
Identification and Gathering
Data Classification
Use Cases
Abuse Cases (inside and outside adversaries)

14. Secure Software Requirements: Getting Started
Build boilerplate requirements for use in new projects
Understand how requirements differ for:
In-house development
Product Development
Software Acquisition
Develop common abuse cases
Begin Risk Management Process
Threat Model Development
Feature/Component Risk Analysis

15. Secure Software Design
Design Processes
Attack surface evaluation, Threat modeling, Control Identification, Control prioritization
Design Considerations
Confidentiality, Integrity, Availability, Authentication, Authorization, and Auditing
Security design principles, Interconnectivity, Security management interfaces, Identity management
Architecture
Distributed, Service-oriented, Rich Internet applications, Pervasive computing
Integration with existing architectures
Software as a Service
Technologies
IAM, Audit, DRM, Flow control (e.g., proxies, firewalls, middleware)
Data protection (e.g., DLP, encryption and database security)
Computing environment (e.g., programming languages, virtualization, and operating systems
Integrity (e.g., code signing)

16. Secure Software Design: Getting Started
Saltzer & Schroeder: Security Design Principles
Economy of mechanism
Fail Safe Defaults
Complete Mediation
Open Design
Separation of Privilege
Least Privilege
Least Common Mechanism
Psychological acceptability

17. Secure Coding: Key Concepts
Declarative versus programmatic security (e.g., bootstrapping, cryptographic agility, and handling configuration parameters)
Common software vulnerabilities and countermeasures
Defensive coding practices (e.g., type safe practices, locality, memory management, error handling)
Exception management
Configuration management (e.g., source code and versioning)
Build environment (e.g., build tools)
Code/Peer review
Code Analysis (static and dynamic)
Anti-tampering techniques (e.g., code signing)
Interface coding (e.g., proper authentication and third party API)
Common software vulnerabilities and countermeasures
OWASP and CWE vulnerability categories
Virtualization
Side Channel (e.g., cold booting)
Embedded systems

18. Secure Coding: Getting Started
Never build your own crypto or authentication mechanisms
Develop a list of banned functions
Train developers to avoid most common flaws
Develop with least privilege

19. Secure Software Testing: Key Concepts
Testing for Security Quality Assurance
Functional Testing (e.g., reliability, logic, performance and scalability)
Security Testing (e.g., white box and black box)
Environment (e.g., interoperability)
Bug tracking (e.g., defects, errors and vulnerabilities)
Attack surface validation
Test types
Penetration Testing
Fuzzing, Scanning, Simulation Testing (e.g., environment and data)
Testing for Failure
Cryptographic validation (e.g., environment and data)
Impact Assessment and Corrective Action
Standards for software quality assurance (e.g., ISO 9126, SSE-CMM and OSSTMM)
Regression testing

20. Secure Software Testing: Getting Started
Use security testing tools to discover common vulnerabilities.
Implement static analysis testing for all Internet facing code.
Add security bug categories to the bug tracking system

21. Secure Software Acceptance & Deployment: Key Concepts
Pre-release or pre-deployment
Completion Criteria (e.g., documentation, BCP)
Risk Acceptance
Documentation (e.g., DRP and BCP)
Post-release
Validation and Verification (e.g., Common Criteria)
Independent testing (e.g., third-party)
Installation and Deployment
Bootstrapping (e.g., key generation, access management)
Configuration Management (e.g., elevated privileges, hardening, platform change)

22. Secure Software Acceptance & Deployment: Getting Started
Develop an official security signoff during release
Define rules for software security acceptance
Implement a security documentation standard

23. Secure Software Operations & Maintenance: Key Concepts
Operations and Maintenance
Monitoring (e.g., Metrics and Audits)
Incident Management
Problem Management (Root Cause Analysis)
Patching
End of life policies

24. Secure Software Maintenance: Getting Started
Implement patch security testing and delivery mechanisms
Develop a Security Response Plan for software vulnerabilities

25. Building secure software, along with writing secure code, is critical now!
Software Assurance has kaleidoscope of perspectives to be factored into secure software lifecycle.
First line of defense is qualified and educated personnel who know how to write secure code that meets security requirements, including design, testing deployment, and ultimately disposal of software. 25

26. CSSLP CBK Overlap between 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
Please be sure to mention that this is our findings as of now and more research will be done regarding this chart.
The question mark represents the need for a credential that covers all of these areas.
The overlap (while not fully verified but to the best of our knowledge) indicates where we see the other credentials covering the material contained in the CSSLP CBK.
Basically no other credential is covering the subject matter from the holistic perspective that the CSSLP CBK encompasses.
Vendor- Specific Credentials
CSDA
(IEEE)
Associate Level
Status
CSDP
(IEEE)
Professional
Certification Program

28. What is CSSLPCM?
Certified Secure Software Lifecycle Professional (CSSLP)
Base credential (no other certification is required as a prerequisite)
Professional certification program
Takes a holistic approach to security in the software lifecycle
Tests candidates competency (KSAs) to significantly mitigate the security concerns

29. Purpose
Addresses building security throughout the entire software lifecycle – from concept and planning through operations and maintenance, to the ultimate disposal.
Provides a credential that speaks to the individual’s ability to contribute to the delivery of secure software through the use of standards and best practices.
The target professionals for this certification includes all stakeholders involved in the Software Lifecycle. 29

30. Software Lifecycle Stakeholder Chart
Top Management
Auditors
Business Unit Heads
Client Side PM
IT Manager
Industry Group
Delivery Heads
Security Specialists
Software Lifecycle Stakeholders
Business
Analysts
Application Owners
The chart represents all stakeholders in the software lifecycle
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
Technical Architects

31. CSSLPCM Industry Supporters
Microsoft
BASDA
Cisco
SANS
Xerox
DSCI (NASSCOM)
SAFECode
SRA International
Symantec
ISSA
“As the global dependence on information and communications technology has grown, users have become increasingly concerned over the security of software, especially those in the government, critical infrastructure and enterprise sectors. By offering software professionals a means to increase and validate their knowledge of best practices in securing applications throughout the development lifecycle, (ISC)²’s CSSLP is helping the industry take an important step forward in addressing the ‘people’ part of the solution.”
Paul Kurtz, executive director, SAFECode

32. Certified Secure Software Lifecycle Professional (CSSLPCM) Domains
(ISC)²® 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
Result of numerous focus groups and a formal JTA study. 32

33. CSSLPCM Certification Requirements
By Examination:
Process
The first public exam will be held at the end of June 2009
Candidate must submit:
Completed examination registration form
Proof of 4 years experience in the Software Development Lifecycle (SDLC) or 3 years experience with a one year waiver for 4-year degree or equivalent in an IT related field
Pay a Fee of $549 early-bird or $599 standard
Candidate must
Pass the official (ISC)²® CSSLP certification examination
Complete the endorsement process
The Associate of (ISC)² Program applies to those who have passed the exam but need to acquire the necessary minimum experience requirements 33

34. For more information, please contact:
Glenn Johnson, (ISC)² , CSSLP Team Leader Certification Consultant
Vehbi Tasar, (ISC)² Manager of Professional Programs
Visit

35. References
Secure Software Assurance: A guide to the Common Body of Knowledge to Produce, Acquire, and Sustain Secure Software, S. Redwine, Ed., US Department of Homeland Security, 2005.
The Trustworthy Computing Security Development Lifecycle, S. Lipner, et al, Microsoft, March
OWASP:
Microsoft Security Site for Developers:
Books:
The Security Development Lifecycle, M. Howard & S. Lipner Microsoft Press, 2006