Intro + Basic Principles Flashcards
Definition: Software Vulnerability
A vulnerability is a software weakness that allows an attacker to exploit a software bug. A vulnerability requires three key components:
1) system is susceptible to flaw
2) adversary has access to the flaw
3) adversary has capability to exploit the flaw
Goals Software Engineering
- Dependability: producing fault-free software
- Productivity: deliver on time, within budget
- Usability: satisfy a client’s need
- Maintainability: extensible when needs change
Security Best Practices
- Properly design software
- Clear documentation (design and implementation)
- Leverage frameworks
- Code reviews
- Add rigorous security tests to unit tests
- Formal verification for components that can be verified
- Red team software
- Offer bug bounties
Security principle: Isolation
Isolate two components from each other. One component cannot access data/code of the other components except through a well-defined API.
Security principle: least privilege
The principle of least privilege ensures that a component has the least privileges needed to function.
-> Any further removed privilege reduces functionality
-> Any added privilege will not increase functionality (according to the specification)
-> requires isolation
Security Principle: Fault compartments
Separate individual components into smallest functional entity possible. These units contain faults to individual components. Allows abstraction and permission checks at boundaries.
-> Builds on least privilege and isolation
Security principle: Trust and correctness
Specific components are assumed to be trusted or correct according to a specification
Security Principles
- Isolation
- Least Privilege
- Fault compartments
- Trust and correctness
Access control: authorization
- Authorization centers around Information-Flow Control (IFC)
- Who can access what information?
- Access policies are called access control models
- Multi-level security
- Two types of access control:
-> Mandatory Access Control (MAC)
-> Discretionary Access Control (DAC) - Access control models can be hierarchical:
-> Role-Based Access Control (RBAC)
Authorization: Mandatory Access Control (MAC)
- Idea: Rule and lattice-based policy
-> Centrally controlled
-> One entity controls what permissions are given
-> Users cannot change policy themselves
-> Examples: Bell/LaPadula and Biba - Examples: the administrator sets permissions for each file/hospital owns patient file, specifies access permissions
Authorization: MAC - Bell and LaPadula
- Multi-level security model that enforces information-flow control
- All security levels are monotonically ordered, Objects (files) have a clearance level
- A given clearance allows reading objects of lower or equal clearance and writing files of equal or higher clearance
- Summarized as “read-down”, “write-up”
- Enforces confidentiality
- Key weakness: If implemented naively, attacker may overwrite confidential files
Authorization: MAC - Biba
- Multi-level security model that enforces information-flow control
- All security levels are monotonically ordered. Objects (files) have an integrity level
- A given clearance allows reading files of higher or equal clearance and writing files of lower or equal clearance.
- Biba introduces notion of integrity, separate from secrecy
- Summarized as “read-up”, “write-down”
- Key weakness: if implemented naively, attacker may leak privileged information
Access control: Discretionary Access Control (DAC)
- Idea: object owner specifies policy
-> MAC requires central control, DAC empowers the user
-> User has authority over her resources (introduce ownership)
-> User sets permissions for her data if other users want access - Can become complex and may require per-file special casing
- Example: Unix file permissions
Access control: Role-based Access Control (RBAC)
- {DAC,MAC} policy defined in terms of roles (sets of permissions), individuals are assigned roles, roles are authorized for tasks
-> Access permission is broken into sets of roles
-> Users get assigned specific roles
-> Administration privileges may be a role - Roles simplify special casing but roles can become overly complex
