Security Design Principles

Question 1

Economy of mechanism

Answer 1

Design should be simple and small as possible
-> easy to test and verify
-> more complex bigger attack surface or vulnerable components
-> simplifies configuration management, updates and replacements

Question 2

Fail-safe default

Answer 2

Access based in permission rather than exclusion
-> default is lack of access, protection scheme finds conditions for permitted access.

Question 3

Complete mediation

Answer 3

Every access must be checked against the access control mechanism
-> decisions should be retrieved from cache.
-> When a file is already opened control access is not checked again, every time a modification is applied access control should need to be rechecked

Question 4

Open design

Answer 4

Mechanism should be open rather than secret
-> benefits from community
-> does not rely on hiding/obfuscation for a false-sense of security

Question 5

Separation of privilege

Answer 5

Multiple privilege attributes are used to achieve access to a restricted resource
-> MFA requires multiple authentication resources
-> Program divided into parts limited to specific privileges to perform a specific task
-> Day to Day interfaces have the lowest privileges.

Question 6

Least Privilege

Answer 6

Process and users should operate with the least set of privileges necessary to perform a task.
-> System security policy identifies and defines the roles of users or processes.
-> Every permission specifies access to a particular resource
-> If permission is not defined, access to resource is not allowed
-> Higher privileges should only be active for a time window (temporal aspect)

Question 7

Least Common Mechanism

Answer 7

design should minimize functions shared by different users, providing mutual security.
-> reduces number of unintended communication paths

Question 8

Psychological Acceptability

Answer 8

Design should not interfere unduly with the work and also meet the needs of those who authorize access.
-> if hinder usability the user might turn them off (minimal obstruction)
-> it should try to adhere to the user’s mental model of protection

Question 9

Isolation

Answer 9

Public systems should be isolated from critical resources
-> limit number of systems where data is stored and isolate them
-> physical isolation: no physical connection between public access and critical information
-> logical isolation: OS separate process space, memory space, file space. Crypto software has a logical boundary to protect from tampering, and key disclosure or replacement

Question 10

Encapsulation (Isolation)

Answer 10

Isolation based on a logical collection of procedures and data objects that belong to a domain

Question 11

Modularity

Answer 11

Security functions as protected modules
Modular architecture for design and implementation
-> easier to centralize and improve the design of a single component (like cryptographic modules) and harden it from attacks
-> modular architecture allows updating single components more easily without having to update the complete system or make it unavailable for an upgrade

Question 12

Layering

Answer 12

multiple, overlapping protection between all sw, hw and human resources
-> ensures failure or circumvention of one does not compromise the whole system

Defense in Depth

Question 13

Least astonishment

Answer 13

System should always respond in the way that is least likely to astonish the user.
-> transparent to user so its understandable how something works

Question 14

Attack surfaces

Answer 14

Reachable or exploitable vulnerabilities in a system
Network: vulnerabilities over a local or public network; also protocols.
OSI Layer 3-6
Software: vulnerabilities in application, utility or OS. Web server software
OSI Layer 7
Human: vulnerabilities in personnel or outsiders, social engineering, human error, or trusted insiders.

Question 15

Attack surface Analysis

Answer 15

Assess scale and severity of threat
-> find ways to make surface smaller
-> priorities for testing

Question 16

Attack Trees

Answer 16

branching, hierarchical DS represents a set of potential techniques for exploiting security vulnerabilities.
-> root is security incident
-> techniques are branches and subnodes, each subnode is a subgoal
-> leaves are ways to initiate the attack
-> branches can be labelled with difficulty, cost, etc.

Document security attacks in a structured form that reveals key vulnerabilities

Question 17

Security Strategy

Answer 17

Specification/Policy: what is the security scheme supposed to do?
Implementation/Mechanisms: How does it do it?
Correctness/Assurance: Does it really work?

Question 18

Security Strategy - Security Policy

Answer 18

Informal: description of desired system behavior
Formal: rules and practices that specify/regulate how a system provides security services to protect sensitive and critical system resources.

Trade-offs:
Ease of use vs sec: sec mechanisms might reduce capacity of system to provide a security layer
Cost of prevention vs failure and recovery: cost of implementation and maintenance of sec measures vs failure and recovery.

Business decision influenced by legal requirements

Question 19

Security Strategy - Security Implementation

Answer 19

Prevention: seeks that no attack is successful. Some threats will need countermeasures with complete prevention as a goal
Detection: if prevention cannot be guaranteed, detection must be.
Response: respond to the attack and prevent further damage
Recovery: if compromised a backup can be restored.

Question 20

Security Strategy - Assurance and Evaluation

Answer 20

Assurance: ensures system enforces system’s security policy
Evaluation: involves testing and may also involve formal analytic or mathematical techniques.