Tidy up
This commit is contained in:
103 files changed
+3663
-3779
No files matched your search
@@ -14,20 +14,20 @@ Assets could be physical or virtual data
|
||||
|
||||
- Historically systems have been built to serve single users
|
||||
- Often only a few highly trusted users were permitted to access a system
|
||||
- This makes mistakes made by trusted users still a concern
|
||||
- This makes mistakes made by trusted users still a concern
|
||||
- Current multi-user systems have completely different security concerns
|
||||
|
||||
##### Modern Computer Security
|
||||
|
||||
- Possibly thousands of users
|
||||
- Distributed over wide networks
|
||||
- Not all users are inherently trust worthy
|
||||
- Not all users are inherently trustworthy
|
||||
- More and more things are moving to electronic
|
||||
- Requiring protocols to manage them
|
||||
- Requiring protocols to manage them
|
||||
|
||||
### Attacks
|
||||
|
||||
- Monetary transaction need security
|
||||
- Monetary transactions need security
|
||||
|
||||
This is what most interactions look like and therefore attacks are based on this communication
|
||||
|
||||
@@ -45,13 +45,13 @@ What if the server gets hacked, we can use **hash functions**
|
||||
|
||||
###### Digital Certificates
|
||||
|
||||
However, this can be bypassed if the clients machine is hacked
|
||||
However, this can be bypassed if the client’s machine is hacked
|
||||
|
||||
We have to ensure the client is running anti virus software and practices good avoidance.
|
||||
We have to ensure the client is running antivirus software and practises good avoidance.
|
||||
|
||||
###### Insider attacks
|
||||
|
||||
To stop this the company must practice good security such as:
|
||||
To stop this the company must practise good security such as:
|
||||
|
||||
- Database security Controls
|
||||
- File access controls
|
||||
@@ -72,31 +72,31 @@ It is often simply an arms race between developers & researchers and malicious u
|
||||
- Within organisations, management are responsible for defining security needs
|
||||
- Developers implement these policies
|
||||
- A concise document explaining the needs is called a *Security Policy*
|
||||
- What should be protected?
|
||||
- How should we protect it?
|
||||
- What should be protected?
|
||||
- How should we protect it?
|
||||
- UoN security policy
|
||||
- https://www.nottingham.ac.uk/dts/security/it-security.aspx
|
||||
- https://www.nottingham.ac.uk/dts/security/it-security.aspx
|
||||
|
||||
#### Computer Security
|
||||
|
||||
- Usually defined as three keys areas (**CIA**)
|
||||
- Usually defined as three key areas (**CIA**)
|
||||
|
||||
1. Confidentiality
|
||||
- Prevention of unauthorised *disclosure* of information
|
||||
- This involves unauthorised users reading private or secret information
|
||||
- Medical records or credit card details
|
||||
- Prevention of unauthorised *disclosure* of information
|
||||
- This involves unauthorised users reading private or secret information
|
||||
- Medical records or credit card details
|
||||
2. Integrity
|
||||
- Prevention of unauthorised *modification* of information
|
||||
- Also the assurance that data remains *unmodified*
|
||||
- Distributed bank transactions or database records
|
||||
- Just because we have **integrity**, doesn’t mean we have **authenticity**
|
||||
- Can we verify the sender? does it have freshness?
|
||||
- Authenticity = Intercity + Freshness
|
||||
- Prevention of unauthorised *modification* of information
|
||||
- Also the assurance that data remains *unmodified*
|
||||
- Distributed bank transactions or database records
|
||||
- Just because we have **integrity**, doesn’t mean we have **authenticity**
|
||||
- Can we verify the sender? does it have freshness?
|
||||
- Authenticity = Integrity + Freshness
|
||||
3. Availability
|
||||
- Prevention of unauthorised *withholding* of information or resources
|
||||
- The property of being accessible is an usable upon demand by an authorised entity
|
||||
- In other words prevent DoS attacks
|
||||
- e.g. redundant power supplies, firewall packet filtering
|
||||
- Prevention of unauthorised *withholding* of information or resources
|
||||
- The property of being accessible and usable upon demand by an authorised entity
|
||||
- In other words prevent DoS attacks
|
||||
- e.g. redundant power supplies, firewall packet filtering
|
||||
|
||||
#### Accountability
|
||||
|
||||
@@ -109,49 +109,49 @@ It is often simply an arms race between developers & researchers and malicious u
|
||||
- Provides unforgeable evidence that someone did something
|
||||
- Mostly a legal concept
|
||||
- Evidence verifiable by a trusted third party
|
||||
- e.g notaries, digital certificates
|
||||
- e.g notaries, digital certificates
|
||||
- Applies to physical security as well
|
||||
- Like key cards
|
||||
- Like key cards
|
||||
|
||||
##### The security Dilemma
|
||||
|
||||
> “Security-unaware users have specific security requirements but no security expertise”
|
||||
|
||||
- There is a trade off between security and ease of use
|
||||
- There is a trade-off between security and ease of use
|
||||
- Increased resource demands
|
||||
- Interferes with working patterns
|
||||
|
||||
###### Added complexity
|
||||
|
||||
- Often user experience is place at the forefront of software engineering
|
||||
- Often user experience is placed at the forefront of software engineering
|
||||
- This is usually not compatible with security
|
||||
- Security can be seen as controlling access to information
|
||||
- This is hard, we usually control access to data instead
|
||||
- Data - a means to represent information
|
||||
- Information - an interpretation of that data
|
||||
- Data - a means to represent information
|
||||
- Information - an interpretation of that data
|
||||
- Focusing on data can still leave information vulnerable
|
||||
- for example: Mikes criminal record not found
|
||||
- vs you do not have permission to access mikes criminal record
|
||||
- for example: Mike’s criminal record not found
|
||||
- vs you do not have permission to access Mike’s criminal record
|
||||
|
||||
#### Security Design
|
||||
|
||||
- Computer Security is **not** rocket science if:
|
||||
- Approached in a systematic, disciplined and well planned manner
|
||||
- From the inception / design of a system
|
||||
- Approached in a systematic, disciplined and well planned manner
|
||||
- From the inception / design of a system
|
||||
- However, if added as an afterthought, will often lead to disaster
|
||||
- Good security design focuses on these principles
|
||||
1. Focus of control
|
||||
- In a given application, should the focus of protection mechanisms be:
|
||||
- Data - permitted manipulation of data
|
||||
- consistency check
|
||||
- Operations - permitted invocations
|
||||
- Users - permissions for specific users
|
||||
2. Complexity vs assurance
|
||||
- Would we prefer a simple approach with *high assurance*? or a feature rich environment
|
||||
3. Centralised or decentralised controls
|
||||
- Should defining and enforcing security be performed by central entity, or be left to individual components in a system
|
||||
- **Central entity** - possible bottleneck
|
||||
- **Distributed solution** - more efficient, but harder to manage
|
||||
4. Layered security
|
||||
- We can visualise our security model in layers
|
||||
- Each layer protects a boundary, and relies on the security of the layers below
|
||||
1. Focus of control
|
||||
- In a given application, should the focus of protection mechanisms be:
|
||||
- Data - permitted manipulation of data
|
||||
- consistency check
|
||||
- Operations - permitted invocations
|
||||
- Users - permissions for specific users
|
||||
2. Complexity vs assurance
|
||||
- Would we prefer a simple approach with *high assurance*? or a feature rich environment
|
||||
3. Centralised or decentralised controls
|
||||
- Should defining and enforcing security be performed by central entity, or be left to individual components in a system
|
||||
- **Central entity** - possible bottleneck
|
||||
- **Distributed solution** - more efficient, but harder to manage
|
||||
4. Layered security
|
||||
- We can visualise our security model in layers
|
||||
- Each layer protects a boundary, and relies on the security of the layers below
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
> “Cybersecurity is how individuals and organisations reduce the risk of cyber attack.
|
||||
>
|
||||
> Cybersecurity's core function is to protect the devices we all use (smartphones, laptops, tablets and computers), and the services we access - both online and at work - from theft or damage.
|
||||
> Cybersecurity's core function is to protect the devices we all use (smartphones, laptops, tablets and computers), and the services we access - both online and at work - from theft or damage.
|
||||
>
|
||||
> It's also about preventing unauthorised access to the vast amounts of personal information we store on these devices, and online” - UK National Cyber Security Centre www.ncsc.gov.uk/section/about-ncsc/what-is-cyber-security
|
||||
|
||||
@@ -17,19 +17,19 @@
|
||||
- A statement of overall intent and commitment to security
|
||||
- Provides a *foundation* for other aspects
|
||||
- High level policy applies to the organisation and everyone in it
|
||||
- more focused policies may apply to specific departments, systems etc
|
||||
- more focused policies may apply to specific departments, systems etc
|
||||
- Identifies what but not how
|
||||
- the *how* part would be covered by accompanying guidelines
|
||||
- the *how* part would be covered by accompanying guidelines
|
||||
|
||||
#### Characteristics of a good policy
|
||||
|
||||
- Is short and backed from the top of the organisation
|
||||
- Ensure everyone reads it
|
||||
- Ensure everyone reads it
|
||||
- Recognises that information is critical & must be protected
|
||||
- Emphasises the importance of security awareness & training
|
||||
- Emphasises compliance with legal and regulatory requirements
|
||||
- Emphasises relations with third parties
|
||||
- States roles and responsibilities for information security
|
||||
- States roles and responsibilities for information security
|
||||
- Outlines standards and procedures
|
||||
- States the consequences of violations and non-compliance
|
||||
|
||||
@@ -39,7 +39,7 @@ Note the lack of policies on personally owned devices, considering ~100% of peop
|
||||
|
||||
**Removal**
|
||||
|
||||
System is modified so that a particular feature, and the associated risk is removed.
|
||||
System is modified so that a particular feature and the associated risk are removed.
|
||||
|
||||
**Reduction**
|
||||
|
||||
@@ -51,7 +51,7 @@ Nothing is done - the risk is small and insignificant
|
||||
|
||||
**Relocation**
|
||||
|
||||
The system is unchanged, but risk is transferred to another party e.g. an insurance
|
||||
The system is unchanged, but risk is transferred to another party e.g. an insurer
|
||||
|
||||
###### Management need to know
|
||||
|
||||
@@ -63,25 +63,25 @@ The system is unchanged, but risk is transferred to another party e.g. an insura
|
||||
|
||||
### Baseline Security
|
||||
|
||||
- A minimum level of protection that should be considered by all organisations ulitilising IT systems
|
||||
- Although many organisation will require protection considerably above baseline
|
||||
- Can provide a *common* basis for mutual trust
|
||||
- A minimum level of protection that should be considered by all organisations utilising IT systems
|
||||
- Although many organisations will require protection considerably above baseline
|
||||
- Can provide a *common* basis for mutual trust
|
||||
|
||||
###### Cyber Essentials
|
||||
|
||||
- Enables organisations to be certified independently for having met a good practice standard in cyber security
|
||||
- Addresses five technical control themes:
|
||||
1. Firewalls
|
||||
2. Secure configuration
|
||||
3. User access control
|
||||
4. Malware protection
|
||||
5. Security Update management
|
||||
1. Firewalls
|
||||
2. Secure configuration
|
||||
3. User access control
|
||||
4. Malware protection
|
||||
5. Security Update management
|
||||
|
||||
###### ISO 27001
|
||||
|
||||
- the central element of the ISO 27000 series
|
||||
- describes best practice for an ISMS (information security management system)
|
||||
- outlines of each aspect of an ISMS, and other standards provide further detail (e.g. 27002 for controls, 27003 for implementation, 27004 for evaluation)
|
||||
- outlines each aspect of an ISMS, and other standards provide further detail (e.g. 27002 for controls, 27003 for implementation, 27004 for evaluation)
|
||||
|
||||
###### ISO 27002
|
||||
|
||||
@@ -90,6 +90,6 @@ The system is unchanged, but risk is transferred to another party e.g. an insura
|
||||
### The need for Professional Skills
|
||||
|
||||
- Although simplified at the abstract level, actually following even the baseline controls is non-trivial
|
||||
- Simply knowing about them does not tell you *how* to comply
|
||||
- Still requires the ability to assess the current environment and understand the appropriate protection and how to apply it
|
||||
- Organisations require professionals with appropriate security knowledge, skills and competence.
|
||||
- Simply knowing about them does not tell you *how* to comply
|
||||
- Still requires the ability to assess the current environment and understand the appropriate protection and how to apply it
|
||||
- Organisations require professionals with appropriate security knowledge, skills and competence.
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
- Symmetric encryption gives us confidentiality
|
||||
- Implemented using block ciphers or stream ciphers
|
||||
- Lightweight and fast
|
||||
- Used for general communication
|
||||
- Lightweight and fast
|
||||
- Used for general communication
|
||||
|
||||

|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
- Stream ciphers use an initial seed key to generate an infinite keystream of random looking bits
|
||||
- The message and keystream are usually combined using an `xor` ($\oplus$) which is reversible if applied twice
|
||||
|
||||
- How ever using the same keystream to encrypt two messages makes messages easy to break
|
||||
- However, using the same keystream to encrypt two messages makes messages easy to break
|
||||
- A random *number used once* nonce is added as an additional seed
|
||||
- The nonce is not a secret, it simply ensures the keystream is new
|
||||
|
||||
@@ -33,7 +33,7 @@
|
||||
#### Block Ciphers
|
||||
|
||||
- Block ciphers use a key to encrypt a fixed size block of plain text into a *fixed-sized block* of cipher-text
|
||||
- Changing and permuting the bits of the block depending on the key
|
||||
- Changing and permuting the bits of the block depending on the key
|
||||
- Different lengths of messages can be handled by splitting the message up, and padding
|
||||
|
||||
##### SP-Network
|
||||
@@ -68,28 +68,28 @@
|
||||
### Attack Models
|
||||
|
||||
1. Brute force
|
||||
- Weakest attack, guessing the key
|
||||
- If the key is $2^{128}$, on a super computer would take $10^9$ years
|
||||
- Weakest attack, guessing the key
|
||||
- If the key is $2^{128}$, on a supercomputer it would take $10^9$ years
|
||||
2. Cipher text only
|
||||
- Static analysis on the cipher text, frequency analysis etc
|
||||
- e.g. looking at the enginma machine and recognising a letter cannot be itself
|
||||
- Static analysis on the cipher text, frequency analysis etc
|
||||
- e.g. looking at the Enigma machine and recognising a letter cannot be itself
|
||||
3. Known plaintext
|
||||
- Where you know some plaintext and the corresponding ciphertext
|
||||
- e.g. Enigma being broken using “heil hitler”
|
||||
- Where you know some plaintext and the corresponding ciphertext
|
||||
- e.g. Enigma being broken using “heil hitler”
|
||||
4. Chosen plaintext
|
||||
- Seeing if certain plain-texts takes the algorithm longer/shorter
|
||||
- Seeing if certain plain-texts take the algorithm longer/shorter
|
||||
5. Chosen ciphertext
|
||||
6. Related-key attack
|
||||
- Get the same message encrypted in different keys
|
||||
- More of a theoretical attack
|
||||
- Get the same message encrypted in different keys
|
||||
- More of a theoretical attack
|
||||
|
||||
Modern algorithms are expected to overcome these attacks trivially
|
||||
|
||||
## Asymmetric Encryption
|
||||
|
||||
- Two keys, a public & private key
|
||||
- Public-key asymmetric cryptography hinges upon the premuse that:
|
||||
- It is computationally infeasible to calculate a private key from a public key
|
||||
- Public-key asymmetric cryptography hinges upon the premise that:
|
||||
- It is computationally infeasible to calculate a private key from a public key
|
||||
- In practice this is achieved through intractable mathematical problems
|
||||
|
||||
#### Key Exchange
|
||||
@@ -104,17 +104,16 @@ It is extremely easy to go from a -> A but extremely difficult to go backwards.
|
||||
|
||||
#### Public key Encryption
|
||||
|
||||
- Client encrypts message with servers public key, now only the server’s private key can be used to read it.
|
||||
- Client encrypts message with the server’s public key; now only the server’s private key can be used to read it.
|
||||
- The authenticity of signatures generated by the private key can be verified by the public key
|
||||
|
||||

|
||||
|
||||
##### Public key Algorithms
|
||||
|
||||
| Algorithm | Key Exchange | Encryption | Digital Signitures | Mathematical Problem | Elliptic Curves | Typical Key Size |
|
||||
| Algorithm | Key Exchange | Encryption | Digital Signatures | Mathematical Problem | Elliptic Curves | Typical Key Size |
|
||||
| :------------- | :----------: | :--------: | :----------------: | --------------------- | :-------------: | ---------------- |
|
||||
| Diffie-Hellmen | ✅ | ❌ | ❌ | Discrete Logs | ✅ | 256 |
|
||||
| Diffie-Hellman | ✅ | ❌ | ❌ | Discrete Logs | ✅ | 256 |
|
||||
| `RSA` | ❌ | ✅ | ✅ | Integer Factorisation | ❌ | 2048/4096 |
|
||||
| `Elgamal` | ❌ | ✅ | ✅ | Discrete Logs | ✅ | 2048 |
|
||||
| `DSA` | ❌ | ❌ | ✅ | Discrete Logs | ✅ | 256 |
|
||||
|
||||
@@ -1,20 +1,20 @@
|
||||
# Users and Authentication
|
||||
|
||||
- Users must be *identified* to enable:
|
||||
- User specific access controls
|
||||
- Individuals accountability for activities
|
||||
- User specific access controls
|
||||
- Individuals’ accountability for activities
|
||||
- Claimed identities must be authenticated
|
||||
- First line of system protection
|
||||
- Safeguards against abuse by external parties or unauthorised insiders
|
||||
- First line of system protection
|
||||
- Safeguards against abuse by external parties or unauthorised insiders
|
||||
|
||||
##### Authentication Methods
|
||||
|
||||
1. Something the user *knows*
|
||||
- passwords, PINs
|
||||
- passwords, PINs
|
||||
2. Something the user *has*
|
||||
- a card, a token
|
||||
- a card, a token
|
||||
3. Something the user *is*
|
||||
- a bio-metric so a finger print or the users face
|
||||
- a biometric, so a fingerprint or the user’s face
|
||||
|
||||
#### Passwords
|
||||
|
||||
@@ -28,8 +28,8 @@ On one level they are very usable
|
||||
Ease of use is often because users have not been made to use them properly
|
||||
|
||||
- Users make poor selections
|
||||
- Dictionary words
|
||||
- things that people could guess or social engineer
|
||||
- Dictionary words
|
||||
- things that people could guess or social engineer
|
||||
- Use the same password on multiple systems
|
||||
- Share them with other people
|
||||
- Write them down in discoverable places
|
||||
@@ -38,14 +38,14 @@ Ease of use is often because users have not been made to use them properly
|
||||
|
||||
#### Current Guidance on Password Systems
|
||||
|
||||
- The latest NIST recommendation advise:
|
||||
- Against automatic password expiry
|
||||
- Passwords should only be changed when there’s a reason
|
||||
- Against imposing rules for complex passwords
|
||||
- Length matters more than complexity
|
||||
- Against password hints or knowledge-based authentication
|
||||
- Social media means these can be socially engineered
|
||||
- To enable “show password while typing” and to allow paste-in password fields
|
||||
- The latest NIST recommendations advise:
|
||||
- Against automatic password expiry
|
||||
- Passwords should only be changed when there’s a reason
|
||||
- Against imposing rules for complex passwords
|
||||
- Length matters more than complexity
|
||||
- Against password hints or knowledge-based authentication
|
||||
- Social media means these can be socially engineered
|
||||
- To enable “show password while typing” and to allow paste-in password fields
|
||||
|
||||
> Passwords are a **broken mechanism**
|
||||
>
|
||||
@@ -57,12 +57,12 @@ Browsers can now auto-generate passwords for us
|
||||
|
||||
- Avoids users making poor decisions
|
||||
- But also avoids us
|
||||
- Knowing what the password is
|
||||
- Needing to know the good practice
|
||||
- Knowing what the password is
|
||||
- Needing to know the good practice
|
||||
|
||||
Some devices may not support password entry
|
||||
|
||||
- For example dictating a password to an Alexa or google home
|
||||
- For example dictating a password to an Alexa or Google Home
|
||||
- Mobile devices with small keyboards can be tricky
|
||||
|
||||
#### Token-based Authentication
|
||||
@@ -75,23 +75,23 @@ Some devices may not support password entry
|
||||
- Wearable devices
|
||||
- Smartphones
|
||||
|
||||
Often combined with a secret knowledge to form a 2-stage / 2-factor authentication
|
||||
Often combined with secret knowledge to form 2-stage / 2-factor authentication
|
||||
|
||||
- e.g. using an ATM requires card and pin
|
||||
|
||||
Smartphone apps can proveide the same functionality as authentication tokens (i.e. computing OTP)
|
||||
Smartphone apps can provide the same functionality as authentication tokens (i.e. computing OTP)
|
||||
|
||||
- The users no longer need a separate, dedicated device
|
||||
- Think nationwide card reader for transfers
|
||||
- Think Nationwide card reader for transfers
|
||||
- Relies on the security of the smartphone
|
||||
- User authentication on the device and or the app
|
||||
- Prevention of compromise via attacks
|
||||
- User authentication on the device and or the app
|
||||
- Prevention of compromise via attacks
|
||||
|
||||
#### Biometrics
|
||||
|
||||
- Theoretically far more usable
|
||||
- Nothing for the user to remember
|
||||
- Nothing for them to lose or leave behind
|
||||
- Nothing for the user to remember
|
||||
- Nothing for them to lose or leave behind
|
||||
|
||||

|
||||
|
||||
@@ -114,19 +114,19 @@ Biometrics can be copied, but not easily
|
||||
###### Biometrics Errors
|
||||
|
||||
- **F**alse **R**ejection **R**ate (**FRR**)
|
||||
- Errors where the system falsely identifies the legitimate user as an imposter
|
||||
- Also known as False Alarm Rate or Type I error
|
||||
- Errors where the system falsely identifies the legitimate user as an imposter
|
||||
- Also known as False Alarm Rate or Type I error
|
||||
- **F**alse **A**cceptance **R**ate (**FAR**)
|
||||
- Errors where imposters are falsely believed to be legitimate users
|
||||
- Also known as Impostor Pass Rate or Type II error
|
||||
- Errors where imposters are falsely believed to be legitimate users
|
||||
- Also known as Impostor Pass Rate or Type II error
|
||||
- **E**qual **E**rror **R**ate (**EER**)
|
||||
- The point at which FAR and FRR coincide
|
||||
- The measure normally used to assess biometric products
|
||||
- Failure to Enroll
|
||||
- Errors in which the system is unable to establish as biometric template for a proposed user
|
||||
- e.g. some people don’t have finger prints, some reglions require face covering
|
||||
- The point at which FAR and FRR coincide
|
||||
- The measure normally used to assess biometric products
|
||||
- Failure to Enrol
|
||||
- Errors in which the system is unable to establish a biometric template for a proposed user
|
||||
- e.g. some people don’t have fingerprints, some religions require face covering
|
||||
- Failure to Acquire
|
||||
- Errors in which the system is unable to successfully acquire the information required to make a decision
|
||||
- Errors in which the system is unable to successfully acquire the information required to make a decision
|
||||
|
||||
A legitimate user’s experience of biometrics will be informed by:
|
||||
|
||||
@@ -140,13 +140,13 @@ Developers focus can change on implementation. For example if being used as a pa
|
||||
##### Modes of Use
|
||||
|
||||
- **Verification**
|
||||
- User claims an identity - authentication against that identity
|
||||
- One-to-one match (1:1)
|
||||
- Less unique characteristics can be ultised
|
||||
- User claims an identity - authentication against that identity
|
||||
- One-to-one match (1:1)
|
||||
- Less unique characteristics can be utilised
|
||||
- **Identification**
|
||||
- Users’ biometric sample is compared against all in database
|
||||
- One-to-Many match (1:N)
|
||||
- Only the more unique biometrics can be ultised - fingerprints, iris, retina etc
|
||||
- Users’ biometric sample is compared against all in database
|
||||
- One-to-Many match (1:N)
|
||||
- Only the more unique biometrics can be utilised - fingerprints, iris, retina etc
|
||||
|
||||
### 2-Factor Authentication
|
||||
|
||||
@@ -156,4 +156,4 @@ Two-factor and multi-factor Authentication
|
||||
- Typical implementations have been a password & token
|
||||
- Ideally you want factors from different categories
|
||||
|
||||

|
||||

|
||||
@@ -1,22 +1,22 @@
|
||||
# Authentication
|
||||
|
||||
- To allow some access to an asset we must ensure:
|
||||
- They are permitted to access that asset
|
||||
- They are who they say they are
|
||||
- They are permitted to access that asset
|
||||
- They are who they say they are
|
||||
- We can attempt to verify identity using credentials
|
||||
- Something the user *is*
|
||||
- Something the user *has*
|
||||
- Something the user *knows*
|
||||
- Something the user *is*
|
||||
- Something the user *has*
|
||||
- Something the user *knows*
|
||||
|
||||
#### Usernames and Passwords
|
||||
|
||||
- Identification - who are you
|
||||
- Authentication - verify that identity
|
||||
- Authentication should expire
|
||||
- *Remember my credentials* turns this into something you have
|
||||
- *Remember my credentials* turns this into something you have
|
||||
- **T**ime **o**f **c**heck **t**o **t**ime **o**f **u**se - **TOCTTOU**
|
||||
- Repeated authentication
|
||||
- At the start and during a session
|
||||
- Repeated authentication
|
||||
- At the start and during a session
|
||||
|
||||
##### Problems with passwords
|
||||
|
||||
@@ -29,7 +29,7 @@
|
||||
|
||||
### Hash Functions
|
||||
|
||||
- Another crptographic primitive
|
||||
- Another cryptographic primitive
|
||||
- Takes a message of any length, and returns a pseudorandom hash of fixed length
|
||||
|
||||
$$
|
||||
@@ -57,10 +57,10 @@ For a hash function to be useful, we need it to have some important properties:
|
||||
If database is breached, passwords are stored in plaintext
|
||||
|
||||
- Storing passwords in plaintext is a terrible idea
|
||||
- Administrators can read them
|
||||
- Administrators can read them
|
||||
- Storing encrypted passwords is better, but not perfect
|
||||
- Where are keys stored?
|
||||
- Administrators can read them
|
||||
- Where are keys stored?
|
||||
- Administrators can read them
|
||||
|
||||
Using a **one-way hash function** is a much better solution
|
||||
|
||||
@@ -69,53 +69,53 @@ Using a **one-way hash function** is a much better solution
|
||||
#### Password & Shadow Files
|
||||
|
||||
- Operating systems have taken steps to stop people reading hashes for offline attacks
|
||||
- Linux stores hashes in a shadow file `/etc/shadow`
|
||||
- Linux stores hashes in a shadow file `/etc/shadow`
|
||||
- These files are now **read-protected**
|
||||
|
||||
#### Cracking Passwords
|
||||
|
||||
- Cracking a password isn’t always illegal
|
||||
- Password cracking falls into two basic types:
|
||||
- Offline: you have a copy of the password hash locally
|
||||
- This is trying possible passwords and seeing if we have a hash collision with the password list
|
||||
- Usually done via brute force however difficulty is $\{char\space count\}^{length}$
|
||||
- Online: You do not have the hash, and are instead attempting to gain access to an actual login terminal
|
||||
- Online is usually atempted via phising
|
||||
- Offline: you have a copy of the password hash locally
|
||||
- This is trying possible passwords and seeing if we have a hash collision with the password list
|
||||
- Usually done via brute force however difficulty is $\{char\space count\}^{length}$
|
||||
- Online: You do not have the hash, and are instead attempting to gain access to an actual login terminal
|
||||
- Online is usually attempted via phishing
|
||||
|
||||

|
||||
|
||||
##### Dictionary Attacks
|
||||
|
||||
- Most password cracking is now achieved using **dictionary attacks** rather than brute force
|
||||
- Using a dictionary of common words and passwords
|
||||
- Apply small variations to this list, trying them all
|
||||
- Combine words from two different lists
|
||||
- Using a dictionary of common words and passwords
|
||||
- Apply small variations to this list, trying them all
|
||||
- Combine words from two different lists
|
||||
- `qwerty1234password1` is unbreakable using brute force, but won’t last against a dictionary attack
|
||||
|
||||
##### Password Salting
|
||||
|
||||
- We can improve security by pre-pending a random *salt* to a password before hashing
|
||||
- The salt is stored unencrpted with the hash
|
||||
- If a hacker has a list of hashed passwords, and three of them are the same, he can summise they’re all a common password.
|
||||
- Salting adds non-secrete randomness to passwords
|
||||
- The salt is stored unencrypted with the hash
|
||||
- If a hacker has a list of hashed passwords, and three of them are the same, he can surmise they’re all a common password.
|
||||
- Salting adds non-secret randomness to passwords
|
||||
|
||||

|
||||
|
||||
- If we use a different random salt for each user, we get the following security benefits:
|
||||
1. Cracking multiple passwords is slower - a hit is for a single user, not all users with that password
|
||||
2. Prevents **rainbow table** attacks - we can’t pre-compute that many password combinations
|
||||
1. Cracking multiple passwords is slower - a hit is for a single user, not all users with that password
|
||||
2. Prevents **rainbow table** attacks - we can’t pre-compute that many password combinations
|
||||
- Salting has no effect on the speed of cracking a single password
|
||||
|
||||
#### Hashing Speed
|
||||
|
||||
- When password cracking, the most important factor is *hashing speed*
|
||||
- New algorithms take longer
|
||||
- Partly because they’re more complex
|
||||
- But some have been specifically designed to take a while
|
||||
- Partly because they’re more complex
|
||||
- But some have been specifically designed to take a while
|
||||
- Iterate to increase complexity
|
||||
|
||||
##### Social Cracking
|
||||
|
||||
- Obtaining private details by offering some *pretext* as a reason for needing them
|
||||
- We continue to rely on email addresses, DOB and Mother’s maiden names as our *last line of defence* for security
|
||||
- How much information do we need to ring up a company as someone else
|
||||
- How much information do we need to ring up a company as someone else
|
||||
@@ -4,18 +4,18 @@ The reference monitor is an abstract concept
|
||||
|
||||
> An access control concept that refers to an abstract machine that mediates all access to objects by subjects
|
||||
|
||||
- Must be tamper proof
|
||||
- Must be tamper-proof
|
||||
- Must *always be invoked* when access to an object is required
|
||||
- Must be small enough to be verifiable / subject to analysis to ensure correctness
|
||||
|
||||
##### Placement
|
||||
|
||||
- Can be placed anywhere within the system
|
||||
- Hardware - dedicated registers for defining privileges
|
||||
- Operating system kernel - virtual machine hyper-visor
|
||||
- Operating system - Windows security reference monitor
|
||||
- Services layer - `JVM`, `.NET`
|
||||
- Application layer - Firewalls
|
||||
- Hardware - dedicated registers for defining privileges
|
||||
- Operating system kernel - virtual machine hypervisor
|
||||
- Operating system - Windows security reference monitor
|
||||
- Services layer - `JVM`, `.NET`
|
||||
- Application layer - Firewalls
|
||||
|
||||
Reference monitors could be placed in a variety of locations relative to the program being run
|
||||
|
||||
@@ -26,27 +26,27 @@ The last example where the program contains its own reference monitor, as found
|
||||
###### Lower is better
|
||||
|
||||
- Using a reference monitor or other security features at a lower level means:
|
||||
- We can **assure** a higher degree of security
|
||||
- Usually **simple structures** to implement
|
||||
- Reduced performance **overheads**
|
||||
- Has to be extremely quick as many calls will be made
|
||||
- Fewer layer below attack possibilities
|
||||
- We can **assure** a higher degree of security
|
||||
- Usually **simple structures** to implement
|
||||
- Reduced performance **overheads**
|
||||
- Has to be extremely quick as many calls will be made
|
||||
- Fewer layer below attack possibilities
|
||||
- However
|
||||
- Access control decisions are far removed from applications
|
||||
- Access control decisions are far removed from applications
|
||||
|
||||
#### OS Integrity
|
||||
|
||||
- The operating system
|
||||
- Arbitrates access requests
|
||||
- Is itself a resource that must be accessed
|
||||
- Arbitrates access requests
|
||||
- Is itself a resource that must be accessed
|
||||
- This is a conflict, we want to use the OS but not mess with it
|
||||
|
||||
> Users must not be able to modify the operating system
|
||||
|
||||
- Modes of operation
|
||||
- Defines which actions are permitted in which mode e.g. system calls, machine instructions, I/O
|
||||
- Defines which actions are permitted in which mode e.g. system calls, machine instructions, I/O
|
||||
- Controlled Invocation
|
||||
- Allows us to execute privileged instructions safely, before returning to user code
|
||||
- Allows us to execute privileged instructions safely, before returning to user code
|
||||
|
||||
We must distinguish computations done on behalf of:
|
||||
|
||||
@@ -61,10 +61,10 @@ In practice, Windows and Unix only use Ring 0&3 to save on overhead
|
||||
|
||||
### Controlled Invocation
|
||||
|
||||
- Many functions are helf at kernel level, but are quite reasonably called from within user level code
|
||||
- Network and File IO
|
||||
- Memory allocation
|
||||
- Halting the CPU (at shutdown only)
|
||||
- Many functions are held at kernel level, but are quite reasonably called from within user-level code
|
||||
- Network and File IO
|
||||
- Memory allocation
|
||||
- Halting the CPU (at shutdown only)
|
||||
- We need a mechanism to transfer safely between kernel mode (ring 0) and user mode (ring 3)
|
||||
|
||||
> We don’t actually perform privileged operations, we asking the operating system to perform them for us - The operating system can refuse to do it
|
||||
@@ -72,7 +72,7 @@ In practice, Windows and Unix only use Ring 0&3 to save on overhead
|
||||
##### Interrupts
|
||||
|
||||
- Exceptions or Interrupts
|
||||
- In many ways is the hardware equivalent to a software exception - not always bad
|
||||
- In many ways is the hardware equivalent to a software exception - not always bad
|
||||
- Handled by an interrupt handler which resolves the issue and returns to the original code
|
||||
|
||||
Processing an Interrupt
|
||||
@@ -85,9 +85,9 @@ Processing an Interrupt
|
||||
|
||||
- Descriptors hold information on crucial system objects like kernel structure locations
|
||||
- Descriptors are held in descriptor tables
|
||||
- Contain a Descriptor Privilege Level (DPL)
|
||||
- Contain a Descriptor Privilege Level (DPL)
|
||||
- Descriptors are indexed by selectors
|
||||
- Loaded when required (jump calls)
|
||||
- Loaded when required (jump calls)
|
||||
- The CPU protects the kernel by checking the Current Privilege Level (CPL) when a Selector is loaded
|
||||
|
||||
##### Interrupt Gates
|
||||
@@ -101,11 +101,11 @@ Processing an Interrupt
|
||||
###### Modern Kernels
|
||||
|
||||
- Intel introduced the `sysenter` and `sysexit` operations with the Pentium II
|
||||
- performs with much less overhead
|
||||
- performs with much less overhead
|
||||
|
||||

|
||||
|
||||
We got immediately in to ring 0
|
||||
We go immediately into ring 0
|
||||
|
||||
However where we go next is dictated by the `sysenter` pointer, users cannot write to `sysenter`
|
||||
|
||||
@@ -119,20 +119,20 @@ However where we go next is dictated by the `sysenter` pointer, users cannot wri
|
||||
|
||||
- A process is a program being executed currently
|
||||
- Important unit of control
|
||||
- Exists in its own address space
|
||||
- Communicates with other processes via the OS
|
||||
- Separation for security
|
||||
- Exists in its own address space
|
||||
- Communicates with other processes via the OS
|
||||
- Separation for security
|
||||
- A thread is a strand of execution within a process
|
||||
- Share a common address space
|
||||
- Share a common address space
|
||||
- Segmentation - divides data into logical units
|
||||
- Good for security
|
||||
- Challenging memory management
|
||||
- Not used much in modern OSs
|
||||
- Modern OSs only have two segments, one for user space, the other for kernel space
|
||||
- Good for security
|
||||
- Challenging memory management
|
||||
- Not used much in modern OSs
|
||||
- Modern OSs only have two segments, one for user space, the other for kernel space
|
||||
- Paging - divides memory into pages of equal size
|
||||
- Efficient memory management
|
||||
- Less good for access control
|
||||
- Extremely common in modern OSs
|
||||
- Efficient memory management
|
||||
- Less good for access control
|
||||
- Extremely common in modern OSs
|
||||
|
||||
##### Page Tables
|
||||
|
||||
@@ -144,17 +144,17 @@ However where we go next is dictated by the `sysenter` pointer, users cannot wri
|
||||
###### Meltdown
|
||||
|
||||
- In most operating systems, the entire kernel is stored in the upper address space
|
||||
- Pages in this area are flagged as supervisor, and cannot be access outside ring 0
|
||||
- Pages in this area are flagged as supervisor, and cannot be accessed outside ring 0
|
||||
- Meltdown is an exploit that allows us to read this privileged memory
|
||||
- We do this using a *side-channel*
|
||||
- We do this using a *side-channel*
|
||||
|
||||

|
||||
|
||||
- In Intel CPUs, it’s common to speculatively evaluate code prior reaching it
|
||||
- E.g. conditionals
|
||||
- **Significant** speed up
|
||||
- No harm done, changes are just rolled back
|
||||
- But the **cache isn’t rolled back**
|
||||
- In Intel CPUs, it’s common to speculatively evaluate code prior to reaching it
|
||||
- E.g. conditionals
|
||||
- **Significant** speed-up
|
||||
- No harm done, changes are just rolled back
|
||||
- But the **cache isn’t rolled back**
|
||||
- This is called side-channelling and cache timing
|
||||
|
||||
```java
|
||||
@@ -179,8 +179,7 @@ x = memory[data * 4096];
|
||||
4. Page 117 was quicker
|
||||
|
||||
- Meltdown attempts to read a value from kernel memory
|
||||
- Read from kernel
|
||||
- Mask out single bit
|
||||
- Access user memory at that location
|
||||
- If we repeat we can read all memory in kernel space
|
||||
|
||||
- Read from kernel
|
||||
- Mask out single bit
|
||||
- Access user memory at that location
|
||||
- If we repeat we can read all memory in kernel space
|
||||
@@ -4,23 +4,23 @@
|
||||
|
||||
- Identification
|
||||
- Authentication
|
||||
- Lets us verify who we are to the system
|
||||
- Some files are private, some are public
|
||||
- System files must be protected
|
||||
- We need to be able to access applications
|
||||
- Lets us verify who we are to the system
|
||||
- Some files are private, some are public
|
||||
- System files must be protected
|
||||
- We need to be able to access applications
|
||||
- Access control
|
||||
- Auditing
|
||||
|
||||
#### Authentication & Authorisation
|
||||
|
||||
- Subject / Principle - an active entity
|
||||
- Subject / Principal - an active entity
|
||||
- Object - resource being accessed
|
||||
- Access operation
|
||||
- Reference monitor - grants or denies access
|
||||
|
||||

|
||||

|
||||
|
||||
**Principle**
|
||||
**Principal**
|
||||
|
||||
> “An entity that can be granted access to objects or can make statements affecting access control decisions”
|
||||
|
||||
@@ -39,32 +39,32 @@
|
||||
Files or resources - memory, printers, directories
|
||||
|
||||
- Two options for focusing control:
|
||||
1. What a subject is allowed to do
|
||||
2. What may be done to an object
|
||||
1. What a subject is allowed to do
|
||||
2. What may be done to an object
|
||||
|
||||
#### General Model
|
||||
|
||||
- We’ll settle on some common access files:
|
||||
- **Read** - Simply viewing (**confidentiality**)
|
||||
- **Write** - Includes changing, appending, deleting (**integrity**)
|
||||
- **Execute** - Can run a file without knowing its contents
|
||||
- **Read** - Simply viewing (**confidentiality**)
|
||||
- **Write** - Includes changing, appending, deleting (**integrity**)
|
||||
- **Execute** - Can run a file without knowing its contents
|
||||
|
||||
##### Ownership
|
||||
|
||||
- Who is in charge of setting security policies
|
||||
- **Discretionary**: Owner can be defined for each resource
|
||||
- Owner controls who gets access
|
||||
- Owner controls who gets access
|
||||
- **Mandatory**: There could be a system-wide policy
|
||||
- e.g. a government with different levels of security (top secret, level 3 clearance, etc)
|
||||
- Not commonly used for businesses
|
||||
- Most OS’s support the concept of ownership
|
||||
- e.g. a government with different levels of security (top secret, level 3 clearance, etc)
|
||||
- Not commonly used for businesses
|
||||
- Most OSs support the concept of ownership
|
||||
|
||||
### Unix
|
||||
|
||||
- Unix simplifies access control by considering only the *user*, *group* and *others*
|
||||
- User is the current owner
|
||||
- Group is the named group entity
|
||||
- Everyone else
|
||||
- User is the current owner
|
||||
- Group is the named group entity
|
||||
- Everyone else
|
||||
- Unix offers read, write and execute access controls
|
||||
|
||||
##### Groups
|
||||
@@ -76,23 +76,23 @@ Files or resources - memory, printers, directories
|
||||
|
||||
##### UID & GID
|
||||
|
||||
- Usernames in unix are soft aliases, your UID is what determines permissions
|
||||
- User identities: UID
|
||||
- Group identities: GID
|
||||
- Usernames in Unix are soft aliases; your UID is what determines permissions
|
||||
- User identities: UID
|
||||
- Group identities: GID
|
||||
- Your IDs are stored in `/etc/passwd`
|
||||
- This stores user accounts, not just passwords
|
||||
- This stores user accounts, not just passwords
|
||||
- Root has a special UID of 0
|
||||
|
||||
###### The Shadow File
|
||||
|
||||
- In an attempt to improve password security, we can store password hashes in a shadow file
|
||||
- Readable only by root users
|
||||
- Readable only by root users
|
||||
- `/etc/shadow` stores the hashed passwords needed to authenticate users
|
||||
|
||||
#### Root (Unix Superuser)
|
||||
|
||||
- Root’s UID 0 is actually hard coded into the Linux kernel at multiple points
|
||||
- In 2003, this anonymous change was made to the error value return in the `wait4` function is Linux:
|
||||
- In 2003, this anonymous change was made to the error value return in the `wait4` function in Linux:
|
||||
|
||||
```
|
||||
if ((options == (_WCLONE|__WALL)) && (current->uid = 0))
|
||||
@@ -107,15 +107,15 @@ Note: single `=`. This was a backdoor which sets the current uid to 0, giving ro
|
||||
- Separate superuser duties (e.g. daemon, uucp)
|
||||
- Never use root as normal user
|
||||
- Audit `su` and `sudo` usage
|
||||
- In unix, everything is a file
|
||||
- In Unix, everything is a file
|
||||
- Files really represent resources
|
||||
- Organised in a tree structure, with alterations depending on the file system
|
||||
- I-nodes store permission information
|
||||
- Every resource as a owner and a group
|
||||
- I-nodes store permission information
|
||||
- Every resource has an owner and a group
|
||||
|
||||
###### I-nodes
|
||||
|
||||
- I-nodes in unix store the metadata for files
|
||||
- I-nodes in Unix store the metadata for files
|
||||
- Each file name links to an i-node which stores security information
|
||||
|
||||
```
|
||||
@@ -135,9 +135,9 @@ Change: 2022-02-11 21:26:48.260535505 +0000
|
||||
- Every resource has permission bits - held in the i-node metadata
|
||||
- Permissions for the user / group / others
|
||||
- Octal representation
|
||||
- Bit 3: read
|
||||
- Bit 2: write
|
||||
- Bit 1: execute
|
||||
- Bit 3: read
|
||||
- Bit 2: write
|
||||
- Bit 1: execute
|
||||
- Permissions are changed using `chmod` and passing three octal values
|
||||
|
||||

|
||||
@@ -155,11 +155,10 @@ Directory permissions are slightly different to files:
|
||||
|
||||
### Linux Security Modules
|
||||
|
||||
- SInce 2.6, linux provides the ability to hook into security calls
|
||||
- Since 2.6, Linux provides the ability to hook into security calls
|
||||
- This adds the ability to perform more complex Mandatory Access Control after standard Unix DAC
|
||||
- DAC check happens irrespective of whether SM is operationa.
|
||||
- DAC check happens irrespective of whether SM is operational.
|
||||
|
||||

|
||||
|
||||
- If the security module fails, it does not matter as the discretionary access check has already run.
|
||||
|
||||
@@ -4,33 +4,33 @@ Windows Architecture
|
||||
|
||||

|
||||
|
||||
Note: windows has `kernel mode drivers` and `user mode drivers`
|
||||
Note: Windows has `kernel mode drivers` and `user mode drivers`
|
||||
|
||||
### Security Subsystem
|
||||
|
||||
- Runs in user mode
|
||||
- `Logon` processes (`winlogon`, `LogonUI`)
|
||||
- Local security authority (`LSA`)
|
||||
- Checks Users accounts
|
||||
- Provides access token
|
||||
- Responsible for auditing
|
||||
- Checks users’ accounts
|
||||
- Provides access token
|
||||
- Responsible for auditing
|
||||
- Security Account manager (`SAM`)
|
||||
- Maintains user account database used by `LSA`
|
||||
- Encrypts / hashes passwords
|
||||
- Maintains user account database used by `LSA`
|
||||
- Encrypts / hashes passwords
|
||||
- Windows predominantly uses **Access Control Lists**, and has done since Windows NT
|
||||
- Extends the usual read, write and execute with:
|
||||
- Take ownership
|
||||
- Change permissions
|
||||
- Delete
|
||||
- This allows finer control over files for example a user will be able to read a file but not delete it
|
||||
- Take ownership
|
||||
- Change permissions
|
||||
- Delete
|
||||
- This allows finer control over files for example a user will be able to read a file but not delete it
|
||||
- 32-bit access masks (unlike Unix’s 9 bits)
|
||||
- A higher degree of control, with the associated complexity increase
|
||||
|
||||
### Access Control Matrix
|
||||
|
||||
- Access rights are defined individually for each combination of subject and object
|
||||
- Quite an abstract concept, bit would allow for very fine grained control
|
||||
- Not practical, think of the memory required in scaling it up
|
||||
- Quite an abstract concept, but would allow for very fine-grained control
|
||||
- Not practical, think of the memory required in scaling it up
|
||||
|
||||

|
||||
|
||||
@@ -52,41 +52,41 @@ The access control list can be found by right clicking on a file -> properties -
|
||||
|
||||
### Access Control
|
||||
|
||||
- Access control in windows treats more than just files, also:
|
||||
- Registry keys
|
||||
- Active directory objects
|
||||
- Groups
|
||||
- Access control in Windows treats more than just files, also:
|
||||
- Registry keys
|
||||
- Active directory objects
|
||||
- Groups
|
||||
- Inheritance is implemented
|
||||
- File can inherit ACLs from parent directories
|
||||
- File can inherit ACLs from parent directories
|
||||
|
||||
#### Principles
|
||||
#### Principals
|
||||
|
||||
- Principles are more broadly defined as well:
|
||||
- Principals are more broadly defined as well:
|
||||
- Local users
|
||||
- Domain users
|
||||
- Groups
|
||||
- Machines
|
||||
|
||||
Each principles has a human readable name and security ID (`SID`)
|
||||
Each principal has a human-readable name and security ID (`SID`)
|
||||
|
||||
```
|
||||
S-1-5-21-2475811070-2421845406-3333283485-1005
|
||||
S-1-5-21-1664130791-3153540899-3044996548-279530
|
||||
```
|
||||
|
||||
These are examples of `SID` from windows, but why are they so long?
|
||||
These are examples of `SID` from Windows, but why are they so long?
|
||||
|
||||
This is a form of future proofing. Imagine company A buys company B, you can merge the users onto one active directory without two `SID`s clashing. (also 96 bits of memory isn’t a lot in the grand scheme of things)
|
||||
|
||||
##### Local / Domain Principles
|
||||
##### Local / Domain Principals
|
||||
|
||||
- LSA creates local principles
|
||||
- principle = `MACHINE\principal`
|
||||
- Domain principles adminstered on DC by domain admins
|
||||
- principle@domain = DOMAIN\principle
|
||||
- net user /domain
|
||||
- net group /domain
|
||||
- net localgroup /domain
|
||||
- LSA creates local principals
|
||||
- principal = `MACHINE\principal`
|
||||
- Domain principals administered on DC by domain admins
|
||||
- principal@domain = DOMAIN\principal
|
||||
- net user /domain
|
||||
- net group /domain
|
||||
- net localgroup /domain
|
||||
|
||||
#### Groups
|
||||
|
||||
@@ -99,16 +99,16 @@ This is a form of future proofing. Imagine company A buys company B, you can mer
|
||||
#### Objects
|
||||
|
||||
- Objects are passive entities in access operations
|
||||
- In windows:
|
||||
- Executive objects (processes, threads, etc)
|
||||
- Private objects (files, directories)
|
||||
- In Windows:
|
||||
- Executive objects (processes, threads, etc)
|
||||
- Private objects (files, directories)
|
||||
- Securable objects have a security descriptor
|
||||
- Built-in securable objects managed by the OS
|
||||
- Private objects managed by the application software
|
||||
- Built-in securable objects managed by the OS
|
||||
- Private objects managed by the application software
|
||||
|
||||
### Access Tokens
|
||||
|
||||
- Instead of passing a number as in linux, we pass an access token
|
||||
- Instead of passing a number as in Linux, we pass an access token
|
||||
- It is the security credentials for a login session stored in the **access token**
|
||||
- Identifies the user, the user’s groups, and the user’s privileges
|
||||
|
||||
@@ -116,33 +116,33 @@ This is a form of future proofing. Imagine company A buys company B, you can mer
|
||||
|
||||
- Windows subjects: Processes and threads
|
||||
- New processes get a **copy** of the parent access token, possibly modified
|
||||
- Individual access token are immutable and can live beyond policy changes
|
||||
- The access token checked is the one given at login, not the current access token
|
||||
- This is a TOCTTOU issue (Time-of-check to Time-of-use)
|
||||
- Admins can force a user to logoff to update their access token
|
||||
- Individual access tokens are immutable and can live beyond policy changes
|
||||
- The access token checked is the one given at login, not the current access token
|
||||
- This is a TOCTTOU issue (Time-of-check to Time-of-use)
|
||||
- Admins can force a user to log off to update their access token
|
||||
|
||||
### User Account Control
|
||||
|
||||
- After Vista, administrator users do not use an administrative access token by default
|
||||
- Users have two tokens, one heavily restricted and used by default
|
||||
- A prompt allows a user to spawn a process with the adminstrative token, or switch a process’ token.
|
||||
- Similar to `sudo`
|
||||
- Can be swapped mid-execution
|
||||
- A prompt allows a user to spawn a process with the administrative token, or switch a process’ token.
|
||||
- Similar to `sudo`
|
||||
- Can be swapped mid-execution
|
||||
|
||||
#### Domains
|
||||
|
||||
- Single sing-on for network resources
|
||||
- Single sign-on for network resources
|
||||
- Centralised security administration
|
||||
- Domain controller (DC)
|
||||
- Handles user accounts and access control
|
||||
- Trusted 3rd party for authentication
|
||||
- Handles user accounts and access control
|
||||
- Trusted 3rd party for authentication
|
||||
- Multiple DCs allow for decentralisation by design
|
||||
|
||||
#### Interactive Logon
|
||||
|
||||
- The windows interactive logon allows a user to authenticate
|
||||
- The Windows interactive logon allows a user to authenticate
|
||||
- Windows logon begins with the Secure Attention Sequence `Ctrl+Alt+Del`
|
||||
- Can prevent spoofing - is tied directly to `winlogon`
|
||||
- Can prevent spoofing - is tied directly to `winlogon`
|
||||
- The logon process differs slightly for local and domain authentication
|
||||
|
||||
##### Local Logon
|
||||
@@ -150,7 +150,7 @@ This is a form of future proofing. Imagine company A buys company B, you can mer
|
||||
1. `Ctrl+Alt+Del` initiates a login prompt using `GINA`
|
||||
2. These collect credentials which are passed to the `LSA`
|
||||
3. The `LSA` uses `NTLM` to check the credentials against the `SAM` database
|
||||
4. Successful login an access token, which is used to spawn a shell (explorer.exe)
|
||||
4. Successful login produces an access token, which is used to spawn a shell (explorer.exe)
|
||||
|
||||

|
||||
|
||||
@@ -160,4 +160,4 @@ This is a form of future proofing. Imagine company A buys company B, you can mer
|
||||
- Replaces `SAM` with an Active Directory Domain Controller
|
||||
- Checks of a user are now performed on the remote `LSA`
|
||||
|
||||

|
||||

|
||||
@@ -3,8 +3,8 @@
|
||||
**Malware** - **Mal**icious Soft**ware**
|
||||
|
||||
- A very general term, malware is usually categorised based on
|
||||
- How it proliferates
|
||||
- What it does
|
||||
- How it proliferates
|
||||
- What it does
|
||||
|
||||

|
||||
|
||||
@@ -20,19 +20,19 @@
|
||||
|
||||
- Payloads are the actual malware deposited on the machine, or the harmful results
|
||||
- They range in severity
|
||||
- Essentially do nothing
|
||||
- Messages and adverts
|
||||
- Recruited into botnets or mail spam
|
||||
- Stealing private information
|
||||
- System destruction
|
||||
- Ransomware & Crypto-jacking
|
||||
- Essentially do nothing
|
||||
- Messages and adverts
|
||||
- Recruited into botnets or mail spam
|
||||
- Stealing private information
|
||||
- System destruction
|
||||
- Ransomware & Crypto-jacking
|
||||
|
||||
#### Virus
|
||||
|
||||
- A piece of self-replicating code
|
||||
- Propagates by attaching itself to a disk, file or document
|
||||
- When the file is run, the virus runs and attempts to proliferate
|
||||
- Installs without the users knowledge or consent
|
||||
- Installs without the user’s knowledge or consent
|
||||
|
||||
##### Notable Viruses
|
||||
|
||||
@@ -40,38 +40,38 @@
|
||||
- 1986: `Brain`, the first MS-DOS computer virus
|
||||
- 1989: `Ghostball`, the first multipartite virus - affects both `exe`s and the boot sector
|
||||
- 1995: First macro virus, `Concept`, affects MS Word documents
|
||||
- 1996: First linux virus, `Staog`, uses bugs in the linux kernel
|
||||
- 1996: First Linux virus, `Staog`, uses bugs in the Linux kernel
|
||||
|
||||
#### Worms
|
||||
|
||||
- Viruses traditionally require a human to spread
|
||||
- Worms are self-replicating and stand-alone programs
|
||||
- Do not require human intervention
|
||||
- Do not require human intervention
|
||||
- Scanning worms or email worms
|
||||
- Exploit known software vulnerabilities in order to spread
|
||||
|
||||
##### Notable Worms
|
||||
|
||||
- 1988: The Morris Worm, affects BSD unix machines. One of the first known buffer overruns
|
||||
- 1988: The Morris Worm, affects BSD Unix machines. One of the first known buffer overruns
|
||||
- 2000: The `ILOVEYOU` worm, one of the most damaging worms ever, used social engineering to get people to install it.
|
||||
- Used the file name `LOVE-LETTER-FOR-YOU.txt.vbs` as windows didn’t show the file type in the file name
|
||||
- Used the file name `LOVE-LETTER-FOR-YOU.txt.vbs` as Windows didn’t show the file type in the file name
|
||||
|
||||

|
||||
|
||||
### 2003-2004
|
||||
|
||||
- During 2003 and 2004 worms were everywhere
|
||||
- SQL Slammer - fastest spreading worm, crashed the internet (only 376 bytes or 1 UDP packet)
|
||||
- Even when the network was crippled, the occasional UDP packet could be transmitted and further damage the network
|
||||
- MS Blaster - Windows XP mainly, crashes RPC and reboots your machine
|
||||
- Spreading between machines on a internal network easily, no port filtering
|
||||
- Used a buffer overflow in a windows Remote Procedure Call (RPC) service - spreads without the user clicking
|
||||
- Compromised machines performed DDOS on `windowsupdate.com`
|
||||
- Netsky - Infected email attachment, actually removed other worms as part of a *worm war*
|
||||
- Sasser - From the author of Netsky, attacks windows `LSASS`
|
||||
- Spread 17 days after a patch to the vulnerability was released by Microsoft
|
||||
- Buffer overflow in the Local Security and Authority Subsystem Service `LSASS`
|
||||
- Scans IP addresses and infects via port 445
|
||||
- SQL Slammer - fastest spreading worm, crashed the internet (only 376 bytes or 1 UDP packet)
|
||||
- Even when the network was crippled, the occasional UDP packet could be transmitted and further damage the network
|
||||
- MS Blaster - Windows XP mainly, crashes RPC and reboots your machine
|
||||
- Spreading between machines on an internal network easily, no port filtering
|
||||
- Used a buffer overflow in a Windows Remote Procedure Call (RPC) service - spreads without the user clicking
|
||||
- Compromised machines performed DDOS on `windowsupdate.com`
|
||||
- Netsky - Infected email attachment, actually removed other worms as part of a *worm war*
|
||||
- Sasser - From the author of Netsky, attacks Windows `LSASS`
|
||||
- Spread 17 days after a patch to the vulnerability was released by Microsoft
|
||||
- Buffer overflow in the Local Security and Authority Subsystem Service `LSASS`
|
||||
- Scans IP addresses and infects via port 445
|
||||
|
||||
#### Exploit Life Cycle
|
||||
|
||||
@@ -88,39 +88,39 @@
|
||||
###### Stuxnet
|
||||
|
||||
- Believed to be an American-Israeli cyber weapon
|
||||
1. Uses *four zero-day flaws* to infect Windows
|
||||
2. Seeks out any instance of `Siemens Step7`
|
||||
3. Finds programmable logic controllers (PLC)
|
||||
4. Detects attached centrifuges and spins them to destruction
|
||||
5. Reports that the centrifuges are fine
|
||||
1. Uses *four zero-day flaws* to infect Windows
|
||||
2. Seeks out any instance of `Siemens Step7`
|
||||
3. Finds programmable logic controllers (PLC)
|
||||
4. Detects attached centrifuges and spins them to destruction
|
||||
5. Reports that the centrifuges are fine
|
||||
|
||||
### Trojans
|
||||
|
||||
- A malicious program pretending to be a legitimate application
|
||||
- Often obtained in email attachments or at malicious websites
|
||||
- Don’t replicated themselves - *user error*
|
||||
- Randomware is the most common form of Trojan now
|
||||
- Don’t replicate themselves - *user error*
|
||||
- Ransomware is the most common form of Trojan now
|
||||
|
||||
#### Notable Trojans
|
||||
|
||||
- 1989: The AIDS Trojan, encrypts all files filenames on the system and request random
|
||||
- 2002: Beast, affects windows machines from 95-XP and provides the attack with a remote admin tool (RAT) - there are a lot of these types
|
||||
- 2013: Cryptolocker - massive randomware
|
||||
- 1989: The AIDS Trojan, encrypts all files’ filenames on the system and requests ransom
|
||||
- 2002: Beast, affects Windows machines from 95-XP and provides the attacker with a remote admin tool (RAT) - there are a lot of these types
|
||||
- 2013: Cryptolocker - massive ransomware
|
||||
|
||||
##### Ransomware
|
||||
|
||||
- Will usually encrypt or block access to files and demand ransom
|
||||
- It is a clever solution, because if an anti-virus removes it, it is often too late
|
||||
- Usually distributed on malicious websites, or to already infected machines
|
||||
- The file decryption keys are protected by encrpyting using the *public key of a C&C server*
|
||||
- The file decryption keys are protected by encrypting using the *public key of a C&C server*
|
||||
|
||||
###### Ransomware Variants
|
||||
|
||||
- Most the challenge in successfully using randomware is tricking a user into running it, and bypassing anti-virus and browser protection
|
||||
- Fake emails
|
||||
- Malicious web pages
|
||||
- Obfuscated javascript attachments
|
||||
- Deployed using *exploit kits*
|
||||
- Most of the challenge in successfully using ransomware is tricking a user into running it, and bypassing anti-virus and browser protection
|
||||
- Fake emails
|
||||
- Malicious web pages
|
||||
- Obfuscated JavaScript attachments
|
||||
- Deployed using *exploit kits*
|
||||
|
||||
##### CryptoWall JS Example
|
||||
|
||||
@@ -136,6 +136,6 @@
|
||||

|
||||
|
||||
- This was exploited almost immediately
|
||||
- Extremely easy to use the API
|
||||
- Monero mining is pretty easy even on a CPU
|
||||
- JavaScript is easy to inject onto websites via adverts
|
||||
- Extremely easy to use the API
|
||||
- Monero mining is pretty easy even on a CPU
|
||||
- JavaScript is easy to inject onto websites via adverts
|
||||
@@ -7,9 +7,9 @@
|
||||
|
||||
- In C and C++, the programmer performs memory management
|
||||
- Flexible, powerful, fast but dangerous
|
||||
- Buffer Overruns
|
||||
- Stack Overruns
|
||||
- Heap Overruns
|
||||
- Buffer Overruns
|
||||
- Stack Overruns
|
||||
- Heap Overruns
|
||||
- Memory-managed languages avoid this, but of course may have their own vulnerabilities
|
||||
|
||||
### Buffer Overflows
|
||||
@@ -51,7 +51,7 @@ void main()
|
||||
###### Stack Smashing
|
||||
|
||||
- In C and C++, low level functions like `strcpy` perform no bounds checking at all
|
||||
- This is partly due to the fact strings are null terminated, if we provide no null character `strcpy` will continue to run
|
||||
- This is partly due to the fact strings are null terminated, if we provide no null character `strcpy` will continue to run
|
||||
- If `str` is long, we can write into other memory
|
||||
|
||||
```c
|
||||
@@ -68,7 +68,7 @@ void function(char *str)
|
||||
|
||||
###### Stack Canaries
|
||||
|
||||
- Stack canaries modify the prologue and epilogue of all functions to check a value ion front of the return address is unchanged
|
||||
- Stack canaries modify the prologue and epilogue of all functions to check a value in front of the return address is unchanged
|
||||
|
||||

|
||||
|
||||
@@ -77,7 +77,7 @@ void function(char *str)
|
||||
###### Data Execution Prevention (NX)
|
||||
|
||||
- Modern operating systems will mark the stack as non-executable
|
||||
- `NX` on AMD, `XD` on Intel and `XN` on arm
|
||||
- `NX` on AMD, `XD` on Intel and `XN` on ARM
|
||||
- An `NX` stack means that adding in our exploit code won’t work
|
||||
- We can circumvent this using a `return-to-libc` attack
|
||||
|
||||
@@ -85,12 +85,12 @@ void function(char *str)
|
||||
|
||||
- To defeat `ret2lib2` various `0x0` null bytes are inserted into standard library addresses
|
||||
- Developers also restrict access to obvious system calls
|
||||
- Address Space Layout Randomisation (`ASLR`) moves the address of library and programs around
|
||||
- They don’t have to move too much before your hand-crafted `ret` addresses will break
|
||||
- Address Space Layout Randomisation (`ASLR`) moves the addresses of libraries and programs around
|
||||
- They don’t have to move too much before your hand-crafted `ret` addresses will break
|
||||
|
||||
###### Return-Oriented Programming
|
||||
|
||||
- Lets forget about injecting code, how about just using existing code in the actual exploitable program
|
||||
- Let’s forget about injecting code, how about just using existing code in the actual exploitable program
|
||||
- No individual section of this program will do what we want
|
||||
- Find short sections, *gadgets* and link them together
|
||||
|
||||
@@ -109,13 +109,13 @@ void function(char *str)
|
||||
##### Heartbleed
|
||||
|
||||
- Heartbleed is a bug in `OpenSSL`
|
||||
- Open source `SSL` library
|
||||
- Started in `OpenBSD`
|
||||
- Used almost *everywhere*
|
||||
- Open source `SSL` library
|
||||
- Started in `OpenBSD`
|
||||
- Used almost *everywhere*
|
||||
- Specifically targeted the heartbeat extension
|
||||
- Extension to regular `SSL` and used for keep-alive purposes, to stop quiet connections being closed
|
||||
- Client sends a message to the server to say it’s alive
|
||||
- Server responds (also alive)
|
||||
- Extension to regular `SSL` and used for keep-alive purposes, to stop quiet connections being closed
|
||||
- Client sends a message to the server to say it’s alive
|
||||
- Server responds (also alive)
|
||||
|
||||

|
||||
|
||||
@@ -142,6 +142,6 @@ if (r >= 0 && s->msg_callback)
|
||||
s, s->msg_callback_arg);
|
||||
```
|
||||
|
||||
This bug would just memcpy a bunch of the server’s ram and send it back to the client. This can expose RSA keys.
|
||||
This bug would just memcpy a bunch of the server’s RAM and send it back to the client. This can expose RSA keys.
|
||||
|
||||
This is called a **buffer overread** attack.
|
||||
This is called a **buffer overread** attack.
|
||||
@@ -7,18 +7,18 @@
|
||||

|
||||
|
||||
- IP is connection-less and state-less
|
||||
- Best effort service
|
||||
- No delivery guarantee
|
||||
- No order guarantee
|
||||
- Best effort service
|
||||
- No delivery guarantee
|
||||
- No order guarantee
|
||||
- IPv4 No guaranteed security support
|
||||
- IPv6 security support is guaranteed - IPSec
|
||||
|
||||
#### IPSec
|
||||
|
||||
- Optional in IPv4, mandatory support in IPv6
|
||||
- Optional in IPv4, mandatory support in IPv6
|
||||
- Two major security mechanisms
|
||||
- IP Authentication Header (AH)
|
||||
- IP Encapsulation Security Payload (ESP)
|
||||
- IP Authentication Header (AH)
|
||||
- IP Encapsulation Security Payload (ESP)
|
||||
- Does not contain any mechanisms to prevent traffic analysis
|
||||
|
||||
##### Encapsulation Security Payload
|
||||
@@ -31,7 +31,7 @@
|
||||
|
||||
- Stores security parameters e.g. crypto protocol and keys
|
||||
- Established by Internet Security association and key management protocol (ISAKMP) during the Internet Key Exchange (IKE) handshake
|
||||
- Uses Diffie-Hellman for key exchange
|
||||
- Uses Diffie-Hellman for key exchange
|
||||
- The SPI references the entry in a table that corresponds to this session’s parameters
|
||||
|
||||
- ESP uses either *transport* or *tunnel* modes
|
||||
@@ -60,14 +60,14 @@ Tunnel mode
|
||||
#### ARP
|
||||
|
||||
- ARP is a protocol used to obtain physical MAC addresses for given IPs
|
||||
- It is used prior to constructing IP and TCP packets for communication
|
||||
- Network layer
|
||||
- It is used prior to constructing IP and TCP packets for communication
|
||||
- Network layer
|
||||
|
||||

|
||||
|
||||
##### ARP Cache Poisoning
|
||||
|
||||
- We can simply send an unrequested ARP reply, and overwrite the MAC address in a hosts ARP cache with our own
|
||||
- We can simply send an unrequested ARP reply, and overwrite the MAC address in a host’s ARP cache with our own
|
||||
|
||||

|
||||
|
||||
@@ -75,14 +75,14 @@ Tunnel mode
|
||||
|
||||
- Some OSs ignore unsolicited ARP requests, or can be configured to use ARP differently
|
||||
- Some software, such as intrusion detection packages, will include ARP spoofing detection
|
||||
- Maintain a log of current MAC:IP assignments and ARP requests / replies
|
||||
- Maintain a log of current MAC:IP assignments and ARP requests / replies
|
||||
|
||||
#### DNS
|
||||
|
||||
- DNS translates domain names into IP addresses
|
||||
- DNS packets are UDP
|
||||
- Stateless on the transport layer
|
||||
- DNS resolvers will cache the IP for awhile
|
||||
- Stateless on the transport layer
|
||||
- DNS resolvers will cache the IP for a while
|
||||
|
||||
##### DNS Spoofing
|
||||
|
||||
@@ -99,24 +99,24 @@ Tunnel mode
|
||||
|
||||
### Denial of Service
|
||||
|
||||
- A denial of service attack is an attempt to make a machine or network resource unavaliable to its authorised / intended users
|
||||
- This will usually involve flooding a machine with enough requests that it can’t server its legitimate purpose
|
||||
- ping flood
|
||||
- A denial of service attack is an attempt to make a machine or network resource unavailable to its authorised / intended users
|
||||
- This will usually involve flooding a machine with enough requests that it can’t serve its legitimate purpose
|
||||
- ping flood
|
||||
- A distributed denial of service occurs where there is more than one attacking machine
|
||||
|
||||
#### TCP Syn Flooding
|
||||
|
||||
- Attacker initiates a genuine connection but then immediately breaks it
|
||||
- Attack never finishes 3-way handshake
|
||||
- Attack never finishes 3-way handshake
|
||||
- Victim is busy with the timeout
|
||||
- Attack initiates large number of syn requests
|
||||
- Victim reaches it’s half-open connection limit
|
||||
- Victim reaches its half-open connection limit
|
||||
|
||||

|
||||
|
||||
#### Amplification Attacks
|
||||
|
||||
- Regular attacks are your bandwidth vs your targets
|
||||
- Regular attacks are your bandwidth vs your target’s
|
||||
- Amplification attacks utilise some aspect of a network protocol to *increase the bandwidth* of an attack
|
||||
|
||||

|
||||
@@ -136,26 +136,25 @@ Tunnel mode
|
||||

|
||||
|
||||
- In an ideal world, all DNS resolvers would:
|
||||
- Use an authorised list of requesters
|
||||
- e.g. ISPs allowing requests from only their customers
|
||||
- Egress filtering
|
||||
- Use an authorised list of requesters
|
||||
- e.g. ISPs allowing requests from only their customers
|
||||
- Egress filtering
|
||||
- Many DNS servers are set up incorrectly, and will happily amplify your traffic - **Open resolvers**
|
||||
- Botnets maintain lists of these open resolvers and there are projects attempting to shut these down
|
||||
|
||||
##### NTP Amplification
|
||||
|
||||
- NTP is a protocol for synchronsing time between machines
|
||||
- NTP is a protocol for synchronising time between machines
|
||||
- Extremely similar to DNS amplification
|
||||
- `MON_GETLIST` request returns the list of the last 600 contacts
|
||||
- Gives 200x amplification
|
||||
- `MON_GETLIST` is deprecated because of this attack
|
||||
- `MON_GETLIST` request returns the list of the last 600 contacts
|
||||
- Gives 200x amplification
|
||||
- `MON_GETLIST` is deprecated because of this attack
|
||||
|
||||
##### Slow Loris
|
||||
|
||||
- Opens numerous connections to a server
|
||||
- Begin an HTTP request
|
||||
- Send just enough traffic to stop the connection from closing
|
||||
- Apache2 creates a new thread for each connection
|
||||
- More connections slow the server down significantly
|
||||
- Send just enough traffic to stop the connection from closing
|
||||
- Apache2 creates a new thread for each connection
|
||||
- More connections slow the server down significantly
|
||||
- The attack only sends bytes of data at a time making it extremely easy to do
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
- A hardware and/or software system
|
||||
- Prevents unauthorised access of packets from one network to another
|
||||
- All data leave any subnet must pass through it
|
||||
- All data leaving any subnet must pass through it
|
||||
|
||||

|
||||
|
||||
@@ -22,7 +22,7 @@
|
||||
|
||||
#### DMZ
|
||||
|
||||
- A demilitarised zone is a small subnet that separates exrternally facing services from the internal network
|
||||
- A demilitarised zone is a small subnet that separates externally facing services from the internal network
|
||||
|
||||

|
||||
|
||||
@@ -33,45 +33,45 @@
|
||||
- Defends a network against parties accessing *internal services*
|
||||
- Can also restrict access from *inside to outside* services
|
||||
- Network Address Translation
|
||||
- Hides the internal machines with private addresses
|
||||
- Hides the internal machines with private addresses
|
||||
|
||||
**Firewalls are not enough**
|
||||
|
||||
- Cannot protect against attacks that bypass the firewall
|
||||
- e.g. tunneling
|
||||
- e.g. tunnelling
|
||||
- Cannot protect against internal threats or insiders
|
||||
- Might help a bit by egress filtering
|
||||
- Might help a bit by egress filtering
|
||||
- Network firewalls cannot always protect against the transfer of virus-infected programs or files
|
||||
|
||||
#### Packet Filters
|
||||
|
||||
- Specify which packets are *allowed or dropped*
|
||||
- Rules based on:
|
||||
- Source / destination IP
|
||||
- TCP / UDP port numbers
|
||||
- Source / destination IP
|
||||
- TCP / UDP port numbers
|
||||
- Possible for both *inbound* and *outbound* traffic
|
||||
- Can be implemented in a router by only examining packet headers (**IP / TCP**)
|
||||
|
||||
##### Packet Filter Rules
|
||||
|
||||
- Rule execution depends on implementation
|
||||
- `IPTABLES`: **First** rule to match is applied
|
||||
- `PF`: All rules are examined, **last** match is applied
|
||||
- `IPTABLES`: **First** rule to match is applied
|
||||
- `PF`: All rules are examined, **last** match is applied
|
||||
- Rules are organised in *chains*, which are logical subgroups of rules
|
||||
- Depending on the packet, different chains are activated
|
||||
|
||||
###### IPTABLES
|
||||
|
||||
- An application that provides access to the Linux firewall rule tables
|
||||
- Not actually a firewall, but configures the firewall
|
||||
- The firewall is mostly implemented as `netfilter` modules
|
||||
- Not actually a firewall, but configures the firewall
|
||||
- The firewall is mostly implemented as `netfilter` modules
|
||||
|
||||
###### Tables and Chains
|
||||
|
||||
- `IPTABLES` uses tables to store chains
|
||||
- Default is the filtering table
|
||||
- Default is the filtering table
|
||||
- Chains are ordered in lists of rules
|
||||
- Rules match, or they don’t
|
||||
- Rules match, or they don’t
|
||||
- Matches result in a **jump**, else we check the next rule.
|
||||
|
||||

|
||||
@@ -79,7 +79,7 @@
|
||||
Default policy on this chain is `DROP`
|
||||
|
||||
- There can be multiple chains per table
|
||||
- e.g. a `TCP` handling chain
|
||||
- e.g. a `TCP` handling chain
|
||||
- Jumps can go to `ACCEPT`, `DROP`, `LOG` or another chain
|
||||
- Complex behaviour can be built up
|
||||
|
||||
@@ -88,10 +88,10 @@ Default policy on this chain is `DROP`
|
||||
##### Defaults
|
||||
|
||||
- There are four built-in tables in `IPTABLES`
|
||||
- Filter
|
||||
- `NAT`
|
||||
- Mangle - packet alteration
|
||||
- Raw - skips connection tracking
|
||||
- Filter
|
||||
- `NAT`
|
||||
- Mangle - packet alteration
|
||||
- Raw - skips connection tracking
|
||||
- The default table is the filtering table, including input, output and forward chains
|
||||
|
||||

|
||||
@@ -105,14 +105,14 @@ $ iptables -A INPUT -i eht0 -p tcp --dport 80 -j ACCEPT
|
||||
$ iptables -A OUTPUT -i eht0 -p tcp --sport 80 -j ACCEPT
|
||||
```
|
||||
|
||||
- Remember `http` requests are not sent from the client’s port 80, it is sent from a random high numbered port
|
||||
- This is how clients can have multiple web requests open at the same time
|
||||
- Remember `http` requests are not sent from the client’s port 80; they are sent from a random high-numbered port
|
||||
- This is how clients can have multiple web requests open at the same time
|
||||
|
||||
##### Policies
|
||||
|
||||
- **Permissive** - allow everything by default except dangerous services
|
||||
- Make a black list
|
||||
- Easy to make a mistake or forget something
|
||||
- Make a black list
|
||||
- Easy to make a mistake or forget something
|
||||
|
||||
```bash
|
||||
iptables -p INPUT ACCEPT
|
||||
@@ -124,8 +124,8 @@ iptables -A OUTPUT -p tcp --dport ssh -j DROP
|
||||
```
|
||||
|
||||
- **Restrictive** - block everything except designated useful services
|
||||
- Make a white list
|
||||
- More secure by default
|
||||
- Make a white list
|
||||
- More secure by default
|
||||
|
||||
```bash
|
||||
iptables -p INPUT DROP
|
||||
@@ -139,17 +139,17 @@ iptables -A OUTPUT -s 192.168.0.2 -j ACCEPT
|
||||
#### Packet Filter Issues
|
||||
|
||||
- Packet filters are simple, low-level and have high assurance
|
||||
- However they cannot:
|
||||
- Prevent attacks that employ application specific vulnerabilities
|
||||
- Do not support higher-level authentication schemes
|
||||
- Easy to accidentally allow or deny packets incorrectly
|
||||
- However:
|
||||
- They cannot prevent attacks that employ application-specific vulnerabilities
|
||||
- Do not support higher-level authentication schemes
|
||||
- Easy to accidentally allow or deny packets incorrectly
|
||||
|
||||
### Stateful Packet Filters
|
||||
|
||||
- Understand requests and replies (`ACK/SYN`)
|
||||
- Dynamically generate rules
|
||||
- Based on what it sees from TCP handshakes (can be FTP or SSH etc)
|
||||
- Can support policies for a wider range or protocols
|
||||
- Based on what it sees from TCP handshakes (can be FTP or SSH etc)
|
||||
- Can support policies for a wider range of protocols
|
||||
- `IPTABLES` has a module for stateful packet filtering
|
||||
- Allow incoming / outgoing SSH connections
|
||||
|
||||
@@ -166,7 +166,7 @@ iptables -A OUTPUT -s 192.168.0.2 -j ACCEPT
|
||||
|
||||
- Packet filters have limited criteria that allow data in and out
|
||||
- An application gateway considers the *application-layer* protocol that is in use
|
||||
- For example if someone sends an `HTTP` request to port 22, it is blocked
|
||||
- For example if someone sends an `HTTP` request to port 22, it is blocked
|
||||
|
||||
##### Proxy Server
|
||||
|
||||
@@ -184,11 +184,11 @@ iptables -A OUTPUT -s 192.168.0.2 -j ACCEPT
|
||||
|
||||
### Network Address Translation
|
||||
|
||||
The shortage of IP addresses mean that most routers now perform NAT automatically
|
||||
The shortage of IP addresses means that most routers now perform NAT automatically
|
||||
|
||||

|
||||
|
||||
- The implicit advantage in NAT is that your machine is almost totally hidden from the internet
|
||||
- Only **established connections** are forwarded to your internal machine
|
||||
- Or, specific **port forwarding** rules
|
||||
- This prevents any unsolicited attacks on random ports, but no other types of attack
|
||||
- Or, specific **port forwarding** rules
|
||||
- This prevents any unsolicited attacks on random ports, but no other types of attack
|
||||
@@ -1,10 +1,10 @@
|
||||
# Internet Security
|
||||
|
||||
#### Internet Treat Models
|
||||
#### Internet Threat Models
|
||||
|
||||
- Different to other treat models:
|
||||
- The attacker isn’t in control of the network
|
||||
- The attacker hasn’t got access to the target’s OS
|
||||
- Different to other threat models:
|
||||
- The attacker isn’t in control of the network
|
||||
- The attacker hasn’t got access to the target’s OS
|
||||
|
||||
## Cookies
|
||||
|
||||
@@ -22,79 +22,81 @@
|
||||
- **Persistent** - Expire at a given time
|
||||
- **Secure** - Can only be used over `HTTPS`
|
||||
- `HTTPOnly` - Inaccessible to `js`
|
||||
- Makes it harder to steal
|
||||
- Makes it harder to steal
|
||||
|
||||
##### Third Party Cookies
|
||||
|
||||
- Cookies are associated with the domains that produced them
|
||||
- `amazon.com` cookies don’t go to `google.com`
|
||||
- Some websites include request to other domains, such as 3rd party advertisers
|
||||
- These serve cookies *a lot*
|
||||
- This is how advertiser companies know what ads you’ve been served and what adverts you’ve clicked on
|
||||
- `amazon.com` cookies don’t go to `google.com`
|
||||
- Some websites include requests to other domains, such as 3rd party advertisers
|
||||
- These serve cookies *a lot*
|
||||
- This is how advertiser companies know what ads you’ve been served and what adverts you’ve clicked on
|
||||
|
||||
### Cookie Vulnerabilities
|
||||
|
||||
- How a website uses a cookies is up to the server
|
||||
- How a website uses a cookie is up to the server
|
||||
- Many create a `SID` to authenticate users, for example to *keep me logged on*
|
||||
- Obtaining this cookie - *cookie stealing* - lets you **hijack** their session
|
||||
- `HTTP` Cookies can be stolen simply by monitoring
|
||||
- `HTTPS` will require cross-site scripting attacks or DNS poisoning
|
||||
- `HTTP` Cookies can be stolen simply by monitoring
|
||||
- `HTTPS` will require cross-site scripting attacks or DNS poisoning
|
||||
|
||||
#### Cross-site Scripting (XSS)
|
||||
|
||||
- A type of *injection attack*, similar in many ways to an SQL injection
|
||||
- HTML is read by a browser and is a combination of content and structure
|
||||
- If we can inject `html` structures into the content of a website, the browser will simply execute these
|
||||
- e.g. a `<script>` tag
|
||||
- If we can inject `html` structures into the content of a website, the browser will simply execute these
|
||||
- e.g. a `<script>` tag
|
||||
|
||||
##### Reflected XSS
|
||||
|
||||
- A malicious URL that inserts an exploit directly into the page returned by a server
|
||||
- Consider a 404 page at some address
|
||||
- If we embed code into the url
|
||||
- 
|
||||
- Modern browsers will throw up a warning
|
||||
|
||||
- 
|
||||
|
||||
- Modern browsers will throw up a warning
|
||||
|
||||
##### Persistent XSS
|
||||
|
||||
- Even worse, no need to trick people into clicking links
|
||||
- Any website that doesn’t properly sanitise `html` tags from user input is vulnerable
|
||||
- Blog posts with comment sections are obvious targets
|
||||
- Forums, web comments, shopping reviews
|
||||
- Forums, web comments, shopping reviews
|
||||
|
||||
###### The Samy Worm
|
||||
|
||||
- In 2005 Samy Kamkar wrote an XSS-based attack on MySpace
|
||||
- 
|
||||
- Fastest spreading virus of all time
|
||||
|
||||
- 
|
||||
|
||||
- Fastest spreading virus of all time
|
||||
|
||||
### Preventing XSS
|
||||
|
||||
- Wesbites must aggressively escape html characters from *any* user input / output
|
||||
1. Locate all positions in which a website handles untrusted data
|
||||
2. Escape appropriately depending on type of input
|
||||
- When you consider all of the things people input on interactive websites, this can be a rela problem
|
||||
- Websites must aggressively escape HTML characters from *any* user input / output
|
||||
1. Locate all positions in which a website handles untrusted data
|
||||
2. Escape appropriately depending on type of input
|
||||
- When you consider all of the things people input on interactive websites, this can be a real problem
|
||||
- You also need to find all of the bizarre obfuscated versions of XSS
|
||||
- Use an encoding library, which will handle all of these edge cases
|
||||
|
||||
### Cross site Request Forgery (XSRF)
|
||||
|
||||
- When a user puts in a `HTTP` request, they will also send any relevant session cookies
|
||||
- e.g. an `SID` from having logged in
|
||||
- If the user has already authenticated, a malicious URl can then perform some action on their account
|
||||
- `http://shop.com/account.php?act=editemail&e=attacker@mail.com`
|
||||
- e.g. an `SID` from having logged in
|
||||
- If the user has already authenticated, a malicious URL can then perform some action on their account
|
||||
- `http://shop.com/account.php?act=editemail&e=attacker@mail.com`
|
||||
|
||||
#### XSRF in POST
|
||||
|
||||
- Most websites use POST, this is little defence
|
||||
- The phishing email just points to a convincing website with a malicious form on it
|
||||
- 
|
||||
|
||||
- 
|
||||
|
||||
#### Preventing XSRF
|
||||
|
||||
- XSS vulenerabilties make XSRF a lot easier
|
||||
- XSS vulnerabilities make XSRF a lot easier
|
||||
- Use **synchroniser tokens**
|
||||
- Each website form has a one-time token that the server validates when the form is submitted
|
||||
|
||||
|
||||
|
||||
- Each website form has a one-time token that the server validates when the form is submitted
|
||||
@@ -9,9 +9,9 @@
|
||||
#### SQL Security
|
||||
|
||||
- Three entities
|
||||
1. Users
|
||||
2. Actions
|
||||
3. Objects
|
||||
1. Users
|
||||
2. Actions
|
||||
3. Objects
|
||||
- Users invoke actions on objects
|
||||
- Newly created objects are owned by the creator
|
||||
- Privileges can be granted
|
||||
@@ -41,7 +41,7 @@ This view abstracts the drugs away from the patients, so that the admin can orde
|
||||
|
||||
##### Why Not?
|
||||
|
||||
- `INSERT` / `UPDATE` actions depends on the `CHECK` options, else might be **blind inserts**
|
||||
- `INSERT` / `UPDATE` actions depend on the `CHECK` options, else might be **blind inserts**
|
||||
- This is where someone can’t access the data, but can update it
|
||||
- Completeness and consistency are not achieved automatically
|
||||
- Can quickly become very inefficient
|
||||
@@ -49,7 +49,7 @@ This view abstracts the drugs away from the patients, so that the admin can orde
|
||||
|
||||
#### Statistical Databases
|
||||
|
||||
- Where access to data is restricted access to aggregates is permitted
|
||||
- Where access to data is restricted, access to aggregates is permitted
|
||||
- This means averages, sums can be looked at
|
||||
- However, individual records cannot be viewed
|
||||
|
||||
@@ -93,7 +93,7 @@ Salary = V + T + U - S
|
||||
|
||||
- It’s common for user input to be read and then used within an SQL query
|
||||
- Unexpected user input can completely rewrite the query
|
||||
- Nears striking similarities to XSS attack
|
||||
- Bears striking similarities to an XSS attack
|
||||
- An application or website is vulnerable to an injection if it doesn’t filter SQL control characters:
|
||||
- `‘` Represents the beginning or end of a string
|
||||
- `;` represents end of a command
|
||||
@@ -123,5 +123,5 @@ This will work on `MS SQL` but not `MySQL`
|
||||
|
||||
#### Second Order SQL Injection
|
||||
|
||||
- Entry points may be checked for speical characters, but internal functions?
|
||||
- Store the exploit in one pass, then have it executed later
|
||||
- Entry points may be checked for special characters, but internal functions?
|
||||
- Store the exploit in one pass, then have it executed later
|
||||
@@ -1,29 +1,32 @@
|
||||
### Anti-Virus
|
||||
|
||||
- Signature-based detection
|
||||
- Store some small code signature for each virus
|
||||
- Scan files either in bulk or at run-time, compare with the signatures on file
|
||||
- Generic signatures
|
||||
- Hashing the entire file is a bad idea, the author only needs to add a `nop` to completely change the signature
|
||||
- Also hashing every executable is slow
|
||||
- Instead we identify key pieces of the malware and hash that
|
||||
- 
|
||||
- This method is never going to catch a virus it’s never seen before
|
||||
- Store some small code signature for each virus
|
||||
- Scan files either in bulk or at run-time, compare with the signatures on file
|
||||
- Generic signatures
|
||||
- Hashing the entire file is a bad idea, the author only needs to add a `nop` to completely change the signature
|
||||
- Also hashing every executable is slow
|
||||
- Instead we identify key pieces of the malware and hash that
|
||||
|
||||
- 
|
||||
|
||||
- This method is never going to catch a virus it’s never seen before
|
||||
- Heuristics
|
||||
- Determine what actions and rules a virus program will normally adopt
|
||||
- Start the program in a `VM` and see what it does
|
||||
- Theoretically could detect a virus that doesn’t strictly match some signature
|
||||
- Only if it does the same thing as a virus its seen before
|
||||
- A lot slower than signature detection as it needs to be run in a VM before the user is allowed to open it
|
||||
- What if the virus sleeps for 20 seconds before doing anything? very hard to detect
|
||||
- Determine what actions and rules a virus program will normally adopt
|
||||
- Start the program in a `VM` and see what it does
|
||||
- Theoretically could detect a virus that doesn’t strictly match some signature
|
||||
- Only if it does the same thing as a virus it’s seen before
|
||||
- A lot slower than signature detection as it needs to be run in a VM before the user is allowed to open it
|
||||
- What if the virus sleeps for 20 seconds before doing anything? very hard to detect
|
||||
- Machine learning
|
||||
- 
|
||||
|
||||
- 
|
||||
|
||||
### Network Attack Models
|
||||
|
||||
- Firewalls don’t protect against
|
||||
- Attacks using valid protocols
|
||||
- Insider attacks
|
||||
- Attacks using valid protocols
|
||||
- Insider attacks
|
||||
|
||||
Intrusion **Detection** Systems (IDS)
|
||||
|
||||
@@ -37,20 +40,20 @@ Intrusion **Prevention** Systems (IPS)
|
||||
#### IDS Deployment
|
||||
|
||||
- Host-based (HIDS)
|
||||
- Monitors a *single host* to find suspicious activity including resource / app usage
|
||||
- In many ways modern anti-virus does this
|
||||
- Additional layer of security software running on a host within a protected LAN or VPN
|
||||
- Creates a profile of usage for specific users
|
||||
- Can monitor CPU, memory use, application use and the network stack
|
||||
- Monitors a *single host* to find suspicious activity including resource / app usage
|
||||
- In many ways modern anti-virus does this
|
||||
- Additional layer of security software running on a host within a protected LAN or VPN
|
||||
- Creates a profile of usage for specific users
|
||||
- Can monitor CPU, memory use, application use and the network stack
|
||||
- Network-based (NIDS)
|
||||
- Monitors **network traffic** and analyses packets from different protocols to identify suspicious activity
|
||||
- Placed at a viewpoint on a network to examine and analyse traffic
|
||||
- Installed on a firewall or in a DMZ
|
||||
- Installed behind a screened subnet
|
||||
- May perform deeper analysis than many firewalls
|
||||
- like stateful protocol analysis and deep packet inspection
|
||||
- Monitors **network traffic** and analyses packets from different protocols to identify suspicious activity
|
||||
- Placed at a viewpoint on a network to examine and analyse traffic
|
||||
- Installed on a firewall or in a DMZ
|
||||
- Installed behind a screened subnet
|
||||
- May perform deeper analysis than many firewalls
|
||||
- like stateful protocol analysis and deep packet inspection
|
||||
|
||||
##### Components of a IDS
|
||||
##### Components of an IDS
|
||||
|
||||
- Sensors / Agents: collect and collate data from multiple viewpoints on a network
|
||||
- Analysers: ascertain if an intrusion has taken place
|
||||
@@ -61,58 +64,66 @@ Intrusion **Prevention** Systems (IPS)
|
||||
##### Detection Modes
|
||||
|
||||
- **Stateful Protocol analysis**
|
||||
- More complex version of a stateful packet filter
|
||||
- Hold detailed session information on protocols being used, examine for attacks
|
||||
- Why is this user logging on as root?
|
||||
- Why is this command being send a 1000 byte buffer as a parameter (buffer overflow)
|
||||
- Computationally costly and requires the IDS have all possible versions of these protocols defined in its database
|
||||
- More complex version of a stateful packet filter
|
||||
- Hold detailed session information on protocols being used, examine for attacks
|
||||
- Why is this user logging on as root?
|
||||
- Why is this command being sent a 1000-byte buffer as a parameter (buffer overflow)
|
||||
- Computationally costly and requires the IDS to have all possible versions of these protocols defined in its database
|
||||
- **Signature-based**
|
||||
- Fingerprinting sequences of operations or packets
|
||||
- Like antivirus, signatures are created and stored in a database - operations as well as binaries
|
||||
- If operations match a defined singature, then an alarm is triggered
|
||||
- Include some form of attack language
|
||||
- Mechanisms to describe sequences of events
|
||||
- Maintain and monitor intermediate states and event transitions
|
||||
- The pros and cons of these systems are identical to their anti-virus counterpart
|
||||
- Computationally efficient
|
||||
- Always spots know attacks
|
||||
- Always misses unknown attacks
|
||||
- Detailed signature databases must be kept up-to-date
|
||||
- Example: If there is a large amount of `ICMP` traffic, many `TCP` packets (`SYN` packets)
|
||||
- These connections going to a variety of other hosts
|
||||
- *If a host establishes more than 3 tcp connections to different hosts in 5 seconds, its port scanning*
|
||||
- Fingerprinting sequences of operations or packets
|
||||
- Like antivirus, signatures are created and stored in a database - operations as well as binaries
|
||||
- If operations match a defined signature, then an alarm is triggered
|
||||
- Include some form of attack language
|
||||
- Mechanisms to describe sequences of events
|
||||
- Maintain and monitor intermediate states and event transitions
|
||||
- The pros and cons of these systems are identical to their anti-virus counterpart
|
||||
- Computationally efficient
|
||||
- Always spots known attacks
|
||||
- Always misses unknown attacks
|
||||
- Detailed signature databases must be kept up-to-date
|
||||
- Example: If there is a large amount of `ICMP` traffic, many `TCP` packets (`SYN` packets)
|
||||
- These connections going to a variety of other hosts
|
||||
- *If a host establishes more than 3 tcp connections to different hosts in 5 seconds, it’s port scanning*
|
||||
- **Anomaly-based**
|
||||
- Built a model of *normal* and find deviations
|
||||
- Anomaly detection has wide-ranging application from IDS to banking fraud
|
||||
- Build up a picture of normal usage, and detect when usage moves beyond what is normal
|
||||
- Always a trade off between **false positives** and **false negatives**
|
||||
- 
|
||||
- Run a host within a quarantined environment and collect training data
|
||||
- Constructed by monitoring audit logs
|
||||
- Sometimes rely on analysis of sequences of system calls through normal behaviour
|
||||
- 
|
||||
- However network traffic is more complex than a normal curve
|
||||
- 
|
||||
- Very hard to decide if network traffic is nefarious or not
|
||||
- Build a model of *normal* and find deviations
|
||||
- Anomaly detection has wide-ranging application from IDS to banking fraud
|
||||
- Build up a picture of normal usage, and detect when usage moves beyond what is normal
|
||||
- Always a trade-off between **false positives** and **false negatives**
|
||||
|
||||
- 
|
||||
|
||||
- Run a host within a quarantined environment and collect training data
|
||||
- Constructed by monitoring audit logs
|
||||
- Sometimes rely on analysis of sequences of system calls through normal behaviour
|
||||
|
||||
- 
|
||||
|
||||
- However network traffic is more complex than a normal curve
|
||||
|
||||
- 
|
||||
|
||||
- Very hard to decide if network traffic is nefarious or not
|
||||
|
||||
###### Snort
|
||||
|
||||
- Snort is a powerful and well established IDS
|
||||
- Also free!
|
||||
- Also free!
|
||||
- Uses rules to analyse network packets, and then can provide alerts or logging
|
||||
- Snort has built in rules for detecting `nmap`m a logged scan may look like this:
|
||||
- 
|
||||
- The machine `10.0.4.1` is sending out packets with incremented port numbers
|
||||
- The time stamps on the data show the packets are being sent extremely quickly
|
||||
- All these packets are synchronised packets, its not waiting for `ACK` packets
|
||||
- Snort has built-in rules for detecting `nmap`; a logged scan may look like this:
|
||||
|
||||
- 
|
||||
|
||||
- The machine `10.0.4.1` is sending out packets with incremented port numbers
|
||||
- The time stamps on the data show the packets are being sent extremely quickly
|
||||
- All these packets are synchronised packets; it’s not waiting for `ACK` packets
|
||||
|
||||
###### Nmap Timings
|
||||
|
||||
- You can avoid detection when using `nmap` by reducing the speed of the scan
|
||||
- The makes port scanning very hard to distinguish from general network noise
|
||||
- This makes port scanning very hard to distinguish from general network noise
|
||||
- `nmap` contains 6 timing options
|
||||
- paranoid mode leaves 5 minutes between packets
|
||||
- insane mode is basically a DDOS attack
|
||||
- paranoid mode leaves 5 minutes between packets
|
||||
- insane mode is basically a DDOS attack
|
||||
|
||||
#### Machine Learning
|
||||
|
||||
@@ -128,10 +139,9 @@ Intrusion **Prevention** Systems (IPS)
|
||||

|
||||
|
||||
- Scales badly
|
||||
- Search space can increase exponentially
|
||||
- Real-time data
|
||||
- Search space can increase exponentially
|
||||
- Real-time data
|
||||
- False negatives
|
||||
- Limits in the representation
|
||||
- What is normal can change
|
||||
- Do we retrain and risk learning an intruders behaviour?
|
||||
|
||||
- Limits in the representation
|
||||
- What is normal can change
|
||||
- Do we retrain and risk learning an intruder’s behaviour?
|
||||
@@ -1,23 +1,23 @@
|
||||
## Cyber Threat Intelligence
|
||||
|
||||
- Broad Definition
|
||||
- Any information about threats that can assist decisions for preventing and mitigating an attack
|
||||
- Examples
|
||||
- Reading new papers
|
||||
- Read incident reports
|
||||
- Any information about threats that can assist decisions for preventing and mitigating an attack
|
||||
- Examples
|
||||
- Reading new papers
|
||||
- Reading incident reports
|
||||
|
||||
> “Cyber Threat intelligence is information about threats and threat actors that helps mitigate harmful events in cyberspace.” [Wikipedia, 2021; Pierluigi Paganini, 2020].
|
||||
|
||||
#### Threat Inelligence Type
|
||||
#### Threat Intelligence Type
|
||||
|
||||

|
||||
|
||||
#### Threat Intelligence Sharing
|
||||
|
||||
- Standardised language
|
||||
- **S**tructured **T**hread **I**nformation e**X**pression (STIX)
|
||||
- **S**tructured **T**hreat **I**nformation e**X**pression (STIX)
|
||||
- Standardised Exchange Mechanism
|
||||
- Trusted automated Exchange of Indicator Information (TAXII)
|
||||
- Trusted automated Exchange of Indicator Information (TAXII)
|
||||
- STIX and TAXII are to enable automated cyber threat information exchange across organisation and product boundaries
|
||||
|
||||
##### Structured Threat Information Expression
|
||||
@@ -25,8 +25,8 @@
|
||||
- Designed for sharing and analysing threat intelligence
|
||||
- Can be understood by humans
|
||||
- Structured language for automation.
|
||||
- Can be understood by security technology
|
||||
- Active community of developer and analyst
|
||||
- Can be understood by security technology
|
||||
- Active community of developers and analysts
|
||||
- International standard in OASIS
|
||||
|
||||

|
||||
@@ -45,19 +45,19 @@
|
||||
|
||||
#### Cyber Kill Chain
|
||||
|
||||
- Kill chain is a term used bu the US military
|
||||
- Kill chain is a term used by the US military
|
||||
- Lockheed Martin’s process to explain and defensively mitigate future threat
|
||||
- Deconstructs a threat to individual components
|
||||
|
||||
##### Reconnaissance
|
||||
|
||||
- The attacker research on the target before the actual attack starts
|
||||
- The attacker researches the target before the actual attack starts
|
||||
- Through Internet Search, and social media
|
||||
|
||||
##### Weaponisation
|
||||
|
||||
- The attacker develops a malicious payload and send to the victim
|
||||
- This setp happens at the attacker side, without contact with the victim
|
||||
- The attacker develops a malicious payload and sends it to the victim
|
||||
- This step happens on the attacker’s side, without contact with the victim
|
||||
- Difficult to interrupt for prevention
|
||||
- No longer requires advanced skills
|
||||
|
||||
@@ -69,9 +69,9 @@
|
||||
|
||||
- Triggers the intruders’ code
|
||||
- Targets can be
|
||||
- Application or host system
|
||||
- An operating system feature that auto-executes code
|
||||
- User’s themselves
|
||||
- Application or host system
|
||||
- An operating system feature that auto-executes code
|
||||
- Users themselves
|
||||
|
||||
##### Installation
|
||||
|
||||
@@ -88,9 +88,9 @@
|
||||
|
||||
- The attacker takes actions to achieve his original objective inside the victim’s network
|
||||
- Elaborate active attack process that may take months
|
||||
- Information Theft
|
||||
- Hacker Fame / Hactivism - Defacement
|
||||
- Extortion - Ransomware
|
||||
- Nation State Leverage
|
||||
- Destructive malware
|
||||
- A point to compromise additional systems
|
||||
- Information Theft
|
||||
- Hacker Fame / Hacktivism - Defacement
|
||||
- Extortion - Ransomware
|
||||
- Nation State Leverage
|
||||
- Destructive malware
|
||||
- A point to compromise additional systems
|
||||
Reference in new issue
Block a user