Once you have your security intelligence, you have two options: take action or take no action. You would think that the most obvious option is to take action to address your threat, but security intelligence is often tricky because things are not always as “clear-cut” as we would like them to be. Sometimes, your intelligence is the “smoking gun” identifying a security incident. For example, in the case where you find “two concurrent virtual private network (VPN) logins” or “two VPN logins from different parts of the country,” you would probably call the employee and ask about the suspicious logins. In the best case scenario, the employee may have a completely legitimate reason for the logins from two different IP addresses. In the worst case scenario, the employee’s credentials have been compromised. Either way, you will be able to quickly mitigate the potential threat (unauthorized access).

Other times, the intelligence you found is just an indicator of something bigger that you have not quite figured out yet. For example, the intelligence you identified may be an indicator of a hacker, who is in the reconnaissance phase, sending probing packets to your network ports to observe the response. More often than not, it may just be an unexplained anomaly or a false positive for which you will find no answers. Such is the nature of working with intelligence—you never have complete visibility of the threat actors or their actions, but you still must do your best to protect your organization.

Security intelligence is oftentimes used for explanatory analysis (or retrospective analysis) to determine what happened during a security incident so that steps can be taken to mitigate a threat. Exploratory analysis is very valuable to increasing an organization’s defenses. Yet, the ultimate goal with security intelligence is to be able to conduct predictive analysis: to guess what your attacker will do so that you can implement countermeasures to thwart your attacker. Predictive analysis may seem more relevant in a real-time incident, such as ongoing distributed denial of service (DDOS) or a live intrusion. However, it is also relevant for dealing with day-to-day situations: by knowing your environment and your operational baseline, you are able to identify your strengths and weaknesses, which will assist you in developing responsive strategies.

It is impossible to protect against every threat, so one way to address this is by knowing your organization’s landscape and your intelligence gaps, which are the areas in which you lack information on your threats. By understanding your intelligence gaps, you will be able to focus your efforts to address these gaps and to set up early warning sensors. These sensors are usually a combination of tools to include vendor solutions (e.g., security information and event management) and the security analytics techniques discussed in this book.

Additionally, you will be able to address your internal security gaps. For example, suppose you know that your antivirus (AV) vendor’s product is not as robust as you would like, but your budget does not allow you to purchase a better product. Knowing that this is one of your intelligence gaps, you may be more vigilant at reviewing your logs and at checking your quarantined e-mail. You may be also looking for information to cover this gap through other means (increasing security education or frequent system tests).

As you develop your organization’s security intelligence, you will have a better understanding of your organization’s threat landscape and you will develop greater confidence in your ability to respond to the threats. Once you start using security intelligence, your mind-set changes from “reacting to events” to “methodically addressing top threats.” Our goal in this section is to have you start thinking about how security intelligence can increase your overall effectiveness and productivity. To cover all aspects of intelligence analysis in this section was not possible, but we hope to give you a basic understanding of how it works and how it can help you. If you are interested in learning more about this topic, you will find a resource by searching the Internet for “security intelligence analysis” or “intelligence analysis.”

We provided you with the knowledge to conduct an analysis of your existing security data to extract intelligence for security decisions by using the powerful, open-source software tools to examine structured and unstructured data. If you expand this to all of your organization’s businesses processes, you will be able to examine data in ways that you could never have imagined. You will be able to do this in real time to make proactive business decisions, instead of just using historical data to make reactive decisions. In fact, the real power of analytics is realized when you are able to take data across different departments to generate predictive security intelligence. The techniques we cover may also be applied to any of your organization’s business processes—it is just a matter of expanding your skillset and applying the proper techniques to the right data set.

The owners of a small, start-up company found it strange when several of their programmers quit the company at the same time. When company executives “got wind” that the individuals had gone to work for a competitor, they began to ask questions about whether or not the company’s intellectual property had been stolen, since these programmers were working on key pieces of their product. Since this was a small company, the management did not have a security officer, so they looked to the IT personnel to examine the problem and to look for evidence. The first area the IT personnel examined was the e-mail of the employees. Through the e-mail, they were able to piece together that the employees who left the company were collaborating and they intended to steal the code they developed at this company. These e-mails were key evidence that the company saved to an external storage device for preservation. The company made a secondary copy so that they could review the data.

Once the e-mails are preserved, rather than manually reading through the e-mails, you could use the text mining technique covered in this book to see if you can identify patterns that are not readily apparent, such as other associates involved in the source-code theft and when they initiated the plan to steal the code. You may also find other clues, which may cause you to expand your investigation. For example, the former employees in our scenario continued to correspond with current employees at the company even after they left the company. The company was able to identify the personal e-mail accounts of the former employees because they forwarded e-mail to themselves prior to quitting. From the e-mail accounts, the company was able to determine that they were still e-mailing current employees. One of the current employees, who had not left the company yet, was involved in the source-code theft and was still feeding the former employees with details about how the company knew of the theft and still providing insider information.

To expand upon this scenario, for the sake of showing you further applications, let us say you were able to determine that one of the former employee physically downloaded the source code onto a removable USB device on a particular date. What types of security data would law enforcement need from your organization? First, the system used to download the data would have important evidence of the USB device connections, to include artifacts in the registry keys (link files, USB removable devices connected to the system, timeline information, etc.). Second, showing that the employee was physically present in the building would be beneficial to building your case. Other areas to examine would include employee access logs (building entry, parking entry, computer logins, etc.). If you are lucky enough to have physical access log data to your building, you could run security analytics on employee patterns to identify anomalies—which may or may not serve as an indicator of when the criminal activity began. While video surveillance data will provide you with additional evidence to support your case, current techniques in video analytics have not yet fully developed—robust tools that can handle large amounts of data from multiple video feeds and conduct facial recognition at a granular level are still being developed.

A final consideration in our insider threat scenario that we will discuss, which is often overlooked because companies do not expect it to occur, is an unauthorized access after the employee has resigned. Sometimes a company’s IT department may not remove accesses to systems immediately, thereby offering a way for the employee to return to the company. Or, in the case where a former employee, who managed the IT network or was technically sophisticated, may leave a backdoor from which the employee may access the company’s system. Why is it important to examine these areas? Besides the obvious point that it poses a threat to the organization, if you can show that the employee accessed the company’s system while no longer employed, you are able to show another form of criminal activity—unauthorized access. An Internet search for “mitigating insider threats” will provide you with additional resources and ideas to better protect your organization.

Finally, you must also consider the situation in which an employee’s credentials were stolen. Should you call the person and start asking questions or should you just report it to your management? This highlights the importance of having an incident response plan—it assists you in knowing what steps to take and when to involve your management. Depending on your organization’s policy and management decisions, the next steps could include any of following: consult with legal counsel or human resources personnel, interview the employee, or notify your board of directors. Inaction is also action—your company may choose to do nothing, which tends to be common in smaller organizations. After determining if there was any wrongdoing by the employee, your management could also opt to pursue criminal enforcement and/or civil litigation.

Security analytics can also support your justification for resources. By using the techniques covered in this book, you can support your claim for resources to support your security initiatives. For example, if you want to justify the need to purchase a new intrusion detection system, you can easily do so by first showing the statistics on the growth of the threats within your organization’s network. This coupled with the identification of what the current system is not identifying (intelligence gaps) and a simulation of the effects from not identifying the threats translates your security concern into a business problem. Your management may be more inclined to pay for a system to support security, even when there are competing business interests, because you are able to show a compelling need. Most importantly, you are able to translate how this compelling need affects your organization’s profits and/or productivity. You could also use this technique to justify hiring more security personnel and to change internal business practices and/or policies.

The ability to collect large volumes of data containing sensitive personal, financial, or medical information places a greater social responsibility upon those using analytics. No matter where the data reside (in the cloud or within an organization), a security practitioner should be acutely aware of the risks associated with data reuse, sharing, and ownership. Therefore, you need to know the types of data you are handling, so you may take the appropriate steps to safeguard the data through information management and organizational policies. Additionally, if you are working with other individuals handling the data, they should be trained on how to safeguard the data and the ethics of properly using the data.

One way to protect the data is to use data anonymizing tools prior to or after conducting analytics processes. You can do this by using the techniques provided in Chapter 5, through the use of a script, to convert the data of concern into anonymized data. In addition, once your organization determines the need to involve law enforcement or to pursue civil litigation, you may be given the responsibility to produce the evidence supporting the incident. Prior to disclosing the information, you should review the data for any sensitive information, such as personally identifiable information, financial data (i.e., credit cards and bank accounts), Health Insurance Portability and Accountability Act and Gramm–Leach–Bliley Act protected data, and intellectual property. Your legal counsel will be able to provide you with more details on other data needing special protection.

You may also run into a situation where after adjusting your strategy, you still do not find any security incidents. It is at this time that you will need to view your results using a “different lens” to search for meaning in what you have already found. In going back to the DNS lookup scenario, perhaps even after you have shifted your strategy, you still cannot seem to find malicious DNS lookups. Let us look at what you have—a list of your organization’s DNS lookups, which is baseline over a certain period of time. As we have stressed before, this information is very important in security—you must know your organization’s baseline before you can detect anomalies. In addition, you have also identified the DNS lookups, so you could run these domain names against a domain watch list to check that there are no suspicious lookups. We want to stress that what may initially seem like a dead end, may actually be an opportunity—security intelligence of your organization or your threat landscape. Once you have figured out the security intelligence of importance to your organization, you can automate these tasks to assist you in protecting your organization. This is the beauty of security analytics.