126 Core Software Security
for a successful SDL cycle that all requirements are identified and cap-
tured to the best extent possible.
Success Factor 2: Effective Threat Modeling
Though it is a complex and challenging task, on threat modeling rests the
entire risk mitigation plan. Any gaps in a threat model will result in lack
of effective security controls in the software and/or deployment.
Success Factor 3: Effective Architectural Threat Analysis
Architectural threat analysis enables identification of threats and ranks
them in order of priority. It is essential that all threat vectors resulting in
the risk are identified and prioritized.
Success Factor 4: Effective Risk Mitigation Strategy
The culmination of threat modeling and threat analysis is risk acceptance,
tolerance, and a risk mitigation plan. It is imperative that business appe-
tite for risk acceptance and tolerance be thoroughly vetted, including
through legal and finance.
Success Factor 5: Accuracy of DFDs
DFDs are used during threat modeling to identify various components/
elements of interest. DFDs should be as detailed as possible. Any assump-
tions should be reviewed carefully. Specifically, trust boundaries (client/
server, private/public infrastructure, tiered architecture), etc., should be
properly documented and reviewed.
4.6.2 Deliverables
Table 4.2 lists deliverables for this phase of the SDL.
Business Requirements
A formal business requirement is an artifact that lists software require-
ments and business risks mapped to the three pillars of information secu-
rity: confidentiality, integrity, and availability.
Architecture (A2): SDL Activities and Best Practices 127
Threat Modeling Artifacts
A critical component of this SDL phase, there are a few artifacts that
come from this step. Key artifacts include data flow diagrams, techni-
cal threat modeling reports, high-level executive threat modeling reports,
threat lists, and recommendations for threat analysis.
Architecture Threat Analysis
The key artifact from this step of the SDL is an artifact that outlines risks
of threat materializing. Another one that should be required from this
step is threat ranking/priority.
Risk Mitigation Plan
The risk mitigation plan outlines risks (and threats) to be mitigated,
accepted, or tolerated. For each of these categories, it also outlines steps
on mitigation risks. Finally, this report should be presented to business for
sign-off before actual work on the project begins.
Policy Compliance Analysis
This artifact is a report on compliance with different security and nonse-
curity policies within the company—for example, how does software to
be developed comply with information security policy, data governance
policy, data retention and cryptography policy, and so on.
4.6.3 Metrics
The following metrics should be collected and recorded for this second
phase of the SDL cycle:
Table 4.2 Deliverables for Phase A2
Deliverable Goal
Business requirements Software requirements, including CIA
Threat modeling artifacts Data flow diagrams, elements, threat listing
Architecture threat analysis Prioritization of threats and risks based on
threat analysis
Risk mitigation plan Plan to mitigate, accept, or tolerate risk
Policy compliance analysis Analysis of adherence to company policies
128 Core Software Security
• List of business threats, technical threats (mapped to business
threats), and threat actors
• Number of security objectives unmet after this phase
• Percent compliance with company policies (existing)
• Number of entry points for software (using DFDs)
• Percent of risk (and threats) accepted, mitigated, and tolerated
• Percent of initial software requirements redefined
• Number of planned software architectural changes (major and
minor) in a product
• Number of software architectural changes needed based on security
requirements
4.7 Chapter Summary
The primary goal of the Architecture (A2) phase of our DSL model is
to identify the overall requirements and structure for the software from
a security perspective. The key elements of this phase are threat model-
ing, documentation of elements of the software attack surface from an
architectural perspective; definition of security architecture and design
guidelines; continued security, SDL, and privacy policy and requirements
compliance reviews; and software product security release requirements.
These best practices result in the definition of the overall structure
of the software from a security perspective. They identify those compo-
nents whose correct functioning is essential to security. They also identify
the appropriate security design techniques applicable for the soft product
architecture, including the application of least privilege, and minimize the
attack surface of the software product and any supporting infrastructure.
Although a higher layer may depend on the services of lower layers, the
lower layers are forbidden from depending on higher layers. Although the
security architecture identifies an overall perspective on security design,
the specifics of individual elements of the architecture will be detailed in
individual design specifications.
The identification and measurement of the individual elements of
the attack surface provides the development and software security team
with an ongoing metric for default security and enables them to detect
instances where the software has been made susceptible to attack. During
this phase, all exceptions to reducing the attack surface must be reviewed,
because the goal is to maximize security as a default for a software product
Architecture (A2): SDL Activities and Best Practices 129
that is being developed. Threat modeling uses a structured approach at a
component-by-component level, identifying the assets that the software
must manage and the interfaces by which those assets can be accessed.
The likelihood of harm being done to any of the assets identified dur-
ing threat modeling is estimated as a measure of risk. Countermeasures
or compensating controls to mitigate the risk are also identified. Where
appropriate and feasible, tools should be used that can capture the threat
models in machine-readable form for storage and updating. Specific pre-
ship software security criteria are also identified at this stage of the SDL.
Toward the end of the chapter we discussed key success factors and
their importance, deliverables from this phase, and metrics that should be
collected from this phase.
References
1. Kohnfelder, L., and Garg, P. (1999), “The threats to our products.” Microsoft
Interface, April 1, 1999. Retrieved from http://blogs.msdn.com/sdl/attachment/
9887486.Ashx.
2. cisodesk.com (2012), “SiteXposure: Threat Modeling Process—Overview.”
Retrieved from http://www.cisodesk.com/web-application-security/threat-
modeling-overview.
3. Hernan, S., et al. (2006), “Threat Modeling: Uncover Security Design Flaws
Using the STRIDE Approach.” MSDN Magazine. Retrieved from http://msdn.
microsoft.com/en-us/magazine/cc163519.aspx#S3.
4. cisodesk.com (2012), “SiteXposure: Threat Modeling—Practice.” Retrieved from
http://www.cisodesk.com/web-application-security/threat-modeling-in-practice.
5. Hernan, S., et al. (2006), “Threat Modeling: Uncover Security Design Flaws
Using the STRIDE Approach.” MSDN Magazine. Retrieved from http://msdn.
microsoft.com/en-us/magazine/cc163519.aspx#S3.
6. http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx.
7. OWASP (2012), Application Threat Modeling. Retrieved from https://www.owasp.
org/index.php/Application_Threat_Modeling#Data_Flow_Diagrams.
8. Meier, J., et al. (June 2003), Microsoft Corporation MSDN Library Doc: Improving
Web Application Security: Threats and Countermeasures. Retrieved from http://
msdn.microsoft.com/en-us/library/ff648644.aspx.
9. OWASP (2012), Threat Risk Modeling. Retrieved from https://www.owasp.org/
index.php/Threat_Risk_Modeling.
10. Ibid.
11. Meier, J., et al. (June 2003), Microsoft Corporation MSDN Library Doc: Improving
Web Application Security: Threats and Countermeasures. Retrieved from http://
msdn.microsoft.com/en-us/library/ff648644.aspx.
12. Microsoft MSDN (2012), Cheat Sheet: Web Application Security Frame—Web
130 Core Software Security
Application Security Frame Categories. Retrieved from http://msdn.microsoft.com/
en-us/library/ff649461.aspx.
13. OWASP (2012), Application Threat Modeling. https://www.owasp.org/index.php/
Application_Threat_Modeling.
14. Saitta, P., Larcom, B., and Eddington, M. (2005), Trike v.1 Methodology Document
[Draft]. Retrieved from http://octotrike.org/papers/Trike_v1_Methodology_
Document-draft.pdf.
15. OWASP (2012), Threat Risk Modeling. Retrieved from https://www.owasp.org/
index.php/Threat_Risk_Modeling.
16. Saitta, P., Larcom, B., and Eddington, M. (2005), Trike v.1 Methodology Document
[Draft]. Retrieved from http://octotrike.org/papers/Trike_v1_Methodology_
Document-draft.pdf.
17. U.S. Department of Homeland Security—US CERT (2009), Requirements and
Analysis for Secure Software—Software Assurance Pocket Guide Series: Development,
Volume IV Version 1.0, October 5, 2009. Retrieved from https://buildsecurityin.
us-cert.gov/swa/downloads/RequirementsMWV1001AM091111.pdf.
18. MyAppSecurity (2012), Comparison of Threat Modeling Methodologies: P.A.S.T.A
(Process for Attack Simulation and Threat Analysis). Retrieved from http://www.
myappsecurity.com/threat-modeling/comparison-threat-modeling-methodologies.
19. Morana, M., and Ucedavelez, T. (2011), “OWASP Threat Modeling of Banking
Malware-Based Attacks Presentation,” AppSec EU, June 10, 2011, Trinity College,
Dublin, Ireland. Retrieved from https://www.owasp.org/images/5/5f/Marco_
Morana_and_Tony_UV_-_Threat_Modeling_of_Banking_Malware.pdf.
20. Morana, M. (2011), “Writing Secure Software Blog: Attack Simulation and
Threat Analysis of Banking Malware-Based Attacks,” June 10, 2011. Retrieved
from http://securesoftware.blogspot.com/2011/06/attack-simulation-and-threat-
analysis.html.
21. MyApp Security (2012), ThreatModeler. Retrieved from http://www.myappsecurity.
com.
22. FiRST (2012), FiRST Homepage. Retrieved from http://www.first.org.
23. FiRST (2012), “CVSS Frequently Asked Questions.” Retrieved from http://www.
first.org/cvss/faq.
24. Software Engineering Institute–Carnegie Mellon (2012), OCTAVE. Retrieved
from http://www.cert.org/octave.
25. OWASP (2012), Threat Risk Modeling. Retrieved from https://www.owasp.org/
index.php/Threat_Risk_Modeling.
26. STANDARDS Australia–New Zealand (2012), AS/NZS ISO 31000:2009 Risk
Management-Principles and Guidelines. Retrieved from http://sherq.org/31000.pdf.
27. ISO (2012), ISO 31000:2009—Risk Management—Principles and Guidelines.
Retrieved from http://www.iso.org/iso/catalogue_detail?csnumber=43170.
28. Cisodesk (2012), Threat Modeling—Practice Guide. Retrieved from http://www.
cisodesk.com/web-application-security/threat-modeling-in-practice.
29. OWASP (2012), Application Threat Modeling: STRIDE Threat & Mitigation
Techniques List. Retrieved from https://www.owasp.org/index.php/Application_
Threat_Modeling.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.