CSCE 522 Secure Software Development Best Practices

1
CSCE 522 Secure Software DevelopmentBest
Practices
2
Reading

• This lecture
• Jan Jürjens, Towards Development of Secure
  Systems using UMLsec, http//citeseer.ist.psu.edu/
  536233.html

3
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
2. Risk Analysis
5. Abuse cases
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
4
Design Flaws

• 50 of security problems
• Need explicitly identifying risk
• Quantifying impact tie technology issues and
  concerns to business
• Continuous risk management

5
Security Risk Analysis

• Risk analysis identifying and ranking risks
• Risk management performing risk analysis
  exercises, tracking risk, mitigating risks
• Need understanding of business impact

6
Risk Analysis

• Address risk as early as possible in the
  requirements level
• Impact
• Legal and/or regulatory risk
• Financial or commercial considerations
• Contractual considerations
• Requirements must-haves, important-to-have,
  and nice-but-unnecessary-to-have

7
Basic Risk Analysis

• Tailored for specific vulnerabilities
• High-level overview
• Meaningful results
• Cross-tier analysis different trust zones
• Use of deployment pattern
• Decomposing software on a component-by-component
  basis

8
Risk Analysis Practice

• Ad-hoc manner
• Does not scale and not repeatable or consistent
• Depends on knowledge and expertise of analyst
• Results are difficult to compare

9
Attack Resistance Analysis

• Information about known attacks, attack patterns,
  and vulnerabilities known problems
• Identify general flaws using secure design
  literature and checklists
• Map attack patterns based on abuse cases and
  attack patterns
• Identify risk in the architecture using
  checklist
• Understand and demonstrate the viability of known
  attacks

10
Ambiguity Analysis

• Discover new risks
• Parallel activities of team members ? unify
  understanding
• Private list of possible flaws
• Describe together how the system worked
• Need a team of experienced analysts

11
Weakness Analysis

• Understanding the impact of external software
  dependencies
• Middleware
• Outside libraries
• Distributed code
• Services
• Physical environment
• Etc.

12
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
13
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

14
Software Vendor Accountability

• Proper implementation of security features
• Looking for known security flaws
• Passing third party validation
• Source code analysis

15
Checking for Known Vulnerabilities

• Need tool
• Possible attacks and attack types
• How the software behaves if something goes WRONG
• What motivates an attacker?

16
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

17
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

18
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

19
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
20
Software Testing

• Application fulfills functional requirements
• Dynamic, functional tests late in the SDLC
• Contextual information

21
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)

22
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

23
Penetration Testing Today

• Often performed
• Applied to finished products
• Outside ? in approach
• Late SDLC activity
• Limitation too little, too late

24
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

25
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

26
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
27
Software Testing

• Running a program or system with the intent of
  finding errors
• Evaluating capability of the system and
  determining that its requirements
• Physical processes vs. Software
• Testing purposes
• To improve quality
• For Verification Validation (VV)
• For reliability estimation

28
Quality Assurance

• External quality correctness, reliability,
  usability, integrity
• Interior (engineering) quality efficiency,
  testability, documentation, structure
• Future (adaptability) quality flexibility,
  reusability, maintainability

29
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

30
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

31
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.

32
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)

33
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 attackers model

34
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

35
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

36
Application of Touchpoints
External Review
3. Penetration Testing
1. Code Review (Tools)
6. Security Requirements
4. Risk-Based Security Tests
2. Risk Analysis
7. Security Operations
5. Abuse cases
2. Risk Analysis
Requirement and Use cases
Architecture and Design
Test Plans
Code
Tests and Test Results
Feedback from the Field
37
Traditional Software Development

• No information security consideration
• Highly distributed among business units
• Lack of understanding of technical security risks
  

38
Dont 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

39
Deployment and Operations

• Configuration and customization of software
  applications deployment environment
• Activities
• Network-component-level
• Operating system-level
• Application-level

40
Deployment and Operations

• Configuration and customization of software
  applications deployment environment
• Fine tuning security functionality
• Evaluate entire systems security properties
• Apply additional security capabilities if needed

41
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)

42
Attackers 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

43
Vulnerability Monitoring

• Identify security weaknesses
• Methods
• Automated tools
• Human walk-through
• Surveillance
• Audit
• Background checks

44
System Security Vulnerability

• Software installation
• Default values
• Configurations and settings
• Monitoring usage
• Changes and new resources
• Regular updates
• Tools
• Look for known vulnerabilities

45
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.

46
Next Class

• Malicious code