---
# System prepended metadata

title: Security
tags: [Master]

---

---
tags: Master
---

# Security
[TOC]

## 2. Definitions
- **Information security**: the practice of preventing unauthorized access to information (of any form)
- **Computer security**: protection of computer systems, hardware and information on them
- **Network security**: physical and software measures to protect the networking infrastructure
- **Cyberspace**: global domain within the information environment consisting of different networks
- **Cyber attacks**: an attack to a cyberspace
- **Cyber security**: the ability to protect cyberspace from cyber attacks
- **Cyber security readiness**: the ability and tools to rapidly identify vulnerabilities and combat threats

![](https://i.imgur.com/Ryf9tnD.png =450x)



confused deputy

### Security properties
**CIA**:
- **Confidentiality**:
	- prevent unauthorized disclosure of information
	- protecting personal privacy
	- covers data in storage, processing and transit
- **Integrity**:
	- prevent unauthorized modification of information
	- ensuring information non-repudiation and authenticity
- **Availability**:
	- prevent unauthorized withholding of information
	- reliable access and use of information for authorized users
	- prevent unauthorized deletion of data (by the service provider) or denial of service

### Other properties
- **Reliability**: addresses the consequences of accidental error
- **Usability**: addresses the consequences of user error
- **Security**: deals with intentional failures
- **Safety**: absence of influences to the environment and humanity
- **Dependability**: reliability + security + safety
- **Authenticity**: being genuine, able to be verified and trusted; confidence in transmission, message and message originator
- **Non-repudiation**: provide capability to determine whether a given individual took a particular action

### Vulnerability, Threat, Risk
- **Vulnerability**: weakness in a system/application/network that is subject to exploitation
	- ex: SPECTRE
- **Threat**: exploits a particular vulnerability
	- Breaking into a computer (Hackers, …)
    - Attacking a computer (DoS, …)
    - Viruses and Worms
        - Virus: self-replicating program that requires user action to activate
        - Worm: self-replicating program that does not require user action to activate, it propagates through the network
    - Stealing information (use criptography)
    - Using a machine to attack others (E-mail viruses, worms, DoS, spam, …)
    - Interfering with the physical world (power systems, traffic control, medical devices, smart vehicles, IoT, …)
    
- **Risk**: probability that a particular threat will exploit a vulnerability



### Security policy, service, mechanism
- **Policy**: rules and requirements established by an organization for protecting CIA of information
- **Mechanism**: a device or function designed to provide security services /// **implementation of a policy**
- **Service**: capability to support one or more security requirements (CIA) (key management, AC, auth...)



## 3. Authentication 1
**Authentication**: process of verifying user's identity.
- motivation:
    - user identity can be a parameter for AC decisions
    - user identity used to log security relevant events (non-repudiation)
- **not always necessary or desirable to base AC on user identities**

### PASSWORDS
**Password**: secret shared between user and system

- **Authenticating** a remote user
    Users might need to receive their passwords.
    - do not give password to phone caller, send to user's number
    - send disposable password: user needs to reset when logging in
    - send (physical) mail with personal delivery
    - confirm identity using SMS (deprecated by NIST)

- **Resetting** password
    - when creating a new account, delay in getting password is tolerated
    - when changing/forgetting password it is not tolerated
        - big companies need "hot desk" (24/7 phone, trained staff)
        - on website use other info to auth (secret questions, SMS, etc)

- **Guessing** passwords
    - **brute force**: try all combinations up to tot
    - **knowing target**: names of friends, relatives, pets, ...
    - **dictionary attack**: try most used passwords from a DB
    - mitigations:
        - set a password (password is better than password)
        - change default passwords (admin, empty, password)
        - force long and weird passwords (OUTDATED)
    - new NIST rules:
        - forbid common passwords
        - no hints on knowledge based auth
        - limit attempts


### PHISHING and SPOOFING
**User has no guarantees about the system's identity: unilateral auth**
- **PHISHING**
    **Attacker impersonates the system** to trick a user into releasing credentials. Avoid by checking if login is at the "true" website (how to check?!)
    **Social engineering: attacker impersonates user** to trick system operator

- **SPOOFING**
    1. Attacker starts a program that presents a **fake login screen and leaves the computer**
    2. User puts credentials in fake login
    3. Sends credentials to attacker, shows error, closes
    4. User now logs into true login (*without noticing anything*)
    
    **Counters**
    - display failed attempts
    - **trusted path**: guarantee user is communicating with OS (ex: windows ctrl+alt+del)
    - mutual authentication (how?!)

### Protecting passwords
- OS has file with usernames and passwords
- attacker could aim at that
- protection:
    - cryptography
    - AC enforced by the OS for accessing the password file
    - combination of both

### HASH FUNCTIONS
- **Cryptographic hash functions**
- **A 1-way function is relatively easy to compute but hard to reverse**
- **Store hash(p) instead of p. Then compare hash(a) and  hash( p) to check if passwords match**
- requirements:
    - **easy to compute**
    - **one-way** aka hard to inverse
    - **compression**: input of any length, output of fixed (usually 64-256 bits) length
    - *weak collision resistance*: given an x, hard to find y with same hash
    - **STRONG COLLISION RESISTANCE**: hard to find x and y with same hash

- IMPLEMENTATIONS:
    - **MD4**: now weak
    - **MD5**: standard choice for internet protocols, now broken and not recommended
    - **SHA-1 (Secure Hash Algorithm)**: now weak lel
    - **RIPEMD-160**: frequently used by EU crypto service providers
    - **SHA-256**: bigger hash means probably most secure

- ![](https://i.imgur.com/qtD0Lt2.png)

- **SALTING**
    When storing password
    - generate random salt (s)
    - add it to password (p )
    - store hash(p+s) and s
    

### SSO: Single Sign On
- **Having to remember many passwords for different services is a NUISANCE**
- **only one strong password**:
    - easier for users
    - weak point: only 1 password to hack and its gg ez
- systems need balance **between convenience and security**
- ![](https://i.imgur.com/a3mF0t7.png)
- ![](https://i.imgur.com/NcZfEwH.png)

- Solution: **SSO + multi-factor auth**

### Assurance levels
**Users can be authenticated on the basis of several factors**:
- something you know (password)
- something you own (keycard)
- who you are (biometrics)

### Contextual authentication
- **consider context** when user is logging in
- login from an **unusual** place, **unusual** hour and **unusual** activity presents **high risk score** => warn user


<br>
<br>
<br>
<br>
<br>
<br>


## 4. Access Control

### Example: Operating System

- OS is a software that manages HW and SW resources 
- A multi-user OS allows for multiple users to use the same computer at the same time
    - sharing is desirable
    - protection is difficult
- A multi-tasking OS is able to allow multiple software processes to run at the same time
- OS must protect users from each other
    - user auth 
    - memory and file protection
- Different Level of protection
    - no protection (one user)
    - isolation, processes unaware of each other
    - share (all, nothing or granular)
- **Resource Encapsulation**
    - data and functions required to use the resource are packaged into a single self-contained component
    - OS controls which users can perform which operations on the resource

### Access Control

- mediates requests to resources
- Grants or Denies access to resources
- Protects resources from unauthorized access

### AC Policies

- set of rules to implement specific security properties (CIA)
- **contract** between the designer/implementor of a system and customers

### AC Structures

- **Policy**
    - rules that control what actions, subjects may perform on resources
- **Model**
    - mathematical representation of the policy
- **Enforcement**
    - functions that implement the controls imposed by the policy and formally stated in the model
    ![](https://i.imgur.com/LULKs2B.png)



![](https://i.imgur.com/5qiaCg9.png =250x)

When policy and model are defined as mathematical objects, the meaning of policies is **independent** of a particular implementation

### Example of Vulnerability - Unix finger command

- A widespread implementation would accept an argument of any length, although only 256 bytes had been allocated by the program
- when an attacker used the command with a longer argument, the trailing bytes of the argument ended up being executed by the CPU
- In 1988, large numbers of Unix computers were brought down simultaneously by the “Internet worm,”

### Access Control Matrix

- Given all subjects and objects, the ACM enumerates what actions are allowed for actions are allowed for each subject/object pair

![](https://i.imgur.com/1ihCYL1.png)

<br>

### Convert Matrix in List

##### MATRIX
![](https://i.imgur.com/SFetNEb.png =500x)

<br>

##### ACCESS CONTROL LIST (ACL)

![](https://i.imgur.com/PqpKsS9.png =410x)

<br>

##### CAPABILITY LIST

![](https://i.imgur.com/6slSyV7.png)

<br>

### AC Models - DAC (Discretionary Access Control)


- Subjects can give rights to other subjects
- Discretionary
- Owner of a resource decides how it can be shared
- No central entity deciding who can do what on which resources
- Typically used in operating systems
- Users can be put in **groups**
     - A group may appear in access control matrices or ACLs
    - Checking that a subject has a permission -> finding a group to which the user belongs with associated that permission on a given resource
    
    
**Pros**:
- Flexible
- Intuitive

**Cons**:
-  Subjective
    -  rely on owner’s judgement to modify the protection state of a resource
- Easy to lose control of the situation
    - human error
- Vulnerable to trojans


### AC Models - MAC (Mandatory Access Control)

- Users operate in an organization
- Organization decides how data should be shared
- Usually enforced by using security labels
- Multi-level security models
- Information at various sensitivity levels
- Users have various degrees of trustworthiness 
- prevent the release of sensitive information (e.g., war plans) to untrusted users (e.g., janitors)

**Pros**:
- Not vulnerable to trojans because of the No Write Down property
- Rigid

**Cons**:
- Information leakage still possible by **covert channel**


#### Multi-Level Structure

- Information labeled according to their sensitivity **label** 
- Label -> L = (S,N)
- S takes values over a linearly ordered set
    - Top Secret >= Secret >= Confidential >= Unclassified
- N is a set of **need-to-know categories** from an unordered set
    - Crypto, Nuclear, Janitorial, Personnel
- When a document contains both sensitive and non-sensitive information, the originator needs to use the highest appropriate level
- Each user is associated to a **clearance** 
- C = (S, N )
- S is a hierarchical security level
- N is a set of **need-to-know categories**

#### Multi-Level Security

- **No Read Up Property**
    - subject *s* can read resource *r* if (Ss, Ns) dominates (Sr, Nr)
    - subject clearance dominates the sensitivity label
- **No Write Down Property**
    - subject *s* can write to resource *r* if (Sr, Nr) dominates (Ss, Ns)
    - subject clearance is dominated by the sensitivity label
- **Tranquility Principle**
    - prevents the ability to change security labels arbitrarily as this can subvert security

#### Covert Channel
Vulnerability that allows information to flow from high to low levels.
User A at high level, B at low level.
B creates dummy.obj at low. If A upgrades the file's level, it can't be read by B => bit 0. If A doesn't, it can be read => bit 1.
This process can be repeated indefinitely

### AC Models - RBAC

- Permissions are assigned to roles rather than to individual users
- Users are assigned to roles rather than directly to permissions

**Pros**:
- Easy to grasp the idea of roles
- Easy to manage in principle
    - Simply assign roles to a new subject, instead of deciding on access for each resource
    - Easy to revoke authorization for a subject by removing roles
- Easy to tell through roles which permissions a subject has, and why

**Cons**:
- Role meaning is fuzzy
- Difficult to decide on the granularity of roles



#### RBAC Roles

- Groups are just collection of users
- Role is a collection of users **and** a collection of permissions
-  A user can be a member of many roles
-  Each role can have many users as members
-  A permission can be a member of many roles
-  Each role can have many associated permissions

#### RBAC Session

- A user can invoke multiple sessions
- In each session a user can invoke any subset of roles that the user is a member of
- Help implementing the Principle of least Priviledge

![](https://i.imgur.com/Bo0JD75.png =400x)

#### RBAC Separation of Duty or 4 eyes principle

- Captures conflict of interest policies to restrict authority of a single entity
- Key to fraud prevention
- A single person should not be allowed to both *approve checks* and *cash them*

### Principle of Least Privilege

Principle of least Privilege every subject (such as a process, a user, or a program) must be able to access only the information and resources that are necessary for its legitimate purpose


- User have as little privilege as possible on the server itself
- Even if commands are injected, if these are run with the lowest possible privileges, then less harm can be performed
- This seems to be an effective mitigation measure to **reduce the impact of unknown vulnerabilities**


## 5/6. Crypto
- Cryptography: how to hide secrets
- Cryptanalysis: how to break ciphers
- Cryptology: both

Cryptography used in:
1. data confidentiality (hide content)
2. data integrity (check if data has been changed)
3. entity authentication
4. data origin authentication


### Cryptosystem
**Magic 5-tuple (E, D, M, K, C)**
- E: encryption algorithm *M x K -> C*
- D: decryption algorithm *C x K -> M*
- M: set of plaintexts
- K: keys
- C: set of ciphertexts

### Kerckhoff's principle
Algorithm should NOT be SECRET
**KEYS ARE THE ONLY SECRET**

### Essentials
The security of the cryptosystem often **depends on keeping the key secret** to some parties.
Concepts:
- **Key management**: generate, store, share/DELIVER etc
- **keyspace**: all possible keys
- **entropy**: variance in keys (bits)

### Key delivery
A and B want to communicate. 4 options:
- A sends key to B
- C selects key and sends to A and B
- A sends key to B using previous key as encryption
- A sends key through secure C and C secure to B

### "Computationally secure"
When the ciphertext generated meets at least one of:
- cost of breaking > data value
- time of breaking > data lifetime

Estimate time using brute-force approach (trying every possible key)

### Moving problems
Communication security => key management => computer security (access control)

### Encryption
- substitution: replace each byte/letter/block with a fixed one (A->M, B->N, ...)
	- Caesar cipher aka ROTk
	Rotate the alphabet by K (key):
    Every char is replaced with the char that is K slots next in the alphabet
- transposition: move byte/letter/block:
	- Columnar cipher
	    HOW?
**Most encryption systems use multiple stages of both**

### New Encryption
- uses blocks of bits instead of chars
- symmetric or asymmetric key encryption

#### Symmetric
- same key on every host interested
  ![](https://i.imgur.com/xyvxuUd.png)

- **Management of keys determines who has access to encrypted data**
- **stream ciphers**: encrypt bit by bit, example **XOR**
- **block ciphers**: 64/128 bits

##### Stream Cipher
encrypt sequences of Short data blocks under a **changing key stream**:
- can rely on simple bitwise operations (XOR)
- typical block of 1 bit
- same bit will encrypt to different bit depending on the bit of the key
- faster than block because it can be implemented in hardware

##### Block Cipher
Breaks the message M in blocks M1, M2, ... and encrypts each block with the same Key

###### DES, Data Enctiption Standard 

- Feistel algorithm
- Built for fast hardware and slow software
- key always of 56 bits and blocks of 64
- Easy to break with brute force, searching for the key with specialized hardware


###### AES, Advanced Encryption Standard

- Official sucessor of DES
- Rijndael algorithm
- Variable Key and blocks length
- Much more secure

#### Asymmetric aka PKC, Public Key Criptography

- Comunication on non-secure channels 
- **No need to share secret**
- based on One-way functions (usually prime multiplication)
- 2 differentkey mathematically related, impossible to determine one from the other
    - 1 key to decode and the other to encode 
    - order is not important but you need both
    - one key is set to be the public key (widely known) the other is private

HOW IT WORKS
- Alice encrypts some information using Bob's public key
- Bob decrypts the ciphertext using his private key
Can also prove who sent a message:
- Alice could encrypt some plaintext with her private key
- When Bob decrypts using Alice's public key, he knows that Alice sent the message

PKC and **DIGITAL SIGNATURE** gives:
- authentication: confirm it was sent by Alice
- non-repudiation: Alice can't deny having sent it
- integrity: message was not modified

Examples:
- **RSA**:
	- can be used for anything
	- only problem is how to generate good and random keys
	- provides auth
	- How:
		- Alice and Bob have public and private keys
		- encrypt with other's public and own private
		- decrypt with own private and other's public
- **Diffie-Hellman**: 
	- used **for secret key exchange only**
	- does not provide auth
	- vulnerable to Man-In-The-Middle attacks
	- How:
		- Alice and Bob generate private keys (a, b)
		- Alice generate public key A = g^a mod p
		- Alice send A, g, p
		- Bob gen pub key B = g^b mod p
		- Bob send B
		- Alice K = B^a mod N
		- Bob K = A^b mod N
		- They now have same K

<br>

![](https://i.imgur.com/18TPMUA.png)

<br>

### Pros and Cons of PKC
Pros:
- private keys are safe
- confidentiality, integrity, non-repudiation

Cons:
- slower than symmetric key
- how to share public key?
- therefore, how to make sure she is Alice?

### Birthday attack on signatures
1. prepare 2 programs A, B, with same hash
2. send A to Bob, he signs and sends back signed program
3. now compute signature and use it for B instead

Fix: make hash really big => hard to find collisions

### Digital certificates and TTP
- cannot trust signatures by themselves
- Digital Certificate => certifies binding between pub-key and entity (person, hardware, etc)
- are released by a TTP: Trusted Third Party

### PKI
**Public Key Infrastructure** is an **arrangement that binds public keys with respective identities of entities** (like people or organizations)

System used by TTP for validating.
Components:
- CA: Certificate Authority (authorizes sub-CAs)
	- subordinate CA: hands out certificates
- RA: Registration Authority (verifies certificates)
- CPS: Cryptographic Practices Statement (how good security is)
- CRL: Certificate Revocation List (revoked certificates)


### SSL/TLS
Secure Socket Layer
and
Transport Layer Security (new version of SSL)
- certificates secure connection
- ![](https://i.imgur.com/0pVLx71.png)
- used by **HTTPS**

TLS (**HOW IT WORKS ON PDF**):
- handshake protocol:
	- decide algoz and version
	- authenticate both parties (optional)
	- use PKC to establish symmetric key

- record protocol: use secret symmetric key to communicate

### SSL/TLS Authentication, Confidentiality, Integrity
- Authentication: during handshake, data gets encrypted using other's public key
- Confidentiality: uses shared secret key => secure
- Integrity: use hash on every message
![](https://i.imgur.com/roHYtxx.png)
![](https://i.imgur.com/GbUdWcy.png)


### TLS Vulnerabilities
- 3-shake: hacker sends "finished" using same MasterSecret as others. "Now the two sessions can be mistaken (same “finished” message)"
- Sweet32: using 3DES cypher (32 bit hash), possible Birthday attack. 3DES removed in v1.3
- CRIME: when using DEFLATE compression. Deflate removed in v1.3

<br>
<br>
<br>
<br>
<br>
<br>

## 7. WEB SECURITY
- how can server trust client?
- ssl/tls is secure tunnel, but is content secure?

### Client certificates
- Visa/Mastercard SET to certify each card individually

### Why web security
![](https://i.imgur.com/9RLAk9W.png)

### Cookies
![](https://i.imgur.com/ZvkE8pK.png)
![](https://i.imgur.com/cdAWqPo.png)

### Definition
- Web application security is a branch of information security that deals specifically with security of websites, web applications and web services.
    At a high level, web application security draws on the principles of application security but applies them specifically to internet and web systems
- Application security encompasses measures taken to improve the security of an application often by finding, fixing and preventing security vulnerabilities

### Attackers
- Web attacker
    - Controls site “attacker.com”
    - Can obtain SSL/TLS certificate for “attacker.com”
    - User visits “attacker.com” or runs attacker’s app, etc.
- Network attacker
    - Passive: Wireless eavesdropper
    - Active: Evil router, DNS poisoning
- Malware attacker
    - Attacker escapes browser isolation mechanisms and run separately under control of OS

### Injection attack
- goal: execute malicious code on server
- Examples:
    - exploit "eval" statements and missing input sanitization (php, js, ..)
    - exploit "mail" in php
    - SQL injection: trick SQL interpreter by escaping chars
- FIX: **SANITIZE INPUT** (ex: use prepared statements / escape chars)

### XSS attacks
**Cross Site Scripting**.............
- inject malicious scripts (js) in web server
- fix: never trust user input: disallow \<script> and check/escape special chars
- difficult to prevent: need to carefully check inputs

### Phishing attacks
- send malicious link and jebait users to click it
- can get credentials and redirect and login to legitimate site
- counter-measures:
    - certificates: not perfect, usually only verify domain property, slow to obtain
    - legitimate website monitor activity (someone copying the website or weird transactions)
    - browsers having a list of phishing/suspected sites and warn users
- **none effective**:
    - people ignore certificate/browser warning
    - people can't tell / don't read fake emails


<br>
<br>
<br>


## Blockchain
- linked list of records (ex: of transactions)
- links are hashes
- distributed
- new blocks need to be validated
    - cryptomining: need proof-of-work (computational power)
    - miners solve problem, attach new block, get reward (crypto coin)
- **COINHIVE**
    - js library for websites: use users to mine Monero
    - alternative source of income (less ads)
    - malicious agents inject it everywhere (websites, apps, extensions, ads, etc...) aka **CRYPTOJACKING**
    - fix: disable extensions, use ad-blocker, antivirus, browser settings that block mining

<br>
<br>
<br>
<br>
<br>
<br>

## 8. AUTHENTICATION II

### SSO in Depth

- Multiple systems = multiple sign-on 
    - Burden for administrations and user
    - more security domain = even for sign-on
- Single Sign-on
    - Less time spent re-entering password
    - Less IT costs (low help desk for forgotten passwords)
    - More password - user combinations
    - More complex passwords
    - Shared sessions
    - Only a password to remember
    - But less security, one password for everything


#### SSO Types:

- **Pseudo-SSO**
    - separate auth to each service.
    - client software manages credentials
    - login hidden from user
- **Proxy-based SSO**
    - pseudo-SSO but implemented in a proxy
    - proxy manages user credentials
    - login hidden
- **True SSO**
    - User auth to a one auth service
    - This auth service asserts user identity to other services
- **Federated SSO**
    - auth between administrative domains


<br>
<br>
<br>
<br>


### SAML: Security Assertion Markup Language

- To access resources a user authenticate with his **Identity Provider**. 
- One Identity Provider grants access to resources of many Service Providers.
- Strong trust relationship with Identity Provider
- Loose trust relationship with Service Provider


![](https://i.imgur.com/At8bNIR.png =300x)


#### SAML
Definition of mechanism and formats for the communication of identity information between identity and service providers.

- It is a flexible protocol that can be customized  if necessary.
- It's a XML-based framework for communicating
- It must be used if there is a trust relationship between asserting and    relying parties.
- To gain trust we need to exchange metadata using cryptographic mechanism but 
    - This security framework is not part of SAML

#### Advantages of SAML

- **Platform Neutrality**
    - Security is more indipandent (external framework)
- **Loose coupling of directories**
    - User informations are not synchronized or maintaied between directories
- **Improved online experience for end users**
    - Single Sign-On
    - Users authenticate to an Identity Provider and the access many Service Providers.
- **Reduce administrative costs and risks for service providers**
    - Reduce the cost of maintaining account informations
    - Identity Provider keep track of users

#### Goals

- Creation of trusted security statements
    - Bill authenticated using a password -> Bill has access to X
- Exchange of security statements
    - SSO
    - Bill authenticated -> he does not have to be authenticated again
- SAML **does not** perform auth
- SAML **does not** grant access to resource X

<br>

![](https://i.imgur.com/UBy7mbT.png =600x)

<br>

![](https://i.imgur.com/FgLuS5x.png =500x)

<br>

#### SAML ASSERTIONS


Package of information supplying one or more statements made by a SAML authority. There are 3 kinds of assertions statements.

- **Authentication**
    - Subject was auth in some way
    - Typically generated by the Identity Provider
- **Attribute**
    - Subject is associated with the supplied attributes
- **Authorization Decision**
    - A request to allow a subject to access a resource has been granted or denied

#### SAML PROTOCOLS

- Request from a SAML authority
    - one or more assertions
- Request that an Identity provider authenticate a principal and return assertion
- Request that a name identifier be registered
- request that the use of identifier be terminated
- request of *single logout*
    - near-simultaneous logout of related sessions


#### **SAML BINDINGS**

- Mapping SAML request/response into standard messaging
    - HTTP Redirect binding

#### SAML PROFILES

- Define constraints and extensions of SAML for applications
- More interoperability with less flexibility
    - i.g. WEB Browser SSO Profile specifies how assertions are communicated between an identity provider and service provider to enable SSO

WEB BROWSER SSO PROFILE:
- Widely use
- Browser auth at asserting party and request access to relying party
- site 1(asserting party) creates a protocol message containing an auth statement, **artifact**
- site 2 (relying party) pulls the protocol message from site 1

![](https://i.imgur.com/Cz3vL1q.png =350x)


#### SAML METADATA

- Defines how to express configuration and trust-related data
    - Identify actors involved. Identity Provider, Service Provider Requester etc
- THe data that must be agreed on between system entities
    - supported roles
    - identifiers
    - URLs
    - certificate and keys
    - supported profiles

#### SAML CONTEXT

- Additional information in determining confidence within an assertion
- Additional information pertaining to the auth of the Principal at the Identity Provider
    - for example details of multi-factor auth

<br>

![](https://i.imgur.com/NDx4Nn2.png =600x)


#### SAML SECURITY

- Providing assertions may not ensure a secure system
    - How relying party trust what is being asserted to it
- SAML defines a number of security mechanism 
- Relying party and asserting party should have a pre-existing trust relationship
    - generally implemented using Public Key Infrastructure (**PKI**)
    - PKI is recommended but not mandatory 
- Where message integrity and confidentiality are required then **SSL/TLS is recommended**
- Requests from relying and assertion party should use a **bi-lateral auth**
    - SSL/TLS and mutual auth is recommended
- Response message containing assertions via user's web browser (POST, PUT binding) should be **digitally signed** using XML Signature to ensure integrity

#### SAML PRIVACY

- User's ability to control how their identity data is shared and used
- Inhibit actions at multiple providers from being inappropriately correlated
- **pseudonyms** between identity and service provider
    - different identity to stop inappropriate correlation between service providers
- **one-time/transient identifiers**
    - every time a user accesses a service provider with SSO from an Identity provider the service provider wont recognize him.
- **Authentication Context**
    - User authenticated at a sufficient assurance level
    - sufficient but not more than necessary 
- SAML allow the fact of a user consenting to certain operation to be expressed between providers
    - How and when is out of scope for SAML

#### Conclusion

- With SAML service providers don't have to implement Identy Management
    - Reduced administraition burden
    - More interoperability, usability, security and privacy
- SAML profiles are useful use case scenarios
    - Web SSO most adopted
- SAML is ideal starting point to build digital identity management
    - Key enablers in an increasing digital world
    - SPID - Sistema Pubblico Identità Digitale
    - eIDAS


### OAUTH

- Many cars today have a *valet key*
    - You give someone (parker) limited access to your car with a special key, while you have the regular key
- If you give your credentials to a site (Consumer/client) to do some specific actions they may lock you out
- With Outh you can grant access to your private resources on the Service Provider to another site.
- Defined only for HTTP
    - relies on TLS for securing messages
- **Not** an authentication protocol
    - Relies in authentication in several places
- User delegate to piece of software not to users
- **Not** a single protocol
    - several flows

#### OAUTH Flow

- Step 1. **Authentication**
    - user logs into a site, not part of OAUTH protocol
    - OAUTH needs the user to be auth but doesn't define how
- Step 2. **User Consent**
    - The user can decide what to share
    - A token will be created based on the user decisions
- Step 3. **Get OAUTH Token**
    - the third party app receive the bearer token from the social site
    - the token define access rights
    - the app can use the token to access user's resources
    - a token is the same as the valet key
    - Token is opaque to the client
    - Token doesn't have a strictly format
- Step 4. **Access Resources**
    - the app can now access resources on the resource server

#### OAUTH ENTITIES

- **Resource Owner**
    - Usually a person
    - Can access resources
    - can grant access to resources
- **Protected Source**
    - Service provider
    - Protect resource
    - Share resource on owner request
- **Client, APP**
    - Wish to access owner resources
    - needs permission
- **Authorization Server**
    - Generates token
    - Manages authorization

![](https://i.imgur.com/MVxdsZJ.png)
![](https://i.imgur.com/RFniC8y.png)
![](https://i.imgur.com/LLvVrW9.png)


#### More on Tokens

- The token may stop working
    - Expiration
    - Revocation
- Getting a new token
    - repeat the process from the start
- If the owner is not there - Refresh Token
    - Issued alongside the access token
    - Presented along client credentials 
    - Used for getting new access token
- Token is bound to a scope
    - Client can ask for scopes
    - Owner accept scope

#### Security

- Authorization code flow (web app)
    - short-lived access tokens
    - long lived refresh tokens
- Implicit flow (in-browser app)
    - no refresh tokens 
    - when a token dies repeat process
- Resource owner Password (trusted legacy client)
    - Client impersonating resource owner
    - high risk of phishing 
- Client credentials (no user)
    - no refresh tokens, useless
    - with client credentials can ask for another token
    - resource not owned by any user

### ABAC

- DAC and MAC 
    - difficult to manage lots of users
    - low scalability
- RBAC
    - Roles may be not enough to express authN conditions
- ABAC 
    - each resource has an attribute (e.g. creator)
    - each user has attributes
    - single rule to state ownership
    - Flexibility and expressive power
    - Can combine different pattern of auth
    - possibility to have auth conditions dependent of the environment attributes

<br>

![](https://i.imgur.com/MyH70he.png)

<br>

#### ABAC Model
- Subjects are associated with attributes
- Objects are associated with attributes
- Environment conditions are associated with attributes
- Authorization is expressed as conditions on these attributes 

#### ABAC Policy

- Set of rules that govern allowable behavior within an organization
- Based on the privileges of subjects
- **Typically written from the perspective of the object that needs protecting**
- Privileges available to subjects
    - Privileges represent the authorized behavior of a subject and are defined by an authority and embodied in a policy

Example:
- MPEG adult movies can only be downloaded by users whose age is greater than 18
    - Authorization does not refer to specific user
    - MPEG movies have an attribute that denotes their type (adult movies)

#### Subject

- Entity that causes information to flow among objects or changes the system state
- Attributes define the subject 
    - name 
    - org
    - title
    - job
    - ...

#### Object/Resource

-  Passive information system-related entity containing or receiving information
-  Objects have attributes to make access control decision
    -  Title
    -  Author
    -  Date
    -  ...

#### Environment Attributes

- Context in which the information access occurs
    - Current time
    - Network security level
    - Anything not related to subjects and resources


### XACML
eXtensible Access Control Markup Language
- **A language for ABAC**
- XML encoded
- Specify access control
    - policies
    - requests
    - decisions
- OASIS Standard
- **Standardized** approach to authorization 
    - Authorization rules no more embedded in the SW of individual system
- **Externalized** approach to authorization
    - PDP offers authorization as a service in the infrastructure
    - Authorization algorithms can be removed from the application
-  An **attribute and policy based** approach to authorization
    -  XACML policies introduce abstract logic to replace previous static assignments of user permissions
    -  Instead of “Bob can access document X” ->  “any user belonging to company Y with security clearance equal to security classification of the document can access X”
        -  security clearance, document classification are needs to be gathered
        - These descriptive pieces of information are called **attributes**


#### XACML Architecture

- **Policy Information Point** (**PIP**)
    - serves as the source of attribute values, or the data required for policy evaluation.

- **Policy Enforcement Point** (**PEP**)
    - Entity protecting resource
    - Performs access control by making decision requests 
    - Enforce authorization decisions

- **Policy Decision Point** (**PDP**)
    - Receives and examines requests
    - Retrieves policies
    - Evaluates policies
    - Returns the authorization decision to PEP

-  **Policy Administration Point** (**PAP**)
      -  creates policies
      -  store policies

- **Context Handler**
    - Converts request to XACML
    - Converts Authorization to XACML


#### XACML Components

- **Policy Language**
    - Specify access control rules
    - Algorithm for combining policies

- **Request/Response Protocol**
    - Evaluates user access requests against policies

- **Reference Architecture**
    - deployment of software modules
    - house policies and attributes 
    - compute and enforce access control decisions

#### XACML Vocabulary
- **Resource**
    - Data or system component needing protection

- **Subject**
    - An actor who requests access to specific resources

- **Action**
    - An operation on a resource

- **Environment**
    - Properties not belonging to the resource, subject, or action that are important for the authorization decision

- **Attributes**
    - Characteristics of the resource, subject, action, or the environment

- **Target**
    - Defines conditions that determine whether policy applies to the request


#### XACML Requests

- Request consist on
    - Subject Attributes
    - Resource Attributes
    - Action Attributes
    - Environment Attributes
- Attributes are name-value pair
    - Role = "Doctor"
    - Obj = "Medical Record"
    - ... 
- Attributes are stored in **Policy Information Point**, (**PIP**)


#### XACML Policies

- Smallest unit of evaluation
- Structured as policySets
    - every set has many policies
    - one set inside another
- Policies are composed of rules
- Target define a Boolean condition
    - true -> request gets evaluated by a **PDP**
    - false -> decision not applicable
- target minimize sets that must be examined


#### XACML Rules

Look at Examples at slide 9

- set of boolean condition
    - true
    - false
    - indeterminate
- Policy can have multiple rules 
    - Rules can be combining using algorithms
    - 12 different algorithms
- Rules can be separately evaluated but cant exist outside of policies 
    - Policies are the smallest unit of evaluation



#### Combining Algorithms

- **Deny Overrides**
    - AND operation to permit
- **Permit Overrides**
    - OR operation to permit
- **First Applicable**
    - Result is the result of first decision
- **Only one Applicable**
    - if many decisions apply result is indeterminate
    

#### XACML Obligation 

- What to do when an access request is denied or accepted
    - access denied -> mail for tried attempt
    
#### Administration

- Determines how policies can be created and modified
- Decentralized policy administration
- A policy may contain a "PolicyIssuer" element that describes the source of the policy
    - Absence of "PolicyIssuer" implies that the policy is trusted


<br>
<br>
<br>
<br>
<br>
<br>
<br>

## 10. Privacy

- Informational self-determination
    - control information about self
- difficulty in **correlating** data - actions
    - hope to remain anonymous

### Data Anonymization

- Remove **Personally Identifying Information** (**PII**)
    - PII has no technical meaning
    - in privacy breaches everything is PII

### Linkage Attack

- **Quasi-identifiers** are pieces of information that are not unique but combined with other are unique
- Publishing a record with a quasi-identifier is as bad as publishing it with an explicit identity
- Eliminating quasi-identifiers is not desirable


### k-anonymity
    
- you try to identify a man in the released table, but the only information you have is his birth date and gender
- there are k men in the table with the same birth date and gender.
- Any quasi-identifier present in the released table must appear in at least k records
- **Generalization**
  - Replace quasi-identifiers with less specific but semantically consistent values until get k identical
      - Age: 29, 22, 21 -> 2*            
- **Suppression**
    - When generalization causes too much information loss
- Weak to Homogeneity Attack
    - group of k lack diversity
- Weak to Background Knowledge

### LINDDUN

### Linkability

- Distinguish whether 2 items of interest (ioi) are linked or not, even without knowing the actual identity of the subject 
- Cause **identifiability**
    - too much linkable information is 
- Cause **Inference**
    -  if an insurance company knows that people who live in a certain area get sick more often, they might increase their insurance cost for that target group
- Cause **Non-repudiation**
    - Not being able to deny a claim
- Cause **Detectability**
    - Being able to sufficiently distinguish whether an ioi exists or not.
- Cause **Disclosure of Information**
    - violation of confidentiality and thus more to security
- Cause **Unawareness**
    - Being unaware of the consequences of sharing information.
    - Often users are not aware of the impact of sharing data
    - The more information is available, the easier it can be linked
- Cause **Non-compliance**
    - Not being compliant with legislation,regulations, and corporate policies
    - Loss of image, credibility, etc.
    - Fines

### GDPR - Genaral Data Protection Regulation

-  The GDPR covers all EU citizens' data regardless of where the organization collecting the data is located
-  Barring businesses from storing or using an individual's personally identifiable information without consent
-  Requiring companies to notify all affected people and the supervising authority within 72 hours of a data breach


#### art4. GDPR Definitions

- **Personal Data**
    - Requiring companies to notify all affected people and the supervising authority within 72 hours of a data breach
- **Processing**
    - any operation which is performed on personal data or on sets of personal data
- **Pseudonymisation**
    - processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject 
- **Controller**
    - determines the purposes and means of the processing of personal data
- **Processor**
    - processes personal data on behalf of the controller
- **Consent**
    - indication of the data subject's wishes to the processing of personal data
- **Personal Data Breach**
    - destruction, loss, alteration, unauthorised disclosure of, or access to, personal data


#### art7. Condition for consent
- controller shall need to demonstrate user gave consent
- consent request must be clear and easy to access
- user can withdraw consent in any moment

#### art32. Security of processing
- technical and organizational measures proportional to the risk (pseudonymisation, encryption, CIA, ...)
- consider risk of processing data

#### art33.
- notify in 72h after noticing data breach unless it's unlikely to result in a risk
- don't delay on purpose
- notification must describe data breach, risks related and countermeasures users can apply

#### art34.
- when data breach poses high risk, do more stuff

#### art35. 
- when modifying stuff poses high risk, notify users


<br>
<br>
<br>

### **RISK EVALUATION**
**RISK**:
- risk = likelihood X impact of adverse event
- adverse event => vulnerability => weakness
	- attacker reduce system information assurance
	- ex: software bug that can be exploited
- stochastic model defines likelihood
- metrics defines impact
- CVSS: evaluates risk posed by vulnerability
	- 2 subscores combined
		- exploitability
		- impact

- **MEASURE**: objective attribute
	- only measures supporting selected metrics are needed
	- specify dependencies among measures in the metrics using them
	- combine measures to form a metric

- **METRIC**: abstract/subjective attribute
	- organizations should have multiple levels:
		- lower-level for tactical decisions
		- used as input to higher-level
		- higher-level for strategic decision
	- collected via automated means and analyzed and visualized
	- dependent on the accuracy of measures
		- imprecise definition
		- ambiguous terminology
		- inconsistent measurements methods


### Socio-technical system
- any system that involves interaction between humans, machines, and environmental aspects of the work system
- any system that represents social human interaction through technology
- middle ground between technology and social interactions
- **ANTHEM**:
	- biggest healthcare breach
	- lots of personal info leaked
	- victims are suffering identity thefts
	- **WHY:** data encrypted on transfer, **but not on database**



