This chapter covers the fusing of internal and external intelligence to present a singular view of the threats an organization may face. Whether that singular view is presented through training or via threat intelligence specific protocols into a Threat Intelligence Management Platform or a Big Data solution, the goal is to make the view of internal and external data indistinguishable.
Keywords
Security awareness training
CyBOX
OpenIOC
STIX
TAXII
YARA
threat intelligence management platforms
Big Data Security Analytics
Hadoop
Information in this chapter
• Security awareness training
• OpenIOC, CyBOX, STIX, and TAXII
• Threat intelligence management platforms
• Big data security analytics
Introduction
To this point the discussion has revolved around correlating and fusing intelligence into security systems inside the organization. But to take security to the next level and move toward Intelligence-Guided Computer and Network Defense (IGCND), the integration of intelligence into security systems has to be seamless.
The flow of both internal and external information into the collection and processing. While a good security analyst will weigh the value of collected data differently depending on the source, access to the actual data should ultimately be the same across all sources in use by the organization.
This is really the final step in becoming an intelligence-led organization. When data sources are fused together in such a way that indicators from multiple sources can easily be tied to adversary groups, and the analysts building FINTEL have access to contextual information about the quality of the incoming data so as to make better decisions as to how to use the data, then an intelligence organization is full intelligence-led.
In Chapters 5 and 6, the focus was on the Security Information and Event Management (SIEM) and Governance, Risk Management, and Compliance (GRC) as the integration points. There are a lot of advantages to the SIEM environment, but a SIEM treats all data sources equally. The SIEM relies on self-reporting from the source or correlation rules to determine the severity of an incident. Although the GRC environment is more flexible, it was not designed from the ground-up to operate within an intelligence cycle environment.
The focus of this chapter is fusing internal and external data in such a way that the data presents a single, focused picture of the threat to the organization.
Security awareness training
Awareness training may seem like a complete non sequitur based on the previous discussion, but it really isn’t. Too many organizations do not engage in security awareness training for their users and customers. Those organizations that do often limit themselves to a high-level overview of the security reports such as the Verizon Data Breach Report (www.verizonenterprise.com) or the Symantec Internet Security Threat Report (www.symantec.com) Although these reports contain valuable information for the enterprise and are useful overall, they generally do not make for a good basis for security awareness training.
Good security awareness training should be relevant to the organization. It is one thing for users to know that clicking on links is bad; it is quite another thing to note that people within the organization have fallen victim to these specific attack campaigns. By highlighting not only the larger threat, but also the specific threat to the organization, users are more involved in the security process and are going to be more aware to potential threats.
As with monitoring, security awareness training needs to be a continuous process. Not only should users understand the latest threats, they should understand the impact their actions can have on the organization.
Security professionals sometimes forget that most users within the organization are not thinking about security all of the time. Continuous security awareness training helps to keep security always in the mind of the users. Network users can serve as an additional source of information included in an intelligence-led security program – in effect they can become assets.
In conjunction with the creation of the security awareness training, a method for users to report suspicious activity should also be created. Generally speaking, that method should not be an email address, it should be a web form or some other method that can be integrated into the established intelligence cycle. User reporting should be integrated into the intelligence cycle and be correlated against all of the other information being collected by the security team, making user reports another data stream that goes into the production of FINTEL.
Remember that the primary method of access into an organization is through the users. Finding new ways to get a user to click on a link or open a loaded document is an important part of the attack methodology for many adversaries. If network users are thinking about that when they receive an email from someone they don’t know, or attending an event on behalf of the organization, they are much less likely to blindly click on links. They will also be more aware if they do click and something happens.
Users will also be more likely to inform the security team if something suspicious happens if they know the potential risk to the organization. As has been mentioned previously, even the best-defended networks are going to be breached, so having the users of the network act as extensions of the security team means that those breaches can be caught earlier.
All that being said, security training should not be scary. Yes, the weight of a security breach should be stressed, users need to know that security should be taken seriously, but fear has never been the most effective communication tool.
For instance, many organizations use cyber security posters like those found at Schweitzer Engineering Laboratories (www.selinc.com), an example of which is shown in Figure 7.1. These posters serve as a constant reminder of the importance of cyber security to the organization, using humor to attract the attention of users and, hopefully, to keep the thought in the back of the minds of the users.
Working with cyber threat intelligence partners to craft organization-specific training can be invaluable to users on the network. Some threat-intelligence providers, such as iSIGHT Partners (www.isightpartners.com) even provide materials such as their monthly “Potential Targeted Malware Infection Lures,” shown in Figure 7.2. These tools take current known threats facing a variety of sectors and allow the security team to customize them based on what is being seen within the organization. This allows the training to be customized to the organization, but based on cyber threat intelligence regarding threats currently impacting other organizations.
Security awareness training does not have to be classroom based; it can be done via videoconference or even a monthly newsletter, although a videoconference is much more likely to be attended and paid attention to than an email that may sit unread until long after it is too late.
As with any of the other aspects of intelligence-led security discussed in this book, security awareness training is most effective when it is fully supported to by leadership within the organization. If users perceive leadership is fully committed, they are more likely to take it seriously. Therefore, security awareness training should be included as part of any security plan, it should be seen as an integral part of the security program, which it is.
One thing to consider when developing a security awareness training program is the inclusion of trusted security vendors in that program. Oftentimes, having another party come in to discuss trends in cyber threats and how those trends impact the organization adds impact to the conversation. That being said, outside vendors will never replace the security team as the experts on security within the organization. But a speaker from a security vendor can offer a different perspective. Many security vendors are happy to offer this service at no cost to their customers.
Customer security awareness training
Depending on the nature of the organization, it may make sense to provide security awareness to training to customers as well as employees. Many organizations do this today and it not only improves the entire security ecosystem it can also generate valuable intelligence.
Consumer-facing organizations have known this for a while. Financial institutions regularly send email to their customers letting them know about the latest phishing scams, retail companies send out emails reminding customers that they will never the customer to send a password via email, and email providers send out warnings about potential threats to their customers’ accounts and data.
In addition to warning customers, the organization should ask their customers to forward them suspicious email. Whereas employee reporting should done through systems that can integrate directly into security collecting platform, simply asking customers to forward suspicious emails should be enough. On the backend, there should be a way to integrate those emails into the security analytics platform in a programmatic way. But, all of that should be invisible to the customer.
Repeating the “if you see something, say something” mantra to your customers will, as with the employees of the organization, keep security always in the back of their mind. Having customers forward samples of suspicious or phishing emails that appear to be related to the organization greatly improves the attack surface that the security team is able to monitor. It also lets customers know that the organization takes security very seriously and it provides additional campaign information that can be compiled and shared internally as well as delivered back to the customers.
OpenIOC, CyBOX, STIX, and TAXII
In the realm of vulnerability intelligence most organizations rely heavily on the Security Content Automation Protocol (SCAP) to share vulnerability information between platforms. SCAP is an efficient way of sharing vulnerability information, but it does not really work for sharing cyber threat data. Organizations that rely on multiple sources of intelligence and want to join those sources into a single platform need a common language and structure.
The good news is that there are number of emerging standards that allow organizations to normalize threat intelligence data across all platforms within the organization. Threat intelligence languages and frameworks are also being used by intelligence providers to programmatically deliver security data directly into client systems. Two examples of this type integration discussed in Chapter 6 are YARA (see p. 0000) and CRITs (see p. 0000).
OpenIOC
One of the first tools is OpenIOC (www.openioc.org), which is a framework originally developed my Mandiant (www.mandiant.com), but released as an open platform that everyone can use. OpenIOC is a framework for cataloging indicators of compromise associated with malware. The OPenIOC framework uses an XML-based schema, similar to this snippet1:
OpenIOC allows an organization to track indicators of compromise (IOC) across multiple platforms and tie behaviors associated with those IOCs together with the IOC. This enables security analysts to tie operational and tactical data together in a single framework.
CyBOX
Cyber Observable eXpression (cybox.mitre.org) is a framework developed by Mitre (www.mitre.org) to manage communication and reporting of cyber observables, another way of saying indicators. Out of the box, CyBOX takes a much broader view of what constitutes an indicator than OpenIOC (though OpenIOC is designed to be extensible). CyBOX looks for what it terms measurable or stateful events. A measurable event is a new registry key added, the hash of a file changing, or a file being deleted. Stateful events are those that are constant, such as a file hash, the registry entry itself or a domain name.
CyBOX creates different objects for each type of observable, allowing for variance depending on the nature of the indicator. While this makes it a more complex framework than OpenIOC it does allow for context around the observable to be shared.2
STIX and TAXII
Structured Threat Information eXpression (STIX) and Trusted Automated eXchange of Indicator Information (TAXII) are, respectively, a language for conveying cyber threat intelligence information and transport mechanism over which to share cyber threat information. While STIX (stix.mitre.org) and TAXII (taxii.mitre.org) are usually mentioned in the same breath, they are actually two very different things.
STIX is a language for communicating the operational, tactical, and strategic information about a threat in a standardized way that can be ingested using a variety of security tools. In other words, it provides actor, tactics, and infrastructure information to in a single package that can be shared across an organization or with other organizations.
The language can be structured in a number of ways, as long as it includes the proper elements, a snipped of a typical STIX report looks like this3:
By default, STIX uses the CyBOX schema to describe observables within the language. In fact the CyBOX schema is imported natively.
That being said, STIX is extensible, and for organizations that prefer to use OpenIOC, STIX does provide a default extension for OpenIOC. STIX also provides an extension for YARA rules.
TAXII, on the other hand, is a transport mechanism. It provides protocols for sharing cyber threat intelligence, but it can be used for other types of data sharing as well. TAXII has four core services: Discovery, Feed Management, Poll, and Inbox. The Discovery service is about determining the method of communication between other TAXII hosts. The Feed Management service is about managing data subscriptions. Poll and Inbox are about the pushing and pulling of data to the source, respectively.
TAXII is not a transfer protocol; instead it binds itself to HTTP and HTTPS, allowing those protocols to conduct the transfer. Version 1.0 of TAXII also limits its message bindings to XML.
In essence, TAXII is a mechanism for delivering intelligence messaging, using XML, over an HTTP/HTTPS connection. That being said, TAXII is not limited to any of those aspects of communication, it is simply its primary purpose at this time.
Threat intelligence management platforms
Having emerging standards and getting threat intelligence partners to support those standards, the next step is finding a central repository where that data can be stored as it proceeds through the intelligence cycle.
In this case, a SIEM is not usually enough. Many cyber threat intelligence providers have done an admirable job of trying to shoehorn threat intelligence into SIEM platforms, but it is not usually a good fit for reasons discussed earlier.
In essence, intelligence-led security organizations often outgrow their SIEMs, which creates a problem because so much invaluable data is contained within those SIEMs and most organizations build their security programs around their SIEMs.
That is where a relatively new category of security systems comes into play. Gartner refers to these platforms as threat intelligence management platforms (TIMPs). TIMPs are built from the ground up to support the correlation of threat intelligence, which includes being able to ingest data in STIX, OpenIOC, and other threat intelligence languages and frameworks.
Adopting a TIMP within the network does not mean abandoning a SIEM in which an organization has invested heavily. In fact, TIMPs are not designed to replace a SIEM; instead, they are built to work with the data contained within the SIEM. A security analyst can build a finished report merging indicators from multiple sources and deliver that information directly into the SIEM, as in Figure 7.3.
Figure 7.3Viewing multiple campaigns in the ThreatQuotient (ThreatQ) console.
This customized view of a suspected campaign gives the security analyst even more control over the types of indicators delivered into the SIEM for correlation. It also means that, using internally collected data, the security analyst can flesh out the reports from multiple threat-intelligence providers and build a FINTEL product that is unique to that organization.
There are a number of young companies that are jumping into this new category. Just some of the vendors are ThreatQuotient (www.threatquotient.com), ThreatStream (www.threatstream.com), Centripetal Networks (www.centripetalnetworks.com), ThreatConnect (www.threatconnect.com),4 and VorStack (www.vorstack.com). There are also established security vendors who are moving into this space, like BAE Systems (www.bae.com) with the Detica CyberReveal®. There is also a project under the FS-ISAC called Soltra (www.soltra.com), that is a combination of TIMP and information sharing platform.
TIMPs solve a number of problems that have plagued early adopters of cyber threat intelligence and organizations moving toward IGCND. The most important one is the SIEM problem outlined above, but SIEMs are not the only recipients of cyber threat intelligence within the network.
Previous chapters have discussed intelligence integration into network monitoring platforms, web proxies, firewalls, Domain Name System (DNS) servers, incident response tools, intrusion detection systems, and more. There are a few different ways this can be done, but the most common way it is done today is to integrate each intelligence data feed into multiple platforms. The same intelligence data, from multiple providers, is ingested across multiple platforms within the organization.
This model creates a lot of duplication within the organization and it takes control of intelligence distribution within the organization away from the security team leaves it in the hands of the cyber threat intelligence providers. By using a TIMP to centralize the collection of external cyber threat intelligence data the security team regains control. A security analyst can sort through the relevant indicators from a variety of sources and use that information to build a YARA signature. She can then push that YARA signature to the platforms to which it applies.
Some intelligence data needs to be delivered to some platforms, but not others. Using the TIMP as the central repository, the security team now has the ability to build alerts using standardized language and can control where it is delivered. Again, this gives the security team the ability to inject itself into the kill chain as early possible, so it is not using intelligence within the SIEM to tag events postcompromise.
Using a TIMP platform can increase the efficiency of the security organization in an intelligence-led security program. Today, security analysts spend a great deal of time manually coordinating threats from multiple intelligence vendors. There is a lot of cutting and pasting and note taking that interferes with the work of actually securing the organization. This work is a necessary, but tedious, aspect of an intelligence-led security organization.
By normalizing the cyber threat intelligence from multiple vendors a TIMP speeds up the processes of correlating information and reduces the amount of cutting and pasting and note taking that needs to be done manually. Within the TIMP the security team has the ability to coordinate data from multiple sources, add notes directly into the platform and quickly produce the desired output. Again, they can even stream that information, notes and all, into the targeted platform. The notes are particularly useful, so when the intelligence does result in an alert the on-duty analyst will have immediate context as well as a reference point as to where to go look for more information.
TIMPs as a Rosetta Stone
Sun Tzu said, “Thus, what enables the wise sovereign and the good general to strike and conquer, and achieve things beyond the reach of ordinary men, is foreknowledge.” In this passage, Sun Tzu is talking specifically about spies, but the broader point is getting to know the enemy and understand how the enemy operates.
This need to understand the actors behind the threat is what is very quickly driving intelligence-led security to be adversary focused. Focusing on the adversary allows organizations to tie all of the different indicators together to produce focused operational intelligence, but it also allows security teams to connect that operational intelligence to the tactical intelligence by tying those indicators to tools and infrastructure used in attacks. Finally, both the indicators and the tools can be tied to a group. That group may not be known at first, but by continuing to track the activity more and more information about that group becomes apparent and attribution can be guessed.
This is what cyber threat intelligence providers do, some with greater success than others. They combine open source intelligence (OSINT), signals intelligence (SIGINT), and, in some cases, human-sourced intelligence (HUMINT) to paint pictures of these different groups and their associated tactics and indicators. Once all of this information has been collected it is published to their clients in report format as either a PDF, an email delivery, or delivered through the Application Programming Interface (API).
That is when the problem starts for the clients. An organization may have three or four different threat-intelligence providers sharing the same information under different adversary names. Figure 7.3 demonstrates this problem well. A security analyst has uncovered the domain weather-online.hopto.org within the organization. The analyst thinks it is suspicious so the analyst enters it into the analyst’s ThreatQuotient management platforms and the analyst’s suspicions are confirmed. The analyst sees that the domain has been confirmed as malicious, but one organization refers to the actor as SNAKE, while the second refers to it as ENERGETIC BEAR.
This may be the most powerful use case for a TIMP within the organization. Not only can the TIMP tie together indicators from across multiple threat intelligence solutions, it can also be used to tie campaign information from across multiple cyber threat intelligence providers. Remember that no one threat-intelligence provider is able to monitor everything that is happening on, and off, the Internet. Quite often, one intelligence provider will see one aspect of an attack, while another will see a different aspect. Combining the two sources of information can provide an organization with a more complete view of the attack.
Unfortunately, intelligence providers make combining datasets challenging by assigning different names to the adversaries they are tracking. Considering that the adversaries are assigned different names and providers have different views of the activity of those adversaries, it is challenging for their customers to determine which group from one provider matches a group from another provider. Again, it requires a lot of manual effort on the part of the client to match indicators, tactics, and any other aspects known about the groups.
That is where the Rosetta Stone–like capabilities of TIMPs have the potential to excel. The TIMP is already synthesizing data from multiple sources and normalizing it for distribution throughout the network. The TIMP can also be used to isolate groupings of indicators and match them from one provider to another (shown in Figure 7.3) thus presenting a cross section of indicators from different providers all tied to the same actor in an automated fashion.
A caveat to this is that the process will never be perfect. One cyber threat intelligence provider may assign an indicator to one group while another provider assigns it to a completely different group. Not just different group names, but groups with completely different attributes. For example, one provider may tie an indicator to an actor operating out of Estonia, while another may tie that same indicator to a group operating out of India. Of course, that doesn’t mean that one or both threat-intelligence providers are wrong. With the explosion of malicious activity around the world and a limited number of vulnerable hosts (it is still a very large number), it is not uncommon for the same host to be compromised by two different actors and used for redirection by both of those malicious actors.
If the first provider noted traffic originating from the compromised host that mirrored activity seen from the Estonian group while the second provider could be seeing activity from the same host that matches tactics, techniques, and procedures (TTPs) from the group in India. Even though it is rare that there will be a one-to-one match of indicator sets associated with actors from one cyber threat intelligence provider to another, the TIMP can still simplify the process of connecting groups across providers.
This actually ties to one of the biggest complaints that cyber threat intelligence consumers have: why can’t cyber threat intelligence providers create a Rosetta Stone on their own? This is similar to the problem that antivirus vendors face 20+ years ago. Symantec would label a virus as one thing, while McAfee would refer to it by a different name, Kaspersky would have yet a third name and so on. Security teams that were struggling to keep up with latest virus outbreaks were very frustrated (sound familiar?) trying to track threats across the organization and around the world. Antivirus vendors got together and agreed to sharing naming information, making it easier to find the name of a piece of malicious code across all providers. That has worked very well for these providers for several decades now.
Unfortunately, it is not as easy to do this with cyber threat intelligence. There is a lot of intellectual property involved in building an intelligence collection infrastructure and creating reporting that is delivered to clients. Sharing malicious actor information involves more than just sharing a file hash. In order to truly share information cyber threat intelligence providers would have to disclose all of the attributes discussed throughout this book. At this point there isn’t an effective way to manage sharing and protect the intellectual property of the cyber threat intelligence providers.
Big data security analytics
The term big data is everywhere. It seems every security company today is talking about a big data solution or something they are doing to further enhance big data solutions. Through all of the marketing hype, there are excellent reasons for some organizations to look at a big data solution for their environment.
Big data security analytics is really an answer to the question asked in Chapter 5: how much data should an organization collect for security analysis? In the big data security analytics model, the answer to that question is: everything.
In the traditional GRC and SIEM collection model, log data has to be massaged for it to be delivered into the platform – the platform needs to know what it is ingesting to be able to act upon it. These solutions are also often limited in terms of the amount of data they can successfully ingest and process in a timely fashion. Any security analyst that has ever worked with a SIEM that is nearing database capacity knows this feeling: Enter in a search query, head out for a nice long lunch, come back, stop to chat with coworkers, get back to the desk and see the search results are still not presented. In an intelligence-led security organization those types of waits are unacceptable.
To start with, the underlying databases used in these solutions have already been implemented across a wide range of high-volume, high-transaction sectors, such as finance and retail. Because of this background, they are well suited for high volumes of data collection from a range of sources, which means that they can handle large amounts of data, process that data quickly, and return search results in a timely fashion.
Big data solutions are also used to dealing with nebulous data types. Most SIEMs will choke on data that does not conform to a specific type or exists outside of a specific framework. While having a structured framework across all platforms makes for easier correlation, it also runs the risk that not all data will be included.
When a security vendor restricts their data to a limited framework that sometimes means having to drop fields in order to support that framework. So, while the vendor may log a great deal of contextual information a lot of it might be lost when it is converted to syslog or CEF formats. The plus side is that the conversion makes it easier to correlate logs and other data across multiple platforms if they are all in the same format.
With big data security analytics, that is no longer a concern. The big data solution ingests the data natively and builds objects around the data, it also allows for unstructured data to be ingested into the solution. This means instead of a dataset limited by the capabilities of the SIEM or GRC, pointers to all of the data resides within the database. Now security analysts can write queries based on what they want to know.
But wait – being a security analyst does make someone a database expert. A security analyst may have gone her entire career without writing anything more than a few MySQL queries; all of a sudden the analyst is expected to write a bunch of queries to this database?
Absolutely not, that is really where the security analytics part of the big data security analytics solutions comes in to play. Vendors that are offering big data security analytics solutions put a front-end to the database that manages many of the typical relational queries that can provide security value. On top of that, most of the vendors offer outsourced expertise with these queries and can help create custom rule sets based on the specific security systems within the network as well as the security goals of the organization. Of course, this expertise usually comes with a cost.
The real value in a big data security analytics system that is properly deployed and contains the right datasets is the ability to detect anomalous events. Ultimately, that is the goal when trying to detect events outside of those that match signatures or indicators: highlight activities in the organization that simply don’t “feel right.”
Some types of anomalous traffic detection were discussed in Chapter 6 (see p. 0000), but a big data security analytics solution can take the discovery of these anomalous events to the next level. Yes, these solutions do require a great deal more caring and feeding than a traditional SIEM or GRC solution, but the possibilities for incident detection are vastly improved.
Hadoop
Hadoop (hadoop.apache.org) is an open source scalable solution for distributed computing that allows organizations to spread computing power across a large number of systems. The goal with Hadoop is to be able to process large amounts of data simultaneously and return results quickly. Hadoop is a very powerful tool, with a wide range of resources, including security analytics.
The Hadoop framework solves some of the problems with SIEM and GRC platforms mentioned earlier. Because of its distributed nature, Hadoop is able to process a lot of log and unstructured data in a very timely fashion and return those results. That being said, Hadoop is not a database, instead it is a storage and processing system. What that means is that can take data transactions in whatever form and allow the organization to process those transactions across commodity hardware.
Several security vendors, such as RSA (www.rsa.com) and Splunk (www.splunk.com) have already seen the value that Hadoop can bring to security and provide front security front ends to the Hadoop framework.
Conclusion
Correlating data collected internally with a variety of external sources of information and fusing that into a single stream of FINTEL presents a significant challenge to any organization. However, mastering gaining control over these varied datasets significantly improves security across the organization, by increasing situational awareness and response to security events.
One way to improve that fusion is by using emerging cyber threat standards such as OpenIOC, CyBOX, STIX, and TAXII to ensure that all sources of security sharing are communicating using the same framework.
Another option is to use a TIMP as a clearinghouse for all threat intelligence data. The TIMP platform can then translate the different forms of data inputs into a single fused output that can be programmatically delivered to the appropriate security systems.
An alternative, and at times significantly more complex, solution is to migrate to a big data security analytics platform. Big data security analytics platforms are great for collecting any and all data in its raw format in order to provide full context of a security event. Correlation is done based on an understanding of the data structures, rather than forcing the data to comply to the platform structure. These platforms provide a security-focused front end that manages much of the querying and analysis through an easy to use front end. Thus ensuring that security analysts don’t need to be database experts as well.
Whatever methods an organization uses to tie all data sources together into a singular format that can be distributed throughout the network, there will absolutely be improvements in the security posture of the organization.
