is valuable resources for the business to protect.
is an action or inaction that could cause harmful occurrence to assets (accidental or deliberate).
intentionally exploit vulnerabilities.
are accidental exploitations of vulnerabilities (fire, earthquake).
is the result of having a vulnerability exploited by a threat.
is the possibility that a threat will exploit a vulnerability to cause harm to an asset.
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.
is anything that removes a vulnerability or protects against one or more specific threats.
is the exploitation of a vulnerability by a threat agent.
is the occurrence of a security mechanism being bypassed or thwarted by a threat agent.
is a weakness that allows a threat to cause harm or to gain access to an asset.
program/script used to exploit a vulnerability and compromise an asset
impact resulting from compromising an asset
Risk =Threat * Vulnerability * Impact
Process of finding all the vulnerabilities
exploit all the vulnerabilities
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
Describes the actions you can perform on a system once you have identified and authenticated.
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.
: 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.
: Users should be granted the minimum amount of access (authorization) required to do their jobs, but no more.
: 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).
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]
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.
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
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).
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
Do not store it, do not send it, dispose the data, do not touch it unless you have to.
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...)
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
NIST risk management process
Access control defensive categories and types
Deterrent ("beware of dog")
(Synchronous Dynamic Token, Asynchronous Dynamic Token)
(Biometric Fairness, Psychological Comfort, and Safety, Biometric Enrollment and Throughput)
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
Security incident management
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
Data must be secure when it is
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
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
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
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
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.
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.
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.
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