CSCE 548 Secure Software Development Test 1 Review

1
CSCE 548 Secure Software DevelopmentTest 1
Review
2
Final 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

3
Final Project Format

• 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

4
Final Project Format

• 4. Current Work
• 4.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

5
Reading

• McGraw Software Security Chapters 1 9, 12

6
Non-Textbook Reading

1. Lodderstedt et. al, SecureUML A UML-Based
   Modeling Language for Model-Driven Security,
   http//kisogawa.inf.ethz.ch/WebBIB/publications-so
   ftech/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?doid3
   84192.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
   

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

8
Why Software?

• Increased complexity of software product
• Increased connectivity
• Increased extensibility
• Increased risk of security violations!

9
Security 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

10
Application 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

Who Knows
Deep Trouble
11
Three Pillars of Software Security

• Risk Management
• Software Security Touchpoints
• Knowledge

12
Risk Management
13
Risk Assessment
14
Risk Management Framework (Business Context)
Understand Business Context
15
Risk Acceptance

• Certification
• How well the system meet the security
  requirements (technical)
• Accreditation
• Managements approval of automated system
  (administrative)

16
Software Security Touchpoints
17
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
18
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

19
Additional 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

20
Best Practices

• Earlier the better
• Change operational view to secure software
• Best practices expounded by experts and adopted
  by practitioners

21
Who Should Care?

• Developers
• Architects
• Other builders
• Operations people

Do not start with security people. Start with
software people.
22
SANS Secure Programming Skills 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

23
Goal of Taxonomy

• List of common coding mistakes
• Support for software developers to avoid making
  mistakes
• Useful in automated tools
• Real time
• Compile time
• Teaching aid
• NOT an attack taxonomy

24
7 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

25
Next ClassOverview of the 19 deadly sins,
vulnerability taxonomy, SANS top 25
vulnerabilities