Fundamentals of Secure Development
This course introduces you to the business and regulatory imperatives for secure software development. It presents models, standards, and guidelines that can help you understand security issues and improve the security posture of your applications. And, it describes how to integrate secure development practices into the software development lifecycle.
After completing this course, you will be able to:
Identify major factors in the business, regulatory, and threat landscapes that drive the demand for software security.
Identify important security models, standards, and guidelines that provide a strategic roadmap for application security.
Identify secure development practices and principles that correspond to each phase of the software development lifecycle.
What is Software Security?
Software security focuses on protecting information and resources made accessible by applications running on computer systems.
Software security is often confused with network security. Network security focuses on the protection of an organization’s IT infrastructure—the servers and related equipment that control the flow of data between networked systems.
Network security controls are typically insufficient to mitigate software security risks.
Software security attacks often occur at higher layers of operation, not visible to network security controls.
The Security Imperative
Key reasons why organizations must develop and deploy secure software include:
- High business costs of security breaches
- Compliance and legal implications of security breaches
- Customer expectations of security
- An increasing threat landscape
Compliance and Legal Implications
Federal and state regulations mandate software security and require protection of sensitive customer data.
Even if an organization is not required by local regulations to develop secure software, they might still need to do so to conduct business in other states.
It is difficult, if not impossible, to ignore software security without incurring significant fines or loss of business.
Customers Expect Secure Solutions
- Regulatory and legislative measures and the media have increased business awareness of the need for secure software and services.
- Failure to develop and deliver secure software and services could damage your organization’s reputation, and drive business to your competitors.
An Increasing Threat Landscape
In the past, hackers were motivated to attack systems and software to gain notoriety. Today, the number of attacks is increasing, and attackers are motivated by financial gains, political agendas, and corporate and international espionage.
Specialized hacking techniques are publicly documented and well understood by many. In addition, automated attack tools are freely available and accessible.
This translates to a higher probability of being hacked, as well as higher expected costs for recovering from cyber attacks.
Overview of Secure Development Models, Standards, and Guidelines
This module introduces you to the following secure development models, standards, and guidelines that provide a fast track to improving application security:
- Open Web Application Security Project (OWASP) Top 10
- Microsoft Security Development Lifecycle (SDL)
- CWE/SANS Top 25 Most Dangerous Software Errors
- Payment Application Data Security Standard (PA-DSS)
- Cloud Security Alliance (CSA) Notorious Nine Report
- Cloud Security Alliance (CSA) Top 10 Big Data Security and Privacy Challenges
- OpenSAMM - Software Assurance Maturity Model (SAMM)
- Building Security In Maturity Model (BSIMM)
- Comprehensive Lightweight Application Security Process (CLASP)
- The Common Criteria for Information Technology Security Evaluation (CC)
Important points about secure development include the following:
- Hacker methods and attacks are constantly evolving, as are the security techniques to address them.
- These security models, standards, and guidelines greatly improve your application security posture, but they do not make your application "hacker proof".
Security in the Software Development Lifecycle
Secure development models are similarly divided into phases that overlay your existing software development model. Each phase describes the tasks that must be executed in each software development phase to minimize your application’s exposure risk.
Secure development models are precise in their requirements. The outputs from each phase serve as input for other phases in the model.
In comparison, standards and guidelines are less structured, providing an overview of quality baselines to achieve, vulnerabilities to be aware of, and coding patterns to follow or avoid.
Open Web Application Security Project (OWASP) Top 10
The Open Web Application Security Project, or OWASP, is an open-source, non-profit organization that provides guidance on secure Web software development, testing frameworks, and tools.
Perhaps the most well-known of their offerings is the OWASP Top 10 list, which describes the most common Web application attacks and vulnerabilities, along with example code vulnerabilities, example attacks, and guidance on mitigating the risk. OWASP Top 10 is updated every few years to help you focus on vulnerabilities that pose the most current risk.
As a developer, you benefit greatly by ensuring that your Web application is resilient to the current OWASP Top 10 vulnerabilities. However, as with any security model, standard, or guideline, following OWASP Top 10 does not necessarily eliminate all possible risks.
The Microsoft Security Development Lifecycle (SDL)
Microsoft developed the Security Development Lifecycle (SDL) to improve and sustain the overall security code quality across all of its products, services, and line-of-business applications. The SDL is a freely available security development model designed to overlay onto existing software development processes. At its core, it categorizes the secure software development process into the following phases: Training, Requirements, Design, Implementation, Verification, Release, and Response.
The Microsoft SDL yields security benefits to any software development team developing in any language on any platform. In each SDL phase, development teams must perform risk assessment and mitigation activities. For example, in the training phase, the SDL requires that each software development team member in a technical role attend at least one security training class each year. In the Implementation phase, it requires that developers use static code analysis tools, which will be discussed later in this course. The SDL requires participation of the entire software development staff, including program managers, developers, and test teams. This contrasts with other models, standards, and guidelines, which tend to focus strictly on the developer aspects of developing secure software.
Microsoft also publishes a set of tools to help software development teams implement and execute the SDL process more efficiently. Example tools include a threat-modeling tool that helps teams identify threats early in the Design phase, and a fault-injection tool to aid with security testing efforts in the Verification phase. Microsoft has also published the Simplified SDL, a lightweight framework version of the SDL available as a spreadsheet, to help organizations realize the greatest benefits of the SDL with minimal effort.
CWE/SANS Top 25 Most Dangerous Software Errors
The MITRE Common Weakness Enumeration (CWE) group and SANS Institute published a report on the top 25 most dangerous software errors. The list is intended to help developers understand, recognize, and prevent common security coding errors that could lead to serious vulnerabilities in their applications. Although the last report was published in 2011, nearly all of the weaknesses cited are still relevant today.
Each of the 25 errors is accompanied by a wealth of information such as remediation cost, attack frequency, consequences, and mitigation techniques.
Payment Application Data Security Standard (PA-DSS)
In addition to the security and privacy requirements specified in the Payment Card Industry Data Security Standard (PCI DSS), the Payment Card Industry Security Standards Council also created a Payment Application Data Security Standard (PA-DSS) for software vendors who develop payment applications.
The PA DSS has fourteen requirements, which are listed on the next screen.
Payment Application Data Security Standard (PA-DSS) (Contd.)
The fourteen PA-DSS Requirements and Security Assessment Procedures are:
1. Do not retain full track data card verification code or PIN block data.
2. Protect stored cardholder data.
3. Provide secure authentication features.
4. Log payment application activity.
5. Develop secure payment applications.
6. Protect wireless transmissions.
7. Test payment applications to address vulnerabilities and maintain payment application updates.
8. Facilitate secure network implementation.
9. Do not allow cardholder data to be stored on a server connected to the Internet.
10. Facilitate secure remote access to payment application.
11. Encrypt sensitive traffic over public networks.
12. Encrypt all non-console administrative access.
13. Maintain a PA-DSS implementation guide for customers, resellers, and integrators.
14. Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel,
customers, resellers, and integrators.
Cloud Security Alliance (CSA) Notorious Nine Report
The Cloud Security Alliance publishes the Notorious Nine, which is an up-to-date report on the top nine threats in cloud computing based on expert consensus and survey. Organizations can use this guide to make better decisions about the risks related to cloud technology adoption.
For each threat, this report describes threat implications, controls to reduce risk, and external links to additional resources.
Many, but not all, of the Notorious Nine have direct implications for application security, and development teams writing applications for cloud deployment can benefit greatly by reading this report for the latest cloud computing threats.
In 2012, the CSA published the Top 10 Big Data Security and Privacy Challenges report. It covers the following issues important to application developers:
1. Secure computations in distributed programming frameworks
2. Security best practices for non-relational data stores
3. Secure data storage and transactions logs
4. Endpoint input validation/filtering
5. Real-time security monitoring
6. Scalable and composable privacy-preserving data mining and analytics
7. Cryptographically enforced data-centric security
8. Granular access control
9. Granular audits
10. Data provenance
OpenSAMM
The Software Assurance Maturity Model (SAMM) is an open software security framework known as OpenSAMM. It helps organizations accomplish the following:
- Evaluate existing security software practices.
- Build a software security program.
- Demonstrate improvements to a security assurance program.
- Define and measure security-related activities.
Building Security In Maturity Model (BSIMM)
The Building Security In Maturity Model (BSIMM) is a study of real-world software security initiatives from companies such as Adobe, Microsoft, PayPal, and many others. It does not represent a security development model, but instead provides an aggregate of the experiences and lessons learned by the participating organizations.
BSIMM describes over 100 activities that your organization can implement. Those activities are organized in a free software security framework (SSF) that defines 12 practices organized into four domains: governance, intelligence, Secure Software Development Lifecycle (SSDL), and deployment.
The Governance domain helps organizations manage and measure software activities related to internal strategy and metrics, compliance and policy, and training.
The Intelligence domain provides proactive security guidance and describes organizational threat assessment and modeling.
The SSDL domain discusses essential software security practices to integrate into your own software development process.
The Deployment domain provides practices that are more aligned with traditional network security and software maintenance, such as penetration testing, configuration, and vulnerability management.
Comprehensive Lightweight Application Security Process (CLASP)
The Comprehensive Lightweight Application Security Process (CLASP) is an OWASP project. It defines a process to handle security issues and concerns early in the software development lifecycle. CLASP provides the following key resources:
- Security best practices
- Fundamental security goals and principles
- Activities to improve your secure software development process
- Secure software engineering roadmaps
- A downloadable book and searchable vulnerability checklist for use by development teams
The Common Criteria (CC) for Information Technology Security Evaluation is a certification standard for computer security products (ISO/IEC 15408). It defines a repeatable framework for specification, implementation, and evaluation of computer security products.
CC consists of the following three parts:
– Introduction and general model
– Security functional requirements (SFRs)/components
– Security assurance requirements (SARs)/components
CC helps validate certain security attributes of a computer security product, but does not provide a guarantee of actual security.
