Application Control – Maintenance Headache or Manageable Solution?
October 10, 2019
David Murray | Product Manager for Endpoint Security | Ivanti
Industry analysts are increasingly turning to application control as a key component in protecting endpoints against targeted attacks and advanced, persistent threats. Many companies have tried and failed to implement effective whitelisting. Discovery can be an exhaustive process. Once implemented, there is a constant need to maintain and update the whitelist. Some solutions also take a heavy toll on the system when it comes to performance. In this session, you'll learn how to implement Application Control in a real-world environment without all the drama.
David Murray: Okay, let's go ahead and get started. Welcome to this webinar, where we will discuss application control. And we're going to assess whether it is a maintenance headache or a manageable solution. Hopefully, I'll convince you it's the latter. Otherwise, I don't think this'll be a good use of the next hour for either of us. This is actually the third in a series of four webinars that we're conducting for October Cybersecurity Month. We've already had webinars on building a solid security foundation, and we've had one on privilege management. Next week we're going to finish out the series with a focus on patch management. But today is all about application control. And for anybody that was on last week, I'm going to follow a similar format to last week, where I'm going to go through a bunch of slides, but I've also got some demo that I'll do along the way.
David Murray: Okay so, let's start with defining what it is we're talking about. What is application control, or sometimes you hear the term application whitelisting? People often use these terms interchangeably. In their research note how to plan, implement, and operate a successful application whitelisting deployment, Gartner say the following about application whitelisting. So, what they say is, "Application whitelisting is a powerful tool for protecting endpoints in both end user and data center environments. Taking a default deny approach to endpoint security can provide strong protection on endpoints. However, whitelisting has a well-deserved reputation for being difficult to manage from an IT administrator perspective and is potentially impactful to the normal operation of end users."
David Murray: So, that kind of sets out the challenge in the context of today's presentation on maintenance headache or manageable solution. I've often compared antivirus with application whitelisting by using the bouncer at the nightclub door analogy. Antivirus is like that bouncer who watches everybody going in and is trying to spot bad behavior. They're going to catch some, but others probably had a few too many drinks. They manage to slip by, and inevitably they cause some problem inside the club. That's kind of your antivirus approach, trying to catch bad behavior. Application whitelisting is more like the doorman on the door of an exclusive club that's got a guest list. And it's a very simple approach. If you're not on the list, you don't get in.
David Murray: The problem, of course, is there's still a list that has to be checked and maintained. And when you extend this analogy to a computer network, you'll have tens of thousands of executable files on a single computer. And when you extend this to a typical computer network, that extends to millions of files. That quickly does become a big maintenance headache. So, there needs to be a better approach than just whitelisting. That's why I prefer the term application control. I don't really like application whitelisting as a term because it implies that there's a list that you've got to manage.
David Murray: Now, the Australian Signals Directorate, they're one of the strongest advocates of application whitelisting. They also use that whitelisting term, and what they state is that application whitelisting is one of the most effective strategies in ensuring the security of systems. Application whitelisting is a security approach designed to protect against malicious code, also known as malware, executing on systems. When implemented properly, it ensures that only authorized applications can be executed. So, they use this term authorized applications, and I think that's a good way to think of it. So, in your environment, you've got malware that you're trying to keep out. Some of that's going to be known, and it's going to get blocked by antivirus. Some of that, however, is going to be unknown, and sometimes it doesn't get detected by antivirus solutions.
David Murray: On the other hand, you've got applications, some of which are authorized. This is the good stuff that you want your users to have. And some of it's unauthorized. That could include vulnerable versions of applications, or it could include other applications like games, file sharing software that consume network bandwidth, and they introduce risk into your environment. It really comes down to what's trusted and what is untrusted? And that's what I like to focus on. It's often referred to as controlling the gray. Application control is really about controlling the gray area that exists between blacklisting on the one hand and whitelisting on the other. And it does this by eliminating untrusted or unwanted change and only allowing trusted and known applications to run. So, rather than focusing on whitelisting, we focus instead on what we want to trust, and we block everything else that we consider to be untrusted.
David Murray: Now, in our webinar two weeks ago, we focused on how to build a solid security foundation, and we looked in detail at some of the security frameworks from around the globe. So, I won't spend a lot of time on these today, but on this slide, you can see the top five controls from the Center for Internet Security, the critical security controls as they're sometimes called. These top five controls provide you with that cyber hygiene, that foundation level of security.
David Murray: Number two on the list is the inventory and control of software assets. And what the Center for Internet Security Guide says about this is as follows, "Actively manage all software on the network, so there's only authorized software is installed and can execute. And all unauthorized and unmanaged software is found and prevented from installation or execution." That's quite similar to what I described on the previous slides. This CIS controlled number two, it does extend beyond application control or application whitelisting to include other aspects like software inventory, where whitelisting or application control is very much a part of it.
David Murray: We switch over to Australia. They have the ASD, the Australian Signals Directorate Top 4. More recently that's been expanded to what they call the Essential 8. We're just looking at the Top 4. Just looking at the Top 4 provides mitigation of over 85% of the techniques used in cyberattacks. And again, here we can see we've got application whitelisting on the list, one of these key defenses.
David Murray: Over in the UK, there's the National Cyber Security Centre and their framework called Cyber Essentials. You can see here what Cyber Essentials includes down at the bottom. The terminology used here is a little bit different to other frameworks. They've simplified the language, and they've deliberately tried to avoid using jargon. So for example, where we might say vulnerability management, what they have is they recommend that you keep your devices and software up to date, very simple language. They also recommend that you protect your systems from viruses and other malware. But when you look on the website and try to understand what that means, they also list whitelisting as one of the anti-malware measures, and they state that, "Whitelisting can also be used to prevent users installing and running applications that may contain malware. The process involves an administrator creating a list of applications allowed on a device. Any application not on this list will be blocked from running. This is a strong protection, as it works even if the malware is undetectable to antivirus software. It also requires little maintenance." So, they take a slightly different approach or a different angle on the maintenance side of things.
David Murray: Looking at each of these national frameworks from around the globe, you can see that while there might be some kind of differences in the overall messaging and the relative prioritization within these frameworks, application control appears in the top four or top five from each of them. So, in the case of the CIS inventory and control software assets, Australia's Signal Directorate, they call it application whitelisting. And Cyber Essentials, keeping it simple as just saying, "Protect from viruses and other malware."
David Murray: Let's look at this from a different angle. If you look at how breaches occur and in particular look at targeted threats or advance persistent threats, sometimes referred to as APTs for short, these follow a fairly well-defined framework for success. An APT is more of a methodology used by attackers rather than a piece of malware that ends up on an endpoint. And this is often referred to as a kill chain, the term used to describe the various stages of a cyberattack. And no matter what group is behind these types of attacks, their exploitation techniques follow a fairly predictable pattern. Here on this diagram, I'm showing five stages. Sometimes, you'll see a more elaborate version of this, a couple of these stages broken out further, and you'll see seven or even eight different stages. But overall, it's broadly the same flow and the same pattern. And really for organizations to protect themselves against these types of targeted threats, this is why you need to implement a security framework like the CIS framework to provide that defense-in-depth.
David Murray: If we look at each of these stages, the first stage is discover, essentially casing the joint. The attackers in this case first learn the internal structure of the target organization and gather information from public sources, from websites, from Internet searches, social media, these types of locations to build an understanding of the target organizations. The attackers then create an initial plan, and they identify probable ports of entry. They will assemble a team and tools required for the initial campaign, and then they start to probe the perimeter, essentially a discovery exercise. And that will include things like port scans, vulnerability scans, maybe even a physical security assessments. That's the first stage, discovery.
David Murray: Next stage is distribute, and that involves developing the payload and creating a delivery mechanism so that it can successfully land on a victim endpoint and ultimately then delivering it to the target. More often that not, that's going to be via a phishing email. Some other mechanisms can also be used. Once the payload has been created and physically delivered, it now has to be triggered on the targeted system. The trigger could be automatic, or it could require some sort of interaction with the end user. Maybe the end user's got to click on an email attachment or a link, or maybe they've got to plug in a malicious USB stick into an endpoint. Once the payload has been triggered, most often a vulnerability is going to be exploited in order for the payload to run and install itself. Those vulnerabilities, they could be zero-day, but most likely, they're going to be known existing vulnerabilities. An attacker is only going to be as sophisticated as they need to be, and if systems are unpatched, they're going to be able to use existing known vulnerabilities, rather than having to rely on something more creative. They might even use multiple different vulnerabilities in a campaign.
David Murray: So, once the exploit phase has occurred, attackers may then want to upload additional payloads onto the compromised endpoints. The initial payload may have been small and designed just to gain an initial foothold and then expand from there. So, the payload will typically establish a connection back to the attacker often by piggybacking on legitimate or trusted communication protocols. And once connected, the attacker will validate they have control over their installed payload and verify, as well, that they haven't been detected at this point.
David Murray: That then brings us to the final phase of the APT framework is where the attacker carries out their real mission, their larger goal. And that typically will involve data exfiltration or sometimes just disrupting the CIA triad, a confidentiality, integrity, availability of systems. Often at this point, they will try to move laterally within the organization using their initial foothold as a base. Endpoints may be the initial entry point, but often what you'll see, it's fairly common that the servers or data centers will be the ultimate goal. There might be some additional steps in here that could include extend, elevating privilege and access, moving laterally within the organization, and also obfuscating their presence, going slow and low to avoid detection. Very much the persistent part of an APT.
David Murray: So, that's the typical flow for an APT, an advanced persistent threat. That's a fairly sophisticated attack. But even more random attacks like ransomware, they're going to follow broadly a similar pattern. And it's just that some of the steps, particularly the initial discovery steps, they might not occur at all, or they might just be automated. The reason I went through all of this was to show how application control can disrupt that cyberattack kill chain. So, what's application control going to do? Application control is going to stop that initial exploit. While an attacker may figure out a way to distribute the initial payloads onto an endpoint, it's going to get blocked so it can't run, and it can't spread. If it can't run, it can't collect back to the attacker for further instructions. It can't install additional payloads or move about laterally. Ultimately, it can't execute. Because it can't run, it can't find or exfiltrate data, effectively blunting the attack.
David Murray: So, application control really effective at stopping these types of attacks. You'll still have some of the initial phases like discover and distribute that might occur. The malware may ultimately make its way onto the endpoint. But with application control, it's not going to be able to execute.
David Murray: Now, application control isn't the only defense against these types of attacks, and that's why the Center for Internet Security and these other frameworks recommend having this layered approach with multiple defenses. One of these is patch or vulnerability management. Now, patch can also prevent at the initial exploit by removing the vulnerabilities that an attacker can exploit and prevent them from implanting code and expanding their footprint. So, you may see some overlap here in terms of this cyberattack kill chain in terms of what patch management or vulnerability managements can do and application control can do. They can both be effective at breaking that kill chain at that exploit phase.
David Murray: So, you might well think, "Well, if that's the case, do we really need application control at all? If I just patch everything, I can block that exploit phase. And if I'm doing that with patch, application control might be a bit redundant and unnecessary maybe. Just patch everything." Well, of course, there's a few reasons why patch might not be sufficient. So, let's consider some of these. While you can patch known vulnerabilities, you also have zero-day vulnerabilities, vulnerabilities that exist that haven't yet been disclosed for which there isn't a patch available. So, you can't apply a patch if it doesn't yet exist, but the vulnerability still exists and can be exploited. But even beyond zero-days, something that I'll be going into a bit more detail in our patch webinar next week, there's always going to be some lag between a patch being released by a vendor and it being applied within an organization. And that lag or gap also provides an opportunity for an exploit beyond just the zero-day scenario.
David Murray: Antivirus will detect known malware and might provide some protection against malware variants. But invariably, there's always going to be a percentage of malware variants that will evade antivirus solutions. Antivirus is always trying to play a catch up game and really has proven time and again to be ineffective against more advanced malware, most of which is going to be tested to ensure that it can actually evade AV. For many of the high profile outbreaks that have occurred over the past few years, the likes of the WannaCrys and those, those endpoints, they all had antivirus on there.
David Murray: Third party applications, so, many companies do a reasonable job of patching their Windows operating systems and patching Microsoft applications. But third party applications have vulnerabilities too, which need to be patched. And if they're not getting the same level of attention, there's a gap there that can be exploited. And there really are more vulnerabilities now in these third party applications than on Microsoft applications.
David Murray: There's also some legacy applications and legacy operating systems. These are systems and applications that are no longer getting patches, but they still have vulnerabilities that can be exploited. So, how do you protect those? You can't protect those any longer with patch.
David Murray: And similarly, there are going to be some systems that can't be patched due to conflicts. So often, you're going to have some home grown applications. They might work with one version of a piece of software version of Java or something like that. But if you apply a patch to that piece of software, you patch to the latest version of Java, that may be the cause of that home grown application to stop working. Now if that's a business critical application, the system can't be patched, and organizations will legitimately take the view that, "We need to keep our business running here. So, we're going to take a risk on this. We're going to apply some additional mitigations to protect this system, but we know we can't patch it."
David Murray: And you also have some legitimate applications like PowerShell, and these can be used in a nefarious manner to infect vulnerable systems, often referred to as fileless malware or living off the land. Patch doesn't help with these. They're not actually vulnerable applications. They're just legitimate applications that exist on the systems that are being used in a malicious way by a third party.
David Murray: And really, at the end of the day, you still have non-malicious software that's simply unwanted. So, applications or versions of applications, they just simply don't want to allow it to run on your network. And these are some of the key reasons why the Center for Internet Security and these other national frameworks have application control right up at the top of their list of priorities for an effective layered security solution.
David Murray: Okay so, if everyone says it's really important, why hasn't everyone implemented application control? So, I'm returning here to our friends at Gartner and their report they produced last year, how to plan, implement, and operate a successful application whitelisting deployment. It's actually a really good report, well worth a look if you're considering application control, and I've borrowed this graph from the report. And it basically shows that the more unpredictable the environment and the greater the frequency of change in the environment, the greater the effort to manage the whitelist. In the document, Gartner states, "Application whitelisting is a good fit for the protection of low change predictable environments. In general, any device covered by a well-developed and well-adhered to change control policy is well suited. However, highly dynamic endpoints, such as developer workstations or machines where the end user has local admin rights, will result in higher administration workloads, and they're a poorer fit."
David Murray: Now, I can see where Gartner are coming from with this statement. But for me, it comes back to the application whitelisting versus application control concept. If you're having to manage a whitelist, and there's a lot of change going on there, absolutely you're going to see this straight line effort to manage continuing to increase as it's shown here. But this is where you have to apply some automation, some rules, in order to be successful. You decide what you want to trust and what you don't, and this probably has a greater influence on the level of effort involved in terms of implementing application control.
David Murray: So, this brings us to how we implement application control here at Ivanti. The key difference between our approach to application control and other approaches is due to something called trusted ownership. Now, every file on a Windows machine has an owner. Trusted ownership uses this fact to determine whether something should be allowed to run. So, when you launch an application, if the owner of the associated executable, if that matches one of the trusted owners, one of those owners that we said are allowed to run, then the application can execute. If it doesn't match, it's blocked. It's really that simple.
David Murray: The trusted ownership cuts down substantially on the manual effort of managing a typical whitelist. With trusted ownership, most applications that should be blocked are allowed. They will do so automatically. You're going to get some applications that trusted ownership has blocked that need to be allowed, particularly when you're introducing application control into a kind of more of a brown field rather than a green field environment, where users have had the freedom for several years to install software. For these situations, for those specific applications, you create exceptions to override trusted ownership by creating individual rules. So, some management is required. It's not totally free of management, but much less than managing your typical whitelist. And if you're deploying software in a controlled manner using an endpoint management solution, you're updating software using SCCM, you're using approved software repositories. All of these applications and all of these updates will automatically be whitelisted.
David Murray: Okay so, enough slides. Let's take a look at this in practice. So, I'm going to start here on an endpoint. This is a typical Windows 10 endpoint, nothing too exciting on here at the moment. I've installed one piece of software, an application called PuTTY. But otherwise, this is a pretty clean system, and I haven't done anything special in terms of creating a whitelist for this. I've just supplied our default configuration and put this into restricted mode. So, if I select a file that's been installed like Notepad that's installed as part of the operating system, if I try and run that, it's going to run. So, I haven't got to add this to a whitelist or do anything with it. And the reason that's allowed to run is because of the ownership. So, if I go in and look at the ownership properties, you'll see the owner here is trusted installer. Now, I've said that trusted installer, it's actually one of our defaults trusted owners. And anything that gets installed by trusted installer, by administrators, it's going to be allowed to run.
David Murray: If I was to take a copy of Notepad and simply copy that to the desktop, paste, it's the same file. I've just copied it, but now it's blocked. Why is that blocked? And the reason is because by moving the file, by modifying these in any way, when I look at the properties of it, now you can see that when the ownership properties become available to me, we'll see that the owner is now DM_testuser01 because I have moved a file same as if I downloaded it from the Internet. It's now got a different owner. Same is true of this application PuTTY that I've installed on the system. This application is now blocked, and again, for the same reason. If I look at the ownership, again, it's this testuser01. So, any software that's installed by the system administrator, by your patching solution, by your endpoint management software, is automatically going to be trusted. Anything that the user downloads from the Internet, anything that they click on, any email, is going to get blocked. Very simple process.
David Murray: But let's say I as a user, I need this application PuTTY. It's already installed on my endpoint. Now maybe the administrator will say, "You know what? Just delete that. We'll deploy it for you, or go to our trusted file share and download it from there." But let's say for the sake of argument today, we're going to show how we might deal with that. So, I'm going to switch over now to our administration console. So, this is Ivanti Security Controls. As you can see here, it contains both patch management and application control. And in fact, within application control, we contain both privilege management and application control. So, if you look back to those frameworks we talked about earlier, the Center for Internet Security, the Australian Signals Directorate, Cyber Essentials, you'll tend to see vulnerability management or patch management, application control or application whitelisting, and privilege management as the core elements in the top four, top five. So, we can go and patch our machines and do all of that. We'll look at that a bit more next week. Today I'm going to focus on application control.
David Murray: So, what I'm going to do is I've got a demo configuration I've got here. And within this, I'll have to see here. But let me just look at a couple of things for now. Today, we're going to look at something we call executable control, which is what we call a few of our products, we call application control. So, within that, we actually have three features, one called executable control, which is about controlling executables as far as applications per se. We've got privilege management, and we have something called browser control as well.
David Murray: So today, I'm going to focus mostly on this feature called executable control. Here you can see our list of trusted owners. I've enabled trusted ownership, and if an application is owned by system, by administrators or by trusted installer, which is the case with our Notepad application, it's going to be allowed to run. If it's not owned by one of those, it's going to be blocked. So, I can create rule sets on what we call rule sets, and I create these for groups. I can create them for users, specific devices, and so on. I'm going to focus on the groups for now, and I'm going to focus on the everyone group.
David Murray: So, I'm going to go into executable control. You can see here I'm in restricted mode for everyone, for all our users. I can set up different groups based on access directory, but just using the everyone group for now. Initially, you would start out on restricted, move to audit only. We could move to a self-authorizing mode. I'll talk a little bit about that later on. But for now, we're actually already in restricted mode. If you have got one rule already created here for one drive on the system, but what I'm going to do now is PuTTY was blocked. So, I'm going to create a rule. I can create different types of rules. I can have the specific file hash if I want to go for more of a absolute whitelisting approach, but I'm going to create a simple file rule. I'm going to say if the file is called putty.exe, and even if it's not owned by a trusted owner, which we know it's not, I'm going to add that rule in there. And it's that simple.
David Murray: Maybe there's some things that I want to block as well. So, we saw that Notepad was allowed to run, and just for demonstration purposes, maybe I don't like Notepad and having that running in our environment. So, I'll put in notepad.exe, and I'll add that as a denied item. Now I can save those down to our endpoints. I've got a couple of systems connected to my demo environment here. The top one is the one that we're looking at today. What's happening here is it's sending an instruction out to the endpoint telling them to come and check in and see if there's a new policy. They do that, and they get that new policy. So, I'll just close that down, and I'll go back here to my endpoint.
David Murray: So, on my endpoint, previously we had PuTTY that was not allowed to run. And if the demo gods are kind to me, we now see that PuTTY is allowed to run. On the other hand, Notepad, which was allowed to run this version that had the correct trusted owner, that is now blocked. So, really simple administration. But I'm sure you're probably thinking as you look to that demo, "Hang on a sec. Did you just create a rule for a file called putty.exe? What if we had malware that was called putty.exe? Would that be allowed to run?" Yep. That would be allowed to run. So, that's not a very good rule. So, let's just get rid of that rule. And we'll save that off. So, that's going to go down to my endpoints, and PuTTY's going to be blocked again when that gets there. I'll just wait a sec for that to finish out. Here, it's probably doing that, but the results here refresh every 15 seconds. So, I got to wait a little bit.
David Murray: What I really want to do here is when applications are blocked on an endpoint, they will create an application control event. And I can go and look at those events on the endpoints. So, I've got something called an event viewer. When that comes up, I can look at a whole bunch of different things. I can look at denied executables. I can look at allowed. I can look at privilege and management events, a whole bunch of other things. I've got a default view that I set up for myself that looks at the long range over the last month. Typically, you'd be looking at a shorter range. When I run that query, what it's going to show me is a list of applications that have been blocked over the last month on this endpoint. And you can see top of the list is this putty.exe. There's a few other applications here I've been playing around with, Notepad for demo purposes, [Rigid 00:34:02]. There's a couple of other things.
David Murray: So, I've got a list of events now, and I can go back to my configuration here. And if I go into my everyone group, I still have my one drive there. But if I go back to my event viewer, what I can simply do is say, "Okay, putty.exe is blocked. This has come through maybe the help desk. I need to add this into configuration." So, I'm actually going to do that by dragging it. I can do it a few different ways, file path, file name. Again, I can pick the specific file hash if I want to get very specific about it. But I'm going to create something called putty.exe. Now, that looks quite similar to the rule that we had before.
David Murray: The difference this time is when I opened that, I don't want to allow it to run if it's not owned by a trusted owner. But because I selected the events and brought the event over, there's a bunch of metadata that comes with that. So, I can do things like selecting, if it's assigned executable, if it's signed by the vendor, Simon Tatham, and I can verify that certificate, that run time. I might want to put in some other checks. Maybe I don't want everything from this vendor. Maybe I only want it if it's part of the PuTTY suite, property name. So, I can add in a whole bunch of metadata. This makes a much more secure rule than what I had before. So, when I send that down to the endpoint, it's still going to run. But in this case, it's going to do some checks. So, if I just had a piece of malware that I crafted and called it putty.exe, unless I can get it to match all of these other things like being signed by Simon Tatham's certificate and so on, it's not going to run. Obviously, I could select the hash to be absolutely certain. So, back on my endpoints. PuTTY is now allowed to run, but using that rule, which is a better rule overall.
David Murray: Now over time, maybe even taking this a step further, if I decide for example, that over time a new version comes out, and maybe this old version has a vulnerability in it. And I really don't want that version to be in place anymore. So, I go to putty.exe and see in addition to on the metadata, in addition to some of this, I've got version information. So, it took up the version information from the file. You can see it's a .70 version. But if I said, "Well, actually, no, we don't want .70 to run anymore. We want .75 to run," I can change the metadata rule for that. Actually while I'm there... Did I do that? Yes, .75.
David Murray: The other thing I wanted to show you, you can look at things like access times and application limits in terms of the number of instances of the application that's allowed to run on the endpoints. Maybe I've got some licensing concerns that I want to take care of. But let's go with that, and if I save that down to the endpoint, when that gets to the endpoint, this putty.exe should no longer run. This is, let's say, an older vulnerable version of the application, and I said, "No, we're changing that. Maybe we can't patch. There isn't a patch available or whatever." But now on the endpoint itself, we can see that PuTTY is now blocked because I've changed that piece of metadata that the version [inaudible 00:37:47].
David Murray: So, let's switch back to slides for a moment. Hopefully, that's given you a good sense of that. Don't think there was anything else. Just looking through my notes here in terms of what I wanted to show on the demo. And hopefully that gives you a basic concept of trusted ownership. Legitimately installed files should be allowed automatically.
David Murray: There's going to be some edge cases that need to be addressed and particularly in more kind of brown field environments, where users have had the freedom to install software. There may be some user installed applications that will fail trusted ownership checking, and you're going to need to do something about those. One of those might be just creating an exception for it. It might often be the easiest way to address that, so long as you're happy that it's not malware.
David Murray: Because of that, you don't want to just go in if you're rolling out application control, you don't want to go in and do what I've done with my demo environment and just turn it on to restricted straightaway. That'll work very well in a clean environment where you've got new systems spinning out. But if you've got a brown field environment, users have been installing their own software, you put it into restricted, you're going to see a lot of applications failing trusted ownership checking. And applications are going to get blocked. Users are going to get frustrated, not a good career move.
David Murray: So, what you want to do instead is you want to start out in audit mode. And what this allows you to do is to identify applications that would be blocked if you were in restricted mode. And you can use this to understand how much of that noise is out there, how much of the Wild West there has been, how much of users installing their own software have you got to deal with versus applications that were installed centrally and correctly. And in audit mode, while you're under no pressure, users aren't contacting you. They don't even know that these applications might have been blocked. You can go and create rules to handle these exceptions. You need to have a process to determine whether you should or not. But you can create the rules to handle these exceptions.
David Murray: Once you've created the rules, then when those applications run subsequently, what you're going to see when you review the log events, they're no longer going to create log events. So, you get this [inaudible 00:40:15] process, and over time, you should start to see these logs getting very quiet. You've created enough rules for those exceptions. They no longer create events, and now you're not getting additional log events. So over time, your logs get quieter. And once they've got to a point where you're not seeing very many or any new log events, now you move into the next phase, which is going to be probably a restricted mode.
David Murray: There is a halfway house between audits and restrictors, which I touched on earlier in the demo called self-authorizing. And as the name suggests, when an application is blocked, rather than having to contact the help desk, users can go ahead, and they can authorize the application themselves. Now, what that does for you is it can provide you with a little bit of extra reassurance. So, if you're concerned about going straight into restrictors and getting the negative career move where everybody suddenly gets blocked, in this case, those applications are still logged. You're still going to get the log events, but user productivity isn't impacted. Users will get a popup saying, "Do you want to authorize this application?" So, it kind of creates awareness for the end user as well. "Oh, should I click yes for this? Well, if it's not the case, then I at least do my job. Yes, I should, but maybe if I clicked on something in a phishing email, maybe I shouldn't."
David Murray: But usually what you're going to find out at this stage is you're going to see very few of these self-authorization requests, particularly if you've done a reasonable job in the earlier phase. And you can just go ahead and move then with confidence into a fully restricted mode. After that, you're in a kind of production scenario, and it's a question of monitoring the logs maybe every day, depending on how much activity there is. Maybe events will come through the help desk that somebody needs something resolved, and then you adjust the configuration again.
David Murray: In terms of best practices, when it comes to roll out, you'll start small. You'll start with the pilot of 50 to 100 users or 100 endpoints. I would tend to go towards a lower number, maybe even less than 50, and pick endpoints that represent a good cross-section of your population. You're going to learn just as much from a small group. The benefits of going with a small group, you don't run the risk of seeing lots and lots of events coming in that are just noise while you're creating these rules. So, that small group would provide you with a good learning experience in terms of how the rules work and how to update the configuration.
David Murray: The real benefit during this initial phase, however, isn't so much about the configuration. It's more about testing out your support workflows. The success or failure of an application control rollout will depend on what happens when applications get blocked. So, if users need exceptions created, this needs to be done in a fairly timely manner. You need to decide, and this is really important, you need to decide who is going to own the decision-making and what that support workflow looks like. Once you've figured that piece of it out, the rest actually is fairly easy. The technology side, as you've seen from me just creating the rules in the demo, that part was relatively easy. But if you end up with a situation where users are not getting exceptions dealt with, and they're being frustrated, they're considering that their productivity is being impacted, that's when you get into trouble with application control. So, you need to ensure that you've got a process that'll work and that that process will scale once you've rolled out to larger numbers. So, don't ignore the process side. This really is what will determine success or failure.
David Murray: Now, I've included a link here for an implementation best practices guide. If you go there right now and have a look up there... Actually, it's not there just yet. This is a document that I have been working on, actually, for the last number of months, probably longer than I care to admit really. But I have completed it now, and it's currently with our technical publications team for final editing. So, it's going to be posted here very shortly, hopefully within the next week or so. So, if you are getting to a point where you're starting to roll out application control, do take that guide down and have a review of it. It covers points I've made on this slide with you in a lot more detail.
David Murray: Okay, on this slide, this is an implementation best practices diagram from Gartner, again, from that same document. They've broken this down into a number of phases. So, a very good approach, a very good guidance here. They've got a pre-implementation phase where you select a subset of typical endpoints, so again, making that same point. Select a population. Don't try and roll out to everybody at once. Identify what you want to trust and how you're going to support changes when issue occurs. Again, they're making that same point. Change, control, process, planning, really important.
David Murray: Next, you get into an implementation phase. You start to roll the agents out to your initial test group. You go into an audit or a learning mode and start to build your policies and ultimately, move into restricted mode for the pilot group and continue to iterate as issues are found. So, an element of lesson learned as well. So from there, you expand your population, and you repeat that process. And you talk about event driven operations, how you handle exceptions, how you onboard new applications, troubleshooting, responding to incidents. And then some periodic operations, just reporting population adjustment over time and those types of things.
David Murray: Okay. One of the other things I wanted to talk about was fileless malware. So, I touched on this a little bit earlier on. We hear more and more about fileless malware in recent advance attacks. And the reason that this is worth discussing is that fileless malware is touted as malware that bypasses application control. And the reason it can do so is that application control is typically file-based. What fileless attacks do, as the name suggests, is that they exploit a vulnerability in a running process. And they map directly into that process in memory, and then they leverage some standard operating system tools like PowerShell to do their dirty work. Now, PowerShell is a trusted application. It would've been installed when you set up your system. It's allowed to run, and application control is taken right out of the game. So, Superman had kryptonite, and application control has fileless malware. This is a real problem for the world of application control.
David Murray: Good news is within Ivanti, our application control has some additional capabilities built in to protect against fileless malware. Of course, with patching your vulnerabilities, you can stop the attack at the source. Fileless malware does need to gain a foothold on the system and get into that memory space, but it will generally do this by exploiting a vulnerability. So, use that defense in depth, patch, address those vulnerabilities, and you stop that opportunity. But if it gets past that, let's assume that you have an unpatched vulnerability that gets exploited or maybe there's a zero-day, and this fileless malware now tries to runs PowerShell to launch a script to do its dirty work. This is going to get blocked by our application control solutions.
David Murray: So, how does this happen? The reason this happens is, again, trusted ownership. Trusted ownership also applies to scripts. So, the PowerShell script, it's going to get passed through the same rules as if it were an executable, and because the ownership of that script is not going to be one of the trusted owners, it's going to get blocked. So, when people talk about fileless malware as a way to circumvent application control, just know that it's not the case with Ivanti's application control solution.
David Murray: So, I'm going to switch back to our demo environment, just to have a quick look at that again. So, here on my system, you'll see that I've got a little script on the system here. So, if I go and run that script with PowerShell, ask me if I want to do that, and it opens this and because my scripting abilities are very limited, all I managed to do was pop up a message box that says application control is really easy. Hopefully, you believe me by now. So, the reason that that was allowed to run, again, if I look at the properties... And again, it's going to take a couple of seconds just for it to come back and let me look at the properties. Let's see that the owner in this case is one of our trusted owners. In this case, it's administrators. So, the administrator has put this script on the system, and I can use this script.
David Murray: However, if I modify this script in any way... So, let me open this. Okay, I'm running in... Oh, am I doing this? Oh yeah, okay. Well, my demo's working. Notepad is still blocked. So, let me go back to my console and unblock Notepad because I need Notepad for this demo. So, I go down here to my denied application, and I'm going to remove that. Save that. So yeah, it proves application control works I guess. Just give that a few seconds to get down there. Great. So, that's now on my endpoint. So, I've got my script, and if I open, which hopefully I can do now, yippee. And you can see it's a pretty simple script. It says, "Application control is easy." So, let me just modify that, and I'll say something nasty like, "You have been hacked. This is malware." And I save that off, and when I now go and run this with PowerShell again, lo and behold, it's blocked. So, I'm not authorized to run that. And again, the reason of course is that when I look at the properties... In this case, you'll see that the properties are no longer the administrator. They're now this DM_testuser01. Okay so, just to demonstrate that we can deal with fileless malware.
David Murray: So, let's switch back to my slides. Getting close to the finish now. So, what you saw in the demo was Ivanti Security Controls as I outlined. Just to give you a bit more info on Ivanti Security Controls, this brings together the best-in-breed technology from across the Ivanti security portfolio into a single platform. That name, Ivanti Security Controls, was something we selected to really align with those critical security controls from the Center for Internet Security and those other frameworks that we discussed earlier. So, you can see right now application control, patch management, privilege managements all form part of the solution. And what it does is it's designed to provide that layered modular defense-in-depth, giving you that solid security foundation to protect against security threats.
David Murray: One of the other things that we focused on within Ivanti... We've grown through acquisition if you're not familiar with the Ivanti history. So, we've acquired a lot of security technologies over the years, and some of those have been overlapping. So, when it came to selecting what we considered was best-in-breed, it wasn't just about the technology and a good security technology. Good security technology is only good if it can be used. And part of that talks to simplicity, and we really looked at selecting technologies, hopefully like you've just seen with application control, that are easy and intuitive to use. So, that formed part of our decision criteria, having a simplified workflow, and also building in automation, probably more so on the patch side right now. Automated patching very much part of that, but automation, again, in the context of application control, where we're not talking about whitelists. We're talking about building rules, building trusted owners to automate the maintenance of that whitelist effectively.
David Murray: And then finally, balancing security with user needs. Gartner talked earlier about the potential impact on end users. We're very much aware of that, both from a performance perspective and also, from a productivity perspective, the need to get that balance right when you introduce security. So, that's what we've done or at least tried to do within Ivanti Security Controls.
David Murray: From an application control perspective, I've mentioned the three features. What we focused on today in the demo was on the executable control aspect of this. Our webinar last week was around privilege management. So, today was about execution control ensures that untrusted applications and scripts aren't able to run, very effective at blocking ransomware and other types of malware. It also complements patch very well in that it protects what you can't patch and provides that zero-day protection. So, as I mentioned, application control includes privilege management. Security best practice dictates that where possible, you should remove local admin privileges. In addition to being security best practice, untrained users with admin privileges, they can break their own machines. They can break other users' machines and potentially servers if they modify settings they don't understand. So, with the privilege management feature, you can elevate or restrict admin privileges on applications and allow or restrict access to sensitive Windows operating system functionality.
David Murray: So, we showed the link for last week's webinar if you want to look at that in more detail. And last, we've got a browser control feature, which provides the ability to enhance end users' productivity by restricting website access. Okay, if you want a demo it or you want to trial Ivanti Security Controls, I've included a couple of links here on this slide. So, if you want a demo, you can schedule that, and it'll be with one of our sales engineers where they get on a call. They'll walk you through a detailed demo of the patch and application control and privilege management features. You'll get an opportunity to ask questions, go into a lot more detail than we went into today. You want to go ahead from then and trial us, I've two links listed here. If you're a customer that isn't familiar with Ivanti at all, or you're not using Ivanti Security Controls, there's one link there. But maybe you're an existing patch customer. You're already using the patch part of Ivanti Security Controls or patch for Windows as it used to be known. There's another link there that you can use for that.
David Murray: More information. So, I mentioned this is the third in a series of four webinars. You've liked what you heard today, or you want to find out some more information about patch, next week we will have a Plugging Your Patching Holes with Ivanti Security Controls webinar, and we've got some exciting new things to tell you about there as well. Some additional resources from a patching perspective in particular, we've got our Patch Tuesday. We run a webinar the Wednesday, that was yesterday, for Patch Tuesday. So, go onto our website and have a look. My manager Chris Goettl goes through and delivers a very informative webinar on what took place during Patch Tuesday. We've also complemented that more recently with something called Threat Thursday, which is a blog that runs. But on the fourth Thursday of every month, we have a webinar as well. That's on October the 24th. Coming up just ahead of that, a cyber security virtual event on October the 23rd. So, an event that you don't need to travel to, no need to get travel approvals or anything like that. No need to get badges. Just register for the event, and you can go to that.
David Murray: So, last point I want to make before we go to questions is I'm always keen to talk to customers. I've been working in application control for quite a long time. So, if you're a customer that's already using application control and you came along just to find out some more information, but particularly if you're a patch customer with Security Controls, you're thinking about application control, maybe you've already started on that journey, I want to hear from you. I want to understand how that journey is going for you. Is it working? Is it a manageable solution? Is it a maintenance headache for you? Come and talk to me. I want to learn about your journey. I've included my email address there.
David Murray: So, question I see that's come in. How does this fit in with EPM? So, I've talked today about Ivanti Security Controls, and we've got a couple of different security products within Ivanti. One of those is our endpoint management solution, our former LANDesk heritage. And the good news is that in the recent release, I'm thinking that's 2019.3. Maybe it's 2019.2, they've actually introduced the former Absence application control, which is the model I've talked about today. So, I mentioned the acquisition history of Ivanti. So, our application control heritage comes from a company called Absence, a great product they had called Application Manager. We brought that into Security Controls. We've also now just brought that into our EPM solution as well, so both the privilege management and also, I believe, the application control functionality is in there as well. But that's in the most recent release.
David Murray: Any other questions? I think we're just about out on time. But if there's any other questions, send them in now, and we'll try to get those into the next minute or so. Otherwise, as I say, please come and talk to me. I do want to understand how you're getting on out there with application control. If you're not using it yet, and you'd like to, and you'd like to have another more detailed demo, come and talk to me. Okay, nothing I guess coming in, Jesse. So, with that maybe... Oh sorry, Jared. I'll pass that back.
Jared: Great yeah. Thanks everybody once again for attending. You will receive a link with the recording of this session and David's slides. Look for that in your inbox later today. And then be sure to join us the next webinar in the series. I pasted a link to that in the chat. Also, definitely take a look at the free cyber security virtual event. We've got great insights from Forester, CrowdStrike, Morphisec, Kenna Security, and even our own professionals here at Ivanti. So, we're really excited about it. We'll definitely see you on the next webinar. Thank you so much, everybody, for attending.