---
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


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

- 

- **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**
- 
- 

- 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


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


<br>

### Convert Matrix in List

##### MATRIX

<br>

##### ACCESS CONTROL LIST (ACL)


<br>

##### CAPABILITY LIST


<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


#### 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

- **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>


<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
- 
- 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

### 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

### Cookies

### 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


#### 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>


<br>


<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


#### 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>


#### 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


#### 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>


<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**