297 lines
11 KiB
Markdown
297 lines
11 KiB
Markdown
#public
|
|
# Malware/malicious software
|
|
- **Malware**: software written with intent to do HARM
|
|
```mermaid
|
|
flowchart TD
|
|
A[Data] <---> B[People]
|
|
A <---> C[Devices]
|
|
B <---> C
|
|
```
|
|
> Greatest Vulnerability is People
|
|
## Malware types
|
|
- **virus:** program to modify other programs
|
|
- **Worm**: program that spreads itself
|
|
> diff b/t virus and worm is method of movement
|
|
- **Trojan**: an innocent program that hides malware inside
|
|
- **Ransomware**: require payment to remove (often in exchange for decryption key)
|
|
- **Phishing**: Faking identity in order to build trust to encourage specific user behavior
|
|
- **DOS/DDOS**: (distributed) denial of service to overwhelm services and prevent legitimate activity from getting through
|
|
|
|
# Threat Actors
|
|
| Group | Motivations |
|
|
| ---------------- | -------------------------------------------------------- |
|
|
| Nation States | Intelligence Infrastructure |
|
|
| Groups of people | Intimidate, org-goals |
|
|
| Individuals | ego, \$\$\$, etc |
|
|
| Insider Threats | Those inside of an organization who abuse trusted access |
|
|
>Insider Threats are the Greatest challenge in cyber-sec
|
|
|
|
> There is an upward trend in the amount of malware and damage done in USD. 5 month avg for identifying breaches
|
|
|
|
# CIA TRIAD
|
|
```mermaid
|
|
flowchart TD
|
|
A[Confidentiality] <---> B[Integrity]
|
|
A <---> C[Accessibility]
|
|
B <---> C
|
|
````
|
|
True security manages all 3, our job is to find the right balance
|
|
## CONFIDENTIALITY
|
|
Ensuring that only authorized users can access data
|
|
### 3 Types of confidentiality
|
|
| type | definition | exampe | |
|
|
| --------------- | -------------------------------------------------------------------------- | ------------------------- | --- |
|
|
| Confidentiality | limiting access to information including the existence of such information | "What conversation" | |
|
|
| Privacy | Limit the information shared | Not giving away PII | |
|
|
| Secrecy | Data not to be shared beyond small circle | Restricting access to PII | |
|
|
- **PII**: personally identifiable information
|
|
## INTEGRITY
|
|
Ensure data and system resources are trustworthy
|
|
Trustworthy: known author, not maliciously modified
|
|
|
|
| Catagory | definition |
|
|
| --- | --- |
|
|
| Data integrity | Data has not been modified or overwritten |
|
|
| Origin Integrity | maintaining the authorship and chain of editors |
|
|
| System integrity | overall design of processes that work with data |
|
|
> While confidentiality is often considered the "Traditional" focus of security, Integrity can be considred just as important
|
|
## AVAILABILITY
|
|
Authorized users can access data and systems when needed.
|
|
Confilicts directly with Confidentiality, this balance is our job.
|
|
DDOS/DOS attacks affect availibility.
|
|
> "If one person can have access, many have access"
|
|
|
|
# What is security?
|
|
> Just fire-walling/encrypting your system $\neq$ security
|
|
|
|
**Security is a systems issue**, good security is a heuristic endeavor encompassing the following questions:
|
|
1. What are we protecting?
|
|
2. What can go wrong?
|
|
3. What are we going to do about it?
|
|
4. Did we do a good job?
|
|
|
|
You need to deal with policy and procedure. E.G. talking to non-tech savvy people or encouraging more scrutiny of strange emails
|
|
|
|
- **Forensics:** determine what was done when
|
|
```mermaid
|
|
mindmap
|
|
id))system((
|
|
id(Hardware(
|
|
id(Software(
|
|
id)networking(
|
|
|
|
```
|
|
# The Five As
|
|
| [[Malware#Authentication]] | Verification of a user's Identity | static password |
|
|
| ------------------------ | -------------------------------------------- | ------------------------- |
|
|
| Access control | control who is allowed access to something | ACT card |
|
|
| [[Malware#Accounting]] | keeping track of activity | logs of command history |
|
|
| [[Malware#Auditing]] | checking for suspicious behavior or failures | log analysis |
|
|
| Action | taking action on a threat | changing a users password |
|
|
|
|
|
|
## Authentication
|
|
> How do we know who you say you are? j do we know you're authorized?
|
|
### 3 mechanism of authentication:
|
|
| something you **know** | Static username and passwd |
|
|
| ---------------------- | -------------------------------------------------------------------- |
|
|
| something you **have** | one time password (OTP) --> usually **2nd device** as authentication |
|
|
| something you **are** | Biometric credential |
|
|
|
|
## Accounting
|
|
- cant have $\infty$ storage, so what do you keep?
|
|
## Auditing
|
|
You need to know your system is compromised if you're taksed to protect it.
|
|
"Did something happen?"
|
|
This is looking at logs created and making policies to take action of some kind
|
|
you also need to determine the action to take
|
|
# measures and countermeasures
|
|
| prevention | measures to **stop breaches** | Gaurd at the gate, strong authentication policy | |
|
|
| ---------- | --------------------------------- | ----------------------------------------------- | --- |
|
|
| detection | measures to **detect breaches** | beggining, ongoing, or afterwords | |
|
|
| Reaction | measures to **recover of assets** | Rebuild, Repair, Pursue | |
|
|
|
|
```mermaid
|
|
flowchart TB
|
|
id1[Passwords are easy to guess] --> id2[Password policies] --> id3[Users write down passwds] --> id4[etc]
|
|
|
|
```
|
|
# Insider threats
|
|
- **Threat**: An event of condition that has the potential to cause loss or undesirable consequences
|
|
- **Insider Threat**: threat caused by someone inside of the organization
|
|
- Disgruntled employee
|
|
- Careless employee
|
|
|
|
| |IT sabatoge| Theft of IP | Fraud | Espionage |
|
|
| --- | --- | --- | --- | --- |
|
|
| WHO | techinal/priveleged access | scientists, programmers, engineers, sales | fincacial pros, low/mid developers, customer service | anybody |
|
|
| WHEN | on/before termination | ~60 days b4 leaving | Long period of time | long period of time |
|
|
| WHY | revenge | new job, start company | Greed, financial need | dissatisfaction, greed, financial need |
|
|
|
|
## Identifying Insider Threats:
|
|
- Who has the most access?
|
|
> Don't assume sysadmin is the villan, just be aware of their access level
|
|
- become the insider. "Think like the attacker"
|
|
- most employees dont join to become insiders
|
|
## Lifecycle of an insider
|
|
1. Recruitment/tipping point
|
|
2. Search/Reconnisance
|
|
3. Acquisition/collection
|
|
4. Exfiltration/Action
|
|
|
|
# Threat Modeling
|
|
> The equifax breach exploited a known vulnerability that equifax didn't patch for months. $1.4 Billion in damages
|
|
## The fundamental security problem
|
|
There are more attacks than can be reasonably stopped with limited time/money
|
|
## Why threat model
|
|
- Proactive vs Reactive
|
|
- Prioritization
|
|
- Systematic approach
|
|
- Find problem's you'd otherwise miss
|
|
- Legal compliance
|
|
## The cost of a vulnerability
|
|
![[Diagram 2.svg]]
|
|
## What is threat modeling?
|
|
A structured process to identify, quantify, and address security risks in a system or process
|
|
## Key Questions
|
|
1. What are we protecting
|
|
2. What can go wrong
|
|
3. What are we going to do about it
|
|
4. did we do a good job
|
|
## Steps
|
|
### 1. define scopes and assets
|
|
### 2. Create architecture diagram
|
|
- Data flow
|
|
- Network diagram
|
|
- Component diagram
|
|
- Trust breakdown diagram
|
|
### 3. Identify threats
|
|
| S | spoofing Identity |
|
|
| --- | --- |
|
|
| T | Tampering with data |
|
|
| R | Repudation |
|
|
| I | Information disclosure |
|
|
| D | Denial of servie |
|
|
| E | Escalation of privelege |
|
|
> [[Malware#CIA Triad]]
|
|
|
|
### 4. Rank and prioritize threats
|
|
|
|
#### DREAD
|
|
on a scale of 1 - 10
|
|
Risk = (D+R+E+A+D)/5
|
|
|
|
| D | Damage potential |
|
|
| --- | --- |
|
|
| R | Reproducability |
|
|
| E | Exploitability |
|
|
| A | Affected Users |
|
|
| D | Discoverability |
|
|
|
|
Ex: Mybama SQLI
|
|
|
|
| D | 10 |
|
|
| --- | --- |
|
|
| R | 10 |
|
|
| E | 7 |
|
|
| A | 10 |
|
|
| D | 8 |
|
|
R 9 = (10 + 10 + 7 + 10 + 8) / 5
|
|
9 is a **Critical threat**
|
|
#### Impact/likelyhood table
|
|
|
|
| likelyhood | low | med | high |
|
|
| ---------- | --- | --- | ---- |
|
|
| low | 1 | 2 | 3 |
|
|
| med | 2 | 4 | 6 |
|
|
| high | 3 | 6 | 9 |
|
|
|
|
| < 3 | < 6 | 9 |
|
|
| --- | --- |---|
|
|
| low, fix when possible | Vulnerable. Fix ASAP | HUGE PROBLEM |
|
|
|
|
### 5. Determine Mitigation
|
|
1. **Eliminate**: remove the vuln --> unused admin page
|
|
2. **Mitigate**: Reduce likelihood of attack --> Sanitize SQL inputs
|
|
3. **Transfer**: Move to somewhere else --> send it to your SSO
|
|
4. **Accept**: It's good enough --> password logins (using microsoft)
|
|
|
|
## Why it works:
|
|
1. Systematic, not random
|
|
2. Visual
|
|
3. Collaborative
|
|
4. Proactive
|
|
5. Prioritized
|
|
6. Documented
|
|
|
|
# Encryption
|
|
## Symmetric V. Asymmetric
|
|
- **Symmetric encryption**: Uses a single key
|
|
- **Asymmetric encryption**: Uses two keys
|
|
|
|
```mermaid
|
|
stateDiagram-v2
|
|
|
|
state symmetric{
|
|
plaintext
|
|
}
|
|
state asymmetric{
|
|
text
|
|
key
|
|
}
|
|
text --> encryption
|
|
key --> encryption
|
|
encryption --> cyphertext
|
|
plaintext --> encryption
|
|
cyphertext --> decryption
|
|
decryption --> Plaintext
|
|
|
|
```
|
|
### Asymmetric key encryption
|
|
> Asymmetric has 2 keys and is more computationally expensive
|
|
|
|
takes 2 keys, and runs the encryption algo on the combined input
|
|
1 is the private key, one is the public
|
|
how do you securely send the keys?
|
|
### Symmetric key encryption
|
|
Cheaper, older and more common
|
|
> Block cipher
|
|
- **DES**: Data Encryption Standard
|
|
- Oldest standard
|
|
- originally labbeled by NIST
|
|
- **AES**: Advanced Encryption Standard
|
|
- updated DES, more computationally signifigant for modern computing
|
|
- **3DES**: 3 Data Encryption Standard
|
|
- does DES 3 times
|
|
- **TLS**: Transport Layer security
|
|
- for high level web traffic
|
|
- **SSL**: Secure Socket layer
|
|
- for secure communication between machine
|
|
## Feistel block cipher
|
|
Takes initial input, splits in half, encrypts left half, and switches. Repeats
|
|
The key is used in encryption through a reversable algorithm.
|
|
![[Pasted image 20260217083518.png]]
|
|
|
|
## Diffie Heiman Key exchange
|
|
Symmetric means you have to pass around the key,
|
|
Asymmetric is computationally expensive
|
|
Diffie-Heiman is a solution
|
|
1. Publish your public key
|
|
2. Send hash function with any work you then publish
|
|
3. Your public key can be used to verify integrety of any published work
|
|
3a. verifying file downloads
|
|
3b. git commits
|
|
You can aslo force 1-way encryption with a block cipher so:
|
|
data --> hash
|
|
but not:
|
|
hash --> data
|
|
any slight change of input, dramatically changes output (Avalance effect)
|
|
> since encryption methods take any size and hash it to a fixed size, collisions are possible. Furthermore, Collisions are going to be vastly different inputs
|
|
|
|
## Hash functions
|
|
- Md5
|
|
- Sha1
|
|
- Sha3
|
|
- Sha256
|
|
- RSA
|