INFORMATION

ASSURANCE &
SECURITY 2
 MODULE 10
INTRUSION DATA ANALYSIS /
INCIDENT RESPONSE AND
HANDLING
OBJECTIVES
Upon completion of this module, the student would be able to:
➢ Explain the process of evaluating alerts.
➢ Explain how alerts are classified.
➢ Interpret data to determine the source of an alert.
➢ Use Security Onion tools to investigate network security events.
➢ Describe network monitoring tools that enhance workflow management.
➢ Explain the role of digital forensic processes..
OBJECTIVES
Upon completion of this module, the student would be able to:
➢ Identify the steps in the Cyber Kill Chain.
➢ Classify an intrusion event using the Diamond Model.
➢ Apply the VERIS Schema to an Incident.
➢ Describe the goals of a given CSIRT
➢ Apply the NIST incident handling procedures to a given incident scenario.
 EVALUATING ALERTS,
WORKING WITH NETWORK
SECURITY DATA AND DIGITAL
FORENSICS
Sources of Alerts
Security Onion
▪ Security Onion is an open-source
suite of Network Security Monitoring
(NSM) tools that run on an Ubuntu
Linux distribution.
▪ Some components of Security Onion
are owned and maintained by
corporations, such as Cisco and
Riverbend Technologies, but are
made available as open source.
Sources of Alerts
Detection Tools for Collection
▪ CapME provides the cybersecurity analyst with an
easy-to-read means of viewing an entire Layer 4
session. A Security Onion Architecture
▪ Snort uses rules and signatures to generate alerts.
▪ Bro uses policies, in the form of scripts that
determine what data to log and when to issue alert
notifications.

▪ OSSEC actively monitors host system operations,

including conducting file integrity monitoring, local
log monitoring, system process monitoring, and
rootkit detection.

▪ Suricata uses native multithreading, which allows

the distribution of packet stream processing across
multiple processor cores.
Sources of Alerts
Analysis Tools ▪ Sguil – This provides a high-level
cybersecurity analysts’ console for
A Security Onion Architecture investigating security alerts from a
wide variety of sources.
▪ ELSA – Logging sources such as
HIDS, NIDS, firewalls, syslog clients
and servers, domain services, and
others can be configured to make
their logs available to ELSA
databases.
▪ Wireshark – This is a packet capture
application that is integrated into the
Security Onion suite.
Sources of Alerts
Alert Generation
▪ Alerts are generated in Security Onion by Sguil Window
many sources including Snort, Bro, Suricata,
and OSSEC, among others.
▪ Sguil provides a console that integrates
alerts from multiple sources into a
timestamped queue.
▪ Alerts will generally include the following
five-tuples information:
• SrcIP - the source IP address for the event.
• SPort - the source (local) Layer 4 port for the
event.
• DstIP - the destination IP for the event.
• DPort - the destination Layer 4 port for the
event.
• Pr - the IP protocol number for the event.
Sources of Alerts
Rules and Alerts
▪ Alerts can come from a number of sources:
• NIDS - Snort, Bro and Suricata
• HIDS – OSSEC
• Asset management and monitoring - Passive Asset Detection System (PADS)
• HTTP, DNS, and TCP transactions - Recorded by Bro and pcaps
• Syslog messages - Multiple sources
Sources of Alerts
Snort Rule Structure
▪ Snort rules consist of the rule
header and rule options.
• Rule header contains the action,
protocol, addressing, and port
information
• Rule options include the text message
that identifies the alert also metadata
about the alert.
▪ Snort rules come from a variety of
sources including Emerging Threats
(ET), SourceFire, and Cisco Talos.
▪ PulledPork is a Security Onion
component that can download new
rules automatically from snort.org.
Overview of Alert Evaluation
The Need for Alert Evaluation
▪ Exploits will inevitably evade protection
measures, no matter how
sophisticated they may be.
▪ Detection rules should be overly
conservative.
▪ It is necessary to have skilled
cybersecurity analysts investigate
alerts to determine if an exploit has
actually occurred.
▪ Tier 1 cybersecurity analysts will work
through queues of alerts in a tool like
Sguil, pivoting to tools like Bro,
Wireshark, and ELSA .
Overview of Alert Evaluation
Evaluating Alerts
▪ Alerts can be classified as follows:
• True Positive: The alert has been verified to be an actual security incident.
• False Positive: The alert does not indicate an actual security incident.
• True Negative: No security incident has occurred.
• False Negative: An undetected incident has occurred.
Overview of Alert Evaluation
Deterministic Analysis and Probabilistic Analysis
▪ Statistical techniques can be used to evaluate the risk that exploits will be
successful in a given network.
• Deterministic Analysis – evaluates risk based on what is known about a vulnerability.
• Probabilistic Analysis – estimates the potential success of an exploit by estimating the
likelihood that if one step in an exploit has successfully been completed that the next step will
also be successful.
A Common Data Platform
ELSA
▪ Enterprise Log Search and Archive (ELSA) is
an enterprise-level tool for searching and
archiving NSM data that originates from
multiple sources.
▪ ELSA is able to normalize log file entries into
a common schema that can then be
displayed in the ELSA web interface.
▪ ELSA receives logs over Syslog-NG, stores
logs in MySQL databases, and indexes using
Sphinx Search.
A Common Data Platform
Data Reduction
▪ Data reduction is the identification of
data that should be gathered and stored
to reduce the burden on systems.
▪ By limiting the volume of data, tools like
ELSA will be far more useful.
A Common Data Platform
Data Normalization
▪ Data normalization is the process of combining data from a number of sources
into a common format for indexing and searching.
A Common Data Platform
Data Archiving
▪ Retaining NSM data indefinitely is not feasible
due to storage and access issues.
▪ Compliance frameworks may require storage of
data for a specified period of time.
▪ ELSA can be configured to retain data for a
period of time. The default is 90 days.
▪ Sguil alert data is retained for 30 days by
default.
Investigating Network Data
Working in Sguil
▪ In Security Onion, the first place that a
cybersecurity analyst will go to verify alerts is
Sguil.
▪ Sguil automatically correlates similar alerts
into a single line and provides a way to view
correlated events represented by that line.
Investigating Network Data
Sguil Queries
▪ Queries can be constructed in Sguil using the Query Builder, which simplifies constructing
queries.
▪ Cybersecurity analyst must know the field names and some issues with field values.
Investigating Network Data
Pivoting from Sguil
▪ Sguil provides the ability to “pivot” the
investigation to other tools such as ELSA,
Wireshark, or Bro.

▪ Log files are available in ELSA, relevant

packet captures can be displayed in
Wireshark, and transcripts of TCP
sessions and Bro information are also
available.
Investigating Network Data
Event Handling in Sguil
▪ Three tasks can be completed in
Sguil to manage alerts.
• Alerts that have been found to be
false positives can be expired.
• An event can be escalated by
pressing the F9 key.
• An event can be categorized.
Investigating Network Data
Working in ELSA
▪ ELSA provides access to a large number of
log file entries.
▪ ELSA will only retrieve the first 100 records
for the previous 48 hours.
▪ The easiest way to see information in ELSA
is to issue the built-in queries that appear to
the left of the ELSA window and then adjust
the dates and resubmit the query using the
Submit Query button.
Investigating Network Data
Queries in ELSA
▪ ELSA provides field summary and value information for every field that is indexed in the query results.
This permits refining queries based on a wide range of values.
▪ Clicking an entry in the Value column will display the query with the value added to the previous
query. This process can be repeated to narrow down search results easily.
▪ Regular expressions are executed in ELSA using the grep function.
Investigating Network Data
Investigating Process or API Calls
▪ If malware can fool an OS kernel into allowing it
to make system calls, many exploits are
possible.
▪ OSSEC rules detect changes in host-based
parameters like the execution of software
processes, changes in user privileges, and
registry modifications, among others.
▪ OSSEC rules will trigger an alert in Sguil.
▪ Choosing OSSEC as the source program in ELSA
results in a view of the OSSEC events that
occurred on the host.
Investigating Network Data
Investigating File Details
▪ When ELSA is opened directly, a query short cut exists for Files.
▪ Opening the Files queries and selecting Mime Types in the menu displays a list of the types of
files that have been downloaded.
▪ MD5 and SHA-1 hashes for downloaded files are also available.
▪ File hash values can be submitted to online sites to determine if the file is known malware.
Enhancing the Work of the Cybersecurity Analyst
Dashboards and Visualizations
▪ Dashboards provide an interactive combination of data and visualizations designed to improve the
value of large amounts of information.
▪ Allow analysts to focus on specific details and information
▪ ELSA capable of designing custom dashboards
▪ Squert provides a visual interface
▪ Cisco Talos provides an interactive dashboard
Enhancing the Work of the Cybersecurity Analyst
Workflow Management
▪ Network security monitoring requires workflows to be managed.
• Enhances efficiency of the cyberoperations team
• Increases the accountability of staff
• Ensures that all potential alerts are treated properly
• Each alert should be systematically assigned, processed, and documented
▪ Sguil provides basic workflow management but not a good choice for large operations, third party
systems are available that can be customized
▪ Automated queries add efficiency to workflow
• Search for complex security incidents that may evade other tools
• ELSA query can be configured as an alert rule and run regularly
• Can be created in a scripting language such as Python
Evidence Handling and Attack Attribution
Digital Forensics
▪ Cybersecurity analyst will uncover evidence of criminal activity.
• Must identify threat actors, report them to the appropriate authorities, and provide evidence
to support prosecution.
• Usually first to uncover wrong doing.
▪ Digital forensics is the recovery and investigation of information found on digital devices as it relates to
criminal activity.
• Could be data on storage devices, in volatile computer memory, or traces of cybercrime in
network data such as pcaps and logs
▪ Cybercriminal activity can be characterized as origination from inside or outside of
the organization.
▪ Under HIPAA, notification of breach must be made to the affected individuals.
▪ Analysts must know the requirements regarding the preservation and handling of
evidence.
Evidence Handling and Attack Attribution
The Digital Forensics Process
▪ NIST describes the digital forensics process as involving four steps:
1. Collection – Identification of potential sources of forensic data and acquisition,
handling, and storage of that data.
2. Examination – Assessing and extracting relevant information from the collected data.
May involve decompression and decryption.
3. Analysis – Drawing conclusions from the data. (People, places, time, events, etc.)
4. Reporting – Preparing and presenting information. Suggestions for further
investigation and next steps should be made.
Evidence Handling and Attack Attribution
Types of Evidence
▪ In legal proceedings, evidence is broadly classified:
• Direct evidence was indisputably in the possession of the accused, or is eyewitness
evidence from someone who observed criminal behavior.
• Best evidence is evidence that is in its original state.
• Corroborating evidence supports an assertion that is developed from best evidence.
• Indirect evidence, in combination with other facts, establishes a hypothesis. Also
know as circumstantial evidence.
Evidence Handling and Attack Attribution
Evidence Collection Order
▪ Collection of digital evidence should begin in order from the
most volatile evidence and proceed to the least volatile. Evidence Collection Priority

▪ Data in RAM is most volatile.

▪ Example most volatile to least volatile:

1. Memory registers, caches

2. Routing table, ARP cache, process table, kernel statistics, RAM
3. Temporary files systems
4. Non-volatile media, fixed and removable
5. Remote logging and monitoring data
6. Physical interconnections and topologies
7. Archival media, tape or other backups
Evidence Handling and Attack Attribution
Chain of Custody
▪ Chain of custody involves the collection, handling, and secure
storage of evidence.

▪ Who discovered the evidence.

▪ All details about the handling of evidence including
times, places, and personnel involved.
▪ Who has primary responsibility for the evidence, when
responsibility was assigned, and when custody changed.
▪ Who has physical access to the evidence while it was
stored? Access should be restricted to only the most
essential personnel.
Evidence Handling and Attack Attribution
Data Integrity and Preservation
▪ Digital evidence should be preserved in its original condition.
• Original evidence should be copied, and analysis
should only be conducted on copies.
• Timestamps may be part of evidence so opening
files from the original media should be avoided.
▪ Process used to create copies of evidence should be
recorded.

▪ Special tools should be used to preserve forensic evidence

before the device is shut down and evidence is lost.

▪ Users should not disconnect, unplug, or turn off infected

machine unless told to by security personnel.
Evidence Handling and Attack Attribution
Attack Attribution
▪ Threat attribution is the act of determining the individual, organization, or nation responsible for a
successful intrusion or attack incident.
▪ Identification of threat actors should occur through principled and systematic investigation of
evidence.
▪ In an evidence-based investigation, the incident response team correlates the tactics, techniques,
and procedures (TPP) that were used in the incident with other known exploits to identify threat
actors.
▪ Aspects of a threat that can aid in attribution are the location of originating hosts or domains,
features of the codes used in malware, the tools used, and other techniques.
INCIDENT RESPONSE MODELS
AND INCIDENT HANDLING
The Cyber Kill Chain
Steps of the Cyber Kill Chain®
Steps of the Cyber Kill Chain
▪ Developed by Lockheed Martin
to identify and prevent cyber
intrusions.
• The steps of the Cyber Kill Chain
help analysts understand the
techniques, tools, and
procedures of threat actors.
• The threat actor gains more
access to the target as they
progress through the steps.
• The goal is to stop them as early
as possible to lessen the damage
done.
The Cyber Kill Chain
Reconnaissance
▪ Reconnaissance is when the threat actor performs
research, gathers intelligence, and selects targets.
▪ Organizations may provide information on websites,
public-facing network devices, in news articles,
conference proceedings, and social media outlets.
The Cyber Kill Chain
Weaponization
▪ Weaponization uses the vulnerability information
gathered in the reconnaissance step to identify
and develop a weapon against specific targeted
systems in the organization.
The Cyber Kill Chain
Delivery

▪ Delivery is when the threat actor delivers the

developed weapon using either a website, a
removable USB media, or an email attachment.
The Cyber Kill Chain
Exploitation
▪ Exploitation is when the threat actor
triggers the weapon and executes it to
compromise the vulnerability and gain
control of the target.
The Cyber Kill Chain
Installation
▪ Installation is when the threat actor
establishes a back door into the system to
allow for continued access to the target.
The Cyber Kill Chain
Command and Control
▪ Command & Control (CnC or C2) is when an
outside server channel is used by the threat
actor to manipulate a target by issuing
commands to the software that they installed
on the target.
The Cyber Kill Chain
Actions on Objectives
▪ Actions on Objectives is the final step of the kill
chain and is when the attacker achieves attack
objective.
• Can be used for data theft, performing a DDoS attack, or
using the compromised network to create and send
spam.
• Threat actor is deeply rooted in the systems of the
organization and may be extremely difficult to remove
from the network.
The Diamond Model of Intrusion
Diamond Model Overview
▪ The Diamond Model identifies four parts involved in a security incident.
• Adversary – Parties responsible for the
Meta-features expand intrusion.
the model to include
important elements. • Capability – Tool or technique used by the
threat actor.
• Infrastructure – The network path(s) used by
the threat actor to establish and maintain
command and control.
• Victim – The target of the attack. The victim
could then used as part of the infrastructure to
launch other attacks.

▪ The adversary uses capabilities over infrastructure to attack the victim.

• Each line in the model shows how each part reached the other.
The Diamond Model of Intrusion
Pivoting Across the Diamond Model
▪ The Diamond Model is ideal for illustrating how the adversary pivots from one
event to the next.
For example
1) An employee reports that his computer is acting abnormally and a
scan indicates the computer is infected with malware.

2) An analysis of the malware reveals that the malware contains a list

of CnC domain names.
3) These domain names resolve to a list of IP addresses.
4) These IP addresses are used to investigate logs to determine if
other victims in the organization are using the CnC channel.
5) The IP addresses are also used to identify the adversary.
The Diamond Model of Intrusion
The Diamond Model and the Cyber Kill Chain
▪ The example illustrates the process used by an adversary as they traverse the
Cyber Kill Chain. 1) Adversary conducts a web search for victim company Gadgets, Inc.
receiving as part of the results their domain gadgets.com.
Reconnaissance
2) Adversary searches “network administrator gadget.com” and discovers
Weaponization the network administrators’ email addresses.
3) Adversary sends phishing emails with a Trojan horse attached to the
Delivery network administrators.

Exploitation 4) One network administrator (NA1) opens the malicious attachment which
executes the enclosed exploit.
Installation 5) NA1’s host registers with a CnC controller by sending an HTTP Post
message and receiving an HTTP Response in return.
C2
6) Analysis of the malware identifies additional backup IP addresses.
Action on 7) Through a CnC HTTP response message sent to NA1’s host, the malware
Objectives
begins to act as a proxy for new TCP connections.
The Diamond Model of Intrusion
The Diamond Model and the Cyber Kill Chain (Cont.)
▪ The example illustrates the process used by an adversary as they traverse the
Cyber Kill Chain. 8) Through the proxy established on NA1’s host, Adversary does a web
search for “most important research ever” and finds Victim 2, Interesting
Reconnaissance Research Inc.

Weaponization 9) Adversary checks NA1’s email contact list for any contacts from
Interesting Research Inc. and discovers the contact for the Interesting
Delivery
Research Inc. Chief Research Officer.
10) Chief Research Officer of Interesting Research Inc. receives a spear-phish
Exploitation email from Gadget Inc.’s NA1’s email address sent from NA1’s host with
the same payload as observed in Event 3.
Installation
The adversary now has two compromised victims from which additional
attacks can be launched.
C2

Action on
Objectives
The VERIS Schema
What is the VERIS Schema?
▪ Vocabulary for Event Recording and Incident Sharing (VERIS) schema is a set of
metrics to describe security incidents in a structured way.
VERIS schema
▪ In the VERIS schema, risk is defined as the intersection
of four landscapes of Threat, Asset, Impact, and Control.

▪ Information from each landscape helps to understand

the level of risk to the organization.

▪ VERIS helps to determine these landscapes using real

security incidents to help risk management assessment.
The VERIS Schema
Create a VERIS Record
▪ When creating records to add to the database, start
with the basic facts about the incident and use the
VERIS elements outlined by the community.
• The only required fields in the record are those where the
attribute is present.
• As more is known about the incident, data can be added.

Additional information can be recorded by adding VERIS labels to

the existing record.
The VERIS Schema
Top-Level and Second-Level Elements
▪ The VERIS Schema identifies five top-level elements, providing a different aspect of
the incident.
• Each top-level element contains several second-level elements for classifying
collected incident data.
▪ Impact Assessment – All incidents have an impact, whether it is
minor or widespread, which can only be determined after an
incident has occurred.

▪ Discovery and Response – Identifies the timeline of events, the

method of incident discovery, and what the response was to the
incident, including how it was remediated.

▪ Incident Description - Describes an incident completely, using the

A4 threat model developed by Verizon.

▪ Victim Demographics – Describes the organization that has

experienced the incident and its characteristics.

▪ Incident Tracking – Records general information about the incident

so organizations can identify, store, and retrieve incidents over
time.
The VERIS Schema
The VERIS Community Database
▪ The VERIS Community Database
(VCDB) is a very useful shared
database for organizations willing
to participate.
• Organizations can submit security
incident details to the VCDB for the
community to use.
• The larger and more robust the VCDB
becomes, the more useful it will be in
prevention, detection, and remediation of
security incidents.
• It will also become a very useful tool for
risk management, saving organizations
data, time, effort, and money.
CSIRTs
CSIRT Overview
▪ A Computer Security Incident Response Team (CSIRT) is a group commonly found
within an organization that provides services and functions to secure the assets of
that organization.

▪ A CSIRT:
• Responds to incidents that have
already happened.
• Provides proactive services and
functions such as penetration
testing, intrusion detection, or even
security awareness training.
CSIRTs
Types of CSIRTs
▪ There are many different types of CSIRTs
and related organizations:
• Internal – used in banks, hospitals,
universities, etc.
• National – handles incidents for a country
• Coordination center – incident handling
across multiple CSIRTs
• Analysis centers – data from many sources
to identify trends
• Vendor teams – remediation for
vulnerabilities in hardware/software
• Managed security service providers – a fee-
based service
CSIRTs
CERT
▪ Computer Emergency Response Team
(CERT) is a trademarked acronym
owned by Carnegie Mellon University.
▪ A CERT provides security awareness,
best practices, and security
vulnerability information, but does not
respond to security incidents.
▪ Other countries have asked for
permission to use the CERT acronym.
NIST 800-61r2
Establishing an Incident Response Capability
▪ The NIST “Computer Security Incident Handling Guide” Special Publication
800-61, revision 2 (800-61r2) provides guidelines for:
• Incident handling
• Analyzing incident-related data
• Determining the appropriate response to each incident
▪ NIST recommends establishing a computer security incident response
capability (CSIRC) and creating:
• Incident Response Policies
• Incident Response Plans
• Incident Response Procedures
NIST 800-61r2
Incident Response Stakeholders
▪ The following groups and individuals may also be involved with incident handling.

▪ It is important to ensure their cooperation before an incident is underway as their

expertise and abilities can help the CSIRT to handle the incident quickly and
correctly.
NIST 800-61r2
NIST Incident Response Life Cycle
▪ NIST defines the following four steps in the incident response process life cycle:
• Preparation – The members of the CSIRT are trained in how to respond to an incident.
• Detection and Analysis – Through continuous monitoring, the CSIRT quickly identifies,
analyzes, and validates an incident.
• Containment, Eradication, and Recovery – The CSIRT implements procedures to contain the
threat, eradicate the impact on organizational assets, and use backups to restore data and
software.
• Post-Incident Activities – The CSIRT then documents how the incident was handled,
recommends changes for future response, and specifies how to avoid a reoccurrence .
NIST 800-61r2
Preparation

▪ The preparation phase is when the CSIRT is:

• Created and trained
• Tools and assets that will be needed to investigate incidents are acquired and deployed.

▪ The following are examples of actions that also take place during the preparation phase:
• Organizational processes are created to address communication between people on the response team.
• Facilities to host the response team and the SOC are created.
• Necessary hardware and software for incident analysis and mitigation is acquired.
• Risk assessments are used to implement controls that will limit the number of incidents.
• Validation of security hardware and software deployment is performed on devices.
• User security awareness training materials are developed.
NIST 800-61r2
Detection and Analysis
▪ Different types of incidents will require different responses and organizations need to be prepared for
incidents from various attack vectors including the Web, Email, loss or theft, impersonation, attrition,
or media.

▪ Some incidents are easy to detect while others may go undetected for months.
• There are automated ways of detection such as antivirus software or an IDS.
• There are also manual detections through user reports.
• There are two categories for the signs of an incident; precursor and indicator.
▪ Incident analysis is difficult because not all of the indicators are accurate and the CSIRT must react
quickly to validate and analyze incidents.

▪ Incident notification is when an incident is analyzed and prioritized, the incident response team
needs to notify the appropriate individuals so that all who need to be involved will play their roles.
NIST 800-61r2
Containment, Eradication, and Recovery
▪ Containment ensures the incident does not continue.
• Different types of incidents will require different strategies.
• For every type of incident, a containment strategy should be created and enforced.
• During an incident, evidence must be gathered and documented in a clear and concise manner
for subsequent investigation by authorities.

▪ Eradication is identifying all of the hosts that need remediation and all of the effects
of the security incident must be eliminated.
• Exploited vulnerabilities must be corrected or patched so that the incident does not occur again.

▪ Recovery of hosts requires clean and recent backups, or they will have to be rebuilt
with installation media.
NIST 800-61r2
Post-Incident Activity Phase

▪ It is important to perform a post-mortem and periodically meet with all

of the parties involved to discuss the events that took place and the
actions of all of the individuals while handling the incident.
▪ After a major incident has been handled, the organization should hold a
“lessons learned” meeting to:
• Review the effectiveness of the incident handling process.
• Identify necessary hardening needed for existing security controls and practices.
NIST 800-61r2
Incident Data Collection and Retention
▪ In the ‘lessons learned’ meetings, the collected data can be used to:
• Determine the cost of an incident for budgeting reasons.
• Determine the effectiveness of the CSIRT.
• Identify possible security weaknesses throughout the system.

▪ NIST Special Publication 800-61 provides examples of performing an objective

assessment of an incident.
▪ There should be an evidence retention policy that outlines how long evidence of an
incident should be retained.
• Evidence is often retained for many months or many years after an incident has taken place.
• Reasons affecting evidence retention include prosecution, the type of data, and the cost of
storage.
NIST 800-61r2
Reporting Requirements and Information Sharing
▪ An organization may have reporting requirements.
• There could be governmental regulations which the organization must adhere to.
• Management may also have to report to stakeholders, customers, vendors, partners, etc.

▪ NIST recommends organizations share incident information with VERIS, however:

• Plan incident coordination with external parties before incidents occur.
• Consult with the legal department before initiating any coordination efforts.
• Perform incident information sharing throughout the incident response life cycle.
• Attempt to automate as much of the information sharing process as possible.
• Balance the benefits of information sharing with the drawbacks of sharing sensitive information.
• Share as much of the appropriate incident information as possible with other organizations.
• Diane Barrett/ Martin M. Weiss (2018).CompTIA Security+ SY0-501 Exam Cram (5th Edition)

• Emmett Dulaney and Chuck Easttom. CompTIA Security+ Study Guide: Exam SY0-501 7th Edition

• David L. Prowse (2018) Pearson. CompTIA Security+ SY0-501 Cert Guide (4th Edition)

• Cisco Networking Academy (Author).(June 25, 2018)CCNA Cybersecurity Operations Companion

Guide 1st Edition

• Omar Santos/ Joseph Muniz /Stefano De Crescenzo(June 17, 2017)CCNA Cyber Ops (SECFND #210-
250 and SECOPS #210-255)Official Cert Guide Library 1st Edition