CSCE 548 Secure Software Development Test 1 Review

CSCE 548 CSCE 548 Secure Software Secure Software

DevelopmentDevelopment

Test 1 ReviewTest 1 Review

Final Project FormatFinal Project Format Title

Author

Abstract

What you did in this paper

1. Introduction

2. Related work

3. Background information

4. Current research/development

5. Conclusions and Future Work

6. Group members’ contributions

References

CSCE 548 - Farkas 2

Final Project FormatFinal Project Format

1. Introduction– Problem description, its importance– Representative example– Brief description of related works– What is missing? – Your work addressing the

research/development gap– Organization of the report

CSCE 548 - Farkas 3

Final Project FormatFinal Project Format

4. Current Work4.1 Definition of concepts (if applicable)

4.2 Problem definition

4.3 Solution

4.4 Proof-sketch of solution (if applicable) correctness/efficiency/contribution to the area

CSCE 548 - Farkas 4

CSCE 548 - Farkas 5

ReadingReading McGraw: Software Security: Chapters 1 – 9, 12

Non-Textbook ReadingNon-Textbook Reading1. Lodderstedt et. al, SecureUML: A UML-Based Modeling Language for

Model-Driven Security, http://kisogawa.inf.ethz.ch/WebBIB/publications-softech/papers/2002/0_secuml_uml2002.pdf

2. B. Littlewood, P. Popov, L. Strigini, "Modelling software design diversity - a review", ACM Computing Surveys, Vol. 33, No. 2, June 2001, pp. 177-208, http://portal.acm.org/citation.cfm?doid=384192.384195

3. I. Alexander, Misuse Cases: Use Cases with Hostile Intent, IEEE Software, vol. 20, no. 1, pp. 58-66, Jan./Feb. 2003. http://www.computer.org/portal/web/csdl/doi/10.1109/MS.2003.1159030

4. B. Schneier on Security, http://schneier.com/blog/archives/2007/05/is_penetration.html

5. P. Meunier, Classes of Vulnerabilities and Attacks, Wiley Handbook of Science and Technology for Homeland Security, http://homes.cerias.purdue.edu/~pmeunier/aboutme/classes_vulnerabilities.pdf

CSCE 548 - Farkas 6

CSCE 548 - Farkas 7

Software Security Software Security

NOT security software!Engineering software so that it continues to

function correctly under malicious attack– Functional requirements– Non-functional requirements (e.g., security)

CSCE 548 - Farkas 8

Why Software?Why Software?

Increased complexity of software productIncreased connectivityIncreased extensibility

Increased risk of security violations!

CSCE 548 - Farkas 9

Security ProblemsSecurity Problems

Defects: implementation and design vulnerabilities Bug: implementation-level vulnerabilities (Low-

level or mid-level)– Static analysis tool

Flaw: subtle, not so easy to detect problems– Manual analysis– Automated tools (for some but not design level)

Risk: probability x impact

CSCE 548 - Farkas 10

Application vs. Software SecurityApplication vs. Software Security

Usually refers to security after the software is built– Adding more code does not

make a faulty software correct– Sandboxing – Network-centric approach

Application security testing: badness-ometer

Deep Trouble

Who Knows


Three Pillars of Software SecurityThree Pillars of Software Security

Risk ManagementSoftware Security TouchpointsKnowledge


Risk ManagementRisk Management


Risk AssessmentRisk Assessment

RISKRISK

Threats

Vulnerabilities Consequences


Risk Management Framework(Business Context)

Understand BusinessContext

Identify Business and Technical Risks

Synthesize and RankRisks

Define RiskMitigation Strategy

Carry Out Fixesand Validate

Measurement and Reporting


Risk Acceptance

Certification How well the system meet the security

requirements (technical)

Accreditation Management’s approval of automated system

(administrative)


Software Security Touchpoints


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


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

Additional MaterialsAdditional Materials

Security requirement analysis SecureUML by Lodderstedt et. Al

Abuse cases Misuse Cases: Use Cases with Hostile Intent by Alexander

Software Reliability Modeling software design diversity by Littlewood et. al



Best PracticesBest Practices

Earlier the betterChange “operational” view to secure

softwareBest practices: expounded by experts and

adopted by practitioners


Who Should Care?Who Should Care?

DevelopersArchitectsOther buildersOperations people

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


SANS: Secure Programming SANS: Secure Programming Skills AssessmentSkills Assessment

Aims to improve secure programming skills and knowledge

Allow employers to rate their programmers Allow buyers of software and systems vendors to

measure skills of developers Allow programmers to identify their gaps in secure

programming knowledge Allow employers to evaluate job candidates and

potential consultants Provide incentive for universities to include secure

coding in their curricula


Goal of TaxonomyGoal of Taxonomy

List of common coding mistakesSupport for software developers to avoid

making mistakesUseful in automated tools

– Real time – Compile time

Teaching aidNOT an attack taxonomy


7 Plus 1 Kingdoms7 Plus 1 Kingdoms

1. Input validation and representation

2. API abuse

3. Security features

4. Time and state

5. Error handling

6. Code quality

7. Encapsulation

8. Environment

NEXT CLASSNEXT CLASSOVERVIEW OF THE 19 DEADLY SINS, VULNERABILITY TAXONOMY, SANS TOP 25 VULNERABILITIES


Documents

CSCE 548 Secure Software Development Test 1 Review