View
225
Download
2
Category
Tags:
Preview:
Citation preview
CSCE 201 CSCE 201 Secure Software DevelopmentSecure Software Development
Best PracticesBest Practices
2
ReadingReading
This lecture: G. McGraw, Software [In]security: Software
Security Zombies, 07/2011, http://www.cigital.com/resources/papers/
3
How to address software security? How to address software security?
Do not address at allAd-hoc evaluationAdd security features after the fact Identify security vulnerabilitiesTest security levelIncorporate security throughout of SDLC
4
Checking for Known Checking for Known VulnerabilitiesVulnerabilities
Need toolPossible attacks and attack typesHow the software behaves if something
goes WRONGWhat motivates an attacker?
5
Three Pillars of Software SecurityThree Pillars of Software Security
Risk Management – Business caseSoftware Security Touchpoints – Best
practicesKnowledge – Tools
6
Risk ManagementRisk Management
How much effort to invest in securityConsequences of security breachesAcceptable-level of security Tracking and mitigating risk throughout the
full SDLC
7
KnowledgeKnowledge
Gathering, encapsulating, and sharing security knowledge
Knowledge categories: – Prescriptive knowledge– Diagnostic knowledge– Historical knowledge
Applied along the SDLC
8
TouchpointsTouchpoints
System-wide activity: from design to testing and feedback Touchpoints:
1. Code review2. Architectural risk analysis3. Penetration testing4. Risk-based security testing5. Abuse cases6. Security requirements7. Security operations
9
Application of TouchpointsApplication of Touchpoints
Requirement and Use cases
Architecture and Design
Test Plans Code Tests andTest Results
Feedback fromthe Field
5. Abuse cases
6. Security Requirements
2. Risk Analysis
External Review
4. Risk-Based Security Tests
1. Code Review1. Code Review(Tools)(Tools)
2. Risk Analysis
3. Penetration Testing
7. Security Operations
10
Misuse CasesMisuse Cases Software development: making software do
something– Describe features and functions– Everything goes right
Need: security, performance, reliability– Service level agreement – legal binding
How to model non-normative behavior in use cases?– Think like a bad guy
11
Misuse CasesMisuse Cases
Analyze system design and requirements– Assumptions– Failure of assumptions– Attack patterns
Software that is used also going to be attacked
What can a bad guy do and how to react to malicious use
12
Misuse Case DevelopmentMisuse Case Development
Team work – software developers and security experts
Identifying and documenting threats Creating anti-requirements: how the system can be
abused Creating attack model
– Select attack pattern relevant to the system– Include anyone who can gain access to the system
13
Application of TouchpointsApplication of Touchpoints
Requirement and Use cases
Architecture and Design
Test Plans Code Tests andTest Results
Feedback fromthe Field
5. Abuse cases
6. Security Requirements
2. Risk Analysis
External Review
4. Risk-Based Security Tests
1. Code Review(Tools)
2. Risk Analysis
3. Penetration Testing
7. Security Operations
14
Software TestingSoftware Testing
Application fulfills functional requirementsDynamic, functional tests late in the SDLCContextual information
15
Security TestingSecurity Testing
Test: finding flaws in software can be exploited by attackers
Quality, reliability and security are tightly coupled
Software behavior testing– Need: risk-based approach using system
architecture information and attacker’s model
16
Security TestingSecurity TestingLook for unexpected but intentional misuse of the
systemMust test for all potential misuse types using
– Architectural risk analysis results– Abuse cases
Verify that – All intended security features work (white hat)– Intentional attacks cannot compromise the system
(black hat)
17
Penetration TestingPenetration Testing
Testing for negative – what must not exist in the system
Difficult – how to prove “non-existence” If penetration testing does not find errors than
– Can conclude that under the given circumstances no security faults occurred
– Little assurance that application is immune to attacks
Feel-good exercise
18
Success of Penetration TestingSuccess of Penetration Testing
Depends on skill, knowledge, and experience of the tester
Important! Result interpretationDisadvantages of penetration testing:
– Often used as an excuse to declare victory and go home
– Everyone looks good after negative testing results
19
Behavior in the Presence of Behavior in the Presence of Malicious AttackMalicious Attack
What happens when the software fails?– Safety critical systems
Track risk over timeSecurity relative to
– Information and services protected– Skills and resources of adversaries– Cost of protection
System vulnerabilities
20
Malicious InputMalicious Input
Software: takes inputTrust input?
– Malformed or malicious input may lead to security compromise
– What is the input? Data vs. control
Attacker toolkit
21
Traditional Software Traditional Software DevelopmentDevelopment
No information security considerationHighly distributed among business unitsLack of understanding of technical security
risks
22
Don’t stand so close to me Don’t stand so close to me
Best Practices– Manageable number of simple activities – Should be applied throughout the software
development process Problem:
– Software developers: lack of security domain knowledge limited to functional security
– Information security professionals: lack of understanding software limited to reactive security techniques
23
Vulnerability MonitoringVulnerability Monitoring
Identify security weaknessesMethods:
– Automated tools– Human walk-through– Surveillance – Audit– Background checks
24
Red TeamRed Team
Organized group of people attempting to penetrate the security safeguards of the system.
Assess the security of the system future improvement
Requested or permitted by the owner to perform the assessment
Wide coverage: computer systems, physical resources, programming languages, operational practices, etc.
25
Next ClassNext Class
Midterm exam
Recommended