Cyber Crime Investigations

Investigating Insider Threat Using Enterprise Security Management • Appendix B 379 Room for Improvement Microsoft probably did not intend for security teams to collect and analyze Exchange message tracking logs, so ease of collection and parsing was not part of the product criteria because these logs were meant for debugging purposes. With that in mind, Microsoft could make improvements in several areas. One improvement could be the addition of a consolidated logging mechanism. A centralized log collector would eliminate the scenario of connecting to each Exchange server to collect mes- sages, and getting duplicate events as a message passes through each server.This would also alleviate the need to open network shares or install connectors on each Exchange server. It also would be nice to have different levels of logging. If all you had to do was track e-mails sent and received, it would be nice to turn off logging for all the other components.The most important improvement, however, would be the ability to log attachment names. It would be nice to see the actual attachment that was being sent with an e-mail.This is where the Exchange logs are lacking. If this functionality existed, it would be possible to see what types of documents were leaving the organization and being sent among groups. If we can write a signature on our intrusion detection system that will parse out the attachment name, it should be a trivial addition for Microsoft. In addition to Exchange, Sendmail does not log attachment names either. We have not been able to find a statement from either vendor indicating that they will include this capability in later releases of their products, nor that they are even con- sidering doing so. Everyone should call the vendor of their mail server and relay the message that this is important information and should be a requirement for future releases. As noted earlier, ILP systems are available that monitor e-mail as it crosses the network. Such products will provide the attachment names from e-mails that have been sent, but they come with their own sets of problems. Also, it’s fairly easy to change the name of an attachment, thus requiring deep inspection where the actual content of the attachment is analyzed. In large organizations, dealing with the massive amounts of traffic that need to be inspected can get expensive from a device perspective. E-mail is a great technology for communication. It allows users within organiza- tions to communicate efficiently across time zones, and it allows friends to stay in touch. Just imagine if every time you sent an e-mail you actually had to pick up the phone to get the same message delivered.You would never get anything done. As with all conveniences, we pay a price; a security risk is associated, and therefore, we must take precautions, such as monitoring. www.syngress.com

380 Appendix B • Investigating Insider Threat Using Enterprise Security Management Voice over IP Now we will walk through the collection of VoIP logs. VoIP is a way to send voice over a standard IP network. Voice coders and decoders are used to convert voice into IP packets that can be sent over the network.The Session Initiation Protocol (SIP) takes care of the routing and management of VoIP transactions. VoIP phone systems are becoming more and more prevalent.They are in most large organizations and have even started to hit the hotel and consumer markets. VoIP systems generate what is known as a call detail record (CDR), which is really just a log entry stating that a call was made or received.Tracking phone calls has been a hot topic in recent times, with the collection of CDRs from the major phone companies being consid- ered an invasion of privacy, but in the private and public sectors, usually an agree- ment is signed stating that all IP-related activity can and will be monitored for misuse. It’s hard to say whether CDRs should be considered to be logical security or physical security, but it seems that it could be considered either or neither. We con- sider phone records as a combination of the two. To understand VoIP logging let’s start with a simple example of how a call takes place. Figure B.12 depicts a typical VoIP topology.The call starts from the originator and is routed to the phone’s default gateway, which in the VoIP world is known as the signaling server.The signaling server is responsible for the setup and teardown of calls.The signaling server then routes the call to a call server, which runs software that performs call control functions such as accounting and administration, protocol conversion, and authorization.The call server then passes the call to the VoIP switch, which either sends the call out or routes it back to another internal phone. In VoIP, the sound from your voice is treated as data.The sound is converted into packets and traverses the network just as normal IP packets would.There are routers and switches, but the difference here is that a simple latency issue doesn’t make your download slow; it makes your VoIP service unusable, a condition known as the jitters.You may have experienced this before, where the person you are talking to sounds as though he is on another planet. A VoIP network consists of other com- ponents, such as media gateways that handle protocol conversions or components that convert text to voice. For further information on the inner workings of VoIP visit www.protocols.com/pbook/VoIPFamily.htm, where you’ll find a great introduction to the components and protocols involved. www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 381 Figure B.12 Simple VoIP Topology SIP Svr Call Svr Switch Benefits of Integration As with tracking any type of communications, monitoring VoIP logs provides basic session information similar to monitoring e-mail traffic.The information typically provided in a CDR is the call initiator, the recipient, and the duration of the call. If we compare CDRs to e-mail events, we can consider the duration to be the size of the message or how much information was communicated. Basic use cases would be to monitor top talkers, or monitoring who is talking to whom and what time of day calls are being placed. An interesting application for VoIP logs is to monitor off-hour usage, meaning who comes into the office on the weekends or in the middle of the night to make long-distance personal calls. More advanced use cases would be to build relationship charts that show all the people from different groups that are communicating with each other. For example, in the intelligence community, there are people with compartmentalized knowledge who should not share this information with other people who have different com- partmentalized knowledge. It seems as though monitoring phone calls among people would be very appealing to some of the more classified segments of the industry. In the use case we are discussing in this Appendix, VoIP logs play a key component to the detection mechanism that is proposed. Monitoring phone calls between users who should not be communicating on a regular basis will uncover anomalies such as high volumes of calls between users and long call duration.This type of behavior, although it may be normal and may not be malicious, can indicate that a user should be investigated further. www.syngress.com

382 Appendix B • Investigating Insider Threat Using Enterprise Security Management Challenges of Integration VoIP systems have been designed from the beginning with CDR logging in mind. Most, if not all, call servers have the capability to log the calls made and received. This logging was not designed with the security analyst in mind; its main driver is billing. If there was no logging, it would be impossible for service providers to charge for calls that are placed or received. Call servers write CDRs to local text files, but this is not the ideal place to col- lect them.The call servers usually have a management software package available that connects directly to a Transmission Control Protocol (TCP) port on each switch where these logs are constantly being streamed out (similar to syslog). Once they are collected, they are put into a database where they can be analyzed for billing and usage information.This works great for integration with ESM, because log aggrega- tors are our friends. Because the logs are already being aggregated and collected, all that’s needed is one connector to connect to one system to obtain all the call records from all the switches managed by the telephony manager application. The next step for integration with VoIP products is configuration, which is by no means a difficult task. Enabling CDRs for external-to-internal calls and internal- to-external calls is typically the default on most systems. On the Nortel system depicted in Table B.3, you can easily show the configuration of the trunks and see that CDR logging is enabled. Table B.3 Trunk Configuration on a Nortel System Default Configuration CDR Logging Enabled …snip… TYPE CDR_DATA CUST 00 CDR NO IMPH NO OMPH NO AXID NO TRCR NO …snip… …snip… TYPE CDR_DATA CUST 00 CDR YES IMPH NO Continued www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 383 Table B.3 continued Trunk Configuration on a Nortel System Default Configuration CDR Logging Enabled OMPH NO AXID NO TRCR NO …snip… …snip… TYPE CDR_DATA CUST 00 CDR YES IMPH NO OMPH NO AXID NO TRCR NO …snip… Granted, that’s not very challenging.The challenging part is configuring the log- ging of internal-to-internal calling. Most phone systems do not log this by default, because it’s not relevant to billing. In order to log this data, internal call detail (ICD) needs to be enabled. On Nortel systems, this setting is set to ICDD (Internal Call Detail Disabled) by default.Table B.4 shows how the configuration should look on a Nortel system if ICD is enabled. Table B.4 Configuration on a Nortel System When ICD Is Enabled Default Configuration ICDA Enabled …snip… CLS CTD FBA WTA LPR MTD FNA HTA TDD HFA CRPA MWA LMPN RMMD SMWD AAD IMD XHD IRA NID OLD VCE DRG1 POD DSX VMD CMSD SLKD CCSD SWD LNA CNDA CFTD SFD MRD DDV CNID CDCA MSID DAPA BFED RCBD CDMD LLCN MCTD CLBD AUTU GPUD DPUD DNDD CFXD ARHD CLTD ASCD CPFA CPTA ABDD CFHD FICD NAID BUZZ AGRD MOAD AHD Continued www.syngress.com

384 Appendix B • Investigating Insider Threat Using Enterprise Security Management Table B.4 Configuration on a Nortel System When ICD Is Enabled Default Configuration ICDA Enabled DDGA NAMA …snip… …snip… CLS CTD FBA WTA LPR MTD FNA HTA TDD HFA CRPA MWA LMPN RMMD SMWD AAD IMD XHD IRA NID OLD VCE DRG1 POD DSX VMD CMSD SLKD CCSD SWD LNA CNDA CFTD SFD MRD DDV CNID CDCA MSID DAPA BFED RCBD ICDA CDMD LLCN MCTD CLBD AUTU GPUD DPUD DNDD CFXD ARHD CLTD ASCD CPFA CPTA ABDD CFHD FICD NAID BUZZ AGRD MOAD AHD DDGA NAMA …snip… Log Format The logging format from VoIP systems is generally very simple and doesn’t contain too many fields that are relevant to ESM.The fields that are interesting for analysis are the call initiator, the recipient, and the call duration fields.The following log example is from a Nortel system: N 025 00 2600 T001023 08/16 17:34 00:03:18 A 14155551212 & 0000 0000 N 027 00 T001002 2600 08/16 17:38 00:00:06 A 14155551212 & 0000 0000 N 029 00 2600 2669 08/16 17:38 00:01:02 & 0000 0000 The first line shows an internal-to-external call, placed from extension 2600 to the number 415-555-1212, at 17:34, with a duration of 3 minutes and 18 seconds. The second line shows a call originating from an external number going to exten- sion 2600 with a 2-second duration.The third line shows an internal-to-internal call from extension 2600 to extension 2611 lasting 6 seconds. The relevant fields in the preceding log are the source of the call, the destina- tion, the duration, and the trunk the call went through.The trunk the call went through is not important in the actual analysis, but as far as understanding whether a call was inbound or outbound, the location of the trunk in the log line is important. In the preceding example, the trunk is the value that starts with a T and is in bold. If www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 385 the trunk appears before the extension, as in line two, it is an incoming call; if the trunk appears after the extension, it is an outbound call; and if no trunk is specified, the call was placed between two internal phones. It is also important to note that these logs are from a call server that serves only one prefix. If you have a server that serves multiple prefixes, the extension numbers will be five digits rather than four. From Logs to ESM After parsing the logs and sending the events to the ESM platform, they are ready to be analyzed and compared with other event feeds. As part of VoIP log processing, a process needed to be put in place to map the values to the appropriate fields.This can be especially challenging when placement of the values changes the meaning of the events, as is the case with the position of the trunk value. Furthermore, because this is a new event source, the schema does not always contain a field that can deal with a value such as a phone number.This requires that we add a new field to the system, or that we use a field that may be reserved for different types of values. In this case, it’s best not to abuse a field used for an IP address or a username; rather, we should use a field that is reserved for custom values for devices such as this. Figure B.13 shows how the events would look to an analyst as they come into the ArcSight ESM v4 console. Notice the direction associated with each event.The internal-to-internal calls have no direction because they stay within the same system. This will be important in our analysis process later. Figure B.13 ArcSight ESM v4 Source: ArcSight ESM v4.0 www.syngress.com

386 Appendix B • Investigating Insider Threat Using Enterprise Security Management Figure B.13 shows several calls being made and the fields as they map to the ESM schema. In the highlighted event, an inbound call was placed from 510-555- 1212 to extension 2600.The call’s duration was 1,980 seconds or 33 minutes. Figure B.14 shows a detailed event view of this phone call. Figure B.14 Detailed Event View of Call Shown in Figure B.13 Source: ArcSight ESM v4.0 The fields displayed are the event name; the priority of the event, which in this case is 2 because this is a normal event similar to a firewall accept; the direction of the call; the product vendor that generated the event; the originator; the recipient; the duration; and the trunk over which the call came.The biggest challenge here is the duration.This is a very important field in terms of analysis, as it allows you to compute top talkers, top talker pairs, and the most expensive phone calls. If you recall from the raw logs, the duration was in a time format whereby the call in this detailed view would have had a value of 22:30, or 22 minutes and 30 seconds.The raw value is very difficult to do any computation on, so the number must be con- verted into seconds to allow for functions to be run. In this example, 22:30 is con- verted into decimal notation as 22.5 minutes and then multiplied by 60 to get the total number of seconds that the call lasted. Figure B.15 is a visual analysis of these phone calls.The call originator is repre- sented by the small dark boxes; the call direction is represented by the gray circles; and the destination or call recipient is represented by the white boxes.The figure www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 387 shows several transactions. On the left, you can see that three inbound calls are placed to extension 2600.The graph on the right shows all the calls placed from extension 2600: three outbound calls and one internal-to-internal call. Figure B.15 Visual Analysis of the Preceding Phone Calls Source: ArcSight ESM v4.0 Visualization of event data always lends itself to speeding up the analysis process. It has been said that a picture is worth a thousand loglines, and seeing a visualization of phone calls made and received validates that statement.The number of phone calls made and received by large organizations per day can be in the millions (or, at least, hundreds of thousands).Trying to make any sense of those calls in a text-based log- file in the format shown previously would be a nightmare. With a visual representa- tion of the same messages, we can quickly separate inbound and outbound calls as well as determine the caller and recipient. Although the examples in this Appendix include a detailed explanation of VoIP CDRs and how we can collect them, similar logging mechanisms exist on most, if not all, private branch exchange (PBX) phone systems. PBX phone systems are beginning to be phased out by more advanced VoIP systems that are considered more reliable as well as more cost-effective.The events that a PBX system writes are known as call state events (CSEs) and again are written after a phone call has been www.syngress.com

388 Appendix B • Investigating Insider Threat Using Enterprise Security Management completed. PBX state events contain much of the same information that a VoIP system will write to a CDR—typically the caller, recipient, and call duration. Logical security typically deals with events generated from devices that are tied into the IP network of an organization. In the past, the phone system was com- pletely separated from the IP network, so if it was even considered, it was more in the communication or physical monitoring realm. Now with the introduction of IP- enabled phones, it tends to be a gray area where the collection of CDRs could be considered either physical or logical. As we move to the next section, it’s important to remember the information that we can obtain through the collection of CDRs. These events are not security events per se, and they don’t indicate any wrongdoing, but the statistics they provide give analysts another data point in their detection of an insider trading attempt. Bridging the Chinese Wall: Detection through Convergence Now that we have an understanding of what a Chinese wall is and some of the ben- efits and challenges of the collection of new data sources for analysis, we will walk through a simple scenario of two employees working for a large investment bank and how their plan to trade insider knowledge is detected. Several advanced correla- tion techniques will be addressed in the eventual detection, such as role-based corre- lation and statistical anomaly detection.The example we are using in this Appendix involves two users in an investment bank, but the theory and detection mechanism could be applied to any type of organization where silos of information need to be separated. Government agencies currently use these principles and data sources to monitor the communications of their internal employees. In such an example, it is not investment information that is considered compartmentalized; it is much more serious—the data could be the location of agents, agents’ identities, or upcoming missions, where a compromise wouldn’t have a dollar price tag.This technology cur- rently is applied across vertical markets because the underlying principles are good security practices and prevent the compromise of information among departments where the combination of compartmentalized knowledge leads to compromise. The Plot David and Maxwell work for a large financial institution, Finance123.They work in different departments: David works in the Mergers and Acquisitions department and Maxwell works in the Brokerage and Investment Banking department. Because communication between these two departments represents a conflict of interest and www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 389 violates compliance regulations, strict policies are in place prohibiting communica- tion between the departments.The policies even go so far as to restrict the employees from entering the building through the same entrance.The policies are verbally communicated, but there are no restrictions on who you can call, what e- mail addresses you can send or receive, or who you can meet for lunch down the street. Unfortunately, for Finance123, the technology and policies are not in sync. Not all policies can be implemented with technology; sometimes there are staff and procurement limitations, and as the old saying goes, “where there is a will, there is a way.”This is especially true of how humans behave when they are trying to get around the “system.”The best you can hope for in this situation is an early detection mechanism through warning signs, anomaly detection, and analysis, finding and stop- ping the problem before it occurs. Maxwell and David, our conspirators, know that the information they hold is valuable to one another. If David clues Maxwell in on an upcoming acquisition Maxwell can recommend to all of his clients to invest in the company that is going to be bought.This is good for both Maxwell and David; their commissions increase and they look like financial superstars.This activity is exactly what the Chinese wall was designed to prevent.The scenario shows how David and Maxwell’s communica- tion behavior is brought to the attention of security analysts, preventing what would be considered a breach of the set policies of Finance123 and an insider trading attempt. Detection Finance123 uses an advanced ESM system set up to monitor external threats and detect internal abuse. By collecting events from these nontraditional data sources, the company is able to monitor internal communications as well as detect anomalous behavior by employees.The setup is fairly typical of an ESM deployment. It consists of several components. Figure B.16 shows (from left to right) the devices generating the data, the ArcSight connectors that are collecting the data and forwarding it to the ESM system, the ArcSight Manager, and analyst consoles. www.syngress.com

390 Appendix B • Investigating Insider Threat Using Enterprise Security Management Figure B.16 Components of an ESM System ESM Connectors Microsoft ESM ESM Exchange Server Manager Console Nortel VoIP ESM Console ESM Console Building the Chinese Wall The first important step for eventual detection is for the ESM platform to under- stand the users in each department. We can refer to this as role-based correlation. Without an understanding of which users are in each department, analysis would be extremely difficult and would require an analyst to remember the different users and their departments. Furthermore, it wouldn’t be possible for the ESM platform to detect anomalous communications among groups without having an understanding of what the groups are. Because cross-departmental communications are being mon- itored between two departments, the setup is simple. All that is needed for the ESM platform to understand the user organization is a list of user attributes in each department. A user attribute is any value that identifies a particular user, such as a domain logon, extension, or e-mail address. Once we know the attributes of a particular user, we can correlate events and attribute events back to that user. Using Active List technology within ESM, we can easily track these attributes and correlate events against these lists, specifically checking for a particular event value as being in one of the lists. An example would be an event sent to ESM where the source username, maxwellj@finance123.com, is checked against the Active List to validate whether maxwellj@finance123.com is a member of the Brokerage department. Figure B.17 shows the two role-based active lists. www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 391 Figure B.17 Role-Based Active Lists Source: ArcSight ESM v4.0 In these two active lists, we have set up a virtual Chinese wall where we are keeping track of the user attributes from each department. In the Brokerage Active List, notice that there are several entries for Maxwell. We can see his e-mail address, his phone extension, and his Windows domain account logon username. In the Mergers and Acquisitions list to the right, there are similar attributes for David. Bridging the Chinese Wall As David and Maxwell continue to share information with each other, they commu- nicate using standard channels, not considering that they could be monitored. However, they are being monitored. All of their communications are being tracked, and because they have been corresponding quite a bit, their behavior sets off alerts in the ESM system because their patterns are anomalous.The setup used to detect these anomalies is a series of moving average data monitors. Data monitors sit in the real- time event flow and collect stats on the events that are coming into the ESM plat- form.The data monitors used in this scenario are designed to collect information on the communications that are occurring between departments. ESM is tracking all forms of communication between users in the two previously described active lists. If the e-mail sender is in the Brokerage Active List and the recipient is in the Mergers and Acquisitions Active List, or vice versa, the communication will be www.syngress.com

392 Appendix B • Investigating Insider Threat Using Enterprise Security Management tracked. Similarly for phone calls, if the caller is in one list and the destination exten- sion is in the other, the call will be tracked. So, why not alert on all communications between departments? There may be valid business reasons for some forms of communications, but if you look at every e- mail that is sent between the departments or every phone call made, you would need a team of hundreds of analysts.This is why we are looking for anomalies; either users who have never communicated before or users who demonstrate behavior pat- terns that fall outside those of normal communications. Four different data monitors are being used in this scenario.The first is tracking the number of e-mails sent between users in the two departments. Figure B.18 shows several groups of sender/recipient pairs that are communicating across depart- ments.The number of e-mails from Maxwell to David and David to Maxwell is far higher than those from most users in the organization.They are not the only users communicating between the departments, but they are the only two who seem to be replying to each other’s e-mail, as both show up as a sender and as a recipient. The other two nodes on the data monitor have only sent e-mail to the other department. Figure B.18 Groups of Sender/Recipient Pairs Communicating across Departments Source: ArcSight ESM v4.0 www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 393 The data monitor in the preceding figure shows the number of e-mails between a given sender and recipient pair from different departments over time. Each time slice is 24 hours.The x-axis represents time—in this case, days—and the y-axis rep- resents the number of e-mails.The expanded section shows that Maxwell has been sending David an average of eight e-mails per day for the past 11 days.This is quite a bit of communicating back and forth for two users who really don’t have any busi- ness communicating.The line in the middle of the chart shows the moving average. From the chart, one can conclude that prior e-mails sent from Maxwell to David were less than eight per day because the average is going up, and the number of e- mails sent from Maxwell to David has declined in the past two days; thus, the average begins to taper down.The node on the top right shows the number of e- mails David has sent Maxwell and the average is also going up.This is most likely because when the e-mails from Maxwell to David go up, David replies more often to Maxwell, or vice versa.The bottom-left portion shows the next highest sender recipient pair in the organization.This is user2 sending to userW. As we continue to monitor e-mail traffic between the departments, not only do we want to look for anomalies in the number of e-mails sent, but we also want to see the size of the e-mails sent. If two users are trying to hide their communication or just not communicating via e-mail, but one sends the other a large attachment con- taining details on all upcoming mergers and acquisitions, that communication needs to be caught, even though the message count would be only 1, meaning that it prob- ably wouldn’t show up on an analyst’s radar using the previous data monitor. Figure B.19 shows a data monitor looking for anomalies in the size of messages between users from different departments. It is apparent from the graph that Maxwell and David have been sending far more information back and forth than any other users in the two departments. We achieve this statistic by running a sum function on the bytes out field of the e-mail events that the Exchange server is generating. As mentioned, the preceding data monitor is doing a sum function on the size of all of the e-mail messages that have been sent between users in different depart- ments. Again, this is set up as size over a given time slice, which in this case is a 24- hour period.The y-axis is represented in bytes and the x-axis is represented in days. In the callout, you can see that Maxwell has sent David nearly 12 million bytes per day.This is nearly 1.15 MB. E-mail messages are typically very small. A large e-mail containing several paragraphs of text is typically around .5 MB.This would indicate more than the average “Hey what’s up?” e-mail going back and forth, and in fact would indicate that attachments probably are being sent or that data is being pasted into the body of the e-mail. www.syngress.com

394 Appendix B • Investigating Insider Threat Using Enterprise Security Management Figure B.19 Data Monitor Looking for Anomalies in Size of Messages Source: ArcSight ESM v4.0 David and Maxwell have been showing up all over the e-mail anomaly data monitors, and similar data monitors are tracking the usage of the VoIP system. With the VoIP events, we can track almost the same information as with e-mail if we think about the duration of the call as the bytes sent in the e-mail message. Figure B.20 shows the sum of the duration of calls that have taken place between users in the different departments—namely, David at extension 2156 and Maxwell at exten- sion 2609. Remember that the duration has been converted to seconds, so the num- bers in the legend represent seconds. Figure B.20 Sum of Duration of Calls between David and Maxwell Source: ArcSight ESM v4.0 www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 395 The data monitor in the figure is tracking the sum or total time spent on the phone between two extensions that are in different departments.The x-axis again represents the time slices, which are 12 hours, and the y-axis represents the total time spent on the phone per day, in seconds.The chart that is called out suggests that extension 2156 (David) has spent nearly 23 minutes per day on the phone with extension 2609 (Max). From the average marker in the middle of the graph, we can see that the average talk time between the two is steadily increasing. Figure B.21 shows the data monitors used in this scenario, displayed on a dash- board. Although we covered only one type of data monitor in this Appendix, there are different ways to present the data monitors, including event graphs, top values, and geographic event mapping, to name a few. We will use some of these data mon- itor types for analysis in other use case examples in this book. Figure B.21 Data Monitors Displayed on a Dashboard Source: ArcSight ESM v4.0 www.syngress.com

396 Appendix B • Investigating Insider Threat Using Enterprise Security Management Data monitors don’t just create a nice visual representation of event traffic; they also serve a much greater purpose.They actually perform statistical correlation. If an analyst wasn’t watching these visual representations all day long, the communication between Maxwell and David may have gone unnoticed. However, because data monitors are doing real-time analysis, they generate correlation events which can have actions associated with them.The correlation event is based on certain condi- tions that are configured as part of the data monitor, such as the percent deviation that you want to trigger an alarm or have an action take place. In this case, we are alerting whenever we see a spike in communications between departments that is greater than 10 percent.This means that the analyst a Finance123 received several notifications telling her that there was a spike in traffic between these two users. Figure B.22 shows the correlation events generated by these data monitors in the analyst’s console. Figure B.22 Correlation Events Generated by These Data Monitors in the ArcSight ESM Console Source: ArcSight ESM v4.0 Because the analyst has received these notifications, it’s time to do some investi- gation.The first step the analyst must take is to look at the details of the notifications and determine who is involved and what other events may be coming from those users.The best way to do this is to run an investigative report where the username is used as a filter condition.The analyst runs several reports to show calls made between Maxwell and David, the duration of the calls, and e-mail traffic between the two users.These reports can be presented to management, legal, or HR as evidence that these users have been displaying some questionable behavior.The report in www.syngress.com

Investigating Insider Threat Using Enterprise Security Management • Appendix B 397 Figure B.23 is an example of a user investigation report based on e-mail traffic between Maxwell and David. Figure B.23 User Investigation Report Based on E-mail Traffic between Maxwell and David Source: ArcSight ESM v4.0 Just by reading the message field of the e-mail alone, the analyst is very suspi- cious and decides that an investigation is warranted.The report is given to manage- ment, and further investigation into the contents of the e-mails, the different accounts that David has been involved with, and the investments that Maxwell has been advising on reveals too many coincidences to say they were not conducting fraudulent activities. www.syngress.com

398 Appendix B • Investigating Insider Threat Using Enterprise Security Management Conclusion The type of fraud we discussed in this Appendix would result not only in the loss of a job, but also in legal ramifications.The employees and the company in this case are fictitious, but this type of thing happens every day and is very hard to detect. If you consider all the information that is floating around your organization, imagine having to track where it is going externally, let alone internally.These are the types of processes that we can streamline and automate through ESM and the convergence of new data sources. Although these data sources do present some challenges, such as the collection of the e-mail messages and some of the parsing of the VoIP CDRs, these are things that will only improve over time as companies tell their vendors that they need manageable logs and the ability to collect those logs in a convenient manner. Once they are collected, there are worlds of possibilities for analysis. www.syngress.com

A Index Absolute immunity, 83-84 Association of Certified Fraud Access points Examiners, 276, 283 description of, 113, 128 ATMs, 230 encryption schemes used with, 116 Authentication ACFE. See Association of Certified admissibility of evidence and, Fraud Examiners correlation between, 180 Admissibility of evidence, 52-55, 180, digital evidence, 57-58, 65-66, 178- 225 179 “Agent of the government,” 76-78, in 802.11 standard, 114 87 encryption used for, 115 American Academy of Forensic investigator’s testimony used for, Sciences, 3 179 American Management Association, open system, 115-116 73 B Analysis phase, of digital forensics Backups, 228 binary analysis, 248 Barbera v. Smith, 83-84 challenges, 245 BestCrypt, 96-97 data carving, 250 Binary analysis, 248 deleted items, 249 BIOS, 167 description of, 223, 244-245 BitLocker Drive Encryption, 151 e-mail analysis, 250 Bit-stream copy, 171, 222 enterprise events, 251-252 Bit-stream image example of, 245 exchangeable image file format, 248 criticisms of, 16 flow charts, 251-252 definition of, 14, 171 metadata, 247 description of, 13 single-computer analysis, 247-250 evidence tampering and, 15 timelines, 252 Bloombecker, Buck, 161-162 tools used in, 253-255 Booting, accidental, 147 Andersen Consulting LLP v. UOP, 122 Britz, Marjorie, 28 Anti-forensics, 246-247 Burns v. Reed, 83-84 Anti-spyware software, 272-273 Business-targeted crime, 275-277 Anti-virus software, 272 Byte conversions, 92 Application stupidity, 197-198, 218 399

400 Index C tools necessary for, 226-228 from virtual machines, 238-239 California v. Ciraolo, 125 from VoIP systems, 234 Casey, Eoghan, 26 Common carrier, 122 CD, 167 Companies Cellular phones, 230-231, 271 concerns of, 79-80 Certification of personnel, 191-192 confidential information held by, CFAA. See Computer Fraud and 80-81 Abuse Act corporate practices of, 81-82 Chain of custody media avoidance by, 81 Compression, 93 authenticating of evidence through, Computer 56-58 accidental booting of, 147 Computer Fraud and Abuse Act cyber crime investigator’s use of, 57 definition of, 13-14 definition of, 31 Chat messaging, 213 crimes determined without Chat sessions, 168-169 Child pornography, 4-6, 71, 180-181 presence of, 11-12 Civil cases, 64 criminal involvement, 7-8 Collection of data and evidence definitions of, 31, 33 admissibility concerns, 225 digital evidence from, 26 from cell phones, 230-231 disassembly of, 181 criteria for, 225 as evidence, 137-138, 141 description of, 222-223 familiarity with, 7 from digital entertainment systems, as incidental to crime, 26 as instrument of crime, 26 229-230 IP addresses, 198-202 from digital video recorders, 233- MAC addresses of, 115-116, 205- 234 206 from flash memory, 231-232 nondigital evidence associated with, from gaming machines, 232-233 from global positioning system, 233 181-182 from hard drive interfaces, 229 operating system of, 148-149 from MP3 players, 229-230 personal. See Personal computers from NAS devices, 238 storage on, 92-93 from PBX systems, 234 system time, 181 from PDAs, 230-231 as target of crime, 26 preparation for, 226-229 transporting of, 147 from Raid arrays, 236-237 of victims of crime, 163 from SANs, 236-238 Computer abuse, 25

Index 401 Computer crime mission critical, 93 categories of, 26 network infrastructure, 161-162 crime as central focus of, 40-41 pulling-the-plug on, 148-149, 160 cyber crime vs., 33-40 shutting down, 90, 148, 151 defining of, 24-31, 33, 195 user-friendliness of, 197 evolution of, 31-33 Computer tampering, 7 focus of, 40 Computer trespasser, 122 laws pertaining to, 46-47 Computer viruses, 272, 276 legal definition of, 29, 31 Computer-assisted crimes, 27 linguistic confusion associated with, Confidential information, 80-81 34 Crime word origin of, 33 computer. See Computer crime cyber. See Cyber crime Computer Crime and Intellectual during cyber crime investigation, Property Section, 29, 139-140 20, 87 Computer crime investigations desensitizing of, 9-10 communities involved in, 24 perpetuation methods, 195-196 evolution of, 32 Crime scene digital media identified at, 145-146 Computer focused crimes, 27 seizure method that minimizes, 178 Computer forensics “Crimes with a cyber-component,” analysis programs used in, 138 40-43, 47 best practices for, 220-221 Criminal cases, 64 description of, 90 Cross examination, 62-63 evolution of, 220-222 Cryptographic algorithms, 16 future of, 106 Cyber crime preview software packages used in, absence of laws for, 20 167-168 computer crime vs., 33-40 specialists in, 155 computer involvement, 11-12 Computer Fraud and Abuse Act crime as central focus of, 40-41 description of, 29-31 “crimes with a cyber-component” statutory violations under, 123-124 WiFi transmission eavesdropping term vs., 40-43, 47 defining of, 28, 33, 42 and, 123-124, 127 desensitization associated with, 9-10 Computer hardware seizure. See legal categories of, 27-28 local agency reporting, 162-163 Hardware seizure media use of, 42 Computer system myths regarding, 7-11 Computer Fraud and Abuse Act provisions regarding access to, 127

402 Index personal computer effects on, 141, overview of, 263-268 162 personal property-targeted crime, persons who commit, 265 272-275 public perceptions of, 24 summary of, 281-282 scene of. See Crime scene Cyber crime prevention substantiation of, 163 traditional crime and, 8-10 organizations, 283 victims of, 162-164 Cyber stalking, 7 Cyber crime investigations Cyber-deceptions and thefts, 27 crime committed during course of, Cyberethics, 29 Cyber-handshake, 127 20, 87 Cyber-pornography, 27 description of, 2-3 Cyber-trespass, 27 in-house, 71 Cyber-violence, 28 tools used in, 174-177 Cyber crime investigators D authentication of seized evidence Dante, 2 by, 179 Data bridging the gaps among, 38-40, 42 case study involving, 2-3 collection of. See Collection of data elistist mentality of, 10-11 and evidence foundation of the crime established encrypted, 109 by, 82 live, examination of, 16 getting started as, 217-218 storage of, on alternative media, 230 jargon use by, 35-36, 41 volatility of, 228 as percipient witnesses, 51-52 Data carving, 250 prosecutor’s relationship with, 58-59 Data objects role of, 72-78, 85-86 definition of, 134-135, 138, 189 testifying by. See Testifying discovery of, after seizure, 143 training of, 20, 217 finite, on-scene imaging of, 171- Cyber crime laws, 4-6 Cyber crime prevention 174 business-targeted crime, 275-277 physical container vs., 139 family-targeted crime, 268-271 Databases, 253-254 government agency-targeted crime, dcfldd, 240 dd, 240 278-280 Defense counsel motives analysis, 264-265 alternative defenses presented by, 63 organization-targeted crime, 277- cross examination by, 62-63 278

Index 403 digital evidence admissibility warrant for, 173 challenges, 53 Digital forensics technical expertise level of, 60-61 analysis phase of. See Analysis phase, Defiler’s Toolkit, 246 of digital forensics Deleted items, 249 Denial-of-service attack, 26 best practices of, 223 Deposition, 64 collection phase of. See Collection Dial-up modem, 199 Digital entertainment systems, 229- of data and evidence definition of, 220 230 examination phase of, 223, 241-244 Digital evidence. See also Evidence phases of, 222-256, 258 reporting phase of, 223, 255-256 admissibility of, 52-55, 180, 225 software, 259 authenticating of, 57-58, 65-66, Digital media. See also Media convergence of, 155 178-179, 225 documentation of, 146 believability of, 225 identification of, at crime scene, completeness of, 225 criteria for, 225 145-146 defining of, 137-141 prioritizing of, 146 description of, 26 pulling-the-plug on, 148-149, 160 hash values of, 57-58, 65-66, 180 seizure of, 147 identification of, 145-146 size of, 150-151 law enforcement officer training in, stolen, 192 Digital protocols, 119 159 Digital video recorders, 233-234 on-scene assessment of, 142 Direct connect model, 100 original computer used to view, 138 Direct examination, 62 previewing of, on-scene, 167, 180- Direct sequence spread spectrum, 120 Documentation, 146, 177, 235-236 181, 183 DSL, 199-200 reliability of, 225 DSSS. See Direct sequence spread tools for collection of, 174-177 Digital evidence seizure spectrum common threads in, 177-180 DVD, 167, 214 description of, 135 DVR. See Digital video recorders example of, 164-166 Dynamic addressing, 200-201 importance of, 159-160 Dynamic analysis, 248 methodology used in, 141-149, 178, 180-182, 189 options for, 159-177 steps involved in, 144, 160-161

404 Index E Employee(s) monitoring of, 74-75, 87 Eavesdropping privacy of, 74 WiFi. See WiFi transmission eavesdropping Encryption on wired network, 115 authentication through, 115 file level, 94-95 ECPA. See Electronic full disk, 243-244 Communications Privacy Act of police transmissions, 119 volume level, 95 802.3 standard, 113 whole disk, 95, 99, 151-152 802.11 standard End-user license agreement, 274 authentication in, 114 Enterprise network, 91 definition of, 113 Ethernet, 113 nonencrypted nature of, 122 Evidence. See also Digital evidence privacy in, 115-116 summary of, 126 authenticating of, 56-58 802.11a standard, 114, 118 chain of custody for, 13-14, 56-58 802.11b standard, 114, 118 computer as, 137-138, 141 802.11g standard, 114, 118 definition of, 137 Electronic Communications Privacy electronic, 13 hearsay requirements for, 15 Act information as, 141, 161 “access” terminology used in, 130 preservation of, 13 description of, 73, 75 prioritizing of, 11-13 “electronic communications” testimony about, 14 weight of, 50, 55 provisions, 121 Evidence tampering WiFi transmission eavesdropping bit-stream image standard and, 15 standards for preventing, 14 and, 121-122, 126 Exabyte, 92t Electronic evidence, 13 Examination phase, of digital Electronic Frontier Foundation, 153 E-mail forensics, 223, 241-244 Exchangeable image file format, 248 analysis of, 250 EXIF. See Exchangeable image file description of, 211-212 from e-mail programs, 212 format free, 212 Expert witness harassment using, 163 monitoring of, 73-74, 87 definition of, 52 original computer used to view, 138 expertise of, 55-56 phishing scam using, 194 tracing of, 6, 212

Index 405 F G Facebook, 213 Gaming machines, 232-233, 271 Faraday device, 222 Gateways, 203-204 Fast forensics, 244 Gigabyte, 92t Federal Rules of Criminal Procedure, Global positioning system, 233 Government agency-targeted crime, 139 Federal Rules of Evidence, 139, 178 278-280 FHSS. See Frequency hopping spread GPS. See Global positioning system GREP, 253 spectrum Grice, Paul, 34 Fiber channel, 229 Fiber-channel storage area networks, H 237 Hacker Defender, 104-105, 105f File level encryption, 94-95 Hanson, Kirk, 70 File slack space, 135 Hard drive Finder of fact, 62 Fingerprints, 221 copying files from, 109 Firewalls, 273-275 difficulty in accessing, 181 First responders encryption of, 243 failure of, 179 definition of, 157-158 finite sections of, 171-174 seizure method selected by, 180 on-scene imaging of, 170-171, 173- training of, 158, 184 Flash drives, 145, 214 174, 183 Flash memory, 231-232 Hard drive interfaces, 229 Flow charts, 251-252, 256 Hardware documentation, 235-236 Forensic image, 223 Hardware seizure Forensics. See Computer forensics; description of, 142-143 Digital forensics; Live forensics encryption concerns, 151-152 Fourth Amendment, 125, 129 factors that limit, 149-157, 183 FRCP. See Federal Rules of Criminal labeling of hardware, 147 laboratory analysis delays after, 153- Procedure FRE. See Federal Rules of Evidence 155 Free Internet-based e-mail, 212 privacy concerns, 152-153 Frequency hopping spread spectrum, steps involved in, 143 Hash sets, 242 120 Hash values, 57-58, 65-66, 180 Friends network, 213 Hashes, 171, 224 FTK, 138 Full disk encryption, 243-244 Full disk imaging, 183

406 Index Hearsay, 15 previewing of, 167, 180-181, 183 Heatherington, Cynthia, 266 as property, 139 Helix, 167, 175 in RAM, 169 Hewlett-Packard, 2-3, 6, 70 from running computer, 168-170 High Technology Crime Investigation In-groups, 36-39 In-house investigations, 71 Association, 85, 283 Instant messaging, 196, 213 Homeland Security Presidential Institute of Electrical and Electronics Directive #5, 35 Engineers standards. See IEEE Host bus adapter, 237 standards Hostnames, 204 Internet Hotspots, 207-208 connection methods, 199 HTCIA. See High Technology Crime description of, 268 identity protection Investigation Association recommendations, 266 recommendations for using, 269- I 270 Internet Crimes Against Children Identity protection, 266 Task Forces, 173 Identity theft, 194 Internet service providers IEEE standards data retention by, 87 Internet access by, 199-200 definition of, 112-113 Interpersonal communication 802.3, 113 chat messaging, 213 802.11, 113-114 description of, 211 IM. See Instant messaging e-mail. See E-mail ImageMaster, 175 instant messaging, 196, 213 Imaging social networking, 32, 213-214 copying vs., 171 IP addresses, 198-202, 216 of finite data objects on-scene, 171- ipconfig, 201, 205 iPods, 229-230, 271 174 iSCSI, 237 full disk, 183 IT personnel of information on-scene, 170-171, as “agent of the government,” 76-78 crimes committed by, 75 183 information provided by, 78 Immunity, 82-84 in live forensic environment, 91 Industrial, scientific, and medical band, 118 Information duplicates of, 179 as evidence, 141, 161 imaging of, 170 on-scene, 167-168, 170

J Index 407 Jargon postmortem forensics vs., 90-99, cyber crime community’s use of, 101-104, 107 35-36, 41 in-group’s use of, 36-39 software manufacturers, 99-100 storage, 92-93 K Local area network, 113 Logical unit numbers, 237 Katz v. United States, 125 Kilobyte, 92t M Klismafile, 246 Knoppix, 167 MAC addresses, 115-116, 205-206 MAC spoofing, 205 L Malicious software, 104 Malware Laboratory analysis-related delays, 153-155 analysis of, 248-249 description of, 239, 275-276 Law enforcement officers Malware viruses, 273 acting as agent of, 76-78, 87 Maxims, 34 awareness-level training for, 159 MD5 algorithm, 14-15 computer-related training for, 156, MD5 hash, 171 158-159 Media. See also Digital media concerns of, 75-78 avoidance of, 81 corporate practices understood by, portability of, 214 79-82 technophobe portrayals by, 38 digital evidence training for, 159 types of, 214 role of, 79-82, 86 Megabyte, 92 tools used by, 176-177 Memory acquisition, 240 Memory analysis, 239-241 Linux operating system, 167, 227 Metadata, 247 Live forensics Metasploit, 246 Meterpreter, 246 case study of, 101-104 Mini smart cards, 214 encrypted file systems, 94-99 Modem enterprise network, 91 dial-up, 199 Hacker Defender, 104-105 external, 200 information gathered using, 101 MP3 players, 229-230, 271 IT security personnel in, 91 Musiker, Jean A., 74 methods of, 100 MySpace, 213-214

408 Index N Organization-targeted crime, 277-278 Out-groups, 36-39 NAS devices, 238 Outlook, 212 National Incident Management Outlook Express, 212 System, 35-36 P National Institute for Standards and Packet sniffer, 105 Technology, 176 Paraben Forensics Mail Examiner, National Institute of Justice, 4 Necrofile, 246 250 Network analysis, 105 Parker, Donn, 24-25 Network infrastructure, 161-162 Passwords Network interface cards, 114-115, encryption of, 244 200 trafficking of, 124 Network intrusion detection PBX systems, 234 PCI card, 240 software, 275 PDAs, 230-231, 262, 271 Networking, 202-204, 216 Percipient witnesses, 51-52 NIST. See National Institute for Personal computers computer crime affected by, 141, Standards and Technology *nix, 227, 240 162 development of, 32 O storage size of, 150, 161 Personal firewalls, 273-275 On demand connection model, 100 Petabyte, 92t One-party consent, 4-5 PGP, 151 Online predators, 218 Phishing scam, 194 On-scene imaging Physical memory capturing of, 103 of finite data objects, 171-174 imaging of, 96, 97f of hard drive, 170-171 Plea bargain, 50-51 On-scene previewing of information, Pod slurping, 230 Postmortem forensics, 90-99, 101- 167, 180-181, 183 On-scene responders, 142 104, 107 Open system authentication, 115-116 PPA. See Privacy Protection Act Operating systems Pre-deployed agent model, 100 Pretexting, 6 description of, 148-149 evolution of, 221 flow charts, 251-252, 256 hash sets of, 242 Optical media, 146

Index 409 Pretrial motions, 50-51 “dumping” of, 168-169, 183 Prevention. See Cyber crime Linux operating system’s use of, 167 recovery of, 168-169 prevention Remote access Trojan, 79-80 Privacy Report definition of, 255 of cellular conversations, 119-120 elements of, 255 in 802.11 standard, 115-116 review of, before testifying, 61 of employees, 74 Responders Fourth Amendment expectation of, first, 157-159 non-technical, 157 125, 129 training of, 155-157, 184 hardware seizure and, 152-153 Richards v. NYC, 83 in wireless local area networks, 115, Rootkits, 104, 109 Routers, 203, 208 1245 RTA v. Mitchell, 16 Privacy Protection Act, 152, 183 Running processes, 101, 108 Private networks, 203 Running services, 101, 102, 107-108 ProDiscover IR, 98 Property S access to, 265-266 Sam Juicer, 246 cyber crime that targets, 272-275 SANs, 236-238 definition of, 139-140 Sarbanes–Oxley Act, 70 information as, 139 SATA, 229 Prosecutor Scanner, 119 case discussions with, 59-60 SEARCH, 168-169 guidance provided by, 82 Search and seizures immunity of, 82-84 role of, 82-84, 86 by civilians, 76-77 technical expertise level of, 58-59, digital evidence. See Digital 67 evidence seizure “Pulling-the-plug,” 148-149, 160 hardware. See Hardware seizure unreasonable, 125 Q Security event management systems, Qualified immunity, 83 254-255 Seizures. See Search and seizures R RAID arrays, 150, 236-237 RAM data held in, 169

410 Index SEM systems. See Security event Technophobes management systems alienation of, 39-40 description of, 7, 9, 24 Slammer virus, 276 distancing from technology by, 37 Smyth v.The Pillsbury Company, 73 media portrayals of, 38 Snort, 254 as out-group, 37 Social networking, 32, 213-214 Spada, 167 Telecommunications Act, 123 Specialist-level responders, 156 Telephone Disclosure and Dispute Spreadsheets, 253 Spyware, 272-273 Resolution Act, 119-120 SQL databases, 254 Terabytes, 92, 150-151 Static addressing, 200-201 Testifying. See also Witness Static analysis, 248 Steve Jackson Games, Inc. v. Secret assessment of defense counsel before, 60-61 Service, 153 Storage, 92-93 cross examination, 62-63 Storage area networks. See SANs during deposition, 64 Storage media digital evidence admissibility evolution of, 221 established while, 52-55 on-scene previewing of information direct examination, 62 discussion with prosecutor before, on, 167, 180-181, 183 preparation of, 226-227 59-60 prioritizing of, 146 effective presentation during, 61-63 seizure of, 147 expertise level necessary for, 51-52 size of, 150-151, 154 keys to, 58-64 types of, 279 listening to question, 61 wireless, 210-211 misconceptions about, 51-56 System flow charts, 251-252 report review before, 61 System time, 181 summary of, 65 theory of the case understood T while, 63-64 Taylor, Robert, 26 Theory of the case, 63 Technician-level responders, 156 Timelines, 252, 256 Technophiles Timestomp, 246 TiVo, 233 definition of, 24 TPM chip, 152 jargon developed by, 35 Transmogrify, 246 Trap and trace, 5 Trojan defense, 249

Trojan horse, 78 Index 411 Trusted Platform Module, 243-244 Two-party consent, 5 Whole disk encryption, 95, 99, 151- 152 U WiFi U3 Smart Drives, 232 access points, 113, 116, 128 Unauthorized access, 29-30 description of, 112 United States v. Bonallo, 15 free access to, 112 United States v. Granderson, 125 summary of, 126, 128 United States v. Jarrett, 77-78 United States v. Knotts, 125 WiFi networks United States v. Steiger, 78 illegal access to, 130 United States v. Stephenson, 179 Wired Equivalency Protocol, 117 United States v.Whitaker, 15 Unreasonable searches, 125 WiFi protected access, 115-117 U.S. Department of Justice, 29, 160- WiFi radio frequency 161, 278 industrial, scientific, and medical USB Hacksaw, 232 band, 118 V overview of, 117-118 scanning, 118-120, 129 Virtual machines, 238-239, 249 WiFi transmission(s) Viruses, 272, 276 Computer Fraud and Abuse Act VoIP systems, 234 Volume level encryption, 95 applicability to, 123-124 eavesdropping. See WiFi W transmission eavesdropping Wardriving, 124, 208-210 Electronic Communications Privacy Warrant Act applicability to, 120-122 legality of, 50 interception of, 112-131 limitations of, 173 over common carrier, 122 need for, 6 privacy expectations, 125 reasons for issuing, 139 Telecommunications Act Weight of the evidence, 50, 55 WEP. See Wired Equivalency applicability to, 122 WiFi transmission eavesdropping Protocol federal statutes regarding, 121-124 hardware and software needed for, 120 passive manner of, 124, 127 summary of, 129 Wired equivalency protocol, 115-117 Wireless fidelity. See WiFi Wireless local area networks

412 Index description of, 113 encryption schemes used by, 115 privacy in, 115, 125 Wireless networks hotspots, 207-208 investigating of, 209-210 overview of, 206-207 summary of, 216-217 wardriving, 208-210 Wireless routers, 208 Wireless storage devices, 210-211 Witness. See also Testifying cross examination of, 62-63 direct examination of, 62 effective presentation as, 61-63 expert. See Expert witness percipient, 51-52 WPA. See WiFi protected access Write-blocker, 224 X Xbox, 232, 270-271 Y Yar, Majid, 27-28