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