1. CSCE 548 Secure Software Development Test 1 Review

2. Reading McGraw: Software Security: Chapters 1 – 9 Other:
I. Alexander, Misuse Cases: Use Cases with Hostile Intent, IEEE Software, vol. 20, no. 1, pp
Computer Security Incident Handling Guide, Recommendations of the National Institute of Standards and Technology
Software Engineering Institute, CMU, Advancing Cybersecurity Capability Measurement Using the CERT®-RMM Maturity Indicator Level Scale
OWASP Software Assurance Maturity Model (SAMM)
CSCE Farkas

3. 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 Farkas

4. Why Software? Increased complexity of software product
Increased connectivity
Increased extensibility
Increased risk of security violations!
CSCE Farkas

5. 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
CSCE Farkas

6. 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
Deep
Trouble
Who
Knows
CSCE Farkas

7. Three Pillars of Software Security
Risk Management
Software Security Touchpoints
Knowledge
CSCE Farkas

8. Risk Management
CSCE Farkas

9. Risk Assessment RISK Threats Vulnerabilities Consequences
CSCE Farkas

10. Risk Management Framework (Business Context)
Understand Business
Context
Identify Business
and Technical Risks
Synthesize and Rank
Risks
Define Risk
Mitigation Strategy
Carry Out Fixes
and Validate
Measurement and Reporting
CSCE Farkas

11. Risk Acceptance Certification Accreditation
How well the system meet the security requirements (technical)
Accreditation
Management’s approval of automated system (administrative)
CSCE Farkas

12. Software Security Touchpoints
CSCE Farkas

13. 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
CSCE Farkas

14. 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
CSCE Farkas

15. 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
CSCE Farkas

16. Best Practices Earlier the better
Change “operational” view to secure software
Best practices: expounded by experts and adopted by practitioners
CSCE Farkas

17. Do not start with security people. Start with software people.
Who Should Care?
Developers
Architects
Other builders
Operations people
Do not start with security people.
Start with software people.
CSCE Farkas

18. 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
CSCE Farkas

19. Next Class Midterm
CSCE Farkas