Development*Process*for*Secure*
So2ware
Development Processes
(Lecture outline)
• Emphasis on „building secure software” as opposed to „building security software”
• Major methodologies
– Microsoft's Security Development Lifecycle – OWASP CLASP
– Cigital's Security touchpoints
Microsoft Security Development Cycle
• http://www.microsoft.com/security/sdl/default.aspx
414*
Development Processes
(Lecture outline)
• Emphasis on „building secure software” as opposed to
„building security software”
• Major methodologies
– Microsoft's Security Development Lifecycle – OWASP CLASP
– Cigital's Security touchpoints
Open Web Application Security Project
OWASP
https://www.owasp.org/
• Collect resources
for Web applications
– Top ten security flaws
– Various security testing tools – Various security
control means
• e.g., code review guide
• CLASP – Comprehensive Lightweight Application
Security Process 416*
– Injection
– Cross-site Scripting (XSS) – Broken authentication and session
management
– Insecure direct object references – Cross-site request forgery (CSRF) – Security misconfiguration
– Insecure cryptographic storage – Failure to restrict URL access – Insufficient transport layer
protection
– Unvalidated redirects and forwards
Open Web Application Security Project
OWASP
https://www.owasp.org/
• Collect resources
for Web applications
– Top ten security flaws
– Various security testing tools – Various security
control means
• e.g., code review guide
• CLASP – Comprehensive Lightweight Application
– Injection
– Cross-site Scripting (XSS) – Broken authentication and session
management
– Insecure direct object references – Cross-site request forgery (CSRF) – Security misconfiguration
– Insecure cryptographic storage – Failure to restrict URL access – Insufficient transport layer
protection
– Unvalidated redirects and forwards
https://www.owasp.org/index.php/ OWASP_Appsec_Tutorial_Series
CLASP
https://www.owasp.org/index.php/Category:OWASP_CLASP_Project
• Goal:
– move security concerns into the early stages of the software development lifecycle, whenever possible
• Set of process pieces that can be integrated into
any software development process
– Introduction to the Concepts behind CLASP to get started – Seven key Best Practices
– High-level Security Services (authorisation, authentication, …)
– Core Security Principles
– Roles
– Activities
– Process engineering and roadmaps
– Checklisted Coding Guidelines
– Vulnerabilities that occur in source code
– Searchable Vulnerability Checklist
418*
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics • Publish operational security
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics • Publish operational securityguidelines
• People should consider security to be an
important project goal • Train all team members • Make people aware of
security setting
• Institute accountability for security issues
• Appoint a project security officer
• Institute rewards for handling of security issues
420*
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics
• Publish operational security
guidelines
• Security analysis of
requirements and design
– Threat modelling
• Source-level security review • Security tests
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics• Publish operational security
guidelines
• Treat security requirements same way as functional requirements
• Define security policy • Identify attack surface • Identify resources and trust
boundaries
• Identify misuse cases • Specify operational
environment
422*
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics
• Publish operational security
guidelines
• Annotate classes with security properties
• Apply principles of secure design
• Manage resources • Manage contracts and
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures• Define and monitor metrics
• Publish operational security
guidelines
• Address reported security issues
• Manage security issue disclosure process
424*
CLASP Best Practices
• Institute awareness programs
• Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures
• Define and monitor metrics • Publish operational security
guidelines
• Select metrics • Collect data • Evaluate results
CLASP Best Practices
• Institute awareness programs • Perform application assessments • Capture security requirements • Implement secure development practices • Build vulnerability remediation procedures • Define and monitor metrics• Publish operational
security guidelines
• Build operational security guide
• Specify database security configuration
426*
Development Processes
(Lecture outline)
• Emphasis on „building secure software” as opposed to
„building security software”
• Major methodologies
– Microsoft's Security Development Lifecycle – OWASP CLASP
– Cigital's Security touchpoints
Seven Security Touchpoints
G. McGraw, “Software Security: Building Security In”
428*
“All software projects produce at least one artifact: source code”
Seven Security Touchpoints
G. McGraw, “Software Security: Building Security In”
“All software projects produce at least one artifact: source code”
1. Code review (tools) 2. Risk analysis
3. Penetration test
4. Risk-based security test
5. Abuse analysis
6. Security requirements 7. Security attacks
Code review (tools)
• Aim: catching implementation bugs early • Tool helps to achieve good code coverage • Aim for good, not perfect430*
Risk analysis
• Create description of
architecture
– Start with one page – Forest-level view
• Attack resistance
– Use checklists of known attacks – Example: Microsoft STRIDE
• Spoofing, Tampering,
Repudiation, Info disclosure, Denial of service, Elevation of privilege
• Ambiguity analysis
– Discover new risks
– Find unclear parts in how the system works
– Trust, data sensitivity, threat models
• Weakness analysis
– Impact of external software dependencies
– Platform (hardware, OS) – Frameworks
– Called services
Penetration test
• Use the source– Otherwise people send time on
reverse-engineering system
• Apply business
priorities
– Logic flaw vs. XSS flaw – XSS is important if it contributes towards compromising business logic • Use in-house QA department
– They already know the system
– Use tools and training to add security testing skills
• Test more than once • Incorporate the findings
back into development 432*
Attack on a system with the intention of finding security weaknesses, potentially gaining access to it, its functionality and data
Risk-based security test
• Test based on priorities
– Architectural risks
– Risks discovered during code review
• Test malicious input
Abuse analysis and
Security requirement
• Security is not a set of features
• How system should react to illegitimate use • Like use cases, but with malicious users
434*
1.
Input validation and
Representation
2.
API Abuse
3.
Security Features
4.
Time and State
5
. Error Handling
6.
Code Quality
7.
Encapsulation
*
Environment
External analysis
• Unfortunately
– Software architects, developers, and testers are largely unaware of the software security problems
• Good news
– They acknowledge that security problems exists!
• Bad news
– Barely begun to apply the security solutions
436*
Exercise
• ISSRM domain model• Security modelling
• Security risk measurement • Secure Tropos
• Goal modelling • i */ Tropos
• Mal-activity diagrams • Secure UML
• Security access management • Phishing
• Trojan Horse
• Security monitoring
• ISSRM process • Trust management
• Security trade-off analysis • Security error taxonomy • Security requirements
elicitation
• Security requirements taxonomy
• Misuse cases
• Role-based access control • UMLsec
• Social engineering • Cryptography
Exercise
Assign terms/techniques according to
different stages of Microsoft SDC
• ISSRM domain model • Security modelling • Security risk measurement • Secure Tropos
• Goal modelling • i */ Tropos
• Mal-activity diagrams • Secure UML
• Security access management • Phishing
• Trojan Horse • Security monitoring
• ISSRM process • Trust management • Security trade-off analysis • Security error taxonomy • Security requirements elicitation • Security requirements taxonomy • Misuse cases
• Role-based access control • UMLsec
• Social engineering • Cryptography
• CIA 438*
Exercise
Align terms/techniques to different
CLASP activities
Institute awareness programs Perform application assessments Capture security requirements Implement secure development practices Build vulnerability remediation proceduresDefine and monitor metrics
Publish operational security guidelines
• ISSRM domain model • Security modelling • Security risk measurement • Secure Tropos
• Goal modelling • i */ Tropos
• Mal-activity diagrams • Secure UML
• Security access management • Phishing
• ISSRM process • Trust management • Security trade-off analysis • Security error taxonomy • Security requirements elicitation • Security requirements taxonomy • Misuse cases
• Role-based access control • UMLsec
Exercise
What techniques could be used at
different touchpoints?
440*
• ISSRM domain model • Security modelling • Security risk measurement • Secure Tropos
• Goal modelling • i */ Tropos
• Mal-activity diagrams • Secure UML
• Security access management • Phishing
• Trojan Horse • Security monitoring
• ISSRM process • Trust management • Security trade-off analysis • Security error taxonomy • Security requirements elicitation • Security requirements taxonomy • Misuse cases
• Role-based access control • UMLsec • Social engineering • Cryptography • CIA
Development Processes
(Lecture outline)• Emphasis on „building secure software” as opposed to
„building security software”
• Major methodologies
– Microsoft's Security Development Lifecycle – OWASP CLASP
– Cigital's Security touchpoints
Building Security in Maturity Model
• Empirical approach to secure software design
• Gathered data from
42
large-scale software
security initiatives
– Tech companies (e.g., Adobe, Google, Microsoft,…) – Financial companies (e.g., DTCC, Wells Fargo)
• Added only activities seen in the real world
– Actual practices, not best practices
442*
Software Security Framework
• 12 practices in 4 domains
• Each practice consists of activities
• 110 activities in total
• Each activity at least in one company
• No company that does it all
Software Security Framework
444*
Four Domains
• Governance
– Organize, manage, and measure a software security initiative
– Staff development
• Intelligence
– Collections of corporate knowledge used in carrying out software security activities throughout the organization
– Collections include both proactive security guidance and
organizational threat modeling
• SSDL Touchpoints
– Analysis and assurance of particular software development artifacts and processes
– All software security methodologies include these practices
• Deployment
– Traditional network security and software maintenance organizations – Software configuration, maintenance,
and other environment issues have direct impact on software security
Software Security Framework
446*
$ $ EXAMPLE$
Goal: transparency of expectations and
accountability for results
• Level 1: Attain a common understanding of direction and strategy
– Publish process, evolve as necessary – Create evangelism role/internal marketing – Educate executives
– Identify gate locations, gather necessary artefacts – Require security sign off
• Level 2: Align behaviour with strategy and verify behaviour
– …
• Level 3: Practice risk-based portfolio management
– …
Development Processes
• Emphasis on „building secure software” as opposed to
„building security software”
• Major methodologies
– Microsoft's Security Development Lifecycle – OWASP CLASP
– Cigital's Security touchpoints
