1. development lifecycle & Principles
Engineering Secure Software
development lifecycle & Principles

2. Information Systems Security
The CIA Triad
Source: By I, JohnManuel, CC BY-SA 3.0,

3. Core Security Properties
Software security breaks into these categories
Confidentiality
Integrity
Availability
Auditability or non-repudiation (some people add it as the fourth property, but we can consider it as a part of integrity)
Very broad, multi-dimensional categories

4. 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

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

6. 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

7. Auditability or Nonrepudiation
An actor should not be able to deny or dispute its actions
For example, key-card access
A party of a transaction cannot deny having received a transaction, and the other party cannot deny having sent the transaction
Trusted third parties

8. An Example Security Incident
AOL voluntarily releases data including 20 million web queries from 650,000 AOL users. Data included all searches from those users within a three month period, as well as whether they clicked on a result, and what that result was/where it appeared on the result page.
Security property violated: Confidentiality

9. An Example Security Incident
Dutch Government Identity Management Platform DigiD Disrupted by DDOS Attack.
Security property violated: Availability

10. An Example Security Incident
A secondary domain hosted by Bluehost was defaced by an opportunistic attack. We are consolidating the secondary domains in our primary provider and all domains will be pointing to our web site.
Security property violated: Integrity

11. An Example Security Incident
Hackers breach website of Hong Kong police force and publish non-public data, deface we page.
Security properties violated: CIA

12. 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
© Andrew Meneely

13. Security at Every Step Requirements & Planning Design Implementation
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
Defaults
Permissions
Maintenance
Patching
Regression
Assessment

14. 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 /

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

16. 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

17. 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

18. 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 . This allowed attackers to send s 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