CSCE 548 Building Secure Software

CSCE Farkas2 Reading This lecture: – McGraw: Chapter 1 – Recommended: CyberInsecurity: The Cost of Monopoly, Next lecture: – McGraw: Chapter 2

CSCE Farkas3 Why do we need software security? Software is essential in most every aspect of our life Current news (recommended): – Kelly Jackson Higgins, Dark Reading, SQL Injection Hack Infects 1 Million Web Pages, InformationWeek, January 5, 2012, – Gregg Keizer, Adobe plugs 6 critical holes in Reader, Computerworld, January 11, 2012, n_Reader n_Reader – Gregg Keizer, Microsoft patches critical Windows drive-by bug, Computerworld, January 10, 2012, dows_drive_by_bug dows_drive_by_bug

CSCE Farkas4 How to address software security? Do not address at all Ad-hoc evaluation Add security features after the fact Identify security vulnerabilities Test security level Incorporate security throughout of SDLC

CSCE Farkas5 This Course Not a software engineering course Understand basic security concepts and their impact Introduce systematic security design and development along project management Best practices

CSCE Farkas6 Security Objectives Confidentiality: prevent/detect/deter improper disclosure of information Integrity: prevent/detect/deter improper modification of information Availability: prevent/detect/deter improper denial of access to services Which objective SW security addresses?

CSCE Farkas7 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 Farkas8 Why Software? Increased complexity of software product Increased connectivity Increased extensibility Increased risk of security violations!

CSCE Farkas9 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 Farkas10 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 Farkas11 Three Pillars of Software Security Risk Management Software Security Touchpoints Knowledge

CSCE Farkas12 Risk Management How much effort to invest in security Consequences of security breaches Acceptable-level of security Tracking and mitigating risk throughout the full SDLC

CSCE Farkas13 Touchpoints System-wide activity: from design to testing and feedback Focus on security from ground up Touchpoints: 1. Code review 2. Architectural risk analysis 3. Penetration testing 4. Risk-based security testing 5. Abuse cases 6. Security requiremetns 7. Security operations

CSCE Farkas14 Knowledge 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

CSCE Farkas15 Security 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

Start with Software Developers! CSCE Farkas16

CSCE Farkas17 Next Class Risk Management