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
CSCE 548 - Farkas 11
Three Pillars of Software SecurityThree Pillars of Software Security
Risk ManagementSoftware Security TouchpointsKnowledge
CSCE 548 - Farkas 12
Risk ManagementRisk Management
CSCE 548 - Farkas 13
Risk AssessmentRisk Assessment
RISKRISK
Threats
Vulnerabilities Consequences
CSCE 548 - Farkas 14
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
CSCE 548 - Farkas 15
Risk Acceptance
Certification How well the system meet the security
requirements (technical)
Accreditation Management’s approval of automated system
(administrative)
CSCE 548 - Farkas 16
Software Security Touchpoints
CSCE 548 - Farkas 17
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
CSCE 548 - Farkas 18
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
CSCE 548 - Farkas 19
CSCE 548 - Farkas 20
Best PracticesBest Practices
Earlier the betterChange “operational” view to secure
softwareBest practices: expounded by experts and
adopted by practitioners
CSCE 548 - Farkas 21
Who Should Care?Who Should Care?
DevelopersArchitectsOther buildersOperations people
Do not start with security people.Start with software people.
CSCE 548 - Farkas 22
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
CSCE 548 - Farkas 23
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
CSCE 548 - Farkas 24
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
CSCE 548 - Farkas 25
Top Related