This document discusses best practices for secure software development. It covers topics like using abuse cases and misuse cases to model potential security threats during requirements and design. It emphasizes doing security testing early in the development lifecycle using risk analysis and architecture information. Other topics include penetration testing, quality assurance, and monitoring systems for vulnerabilities once deployed. The overall message is that security needs to be built into software from the start through practices like threat modeling rather than as an afterthought.

1. CSCE 522
Secure Software Development
Best Practices

2. CSCE 522 - Farkas 2
Reading
 This lecture:
 Pfleeger Chapter 3.1
 G. McGraw, Software [In]security: Software
Security Zombies, 07/2011,
http://www.informit.com/articles/article.aspx?p=173
9924

3. CSCE 522 - Farkas 3
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

4. CSCE 522 - Farkas 4
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

5. CSCE 522 - Farkas 5
Software Vendor Accountability
 Proper implementation of security features
 Looking for known security flaws
 Passing third party validation
 Source code analysis

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

7. CSCE 522 - Farkas 7
Misuse Cases
 Extends use case diagrams
 Represent actions the system should prevent
 Represent together
– Desired functionalities
– Undesired actions
 Security: emergent property  must be
built in from the ground up
 Making explicit trade offs

8. CSCE 522 - Farkas 8
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

9. CSCE 522 - Farkas 9
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

10. CSCE 522 - Farkas 10
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

11. CSCE 522 - Farkas 11
Software Testing
 Application fulfills functional requirements
 Dynamic, functional tests late in the SDLC
 Contextual information

12. CSCE 522 - Farkas 12
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)

13. CSCE 522 - Farkas 13
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

14. CSCE 522 - Farkas 14
Penetration Testing Today
 Often performed
 Applied to finished products
 Outside  in approach
 Late SDLC activity
 Limitation: too little, too late

15. CSCE 522 - Farkas 15
Late-Lifecycle Testing
 Limitations:
– Design and coding errors are too late to discover
– Higher cost than earlier designs-level detection
– Options to remedy discovered flaws are constrained
by both time and budget
 Advantages: evaluate the system in its final
operating environment

16. CSCE 522 - Farkas 16
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

17. CSCE 522 - Farkas 17
Quality Assurance
 External quality: correctness, reliability,
usability, integrity
 Interior (engineering) quality: efficiency,
testability, documentation, structure
 Future (adaptability) quality: flexibility,
reusability, maintainability

18. CSCE 522 - Farkas 18
Correctness Testing
 Black box:
– Test data are derived from the specified
functional requirements without regard to the
final program structure
– Data-driven, input/output driven, or
requirements-based
– Functional testing
– No implementation details of the code are
considered

19. CSCE 522 - Farkas 19
Correctness Testing
 White box:
– Software under test are visible to the tester
– Testing plans: based on the details of the
software implementation
– Test cases: derived from the program structure
– glass-box testing, logic-driven testing, or
design-based testing

20. CSCE 522 - Farkas 20
Performance Testing
 Goal: bottleneck identification, performance
comparison and evaluation, etc.
 Explicit or implicit requirements
 "Performance bugs" – design problems
 Test: usage, throughput, stimulus-response
time, queue lengths, etc.
 Resources to be tested: network bandwidth
requirements, CPU cycles, disk space, disk
access operations, memory usage, etc.

21. CSCE 522 - Farkas 21
Reliability Testing
 Probability of failure-free operation of a
system
 Dependable software: it does not fail in
unexpected or catastrophic ways
 Difficult to test
 (see later lecture on software reliability)

22. CSCE 522 - Farkas 22
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

23. CSCE 522 - Farkas 23
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

24. CSCE 522 - Farkas 24
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

25. CSCE 522 - Farkas 25
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

26. CSCE 522 - Farkas 26
Traditional Software
Development
 No information security consideration
 Highly distributed among business units
 Lack of understanding of technical security
risks

27. CSCE 522 - Farkas 27
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

28. CSCE 522 - Farkas 28
Deployment and Operations
 Configuration and customization of
software application’s deployment
environment
 Activities:
– Network-component-level
– Operating system-level
– Application-level

29. CSCE 522 - Farkas 29
Deployment and Operations
 Configuration and customization of
software application’s deployment
environment
 Fine tuning security functionality
 Evaluate entire system’s security properties
 Apply additional security capabilities if
needed

30. CSCE 522 - Farkas 30
Who are the attackers?
 Amateurs: regular users, who exploit the
vulnerabilities of the computer system
– Motivation: easy access to vulnerable resources
 Crackers: attempt to access computing facilities
for which they do not have the authorization
– Motivation: enjoy challenge, curiosity
 Career criminals: professionals who understand
the computer system and its vulnerabilities
– Motivation: personal gain (e.g., financial)

31. CSCE 522 - Farkas 31
Attacker’s Knowledge
 Insider
– Understand organizational data, architecture,
procedures, etc.
– May understand software application
– Physical access
 Outsider
– May not understand organizational information
– May have software specific expertise
– Use of tools and other resources

32. CSCE 522 - Farkas 32
Vulnerability Monitoring
 Identify security weaknesses
 Methods:
– Automated tools
– Human walk-through
– Surveillance
– Audit
– Background checks

33. CSCE 522 - Farkas 33
System Security Vulnerability
 Software installation
– Default values
– Configurations and settings
 Monitoring usage
– Changes and new resources
– Regular updates
 Tools
– Look for known vulnerabilities

34. CSCE 522 - Farkas 34
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.

35. CSCE 522 - Farkas 35
Next Class
 Malicious code