# Software Security Lecture

## Determining Security Requirements
- regulations/standards (HIPPA, SOX, etc.)
- organizational values (e.g., valuing privacy)
- Policy arising from threat modeling
- Avoiding potential attacks
### Abuse Cases
- Opposite from *use cases*
- which describe what it should do
- Abuse cases illustrate security requirements
- describe what it should *not* do
#### Defining Abuse Cases
- Using attack patterns and likely scenarios
- based on the threat model
- What might occur if a security measure was removed?

## Design Flaws
- Design Defects = Flaws
- **Flaws** are problems in the design
- **Bugs** are problems in the implementation
- **\*Avoid flaws during design phase\***
-
### Design v.s. Implementation
- Many different levels of system design decisions
- Highest level: processes, interactions, and programming languages to use
- Next level: design **modules/components**, identifying the **core functionalities** and how they work together
- Lowest level: **data structure** and **functions**

## Top Design Flaws
- priciples and rules
- **IEEE Center for Secure Design**
### Top 10 Flaws
1. Assume trust
2. Use of an authentication mechanism that can be bypassed or tampered with
3. Authorize without sufficient context
4. Confuse data control instructions, and process control instructions from untrusted sources
5. Fail to validate data *explicity* and *comprehensively*
6. Fail to use cryptography correctly
7. Fail to identify sensitive data andhow to handle it
8. Ignore the users
9. Integrate external components without consiering their attack surface
10. Rigidly constrain future changes to objects and actors

### Failure: Authentication Bypass
#### Clients coereced to accept invalid SSL certificates
- Bypass client authentication of server: Am I really talking to my bank?
- Web browser should present a warning
- **Remember: Security is *not* a feature**
- It should test what should *not* happen
#### Authentication tokens with long timeouts
- Motivate brute-force

### Failure: Bad Crypto
- Don't make your own crypto
- Don't assume it gives you something it doesn't
- Hashing protects integrity but not confidentiality
- Use properly generated keys of sufficient size
- Don't hard-code keys

### Failure: Ignore which data is sensitive
- Which require protection?
- Personally identifiable information, sensor reading, cryptographic keys, session tokens, geolocation data, ...
- How are data sources exposed?
- What is the threat model?
- Example failure: embedding authentication token in exposed URL

### Failure: Ignore Attack Surface of External Components
- Do third-party components do *only* what I want?

## VSFTPD -- Very Secure FTPD
- FTP: File Transfer Protocal
- Thoughtful design and good performance writtten in C
### VSFTPD Threat model
- Clients untrusted, until authenticated
- Once authenticated, limited trust:
- According to user's file access control policy
- Possible attack goals
- Steal or corrupt resourses
- Remote code injection
- Circumstances
- Client attacks server
- Client attack other clients
### Defenses
- Secure Strings: check *everything*
- integer overflow, buffer overflow, ...
- Secure system calls
- Make wrappers for system calls to ensure error is well-handled
- Minimal Privilege
- Untrusted input always handled by non-root process
- Uses IPC (inter-process communication) to delegate high-privilege actions
- Reduce privileges as much as possible
- `chroot` to hide all directories but the current one
- Keeps visible only those files served by FTP