Key Principles Flashcards

1
Q

Confidentiality

A

the property that information is not made available to unauthorized entities

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Integrity

A

the property that information is not altered or destroyed in an unauthorized manner

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Authentication

A

the act of confirming the identity of an entity interacting with a system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Authorization

A

the act of assigning rights and privileges to entities interacting with a system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Non-repudiation

A

the ability to associate actions or changes to a unique individual

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Least Privilege

A

Every component and entity has the minimum possible
privileges to complete its task

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Zero Trust

A

Dropping privileges is hard.
Start with zero privileges and add only the ones that are necessary.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Economy of Mechanism (8 Design Principles for Security)

A

Design should be as simple as possible. Complex mechanisms are difficult to test.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Fail-safe Defaults (8 Design Principles for Security)

A

Default state should be “lack of access.” Examples: No default pswd, no debugging interfaces or backdoors. Secure initial config. Start with highest security level. Invalid configuration falls back to high security.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Complete Mediation (8 Design Principles for Security)

A

Complete access control -> Every access to every object checked.
Authentication and authorization are critical. Any value that can be influenced by user can’t be trusted

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Open Design (8 Design Principles for Security)

A

NOT security by obscurity. Design should be available for everyone to build trust and allow reviews. Security should depend on secrecy of a small token

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Separation of Privilege (8 Design Principles for Security)

A

Access depends on more than one condition. Examples: launching missile requires two people and keys, bank safe needs two physical keys

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Least Privilege (8 Design Principles for Security)

A

Every component and entity has the minimum possible privileges to complete its task. Examples: Avoid running progs as root, drop privileges when no longer needed

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Least Common Mechanism (8 Design Principles for Security)

A

Reduce mechanisms used by more than one component, person…
Reduces surprise interactions. Avoids race conditions.
Reduces dangerous information flows

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Psychological Acceptability (8 Design Principles for Security)

A

Easy to use interfaces to tools and technologies otherwise people will use them incorrectly/for the wrong reasons/not at all

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Trusted Computing Base (TCB)

A
  • an abstraction layer (that represents a small amount of high-privilege software and hardware) that security depends on and that we distinguish from a much larger amount that can misbehave without affecting security
  • components responsible for enforcing security policy
  • we blindly trust that it behaves correctly, because if it was bad, then all of the security measures we make on the upper levels are pointless
17
Q

Capabilities

A
  • processes have capabilities (NOT users)
  • divide root privileges into smaller units that can be enabled/disabled independently
  • purpose: only give application the set of privileges it needs
18
Q

Validate ________

A

Validate INPUT!
Easier and more reliable to define acceptable input by the affirmative (ie input MUST be X, not input is not Y)

19
Q

Sanitize ________

A

Sanitize OUTPUT!
(remove any sensitive information that you don’t want to be seen, like error messages)

20
Q

Same Origin Policy

A
  • script from one origin can’t access data associated with a different region
  • enforced by browser, tracks with objects map where
  • ex: Facebook tab on browser can’t read cookies from bank tab
21
Q

MAC (Message Authentication Code)

A
  • mathematical cryptographic summary of the data
  • hash + authentication = MAC (Message Authentication Code)
  • get MAC when you use your key as input to hash algorithm
22
Q

Security by Obscurity

A
  • when security doesn’t depend on cryptography
  • assumes that system complexity –> not understandable to attackers –> system secure
  • ok to use obscurity to protect intellectual property, but bad to use as the foundation of a system’s security
23
Q

Intrusion Detection Systems (IDS)

A
  • goal: detect attacks on a system
  • contrast to prevention, recovery
  • blocklisting & allowlisting signatures of known events
  • blocklisting prone to false negatives
  • allowlisting prone to false positives
24
Q

Linux Kernel

A

Major component of TCB, able to interpose on or inspect everything a program does

Operates in supervisor mode:
- Process management.
- Memory management.
- Filesystem.
- Device drivers and hardware abstraction.
- Enforcement of security model & policy.

25
Q

Processes

A
  • Units of computation.
  • Has own virtual memory space.
  • Code, data, stack, heap, CPU context, kernel controlled-resources.
  • OS isolates processes from each other. Can have multiple threads of execution.
  • processes act on behalf of a user, sensitive operations checked against user credentials
26
Q

Attributes of Processes

A

Process ID (PID): unique identifier
User ID (UID): owner user
Effective User ID (EUID): checked for access control
Saved User ID (SUID): to temporarily drop and restore privileges

27
Q

Content Security Policy (CSP)

A
  • lets websites declare allowed origins of content
  • server specifies the policy in Content-Security- Policy header in HTTP response. Browser enforces the policy
  • dangerous features disabled (eval(), inline CSS, inline JavaScript and event handlers)
  • effective against XSS: can’t inject inline code & can’t include code from attacker origin
28
Q

Cross-Origin Resource Sharing (CORS)

A
  • mechanism to relax SOP, to allow controlled cross-origin requests
  • browser allows scripts to access cross-origin resources if the server indicates this is allowed via special HTTP headers
29
Q

Subresource Integrity (SRI)

A
  • mechanism to protect integrity during website delivery when assets are delivered through a third party (e.g., a CDN)
  • website owner includes hashes of assets and browser verifies hash after retrieving resource
30
Q

Least Privilege

A
  • explicitly declare what you can do
  • every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose
31
Q

Golden rule of crypto

A

DON’T BUILD YOUR OWN CRYPTOGRAPHIC PRIMITIVES
- its super hard and you will mess up.

32
Q

Untrusted input is…

A

anything that comes from the external world