Discovering the Scope of the Incident
In this chapter we’re bridging incident detection and characterization with data collection and analysis—two major parts of the book. We will present real-world scenarios and walk you through reviewing the initial data, developing leads, collecting preliminary evidence, performing a high-level review, and then determining the appropriate data collection and preservation activities. To discover the scope of an incident, you are essentially performing a limited investigation.
To help make it clear what we’re focusing on in this chapter, think about a police investigation. If a convenience store is robbed, the police do not interview every single person within a certain radius of the crime. Nor do they seize every item in the store for fingerprint dusting. Rather, they gather and examine initial evidence. They take statements from witnesses, or review security camera footage. Based on that information, they decide what next steps are most likely to further the investigation—perhaps interviewing other people, reviewing additional security camera footage, or obtaining a search warrant. In some cases, the police may decide there is no effective way to pursue the investigation, perhaps due to a lack of initial evidence.
Given that background, let’s think about how you would scope a computer security incident. Although the incident involves computers, many traditional investigative principles still apply. A good incident responder will consider those principles, because they are generally effective at solving crime. For example, if you detect that a user received a phishing e-mail, you should determine additional facts, such as what other users received the e-mail, what departments they work in, and what dates the e-mails were received. In this chapter, we share some of our experience with applying traditional investigative principles in the context of computer security incidents. First, we cover some basic concepts, and then we look at a number of scenarios to help illustrate how you might use them.
Before We Get Started
The scenarios presented later in this chapter are realistic scenarios based on actual investigations we’ve personally done. However, there is no direct correlation between our scenarios and an incident at any single organization. We’ve taken special care to sanitize all the details and “mix things up.” If you read one of our scenarios and think we’re discussing an incident that occurred at your organization, keep in mind that you are not alone—these scenarios have occurred at an alarming number of organizations.
Throughout our scenarios, we reference a few topics that we have not fully covered yet. For example, as part of a scenario, we might perform a live response. Although we have presented the concept of a live response earlier in the book, we have not provided details on the actual process yet. For the purposes of this chapter, however, those details are not critical. If you are still interested in seeing those details now, feel free to skip ahead and read some of the data collection and analysis chapters and then return here.
In this section, we’ll discuss some basic concepts you can use in the early stages of your investigation to help you discover the scope and decide what steps to take next. When we say “scope,” we mean gaining a better idea of what the attacker did, because initial detection rarely tells a complete story. We will cover three areas that should help you discover the scope:
• Examining initial data
• Gathering and reviewing preliminary evidence
• Determining a course of action
Later in this chapter, we present a number of scenarios to help illustrate how to apply the concepts discussed in each of these areas. Please keep that in mind as you are reading the remainder of this section—there’s more to come. Let’s look at the first area, examining initial data.
Examining Initial Data
As part of the detection event, you should have some initial information about the detection. For example, if the event was structured query language (SQL) injection, you should have a date, time, and the source and destination IP addresses. You will also want to talk to the staff that manages the detection system to see if any other details are available. Use a “trust but verify” approach—ask if you can see the alert details. You may notice that there is additional information that is useful to the investigation. Ask about other detection systems and what they detect and record—there may be systems in place that could provide additional information. Keep in mind that network administrators may not think like investigators. You should not assume they would tell you about “important information,” because they may not know what is important to the investigation.
The detection event should not stand on its own, however. You must assemble facts that provide a better context of the detection event. For example, you may receive an alert that a system in your environment connected to a website that hosts malware. Your reaction may be to contain the system, perhaps by removing its network access, and that may be a good first step. However, it’s also a good idea to find out more. Think about the five W’s and one H—who, what, when, where, why, and how. Who is the user? What department do they work for? Has anyone talked to them? Were they at the computer? What time of day did it happen? What was the website? Is it well known? What was transferred? How much data was transferred? What data was downloaded or uploaded? Are there other anomalies related to that system or user subsequent to this event? The answers to questions like these may have a large impact on how you decide to proceed.
Now that you’ve examined the initial data, let’s discuss how you will decide what preliminary evidence to gather and what you will do with it.
In this step, you have to determine what sources of preliminary evidence may be able to help and then decide which sources you will actually use. Finally, you will collect and review the evidence. You will need to find evidence sources that quickly provide initial answers. Ideally, you should identify sources of evidence that come from several categories and require low effort to analyze. For example, if an investigative question is to determine if malware executed on a system, you might consider the following evidence sources:
• Artifacts the malware directly creates on the system, such as files or registry keys
• Operating system artifacts, such as Windows prefetch, that are indirect artifacts
• Application artifacts, such as Internet browser history or software metering tools
• Network artifacts, such as firewall logs that might record network connections
Those four sources are what we call “independent evidence sources.” For example, the existence of firewall logs that might show the malware’s network connections does not depend on the presence of a registry key, and vice versa. You will come to conclusions that are more reliable if you use multiple independent evidence sources. Let’s talk a little bit more about this because it’s very important during the early stages of an investigation.
If you use independent sources, the likelihood that you will detect execution, if it happened, is higher. There are a number of reasons we believe this is true. It’s more difficult for an attacker to remove or modify evidence from all independent evidence sources. It’s also less likely that a routine process would overwrite or discard evidence in all sources. And with multiple independent sources, you can cross-check information, such as the exact time an event occurred. If the sources agree, whether the findings are positive or negative, conclusions based on the findings are more compelling.
If the sources are dependent on each other or fall within a single category, such as Windows prefetch, the chance of detection is lower. For example, it’s possible that Windows simply deletes prefetch files as part of the normal prefetch file management process. Evidence sources from a single category often lead to inconclusive results because there are too many alternate theories that you cannot rule out.
After you’ve identified sources and gathered the data, you will perform a review. Every minute that passes, the attacker may be causing more damage. Therefore, you should use review methods that produce results quickly. You should also perform basic tests to ensure the review method is fast and accurate. For example, if you need to query firewall logs for a specific IP address, you should start out with a small test—such as querying data for only one day. That test will give you an idea of how long the query takes, which will allow you to decide whether or not the method is acceptable. You can also test accuracy by including an IP address that you know should generate results. In Chapters 11 through 16 of this book, we will go into more detail regarding analysis methods.
 |
As we’ve mentioned before in this book, the absence of evidence is not the evidence of absence. The initial system on which you detect malicious activity may be the only system affected … or it may be one of hundreds. The attacker may have just gained their initial foothold, or they may have stolen gigabytes of data. We’re not advocating a paranoid approach—we’re only suggesting that it’s poor form to assume that “nothing bad happened” when you do not find evidence that it did. Based on our experience, that assumption is a major factor when breaches go undetected for extended periods. |
Determining a Course of Action
Once you have gathered and reviewed preliminary evidence, you will need to make decisions about what major activities to perform. Those activities normally include preserving evidence, but could also be posturing or containment actions. As with any decision, there are a number of factors you can weigh to help you make a choice. We find it helpful to ask ourselves the following questions throughout the scoping process:
• Will the action help answer an investigative question?
• Will the action answer my questions quickly?
• Am I following the evidence?
• Am I putting too much effort into a single theory?
• Am I using multiple independent sources of evidence?
• Do I understand the level of effort?
• Am I staying objective?
• Am I tracking the earliest and most recent evidence of compromise?
• Have I uncovered something that requires immediate remediation?
Because there is no “best way” to make a decision or “ideal path” to solve a case, we’ve decided to present two scenarios to help illustrate the process. Each scenario contains a reasonable investigative outcome, followed by one or more paths that are problematic. We’ve taken this approach so that you can see a pattern in the adequate versus inadequate investigative paths, and the reasoning that leads to each. Because this chapter is about discovering the scope of an incident, these scenarios only cover the investigation aspects. Remediation and recovery topics are covered in Chapters 17 and 18.
In this scenario, you work in the IT security department for a large online retailer. Your company has been receiving increased complaints from customers regarding e-mail spam. The customers indicate that shortly after becoming a new customer, they begin to receive a large amount of e-mail spam. This scenario is initially a bit less “concrete” than others are, because there is no real alert data or other indication of a security issue. Nevertheless, concern is mounting, and IT security has been asked to investigate.
Let’s start by examining the initial data. Because the “initial data” related to the scenario is anecdotal customer complaints, you decide you need something more concrete to support the customers’ claims. One option is to work with customers and review their e-mail. However, that idea has a number of reliability and privacy concerns and should probably be avoided. A better choice is to create fake customer accounts, each with unique e-mail addresses. Therefore, you decide to create three fake customer accounts, each with unique e-mail addresses in separate e-mail domains. To greatly reduce the likelihood that spammers would “guess” the addresses, you create the usernames as random strings 64 bytes in length. After creating the customer accounts, you begin monitoring the associated e-mail accounts for any incoming messages. Meanwhile, you assume data is being lost somehow, and begin to do some research and prepare for what might come next.
Moving into the gathering and reviewing preliminary evidence phase, your first step is to determine where the customer data resides and how it is managed. You start by locating all databases where customer e-mail addresses were stored. If the e-mail addresses are being stolen, they should come from one of these databases. You discover that there is one internal database and one external database. The internal database is the production server used for normal business. The external database is with a third-party marketing firm, primarily used for e-mail and postal mail campaigns.
To gain additional context, you interview the in-house IT department and business owners to learn more about the database type and size, the approximate volume of network traffic, when records were updated, who performed the updates, where backups were kept, and how and when records were transferred to the third-party marketing firm. You learn the following facts:
• The customer database system is a mainstream commercial product, with advanced query monitoring and reporting capabilities.
• The database is approximately 500GB (gigabytes) in size.
• The database network traffic is approximately 3TB (terabytes) per day.
• Customer records are updated directly via the company website or manually via phone call into the customer service department.
• No other method of updating customer records exists.
• Backups are kept both on-site and off-site at another of your company’s facilities.
• The marketing firm receives data at the end of the month following any updates.
• It’s unlikely the marketing firm is a source of the data loss, because, according to the customers’ complaints, spam was received sooner than the firm received the data.
• Theft of customer records via customers calling in via phone seems unlikely; therefore, any investigative focus on the data input side would concentrate on the website.
• The volume of network traffic to the database is high, so performing a network packet capture may be difficult, if required. Because the database supports advanced query monitoring, this may be a better method to monitor database access.
At this point, you are still waiting to see if any spam comes in to the e-mail accounts you created for the fake customers. So while you wait, you think about additional leads or theories to explain the situation. For example, a number of executives are asking if this could be the work of an insider. Also, perhaps someone modified the code on your website to send attackers a copy of a customer’s e-mail address, or is taking copies of backup tapes. Although those other theories are possible, right now you do not have information that suggests one is more likely than another. Expending a large amount of effort on any one of those theories is not justified at this point. Nevertheless, you can still determine some low-effort steps that may help you eliminate one or more of these theories. For example, you could directly enter customer information into the database instead of using the website. If you notice the e-mail address is still spammed, then you have some evidence to suggest the website is not involved. Regarding the backup tape theory, you can request someone on the IT staff create an extra backup that contains customer records that are not part of the production database. And, finally, regarding an insider threat, there are no reasonable investigative steps to take at this point, although it may prove useful to compile a list of accounts that have access to the customer database.
After two weeks of waiting, you begin to receive spam in the e-mail accounts for the fake customer profiles you created. The messages come in quickly, and within two days each account has about 20 spam e-mails, all very closely related in content. You also receive spam associated with the account you manually entered into the database, suggesting the website is not part of the problem. In addition, you still do not see any spam connected with accounts you placed on the backup tapes, suggesting that is not the source of the data loss.
Based on known facts, it seems like the strongest lead for data loss is direct access to the database. The attacker might have malware on the database server, or they could be accessing it over the network. There are two basic ways to monitor queries—through network-level packet captures or through database-level query monitoring and logging. Because there is a very high volume of network traffic to the database, performing a packet capture will require you to implement a high-end monitoring system that will require time and incur significant cost. Also, if the queries are encrypted or if the attacker is accessing the database through malware on the system, you may not be able to easily decode the network content. Therefore, you decide that the most efficient and reliable way to gather additional evidence is to implement database-level query monitoring. At the same time, you also create a few more fake customer accounts so that you can collect additional data points for the investigation.
For the first couple of days after setting up the query monitoring, you scan through the logs to get an idea of what looks “normal.” You also talk to the database and application administrators to identify exactly where certain data is stored for a customer. Specifically, you check to see if there are any queries or stored procedures that perform a bulk export of customer profile information that includes e-mail addresses. You don’t notice any that seem to happen on a daily basis, so you are hopeful that it will be obvious if an attacker does query the database. After two more weeks of waiting, you begin to receive spam on the newly created accounts. So you retrieve the query logs that cover the period from when you last reviewed them up until you began to receive spam. You search through the logs for the field of interest, “custemail.” There is a single query containing that string, and it occurred three days ago. The query was “select custemail from custprofile where signupdate >= 2014-02-16.” This SQL query retrieves customer e-mail addresses for accounts that were created on or after February 16, 2014. That date is about two weeks ago, roughly coinciding with the last wave of new spam.
A review of the logs reveals that the query was executed on February 17, 2014 at 11:42 A.M. GMT, and originated from an IP address that belongs to a desktop computer assigned to your company’s graphic arts department, but the query used a username that belongs to a database administrator from the IT department. You track down the graphic arts department director and ask if they do anything with customer e-mail addresses as part of normal business. They explain they have no interaction or contact with customers, but they do have frequent e-mail contact with a number of outside vendors.
At this point, you’ve gathered enough preliminary evidence to conclude there is an actual problem, you have good leads, and you can determine a course of action. First, let’s recap some of the critical points:
• There is evidence to support complaints of people receiving spam shortly after becoming a new customer.
• Preliminary data suggests a two-week cycle of data theft that only includes a customer’s e-mail address. The data is being extracted directly from the production database.
• Database queries are made over the network, originating from a desktop computer in the graphic arts department. The department does not use customer e-mail addresses are part of their normal business processes. Additionally, the query uses a database user ID that belongs to a database administrator in the IT department.
Now it’s time for you to determine a course of action. Based on these points, you have two main sources of evidence that could further the investigation—the production database and the desktop in the graphic arts department. Because you currently have few leads and a low volume of data, you decide it’s a better idea to gather evidence that is more detailed. Regarding the graphic arts desktop, you decide to do the following:
• Collect a live response.
• Create forensic images of memory and the hard drive.
• Interview the user and determine the following:
• How long the system has been assigned to them
• If they’ve noticed anyone using it who shouldn’t be
• If the system has been “acting strange”
• If the system is left on 24 hours a day, seven days a week
Regarding the database server, you decide to do the following:
• Collect a live response.
• Preserve all database logs that record user access.
• Preserve all query logs.
• Preserve all application and system logs.
As other members of your team perform the data collection, you start to think about what you will look for first once you have a copy. Because you know that a SQL query originated from the graphic arts computer on February 17, 2014 at 11:42 A.M. GMT, you believe examining that system first to see if anyone was logged in at the time is a good first step. You are also interested in that system’s network activity around the time of the query. Because your network assigns IP addresses with DHCP, you will need to determine what the system’s IP address was so you can query the proxy and firewall logs. (Note that in the preceding list, we retain all database logs that contain user access information. We don’t retain only the records pertaining to the suspected user account.)
A detailed examination of the graphic arts computer reveals that malware is installed. The malware is persistent, and provides comprehensive features including a remote shell, remote graphical interface, and the ability to launch and terminate processes. The malware connects to an IP address that is allocated to a foreign country. In addition, evidence suggests that the malware has been installed for nearly two years. However, there is insufficient evidence to explain how the system was originally compromised. Your final steps in the investigation are:
• Use a host-based inspection tool to examine each computer in your enterprise for indicators of compromise—file names, registry keys, and other unique characteristics of the malware.
• Query firewall logs for indications that other computers may be infected—traffic to the IP address the malware connects to.
This scenario mentions “insider threat” a few times. You may have noticed that we placed the insider threat theory at the same level, or perhaps lower, than other theories—even when part of the initial evidence pointed to an internal system. You may hear some people argue that the insider threat is more likely because it’s “easier” to attack a network from within, or because the news media says it’s a big problem. In our experience, attackers often find it easy to gain access to internal systems—although victims never admit as much because it would be embarrassing or legally damning. In addition, we have found that investigations tend to fail when they focus too much on “who is doing this” before they answer “what is happening.” Therefore, without other specific evidence that suggests an insider threat, we recommend that you simply follow the evidence and keep an open mind. |
Next, let’s look at a number of ways scoping this scenario could have lead to undesirable outcomes.
Customer Data Loss—Scoping Gone Wrong
This scenario started off light on details and, because of that, could have easily taken a turn for the worse. Here are a few of those paths:
• The Unwise Path After receiving complaints that customer data was being stolen, a decision is made to search every computer in the company for unique strings that are part of the customer data. During the search for strings, files over a certain size are also cataloged. The size is computed based on the size of the customer records.
The Problem Using this approach might be OK if you had more information to suggest that the data was being stored on a system within your environment. This approach also assumes that the entire list of customer e-mail addresses was being extracted from the database at every theft interval. There is no indication that occurred. Also, that approach does not make sense because extracting the full list incurs significant overhead on the database, on the system the data is placed on, and on the Internet connection. At a minimum, the attacker would probably use compression, likely reducing the size of the data by a factor of 10. Finally, the level of effort required to search thousands of computers in an enterprise, and deal with possible compression/encoding and false positives, can be very high. This path is more of a “last resort” option.
• The Unwise Path The investigation focuses on who within the company had enough knowledge and access to steal the customer information. Profiles of numerous employees are compiled. Each employee’s personnel file is reviewed. Additional background checks are performed on each person. Surveillance software that captures keystrokes and screenshots are installed on the employees’ computers. Security footage of their coming and going from the office is copied and reviewed on a daily basis.
The Problem Focusing on “who could do this” often leads to a witch-hunt instead of an investigation. This path arguably invades the privacy of employees, and with no evidence to suggest that any of them are involved.
• The Unwise Path Because the customer data resides on the database server, the security team decides to image and analyze memory from the database server. They believe there must be malware on the server because data is being stolen. And even if there isn’t malware, they believe there must be some remnants of malicious activity in memory. The team focuses on memory because the time and space required to create an image is much less than imaging the hard drives. They also believe that anything that happens on the system must, at some point, be in memory—so the need to preserve the hard drives is low. They proceed to image memory on a daily basis, looking for something malicious.
The Problem Making a conscious decision to focus all of your resources on a single category of evidence is poor investigative form, regardless of how confident you are in that source.
AUTOMATED CLEARING HOUSE (ACH) FRAUD SCENARIO
In this scenario, you work for a local hardware store chain. You are the IT director and the IT security manager. You were just informed by your CEO that the company’s bank called to let him know they stopped an ACH transfer of $183,642.73. The transfer was to an account that has never been used before and was flagged by their fraud prevention system. The bank indicates that the CFO’s online banking account was used. The CFO says he did not make that transfer request. Your CEO confirms that the transfer request was not legitimate. Your CEO wants you to figure out how this happened. You start by reviewing the information the bank provided:
• The transfer request was initiated online using your CFO’s online banking account.
• The requested transfer amount was US$183,642.73.
• The transfer request was initiated one day ago, at 4:37 P.M. GMT-5 (EST).
• The source IP address was your company’s public Internet IP address (your firewall).
Based on this initial data, you begin to think about what sources of preliminary evidence you might want to examine. Considering two broad categories—network and host—the first sources that come to mind are the firewall and the CFO’s laptop computer. You know that the firewall keeps about two weeks of logs that you can examine. In addition, you could collect forensic data from the CFO’s computer, such as live response, memory, and the hard drive. However, it’s possible that a computer other than the CFO’s is involved. Because your Internet traffic is not high and you can quickly export the firewall logs, you decide to first quickly review the logs for connections to the bank. That should help answer what sources of evidence are high priority.
You export yesterday’s firewall logs to your computer and begin a preliminary review. You think it’s best to start looking near the time the unauthorized transfer request occurred, because someone should have logged in just prior to the transfer request. Therefore, you perform a search for all connections to the bank’s IP address any time within the 4:00 P.M. hour. You find that there are a number of connections over port 443, the standard HTTPS port, starting around 4:10 P.M. and continuing until 4:48 P.M. Within those connection records, you identify two unique internal IP addresses—one belongs to your CFO’s computer and the other you do not immediately recognize.
Based on the results of your preliminary firewall log review, you come up with two high-priority tasks. First, because you have preliminary evidence that suggests a link between the unauthorized transaction and the CFO’s computer, you believe it’s important to preserve full forensic data—live response, memory, and hard drive. You must do this quickly because with a recent event, there is a higher likelihood that useful artifacts are still on the system. Second, because you identified another IP address that connected to the bank’s website around the same time, you need to track down that IP address and, once you understand more, take appropriate action.
While waiting for the data collection processes on the CFO’s computer to finish, you start to track down the IP address you didn’t recognize. Because your network’s IP scheme is controlled through DHCP, you decide to check the DHCP server logs to find more information about the IP address. You search for the IP address on the date in question, and discover that it was assigned to the MAC address of the wireless card in the CFO’s laptop. So for now you don’t have another computer to deal with—the preliminary evidence suggests the incident is isolated to the CFO’s computer. Because the data collection is still running, you take the time to export a copy of all the firewall logs so they are preserved.
Next, you decide to talk to the CFO to gain some context regarding his computer. During the interview, you discover the following:
• The CFO was at work yesterday, but left for the day at 4:30 P.M.
• The CFO had a meeting just prior to leaving for the day. The meeting was held in the conference room, and during that time, the CFO says he used the company wireless network. The meeting was to compare your current bank’s service offerings against a competitor. During that meeting, the CFO did access the bank’s website, but did not use online banking.
• The CFO restates that he did not initiate the unauthorized transfer, and that he does not know anything about the destination account number associated with the transfer.
As the initial data collection is wrapping up, you begin to develop your plan to move the investigation forward. First, let’s recap what you know and what evidence you have collected:
• A review of the firewall logs shows connections from your CFO’s computer to the bank during the time frame in question. There were no connections from other computers.
• The CFO says he did not request the transfer, and, additionally, he was not in the office at the time of the transfer request. Your company does not provide remote access to computers left at the office.
• You have firewall logs for the past two weeks.
• You have live response data, memory, and hard drive images of the CFO’s computer.
Based on that, let’s plan what you should do next. Given that there was a connection from the CFO’s computer to the bank at the time the unauthorized transfer was requested, but the CFO was not at the office, you theorize explanations for the connection:
• Perhaps someone entered the CFO’s office and used his computer—you could check the Windows event logs for logon events. You could also check security cameras to see if anyone entered the CFO’s office.
• Maybe there is undetected malware on the CFO’s computer, providing a remote attacker with access to the system—you could review the forensic data you collected for suspicious startup programs or artifacts created around the time in question.
You believe it’s unlikely that someone entered the CFO’s office at around 4:37 P.M., because the office space is open and anyone moving around is easily seen. So you decide to pursue the theory that malware is on the CFO’s computer, and begin by performing a review of the live response and disk image you collected. The thought occurs to you that perhaps you should perform a close inspection of firewall logs for traffic after the CFO left the office for the day. For now, you decide that looking at the system may provide artifacts that are easier to identify—so reviewing the firewall logs will be next on your list after spending some time reviewing the system. As you review the evidence collected from the CFO’s computer, you discover a recently installed persistent executable. You send the file to a third party for analysis, and they conclude that the file is a variant of the Zeus banking malware. They provide you with some additional indicators of compromise, and your final steps in the investigation are
• Conduct a thorough forensic examination of the CFO’s computer. You still need to determine how and when the system was infected.
• Use a host-based inspection tool to examine each computer at your company for indicators of compromise—file names, registry keys, and other unique characteristics of the malware.
• Query firewall logs for indications that other computers may be infected—traffic to the IP address the malware communicates with.
As this investigation winds down, let’s think about how different decisions may have affected the outcome.
ACH Fraud—Scoping Gone Wrong
The initial details in this scenario were helpful in developing good leads. Even so, poor judgment could have lead to a very different outcome. Here are two that come to mind:
• The Unwise Path You have no recent antivirus or IDS alerts, so you believe the security issue must be at the bank. You push back on the bank’s claims, stating there are no security issues at your company and that the bank should solve the case. Because a valid destination bank account was specified in the unauthorized transaction, you think the bank should be able to work with the financial community and track down who really did this and put them in jail.
The Problem There was no attempt made to validate the bank’s initial data. Your company assumes that existing network security measures would detect a problem, if there was one. There is also an assumption that one or more third-party organizations can help further the investigation. Finally, if you decide to investigate your network at some point in the future, the associated delay in preserving data may result in losing critical evidence.
• The Unwise Path Your CEO believes that financial institutions have security measures in place to prevent exactly this type of problem, so the CFO must have initiated the transfer. The CEO wants you to investigate the CFO as the primary suspect and avoid tipping him off.
The Problem Even if security measures were in place, such as two-factor authentication, no security system is invulnerable. In addition, the focus of the investigation is going outside of your area of expertise, so you should recommend that your CEO seek outside assistance.
SO WHAT?
Discovering the scope of an incident is a critical part of quickly solving the case. Understanding the scope allows you to make better decisions about where to use resources—including people and technology—on a case. The process we outlined in this chapter will help you to form good scoping habits so you effectively allocate your resources, focus on the right tasks, and ultimately find evidence that allows you to solve the case.
1. If your evidence sources do not include multiple independent categories, what steps could you take to increase confidence in your conclusions?
2. In the ACH fraud scenario, think of another reasonable theory for how an attacker might have gained access to the CFO’s computer. Explain how you would proceed with investigating that theory.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.