Traps v3.4: Good News for Breach Prevention in Government Environments

It’s time to be reminded once again how critical the security of our endpoints is to our overall network’s security and risk posture. We all read the bad news headlines about how fast the “bad guys” are advancing. But it’s also a good time to note: so are the “good guys.”

If you look at some of the biggest government attacks over the last two years, two consistent themes arise. There were vulnerabilities in the operating system or an app on the endpoint that was used to gain entry – and that app, of course, hadn’t been patched. And once the attacker got onto the network, using that endpoint as a beachhead, they had unfettered access to move across it – ultimately, in many cases, getting to exactly what they wanted. You know the drill because you’ve heard it repeated more times than you’d prefer. But we don’t have to stop there.There really is good news – and we’re adding to that good news with some recent updates to Traps advanced endpoint protection, a cornerstone of our next-generation security platform.

Take one of our government customers as an example. Their employees are highly mobile. They’re highly targeted. They know there are great risks on their endpoints. They understand what’s at stake. But, luckily, they don’t put their heads in the sand and wait to be told antivirus is dead – and that’s despite government guidance which often still calls for this dying solution to the problem. They’re proactively addressing the multiple risks – both exploits and zero-day malware – with our Traps advanced endpoint protection. I’ll explain a bit more about how it works below. Especially in highly targeted government environments, you need this multi-method breach prevention. What we mean by “multi-method” is that you have to address bothunknown malware and exploits that take advantage of those vulnerable operating systems and applications I mentioned previously, using multiple methods for each.

What can you do about exploits without disrupting the user or using a lot of your resources to address them? Many people still believe that addressing exploits is really difficult, disruptive to the end user, and not worth the effort. (In case you’re unfamiliar with exploits, more than 30 percent of recent CryptoWall ransomware attacks were delivered using exploit kits that leveraged unpatched vulnerabilities. You can check out our Cyber Threat Alliance CrytoWall Report, 2016 to learn more about this example of how exploits are being used today).

Actually, the good news is that we can detect an exploit as soon as it attempts to execute, and we do so seamlessly. Traps does not perform any system scanning, so the footprint is extremely small, and the CPU utilization and disk I/O are minimal. While actively preventing security breaches, Traps remains essentially transparent to users. And as far as the exploits, there are actually core exploit techniques that are used by all exploit-based attacks. So, yes, there are many thousands of exploits, but the truth is that they all rely on a small set of core exploit techniques, and those techniques don’t change often. We can actually break that chain and block the techniques the second they’re attempted. Here’s a bit more insight into this good news that Traps uses multiple methods for exploit prevention:

  • Memory Corruption/Manipulation Prevention: These exploit techniques manipulate the operating system’s normal memory management mechanisms for the application opening the weaponized data file that contains the exploit. This method recognizes and stops these exploit techniques before they have a chance to subvert the application.
  • Logic Flaw Prevention: These exploit techniques allow the exploit to manipulate the operating system’s normal processes that are used to support and execute the target application opening the weaponized data file. For example, the exploit may alter the location where dynamic link libraries (DLLs) are loaded from into an application’s execution environment so that the exploit’s malicious DLLs can replace legitimate ones. This method recognizes these exploit techniques and stops them before they succeed.
  • Malicious Code Execution Prevention: This prevention method recognizes the exploit techniques that allow the attacker’s malicious code to execute and blocks them before they succeed.

What can you do to address unknown malware or zero-days on the endpoint?Traditionally, you’d try to get antivirus to address the issue. But that ship has sailed – AV simply can’t deal with the volume and sophistication of the zero-day (aka “unknown”) threats today. And the first thing attackers do today is make sure their attack shuts off antivirus. In fact, theNTT 2015 Global Threat intelligence report estimates that approximately 54 percent of new cyberattacks go undetected by traditional endpoint protection, but it is likely even higher. Thegood news is that we have multiple methods we use to thwart unknown malware on the endpoint, including several new features we’ve just announced:

  • Static Analysis via Machine Learning: provides an instantaneous verdict on any executable file before it is allowed to run. By examining hundreds of the file’s characteristics in a fraction of a second, this method determines if it is likely to be malicious or benign without relying on signatures, scanning or behavioral analysis. The threat intelligence available through WildFire is used to train a machine learning model to autonomously recognize malware, especially variants that have never been seen before, with unmatched effectiveness and accuracy.
  • Quarantine of malicious executables: Traps version 3.4 now immediately removes malicious files to prevent further propagation or execution attempts of infected files.
  • WildFire Inspection and Analysis: This method works because of the ability to automatically reprogram the endpoint protection based on real-time insights from WildFire about the unknown files it’s assessing. An attacker can use each piece of malware once, at most, anywhere in the world, and only has seconds to carry out an attack before WildFire renders it entirely ineffective.
  • Trusted Publisher Execution Restrictions: Now we can use another verification method on files digitally signed by trusted publishers that Palo Alto Networks recognizes as reputable software publishers.
  • Policy-Based Execution Restrictions: You can define policies to restrict specific execution scenarios that further reduce your attack surface. For example, Traps can prevent the execution of files from the Outlook temp directory or the execution of a particular file type directly from a USB drive.
  • Admin Override Policies: You can define other policies, based on the hash of an executable file, for additional control over what is allowed to run in any environment.

You can read more about any of these capabilities in more detail.

Other things you want to consider:

  • Patching – I know that patching your most critical assets goes without saying, and some government agencies are doing a great job with this. For those that can’t be patched, leverage compensating controls like the ones we’ve talked about above. With Windows XP, Windows Server 2003, and versions of Internet Explorer (IE) older than version 11 having reached end-of-life (i.e., support), agencies still running these legacy systems and software are going to be vulnerable. Security patches are no longer available so the risks to them are going to be tough to tackle. And as I’ve mentioned, think about both your IT and OT networks here.
  • Get visibility today of every user, device and application running on your network —You can’t protect what you don’t know or understand. As an example, read more about how governments are employing user identification to understand their users and contextually whitelist not only certain applications by user or user group but also specify which capabilitieswithin the app (think of chat or file sharing within WebEx or file downloads from Dropbox) they will allow.
  • Regardless of which cyber model you use – the Gartner attack lifecycle or the Lockheed Martin Cyber Kill Chain – ensure you’ve done a meaningful gap analysis and understand precisely where you’re vulnerable at each stage of that lifecycle. By the way, this is critical on your SCADA systems today, too. These systems notoriously run end-of-life operating systems, and there’s no simple way to patch them. (If you’re interested in how Palo Alto Networks does that, you can read more about our Prevention Gap Analysis tool.)
  • Virtually segment your network – This means creating zones to limit users per zone, strictly control flows between security zones, and limit types of flows that can move between those segments. This goes back to the cyberattack lifecycle – all you need to do is block them at one place in the chain, and you’ve made their campaign unsuccessful. Think of whitelisting – where specific applications are allowed and other traffic is blocked, contextual to your user base – that’s what we mean here by segmentation.
  • Don’t let your teams or your security enforcement points and products operate in silos. Do your endpoint and network security capabilities complement and inform one another? If not, what will it take for this to happen? Endpoint-to-network security correlation is available and improves the time to prevent an attack. When the network sees a new piece of malware, it grabs all of the indicators and can share relevant information to thwart the attack on the endpoint.

As our “endpoints” change, and we find ourselves at the dawn of the era of the internet of things (IoT), we need to be careful to keep apace with devices that are added to our networks – both IT and OT. Consider your endpoint as a critical point in the cyberattack life cycle. For those of you in the U.S., you can start with the Cyber Security Strategy and Implementation Plan (CSIP)– what are your most critical assets and what are the many ways, through the cyberattack lifecycle, the adversary can get to that critical data? And then ask yourself in the context of your overall security posture, what gaps do you have amid that attack lifecycle? It’s important to consider our endpoint practices, as I’ve described, before our networks become even more complicated with more devices. Build your endpoint security programs to plan for swiftly changing endpoints. That’s our “new normal.” It’s hard to believe that one day we’ll think of our communications with (and vulnerable access from) our security systems and thermostats just like we do our laptops today. Yes, that’s progress – let’s not be afraid to embrace it.

For more information in modernizing your endpoint security strategies:

[Palo Alto Networks Research Center]

Building a Security Culture has Its Benefits

Since I created the Security Culture Framework in 2012 and open sourced it in 2013, the interest in security culture has exploded worldwide. When I first started in the industry, security culture professionals were but a small group of specialists in the US and Europe, discussing how we, based on our experience, built functional security cultures in organizations around the world.

Today, only a few years later, the interest in security culture is truly global, with a large number of organizations applying the principles of the framework to build and improve their security culture.

In my opinion it is important to accept the fact that all organizations have a security culture—whether they acknowledge it or not. This means that a poor security culture may have a negative impact on your organization, opening the organization up to external and internal risk and data breaches. A security culture can (and should) be improved, thus making the improvement a potential benefit.

Security culture is defined as the ideas, customs and social behavior of a group (organization) that keeps it secure. To be secure is one clear benefit of a security culture. What being secure really boils down to are the risk assessment, risk acceptance and risk mitigation strategies of the organization. No two organizations are the same in this respect. A risk-focused approach to security culture is a very good idea, as it allows you to direct your efforts to where they will make most sense for the organization.

An organization with a high risk appetite may choose to focus less on security culture than an organization with a low appetite. As long as they understand the short- and long-term outcomes of such a strategy, I have no problem with such a choice being made. The challenge arises when an organization finds itself in the blind—believing they are doing the right things, while waking up brutally one morning with all their data records being leaked to the press, and then, upon closer inspection, discovering that their awareness training programs worked very well to check a box once a year, but did very little, if anything, to build and improve their security culture.

Making informed choices is part of a security culture. Understanding the threat landscape, the risk strategy, and then transforming this into a security culture program is the way to build and improve security culture.

I plan to write future blogs that will discuss the principles of the security culture framework and my experiences building security cultures around the world. I will also take questions and provide answers to your security culture questions.

What is your experience building and improving a security culture? Do you see any settings where an organization could accept a lesser security culture? If so, why?

Editor’s note:  Roer’s latest book, Build a Security Culture, is available for purchase at ISACA’s Bookstore.

Kai Roer, Security Culture Coach/Author, The Roer Group

[ISACA Now Blog]

Are the Security Issues Facing the Industrial IoT Over-Hyped?

At BlackHat last week, the good folks at CyberTECH invited me to participate in a panel discussion on securing the industrial internet of things, or IIoT. By now, we’ve all heard about the security concerns the manufacturing space has regarding the IIoT: millions of connected devices connecting to a corporate network every day to upload customer data could give cyber adversaries the entry point they need to compromise a network and wreak havoc.

As the panel conversation moved into the audience Q&A, it became apparent to me that most of the security experts in attendance viewed securing the IIoT as the responsibility of the OEMs building IIoT-enabled industrial equipment. This argument was usually followed by a complaint that those same OEMs don’t know anything about cybersecurity, so securing the IoT won’t be possible in the foreseeable future.

This discussion was very spirited. It was also, in my humble opinion, riddled with FUD and assumptions about securing the IIoT that are either inaccurate or simply not true. Securing the IIoT is possible, and it won’t require new gains in security technology to do so. Next-generation security solutions like the Palo Alto Next-Generation Security Platform are perfectly capable of securing the IIoT. The real challenge is getting the security industry to understand that.

Now, the IIoT will enable many devices that have been previously “dumb” to become “smart”; in other words, become equipped with sensors that gather data and connect to the internet so that data can be shared to enable new business models and opportunities. But I think it’s unreasonable to expect the engineers who design those devices to suddenly become experts in cybersecurity. It would be like me expecting my threat research team to become experts in industrial control solutions if they intend to provide threat intelligence to industrial customers.

At the end of the day, data on the IIoT is no different from data on the regular internet; it uses IP packets just like any other internet traffic. And malware delivered via the IIoT doesn’t present any new or unique threat that would require defenses beyond those used to stop malware delivered via more common means, like a spear phishing attack. If your security architecture uses a zero trust model and policy controls that enable the proper use of applications and data, it will still be able to identify malware as it moves through the various steps in the attack lifecycle and stop it.

To sum up, just because an attack on your network is coming from an IIoT-enabled HVAC system, and not a compromised laptop, that doesn’t mean your security architecture can’t stop it, provided it’s a next-generation security architecture designed to combat the methodologies used by today’s more advanced cyberattackers. So the next time the topic of IIoT cybersecurity comes up, everyone just take a deep breath and relax. With the right next-generation security platform in place, embracing the IIoT becomes a much less scary proposition.

[Palo Alto Networks Research Center]

English
Exit mobile version