Secure Programming Lecture 9: SecureDevelopment
David Aspinall, Informatics @ Edinburgh
24th February 2014
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Recap
We’ve looked in detail at two important vulnerabilityclasses:
É overflows, stack and heapÉ injections, command and SQL
We’ve seen secure development processes from theoutside:
É vulnerability advisories, CVE classificationsÉ a maturity model for secure software development:
BSIMM
It’s time to delve a bit more into secure developmentactivities included in BSIMM.
A Building Security In Process
We’ll look at a:
Secure Software Development Lifecycle (SSDLC)
due to Gary McGraw in his 2006 book SoftwareSecurity: Building Security In.
Work by McGraw and others has been combined in thebest practices called Building Security In we saw inBSIMM. This is promoted by the US-CERT.
To avoid debates over specific development processes,BSI indexes best practice activities. But activities relateto lifecycle stages.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
McGraw’s Three Pillars
In Building Security In, Gary McGraw proposes three“pillars” to use throughout the lifecycle:
É I: Applied Risk ManagementÉ process: identify, rank then track risk
É II: Software Security TouchpointsÉ designing security ground up, not “spraying on”É seven security-related activities
É III: KnowledgeÉ knowledge as applied information about securityÉ e.g., guidelines or rules enforced by a toolÉ or known exploits and attack patterns
Security activities during development
How should secure development practices beincorporated into traditional software development?
0. treat security separately as a new activity (wrong)1. invent a new, security-aware process (another fad)2. run security activities alongside traditional
In business, “touchpoints” are places in a product/saleslifecycle where a business connects to its customers.
McGraw adapts this to suggest “touchpoints” insoftware development where security activities shouldinteract with regular development processes.
Security activities during lifecycleMcGraw identified 7 activities as touchpoints, eachconnecting with software development artefacts. Inlifecycle order these are:
É Abuse cases (in requirements)É Security requirements (in requirements)É Risk analysis (in design)É Risk-based security tests (in test planning)É Code review (in coding)É Risk analysis (in testing)É Penetration testing (in testing and deployment)É Security operations (during deployment)
His process modifies one adopted by Microsoft after thefamous Gates Memo in 2002.
Exercise. For each touchpoint (detailed shortly),identify the development artefact(s) it concerns.
Touchpoints in the software developmentlifecycle
The numbers are a ranking in order of effectiveness.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Code reviewMost effective step: eliminate problems at source.
Evidence since 1970s shows that bugs are orders ofmagnitude cheaper to fix during coding than later inthe lifecycle (industry is still learning this; code QAprocesses aren’t as widely deployed as you mightimagine).
É Manual code reviewÉ can find subtle, unusual problemsÉ an onerous task, especially for large code bases
É Automatic static analysisÉ increasingly sophisticated tools automate scanningÉ very useful but can never understand code perfectlyÉ and may need human configuration, interpretation
Especially effective for simple bugs such as overflows.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Architectural risk analysis
Design flaws are not obvious from starting at code;they need to be identified in the design phase.
Architectural risk analysis considers security duringdesign:
É the security threats that attackers pose to assetsÉ vulnerabilities that allow threats to be realisedÉ the impact and probability for a vulnerability exploitÉ hence the risk, as risk = probability × impactÉ countermeasures that may be put into place
Example: poor protection of secret keys; risk is deemedhigh that attacker can read key stored on the filesystemand then steal encrypted document. A countermeasureis to keep encryption keys on dedicated USB tokens.
Risk analysis in general
É Several approaches:É financial loss oriented (cost versus damage)É mathematical (or pseudo-mathematical) risk ratingsÉ qualitative methods using previous knowledge
É If possible, should use specialist non-developersÉ requires understanding business impactÉ perhaps legal and regulatory frameworkÉ devs often strongly opinionated, fixed assumptions
Common steps in risk analysis
1. Study system (specs, design docs, code if ready)2. Identify threats and attacker types/routes3. List possible vulnerabilities in the software4. Understand planned security controls (& risks. . . )5. Map attack scenarios (routes to exploit)6. Perform impact analysis7. Using likelihood estimates, rank risks8. Recommend countermeasures in priority/cost order
Methodologies for risk analysis propose detailedspecifics.
In steps 2 and 3, may use checklists of threat types andpreviously known vulnerabilities; also general goodnessguidelines.
Security design guidelines
Saltzer and Schroeder (1975)’s classic principles:
1. Economy of mechanism: keep it simple, stupid2. Fail-safe defaults: e.g., no single point of failure3. Complete mediation: check everything, every time4. Open design: assume attackers get the source & spec5. Separation of privilege: use multiple conditions6. Least privilege: no more privilege than needed7. Least common mechanism: beware shared resources8. Psychological acceptability: are security ops usable?
You should review these. We discussed these in more detail in 3rdyear Computer Security.
Microsoft STRIDE approach
STRIDE is mnemonic for categories of threats inMicrosoft’s method:
É Spoofing: attacker pretends to be someone elseÉ Tampering: attacker alters data or settingsÉ Repudiation: user can deny making attackÉ Information disclosure: loss of personal infoÉ Denial of service: preventing proper site operationÉ Elevation of privilege: user gains power of root user
Exercise. List the security property each threat typeattacks
The STRIDE approach
STRIDE uses Data Flow Diagrams to chase data througha system.
É Consider each data flow, manipulation, or storage:É Are there vulnerabilities of type S,T,R,I,D,E?É Are there routes to attack?
É Design mitigations (countermeasures)
STRIDE was designed as a developer-friendlymechanism
É devs may not know end user’s risk toleranceÉ so de-emphasises risk assessment, business impact
See MSDN magazine, Nov 2006.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Penetration testingCurrent dominant methodology (alongside bolt-onprotection measures, outside the lifecycle). Effectivebecause it considers a program in final environment.
É Finds real problemsÉ demonstrable exploits easily motivates repair costsÉ process “feels” good
É Drawback: no accurate sense of coverageÉ ready made pen-testing tools cover only easy bugsÉ system-specific architecture and controls ignored
Beware Dijkstra’s famous remark: Testing shows thepresence, not the absence of bugs. Just running somestandard pen-testing tools is a very minimal test.
Example: by feeding data to form elements, a browserplugin pen testing tool uncovers XSS vulnerabilities.
Bad use of Pen Testing
É Black-box pen testing by consultants is limitedÉ They may know tools but not system being testedÉ Judgements about code can be limited
É Developers only patch problems they’re told aboutÉ Patches may introduce new problemsÉ Patches often only fix symptom, not root causeÉ Patches often go un-applied
Good use of Pen Testing
McGraw advocates using pen testing:
É At the unit level, earlier in development:É automatic fault-injection with fuzzing tools
É Before deployment, as a last checkÉ not a first check for security, after deployment!É risk-based, focus on configuration and environment
É Metrics-driven: tracking problem reductionÉ not imagining zero=perfect securityÉ use exploits as regression tests
É For repairing software, not deploying work-arounds
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Security testing
Security testing complements QA processes whichensure main functional requirements are error free.
É Test security functionalityÉ security provisions tested using standard methodsÉ integrated by considering with main requirements
É Tests based on attack patterns or identifiedabuse casesÉ apply risk analysis to prioritizeÉ consider attack patterns
Traditional testing vs security testing
Focus on:
É Explicit functional requirementsÉ check use cases, operate as expectedÉ customer can add/remove items from cart
É Sometimes explicit non-functional requirementsÉ check usability, performanceÉ user experience (UX) is pleasingÉ updating cart takes at most 5 seconds
Testers check a reasonably clear list of desiredbehaviours.
“The system shall. . . ”
Traditional testing vs security testing
Focus on:
É Rarely explicit non-functional non-requirementsÉ check many undefined, unexpected behaviours are
impossible
Testers check an unclear list of undesirable behavioursare absent.
“The system shall not. . . ”
A strategy for security testing
1. Understand the attack surface by enumerating:É program inputsÉ environment dependencies
2. Use risk analysis outputs to prioritize componentsÉ (usually) highest: code accessed by anonymous,
remote users
3. Work through attack patterns usingfault-injection:É use manual input, fuzzers or proxies
4. Check for security design errorsÉ privacy of network trafficÉ controls on storage of data, ACLsÉ authenticationÉ random number generation
Automating security tests
Just as with functional testing, we can benefit frombuilding up suites of automated security tests.
Idea is a grey box approach:
É Think like an attackerÉ Design test suites to attempt malicious exploitsÉ Knowing system, can violate specs/assumptions
This goes beyond random fuzz testing approaches.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Abuse casesIdea: describe the desired behaviour of the systemunder different kinds of abuse/misuse:
É Work through attack patterns, e.g.É illegal/oversized input
É Examine assumptions for correct operation,e.g.É interface protects access to plain-text data on file
systemÉ cookies returned to server as they were sent
É Consider unexpected events, e.g.É out of memory error, disconnection of server
Detail should be filled out in same specific way as for ause case.
Related idea: anti-requirements.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Security requirements
Security needs should be explicitly considered at therequirements stage.
É Functional security requirements, e.g.É use strong cryptography to protect sensitive stored
dataÉ provide an audit trail for all financial transactions
É Emergent security requirements, e.g.É do not crash on ill-formed inputÉ do not reveal web server configuration on erroneous
requests
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Security operations
Security during operations means managing thesecurity of the deployed software.
Traditionally this has been the domain of informationsecurity professionals.
The idea of this touchpoint is to combine expertise ofinfosecs and devs.
Information security professionals
Expert in:
É Incident handlingÉ Range and mechanisms of vulnerabilitiesÉ Understanding and deploying desirable patchesÉ Configuring firewalls, IDS, virus detectors, etc
But are rarely software experts.
Taking part in the development process can feed backknowledge from attacks, or join in security testing.
Infosec people understand pentesting from the outsideand less from inside. Network security scanners aremore evolved and effective than application scanners.
Coders
Expert in:
É Software designÉ ProgrammingÉ Build systems, overnight testing
But rarely understand security in-the-wild.
Coders focus on the main product, easy to neglect thedeployment environment. E.g., VM host environmentmay be easiest attack vector.
Outline
Overview
Lifecycle security touchpoints
1. Code review and repair
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations
Summary
Summary
This lecture outlined some SSDLC activities.
The descriptions were quite high-level.
Exercise. For each of the touchpoints, find specificdocumented examples of their use in a developmentprocess. (McGraw’s book has some, but there areplenty of other sources).
Exercise. Practice thinking about the touchpoints byconstructing scenarios. Consider the development of aparticular piece of software or a system. Imagine whatsome of the touchpoints might uncover or recommend.
Review questions
É Describe 5 secure development lifecycleactivities and the points in which they would beused in a compressed 4-stage agile developmentmethod (use case, design, code, test).
É What kinds of security problem is code reviewbetter at finding compared with architectural riskanalysis?
É Why is risk analysis difficult to do at the codinglevel?
É What is the main drawback of penetration testing,especially when it is applied as an absolutemeasure of security of a software system?
References and credits
Material in this lecture is adapted from
É Software Security: Building Security In, by GaryMcGraw. Addison-Wesley, 2006.
É The Art of Software Security Testing, by Wysopal,Nelson, Dai Zovi and Dustin. Addison-Wesley, 2007.
É Build Security In, the initiative of US-CERT athttps://buildsecurityin.us-cert.gov/.