158 lines
5.3 KiB
Markdown
158 lines
5.3 KiB
Markdown
# Security
|
||
|
||
#### What is security?
|
||
|
||
Security is about the **protection of assets**
|
||
|
||
- **Prevention**: Preventing access and damage to assets
|
||
- **Detection**: Steps to detect the access or damage of assets
|
||
- **Recovery**: Measures allowing us to recover from asset damage
|
||
|
||
Assets could be physical or virtual data
|
||
|
||
##### Historic Computer Security
|
||
|
||
- 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
|
||
- 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
|
||
- More and more things are moving to electronic
|
||
- Requiring protocols to manage them
|
||
|
||
### Attacks
|
||
|
||
- Monetary transaction need security
|
||
|
||
This is what most interactions look like and therefore attacks are based on this communication
|
||
|
||
#### Eavesdropping
|
||
|
||
To prevent this we use encryption, using `HTTPS` or `TLS`
|
||
|
||
But how do we privately agree on an encryption key
|
||
|
||
###### User authentication
|
||
|
||
Is the client who they say they are
|
||
|
||
What if the server gets hacked, we can use **hash functions**
|
||
|
||
###### Digital Certificates
|
||
|
||
However, this can be bypassed if the clients machine is hacked
|
||
|
||
We have to ensure the client is running anti virus software and practices good avoidance.
|
||
|
||
###### Insider attacks
|
||
|
||
To stop this the company must practice good security such as:
|
||
|
||
- Database security Controls
|
||
- File access controls
|
||
- Intruder detection
|
||
- Security Auditing
|
||
|
||
## Definitions
|
||
|
||
There is no solid definition for *security*
|
||
|
||
- Unbreakable?
|
||
- Secure enough?
|
||
|
||
It is often simply an arms race between developers & researchers and malicious users
|
||
|
||
#### Managing Security
|
||
|
||
- 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?
|
||
- UoN security policy
|
||
- https://www.nottingham.ac.uk/dts/security/it-security.aspx
|
||
|
||
#### Computer Security
|
||
|
||
- Usually defined as three keys 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
|
||
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
|
||
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
|
||
|
||
#### Accountability
|
||
|
||
- Users should be held responsible for their actions
|
||
- The system should identify and authenticate users and ensure compliance
|
||
- Audit trails must be kept
|
||
|
||
#### Non-repudiation
|
||
|
||
- Provides unforgeable evidence that someone did something
|
||
- Mostly a legal concept
|
||
- Evidence verifiable by a trusted third party
|
||
- e.g notaries, digital certificates
|
||
- Applies to physical security as well
|
||
- 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
|
||
- Increased resource demands
|
||
- Interferes with working patterns
|
||
|
||
###### Added complexity
|
||
|
||
- Often user experience is place 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
|
||
- 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
|
||
|
||
#### 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
|
||
- 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
|