Year: 2016

If you’re looking for a new car, you may be considering a hybrid – one that combines electric power for efficiency and mileage with traditional internal combustion to recharge the engine and extend the travel range. For many buyers, it is the best of both worlds, providing greater flexibility to extend your trip as needed. The same concept applies to a hybrid data center – one that combines your own, dedicated on-premises resources with the scalability and agility of on-demand compute, networking and storage resources such as those from Amazon Web Services (AWS).

As the insatiable appetite for compute and storage resources to support the business continues unabated, customers are using the public cloud as a way to augment their data centers more quickly and more efficiently than in the past. Initially, a hybrid approach was viewed as a step toward migrating all applications and data to the public cloud. In reality, many customers are settling on a hybrid approach as their new data center architecture.

In a recent conversation I had with a customer, two new physical data centers had just come online, and they were already over-subscribed. They were looking to AWS as a way to extend the life of their data center using a hybrid approach. When you think about it, a hybrid approach makes the most sense. First off, it allows you to start small and establish some guidelines around which applications and data should reside in the cloud. There will be legacy applications that cannot or should not be migrated. There will be data that, after careful internal analysis, does not belong in the public cloud. For new applications, you might look at adopting a simple cloud-first mentality that says: for new applications, look to the cloud as the deployment location. A more advanced cloud-first approach entails changing your application development methodology to one that is componentized, makes heavy use of APIs, can be updated rapidly, and can be deployed globally – in the cloud first.

From a security architecture perspective, a hybrid data center is an extension of your data center and therefore should be treated no differently than your physical data. This means that you should:

• Know exactly which applications are running in the cloud and whitelist them to ensure they are the only ones allowed in the cloud
• Segment the applications to control which can talk to which and limit lateral movement
• Enable applications based on the user credentials and the business need
• Apply threat prevention to block threats from accessing your cloud applications and data while also blocking them from moving laterally

When deployed in AWS, the Palo Alto Networks VM-Series can securely enable your hybrid data center, acting as an IPSec VPN termination point and as a virtualized next-generation firewall, protecting your AWS deployment with application control and advanced threat prevention. More advanced use cases include segmentation for added security and compliance purposes through VPC to VPC and subnet to subnet policies. In effect, you can mimic your physical data center security in AWS.

To learn more about how a hybrid data center with AWS might benefit your organization, check out these resources:

• SANS Webinar with Dave Shackleford: Know Before You Go: Key AWS Security Considerations
• VM-Series with AWS Hybrid Data Center Deployment Guidelines (includes sample deployment script)
• CSA White Paper: Public vs. Private Cloud Security Considerations

The cynical would suggest that cyber insurance is growing as some look for a cheaper route to manage risk. However many see the cyber insurance industry as potentially the new enforcer of good security practices.

Over the last decade, we have seen regulation being applied, be it by nations or industry groups, and most have faced the same challenge; that is, regulation moves at a snail’s pace compared to the rocket ship that is the evolution in IT and cybersecurity. There is a clash between dynamic, evolving cybersecurity in which the bar of what is state-of-the-art continuously evolves, be it from new IT technology use cases, changing threats, or new practices to mitigate these risks.

The impending EU regulations, the Network Information Security Directive and the Data Protection Regulation Reform, both leverage the term and concept of state-of-the-art, suggesting that, in the latter, business should have regard for this cybersecurity capability relevant to the risk and, in the former, businesses should have at least state-of-the-art security technology.

Could the cyber insurance industry, in effect, become the dynamic new regulator of this in the future as cyber insurance adoption grows? Businesses will be eager to prove they are applying such state-of-the-art practices to reduce their premiums, and insurers will be looking to validate if a business can be insured and just what level of premium they should be offered based on the business’ capabilities.

As the cyber insurance market grows, it will surely become more competitive, and so, such analysis would seem key to being able to offer better premiums where the risk posture allows. An example of this is IASME (a UK consortium for small- to mid-sized businesses) tying cyber liability insurance coverage for small businesses to the UK Cyber Essentials program certification that aims to assure a basic level of cybersecurity. They are 1 of 4 accreditation bodies for Cyber Essentials certification in the UK.

The question all this raises is whether those in the insurance industry will have to become cybersecurity experts, and the likely reality is not, as there is already a skills’ shortage in the cyber market. What seems more likely is partnerships will be formed with the security industry so they can gather better intelligence on both the current threat landscape and capabilities, looking to validate their real-world effectiveness and identify best practices.

Much as home insurance is linked to where you live, cyber insurance will be linked to the industry you are in, and where you do business, to better identify the likelihood and scope of claims. Today some cybersecurity vendors, including Palo Alto Networks, already track such data and, with the Cyber Threat Alliance, can track and advise on advance threats.

As cyber insurance evolves, it will require a tripartite relationship amongst knowledge of the risk, relevant state-of-the-art capabilities to prevent the impact, and the skills to validate the ongoing application. It will be interesting to see if, in the longer term, insurers will build out their own list of approved requirements and capabilities. However, unlike most insurance services, which have been built from decades of knowledge to generate the actuarial data that balances premiums against claims, cyber insurance is still relatively nascent. I would challenge there are probably very few insurance markets that are as dynamic as cybersecurity. Only time will tell if the potential benefits for all, with insurers growing involvement in the cybersecurity space, come to fruition.

Greg Day

[Palo Alto Networks Blog]

Current research in cybersecurity often has a narrow focus, detailing recently successful attacks and how those attacks were accomplished. Attackers are often represented as shadowy, nameless figures, with a special kind of mystique surrounding them. That Hollywood image couldn’t be further from the truth. In a new study released today, “Flipping the Economics of Attacks,” Palo Alto Networks has partnered with the Ponemon Institute to understand not only what motivates these attackers but also how we can turn the tables on them by taking away their financial incentives to attack.

The data also shows us a clear path to shift the economic motivation of attacks with two compelling facts:

• Increasing the time it takes to breach an organization by less than 2 days (40 hours) will deter 60 percent of attacks.
• Organizations rated as having “excellent security,” as compared to “typical,” took double the time to breach (140 hours).

To understand how to influence an attacker’s economic motivation, we must consider what I call the “adversary arithmetic,” which boils down to the cost of an attack versus the potential outcome of a successful data breach. If malicious actors are putting in more resources than they are getting out, or we decrease their profit, being an attacker becomes much less attractive. Using the survey findings as a guideline, let’s walk through what we can do to reverse this trend.

An Attacker’s ROI

Here is the situation today: we found that 53 percent surveyed believe that the cost of executing successful attacks has gone down, with more available malware and exploits, better attacker skills, and more effective toolkits as the primary drivers. This is important because as Moore’s Law shows us, increasing computing power over time, and in this case the automation and sophistication of hacking tools, makes launching a successful attack cheaper.

The survey also found that 69 percent of adversaries were motivated solely by profit, meaning that changing the arithmetic to increase the cost of attacks could prevent the majority of them from ever being launched. It is important to note that there is a spectrum of malicious actors, and organizations must always maintain awareness of potentially dangerous, highly targeted attacks, or nation-state led activity such as cyber espionage or cyber warfare. However, if we can de-incentivize anywhere near that number of attackers, we will see seismic change in the threat landscape.

There’s a common notion that attackers are motivated by big potential paydays. We found this to be the exception, rather than the rule, with average annual earnings from malicious activity totaling less than $30,000. This limited earning power becomes even less attractive when you consider the added legal risks, including fines and jail time.

The next step in our equation is how attack targets are selected. We found that the majority of attackers (72 percent) were opportunistic, not wasting time on efforts that do not quickly yield high-value information. While advanced nation-state actors employ lots of planning, think about the average attacker as the mugger on the street, versus the Ocean’s Eleven crew that spends weeks planning a complicated high stakes heist. When put into this context, organizations that prioritize making themselves a harder target will actively prevent a significant number of potential breaches.

Taken together, we have a simple picture of an average adversary: motivated by profit and going after easy targets in an environment where attacks are becoming cheaper. There is reason for hope though, as this same attacker is making a relatively small income, especially compared to cybersecurity professionals, with the added element of risk they face.

Time is the defining factor to change the adversary’s arithmetic. As network defenders, the more we delay adversaries, the more resources they will waste, and the higher their cost will be. We can interrupt the march toward more and more lower-cost attacks by taking a slightly different perspective on the problem. We need a prevention-based focus on the right investments in the right people, process and technology to defend the organization. Working together as a community to shift the economics of this problem, we can hit the core motivation for attackers and shift their behavior over time, bringing us to a world where cyberattacks are the exception, not the norm.

Read the full report for additional findings, including key recommendations for preventing attacks.

One investigative technique for threat analysis involves pulling information from disparate data sources to start piecing together breadcrumbs of data. This technique forms a more holistic picture of a threat. One of the most basic forms of telemetry used to research a threat is the classic IP address/domain record pair, to which the Maltego platform provides an excellent interface to graph these pairs so that interesting links or clusters standout for further analysis. This has historically been a very manual process and often leads to a dead end, as a lot of threat actors commonly take over legitimate systems to carry out campaigns.

Given this, and with a yearning to have more control over the graphing process, we created a new script to facilitate automating the initial building of Maltego graphs using passive DNS (pDNS) data from PassiveTotal. Specifically, SpiderMal is a Python script that can be run from the CLI or, alternatively, pointed to by a Maltego Local Transform. At its core, it uses the PassiveTotal API to connect domain nodes to IP address nodes, and vice versa with their pDNS data. It then recursively crawls from the seeded entity out to a specified level, building out the diagram. This can easily be accomplished through the existing PassiveTotal Maltego transforms by chaining together lookups; however, SpiderMal also includes the ability to filter results based on a temporal range so that only domains or IPs seen within a specified date range are included in the graph. This reduces the noise and allows an analyst to fine tune their results before diving in further.

To illustrate the temporal filtering and recursive search feature we start with a domain and query the PassiveTotal API to pull back all of the resource data for that record. This data is then subsequently passed back to PassiveTotal and their individual resource data is pulled back, so on and so forth until the specified recursive level is reached. This spidering allows one to quickly map out a potential infrastructure or quickly determine that the infrastructure is not actually relevant for a particular threat.

Figure 1: Unfiltered, 3-level, recursive search

Immediately, a few areas jump out as potential points to investigate but there’s a lot of data that may not necessarily be relevant to a threat. To fine-tune this, the same query was run with a filter that limited results to active records in the year 2015.

Figure 2: Temporal filtered, 3-level, recursive search

The ability to jumpstart these graphs, with more control over what goes in them, will hopefully give researchers and analyst more time for the investigative aspect of threat analysis.

Download the SpiderMal.py version 1.0.0, and the Maltego Local Transforms/Machines.

Some additional examples of using the script are included below.

Figure 3: Running the script from the CLI

Figure 4: The graph of the above search

Figure 5: A query seeded with an IP address of a fake Tech Support phishing site

Figure 6: Running the SpiderMal recursive 3 level Machine against an IP within Maltego

Jeff White

[Palo Alto Networks Blog]