Cleaned up Literature folder
This commit is contained in:
parent
73a6380034
commit
fe5eda4e05
586 changed files with 53911 additions and 2475 deletions
|
|
@ -0,0 +1,15 @@
|
|||
# Defensive Security Handbook
|
||||
Defensive Security Handbook: Best Practices for Securing Infrastructure by Lee Brotherston, Amanda Berlin
|
||||
|
||||
[Chapter 1 - Risk Management](Def_Sec_Handbook_Chapter_1.md)
|
||||
[Chapter 2 - Asset management](Def_Sec_Handbook_Chapter_2.md)
|
||||
[Chapter 3 - Policies](Def_Sec_Handbook_Chapter_3.md)
|
||||
[Chapter 4 - User education and awareness](Def_Sec_Handbook_Chapter_4.md)
|
||||
[Chapter 5 - Incident Response](Def_Sec_Handbook_Chapter_5.md)
|
||||
[Chapter 6 - Disaster Recovery](Def_Sec_Handbook_Chapter_6.md)
|
||||
[Chapter 7 - Physical Security](Def_Sec_Handbook_Chapter_7.md)
|
||||
[Chapter 8 - Microsoft Windows Infrastructure](Def_Sec_Handbook_Chapter_8.md)
|
||||
[Chapter 9 - Endpoints](Def_Sec_Handbook_Chapter_9.md)
|
||||
[Chapter 10 - Password Management and Multifactor Authentication](Def_Sec_Handbook_Chapter_10.md)
|
||||
[Chapter 11 - Vulnerability Management](Def_Sec_Handbook_Chapter_11.md)
|
||||
|
||||
|
|
@ -0,0 +1,64 @@
|
|||
# Chapter 1: Risk Management
|
||||
|
||||
Source: Defensive Security Handbook: Best Practices for Securing Infrastructure by Lee Brotherston, Amanda Berlin
|
||||
|
||||
NIST Risk Management Functions:
|
||||
|
||||
- Identify
|
||||
- Protect
|
||||
- Detect
|
||||
- Respond
|
||||
- Recover
|
||||
|
||||
## Software Engineering Institute: OCTAVE Framework
|
||||
Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE)
|
||||
https://resources.sei.cmu.edu/library/asset-view.cfm?assetID=309051
|
||||
|
||||
## Security Baseline
|
||||
Information to gather:
|
||||
|
||||
* Policies and procedures
|
||||
* Endpoints desktops and servers, including implementation date and software version
|
||||
* Licensing and software renewal, as well as SSL certificates
|
||||
* Internet footprint: domains, mail servers, dmz devices
|
||||
* Networking devices: routers, switches, APs, IDS/IPS, and Network Traffic
|
||||
* Logging and monitoring
|
||||
* Ingress/egress points: ISP contacts, account numbers, and IP addresses
|
||||
* External vendors, with or without remote access, and primary contacts
|
||||
|
||||
## Assessing threats and risks
|
||||
Risk management is often split into four steps:
|
||||
- identify
|
||||
- assess
|
||||
- mitigate
|
||||
- monitor
|
||||
|
||||
### Identify
|
||||
- Focus on industry trends and industry specific risks:
|
||||
Information Sharing and Analysis Centers (ISACs) / National Council of ISACs https://www.nationalisacs.org
|
||||
- Overall trends: OWASP top 10 and CIS 20 Critical Security Controls
|
||||
|
||||
### Mitigation options
|
||||
- Avoid risk, e.g.: stop storing Social Security numbers if they are unnecessary for the process
|
||||
- Remediate risk, e.g.: turning off open ports, implementing stricter firewall rules, and patching endpoints
|
||||
- Transfer risk, e.g.: outsourcing credit card processing to a third-party
|
||||
- Accepting risk (last resort!)
|
||||
|
||||
## How Attackers Work
|
||||
Intrusion Kill Chain / Cyber Kill Chain:
|
||||
|
||||
* Reconnaissance: research, identification, and selection of targets, e.g. crawling internet websites for email addresses, social relationships, or information on specific technologies.
|
||||
* Weaponization: coupling a remote access trojan with an exploit into a deliverable payload, such as Adobe Portable Document Format (PDF) or Microsoft Office documents.
|
||||
* Delivery: transmission of the weapon to the targeted environment, mostly by email attachments, websites, and USB removable media.
|
||||
* Exploitation: triggering intruders’ code. Most often, exploitation targets an application or operating system vulnerability, but it could also more simply exploit the users themselves or leverage an operating system feature that auto-executes code.
|
||||
* Installation: installation of the trojan or backdoor on the victim system.
|
||||
* Command and Control (C2): establish an outbound beacon to an internet controller server; intruders now have “hands on the keyboard” access inside the target environment.
|
||||
* Actions on Objectives: intruders take actions to achieve their original objectives, e.g. data exfiltration, violations of data integrity or availability, use as a hopping point for further infiltration
|
||||
|
||||
Use cases to create and implement security-controls, see Table 1-1. Ransomware use case, also includes links to resources.
|
||||
|
||||
Hold fire drills: https://www.fema.gov/media-library/assets/documents/26845
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,13 @@
|
|||
# Chapter 10: Password Management and Multifactor Authentication
|
||||
|
||||
See also: [Identity and Access Management (IAM)](../../Information%20Security/Identity%20and%20Access%20Management%20(IAM).md), [Roles in Identity and Access Management (IAM)](../../Information%20Security/Roles%20in%20Identity%20and%20Access%20Management%20(IAM).md)
|
||||
|
||||
## Password practices
|
||||
Password complexity and brute force cracking:
|
||||
* 8 characters at only lowercase equals 26 ^ 8. Extremely easy, will crack in < 2 minutes.
|
||||
* 8 characters at upper-and lowercase equals 52 ^ 8. Still not the best, will crack in < 6 hours.
|
||||
* 8 characters at uppercase, lowercase, and numbers equals 62 ^ 8. A little better, will crack in < 24 hours.
|
||||
* 10-character passphrase with uppercase, lowercase, numbers, and symbols 94 ^ 10. Approximately 600 years.
|
||||
|
||||
Tools and password dictionaries (comprised from most used passwords obtained from previous hacks) are readily available on the Internet.
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
# Chapter 11: Vulnerability Management
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Chapter 2: Asset management
|
||||
|
||||
Source: Defensive Security Handbook: Best Practices for Securing Infrastructure by Lee Brotherston, Amanda Berlin
|
||||
|
||||
Each asset or group of assets must be assigned an owner and/or a custodian.
|
||||
|
||||
* Asset owner: point of contact for the asset
|
||||
* Custodian: responsible for the stored information
|
||||
|
||||
Categorize the assets into different levels of importance based on the value of the information, and the cost to the company if an asset is compromised.
|
||||
|
||||
## Information classification
|
||||
1. Identify data sources to be protected (uses tools where possible).
|
||||
* include description, location, existing protection measures, data owners and custodians, and the type of resource.
|
||||
2. Classify: identify information classes and label them.
|
||||
1. Define critical assets (incl. firewalls, connections, etc.).
|
||||
3. Map protections to set information classification levels.
|
||||
4. Protect.
|
||||
5. Audit yearly.
|
||||
|
||||
|
||||
## Asset mgt implementation
|
||||
Each department or person involved in each step should understand when and how assets are tracked at every point of their lifecycles.
|
||||
|
||||
* Procure
|
||||
* Deploy
|
||||
* Manage, e.g. moved to storage, upgraded, replaced, returned, or change of users, locations, or departments.
|
||||
* Decommission
|
||||
|
||||
Track changes, monitor and report
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
# Chapter 3: Policies
|
||||
|
||||
SANS offers a template library: https://www.sans.org/security-resources/policies
|
||||
|
||||
# Standards and Procedures
|
||||
Standards and procedures bring policies to life. Policies describe “what” we are trying to achieve, standards and procedures form the “how.”
|
||||
|
||||
Example: a policy states that access be authenticated by use of a password.
|
||||
|
||||
A **Standard** provides more detail as to what constitutes a password, like complexity requirements, the process for changing a password, storage requirements, ability to reuse passwords or otherwise, etc.
|
||||
|
||||
**Procedures** describe specific steps in order to achieve those standards at a technology level.
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# Chapter 4: User education and awareness
|
||||
|
||||
See also: [ISO_27002_2022_6.3_OT Information security awareness, education and training](../iso27diy-corp/Corpus/Standards/ISO-27002-OST/ISO27002-EN-2022/ISO_27002_2022_6.3_OT%20Information%20security%20awareness%2C%20education%20and%20training.md)
|
||||
|
||||
Repetition. Not only train, also educate.
|
||||
|
||||
- Establish Objectives
|
||||
- Establish Baselines
|
||||
- Create Program Rules and Guidelines
|
||||
- Implement and Document Program Infrastructure
|
||||
- Positive Reinforcement for reporting incidents
|
||||
- Gamification
|
||||
- Define Incident Response Processes
|
||||
|
||||
See appendix A for training templates.
|
||||
|
||||
https://www.csoonline.com/article/2134189/how-to-create-security-awareness-with-incentives.html
|
||||
|
||||
## Meaningful metrics
|
||||
Here are some common totals to track:
|
||||
* Emails sent
|
||||
* Emails opened
|
||||
* Links clicked
|
||||
* Credentials harvested
|
||||
* Reports of phishing attempts
|
||||
* Emails not reported on
|
||||
* Hits on training sites
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# Chapter 5: Incident Response
|
||||
|
||||
See also:
|
||||
- [SANS Incident Response Plan](../../Standards/SANS/SANS%20Incident%20Response%20Plan.md)
|
||||
- ISO 27002 5.26
|
||||
|
||||
|
||||
## Pre-incident process
|
||||
Recognize potential incidents, and initiate the response process. Leverage existing processes (check with support desk). Define what constitutes as an incident.
|
||||
|
||||
## Incident processes
|
||||
- Appoint an Incident Manager
|
||||
- Define internal communications
|
||||
- Open a War Room
|
||||
- Have a Conference Bridge to the war room
|
||||
- Allocate the task of communicating to internal stakeholders
|
||||
- Define external communications
|
||||
- Determine key goals; see Disaster Recovery
|
||||
- Prepare for longer lasting attacks
|
||||
|
||||
## Post-incident process:
|
||||
- hold a lessons-learned session
|
||||
- Use this session to update documentation, policies, procedures, and standards
|
||||
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
# Chapter 6: Disaster Recovery
|
||||
|
||||
* Business Continuity Planning (BCP): continuation of business via alternative plans.
|
||||
* Disaster Recovery (DR) is the set of processes used to reach the objectives of the Business Continuity Plan.
|
||||
* Key security aspects CIA: Confidentiality, Integrity, Availability
|
||||
|
||||
## Pre-disaster process
|
||||
Have a process in place to determine what is and is not a disaster, and when to invoke the plan.
|
||||
|
||||
## Setting objectives
|
||||
* Recovery Point Objective (RPO): the point in time that you wish to recover to. What is acceptable: seconds before the disaster strikes, the night before, or the week before? The shorter the RPO, the more costs and complexity.
|
||||
* Recovery Time Objective (RTO): time permitted to reach the RPO.
|
||||
|
||||
These should be driven by the business owners!
|
||||
|
||||
## Recovery strategies
|
||||
- Have regular backups
|
||||
- Warm standbys
|
||||
- High-availability systems
|
||||
- Fail-over scenario’s:
|
||||
- Use alternative systems (e.g. if VoIP crashes, use cellphones)
|
||||
- System Function Reassignment: repurposing noncritical systems to replace critical systems (e.g. use an acceptation-environment as a production environment; requires that the two environments be separated enough that a disaster affecting one will not affect the other).
|
||||
- Have a process for switching back
|
||||
|
||||
Test regularly!
|
||||
|
||||
**tot hier verwerkt**
|
||||
|
||||
|
||||
## Understand Dependencies
|
||||
Map them. Example: if you have an email server with an RTO of 1 hour, and yet the network on which it depends has an RTO of 3 hours, irrespective of how quickly the email server is up and running, it may not be resuming operation in any meaningful sense until 3 hours have elapsed.
|
||||
|
||||
## Develop Scenario’s
|
||||
For testing your procedures and training staff.
|
||||
|
||||
A few broad categories of scenarios useful to consider:
|
||||
|
||||
* Hardware failure of mission-critical platform
|
||||
* Loss of a data center
|
||||
* Pandemic
|
||||
|
||||
## Pre-disaster process
|
||||
Have a process in place to determine what is and is not a disaster, and when to invoke the plan.
|
||||
|
||||
One of the most effective routes is to have a list of named individuals or roles who are authorized to determine when the organization is in a disaster situation and that the plan needs to be executed.
|
||||
|
||||
The process for anyone who is not authorized to make this determination is to escalate to someone who can.
|
||||
|
||||
## Security Considerations
|
||||
* Secure Data at Rest
|
||||
* Secure Data in Transit
|
||||
* Patching and configuration management on backup systems
|
||||
* User access
|
||||
* Physical security on secondary sites
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
# Chapter 7: Physical Security
|
||||
|
||||
See also:
|
||||
- ISO 27002 A 7
|
||||
|
||||
## Physical properties
|
||||
Social engineering remains to this day a very effective way of accessing the inside of a network.
|
||||
|
||||
- Access restriction
|
||||
- Surveillance
|
||||
- Authentication Maintenance (e.g. change door access code after change in staff)
|
||||
- Secure physical media (e.g. lock door where backup tapes are stored)
|
||||
|
||||
## Operational properties
|
||||
- Identify Visitors and Contractors
|
||||
- Visitor and contractor actions (sign-in/ escort/ sign-out)
|
||||
|
||||
## Training and awareness
|
||||
- Tailgating
|
||||
- Badge cloning
|
||||
- Malicious media
|
||||
- Social engineering (‘pretexts’)
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
# Chapter 8: Microsoft Windows Infrastructure
|
||||
|
||||
|
||||
## Active Directory Domain Services
|
||||
Key concepts:
|
||||
- Trusts
|
||||
- Domain Controllers and FSMO roles
|
||||
- Organizational Units
|
||||
- Groups
|
||||
- Accounts
|
||||
- Group Policy Objects (GPO’s)
|
||||
- Enhanced Mitigation Experience Toolkit (EMET)
|
||||
- MS-SQL servers
|
||||
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
# Chapter 9: Endpoints
|
||||
|
||||
|
||||
## Key protection measures
|
||||
- Software / OS updates
|
||||
- Desktop Firewalls
|
||||
- VPN
|
||||
- Disk Encryption
|
||||
- Mobile Device Mgt
|
||||
- Endpoint Visibility (vs. privacy)
|
||||
- Centralize resources
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue