1. Engineering Secure Software

2. A Ubiquitous Concern  You can make a security mistake at every step of the development lifecycle  Requirements that allow for privacy violations e.g. secretary can view everyone’s patient records  Introducing a design flaw, e.g. giving plug-ins total access  Introducing a code-level vulnerability, e.g. buffer overflow  Missing a vulnerability in code inspections & testing  Introducing a vulnerability by regression in maintenance  Not facilitating a secure deployment, e.g. installation defaults © 2011-2012 Andrew Meneely

3. Security at Every Step Requirements & Planning Abuse cases Risk Assessment Threat Modeling Design Architectural risk Secure design patterns Formalism Implementation Vulnerability Taxonomy Input/Output Handling Auditability Testing Penetration Testing Exploratory Testing Automated Testing Deployment Networking & Cryptography DefaultsPermissions Maintenance PatchingRegressionAssessment

4. Core Security Properties  Software security breaks into these categories Confidentiality Integrity Availability  Very broad, multi-dimensional categories  Some people add in “auditability”, but we consider that part of “integrity”

5. Confidentiality  The system must not disclose any information intended to be hidden E.g. your credit card information on a website  Note: open source software can still be confidential

6. Integrity  The system must not allow assets to be subverted by unauthorized users E.g. changing a prisoner’s release date  We must be able trust what is in the system The data being stored The functionality being executed

7. Availability  The system must be able to be available and operational to users E.g. bringing down Amazon.com  These are extremely hard to protect against Any system performance degradation that can be triggered by a user can be used for denial of service attacks Concurrency issues, infinite loop, or resource exhaustion

8. Misc. Philosophies & Proverbs  Defense in depth If they break into this, they can’t get any farther Think Middle-Age castles Original meaning of “firewall”, not today’s firewall  Least privilege Every user or module is given the least amount of privilege it needs Evil: sudo chmod –R a+rw /

9. More Misc. Philosophies & Proverbs  Fail securely Exceptions put the system into weird states Error message information leak Take care of those exceptions properly!  Security by obscurity You can’t rely upon being obscure to be secure ○ Crowds are good at guessing ○ Insiders are corruptible Some notable exceptions: passwords, encryption keys

10. Even More Misc. Philosophies & Proverbs  Detect and record Even if you can’t always sift through that data ahead of time Post-mortem analysis  Don’t trust [input | environment | dependencies | *] Know what to trust Know how to trust

11. Even Even More Misc. Philosophies & Proverbs  Secure by default Don’t rely on your users to use it correctly Convention over configuration  Keep it simple YAGNI Speculative generality can be risky Minimize the attack surface

12. Discussion Exercise: Spam Bot Server  Suppose we had a vulnerability in the RIT mail servers where you could send a special packet and it would bypass authentication for outgoing email. This allowed attackers to send emails using any account.  Which of CIA does this violate? Immediately? As a secondary consequence?  Using the following philosophies, discuss how each of these can be applied here: Defense in Depth Security by obscurity Detect and record Don’t trust input