Risk analysis ToC

• Terminology
• Risk analysis models
• Security Design Principles
• Threat modeling
• STRIDE
• Mitigating Privacy Threats
• Risk Choices
• Quantitative and Qualitative Risk Analysis
• Risk Analysis.
• NIST risk management process
• Access control defensive categories and types
• Authentication Methods
• Defense models
• Risk management life cycle
• Treating risk
• Security incident management
• Incident response process
• Data must be secure when it is
• Securing a network
• Securing a box
• Software development lifecycle
• Calculating Annualized Loss Expectancy

Terminology

• Asset is valuable resources for the business to protect.
• Threat is an action or inaction that could cause harmful occurrence to assets (accidental or deliberate).
• Threat agents intentionally exploit vulnerabilities.
• Threat events are accidental exploitations of vulnerabilities (fire, earthquake).
• Impact is the result of having a vulnerability exploited by a threat.
• Risk is the possibility that a threat will exploit a vulnerability to cause harm to an asset.
• Exposure is being susceptible to asset loss due to a threat; there is the possibility that a vulnerability can or will be exploited by a threat agent or event.
• Safeguard/countermeasure is anything that removes a vulnerability or protects against one or more specific threats.
• Attack is the exploitation of a vulnerability by a threat agent.
• Breach is the occurrence of a security mechanism being bypassed or thwarted by a threat agent.
• Vulnerability is a weakness that allows a threat to cause harm or to gain access to an asset.
• Exploit program/script used to exploit a vulnerability and compromise an asset
• Risk impact resulting from compromising an asset
• Risk =Threat * Vulnerability * Impact
• Vulnerabiliy assessment Process of finding all the vulnerabilities
• Penetration test exploit all the vulnerabilities
• Non-repudiation It means a user cannot deny (repudiate) having performed a transaction. It combines authentication and integrity: non-repudiation authenticates the identity of a user who performs a transaction, and ensures the integrity of that transaction

Risk analysis models

• CIA (Confidentiality, Integrity, Availability)
• Disclosure Alteration and Destruction (DAD) is its opposite.
• Identity and Authentication, Authorization, and Accountability
• Identity and Authentication Proving an identity claim
• Authorization Describes the actions you can perform on a system once you have identified and authenticated.
• Accountability holds users accountable for their actions. This is typically done by logging and analyzing audit data.

Security Design Principles

• (My security keeps failing during annual degree exams, lol)
• Minimize attack surface area: Remove unnecessary functionality or make it work authenticated users are possible reductions.
• Separation of duties: To control fraud; Who requests a computer can not sign having received it; I.e. administrators of a shop should not be users who can buy.
• Keep security simple: avoid double negatives and complex architectures when simple and faster approaches work.
• Fail securely: If unexpected events occur the application should make sure security can not be bypassed.
• Defense in depth: applies multiple safeguards (also called controls: measures taken to reduce risk) to protect an asset. Any one security control may fail; by deploying multiple controls, you improve the confidentiality, integrity, and availability of your data. Avoid single point of failure.
• Fix security issues correctly: Make sure the root cause is identified and the correct fix applied; Similar bugs can be across the company's products.
• Avoid security by obscurity: nearly always fails when it is the only control. Do not hardcoded passwords etc..
• Don't trust services: If you integrate with third party services you increase your attack surface and your security is as bad as theirs.
• Security by default: Enable security controls by default, require strong password but user might change it for an insecure one if they want.
• Least privilege: Users should be granted the minimum amount of access (authorization) required to do their jobs, but no more.
• Use patterns: Each bug should be fixed introducing a pattern (template approach) so that it does not happen again.
• Trust on first use (TOFU) is a security model used by client software which needs to establish a trust relationship with an unknown or not-yet-trusted endpoint. In a TOFU model, the client will try to look up the identifier, usually some kind of public key, in its local trust database. (certificate pinning, ssh fingerprints).

Threat modeling

• Think about attackers or the assets you want to protect
• What are you building? What can go wrong?
• Step 1: Decompose the application into use-cases (DFD) of how the application interacts with external entities to understand attack surface.
• Step 2: Determine and rank threats to those DFD, using STRIDE or Attack trees, etc..
• Step 3: Determine countermeasures and mitigation
• DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.
• DREAD modeling influences the thinking behind setting the risk rating, and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.
• Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5
• To understand the practical risks to a system, you might model threats by considering the following:
• Individual system components: Exploitable vulnerabilities can exist within infrastructure (e.g., hypervisors, software switches, storage nodes, and load balancers), operating systems, server software, client applications, and end users themselves
• Goals of the attacker: Data exposure or modification, Elevation of privilege, Arbitrary code execution
• Denial of service
• Exposed system components (the available attack surface) remote access / physical access
• Economic cost and feasibility of each attack vector
• Data flow diagrams, showing how data moves through the system
• Draw trust boundaries [browser] - [web server] - [db]

STRIDE

• Spoofing of user identity Fixed with authentication
• For computers IPSec, DNSSEC, TLS, SSH host keys, Kerberos authentication, HTTP Digest or Basic authentication, "Windows authentication" (NTLM), PKI systems, such as SSL or TLS with certificates
• For data: Digital signatures, Hashes.
• For people: Something you know (password), something you are (biometrics), something you have (auth key card)
• For maintaining authentication: cookies.
• Tampering Fixed with integrity
• For files: ACLs or permissions, Digital signatures, Hashes, Windows Mandatory Integrity Control (MIC) feature, Unix immutable bits
• For network traffic: SSL, SSH, IPSec, Digital signatures
• Repudiation Fixed with non-repudiation: Logging, Log analysis tools, Secured log storage, Digital signatures, Secure time stamps, Trusted third parties, Hash trees, and tools for preventing 3rd party frauds (Validation services, Proprietary data/customer history, Multi-merchant data, Purchase device tracing).
• Information disclosure Fixed with confidentiality
• For files: ACLs/permissions, Encryption, Appropriate key management
• Network data: Encryption, Appropriate key management
• Protecting communication headers or the fact of communication: Mix networks, Onion routing, Steganography
• Denial of service Fixed with availability: ACLs, Filters, Quotas (rate limiting, thresholding, throttling), High-availability design, Extra bandwidth (rate limiting, throttling), Cloud service.
• Elevation of privilege Fixed with authorization: ACLs, Group or role membership, Role based access control, Claims-based access control, Windows privileges (runas), Unix sudo, Chroot, AppArmor or other unix sandboxes,

Mitigating Privacy Threats

• Minimization Do not store it, do not send it, dispose the data, do not touch it unless you have to.
• Cryptography hashing or encrypting, split keys systems (multiple keys hold by multiple parties to decrypt), blinding (cryptography technique that allows a party to use a service without the service owner knowing about the input or output even if they have the key or are the CA (used for e-voting etc...)

Risk Choices

• Accept
• Mitigate
• Transfer (insurance)
• Avoiding the risk (not do the project or change the design)

Quantitative and Qualitative Risk Analysis

• Quantitative Risk Analysis uses hard metrics, such as dollars.
• Qualitative Risk Analysis uses simple approximate values.
• Calculating the Annualized Loss Expectancy (ALE) is an example of Quantitative

Risk Analysis.

NIST risk management process

• System Characterization
• Threat Identification
• Vulnerability Identification
• Control Analysis
• Likelihood Determination
• Impact Analysis
• Risk Determination
• Control Recommendations
• Results Documentation

Access control defensive categories and types

• Preventive
• Detective
• Corrective
• Recovery
• Deterrent ("beware of dog")
• Compensating

Authentication Methods

• Something you Know (Passwords)
• Something you Have (Synchronous Dynamic Token, Asynchronous Dynamic Token)
• Something you Are (Biometric Fairness, Psychological Comfort, and Safety, Biometric Enrollment and Throughput)

Defense models

• Lollipop model: Perimeter security, protecting the assets
• Onion model: Defense in depth, multiple layers of defenses (encryption, access control, compartmentalisation, monitoring...)
• Zones of trust: Segregating computers in different networks according to the trust (dev deparment, office, wifi...)

Risk management life cycle

• Monitor
• Identify
• Analyse
• Treat
• (repeat)

Treating risk

• Mitigate
• Accept
• Reduce
• Transfer

Security incident management

• Reporting
• Investigation
• Assessment
• Corrective action
• Employees need security training and awareness

Incident response process

• Identification of the Incident
• Logging it (Details)
• Investigation and root cause analysis (RCA)
• Escalation or keeping the senior management/parties informed
• Remediation steps
• Closure report

Data must be secure when it is

• At Rest
• in Transit
• in Use

Securing a network

• The company needs a security policy (not plugging phone to computer, password length, etc)
• Non-repudiation and accountability: users in the organization can not deny actions carried out and are responsible for those.
• Every job has different responsabilities, duties and access rights.
• Partitioning network in VLANs
• Firewall filter all ports not needed from outside
• Encrypted traffic
• Monitoring and detection (IDS, IPS) such as SNORT
• Network usage policy
• Authentication and authorization policies
• Segment the network into zones of trust and place systems into those zones based their communication needs and Internet exposure.
• Run each service in a different box (or virtual box) (db and web)
• Use a fronted proxy such as cloudflare to mitigate DDOS.

Securing a box

• Password protect the boot process before the OS loads (set is BIOS) (important for laptops)
• Password protect CMOS settings
• Disable booting from USB/CD
• Reduce the attack surface of systems by turning off unneeded services.
• Install secure software.
• Setup your IPTABLES/firewall
• Use an Antivirus Scanner (with Real-Time Scanning)
• Full disk encryption
• SSH with PKI login only, unique per machine per user.
• Configure software settings securely.
• Keep software and OS updated
• Strengthen authentication processes.
• Limit the number (and privileges) of administrators.
• Least privilege principle for daemons
• Install fail2ban and monitor daily logs
• review code running or pentest it.
• web server: security headers (X-Content-Type-Optionsno sniff, X-Frame-Options: DENY, Strict-Transport-Security Cache-Control: no-cache, no-store)
• Remove versions from banners (security by obscurity)
• SELinux with enforcing poly, restricts how apps can interact with kernel, for example file system objects are identified by path name rather tha inode, to prevent symlink attacks to files that would not normally be accessabke
• Disable USB usage
• Lock screen

Software development lifecycle

• Use of certified products and systems
• Code review, vuln assessment, continuous testing methodologies
• Separation of development and live systems
• Use of escrow to reduce risks of loss of source code

Calculating Annualized Loss Expectancy

• Annualized Loss Expectancy (ALE) calculation allows you to determine the
• annual cost of a loss due to a risk. Once calculated, ALE allows you to make
• informed decisions to mitigate the risk.
• Asset value (AV) is the value of the asset you are trying to protect. In this
• example, each laptop costs $2500
• The Exposure Factor (EF) is the percentage of value an asset lost due to an incident.
• In the case of a stolen laptop with unencrypted PII, the Exposure Factor is
• 100%:
• The Single Loss Expectancy (SLE) is the cost of a single loss. SLE is the Asset
• Value (AV) times the Exposure Factor (EF). In our case, SLE is $25,000 (Asset
• Value) times 100% (Exposure Factor), or $25,000.
• The Annual Rate of Occurrence (ARO) is the number of losses you suffer per year.
• Looking through past events, you discover that you have suffered 11 lost or stolen
• laptops per year on average. Your ARO is 11.
• The Annualized Loss Expectancy (ALE) is your yearly cost due to a risk. It is calculated
• by multiplying the Single Loss Expectancy (SLE) times the Annual Rate of
• Occurrence (ARO). In our case, it is $25,000 (SLE) times 11 (ARO), or $275,000.
• The Total Cost of Ownership (TCO) is the total cost of a mitigating safeguard.
• Return on Investment (ROI) is the amount of money saved by implementing a
• safeguard. If your annual Total Cost of Ownership (TCO) is less than your Annualized
• Loss Expectancy (ALE), you have a positive ROI (and have made a good
• choice). If the TCO is higher than your ALE, you have made a poor choice