CSCE 522 Building Secure Software. CSCE 548 - Farkas2 Reading This lecture – McGraw: Ch. 3 – G. McGraw, Software Security,

CSCE 522 CSCE 522 Building Secure SoftwareBuilding Secure Software

CSCE 548 - Farkas 2

Reading Reading

This lecture– McGraw: Ch. 3– G. McGraw, Software Security ,

http://www.cigital.com/papers/download/bsi1-swsec.pdf – Ted Demopoulos, Worst Practices in Developing Secure Software,

http://www.demop.com/articles/developing-secure-software.html Next Lecture

– McGraw: Ch. 4 (overview, we’ll cover code review in details later)

CSCE 548 - Farkas 3

Three Pillars of Software SecurityThree Pillars of Software Security

Risk ManagementSoftware Security TouchpointsKnowledge

CSCE 548 - Farkas 4

Risk ManagementRisk Management

How much effort to invest in securityConsequences of security breachesAcceptable-level of security Tracking and mitigating risk throughout the

full SDLC

CSCE 548 - Farkas 5

TouchpointsTouchpoints

System-wide activity: from design to testing and feedback Focus on security from ground up Touchpoints:

1. Code review2. Architectural risk analysis3. Penetration testing4. Risk-based security testing5. Abuse cases6. Security requirements7. Security operations8. External Analysis

Prioritize activities!

CSCE 548 - Farkas 6

KnowledgeKnowledge

Gathering, encapsulating, and sharing security knowledge

Knowledge catalogs: principles, guidelines, rules, vulnerabilities, exploits, attack patterns, historical risks

Knowledge categories: – Prescriptive knowledge– Diagnostic knowledge– Historical knowledge

Applied along the SDLC

Can you give examples?

CSCE 548 - Farkas 7

Security EngineeringSecurity Engineering

Reduce the need for reactive technologies (e.g., intrusion detection) by safer products Understand software

Need for:– Software developers– Operations people– Administrators– Users– Executives

Why do these people need Security Engineering?

CSCE 548 - Farkas 8

Software Security TouchpointsSoftware Security Touchpoints

Best PracticesBoth White Hat (constructive) and Black

Hat (destructive) activitiesThroughout the SDLC

How do you think about security? Which is more important? White hat or Black hat

type of activities?

CSCE 548 - Farkas 9

Application of TouchpointsApplication of Touchpoints

Requirement and Use cases

Architecture and Design

Test Plans Code Tests andTest Results

Feedback fromthe Field

5. Abuse casesAbuse 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

CSCE 548 - Farkas 10

Code Review (Tool)Code Review (Tool)

Artifact: CodeImplementation bugsStatic Analysis toolsWhite Hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Architectural Risk AnalysisArchitectural Risk Analysis

Artifact: Design and specification System must be coherent and present a uniform security

front Document assumptions and identify possible attacks Both at specification-based architecture stage and class-

hierarchy design stage White hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Penetration TestingPenetration Testing

Artifact: system in its environment Understanding fielded software in its environment Information supplied by architectural risk analysis Who does it? Black Hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Risk-Based Security TestingRisk-Based Security Testing

Artifact: unit and system Strategies:

– Testing of security functionality (standard functional testing)

– Risk-based security testing (attack pattern, risk analysis, abuse cases)

Attacker’s mindset White Hat + Black Hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Abuse CasesAbuse Cases

Artifact: requirements and use cases Describe system behavior under attack Explicit coverage of

– What should be protected– From whom– For how long

White Hat + Black Hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Security RequirementsSecurity Requirements

Artifact: RequirementsSecurity explicitly worked into the

requirements levelBoth functional security and emergent

characteristicsWhite Hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




Security OperationsSecurity Operations

Artifact: fielded systemMonitoring system usageCombines both network centric and

software specific operationsWhite Hat





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




External AnalysisExternal Analysis

Evaluate security by outside members Why?Advantages/disadvantages





5. Abuse cases


2. Risk Analysis

External Review



2. Risk Analysis




When to Apply Security? When to Apply Security? Economical consideration: early is better Effectiveness of touchpoints:

– Economics– Which software artifacts are available– Which tools are available– Cultural changes

Bad: reactive strategy need: secure development


Best PracticesBest Practices

Earlier the betterChange “operational” view to secure

softwareBest practices: expounded by experts and

adopted by practitioners

Worst Practices to AvoidWorst Practices to AvoidFrom T. Demopoulos, “Worst Practices in Developing Secure Software

1. Assuming only “important’ SW needs to be secure

2. Emphasizing hitting deadlines over “good code”

3. Having IT make all risk management decisions

4. Not considering security during the entire SDLC

5. Assuming the SW won’t be attacked

6. Not doing any security testing

7. Not planning for failure

8. Counting on “security through obscurity”

9. Disallowing bad input instead of only allowing good input

10. SW that is not secure by default

11. Coding your own cryptography



Who Should Care?Who Should Care?

DevelopersArchitectsOther buildersOperations people

Do not start with security people.Start with software people.


Next ClassNext Class

Code Review

Documents

CSCE 522 Building Secure Software. CSCE 548 - Farkas2 Reading This lecture – McGraw: Ch. 3 – G. McGraw, Software Security,