Foundation Topics
In this chapter, you will learn the different cyber security principles, including what threats, vulnerabilities, and exploits are. You will also learn details about what defense in depth is and how to perform risk analysis. This chapter also provides an overview of what runbooks are and how to perform runbook automation (RBA).
When you are performing incident response and forensics tasks, you always have to be aware of how to collect evidence and what the appropriate evidentiary chain of custody is. This chapter provides an overview of chain of custody when it pertains to cyber security investigations. You will learn the details about reverse engineering, forensics, and sliding window anomaly detection. You will also learn what personally identifiable information (PII) and protected health information (PHI) are, especially pertaining to different regulatory standards such as the Payment Card Industry Data Security Standard (PCI DSS) and the Health Insurance Portability and Accountability Act (HIPAA).
In this chapter, you will also learn the concepts of principle of least privilege. It is important to know how to perform risk scoring and risk weighting in the realm of risk assessment and risk reduction. This chapter provides an overview of these risk assessment and risk reduction methodologies.
The Principles of the Defense-in-Depth Strategy
If you are a cyber security expert, or even an amateur, you probably already know that when you deploy a firewall or an intrusion prevention system (IPS) or install antivirus or advanced malware protection on your machine, you cannot assume you are now safe and secure. A layered and cross-boundary “defense-in-depth” strategy is what is needed to protect your network and corporate assets. One of the primary benefits of a defense-in-depth strategy is that even if a single control (such as a firewall or IPS) fails, other controls can still protect your environment and assets. Figure 3-1 illustrates this concept.
)
Figure 3-1 Defense in Depth
The following are the layers illustrated in Figure 3-1 (starting from the top):
Nontechnical activities such as appropriate security policies and procedures, and end-user and staff training.
Physical security, including cameras, physical access control (such as badge readers, retina scanners, and fingerprint scanners), and locks.
Network security best practices, such as routing protocol authentication, control plane policing (CoPP), network device hardening, and so on.
Host security solutions such as advanced malware protection (AMP) for endpoints, antiviruses, and so on.
Application security best practices such as application robustness testing, fuzzing, defenses against cross-site scripting (XSS), cross-site request forgery (CSRF) attacks, SQL injection attacks, and so on.
The actual data traversing the network. You can employ encryption at rest and in transit to protect data.
The first step in the process of preparing your network and staff to successfully identify security threats is achieving complete network visibility. You cannot protect against or mitigate what you cannot view/detect. You can achieve this level of network visibility through existing features on network devices you already have and on devices whose potential you do not even realize. In addition, you should create strategic network diagrams to clearly illustrate your packet flows and where, within the network, you could enable security mechanisms to identify, classify, and mitigate the threats. Remember that network security is a constant war. When defending against the enemy, you must know your own territory and implement defense mechanisms.
In some cases, onion-like diagrams are used to help illustrate and analyze what “defense-in-depth” protections and enforcements should be deployed in a network. Figure 3-2 shows an example of one of these onion diagrams, where network resources are protected through several layers of security.
)
Figure 3-2 Layered Onion Diagram Example
You can create this type of diagram, not only to understand the architecture of your organization, but also to strategically identify places within the infrastructure where you can implement telemetry mechanisms such as NetFlow and identify choke points where you can mitigate an incident. Notice that the access, distribution, and core layers/boundaries are clearly defined.
These types of diagrams also help you visualize operational risks within your organization. The diagrams can be based on device roles and can be developed for critical systems you want to protect. For example, identify a critical system within your organization and create a layered diagram similar to the one in Figure 3-2. In this example, an “important database in the data center” is the most critical application/data source for this company. The diagram includes the database in the center.
You can also use this type of diagram to audit device roles and the types of services they should be running. For example, you can decide in what devices you can run services such as Cisco NetFlow or where to enforce security policies. In addition, you can see the life of a packet within your infrastructure, depending on the source and destination. An example is illustrated in Figure 3-3.
)
Figure 3-3 Layered Onion Diagram Example
In Figure 3-3, you can see a packet flow that occurs when a user from the call center accesses an Internet site. You know exactly where the packet is going based on your architecture as well as your security and routing policies. This is a simple example; however, you can use this concept to visualize risks and to prepare your isolation policies.
When applying defense-in-depth strategies, you can also look at a roles-based network security approach for security assessment in a simple manner. Each device on the network serves a purpose and has a role; subsequently, you should configure each device accordingly. You can think about the different planes as follows:
Management plane: This is the distributed and modular network management environment.
Control plane: This plane includes routing control. It is often a target because the control plane depends on direct CPU cycles.
User/data plane: This plane receives, processes, and transmits network data among all network elements.
Services plane: This is the Layer 7 application flow built on the foundation of the other layers.
Policies: The plane includes the business requirements. Cisco calls policies the “business glue” for the network. Policies and procedures are part of this section, and they apply to all the planes in this list.
You should also view security in two different perspectives, as illustrated in Figure 3-4:
Operational (reactive) security
Proactive security
)
Figure 3-4 Reactive vs. Proactive Security
You should have a balance between proactive and reactive security approaches. Prepare your network, staff, and organization as a whole to better identify, classify, trace back, and react to security incidents. In addition, proactively protect your organization while learning about new attack vectors, and mitigate those vectors with the appropriate hardware, software, and architecture solutions.
What Are Threats, Vulnerabilities, and Exploits?
In this section, you will learn the difference between vulnerabilities, threats, and exploits.
Vulnerabilities
A vulnerability is an exploitable weakness in a system or its design. Vulnerabilities can be found in protocols, operating systems, applications, hardware, and system designs. Vulnerabilities abound, with more discovered every day. You will learn many examples of vulnerability classifications in Chapter 13, “Types of Attacks and Vulnerabilities.” However, the following are a few examples:
SQL injection vulnerabilities
Command injections
Cross-site scripting (XSS)
Cross-site request forgery (CSRF)
API abuse vulnerabilities
Authentication vulnerabilities
Privilege escalation vulnerabilities
Cryptographic vulnerabilities
Error-handling vulnerabilities
Input validation vulnerabilities
Path traversal vulnerabilities
Buffer overflows
Deserialization of untrusted data
Directory restriction error
Double free
Password management: hardcoded password
Password plaintext storage
Vendors, security researchers, and vulnerability coordination centers typically assign vulnerabilities an identifier that’s disclosed to the public. This identifier is known as the Common Vulnerabilities and Exposures (CVE). CVE is an industry-wide standard. CVE is sponsored by US-CERT, the office of Cybersecurity and Communications at the U.S. Department of Homeland Security. Operating as DHS’s Federally Funded Research and Development Center (FFRDC), MITRE has copyrighted the CVE List for the benefit of the community in order to ensure it remains a free and open standard, as well as to legally protect the ongoing use of it and any resulting content by government, vendors, and/or users. MITRE maintains the CVE list and its public website, manages the CVE Compatibility Program, oversees the CVE Naming Authorities (CNAs), and provides impartial technical guidance to the CVE Editorial Board throughout the process to ensure CVE serves the public interest.
The goal of CVE is to make it easier to share data across tools, vulnerability repositories, and security services.
More information about CVE is available at http://cve.mitre.org.
Threats
A threat is any potential danger to an asset. If a vulnerability exists but has not yet been exploited—or, more importantly, it is not yet publicly known—the threat is latent and not yet realized. If someone is actively launching an attack against your system and successfully accesses something or compromises your security against an asset, the threat is realized. The entity that takes advantage of the vulnerability is known as the malicious actor, and the path used by this actor to perform the attack is known as the threat agent or threat vector.
A countermeasure is a safeguard that somehow mitigates a potential risk. It does so by either reducing or eliminating the vulnerability, or it at least reduces the likelihood of the threat agent to actually exploit the risk. For example, you might have an unpatched machine on your network, making it highly vulnerable. If that machine is unplugged from the network and ceases to have any interaction through exchanging data with any other device, you have successfully mitigated all those vulnerabilities. You have likely rendered that machine no longer an asset, though—but it is safer.
Threat Actors
Threat actors are the individuals (or group of individuals) who perform an attack or are responsible for a security incident that impacts or has the potential of impacting an organization or individual. There are several types of threat actors:
Script kiddies: People who uses existing “scripts” or tools to hack into computers and networks. They lack the expertise to write their own scripts.
Organized crime groups: Their main purpose is to steal information, scam people, and make money.
State sponsors and governments: These agents are interested in stealing data, including intellectual property and research-and-development data from major manufacturers, government agencies, and defense contractors.
Hacktivists: People who carry out cyber security attacks aimed at promoting a social or political cause.
Terrorist groups: These groups are motivated by political or religious beliefs.
Threat Intelligence
Threat intelligence is referred to as the knowledge about an existing or emerging threat to assets, including networks and systems. Threat intelligence includes context, mechanisms, indicators of compromise (IoCs), implications, and actionable advice. Threat intelligence is referred to as the information about the observables, indicators of compromise (IoCs) intent, and capabilities of internal and external threat actors and their attacks. Threat intelligence includes specifics on the tactics, techniques, and procedures of these adversaries. Threat intelligence’s primary purpose is to inform business decisions regarding the risks and implications associated with threats.
Converting these definitions into common language could translate to threat intelligence being evidence-based knowledge of the capabilities of internal and external threat actors. This type of data can be beneficial for the security operations center (SOC) of any organization. Threat intelligence extends cyber security awareness beyond the internal network by consuming intelligence from other sources Internet-wide related to possible threats to you or your organization. For instance, you can learn about threats that have impacted different external organizations. Subsequently, you can proactively prepare rather than react once the threat is seen against your network. Providing an enrichment data feed is one service that threat intelligence platforms would typically provide.
Forrester defines a five-step threat intelligence process (see Figure 3-5) for evaluating threat intelligence sources:
Step 1. Planning and direction
Step 2. Collection
Step 3. Processing
Step 4. Analysis and production
Step 5. Dissemination
)
Figure 3-5 Threat Intelligence
Many different threat intelligence platforms and services are available in the market nowadays. Cyber threat intelligence focuses on providing actionable information on adversaries, including indicators of compromise (IoCs). Threat intelligence feeds help you prioritize signals from internal systems against unknown threats. Cyber threat intelligence allows you to bring more focus to cyber security investigation because instead of blindly looking for “new” and “abnormal” events, you can search for specific IoCs, IP addresses, URLs, or exploit patterns. The following are a few examples:
Cyber Squad ThreatConnect: An on-premises, private, or public cloud solution offering threat data collection, analysis, collaboration, and expertise in a single platform. You can obtain more details at http://www.threatconnect.com.
BAE Detica CyberReveal: A multithreat monitoring, analytics, investigation, and response product. CyberReveal brings together BAE Systems Detica’s heritage in network intelligence, big-data analytics, and cyber threat research. CyberReveal consists of three core components: platform, analytics, and investigator. Learn more at http://www.baesystems.com.
Lockheed Martin Palisade: Supports comprehensive threat collection, analysis, collaboration, and expertise in a single platform. Learn more at http://www.lockheedmartin.com.
MITRE CRITs: Collaborative Research Into Threats (CRITs) is an open source feed for threat data. Learn more at https://crits.github.io.
Cisco AMP Threat Grid: Combines static and dynamic malware analysis with threat intelligence into one unified solution.
A number of standards are being developed for disseminating threat intelligence information. The following are a few examples:
Structured Threat Information eXpression (STIX): An express language designed for sharing of cyber attack information. STIX details can contain data such as the IP address of command-and-control servers (CnC), malware hashes, and so on. STIX was originally developed by MITRE and is now maintained by OASIS. You can obtain more information at http://stixproject.github.io.
Trusted Automated eXchange of Indicator Information (TAXII): An open transport mechanism that standardizes the automated exchange of cyber threat information. TAXII was originally developed by MITRE and is now maintained by OASIS. You can obtain more information at http://taxiiproject.github.io.
Cyber Observable eXpression (CybOX): A free standardized schema for specification, capture, characterization, and communication of events of stateful properties that are observable in the operational domain. CybOX was originally developed by MITRE and is now maintained by OASIS. You can obtain more information at https://cyboxproject.github.io.
Open Indicators of Compromise (OpenIOC): An open framework for sharing threat intelligence in a machine-digestible format. Learn more at http://www.openioc.org.
It should be noted that many open source and non-security-focused sources can be leveraged for threat intelligence as well. Some examples of these sources are social media, forums, blogs, and vendor websites.
Exploits
An exploit is software or a sequence of commands that takes advantage of a vulnerability in order to cause harm to a system or network. There are several methods of classifying exploits; however, the most common two categories are remote and local exploits. A remote exploit can be launched over a network and carries out the attack without any prior access to the vulnerable device or software. A local exploit requires the attacker or threat actor to have prior access to the vulnerable system.
There is also the concept of exploit kits. An exploit kit is a compilation of exploits that are often designed to be served from web servers. Their main purpose is identifying software vulnerabilities in client machines and then exploiting such vulnerabilities to upload and execute malicious code on the client. The following are a few examples of known exploit kits:
Angler
MPack
Fiesta
Phoenix
Blackhole
Crimepack
RIG
Confidentiality, Integrity, and Availability: The CIA Triad
Confidentiality, integrity and availability, is often referred to as the CIA triad. This is a model that was created to define security policies. In some cases, you may also see this model referred to as the AIC triad (availability, integrity and confidentiality) to avoid confusion with the United States Central Intelligence Agency.
The idea is that confidentiality, integrity and availability should be guaranteed in any system that is considered secured.
Confidentiality
The ISO 27000 standard has a very good definition: “confidentiality is the property, that information is not made available or disclosed to unauthorized individuals, entities, or processes.” One of the most common ways to protect the confidentiality of a system or its data is to use encryption. The Common Vulnerability Scoring System (CVSS) uses the CIA triad principles within the metrics used to calculate the CVSS base score.
Integrity
Integrity is the ability to make sure that a system and its data has not been altered or compromised. It ensures that the data is an accurate and unchanged representation of the original secure data. Integrity applies not only to data, but also to systems. For instance, if a threat actor changes the configuration of a server, firewall, router, switch or any other infrastructure device, it is considered that he or she impacted the integrity of the system.
Availability
Availability refers that a system or application must be “available” to authorized users at all times. According to the CVSS version 3 specification, the availability metric “measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the impacted component, this metric refers to the loss of availability of the impacted component itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of an impacted component.”
A common example of an attack that impacts availability is a denial of service (DoS) attack.
Risk and Risk Analysis
According to the Merriam-Webster dictionary, risk is “the possibility that something bad or unpleasant will happen.” In the world of cyber security, risk can be defined as the possibility of a security incident (something bad) happening. There are many standards and methodologies for classifying and analyzing cyber security risks. The Federal Financial Institutions Examination Council (FFIEC) developed the Cybersecurity Assessment Tool (Assessment) to help financial institutions identify their risks and determine their cyber security preparedness. This guidance/tool can be useful for any organization. The FFIEC tool provides a repeatable and measurable process for organizations to measure their cyber security readiness.
According to the FFIEC, the assessment consists of two parts:
Inherent Risk Profile and Cybersecurity Maturity: The Inherent Risk Profile identifies the institution’s inherent risk before implementing controls. The Cybersecurity Maturity includes domains, assessment factors, components, and individual declarative statements across five maturity levels to identify specific controls and practices that are in place. Although management can determine the institution’s maturity level in each domain, the Assessment is not designed to identify an overall cyber security maturity level.
The International Organization for Standardization (ISO) 27001: This is the international standard for implementing an information security management system (ISMS). ISO 27001 is heavily focused on risk-based planning to ensure that the identified information risks (including cyber risks) are appropriately managed according to the threats and the nature of those threats. ISO 31000 is the general risk management standard that includes principles and guidelines for managing risk. It can be used by any organization, regardless of its size, activity, or sector. Using ISO 31000 can help organizations increase the likelihood of achieving objectives, improve the identification of opportunities and threats, and effectively allocate and use resources for risk treatment.
The ISO/IEC 27005 standard is more focused on cyber security risk assessment. It is titled “Information technology—Security techniques—Information security risk management.”
The following is according to ISO’s website:
“The standard doesn’t specify, recommend or even name any specific risk management method. It does however imply a continual process consisting of a structured sequence of activities, some of which are iterative:
Establish the risk management context (e.g. the scope, compliance obligations, approaches/methods to be used and relevant policies and criteria such as the organization’s risk tolerance or appetite);
Quantitatively or qualitatively assess (i.e. identify, analyze and evaluate) relevant information risks, taking into account the information assets, threats, existing controls and vulnerabilities to determine the likelihood of incidents or incident scenarios, and the predicted business consequences if they were to occur, to determine a ‘level of risk;’
Treat (i.e. modify [use information security controls], retain [accept], avoid and/or share [with third parties]) the risks appropriately, using those ‘levels of risk’ to prioritize them;
Keep stakeholders informed throughout the process; and
Monitor and review risks, risk treatments, obligations and criteria on an ongoing basis, identifying and responding appropriately to significant changes.”
There are also standards to score the overall “risk” of a vulnerability. The most commonly used is the Common Vulnerability Scoring System (CVSS) developed by the Forum of Incident Response and Security Teams (FIRST). CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine the urgency and priority of response. CVSS is used by many Product Security Incident Response Teams (PSIRTs), vulnerability coordination centers, security researchers, and consumers of security vulnerability information.
There are also several additional scoring systems:
Common Weakness Scoring System (CWSS): A methodology for scoring software weaknesses. CWSS is part of the Common Weakness Enumerator (CWE) standard. More information about CWSS is available at http://cwe.mitre.org/cwss.
Common Misuse Scoring System (CMSS): A standardized way to measure software feature misuse vulnerabilities. More information about CMSS is available at http://scap.nist.gov/emerging-specs/listing.html#cmss.
Common Configuration Scoring System (CCSS): More information about CCSS can be found at http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf.
Personally Identifiable Information and Protected Health Information
Many regulations as well as the United States government require organizations to identify personally identifiable information (PII) and protected health information (PHI) and handle them in a secure manner. Unauthorized release or loss of such data could result in severe fines and penalties for the organization. Given the importance of PII and PHI, regulators and the government want to oversee the usage more efficiently. This section explains what PII and PHI are.
PII
According to the Executive Office of the President, Office of Management and Budget (OMB) and the U.S. Department of Commerce, Office of the Chief Information Officer, PII refers to “information which can be used to distinguish or trace an individual’s identity.” The following are a few examples:
The individual’s name
Social security number
Biological or personal characteristics, such as an image of distinguishing features, fingerprints, x-rays, voice signature, retina scan, and the geometry of the face
Date and place of birth
Mother’s maiden name
Credit card numbers
Bank account numbers
Driver license number
Address information, such as email addresses or street addresses, and telephone numbers for businesses or personal use
PHI
The Health Insurance Portability and Accountability Act (HIPAA) requires health care organizations and providers to adopt certain security regulations for protecting health information. The Privacy Rule calls this information “protected health information,” or PHI. This information includes, but is not limited to, the following:
Individual’s name (that is, patient’s name)
All dates directly linked to an individual, including date of birth, death, discharge, and administration
Telephone and fax numbers
Email addresses and geographic subdivisions such as street addresses, ZIP Codes, and county.
Medical record numbers and health plan beneficiary numbers
Certificate numbers or account numbers
Social security number
Driver license number
Biometric identifiers, including voice or fingerprints
Photos of the full face or recognizable features
Any unique number-based code or characteristic
The individual’s past, present, and future physical or mental health or condition
The provision of health care to the individual, or the past, present, or future payment for the provision of health care to the individual
Principle of Least Privilege and Separation of Duties
Two additional key concepts in information security are the principle of least privilege and separation of duties. This section defines these two key concepts.
Principle of Least Privilege
The principle of least privilege states that all users—whether they are individual contributors, managers, directors, or executives—should be granted only the level of privilege they need to do their jobs, and no more. For example, a sales account manager really has no business having administrator privileges over the network, or a call center staff member over critical corporate financial data.
The same concept of principle of least privilege can be applied to software. For example, programs or processes running on a system should have the capabilities they need to “get their job done,” but no root access to the system. If a vulnerability is exploited on a system that runs “everything as root,” the damage could extend to a complete compromise of the system. This is why you should always limit users, applications, and processes to access and run as the least privilege they need.
Separation of Duties
Separation of duties is an administrative control that dictates that a single individual should not perform all critical- or privileged-level duties. Additionally, important duties must be separated or divided among several individuals within the organization. The goal is to safeguard against a single individual performing sufficiently critical or privileged actions that could seriously damage a system or the organization as a whole. For instance, security auditors responsible for reviewing security logs should not necessarily have administrative rights over the systems. Another example is that a network administrator should not have the ability to alter logs on the system. This is to prevent such individuals from carrying out unauthorized actions and then deleting evidence of such action from the logs (in other words, covering their tracks).
Think about two users having two separate keys in order to open a safety deposit box. Separation of duties is similar to that concept, where the safety deposit box cannot be opened by a user without the other key.
Security Operation Centers
Security operation centers (SOCs) are facilities where an organization’s assets, including applications, databases, servers, networks, desktops, and other endpoints, are monitored, assessed, and protected. Establishing SOC capabilities requires careful planning. The planning phase helps you decide on and formalize yourself with the objectives that justify having an SOC, and to develop a roadmap you can use to track your progress against those predefined objectives. The success of any security program (including the SOC) depends on proper planning. There are always challenges that are specific to an organization, and these challenges are introduced because of issues related to governance, collaboration, lack of tools, lack of automation, lack of threat intelligence, skill sets, and so on. Such challenges must be identified and treated, or at least acknowledged, at an early stage of an SOC establishment program. SOCs are created to be able to address the following challenges:
How can you detect a compromise in a timely manner?
How do you triage a compromise to determine the severity and the scope?
What is the impact of the compromise to your business?
Who is responsible for detecting and mitigating a compromise?
Who should be informed or involved, and when do you deal with the compromise once detected?
How and when should you communicate a compromise internally or externally, and is that needed in the first place?
To build and operate an effective SOC, you must have the following:
Executive sponsorship.
SOC operating as a program. Organizations should operate the SOC as a program rather than a single project. Doing so depends on the criticality and the amount of resources required to design, build, and operate the various services offered by the SOC. Having a clear SOC service strategy with clear goals and priorities will shape the size of the SOC program, timeline, and the amount of resources required to deliver the program objectives.
A governance structure. Metrics must be established to measure the effectiveness of the SOC capabilities. These metrics should provide sufficient and relevant visibility to the organization’s management team on the performance of the SOC and should identify areas where improvements and investments are needed.
Effective team collaboration.
Access to data and systems.
Applicable processes and procedures.
Team skill sets and experience.
Budget (for example, will it be handled in-house or outsourced?).
Runbook Automation
Organizations need to have capabilities to define, build, orchestrate, manage, and monitor the different operational processes and workflows. This is achieved by implementing runbooks and runbook automation (RBA). A runbook is a collection of procedures and operations performed by system administrators, security professionals, or network operators. According to Gartner, “the growth of RBA has coincided with the need for IT operations executives to enhance IT operations efficiency measures.” Gartner, Inc. is an American research and advisory firm providing information technology related insight for IT and other business leaders.
Here are some of the metrics to measure effectiveness:
Mean time to repair (MTTR)
Mean time between failures (MTBF)
Mean time to discover a security incident
Mean time to contain or mitigate a security incident
Automating the provisioning of IT resources
Many different commercial and open source RBA solutions are available in the industry. An example of a popular open source RBA solution is Rundeck (http://rundeck.org/). Rundeck can be integrated with configuration management platforms such as Chef, Puppet, and Ansible. A commercial RBA example is the Cisco Workload Automation (CWA), which can manage different business processes across a comprehensive set of applications and systems. You can obtain more information about Cisco CWA at http://www.cisco.com/c/en/us/products/analytics-automation-software/tidal-enterprise-scheduler/index.html.
Forensics
The United States Computer Emergency Response Team (CERT) defines cyber forensics as follows:
“If you manage or administer information systems and networks, you should understand cyber forensics. Forensics is the process of using scientific knowledge for collecting, analyzing, and presenting evidence to the courts. (The word forensics means ‘to bring to the court.’) Forensics deals primarily with the recovery and analysis of latent evidence. Latent evidence can take many forms, from fingerprints left on a window to DNA evidence recovered from blood stains to the files on a hard drive.”
Cyber forensics is often referred to as “computer forensics.” However, “cyber forensics” is a more appropriate term than “computer forensics.”
The two primary objectives in cyber forensics are to find out what happened and to collect data in a manner that is acceptable to the court. Any device that can store data is potentially the object of cyber forensics, including, but not limited to, the following:
Computers (servers, desktop machines, and so on)
Smartphones
Tablets
Network infrastructure devices (routers, switches, firewalls, intrusion prevention systems)
Network management systems
Printers
Even vehicle GPSs
Chain of custody is critical to forensics investigations. The following section describes chain of custody in detail.
Evidentiary Chain of Custody
Chain of custody is the way you document and preserve evidence from the time that you started the cyber forensics investigation to the time the evidence is presented at court. It is extremely important to be able to show clear documentation of the following:
How the evidence was collected
When it was collected
How it was transported
How is was tracked
How it was stored
Who had access to the evidence and how it was accessed
When you collect evidence, you must protect its integrity. This involves making sure that nothing is added to the evidence and that nothing is deleted or destroyed (this is known as evidence preservation).
Several forensics tools are available on the market. The following are two of the most popular:
Guidance Software’s EnCase (https://www.guidancesoftware.com/)
AccessData’s Forensic Toolkit (http://accessdata.com/)
Another methodology used in evidence preservation is to use write-protected storage devices. In other words, the storage device you are investigating should immediately be write-protected before it is imaged and should be labeled to include the following:
Investigator’s name
The date when the image was created
Case name and number (if applicable)
Additionally, you must prevent electronic static or other discharge from damaging or erasing evidentiary data. Special evidence bags that are antistatic should be used to store digital devices. It is very important that you prevent electrostatic discharge (ESD) and other electrical discharges from damaging your evidence. Some organizations even have cyber forensic labs that control access to only authorized users and investigators. One method often used involves constructing what is called a “Faraday cage.” This “cage” is often built out of a mesh of conducting material that prevents electromagnetic energy from entering into or escaping from the cage. Also, this prevents devices from communicating via Wi-Fi or cellular signals.
What’s more, transporting the evidence to the forensics lab or any other place, including the courthouse, has to be done very carefully. It is critical that the chain of custody be maintained during this transport. When you transport the evidence, you should strive to secure it in a lockable container. It is also recommended that the responsible person stay with the evidence at all times during transportation.
Reverse Engineering
Reverse engineering is the methodology for acquiring architectural information about anything originally created by someone else. Reverse engineering has been around since long before computers or modern technology. Nowadays, reverse engineering is not only used to steal or counterfeit technology and to “reverse” cryptographic algorithms, but also to perform malware analysis and cyber security forensics. Reverse engineering can even be useful to software developers to discover how to interoperate with undocumented or partially documented software, or even to develop competing software (which in some cases may be illegal).
Reverse engineering can be used for exploit development to locate vulnerabilities in a system and compromise the system, but it also can be used on malware. Security researchers and forensics experts can trace every step the malware takes and assess the damage it could cause, the expected rate of infection, how it could be removed from infected systems, and how to potentially proactively defend against such a threat. Malware analysis extends to identifying whether malware is present on a given system and studying the malware to understand how it functions. Doing this can reveal the purpose of the malware, and even its author.
Two additional uses of reverse engineering are to “reverse” cryptographic algorithms to decrypt data as well as Digital Rights Management (DRM) solutions. Threat actors use DRM reverse-engineering techniques to steal music, movies, books, and any other content protected by DRM solutions.
Many tools are available for performing reverse engineering. The following are a few examples:
System-monitoring tools: Tools that sniff, monitor, explore, and otherwise expose the program being reversed.
Disassemblers: Tools that take a program’s executable binary as input and generate textual files that contain the assembly language code for the entire program or parts of it.
Debuggers: These tools allow reverse engineers to observe the program while it is running and to set breakpoints; they also provide the ability to trace through code. Reverse engineers can use debuggers to step through the disassembled code and watch the system as it runs the program, one instruction at a time.
Decompilers: Programs that take an executable binary file and attempt to produce readable high-level language code from it.