WannaCry: It Wasn't the First, It Won't be the Last. So Now What?

June 21, 2017

Phil Richards | Chief Security Officer | Ivanti

Chris Goettl | Manager, Product Management, Security | Ivanti

Matthew Walker | AVP EMEA Product Specialist | Ivanti

History repeats itself, even in the world of cybersecurity. Heartbleed, Conficker, WannaCry…. We tend to forget it all once the carnage is cleared away and we’ve rebuilt. That’s why these attacks happen on a large scale every time. Join us as we dissect the recent WannaCry attack, showing you how it exploits a machine and then infiltrates the extended enterprise swiftly. In this webinar, we'll discuss:

  • What you can do each step of the way to protect against and respond to infection
  • How to ready yourself for what's inevitably coming next
  • How to keep your eyes peeled for the next attack

Transcript:

Amber: Hello everyone. Thanks for joining us, and welcome to the webinar, WannaCry: It Wasn't the First, It Won't Be the Last. So Now What? This is another in our continuing webinar series on ransomware, which we kicked off in May, the Monday after the WannaCry attack was unleashed. Our plan today is to talk about why, post-WannaCry, you need to stay alert and prepare for the attacks that will come next. At the end of the presentation, we will have time for you to ask your questions, anything you want to know about cyber security, and you'll get your answers from the experts. You can type those in at any point by using the Q&A tool provided.
 
Also, a quick note here―we are live tweeting this webinar. Feel free to join the conversation at #Ivantiwebinars, with an “s.” And now, on to the presentation. Leading you through this webinar will be a number of our Ivanti security experts. We have Phil Richards, our CISO; Chris Goettl, the head of product management for security; and Matt Walker, the VP of sales for security. Chris, why don't you lead us off?
 
Why WannaCry Was So Successful

Chris: Thanks, Amber. Coming out of WannaCry, one of the common things that came up as a question was What went wrong? Why was WannaCry so successful? What were the opportunities that came together for this?

We had a perfect storm of opportunities come together for this, and one of the biggest ones, I think, was that a major protocol was vulnerable. Whenever this happens, we have a combination of things. From an operational standpoint, there's the question of impact. If I patch this, what legacy applications am I going to break? In this case, SMBv1. There's a lot of communication that takes place about that. Obviously, that's a challenge that led an already-long patch cycle for many large enterprises to be even longer. Regarding that, Phil, what do you think when it comes to a protocol like this? What are the challenges companies have?
 
Phil: You know, Chris, you're exactly right. SMBv1 or Servers Message Block is a protocol that gets used frequently throughout an organization not only at the IT or corporate level, but also there's often quite a bit of ad hoc sharing. SMB is the protocol used by Microsoft to mount drives and share directories and files across users. It can be used at the IT level where you have file shares set up from IT, and it can be used from a peer-to-peer level if it's not turned off within the routers. That makes it a particularly difficult protocol to patch or upgrade, because IT is not aware of all of the areas that protocol might be in use. It's really that lack of awareness or understanding of what's going to break from a business perspective that causes people to be a little gun-shy about turning off the protocol or patching it. So you're exactly right, Chris, that becomes real difficult to patch in some of these areas.
 
Chris: Adding to that, we had the perfect proof-of-concept code for a completely wormable combo. As we all saw over the course of this year, the Shadow Brokers disclosure at the start of the year, the release of the Eternal series of SMB exploits, really opened a gate. With that came Double Pulsar, a tool that could be used in conjunction with vulnerabilities like that to download malicious payloads. This created a perfect one-two punch where an attacker could take these proof-of-concepts, take advantage of a protocol they knew was going to be a long tail to get in place throughout an environment, and put together a perfect combination of attacks to make this very successful. When it comes to proof-of-concept code like that, Phil, I know your security team looks at a lot of these things. Tell us a little about challenges you face with disclosures and proof-of-concept code like this.
 

Reference Implementations


Phil: Well, that's a really good question and a good point. One of the things this exploit, and more specifically the code (this code was actually created by the federal government, which we'll talk about in detail a little later), actually produced multiple what are called reference implementations of theoretical exploits. A reference implementation is the first point that demonstrates a theoretical vulnerability can be built and put together in practice. But as I said, it wasn’t one reference implementation, there were multiple reference implementations within this SMB protocol demonstrating weakness and exploits and capabilities in multiple ways and through multiple vectors.

This one reference set of sample code proved to demonstrate a number of holes in the SMBv1 implementation. That first bit of reference implementation is what takes an exploit from theory to reality. As soon as you see reference code, that is the definition of Day Zero of an exploit.
 
Chris: For those of you who catch my regular monthly Patch Tuesday webinar, you saw that June had an additional SMB fix. This was a vulnerability that could exploit Windows Search, somewhere on the network could remotely exploit Windows Search over SMB from any point on the network, without authentication. So there is another SMB vulnerability out there that needs to be patched. If you haven't done your June patch cycle, there's a potentially dangerous, already-known-to-be-exploited vulnerability in the wild.
 
Phil: You know, Chris, to follow along with that, one of the things we need to make sure we're clarifying is when we say there is a vulnerability, for example in the SMB search capability, I'm worried that a lot of people think, "That's not a capability I'm using, therefore I'm not vulnerable to that," or, "I understand the search capability is vulnerable, but how bad can it be. I mean, if you exploit, that means you can do searches" Neither one of those is true. Just because you don't use it doesn't mean you're not vulnerable to it. If something is vulnerable, the CVS score will tell you how bad is bad, and if it has a CVSS score of 8.0 or above, what that means is by exploiting that vulnerability, the person has the ability to get administrative credentials on the machine that's being exploited. It doesn't matter what tool it's in, and it doesn't matter what capability it has. It's really important to understand that those two things are there, and because you're not using software or because it sounds innocuous doesn't mean either of those things is true.
 
CVE-2017-0144

Chris: And talking about that CVSS score―this is the profile for the WannaCry SMB exploit that was most widely targeted. The CVE-2017-0144 is one of those areas you can gain a lot of information if you know what to look for in a CVSS scoring. If you look at the Verizon Breach report from 2016, it profiled a number of vulnerabilities that were exploited, and they showed a developing pattern. The vulnerabilities that are likely to be exploited in a shorter period of time start to fit certain criteria, and this vulnerability had pretty much all of them. Attack vector over the network―that's a type of attack an attacker wants. There's somewhere you have to target a user to do it that will get you into an environment, but a vulnerability like this is how they're going to spread. Normally, a high complexity might be a little more of a challenge, but in this case, you have a government-funded agency with highly trained, technical staff dedicated to looking for ways to exploit systems.
 
There's no level of complexities they won't overcome to do what they're going to do. Privileges required―none. That means no authentication was required to do this. Once they got a foothold in one system, they could remotely exploit others without need for authentication, a perfect characteristic of a vulnerability an attacker wants to achieve this type of spread. User interaction―none required. They don't need to target a user to achieve this exploit. and then confidentiality, integrity, and availability, if they exploit this, they get complete access to that system. These criteria fit the profile Verizon had identified through all their research to a “T.” This was a vulnerability that was very likely to be exploited, potentially in a short period of time.

 

Phil, regarding the complexity―I know you and I have talked about this a few times―complexity being high is not a deterrent.
 
Phil: Yes, and it's important to understand and put that metric in its proper frame of reference. Attack complexity is a measure of roughly how long it's going to be before a reference implementation becomes available for hackers or criminals to use as an exploit. When the attack complexity in this particular case was high, that means it's going to be a relatively longer cycle or longer period of time before a reference implementation becomes available. With a government-funded project, the attack complexity being high is a minimal deterrent. The reason this became such a problem as quickly as it did is because the government activities were leaked to the outside world, and that reference implementation became available. As soon as a reference implementation has demonstrated capability, that is the definition of Day Zero, that's the day we start counting from.
 

Previous Attacks


Chris: For over 13 years now, I've been looking at the world through the eyes of vulnerabilities, what to patch, when to patch, how to prioritize, how to determine what really needs priorities. This gave me a distinctive feeling of deja vu. The reason for that is when you look at a vulnerability that fits this profile, that's in a major protocol, you start to see patterns developing. Back in 2014, in December, we had Poodle, the dance-down methods used to exploit older, more vulnerable versions of TLS and SSL. Before that, we had the OpenSSL Heartbleed vulnerability, the heartbeat in SSL that allowed additional attacks to be made there. Even before that, in 2008, we had what I usually refer to as a masterpiece, the Da Vinci of attacks. Conficker was a piece of work. It took a very good combination of forms of attack, it got in and spread like mad, and it was able to exploit vulnerabilities to brute force attack. It was able to do a number of things, and if you look at the numbers, 15 million machines were affected in this case versus the 250,000 we saw with WannaCry before it was mitigated. If you go back even further, Blaster, Sasser, CodeRed, Nimba, I Love You, all these major worms, one of the biggest differences between those and WannaCry is WannaCry was the first to utilize ransomware.

 

Conficker was probably the only other one with a financial aid. It was used for spamming and spyware, fear software that were placed on all 50 million machines. Long story short, this is a pattern that's going to continue. I like to explain it like this―software is like milk. It has a shelf life. It will go sour at some point, and when it does, you don't want to drink it anymore. You want to throw it out, get rid of it. You don't want to use it anymore.

 

Phil, when you see a major protocol become vulnerable like this, what does that set in motion within your mind and within your team?
 

Importance of Patching


Phil: One of the things I think is important to look at as we look at WannaCry and these other pieces of malware that were extremely successful and very popular is, first of all, you hear us talk about patching over and over and over again, and this illustrates why that's so important. All of these major software vulnerabilities or exploits, with the exception of Heartbleed, were patches that were in the air and that were being applied to environments before these major vulnerabilities came to light. Heartbleed's the only one that was pretty close to a Day Zero, and in fact, there was a patch available on the day Heartbleed was announced. Other than that, everything else was available days, weeks, months, or years in advance. This is why patching is so critical. Every single one of these could have been overcome or could have been avoided with prudent and judicious patching of your environments.
 
Chris: One question I've received a lot since WannaCry hit, at least it feels like since WannaCry hit, it's that age-old months and weeks or it didn't happen that long ago, but one of the things I've had a regular question about is could this have been prevented? The widespread reach could have been mitigated, and the biggest one is that, to your point, most of these widespread impacts were not Zero Days that got out with the ability to go and do all their nasty things before a patch was even available. We had three patch cycles where these SMB vulnerabilities could have been plugged on those systems. You could have easily put the patch in place that would have stopped the wide spread. If one system had been hit by the ransomware side, the vulnerability that could have been exploited to spread quickly could have still been mitigated.
 

Importance of Whitelisting


Also, whitelisting―even if you didn't have the patch in place, the ransomware that would have attempted to download and run on a system could have been blocked by having whitelisting in place. Layered defense, having multiple security controls in place to make sure you are preventing these vulnerabilities from attacking. The combination that is probably the single, most-effective combination against ransomware is patch the vulnerabilities that are going to be exploited and block the payloads that are not trusted from being able to run. Phil, I think you have a strong feeling about this, as well. When you look at whether this could have been prevented―to a certain degree, it was prevented from going further.
 
It Could Have Been Worse

Phil: That's right, Chris. A lot of the potential for WannaCry was mitigated very quickly by a couple of things. First, people came in droves and patched their systems with the available Microsoft patches, so there was a lot of patching activity during the week after WannaCry hit. Additionally, on the second day after WannaCry became available, a researcher found a kill switch for it, which rendered it ineffective for spreading further.
 
As you mentioned, about 250,000 machines were impacted. That impact could have been a lot worse had the kill switch not been in place or had a patch not been available or had the patch been more difficult to get from Microsoft. As you mentioned on a couple of occasions, there were multiple patches for different versions of the operating system. In fact, Microsoft went out of their way to patch deprecated, obsolete operating systems, as well.
 
Chris: Yes, so as we look at the deja vu slide, with all of the reoccurring patterns, we see as software ages, as protocols age, vulnerabilities continue to be found. What can we do to protect ourselves going forward? We've broken this down into two parts. The first part, Phil, what are the top three things everybody should have in place to reduce a significant amount of risk to their environments? We've talked about patching quite a bit. What about application control?
 
Importance of Application Control

Phil: Application control is really all about what you said previously―whitelisting applications that are known to be good, applications blacklisting for certain functionalities that are known to be bad, and taking a more measured approach to software that's between those two extremes. It's really important to do that. Often people, even you and I Chris, when we click on an email, often we're not aware that is ticking off or triggering an application to run on our system.
 
It's always important to have that kind of application control in place so that you're aware applications are trying to run, and if it's known good, it’s allowed, but if it's not known to be good, then some level of executive function or executive decision needs to be made about whether or not that should run.
 

Importance of Antivirus Software


Chris: Absolutely, and when WannaCry hit, there was a race with AV vendors to try and catch up, to detect and block it correctly. Number three, we're in a day and age where as much as 70% of malware is targeted. Even in the case of WannaCry, once they caught up, antivirus/antimalware software was still important in defending us against this type of attack, correct?
 
Phil: That's absolutely correct. When WannaCry hit, within the first hour or so, only about 30% of the virus definitions were able to correctly identify and block WannaCry. Three hours later, it was close to 100%. Even though your particular antivirus/antimalware might not block the initial attack, within a few hours it will definitely slow down or arrest the attack from spreading completely. That's the real value of antivirus/antimalware. It doesn't decimate your environment. You can still become vulnerable and still get hit by certain things, but you won't be completely unable to process all of your work.
 
Chris: These three things are the base. These are what everybody should be doing; this is a great foundation to start with. Let's transition over and talk about a couple of other things that, once you have the ability to step up your game and expand out, things you should be doing. The first one―host-based intrusion prevention.
 

Host-Based Intrusion Prevention


Phil: This is really the process of having your machine look at the network protocols and the network packets sent to and from it, and identifying patterns indicative of malicious intent. There are certain things that will happen, either going out from or coming into your workstation, that might not be caught from an antivirus perspective, but can be determined from a network perspective as an indicator of something that's not good and never an indicator of good traffic. Those kinds of things can be caught, identified, and prevented from happening to your workstation with HIPS, a Host-Based Intrusion Prevention System.
 

User Education


Chris: This next one, I know, is something you are definitely concerned about, Phil, because you've instituted a very good training practice here at Ivanti. Education is one of the foundational things. Security has to be everybody's problem, right? When you're talking about educating your average user, it doesn't matter if it’s the receptionist, HR, legal, or whatever, each of us are going to be targeted in different ways. If we're not cognizant of that, if everybody isn't aware of the security risks of the day-to-day operation of a system, it's going to increase the number of incidents. The first and most important part of a good education program is simply to help reduce the statistical number that's going to come at us, reduce the overall number of incidents that may actually get through, right?
 
Phil: Yes, 95% of malware attacks originate with some sort of social engineering or phishing attack or spear phishing attack, where you receive an email you shouldn’t open, but you open it anyway. Through training, education, and practice, we have seen that we can dramatically impact users’ ability to identify those and not click on them. We can stop more of the bad stuff from coming in at the front door by making sure users are trained. Typically, users are pretty smart, and once they know what to look for, they do a pretty good job of seeing it.
 
Chris: On a personal note, I have two stories about how education is important, but how we are all still susceptible, even with the best training possible.

 

When we started our internal phishing campaign, I was talking with one of our developers, a smart guy who wrote some very complicated security-related features in some of our solutions. We were in a conversation, and out of the corner of his eye, he saw an email pop up. The email said, "Hey, you need to click here to expand your Inbox so you don't run out of space.'' Annoyed, he said, ''Oh, why can't IT just do this for me? Why do I have to click here to expand my Inbox?'' and I said, ''Dude. Hold on. Replay that for me. Why does IT want me to click?" Oh, yeah.
 
Little did he and I know it was one of our first internal phishing campaigns, the email quota campaign. I saved him from a little additional security training, but it can catch any of us. At the right time, we react in a way where―again, these people design these attacks to trigger certain behaviors in humans―we're so crammed with things at times that we can miss something, even with the proper training.

 

The other side of that though, my wife―married 13 years now―has listened to me harp about security-related topics for all the years we’ve been married and before. A couple of months ago, she received an email saying she’d won her eBay auction of $1,800 for a piece of furniture. I was across the breakfast table from her, and I heard her react, ''What? I haven't been on eBay in months. What the heck is…?'' Then she paused and said, ''Oh, wait a second. This is bad isn't it?" She showed it to me, and I said, ''Yeah, actually it's a phishing attempt, pretty sure.” It was one of those things where my wife works in a school and deals with kindergarteners through fifth graders on a daily basis. Security is the last thing on her mind, but because of continual reinforcement of those security topics, she was able to catch something at the right moment, and it clicked with her to stop and think before she clicked. The importance of education in any security program is significant.

 

Email Gateway

The last one though, continuing with email, is the email gateway. Phil, you have a solution in place for us here at Ivanti that was able to stop a couple of the known phishing attempts that led to WannaCry getting into some environments.
 
Phil: That's right, and it does a really good job. Our email gateway service repels about 60% of incoming or inbound email from getting to our Inbox because it identifies it as phishing attempts, malware, adware, or junk mail we didn't request and don't want. It does that based on the content, the sender, the train of mailboxes, or the hops it went through to identify it.
 
Another thing this particular software does is protect the URLs embedded in an email message. This is important because web links have a habit of being good for a long time, in other words, not malicious for a long time, and then they might be malicious for 5 minutes, 10 minutes, an hour, or something like that. They then go back to being not malicious again. What this protection does is evaluate the website at click time. When the user clicks it, it looks at the website, determines if there's malware or an exploit kit attempting to access the system at the time the user wants to click it, and then blocks access or allows the user to access it depending on what it finds. Some of these capabilities are a little more advanced, but they are really helpful in terms of limiting the number of possible threat vectors that get into your environment.
 
To Pay or Not to Pay

 

Chris: Another question that comes up regularly, which I know you and I both agree on, is Why not pay the ransom? Well for one, you're being an enabler. You're encouraging the bad behavior of these threat actors. If people continue to pay, it encourages them to make more money. Two, there's no guarantee. You're talking about a level of trust needed to say, "I'm going to pay you to unransom my machine." Trust went out the window once the attack was made. How can you trust somebody who already did an underhanded thing to you? I think paying a ransom is flat out “No,” shouldn't do it ever, really bad idea, not a good situation to get into, right?
 
Phil: Right. There's another component to this I like to bring up, as well, and that is the company is often in a position where they're evaluating paying a ransom because something in their environment isn't working correctly. Either they don't have backups, or the restore process hasn't been tested and takes an extraordinarily long time to restore, or they don't have some of the controls in place we mentioned on the previous two slides. A ransom attack is one way to focus individuals’ and management's attention on the problem. In the midst of these attacks, paying for the correct process, remediation, and backup and recovery services, becomes a much easier spend than it might be at a different time.

 

Given that it proliferates ransomware by paying, you're not guaranteed to receive your files back. What often happens if you pay is the ransom providers look at that and say, "You know what, I think we're going to extort a little more money out of you." There have been multiple cases where the bad guys have come back and said, "You know what? We said it was only going to be one bitcoin, but we meant five. Now we want you to pony up more money."

 

There are a lot of reasons not to pay the ransom. One of the best reasons is you can look at it as a learning experience for your organization, and make sure your organization is better protected for the next one.
 
Chris: Let’s transition now to going forward. How do we prevent things like this from happening in the future? How do we get better at protecting against the next event that happens?

 

A Defense-In-Depth Strategy

I think it's a combination of things we've talked about so far: defense-in-depth. None of those security solutions alone are going to be a silver bullet for securing your environment, but the combination of them, the overlapping layers of protection, create an ability to defend against a significant number of types of attacks that are going to hit your environment.
 
Defense-in-depth is an important part of any security strategy. You need to patch, you need application control capabilities, user training, Gateway, and other controls such as HIPS. You need to layer those defenses to ensure that any one of them isn't the point of failure that exposes your company.

 

Phil, this is definitely something where you and I are on different ends of the spectrum. How do we balance security, your role, and my concern, which is making sure the users on the other end of the products my teams build―how do we balance your role and mine and make sure we can provide defense-in-depth without causing the type of impact to the business that gets a security control thrown out immediately?
 
Phil: That's a really good question. Savvy security leaders recognize that one of the more important aspects of their job is to balance security controls with end-user productivity. Security people often are told to look at the CIA of security, and that doesn't stand for the Central Intelligence Agency. It stands for Integrity, Availability, and what's the C, again?
 
Chris: Confidentiality.
 
Phil: Confidentiality, Integrity, and Availability. The A in that, the Availability portion, is part of security's main focus. One of the things that means is that as we're implementing security controls, we cannot impact negatively the availability of those systems to our end users. Whether it’s because we impact the end-user workstation or the servers, it doesn't matter. We have to look at both sides of that equation.
 
Chris: That's true of any of our security solutions here at Ivanti. If the user notices them, that's usually bad. We try to make them invisible. “Secure in silence” is how we refer to that. Provide security without interfering with users’ jobs. We should allow them to go off network and still be secure. If they run into a policy or rule that prevents them from doing something, there should be avenues to self-elevate or request support no matter where they are, off or on network.
 
We want to bring that to a level of simplicity where, say, if it's a high cost to maintain―whitelisting is a great example. Traditional whitelisting, a whitelist that says explicitly all the things allowed to run, is an exhaustive process to discover, implement, and maintain. Dynamic models, trust models, ensure you can do application control without the huge overhead it takes to maintain more traditional models. These are principles we bring together so these types of security controls can balance the CISO needs with business needs.
 
Phil: Whitelisting is a really good example. Static whitelisting is notoriously brittle and causes impact to end users, which is why a lot of organizations went away from it even though it's considered one of the most important controls you can put in your environment. The impact to end users is deemed by many organizations to be too large to be able to adequately whitelist all the applications. Ivanti's model of Dynamic Whitelisting and Rule-based Whitelisting accomplishes the goal without the impact to users other models have.
 
Building a Security Control Framework

Chris: This all builds up to, again your area of expertise, a solid security program.  Ivanti is not only a vendor creating security controls you can use among all the other things we do, but we also try to help our customers build a solid security practice. One of the things we've done is have conversations with a group out of the U.S. called the Chertoff Group. They have given us good guidance on this and helped guide our focus around our security strategy. They helped us pick a framework for achieving the goals we have.

There are a lot of things on this slide: PCI, FIPS, FISMA, ISO, COBIT, HIPAA. Many of these are mandatory for portions of your environment. Some of you might be dealing with multiple of them. One thing these frameworks do is give you huge amounts of information, hundreds if not thousands of security controls you have to adhere to, and at the end of the day, it's a thumbs up or thumbs down on whether you've been successful. They don’t do some things that are very critical to building a true security program. It’s only compliance at this level.

Who we turned to was the Center for Internet Security, their critical security controls. This framework is based on giving you prioritized guidance. If you follow this from 1 through 20, you're going to be successful, and it's going to give you the biggest bang for your buck starting from the top and working your way down. They built it based on experience and practice in the industry, guiding people to create an effective security program. Layer on those security controls, and get the best effect with each step you take.

Phil, when you're looking at a framework like this, how does it help you in your role, and how would it help our customers?
 
Phil: Well, a framework is the complete set of things an organization should do to maintain adequate security for their environment. The reason I like the Center for Internet Security critical security controls is because, as you mentioned, they are prioritized. The number one critical control is more important than the number eight critical control. Each of these controls has subcontrols, they're actually control families. There are between 5 and 15 specific things you should do inside each control. Should you do everything in control one before you start control two? No, probably not. You should make sure control one has good coverage and then start working on the items under control two. There is some room for moving around, but you should make sure you have the top five controls pretty well in hand before you start on number 20, which is red team exercises, and that kind of thing. There is a certain priority to things, which is what I like about Center for Internet Security controls.

As you mentioned, depending on the industry you're in, you might be forced into, or some parts of your environment might be forced into other compliance frameworks, as well. All of these frameworks are very, very good, and there's no reason to not go with any of them. If you are in financial services, for example, if you're a bank and you're required to fall in line with the FFIEC guidelines, that is a fantastic framework and there's no reason you should deviate from that if it's required for your industry. If you're in an industry that has a blue sky as far as regulatory oversight, I recommend taking a look at the Center for Internet Security critical security controls as a good model for the types of things you should be doing and the order in which you should be putting them in place.
 
Chris: One thing they do a very good job of is they have this great poster that cross-references all the regulatory frameworks, many of the geographical ones, such as GCHQ, ASD, all the frameworks we use globally, whether vertical or geo-based. They do a great job of taking their controls and translating them into areas of the frameworks you need to make sure you're compliant. If you take these, you're going to do the best things first, and you're also going to achieve the things in the frameworks you care about.
 
Let's take a look at the top five. If you do these five well, you’ll be taking care of a significant amount of risk to your environment right away. The first two on the list are discovery and inventory of authorized, non-authorized devices. If I know what devices are out there, I can go on to step two, which is what software do I have. If I can't see it, if I don't know about it, I can't secure it. This is a foundation of this framework, and it's a foundation of any good security program. If you can't discover what's in your environment, you're already working from behind on being able to secure things because you don't know what's out there.
 
Phil: Right. Breaches that happen in an environment indicate somebody is actively trying to get into the environment to do something horrible or something wrong or something bad. Breaches often gravitate to the one server that doesn't comply with policy for whatever reason, and that one server, for whatever reason, is not part of your configured items list or asset inventory. Almost always, the bad guys find the server you can't find, haven't patched, haven't updated, or haven't put a web application firewall around. They'll find that server, and that's the one they exploit. That's why these two things are so important.
 
Chris: From there, secure configuration, continuous vulnerability assessment and remediation, and controlled use of administrative privileges―with these three controls in place across all the devices you now know about, you have secured, with multiple layers of defense, a number of ways an attacker could possibly attack your system. Surface attack reduction for your environment is what this first five is all about.

If you look at the Australian Signals Directorate, they lay this out in a slightly different fashion. The top five from the CSC map directly to the top four from the ASD, from Australian Signals Directorate: patching applications, patching the operating system, whitelisting, and privilege management. They've actually done a study to show that doing these four things well will reduce 85% of the attacks that target your systems today.

Matt, we have you on the line. You talk to a lot of our customers, even before they're customers, and you hear a lot of the challenges they're having today. Share with us some of the challenges you hear.
 
Matt: Thanks, Chris. What we're seeing is a very strong response to our 90-day offer, which means people are starting to consider patching of their operating systems and applications as a priority. We've seen organizations across the board: education, rail companies, communes, law firms, housing associations, lottery companies, you name it, all looking at ways to baseline their security. What we are seeing is coming in at the patching level. There's been a significant interest in the options we have, and we have a number of options for customers. What happened with this attack was the media picked it up, and it became mainstream. That created visibility around the problem of ransomware, but that's a wider issue about malware and advanced persistent threats.
 
Through that, we've seen strong interest, and that’s at the higher levels of security aspects which you and Phil have talked about. To Phil's point earlier, AC is still a bit brittle, Rule-based Whitelisting, Dynamic Whitelisting, we're going to move on to that stage next. A lot of our customers are talking to us about that, but Patch has been the big thing we've seen interest in from our customers.
 
Phil: Let's go ahead and move on to the next thing, which talks about our post-WannaCry offer. Chris, if you're on, maybe you can cover that and talk a little about what we're providing.
 

New Ivanti Offer


Chris: We've had a 90-day offer available to allow people to take advantage of our patching solutions and get caught up or get visibility around WannaCry. Now we're extending that into a larger offering, which Matt, this is something your team is actively pursuing. We had over 500 people respond to the 90-day patch license, and now they're looking for more. Tell us about this offer.
 
Matt: Okay. What we're telling people who have come to us previously and existing customers who have not had security solutions or have come to us looking for trial licenses, is that we have a number of options for them, which depend upon whether they're using SCCM or need to patch Windows environments or Linux or Unix. As I said previously, the patch aspect of trying to secure your environment has become so common in many organizations that many companies are talking to us, but they have different requirements.
 
We have four offers around patching, but what we're saying also is about the bigger picture―and it's something we’ve talked to prospects and customers about for many years― especially around Application Control. It’s not a silver bullet, but if you run Application Control, it's really going to stop Zero Day threats. It's not necessarily the type of easy patch in terms of making your environment secure in the same way that patching is, but it's definitely going to reinforce that top 10%. Ninety percent is patching, 10% on top is using Application Control.
 
Customers have come to us saying, “We're going to be attacked, we've been told we're going to be attacked, and we want to look at your Application Control,” so we've added this as a second option. We also have Xtraction as a connector for SCCM. The offer is, if you buy 2 of our solutions, you’ll get 20% off, and if you buy 3, you get 30% off. We can handle that through our sales teams and our overlay sales teams. This is open to existing customers and prospects.
 
Chris: That's a good point. It's not only for people who are buying our products for the first time. If you're an existing Patch or Application Control customer looking at the additional solution, you are eligible for 20% off the price of the additional solution.

We're wrapping up here, and we have some questions that have already come in. Phil, I think the first one is directed at the slides that talk about the first three and the second three things to worry about going forward. The question is why were fish pictures chosen for that?
 
Phil: That’s funny. We were looking for something that represented phishing attacks. I thought they were kind of cute. The first one, I thought, was interesting because it's actually a little aquarium fish, a picture of an aquarium fish superimposed on a person as if it was a big fish. It's not really a big fish, it's a tiny fish. The pictures were chosen for interest more than anything else.
 
Chris: Right. The next question is on a more serious note. The question is about Patch Manager and why it took a couple of days to get the 2003 variations of the patch for WannaCry out.

 

Response Times for Patch Manager

This is something we’re taking steps to reduce. We have a variety of patch solutions today. There are a variety of teams who create the content for those, and to give you an idea, we had one of our teams in the U.S. working on that on Saturday as things were developing. When Microsoft released the patches, we had those released within only a couple of hours. Obviously that was not the content team for the product you're on, Nikki.
 
One of the things we are doing, and this falls under my team on the PM side, is making an effort to get all of our content streams for Patch developing out of one content stream. For the particular product line you're on, Nikki, the 17.3 release this fall is targeting switching from the legacy LANDESK engine and content over to the content stream that's going forward for Windows. We are already working toward making sure all of our customers are getting content as quickly as possible, especially in cases like this.
 
Another question that came from Bruce, which was answered privately already but we'll air it here so everyone knows, is will the deck be shared after this presentation? Yes, the recorded version of this webinar and the presentation will be shared afterwards. You can get to it from our webinars page. I believe there will be a follow-up email, also, once that’s all live to let you know it's available.


Amber: I have another question for you that came into our host. We have Susan, who would like to know how Ivanti DSM and PatchLink fit into our security portfolio.
 

How Ivanti DSM and PatchLink Fit into the Ivanti Security Portfolio


Chris: That's a very good question. These technologies came out of the emergence of Ivanti earlier this year when HEAT software joined with LANDESK software. Under my team right now, we have six patch management solutions. DSM will switch over to that same engine I spoke about earlier. That will happen if not later this year, early next year. On the PatchLink side, this is whether you're on the PatchLink SCCM plug-in, or―well, let's tackle that one first.
 
PatchLink and Shavlik Patch for SCCM, two products that did the same thing, are scheduled for release later this year for that particular product line and will be called Ivanti patch for SCCM. You will be able to upgrade or migrate to that version, whether you're on the legacy HEAT brand or the legacy Shavlik brand. Either can be upgraded to the new Ivanti branded plug-in.

 

The PatchLink capabilities within the Endpoint Management Security Suite from HEAT software is also going to switch over to a single content stream very soon. I had a conversation this week with our content leads, and they've identified a way we can automate the generation of that so we can have one team generating content and replicating it into the formats we need to make all engines operable.
 
My hope is that, by the end of 2017, all of our Windows patch capabilities will be on a single content stream, and they'll be releasing at the same time very quickly. That is something we're taking seriously, and we're working hard to consolidate that as quickly as possible. Your products are not going to be consolidated. They're being rebranded and moving forward. The engine and content under the hood will be brought together to make it faster and more efficient as quickly as possible.
 
Amber: We have another question for you: What is the minimum provisions of Shavlik Patch for the upgrade to happen?
 

Shavlik Patch Upgrade Requirements


Chris: Shavlik Patch? I would have to double-check that, but I'm pretty sure it will upgrade 2.1 and 2.2 versions to the Ivanti branded version. Actually, 2.3 update 1 was the version that rebranded to Ivanti Patch for SCCM. With the 2.4 release later this year, you’ll be able to upgrade to that from previous versions. As we get closer to that, we'll have more detailed information about whether there's a version step required to get there. I expect most customers are already on 2.2 or 2.3 of that plug-in. For the HEAT side, we're working through which versions of the HEAT plug-in can be upgraded directly. As we get closer to that release date, we'll try to have more details about what versions you need to be on to upgrade directly to that combined release.
 
Amber: I think that's it for questions that have come in. If anyone wants to ask anything else, please go ahead.

Looks like we're probably done. Thank you very much for joining us today, and we'll make sure we get this webinar out to you and the slides, as well. Thank you.
 
Chris: Thanks everyone.