Today there is much debate on the role of intelligence in cyber strategies. Like so much in the world of cyber, as the requirements have changed, so have the capabilities being offered. With this in mind, what are the characteristics of modern cyber intelligence?
When the Heartbleed vulnerability was announced last year, like most, I started to search for more information. Within the first 24 hours, there were already hundreds of thousands of articles online, many providing technical insight on the exploit. There was no shortage of information about the vulnerability and how it worked, and I even found a video tutorial on how to leverage the exploit.
At a recent leadership event, I observed a very heated debate on intelligence. In many cases, the points made reinforced that intelligence is primarily a lot of noise with limited value.
There is indeed an abundance of technical information on how threats and vulnerabilities work, as well as known bad domains/IPs, and so on. It seems the challenge is that, with so much raw data, how do we ingest it to gain value?
E.O. Wilson, a social biologist suggested, “We are drowning in information, while starving for wisdom[1]”, so what is the difference? The FBI defines intelligence as “information that has been analysed and refined so that it is useful to policy makers in making decisions[2]”.
Depending which security vendor you follow, it is suggested that there were hundreds of millions of new malware iterations created in 2014. Looking at the CVE list[3], the count got to 9751 documented vulnerabilities and exposures identified over 2014. Taking that last number alone, that would be nearly 27 per day, which is too much data to be useful to make security decisions on a daily basis.
When thinking about these numbers, three points stand out as opportunities for intelligence to add value:
Ensuring protection against as many of these threats as rapidly as possible.
Being able to identify which are the high risk attacks that are likely to impact your business. From the total volume of attacks, we need to identify the few that we may choose to be incrementally proactive against. These would typically be those attacks that are targeting your industry or geography. By their nature these are the more targeted attacks that have specific, focused goals that can have greater business impact.
Reverse analysis: recent public breaches seen in the media highlighted the challenge when indicators of compromise (IOCs) have been found but not acted upon. Being able to look up suspicious IOCs to understand if they correspond with existing campaigns or techniques is a growing requirement for security operations teams. ISACs and industry collaboration groups are springing up around the world to do this at a peer-to-peer level, but are limited by the groups’ membership.
From discussions that I’ve had, there are specific elements required to move information into business-valuable intelligence and to enable decisions to be made and actions to be taken. All of these are interdependent, and if any single one is missing, the value quickly collapses. These are the following:
Timely – Seemingly obvious, yet the reality is that, as attacks have become more bespoke and their lifespan has shortened, the time to receive actionable, contextual intelligence is critical.
Actionable – Intelligence is only useful if it includes information on what the recipient should do next (i.e. mitigate the attack). Too much threat information today simply describes the problem, requiring human intervention that makes the intelligence no longer timely.
Machine readable – Where attacks are constrained by only CPU power and network speed, providing intelligence that requires human inspection is inserting an analogue process into a digital problem. If we cannot directly apply actions at a technology level, without requiring human involvement to proxy the information, we add unsustainable lag into the process. This is critical both in terms of the time to apply preventative controls and in relation to the ability to deal with the capacity of today’s cyberattack scope.
Low false positives – If we are to apply intelligence without human input, we must have high levels of confidence in the information received.
Contextual – From a risk management perspective, this mean being able to identify relevant, current, high-risk threats that require context. Likewise doing the reverse lookup on indicators requires context to be able to qualify what the attack is and does.
Summary
Today’s cyber challenge is a numbers game. With the volume of what is happening globally and the volume of security events discovered internally, we are creating a big data challenge that will only expand as we add more IPs and more security capabilities, and the volume of attacks continues to grow. SIEM tools typically help consolidate internal events, but that is only part of the challenge. We also need to add context and consolidate external information.
What is key is that we typically have finite cybersecurity staff and live with the analogue limitation in the digital world. The more we can filter and automate activity (machine to machine), the closer we get to working at the same digital speed as the attack. There is always going to be a requirement for some level of human intervention, but today those humans are typically tied up with tasks that should be automated, so they are completed in a timely manner. Having the right intelligence is an enabler to increase automation and free up cybersecurity staff to focus on the activities they should be focused on.
Exploits have been the major enabler of advanced persistent threats for over a decade now, but it is only in the recent years that the term has become widely used and acknowledged as a main attack vector.
However, this acknowledgement too often assumes people understand what exploits actuallyare. This is mainly due to the highly technical nature of exploits. One should be familiar with how applications are processed and executed in order to understand the means in which this flow can be maliciously manipulated.
As an active and increasing risk, knowledge on exploits various patterns and implementations is critical for sound security decision making – even non-technical people can’t be out of the loop.
This is the first in a series of posts to address security-oriented, but non-technical readers. It is meant to walk you through the building blocks of exploitation, including basic motivations, various techniques, the evolution of protection mechanisms and counterattack measures. Hopefully this series will elucidate many of the terms that you often hear and enable you to know the answers to questions such as:
What is the difference between vulnerability and an exploit?
What does it mean when a software vendor rates vulnerability as critical?
Why can’t exploits be detected by signature-based solutions?
What is the difference between stack overflow and use-after- free vulnerabilities?
What is the difference between memory corruption and Java vulnerabilities?
Let’s begin. We will be focusing first on memory corruption exploits due to their critical role in the threat landscape.
The Remote Attacker’s Problem
Threat actors can have many motivations, but whatever the motivation is, in order to fulfill it an attacker must execute code on a victim’s machine. This code could be anything from silent data exfiltration to wiping out hard disks or sabotaging a SCADA system. However, the attacker’s code should be executed to fulfill the attack’s objective.
The obvious problem is that under normal circumstances the attacker does not have access to its target machine. So, for example, a cutting edge data exfiltration malware is useless until the attacker achieves the ability to remotely run that malware on the target’s machine.
Exploitation is a solution to the remote attacker’s problem. The exploit gives the attacker user privileges on the compromised machine. It is the means by which attacker obtains a firm, minimal foothold in a victim’s machine, and that foothold enables the main components of an attack – backdoor, C2C communication, key loggers, etc. – to be downloaded and executed.
To achieve that, attackers target the applications by which users normally interact with external content. The most commonly used applications are browsers, readers, players and Microsoft Office documents. Attackers will attempt to embed their code in the file the targeted application will open. Let us understand how this is achieved.
The Essential blocks – Vulnerabilities and Shellcode
Applications Input
Applications accept input and process it. In theory this input could be either well-formed and executed or malformed and rejected.
In practice, however, there is also a third possibility in which the file is indeed malformed, but is still accepted by the application. The application will start executing the file but somewhere along the line the execution flow will deviate from its predesignated path and the application will crash.
Memory Address Space
To understand why this happen we should recall what happens when a program is executed. We will refer to an executed program as process and use this term from now on. The operating system allocates the process a memory address space which contains the process code and data. The process memory space is the playground in which the process is executed and will be present with us through the entire series. (We will later dive deeper into how this space is structured.)
In the meantime, our interest in the process address space lies in the fact that an executed process can be viewed as a mere sequence of memory addresses. These addresses are fetched to the Central Processing Unit (CPU) one at a time according to a predesignated sequence. The CPU executes the instructions in the fetched address and proceeds to the consecutive one and so on and so forth until the final instruction, which is exiting the process.
This is what happens when the file is well-formed. However, in the scenario we described above, at a certain point in the sequence the execution flow deviates. The CPU is fetched with an address which does not contain any instructions which will stop the execution. This is, roughly, what happens when a process crashes.
Until this point we have not described anything malicious. The fact that applications accept malformed input files rather than reject them all together is a built in feature of code writing. The application writer by definition is unable to predict all the possible file alterations.
The Attacker’s Perspective
From the attacker’s perspective this is an attractive scenario. If a certain malformed input causes the execution flow to deviate to an empty address, an input could also be crafted to overwrite this empty with the attacker’s instructions. In that case the execution flow will no longer crash but will instead be redirected.
At this point we understand how an attacker can gain control on process execution flow. We have not yet understood what there is to be gained. The memory space the attacker is in is still the memory space the process received from the operating system and in this space the only valid code is the application code.
But what if this memory space contained also a dormant malicious code? In this case the attacker could leverage its control and redirect the execution flow to execute this code. The CPU will keep on executing since it will be fed with valid instructions. If this small piece of code could, upon execution, open a connection between the attacker’s machine and the victim’s machine the attacker will be able to remotely use the machine with legitimate user privileges.
So, in order to take control of a victim machine attacker must craft an application input (usually a data file) in the following manner:
Embed a piece of code in the file which will open a connection between the attacker and the target machine when executed.
Craft the file to be malformed so the execution flow will deviate from its path (as we have explained above).
Calculate the predicted location of the address the process deviates to and feed the address with the location of the attacker’s code.
After completing these preperatory stages the attacker needs to makes sure that the target user will indeed open this crafted file. This would typically be done through social engineering by sending email attachment (the crafted files in that case will be Office documents, Readers, etc.) or compromising a commonly visited web page.
When the user browses the webpage or opens the attachment, the chain we have described will be triggered: the application will start executing. At a certain point – without the user ever noticing – the execution flows will deviate, the deviated address will be overwritten, the execution flow will redirected toward the attacker’s embedded code, the code will be executed and a connection will be established between the attacker’s machine and the target user. From this point onwards the endpoint – the user’s machine — is compromised and the attacker is free to download any malware it desires to the targeted endpoint according to its specific needs and objects.
Common Terminology
We can now define the following terms:
Vulnerability – is the bug in the application which causes execution flow to deviate from its designated path when trying to process a malformed data file. Various vulnerabilities correspond to different malformation variants. A vulnerability enables an attacker to intercept a process execution flow. The vulnerability by itself is merely the potential for compromise.
Shellcode – is the small sized code the attacker embeds in the malformed input file. The shellcode establishes connection between the attacker and the targeted machine. This connection is utilized further on to perform reconnaissance and download additional malware.
Exploit – is the code which redirects the execution flow from the overwritten address to the dormant shellcode. Successful exploitation is accomplished when the shellcode is executed and a connection between the attacker and the target machine is established.
The actual exploitation flow can be thus broken to the following parts:
In upcoming posts we will present different kinds of vulnerabilities and the main implementations of these three parts.
If you are like many of our customers, your Palo Alto Networks firewall and Panorama configurations contain thousands of policies and objects. In previous releases you might have even lamented the difficulty of finding specific items that you want to modify.
Well the search is over! Or is it just beginning?
Introducing Global Find!
With the new Global Find feature introduced in PAN-OS 7.0 and Panorama 7.0, you can quickly locate items in your configuration by searching a key word or phrase. The search results show EVERY location in your configuration where a given object exists and the search results are categorized to help you locate the item you need.
If you are not sure what to search for, you can easily bring up Global Find while navigating your configuration. For example, let’s say you have an address object that contains the network range for your Sales department and you want to see all policies that use that address object. Simply navigate to Objects > Addresses and click the drop-down menu to the right of the object name and then select Global Find. In seconds, you see search results that contain clickable links to all referenced policies.
See Global Find in action:
Even if you know exactly where to find a configuration object, you can use the Global Find feature to quickly locate the object. The clickable search results enable you to jump directly to the area you want to modify, saving you time!
Technology is great. People are better. “People of Palo Alto Networks” celebrates the employees who preserve our unique culture of innovation and collaboration.
Episode 2
Watch us break ground on our new campus.
Big changes are in the future for us – want to be a part of it?
Get in on the ground floor and learn more about securing your career with Palo Alto Networks:
The Palo Alto Networks vision for threat information sharing is that cybersecurity vendors should share the intelligence that they all individually collect with each other and with whomever else has the capacity to consume it. In that way, each vendor can build more innovative products with that superset of intelligence and better protect their combined customer bases because of it.
Project Redstone, the results of which we announced today, was a 90-day proof-of-concept designed to test the value and practicality of security vendors collaborating against one cyber adversary campaign in the summer of 2015: the campaign associated with CryptoWall version 3. The project showed immediate tactical success and demonstrated the value of such a collaborative information sharing arrangement. That said, the project also identified four capability gaps that Palo Alto Networks must solve in order to share intelligence on 5,000 adversary campaigns, every day in real time:
How to convert large volumes of Indicators of Compromise into prevention controls;
How to measure alliance member contributions with more granularity;
What is the common set of success metrics for deployed security controls across Alliance membership; and
What is the right sharing architecture that works at scale.
Introduction
Palo Alto Networks has a bold vision about threat Information Sharing. We believe that cyber threat intelligence collected by security vendors should be shared by all. We believe that the intelligence all security vendors collect through their vastly deployed product sets should not be marketed individually to promote product differentiation or rolled out as an additional revenue stream. Instead, we believe that all security vendors should have access to the same threat intelligence so that individually each vendor can build better and more innovative products to protect its customers. Those innovations are how the security vendors will distinguish their products in the market place. More importantly, the result of that cooperation among security vendors will exponentially provide better threat prevention capabilities to the shared global customer base. Palo Alto Networks helped found the Cyber Threat Alliance with that vision in mind.
Officially formed on September 4, 2014, with nothing more formal than a common Non-Disclosure Agreement (NDA), the Cyber Threat Alliance members began working through the issues of how a group of competitive security vendors could share threat intelligence with each other. Two issues became paramount: building trust between all members and establishing an infrastructure that could facilitate the sharing of large volumes of threat intelligence.
While the Cyber Threat Alliance began working those two issues, other security vendors who agreed with the vision came on board: Barracuda, ReversingLabs, Telefonica, and zScaler. At the White House Summit on Cybersecurity and Consumer Protection held at Stanford University in February 2015, President Obama signed an executive order directing the creation of new Information Sharing and Analysis Organizations (ISAOs) and praised the Cyber Threat Allianceas a model for the way forward.
Three organizational principles distinguish the Cyber Threat Alliance from other existing information sharing groups.
The first is that every participating member must contribute. No members can simply consume the shared intelligence. They must share in equal quantities and the Cyber Threat Alliance measures the volume and quality of intelligence contributions daily to ensure compliance.
The second is that whatever is shared by individual members is deployed across all other members’ product lines. For example, when Palo Alto Networks shares malware samples with the Cyber Threat Alliance, all other Cyber Threat Alliance members use that intelligence to strengthen their individual product sets and vice versa.
The third is that Alliance members will update their security controls to their deployed products within their respective customer bases without the customer having to review and install themselves. In the traditional ISAC (Information Sharing and Analysis Center) modelfor example, customers must decide that they want to share intelligence. They have to package it up and send it off to their respective ISAC Security Operations Centers. Once the new intelligence arrives, the ISAC Security Operations Center must process the information, transform it into useful intelligence and distribute it to the other ISAC members. Once the ISAC members receive the new intelligence, they have to read it, understand it, decide if it is pertinent to their organization and if it is, develop security controls for their organization and deploy them in a timely manner. The process provides good intelligence, but it is also slow and cumbersome. The Cyber Threat Alliance system eliminates the customer as a middleman. Alliance members automatically deploy the right security controls to their deployed systems making the process more efficient for their respective customer bases.
In June 2015, the Alliance founding CEOs met to discuss the next steps for the Cyber Threat Alliance. Now that trust had been established and a rudimentary infrastructure had been built, where should they take the organization?
The original charter stated that all members would share 1,000 unique malware samples with each other daily as the price of admission to the Cyber Threat Alliance. But security experts estimate that adversaries create approximately 1 million unique pieces of malware a day. The CEOs understood that 1,000 shared samples a day between Alliance members is not that significant. On one hand, having competitors share and collaborate on threat intelligence is a good thing for the security industry. On the other, if we are going to go through all this effort, shouldn’t it be for some meaningful goal?
The Big Hairy Audacious Goal (BHAG) that emerged was what if the Cyber Threat Alliance members decided to share adversary campaign information with each other? Instead of simply sharing newly discovered malware, what if the Cyber Threat Alliance dedicated itself to sharing the entire playbooks, the Indicators of Compromise throughout the cyber attack lifecycle, for every cyber adversary operation that is known? The implications of that idea could be a game changer.
Experts from the Cyber Threat Alliance estimate that the number of adversary campaigns that exist in the world at any given time could be as many as 5,000. This is not the number of attacks. This is the number of existing playbooks that adversaries use to conduct those attacks on multiple victims. Other experts not in the Cyber Threat Alliance say the number is higher — roughly 25,000 — and others say it is much smaller, roughly 500. Regardless of the actual number, what is interesting is that the number is not 1 million or even 100,000. The number of existing adversary playbooks is in the thousands. Analysts can track a thousand items in a spreadsheet. This is a manageable number, and that means something that can be done if the Cyber Threat Alliance focuses the right resources on the problem.
If the Cyber Threat Alliance was able to share Indicators of Compromise (IOCs) down the cyber attack lifecycle for every adversary campaign that is known, members of the Cyber Threat Alliance could automatically deploy threat prevention controls to their products and to their customer base potentially in real time. If the Cyber Threat Alliance membership grew large enough, the membership roles would reach a tipping point where every organization – commercial, government and anything else – that connects to the Internet would have at least one Cyber Threat Alliance member’s product deployed within their networks helping to defend it against attacks. At that point, every organization on the planet connected to the Internet will have the latest and greatest attack prevention controls within minutes of discovery.
That is a bold and disruptive idea and it could revolutionize the business.
The founding CEOs decided to run a proof a concept. Instead of tackling 5,000 adversary campaigns at once, they tasked the group to focus on one campaign: collaborate on one playbook to see if the intelligence collected and shared amongst members is better than what the individual Alliance members collect on their own. And they gave the team 90 days to do it. The name of the project was called Redstone and the CEOs met on October 1, 2015, to discuss the results.
Project Redstone: “Lucrative Ransomware Attacks: Analysis of the Cryptowall Version 3 Threat
The Cyber Threat Alliance intelligence analysts focused on the adversary campaign associated with the malware called CryptoWall version 3. CryptoWall version 3 is a nefarious piece of ransomware that encrypts the data on victim’s laptops and consequently demands payment in return for the key that can unlock the data. It is one of the most lucrative and broad reaching ransomware campaigns affecting the customers of the Cyber Threat Alliance members today. Project Redstone was the Cyber Threat Alliance’s attempt to work collaboratively to disrupt this ransomware campaign.
The Cyber Threat Alliance founding members handpicked their best intelligence analysts for Project Redstone. The analysts worked independently during the week but collaborated daily through a chat program called Slack. They conducted weekly progress meetings with the Cyber Threat Alliance working committee to receive guidance and resource support. They deployed a CryptoWall version 3 tracker for public consumption and posted it on the Palo Alto Networks website. This will track new instances of CryptoWall version 3 emerging in the future. During the 90 days, they drafted a white paper describing the results of their research. In the end, they discovered that each founding member knew something about the CryptoWall version 3 campaign that the others did not. In total, after they finished their research, the combined analyst team identified the following:
$325 million in estimated revenue generated by the adversary campaign
406,887 attempted infections across the Cyber Threat Alliance customer base
839 Command & Control URLs used by the campaign
5 Second Tier IP Addresses used for Command & Control by the campaign
49 Campaign Code Identifiers attributed to the campaign
Palo Alto Networks Information Sharing Capability Gaps
In addition to participation in the Cyber Threat Alliance, Palo Alto Networks also shares threat intelligence with other non-vendor organizations and individuals who have the capacity to consume it and whom are willing to share with us. With all of these relationships, the types of sharing generally fall into two buckets.
The first bucket contains large collections of Indicators of Compromise that have no context about specific adversaries at all. They are simply collections of random bad guy activity that somebody, somewhere declared was malicious. This is not helpful. Single Indicators of Compromise by themselves, even if you have a large set of them, are prone to false positives. In order to give them validity, you have to attribute them to the playbook of an adversary. In that way, your Security Operations Center is not looking for a single Indicator of Compromise. Your Security Operations Center is looking for a percentage of Indicators of Compromise about one adversary. If you only see 1/100 in your network, your confidence that a specific adversary is in your network is not high. But if you see 60/100 in your network, your confidence is very high that a specific adversary has compromised your network.
The second bucket usually contains Indicators of Compromise about one adversary. While this is useful as far as it goes, it is not enough. We want to track 5,000 campaigns, every day, in real time.
If the industry is going to make this information sharing concept useful, we need a different bucket. We need a bucket that contains the changes noticed by the information sharers about 5,000 adversary playbooks every day. That is a big ask and we can’t do it today unless we solve some technical issues. From a Palo Alto Networks perspective, there are four research gaps that we must close in order to make this thing work at scale:
Convert Large Volumes of Indicators of Compromise into Prevention Controls: The first capability gap that Palo Alto Networks must solve is how to ingest large volumes of newly discovered Indicators of Compromise from outside sources and convert them into brand new prevention controls for our product line. About half way through Project Redstone, Palo Alto Networks realized that the combined Cyber Threat Alliance intelligence team was discovering reams of new Indicators of Compromise, but we did not have the ability to quickly turn them into prevention controls for our customer base. This was a semi-manual process for us and this does not scale.
Measure Sharing Contributions with More Granularity: The second capability gap we have to solve is how to measure the value of information shared. Our initial thought was that counting Indicators of Compromise down the cyber attack lifecycle, or Kill Chain, from each sharing partner might be sufficient. But Project Redstone showed us that not all Indicators of Compromise are created equal. On the one hand, a sharing partner might provide 100 Indicators of Compromise that are so common that intelligence analysts from Unit 42, the Palo Alto Networks threat intelligence team, will not be able to distinguish them among multiple adversary campaigns.
In other words, they do not help us identify the specific adversary campaign we are trying to track. On the other hand, another sharing partner might provide one Indicator of Compromise that is the linchpin to attributing the entire campaign. Clearly, counting Indicator of Compromise volume between sharing partners is not the right metric. Further, using the Kill Chain to categorize Indicators of Compromise might not be sufficient either. Distinguishing Indicators of Compromise in the Recon, Delivery and Installation stages of the lifecycle is very difficult. A new approach might be called for or if not, we have to get a lot smarter about how to do it with the cyber attack lifecycle model.
Develop Common Success Metrics for Deployed Security Controls: The third capability gap that the security community must develop is a way of collecting success metrics for deployed security controls. When the Alliance analysts finished their research and each individual member company finished deploying their prevention controls to their respective product lines, all Alliance members struggled with capturing meaningful metrics that demonstrated that the deployed prevention controls stopped actual adversary activity. First, since all Alliance members have their own language around how to describe this activity, there was no common language to normalize the information. Second, all security vendors struggled with their respective customer bases about what intelligence is acceptable to share from the customer enterprise to the security vendor intelligence cloud. There are many reasons for this, privacy concerns are the chief among them, but security vendors and their respective customer bases must come to terms with the idea that sharing bad guy information is not sharing company secrets. If the security community wants to establish meaningful metrics around the security controls we all deploy, we have to come to terms with this notion.
Identify the Sharing Architecture that works at Scale: Finally, the fourth, and probably most important capability gap, is the sharing infrastructure. In parallel to Project Redstone, the Alliance technical team started to build out the first working STIX/TAXII instance for the Cyber Threat Alliance members. They did not finish their work until after the research for Project Redstone was complete. Project Redstone analysts relied on their chat program and a shared Box folder to exchange information. This is highly inefficient, does not scale and demonstrates the need for an installed information sharing infrastructure. Further, Cyber Threat Alliance analysts are beginning to suspect that STIX/TAXII may not be the sharing standard that we need for this kind of research. For what we are trying to do, the STIX/TAXII framework has some limitations namely in the area of scaling. At Palo Alto Networks, we either need to determine how to use STIX/TAXII more efficiently or adopt a new framework altogether.
Palo Alto Networks Future State for Information Sharing
In order for Palo Alto Networks to pursue the vision articulated by the Cyber Threat Alliance Founding CEOs — that members of the Alliance will innovate their product lines based on a common shared intelligence and exponentially protect their respective customer bases at the same time – a focus on scaling the Palo Alto Networks operation is required.
In order to track the changes in approximately 5,000 adversary campaigns daily, share that intelligence with all of our sharing partners, and convert that intelligence into real prevention controls for the Palo Alto Networks customer base in a timely and efficient manner, the capability gaps identified above must be closed. For the next six months, the Unit 42 technical team will focus their efforts on these issues.
Conclusion
The vision of the Cyber Threat Alliance is a classic BHAG (Big Hairy Audacious Goal). Project Redstone was the Alliance’s proof of concept that the vision is possible. While the result showed some immediate tactical success, Palo Alto Networks realizes that there are four capability gaps that must be solved in order for the effort to scale. These are all hard but solvable problems. I am hopeful. In the mean time, when non-Alliance vendors come to your door to pitch their wares, ask them why they are not member of the Cyber Threat Alliance. We currently have eight members. We want 50 and we need their help.
