csce201 - software - sec Basic Secure

1. CSCE 201
Secure Software Development
Best Practices

2. 2
Reading
 This lecture:
 G. McGraw, Software [In]security: Software
Security Zombies, 07/2011,
http://www.cigital.com/resources/papers/

3. 3
How to address software
security?
 Do not address at all
 Ad-hoc evaluation
 Add security features after the fact
 Identify security vulnerabilities
 Test security level
 Incorporate security throughout of SDLC

4. 4
Checking for Known
Vulnerabilities
 Need tool
 Possible attacks and attack types
 How the software behaves if something
goes WRONG
 What motivates an attacker?

5. 5
Three Pillars of Software Security
 Risk Management – Business case
 Software Security Touchpoints – Best
practices
 Knowledge – Tools

6. 6
Risk Management
 How much effort to invest in security
 Consequences of security breaches
 Acceptable-level of security
 Tracking and mitigating risk throughout the
full SDLC

7. 7
Knowledge
 Gathering, encapsulating, and sharing security
knowledge
 Knowledge categories:
– Prescriptive knowledge
– Diagnostic knowledge
– Historical knowledge
 Applied along the SDLC

8. 8
Touchpoints
 System-wide activity: from design to testing and feedback
 Touchpoints:
1. Code review
2. Architectural risk analysis
3. Penetration testing
4. Risk-based security testing
5. Abuse cases
6. Security requirements
7. Security operations

9. 9
Application of Touchpoints
Requirement and
Use cases
Architecture
and Design
Test Plans Code
Tests and
Test Results
Feedback from
the 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

10. 10
Misuse 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. 11
Misuse 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. 12
Misuse 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. 13
Application of Touchpoints
Requirement and
Use cases
Architecture
and Design
Test Plans Code
Tests and
Test Results
Feedback from
the 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. 14
Software Testing
 Application fulfills functional requirements
 Dynamic, functional tests late in the SDLC
 Contextual information

15. 15
Security 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. 16
Security Testing
 Look for unexpected but intentional misuse of the
system
 Must 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. 17
Penetration 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. 18
Success of Penetration Testing
 Depends on skill, knowledge, and experience of
the tester
 Important! Result interpretation
 Disadvantages of penetration testing:
– Often used as an excuse to declare victory and go
home
– Everyone looks good after negative testing results

19. 19
Behavior in the Presence of
Malicious Attack
 What happens when the software fails?
– Safety critical systems
 Track risk over time
 Security relative to
– Information and services protected
– Skills and resources of adversaries
– Cost of protection
 System vulnerabilities

20. 20
Malicious Input
 Software: takes input
 Trust input?
– Malformed or malicious input may lead to
security compromise
– What is the input?
 Data vs. control
 Attacker toolkit

21. 21
Traditional Software
Development
 No information security consideration
 Highly distributed among business units
 Lack of understanding of technical security
risks

22. 22
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. 23
Vulnerability Monitoring
 Identify security weaknesses
 Methods:
– Automated tools
– Human walk-through
– Surveillance
– Audit
– Background checks

24. 24
Red 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. 25
Next Class
 Midterm exam