Lesson 17 Flashcards
(99 cards)
1
Q
Incident Response Process (PICERL)
A
Picerel Peperation Identification Containment Eradication Recovery Lessons Learned)
Preperation -> Identification -> Containment ->Eradication-> Recovery -> Post Incident Activity
- Preparation—make the system resilient to attack in the first place. This includes
hardening systems, writing policies and procedures, and setting up confidential
lines of communication. It also implies creating incident response resources and
procedures. - Identification—from the information in an alert or report, determine whether
an incident has taken place, assess how severe it might be (triage), and
notify stakeholders. - Containment—limit the scope and magnitude of the incident. The principal aim
of incident response is to secure data while limiting the immediate impact on
ctomers and business partners. - Eradication—once the incident is contained, remove the cause and restore the
affected system to a secure state by applying secure configuration settings and
installing patches. - Recovery—with the cause of the incident eradicated, the system can be
reintegrated into the business process that it supports. This recovery phase may
involve restoration of data from backup and security testing. Systems must be
monitored more closely for a period to detect and prevent any reoccurrence
of the attack. The response process may have to iterate through multiple
phases of identification, containment, eradication, and recovery to effect a
complete resolution. - Lessons learned—analyze the incident and responses to identify whether
procedures or systems could be improved. It is imperative to document the
incident. The outputs from this phase feed back into a new preparation phase in
the cycle.
2
Q
Cyber Incident Response Team
A
- Reporting, categorizing, and prioritizing (triage)
- CIRT/CERT/CSIRT/SOC
- Management/decision-making authority (led by at least director level. person that can make decisions)
- Incident analysts
- 24/7 availability (costly)
- Roles beyond technical response
- Legal
- Human Resources (HR)
- Marketing
3
Q
Other names for CIRT
A
cyber incident response team (CIRT),
computer security incident response team (CSIRT)
computer emergency response team (CERT).
4
Q
SOC
A
Incident
response might also involve or be wholly located within a security operations center
(SOC)
5
Q
Other roles needed on for Incident Response (CIRT)
A
Roles beyond technical response
•Legal
•Human Resources (HR)
•Marketing
•Legal—it is important to have access to legal expertise, so that the team can
evaluate incident response from the perspective of compliance with laws and
industry regulations. It may also be necessary to liaise closely with law enforcement
professionals, and this can be daunting without expert legal advice.
• Human Resources (HR)—incident prevention and remediation actions may affect
employee contracts, employment law, and so on. Incident response requires the
right to intercept and monitor employee communications.
• Marketing—the team is likely to require marketing or public relations input, so that
any negative publicity from a serious incident can be managed.
6
Q
Communication Plan and Stakeholder Management
A
- Prevent inadvertent disclosure
- Call list identifying trusted parties
- Communication plan
- Share data on a need to know basis
- Out-of-band communications—avoid alerting intruder
- Stakeholder management
- Communication with internal and external stakeholders
- Notification and reporting
7
Q
•Prevent inadvertent disclosure and call list (incident response)
A
You must prevent the inadvertent release of information beyond the team authorized
to handle the incident. Status and event details should be circulated on a need-to-know
basis and only to trusted parties identified on a call list.
8
Q
Communication plan
A
- Communication plan
- Share data on a need to know basis
- Out-of-band communications—avoid alerting intruder
Secure communication between the trusted parties of the CIRT is essential for
managing incidents successfully. It is imperative that adversaries not be alerted to
detection and remediation measures about to be taken against them. It may not be
appropriate for all members of the CSIRT to be informed about all incident details.
The team requires an “out-of-band” or “off-band” communication method that cannot
be intercepted. Using corporate email or VoIP runs the risk that the adversary will
be able to intercept communications. One obvious method is cell phones but these
only support voice and text messaging. For file and data exchange, there should
be a messaging system with end-to-end encryption, such as Off-the-Record (OTR),
Signal, or WhatsApp, or an external email system with message encryption (S/MIME
or PGP). These need to use digital signatures and encryption keys from a system
that is completely separate from the identity management processes of the network
being defended.
9
Q
Stakeholder Management
A
- Stakeholder management
- Communication with internal and external stakeholders
- Notification and reporting
Trusted parties might include both internal and external stakeholders. It is not helpful
for an incident to be publicized in the press or through social media outside of planned
communications. Ensure that parties with privileged information do not release this
information to untrusted parties, whether intentionally or inadvertently.
You need to consider obligations to report the attack. It may be necessary to inform
affected parties during or immediately after the incident so that they can perform their
own remediation. It may be necessary to report to regulators or law enforcement. You
also need to consider the marketing and PR impact of an incident. This can be highly
damaging and you will need to demonstrate to customers that security systems have
been improved.
10
Q
Incident Response Plan
A
- Lists the procedures, contacts, and resources available to responders for various incident categories
- Playbooks and runbooks
- Incident categorization
- Prioritization factors
- Data integrity
- Downtime
- Economic/publicity
- Scope
- Detection time
- Recovery time
11
Q
incident response plan (IRP)
A
An incident response plan (IRP) lists the procedures, contacts, and resources
available to responders for various incident categories.
12
Q
Playbooks and runbooks
A
playbook (or runbook) is a data-driven standard operating procedure (SOP) to assist
junior analysts in detecting and responding to specific cyberthreat scenarios, such as
phishing attempts, SQL injection data exfiltration, connection to a blacklisted IP range,
and so on. The playbook starts with a SIEM report and query designed to detect the
incident and identify the key detection, containment, and eradication steps to take.
13
Q
Incident categorization
A
Incident categories and definitions ensure that all response team members and other
organizational personnel all have a common base of understanding of the meaning
of terms, concepts, and descriptions. The categories, types, and definitions might vary
according to industry
14
Q
Prioritization factors
A
- Prioritization factors
- Data integrity
- Downtime
- Economic/publicity
- Scope
- Detection time
- Recovery time
15
Q
Data Integrity (prioritization factors)
A
Data integrity—the most important factor in prioritizing incidents will often be the
value of data that is at risk.
16
Q
Downtime (prioritization Factor)
A
Downtime—another very important factor is the degree to which an incident
disrupts business processes. An incident can either degrade (reduce performance)
or interrupt (completely stop) the availability of an asset, system, or business
process. If you have completed an asset inventory and a thorough risk assessment
of business processes (showing how assets and computer systems assist each
process), then you can easily identify critical processes and quantify the impact of
an incident in terms of the cost of downtime.
17
Q
Economic/publicity (prioritization Factor)
A
Economic/publicity—both data integrity and downtime will have important
economic effects, both in the short term and the long term. Short-term costs involve
incident response itself and lost business opportunities. Long-term economic costs
may involve damage to reputation and market standing.
18
Q
Scope(prioritization Factor)
A
• Scope—the scope of an incident (broadly the number of systems affected) is not a
direct indicator of priority. A large number of systems might be infected with a type
of malware that degrades performance, but is not a data breach risk. This might
even be a masking attack as the adversary seeks to compromise data on a single
database server storing top secret information.
19
Q
• Detection time(prioritization Factor)
A
• Detection time—research has shown that the existence of more than half of data
breaches are not detected for weeks or months after the intrusion occurs, while in
a successful intrusion data is typically breached within minutes. This demonstrates
that the systems used to search for intrusions must be thorough and the response
to detection must be fast.
20
Q
• Recovery time(prioritization Factor)
A
• Recovery time—some incidents require lengthy remediation as the system changes
required are complex to implement. This extended recovery period should trigger
heightened alertness for continued or new attacks.
21
Q
Cyber Kill Chain Attack Framework
A
Effective incident response depends on threat intelligence. Threat research provides
insight into adversary tactics, techniques, and procedures (TTPs). Insights from threat
research can be used to develop specific tools and playbooks to deal with event
scenarios. A key tool for threat research is a framework to use to describe the stages
of an attack. These stages are often referred to as a cyber kill chain
1, Reconnaissance
- Weaponization
- Delivery
- Exploitation
- Installation
- Command and Control (C2)
- Actions on Objectives
22
Q
- Reconnaissance
A
- Reconnaissance—in this stage the attacker determines what methods to use to
complete the phases of the attack and gathers information about the target’s
personnel, computer systems, and supply chain.
23
Q
- Weaponization
A
- Weaponization—the attacker couples payload code that will enable access with
exploit code that will use a vulnerability to execute on the target system.
24
Q
- Delivery
A
- Delivery—the attacker identifies a vector by which to transmit the weaponized
code to the target environment, such as via an email attachment or on a
USB drive.
25
4. Exploitation
4. Exploitation—the weaponized code is executed on the target system by this
mechanism. For example, a phishing email may trick the user into running the
code, while a drive-by-download would execute on a vulnerable system without
user intervention.
26
5. Installation
5. Installation—this mechanism enables the weaponized code to run a remote
access tool and achieve persistence on the target system.
27
6. Command and control (C2 or C&C)
6. Command and control (C2 or C&C)—the weaponized code establishes an
outbound channel to a remote server that can then be used to control the remote
access tool and possibly download additional tools to progress the attack.
28
7. Actions on objectives
7. Actions on objectives—in this phase, the attacker typically uses the access he
has achieved to covertly collect information from target systems and transfer
it to a remote system (data exfiltration). An attacker may have other goals or
motives, however.
29
MITRE ATT&CK
Another atack framework
MITRE ATT&CK
•Database of TTPs
•Tactic categories
•No explicit sequencing
30
The Diamond Model of Intrusion Analysis
Another Attack framework
•Framework for describing adversary capability and infrastructure plus effect on victim
31
Incident Response Exercises
Tabletop
•Facilitator presents a scenario
•Does not involve live systems
- Least costly
Walkthroughs
•Responders demonstrate response actions (Unlike a tabletop exercise, the responders perform actions such asrunning scans and analyzing sample files, typically on sandboxed versions of thecompany's actual response and recovery tools.)
Simulations
•Red team performs a simulated intrusion
- Simulations—a simulation is a team-based exercise, where the red team attempts
an intrusion, the blue team operates response and recovery controls, and a
white team moderates and evaluates the exercise. This type of training requires
considerable investment and planning.
32
Tabletop
Tabletop
•Facilitator presents a scenario
•Does not involve live systems
- Least costly
33
Walkthroughs
Walkthroughs
•Responders demonstrate response actions (Unlike a tabletop exercise, the responders perform actions such asrunning scans and analyzing sample files, typically on sandboxed versions of thecompany's actual response and recovery tools.)
34
Simulations
Simulations
•Red team performs a simulated intrusion
- Simulations—a simulation is a team-based exercise, where the red team attempts
an intrusion, the blue team operates response and recovery controls, and a
white team moderates and evaluates the exercise. This type of training requires
considerable investment and planning
35
Incident response versus disaster recovery and business continuity
Incident response versus disaster recovery and business continuity
•Disaster recovery plan
•Response and recovery planning for major incidents
•Business continuity plan
•Making business procedures resilient
•Continuity of operation planning (COOP)
36
•Disaster recovery plan
* Disaster recovery plan
* Response and recovery planning for major incidents
```
Disaster recovery plan—a disaster can be seen as a special class of incident where
the organization's primary business function is disrupted. Disaster recovery requires
considerable resources, such as shifting processing to a secondary site. Disaster
recovery will involve a wider range of stakeholders than less serious incidents.
```
37
•Business continuity plan
* Business continuity plan
* Making business procedures resilient
Business continuity plan (BCP)—this identifies how business processes should
deal with both minor and disaster-level disruption. During an incident, a system
may need to be isolated. Continuity planning ensures that there is processing
redundancy supporting the workflow, so that when a server is taken offline for
security remediation, processing can failover to a separate system. If systems do not
have this sort of planned resilience, incident response will be much more disruptive.
38
Continuity of Operation Planning (COOP)
• Continuity of Operation Planning (COOP)—this terminology is used for
government facilities, but is functionally similar to business continuity planning. In
some definitions, COOP refers specifically to backup methods of performing mission
functions without IT support.
39
Incident response, forensics, and retention policy
Incident response, forensics, and retention policy
•Digital forensics requirements
•Retention policies for evidence preservation
The incident response process emphasizes containment, eradication, and recovery.
These aims are not entirely compatible with forensics. Digital forensics describes
techniques to collect and preserve evidence that demonstrate that there has been no
tampering or manipulation. Forensics procedures are detailed and time-consuming,
where the aims of incident response are usually urgent. If an investigation must use
forensic collection methods so that evidence is retained, this must be specified early in
the response process.
Retention policy is also important for retrospective incident handling, or threat
hunting. A retention policy for historic logs and data captures sets the period over
which these are retained. You might discover indicators of a breach months or years
after the event. Without a retention policy to keep logs and other digital evidence, it will
not be possible to make any further investigation.
40
Incident identification
Identification is the process of collating events and determining whether any of them
should be managed as incidents or as possible precursors to an incident; that is, an
event that makes an incident more likely to happen
41
Precursor
an event that makes an incident more likely to happen
42
•Security mechanisms (IDS, log analysis, alerts) [precursor detection channel]
Using log files, error messages, IDS alerts, firewall alerts, and other resources
to establish baselines and identifying those parameters that indicate a possible
security incident.
43
•Manual inspections [precursor detection channel]
• Manual or physical inspections of site, premises, networks, and hosts.
44
•Notification procedures [precursor detection channel]
• Notification by an employee, customer, or supplier.
45
•Public reporting [precursor detection channel]
Public reporting of new vulnerabilities or threats by a system vendor, regulator, the
media, or other outside party.
46
•Confidential reporting/whistleblowing [precursor detection channel]
It is wise to provide for confidential reporting so that employees are not afraid to
report insider threats, such as fraud or misconduct. It may also be necessary to use an
"out-of-band" method of communication so as not to alert the intruder that his or her
attack has been detected.
47
First responder
Member of CIRT taking charge of a reported incident
48
Analysis and incident identification
Analysis and incident identification
•Classify and prioritize
•Downgrade low priority alerts to log-only
49
Analysis and incident identification
Analysis and incident identification
•Classify and prioritize
•Downgrade low priority alerts to log-only
When notification has taken place, the CIRT or other responsible person(s) must
analyze the event to determine whether a genuine incident has been identified and
what level of priority it should be assigned. Analysis will depend on identifying the type
of incident and the data or resources affected (its scope and impact). At this point,
the incident management database should have a record of the event indicators, the
nature of the incident, its impact, and the incident investigator responsible. The next
phase of incident management is to determine an appropriate response.
50
SIEM and incident analysis
Coupled with an attack framework, notification will provide a general sense of where
to look for or expect indicators of malicious activity. Incident analysis is greatly
facilitated by a security information and event management (SIEM) system. A SIEM
parses network traffic and log data from multiple sensors, appliances, and hosts and
normalizes the information to standard field types.
51
Correlation (SIEM)
Correlation
•Static rules and logical expressions
•Threat intelligence feeds
•AI-assisted analysis
The SIEM can then run correlation rules on indicators extracted from the data sources
to detect events that should be investigated as potential incidents. You can also filter or
query the data based on the type of incident that has been reported.
Correlation means interpreting the relationship between individual data points to
diagnose incidents of significance to the security team.
52
SIEM - •Static rules and logical expressions
A SIEM correlation rule is a
statement that matches certain conditions. These rules use logical expressions, such as
AND and OR, and operators, such as == (matches), < (less than), > (greater than), and
in (contains). For example, a single-user logon failure is not a condition that should
raise an alert. Multiple user logon failures for the same account, taking place within
the space of one hour, is more likely to require investigation and is a candidate for
detection by a correlation rule.
Error.LogonFailure > 3 AND LogonFailure.User AND
Duration < 1 hour
53
* Threat intelligence feeds
| * AI-assisted analysis
As well as correlation between indicators observed on the network, a SIEM is likely to
be configured with a threat intelligence feed. This means that data points observed on
the network can be associated with known threat actor indicators, such as IP addresses
and domain names. AI-assisted analysis enables more sophisticated alerting and
detection of anomalous behavior.
54
Retention (SIEM)
Retention
•Preserve evidence of attack
•Facilitate threat hunting and retrospective incident identification
A SIEM can enact a retention policy so that historical log and network traffic data is kept
for a defined period. This allows for retrospective incident and threat hunting, and can
be a valuable source of forensic evidence.
55
SIEM Dashboards
Analyst dashboard
•Console of alerts that require prioritization and investigation
Manager dashboard
•Overall status indicators
Sensitivity and alerts
•Log only/alert/alarm
Sensors
•Source for network traffic data
•Aggregate data under one dashboard
•Per-sensor dashboards
56
Analyst dashboard
Analyst dashboard
| •Console of alerts that require prioritization and investigation
57
Manager dashboard
•Overall status indicators
58
Sensitivity and alerts
Sensitivity and alerts
•Log only/alert/alarm
One of the greatest challenges in operating a SIEM is tuning the system sensitivity
to reduce false positive indicators being reported as an event. This is difficult firstly
because there isn't a simple dial to turn for overall sensitivity, and secondly because
reducing the number of rules that produce events increases the risk of false negatives.
A false negative is where indicators that should be correlated as an event and raise an
alert are ignored.
The correlation rules are likely to assign a criticality level to each match. For example:
• Log only—an event is produced and added to the SIEM's database, but it is
automatically classified.
• Alert—the event is listed on a dashboard or incident handling system for an agent to
assess. The agent classifies the event and either dismisses it to the log or escalates it
as an incident.
• Alarm—the event is automatically classified as critical and a priority alarm is raised.
This might mean emailing an incident handler or sending a text message.
59
Sensors
Sensors
•Source for network traffic data
•Aggregate data under one dashboard
•Per-sensor dashboards
A sensor is a network tap or port mirror that performs packet capture and intrusion
detection. One of the key uses of a SIEM is to aggregate data from multiple sensors and
log sources, but it might also be appropriate to configure dashboards that show output
from a single sensor or source host.
60
Trend analysis
Trend analysis is the process of detecting patterns or indicators within a data set
over a time series and using those patterns to make predictions about future events.
A trend is difficult to spot by examining each event in a log file.
Instead, you need
software to **visualize** the incidence of types of event and show how the number or
frequency of those events changes over time.
61
Frequency-based trend analysis
Frequency-based trend analysis establishes a baseline for a metric, such as number
of NXERROR DNS log events per hour of the day. If the frequency exceeds (or in
some cases undershoots) the threshold for the baseline, then an alert is raised.
62
Volume-based trend analysis
Volume-based trend analysis can be performed with simpler indicators. For example, one simple metric for determining threat level is log volume. If logs
are growing much faster than they were previously, there is a good chance that
something needs investigating. Volume-based analysis also applies to network
traffic. You might also measure endpoint disk usage. Client workstations don’t
usually need to store data locally, so if a host's disk capacity has suddenly
diminished, it could be a sign that it is being used to stage data for exfiltration.
63
Statistical deviation analysis
Statistical deviation analysis can show when a data point should be treated as
suspicious. For example, a cluster graph might show activity by standard users and
privileged users, invoking analysis of behavioral metrics of what processes each type
runs, which systems they access, and so on. A data point that appears outside the
two clusters for standard and administrative users might indicate some suspicious
activity by that account.
64
Logging Platforms
Just remember these are Logging platforms
```
Syslog
•Logging format, protocol, and server (daemon) software
•PRI –facility and severity
•Timestamp
•Host
•Message part
```
Rsyslog and syslog-ng
journalctl
•Binary logging
Nxlog
•Log normalization tool
65
System and security logs
```
System and security logs
•Application
•Security/audit
•System
•Setup
•Forwarded events
```
One source of security information is the event log from each network server or client.
When events are generated, they are placed into log categories. These categories
describe the general nature of the events or what areas of the OS they affect. The five
main categories of Windows event logs are:
• Application—events generated by applications and services, such as when a service
cannot start.
• Security—audit events, such as a failed logon or access to a file being denied.
• System—events generated by the operating system and its services, such as storage
volume health checks.
• Setup—events generated during the installation of Windows.
• Forwarded Events—events that are sent to the local log from other hosts.
66
Network Logs
Network logs
•Traffic and access data from network appliances
Network logs are generated by appliances such as routers, firewalls, switches, and
access points. Log files will record the operation and status of the appliance itself—the
system log for the appliance—plus traffic and access logs recording network behavior,
such as a host trying to use a port that is blocked by the firewall, or an endpoint trying
to use multiple MAC addresses when connected to a switch.
67
Authentication Logs
Authentication logs
•Security log or RADIUS/TACACS+ application logs
Authentication attempts for each host are likely to be written to the security log. You
might also need to inspect logs from the servers authorizing logons, such as RADIUS
and TACACS+ servers or Windows Active Directory (AD) servers.
68
Vulnerability scan output
A vulnerability scan report is another important source when determining how an
attack might have been made. The scan engine might log or alert when a scan report
contains vulnerabilities. The report can be analyzed to identify vulnerabilities that have
not been patched or configuration weaknesses that have not been remediated. These
can be correlated to recently developed exploits.
69
Application Log Files
An application log file is simply one that is managed by the application rather than
the OS.
DNS event logs
•Types of queries made by clients
•Hosts using suspicious IP address ranges or domains
•Statistical anomalies
Web/HTTP access logs
•HTTP status codes
•HTTP headers
VoIP and call managers and Session Initiation Protocol (SIP) traffic
•Log endpoint connections
•Type of connection
•Via headers
Dump files
•Data from system memory
70
DNS Event Logs
DNS event logs
•Types of queries made by clients
•Hosts using suspicious IP address ranges or domains
•Statistical anomalies
A DNS server may log an event each time it handles a request to convert between a
domain name and an IP address. DNS event logs can hold a variety of information that
may supply useful security intelligence, such as:
• The types of queries a host has made to DNS.
• Hosts that are in communication with suspicious IP address ranges or domains.
• Statistical anomalies such as spikes or consistently large numbers of DNS
lookup failures, which may point to computers that are infected with malware,
misconfigured, or running obsolete or faulty applications.
71
Web/HTTP Access Logs
Web/HTTP access logs
•HTTP status codes
•HTTP headers
Web servers are typically configured to log HTTP traffic that encounters an error or
traffic that matches some predefined rule set.....
72
VoIP and call managers and Session Initiation Protocol (SIP) traffic
VoIP and call managers and Session Initiation Protocol (SIP) traffic
•Log endpoint connections
•Type of connection
•Via headers
The call manager's access log can be
audited for suspicious connections.
73
Dump Files
Dump files
•Data from system memory
System memory contains volatile data. A system memory dump creates an image
file that can be analyzed to identify the processes that are running, the contents of
temporary file systems, registry data, network connections, cryptographic keys, and
more. It can also be a means of accessing data that is encrypted when stored on a
mass storage device.
74
Metadata
Metadata is the properties of data as it is created by an application, stored on media,
or transmitted over a network. A number of metadata sources are likely to be useful
when investigating incidents, because they can establish timeline questions, such as
when and where, as well as containing other types of evidence.
File
•Date/time and security attributes
•Extended attributes and properties
Web
•Request and response headers
Email
•Internet header listing message transfer agents
•Spam/security analysis
Mobile
•Call detail records (CDRs)
75
File (metadata)
File
•Date/time and security attributes
•Extended attributes and properties
File metadata is stored as attributes. The file system tracks when a file was created,
accessed, and modified. A file might be assigned a security attribute, such as marking
it as read-only or as a hidden or system file. The ACL attached to a file showing its
permissions represents another type of attribute. Finally, the file may have extended
attributes recording an author, copyright information, or tags for indexing/searching.
76
Web (metadata)
Web
•Request and response headers
When a client requests a resource from a web server, the server returns the resource
plus headers setting or describing its properties. Also, the client can include headers
in its request. One key use of headers is to transmit authorization information, in
the form of cookies. Headers describing the type of data returned (text or binary, for
instance) can also be of interest. The contents of headers can be inspected using the
standard tools built into web browsers. Header information may also be logged by a
web server.
77
Email (metadata)
Email
•Internet header listing message transfer agents
•Spam/security analysis
An email's Internet header contains address information for the recipient and sender,
plus details of the servers handling transmission of the message between them. When
78
Mobile (metadata)
Mobile
•Call detail records (CDRs)
Mobile phone metadata comprises call detail records (CDRs) of incoming, outgoing,
and attempted calls and SMS text time, duration, and the opposite party's number.
Metadata will also record data transfer volumes.
79
Network Data Sources
I didn't really get this one, so i skipped it.
Network data is typically analyzed in detail at the level of individual frames or using
summary statistics of traffic flows and protocol usage.
Protocol analyzer output
•Pivot from alert event to per-packet or frame analysis
•Extract binary data
Netflow/IPFIX
•Records traffic statistics
•Flows defined by endpoints and ports (keys)
•Netflowexporters and collectors
sFlow
•Uses sampling to estimate statistics
•Bandwidth monitor
80
Incident Containment Phase
Response must satisfy different or competing objectives
•What is the loss or potential for loss?
•What countermeasures are available?
•What evidence can be collected?
When an incident has been identified, classified, and prioritized, the next phase of
incident response is containment. Containment techniques can be classed as either
isolation-based or segmentation-based.
81
Conatiment classifications
isolation based or
| segmentation basedbased
82
Isolation-Based Containment
```
Isolation-based containment
•Remove the affected system
•Disconnect hosts from power
•Prevent hosts communicating on network
•Disable user accounts or applications
```
83
Segmentation-based containment
Segmentation-based containment
•Use sinkhole or sandbox to analyze attack
....As opposed to completely isolating the
hosts, you might configure the protected segment as a sinkhole or honeynet and allow
the attacker to continue to receive filtered (and possibly modified) output over the
C&C channel to deceive him or her into thinking the attack is progressing successfully.
Analysis of the malware code by reverse engineering it could provide powerful
deception capabilities. You
84
Incident Eradication and Recovery
* Eradication of attack tools and access methods
* Recovery of systems to restore the operation of business workflows
Includes the following steps:
1Reconstitution of affected systems
2Re-audit security controls –what could have prevented the intrusion?
3 Notify affected third parties
85
Firewall Configuration Changes
* Analyzeattack to determine vector
* Reduce attack surface through configuration changes
* New security control
* Update existing control configuration
86
Ingress filtering rules vs egress filtering (firewall)
Historically, many organizations focused on ingress filtering rules, designed to
prevent local network penetration from the Internet. In the current threat landscape,
it is imperative to also apply strict egress filtering rules to prevent malware that has
infected internal hosts by other means from communicating out to C&C servers. Egress
filtering can be problematic in terms of interrupting authorized network activity, but it
is an essential component of modern network defense
87
Content Filter Configuration Changes
Secure web gateway for egress filtering
•Update URL/content filtering using threat data
Data loss prevention (DLP)
•Identify whether DLP mechanisms were circumvented
Mobile device management (MDM)
•Identify whether MDM mechanisms were circumvented
Update or revoke certificates
•
Remove compromised root certificates from trust stores
•Revoke certificates on compromised hosts
•Re-key certificate
88
secure web gateways (SWGs). (content filter configuration changes)
Secure web gateway for egress filtering
•Update URL/content filtering using threat data
A SWG mediates
user access to Internet services, with the ability to block content from regularly
updated URL/domain/IP blacklists and perform intrusion detection/prevention on
traffic based on matching content in application layer protocol headers and payloads.
89
Data loss prevention (DLP) (content filter configuration changes)
Data loss prevention (DLP)
•Identify whether DLP mechanisms were circumvented
Data loss prevention (DLP) performs a similar function, but instead of user access it
mediates the copying of tagged data to restrict it to authorized media and services. An
attack may reveal the necessity of investing in DLP as a security control if one is not
already implemented. If DLP is enabled and configured in the correct way to enforce
policy, the attacker may have been able to circumvent it using a backdoor method
that the DLP software cannot scan. Alternatively, the attacker may have been able to
disguise the data so that it was not recognized.
90
Mobile Device Management (MDM) (content filter configuration changes)
Mobile device management (MDM)
•Identify whether MDM mechanisms were circumvented
Mobile Device Management (MDM) provides execution control over apps and features
of smartphones. Features include GPS, camera, and microphone. As with DLP, an
intrusion might reveal a vector that allowed the threat actor to circumvent enrollment
or a misconfiguration in the MDM's policy templates.
91
Update or revoke certificates (content filter configuration changes)
Update or revoke certificates
•Remove compromised root certificates from trust stores
•Revoke certificates on compromised hosts
•Re-key certificate
92
Endpoint Configuration Changes
```
Re-assess attack surface and attack vectors
•Social engineering
•Vulnerabilities
•Lack of security controls
•Configuration drift
•Weak configuration
```
Application allow lists/block lists
•Change to least privilege
•Identify failure of controls to prevent execution
Quarantine
•Isolate suspect systems for analysis in sandbox
93
Security Orchestration, Automation, and Response (SOAR)
* Automation versus orchestration
* Security orchestration, automation, and response(SOAR)
* Incident response
* Threat hunting
* Integrates SDN/SDV APIs, orchestration tools, and cyber-threat intelligence (CTI) feeds
* AI-assisted user and entity behavioranalytics (UEBA)
* Runbooks versus playbooks
94
•Automation versus orchestration
Automation is the action of scripting a single activity, while orchestration is the action of
coordinating multiple automations (and possibly manual activity) to perform a complex,
multistep task.
95
Security orchestration, automation, and response(SOAR)
Security orchestration, automation, and response(SOAR)
•Incident response
•Threat hunting
SOAR is designed as a solution to the problem
of the volume of alerts overwhelming analysts' ability to respond, measured as the
mean time to respond (MTTR). A SOAR may be implemented as a standalone technology
or integrated with a SIEM—often referred to as a next-gen SIEM. The basis of SOAR
is to scan the organization's store of security and threat intelligence, analyze it using
machine/deep learning techniques, and then use that data to automate and provide data
enrichment for the workflows that drive incident response and threat hunting.
96
Integrates SDN/SDV APIs, orchestration tools, and cyber-threat intelligence (CTI) feeds
SOAR can also
assist with provisioning tasks, such as creating and deleting user accounts, making shares
available, or launching VMs from templates, to try to eliminate configuration errors. The
SOAR will use technologies such as cloud and SDN/SDV APIs, orchestration tools, and
cyberthreat intelligence (CTI) feeds to integrate the different systems that it is managing.
97
•AI-assisted user and entity behavioranalytics (UEBA)[SOAR]
SOAR will also leverage technologies such as automated malware signature creation and user
and entity behavior analytics (UEBA) to detect threats.
98
Runbooks versus playbooks
A playbook is a
checklist of actions to perform to detect and respond to a specific type of incident.
The aim of a runbook is to automate
as many stages of the playbook as possible, leaving clearly defined interaction points
for human analysis.
99
Adversarial Artificial Intelligence
* Machine learning relies on training data to develop analysis capability
* Threat actor may be able to submit tainted samples
* Adversarial AI
* Security of machine learning algorithms
