Welcome to the Age of Weaponized Malware. What does it mean to your Enterprise?

June 26, 2012

The U.S. has not denied their role in the use of weaponized malware and already, other countries are jumping on board. India recently announced they are empowering government agencies to carry out similar such actions. State sponsored malware attacks are officially out of the shadows and mainstream for organizations and end users alike. In fact, Google recently announced an alert service for gmail users for “state sponsored attacks”. How exactly did we get to this point and what are the factors and threats that you need to be aware of?

Transcript:

Richard: Hello, and welcome to "The Age of Weaponized Malware, What Does it Mean to the Enterprise?" I'm your host and moderator, Richard Stiennon, Chief Research Analyst at IT-Harvest, and today we are very lucky to have presenting with us two Pauls. Paul Zimski is VP of Solution Marketing, and he brings more than 10 years of industry experience in overseas marketing of solution strategy at Lumension, and he's a regular speaker at major security events, such as RSA, and is a regular contributor for major news publications. Paul Henry is probably familiar to many of you. He's one of the world's foremost global information security and computer forensics experts, with more than 20 years experience managing security initiatives for Global 2000 enterprises and government organizations worldwide. Paul's a security and forensics analyst at Lumension Security and a popular and prolific SANS instructor.
 
This topic is of such interest to me in particular, because of some of the historical, I guess, realities that are coming home all of a sudden. The first time I ever heard the term "weaponized software" and "weaponized malware" was from the former president of one of the major antivirus companies. He was presenting, and he said that in the late '90s, representatives from a particular country in Southeast Asia that is nuclear armed came to them at the AV vendor and said, "We would like you to produce weaponized malware for us." And within several...of course, they turned them down, at least so he states. And of course, three months later, another country also weaponized with nuclear weapons came to them, happens to border the original country, and asked for weaponized malware as well. And the explanation was basically, you have two nuclear-armed countries with a history of engaging in battles with each other, and the goal was to find malware that could turn off access to that big red button that would launch missiles.
 
Of course, you know, thankfully, we've never seen anything like that, but here we are in the day of Duqu, Stuxnet and Flame, which have now evidently, according to Sanger of the New York Times, been attributed pretty affirmatively to the United States, maybe with some help from Israel, and we have truly entered the age of weaponized software, software that was used not only for surveillance and network intrusion, but also actually sabotage. So, let's start with you, Paul Henry, and let you get us going on the what and [inaudible 00:03:03]
 
Paul Henry: Sure, sounds great. I mean, you know, bottom line here is state-sponsored malware and attacks, you know, they're officially now out of the shadows, they're part of the mainstream, for both organizations, enterprises and users alike. You know, in fact, here just recently, Google has begun announcing that they're gonna be providing an alert service for their Gmail users when those accounts come under a state-sponsored attack. I got my first one from Google about three to four weeks ago, and on a trip to Texas here recently, actually got an alert from Google indicating that someone had been bruteforcing the password on my Gmail account, actually they provided me with the IP address of the party that was trying to brute force the account.
 
Now, we really need to get into exactly how we got to this point, you know, what the factors are, what the threats really are that you need to be aware of in the enterprise, and for that, I'd like to hand it off to Paul Zimski.
 
Paul Zimski: Yeah, sure. Thanks, Paul. I think there's quite a bit of background which we're gonna go into in a minute about how we got to this point where our email provider is actually saying, "Hey, it looks like perhaps people are trying to hack your account." Or logging into it via IP addresses that don't seem to add up where you usually are logging in at.
 
And I think that a lot of the media coverage on state-sponsored attacks and this concept of weaponized malware is really bringing all this into the forefront. I think we need to be, you know, sort of open our minds and eyes to the fact that the idea of attacking someone even from a sophisticated perspective doesn't necessarily mean that you're going to be running up against, you know, the corporate network and this heavily defended environment. Sometimes, the most effective hacks and most effective attacks really are looking for sort of the weak chinks in the armor, such as endpoints that may not be as well protected out there, or email accounts that's available via web access. Any thoughts, back at you Richard, on sort of how we're here?
 
Richard: Yeah, about two years ago, I was presenting at COSEC, and I was in a process of researching a book on cyber warfare, so state-sponsored attacks. So they've got these wonderful sessions where you stand up and you just throw something out there and you get three minutes of back and forth. And I threw out there, "Hey, what would a good cyber weapon look like?" And I got blank stares. You know, nobody wanted to say anything. But that night at dinner, somebody nudges me, and, you know, the guy sitting next to me on my right, and he goes, "I got one for you, Microsoft updates." And as you'll see, as we get into evidently how Flame propagates itself, Microsoft update is a fairly well trusted service, you know, digitally signed, you know where the source is, and you say, "Yup, I'll update my computer completely." And just imagine if that were compromised, either through compromising Microsoft, either, you know, through a national effort or a hacker doing so, Microsoft updates would be the ideal way to target particular machines based on their licenses, or identified who they are, or IP address block range in a particular country or region.
 
So I think we've gotten here fairly gradually over the last 10 years. We've seen the history, you know, develop from DDoS and using pretty common hacker tools that cyber criminals were using, also being used by activist groups, but all of a sudden, we're entering this new realm. And Paul Henry, maybe you can walk us through a little bit of that history.
 
Paul Henry: Sure, sure, happy to. You know, first, you really have to start out the conversation by jumping on to, you know, the malware that's actually out there, that we've seen creating these issues. And first and foremost would of course be Stuxnet. Now, everybody's caught the news media here over the last month or so, where the United States has now publicly come out and disclosed that in fact, it was the United States and Israel that had crafted Stuxnet, and it was built specifically to target to Iran, trying to sabotage the Iranian nuclear, you know, refinement plants in Iran. You know, for myself, hey, I'm all in favor of sending bytes and not bullets okay, but, you know, depending on what side of the political fence you're standing on there, was it really a great idea to go public with this? You know, that's still open for debate.
 
And, you know, we kind of put ourselves in a position in going public with this where any third world country with an internet connection and an attitude is now believing that, "Hey, since the U.S.A. can do it, well, why shouldn't we?" We've actually, in my opinion, somewhat exposed ourselves to perhaps undue risk with the public admission, but such is life. We'll have to all deal with that now. Now Stuxnet, you know, it attacked Windows system using an unprecedented four day zero attacks, and it specifically targeted a given programmable logic controller in a SCADA system with a rootkit, essentially to make the operator believe it was running at a set point of RPM for that centrifuge, and actually was not. It was actually running at an RPM that would cause damage to its payload. Now again, with Stuxnet, it had a valid but abused digital signature, and again, the payload specifically targeted the Siemens SCADA system itself. I mean, it was one of the first times where we have seen malware that was specifically targeting a SCADA system by and of itself.
 
Now, if we look a little further down the road, of course, we had the next generation of Stuxnet. You know, many in the community believe that, you know, Duqu was actually created by the same authors as Stuxnet. It exploited some, you know, zero day Window kernel vulnerabilities, contents again signed with stolen digital keys. Again, highly targeted and specifically going after the nuclear program in Iran. Was designed, you know, not only to do a bit of damage, but to also gather information, you know, monitoring keystrokes, system information. And it had a really unique central command and control capability, along with a very modular payload delivery capability, that was also, you know, by and of itself, capable of attacking.
 
Now, that of course, brings us to today, we'll say. Flame, or Flamer, designed again to specifically provide for some cyber espionage against Middle Eastern countries, spreads to systems over LAN or via USB stick, and one of the really unique things about this piece of malware was its use of bluetooth. Again, we've had some great trojans, rootkits etc. out there over the years, and some of that capability was actually better than we had, you know, what we had seen from the state-sponsored malware. But the use of bluetooth was actually something fairly new. You know, many have called it the most complex malware ever found. You know, that's arguable. I mean, when we look at some of the legacy stuff out there, you know, that was some fairly powerful stuff, well ahead of its time. But it's the individual capabilities that we're seeing here, the, you know, the really intense delivery capability that really sets this apart.
 
Again, we have the issue here yet again with digital certificates, an MD5, you know, collision was being used. And of course, it too took advantage of multiple day zero exploits. So with that being covered, I'd like to turn it back over to Paul Z.
 
Richard: One second there Paul Henry, before jumping back to Paul Zimski.
 
Paul Henry: Oh, okay.
 
Richard: Yeah, just a couple points on the timeline here, in that just last week, Washington Post followed up the New York Times article that attributed Stuxnet to the United States, and Washington Post now says that Flame also is a U.S. created piece of malware, and...
 
Paul Henry: Oh yeah, security experts have been commenting on that as well for the past few months.
 
Richard: And the actual timeline now is being hypothesized that Flame was a precursor to Stuxnet, and it had to do with the intelligence gathering and surveillance before [inaudible 00:12:08].
 
Paul Henry: Yeah, I believe the mention out there is that it's been out for about eight years.
 
Richard: Yup.
 
Paul Henry: Yeah, let's...
 
Paul Zimski: The other takeaway from all these three is to realize exactly how surgically targeted they were. I think that we tend to think of malware as, or, you know, weaponized malicious software as, "Oh, it's just out there and spreading," but this, what's really, not only the sophistication of these three examples, but the fact that they were specifically designed to go after just a few machines in the entire world, which I think is pretty remarkable, given the amount of resources and effort behind creating them.
 
Richard: Yeah, highly targeted. Well, let me interrupt the flow here, and I'm gonna ask a couple of polling questions, and then we'll look at the results at the end here. I'm gonna ask the first question, which is, "How concerned are you about state-sponsored malware affecting your organization?" And we'll give you 30 seconds here to pick your choice. A, "Very concerned," B, "Increasingly concerned," C, "Not concerned," or "Unsure," D. And as soon as the voting slows down, we'll proceed with the slides...Coming in fast...So, do you wanna look at the results, you guys?
 
Paul Zimski: Yeah, let's go ahead do that.
 
Richard: That way we can maybe add a little context here. Of course, we've already given them the history of Stuxnet and Duqu, so they should at least be, "Increasingly Concerned." Okay, I'm gonna stop the voting and we're gonna look at the results. Twenty-four percent "very concerned," 65% "increasingly concerned," and 10% "not concerned," and that's probably because they have fabulous security. So okay, let's continue with the sides, and Paul Zimski, why don't you tell us a little bit about the [inaudible 00:14:23] .
 
Paul Zimski: Yeah, sure. Well, and I think tying into that poll result there, you know, that it seems like the majority of the audiences has kind of got their eyes maybe lifted and looking, thinking about this problem, where the minority is really thinking, "Okay, this could happen to me, or this is imminent." And I think, you know, when we look at the scale of malware that's out there and all the attacks, at least that we know of, versus the number that have become publicly disclosed as of late, specifically, these three examples, you know, we have to keep...it's easy to go down this path of, "Oh my gosh, the sky is falling. Look at all these sophisticated targeted attacks." And they're certainly out there, and it's certainly a concern, and this is now a new, you know, high water mark, as far as the complexity of attacks.
 
But if we look at the actual number of attacks, out of the millions and millions of new pieces of malware variants that are out there, it's the minority that are actually this sophisticated, this targeted, and, you know, created with so many resources behind them. Now, that's not to say that it's not a problem, but it's just giving you some context of what we're talking about here, so it's a new threat, new type of threat, the game's sort of changed, things are going to get probably much more colorful moving forward. But keep in mind that this is still a risk mitigation game, and it's all about putting in the right defenses, and layered technologies, processes, people, etc. to manage and mitigate risk. Not necessarily, go chase down the three things that the media and the industry happen to be talking about this week. Now I'll open that up to thoughts from you all.
 
Richard: Yeah, no, the other thing to consider is on top of this, of these, you know, possibly 30,000 new pieces of malware that the AV guys see every single day, evidently, at least according to one report, out of one of the AV vendors, the average number of machines infected with each piece of these multifarious pieces of malware is something like 10. So, it's become much, much harder to counter the targeted attacks, because people are, the attackers are changing their malware automatically and on the fly, and generating basically things that need new signatures constantly. It's hard to keep up with that scale.
 
Paul Henry: Yeah, it's really unfortunate, because, you know, the attackers have absolutely evolved. Now we're, unquestionably has evolved, yet we're still using the same defensive mechanisms that failed us a decade ago. Again, I really try to follow the, you know, reports out there, the old CSI crime report, and, you know, today, it's the Verizon Breach report, etc., etc. And it's like nobody's listening. I mean, we're making the same mistakes year after year after year in defense, and, you know, bad guys are absolutely taking full advantage of it.
 
Richard: Yeah, I'm constantly surprised by that. I'm even on record as saying that malware won't be a problem on mobile devices because the mobile device manufacturers, you know, Apple and then LG or whoever, will make sure there's protections, and the carriers will for sure make sure there's protections, because they don't want the hassles from that, but boy was I wrong. [inaudible 00:18:08]
 
Paul Henry: Oh yeah, yeah. The whole DigiNotar issue really brought that to light. I mean, you know, Apple was weeks behind everyone else in rolling out their patches, and I know people using Androids today, many months down the road, that have still not received an update from their carrier.
 
Richard: So, which would be really bad for people in Iran, where they're using DigiNotar certificates to spoof Gmail.
 
Paul Henry: Absolutely.
 
Paul Zimski: Well all right, I think we're gonna move on now. I think Paul Henry, you're gonna walk us through kind of what you've seen change, you know, from 10 or so years ago to where we are now, that there have been a lot of changes, but what's old is new, and some things have been recycled.
 
Paul Henry: Oh yeah, yeah. It's actually kind of wild, because, you know, so many people have claimed that, you know, this new malware is so powerful, and best they've ever seen from a malware perspective, etc., etc. But, you know, again, with the exception of perhaps the determination on the delivery side of it, we've had some very powerful malware out there for well over a decade. I mean, many people can still remember Back Orifice back in '98, from Cult of the Dead Cow. You know, we've had all of the monitoring capability that we're seeing in current generation malware. You could grab screen captures, do keylogging, all of that. I mean it was a...actually, if it were a legit tool, it would be a perfect tool for remotely, you know, managing a Windows environment. That had been around for years. That was immediately followed up with NetBus, which again had a great deal of monitoring capability. And of course, you know, who doesn't remember Sub7 from just a year or so later. So, you know, we've had very powerful malware out there, rootkit level, you know, exploitation for well over a decade.
 
And when we look at the malware that's out there today, there are some differences. Let's specifically talk about that. We'll move through a few additional slides here. You know, from a development perspective, if we go back a little over a decade ago, I mean, our big threat was that 13 year old that had that, you know, modem connection in the basement, trying to impress his peers with his malware writing skills. That very quickly changed, as organized crime had figured out that, "Hey, there's money in this stuff," and got involved themselves. We saw, you know, better product being generated from a malware perspective, because we actually had some funding behind it, we'll say.
 
And it has changed dramatically now. The development today by nation-states is providing, you know, truly modular, incredibly powerful malware, you know, with very customized payload capabilities. I mean, it's a night and day difference to the malware that we were seeing, let's say, a decade or so ago. Now, if we look at a little further here, the delivery mechanism. Again, today, you know, we're primarily seeing zero day propagation for this new state-sponsored malware, and it relies upon multiple vectors, bluetooth, USB, you know, across network shares, etc. So the delivery mechanism is much more determined. It's no longer simply attaching something to an email or trying to lure someone to a website to hit 'em with drive-by malware. Clearly, there is a deliberate intent to deliver this malicious payload. Now, if we look a step further here on the detection side of things. You know, again, they're blowing through a number of our detection capabilities by using compromised digital certificates, and even the data that they're taking from the environments, they're actually, you know, obfuscating the exfiltration of data as it uses, you know, the environment, captures information, trying to remain a bit more stealthy in the operation of the malware itself.
 
Now, looking one further step here on the command and control side of it. This is where we are seeing a great deal of uniqueness in the current generation of state-sponsored malware. The command and control capability, of building in reliability to command and control, so if a command control unit is taken down, another will quickly take its place. And again, looking at the modularity of the payloads for the malware, you know, truly does set it apart from what we've seen historically in terms of malware.
 
Now again, it all ties back to intent. Again, you know, initially, we saw this stuff rolling out when it was first announced by the press to do some damage to the centrifuges to try to, you know, put a little gap in the timing there, buy us some time to perhaps negotiate a settlement with Iran, who knows. And again, you know, the surveillance capability has come up now with Flamer. And again, it is somewhat debatable as to which came first, chicken or the egg here. Did we have Flamer first, doing the surveillance, or was it in fact a direct assault against the centrifuges to try to delay their ability to perhaps get enough uranium to do some damage. We'll I guess learn over time.
 
Again, the whole disrupt or destroy capability of this malware that we've seen here, state-sponsored, has, you know, been quite effective. At this point, I'll hand it back off to Paul Zimski.
 
Richard: Before Paul Zimski jumps in, just I had a few thoughts. You know, we're building this picture of Stuxnet and Duqu, but of course we can't forget that these just happen to be the first examples of what have been called APTs, Advanced Persistent Threats. So, especially, you know, U.S. defense contractors have seen targeting them and getting into their networks, and of course, the most famous case, and we used to think of the most sophisticated attack, being the one against RSA in March of 2011. And yet, we hear today of not only intelligence gathering going on inside the oil and gas exploration industry, which presumably is targeted that, you know, market data, and knowledge of reserves, which would help an attacker's understanding of global markets.
 
But now, we've got Department of Homeland Security issuing alerts and the FS, the financial services [inaudible 00:24:36] announcing, you know, that there's attacks going on, very similar, and evidently, there's some evidence that it's the same attackers as attacked RSA, and these are going against oil and gas pipelines. So, you know, what are they after? [inaudible 00:24:53] the pipelines and finding their control systems, similar to the way Flame did for Stuxnet?
 
Paul Henry: Yeah, whole new world we're living in.
 
Paul Zimski: That's a good question. And the other, you know, one of the other axes to be thinking about, which we haven't, and which, you know, the industry hasn't as a whole, is the corporate espionage side of this. You know, as this complexity and targeted attacks increase, we tend to think of critical infrastructure, we tend to think of, you know, nation-states going after nation-states. And one of the side effects of this is also gonna be the corporate espionage side of things, and, you know, going after intellectual property, for certain. That game's gonna get much more tricky to play.
 
Richard: [inaudible 00:25:48] out of the delivery column you've got here, when you were talking about that and the, in corporate espionage, you know, we already have many cases of the delivery mechanism being an insider. You know, somebody who's an employee, by the company, and it makes me think of World War II, you know, spy movies, but instead of the agents, basically, they're deploying the malware.
 
Paul Henry: Yeah, and again, even in my own incident response practice, you know, out of 10 calls we may go on for incident response, where they believe that that malicious URL was only clicked on last week, so they've only been compromised for a week, once we go in and start examining the environment itself, we come to find out that they've actually been compromised for well over a year, and that has become the norm, not the exception. Again, you know, we've focused the vast majority of our attention on, you know, trying to defend the perimeter, using decade-old tools, and we've done very little on the inside of our networks to be able to monitor for malicious activity, detective controls, we'll say, to let us know that, "Hey, we've been compromised for the last year or longer."
 
Richard: Now you're scaring me.
 
Paul Zimski: All right. So, I think we'll switch gears a little bit here. I think we've, you know, kind of teed up, you know, the facts and the details of what we've been seeing, but I guess the bigger question is why should we care about this? You know, why is this important to the average organization, or the average person even. And I think, you know, number one in everyone's mind is the potential for retaliation risk. You know, any time a government starts, you know, poking a stick in the hornet's nest of another government, there's certainly opportunity for retaliation. And I'd like to get Richard, your viewpoint on this? I know you've written quite a bit about this subject, and, you know, how likely do you think it is that we're gonna see retaliation based off of these three sort of incidences that we've been talking about?
 
Richard: Yeah. Well, I suspect that retaliation risk didn't go up just because, you know, some leaks from the White House or officials evidently indicates the U.S. was responsible for Stuxnet. Though it does add to the loss of face for Iranians, right, when it becomes globally known. I think the intelligence community around the world already knew, or assumed that this was the case, and certainly Iran is gonna look to its, you know, two enemies, Israel and the United States. So, wasn't confirming something they didn't already know. So, I don't think the risk has gone up, but the risk has been there since Stuxnet was discovered. So the clock is ticking, it's going on three years now, and three years is plenty of time to spin up a cyber, you know, attack capability.
 
And of course, you know, every country in the world, and Iran in particular, has a large community of knowledgeable hackers. All would have taken a couple years ago, start recruiting them, and turning them towards cyber weaponization themselves. And obviously, Iran's got, you know, a huge body of educated computer science, you know, up to PhDs, so the capability is there. And now, you know, we're all just making assumptions. You know, it's kind of hard to go down that path, but we're making assumptions that the desire will be there as well. Because frankly, they're, you know, we've already done as much as we can geopolitically. You know, we can't ship products to Iran, a bunch of countries have agreed not to accept oil from them. So, their risk is a lot lower than ours right now if they engaged in more cyber attacks.
 
Paul Zimski: Right. I guess, you know, the big takeaway is, is, you know, not the U.S., but any country, not the U.S. specifically, but any country shouldn't assume that their critical infrastructure is any less vulnerable, or that their skill set and hacking is any more sophisticated as say, other nation-states that they might be messing with, essentially.
 
Richard: Right. And it's still possible to do all of this and maintain plausible deniability. So it could cause damage, and, you know, to the economy, and short term physical damage, and not, you know, not be looking down the muzzle of a gun or an incoming missile because of it.
 
Paul Zimski: Right. So, another interesting, you know, reason, or aspect to think about is why we should care about this is the potential for collateral damage. And in fact, Stuxnet itself wasn't really discovered until it started spreading a little too well. There weren't many governors built into the actual code to say, "Hey, within the nuclear processing facility, spread much as you want, but outside of this zone, don't spread." And so, the concept or thought process of what if one of these things gets out, a piece of weaponized software gets out into the general public or the general network, and starts spreading pervasively without any built-in controls. Could that start rampantly affecting organizations and systems out there? Paul Henry, what's your take on that?
 
Paul Henry: Well, I think the risk of collateral damage is absolutely huge. You don't have to be specifically targeted yourself in a DDoS attack, as an example, if you're simply sharing, you know, some component of that pipe, that internet connection, you are in fact going to be out of business for a while as that DoS is launched. And again, the alternate to that of course would be malware getting into your environment itself. Again, when it comes to SCADA systems, you know, they're primarily built for performance, etc., so many of them actually lack the necessary error correction to even be able to handle a simple UDP flood. You know, that's a known risk.
 
But within our own network environments, we've seen the damage that a fast spreading worm, you know, can do. Everyone, I'm sure, remembers SQL Slammer, as an example. And many organizations were DoSed entirely just from the proliferation, the spreading of SQL Slammer within their environment. So I personally believe that we will see a greater frequency of attacks. I mean, as I said when I started out here, you know, at this point, any third-world country with a grudge and an internet connection, you can rest assured, will be firing packets at the U.S. and others. Again, we have made it fair game with our admission that we developed this software, so I think it's an absolute. We will see some additional bandwidth from attackers coming at us here in the not-too-distant future.
 
Richard: And there is now a good historical example of collateral damage from cyber war, at least by my definition of cyber war, which was met when Russia sent tanks across the border into South Ossetia, you know, the breakaway state from the country of Georgia. And there were massive DDoS against the President's website, the President of Georgia's website. And it just so happened that, you know, a Georgian native-born person was visiting Tbilisi at the time, and she just happened to own a hosting service in Atlanta. So she said, "Hey, just, you know, repoint your DNS and move your site to our servers in Atlanta, we have plenty of bandwidth." They did that, and all of a sudden, you know, their infrastructure was getting hit with 60,000 requests a second, and it took down all of their hosting customers. So, all those guys were victims of collateral damage, and that was back in 2008.
 
Paul Henry: Oh yeah, in an age where we have seen 40 Gig of sustained throughput in a DDoS attack, you're not gonna filter your way around that.
 
Richard: Nope.
 
Paul Zimski: Right, right. Well, and I think sort of a final thought process here on what the potential impact is is that every time one of these attacks is really dissected and made public, it's an opportunity for general cyber criminals to really learn and adapt, and sort of up their game, based on what they've been seeing with these targeted attacks. So, the real issue here is just a general increase in sophistication across the board. That, you know, downstream from these weaponized attacks, the nation-state, the end user ultimately is gonna start seeing a more sophisticated and risky environment for themselves. Thoughts on that?
 
Richard: Yeah, just like, you know, cyber criminals are today running businesses, right, so they invest the minimum amount they need to get the return that they need. But as they see these more sophisticated attacks, they come to the realization that most enterprises are, in that, you know, your most valuable corporate secrets and your most valuable information is vulnerable to attack and being stolen. Once the cyber criminals start to think, "Hey, we can come up with the most bizarre scenario, targeting the greatest centers of wealth, and, you know, steal a lot of money if we just use this level of sophistication." So, I agree, they'll learn from this.
 
Paul Henry: Yeah, I've got to agree as well. I mean, again, if we look at the bigger picture here and look at the evolution, we'll say, of malware, and we go back a decade or longer ago, it was that 13 year old trying to impress his peers writing malware in mom's basement, you follow me? You know, cyber criminals came into the game, and we saw some absolute sophistication added to malware as the development of it was well funded. And now, we have nation-states in the game. I mean, come on, they print the money, okay? So funding for this has now become an afterthought. In many respects, a lot of us find ourselves out-manned, outspent and outgunned when it comes to defense.
 
And throughout all of this, over the last decade or so, we're using the same defensive mechanisms. They couldn't protect us a decade ago, you know, in a script kiddie level environment. Now we got nation-states in the game, yet many organizations have not adjusted their defenses to account for it.
 
Paul Zimski: Right, gotcha Paul. So, I think what we're gonna do right now is go to our second polling question. I'm gonna start a...
 
Richard: I got that up. So we're gonna poll, and basically, the question is, "How confident are you that your organization has the appropriate technology in place to effectively combat state-sponsored malware, and/or its derivatives?" Usual, A, "Very confident," B, "Confident," C, "Not confident," and D, "Unsure." ...I think everybody's learned to vote fast now, because I didn't give 'em much time last time...
 
I know that, you know, like Paul Henry, I travel the world and talk to clients, and things have changed so dramatically, really since RSA. But even before that, there was for instance, the activity on the part of enterprises to start doing their own malware research. I started seeing job postings for, you know, reverse engineers [inaudible 00:38:11]. And I'm scratching my head going, "Wait a minute, you know, that's the bailiwick of the antivirus vendors. They're the experts, you know, leave it to them. They create the products, and they protect the enterprises." Why do enterprises feel they have to do their own reverse engineering? And it's because they're under targeted attacks.
 
And now, I actually see them going the next step. They're engaging in the kind of back hacking, you know, that government agencies would do, or frankly, you know, we know Google did after the Aurora attacks, because they don't feel there's anybody they can turn to. There's no, you know, World Court or police, you know, or even cyber police that you can turn to and say, "Hey, somebody's infiltrating my organization. Here's the command and control server in XYZ country." So they go ahead and take over that command and control server, and sometimes they wipe out their documents that they find there. Sometimes they shut down the server.
 
Paul Henry: Yeah, it's scary in an environment where we still haven't learned to do effective attribution as well.
 
Richard: Yeah...So let's look at the results here. So we have 1% are very confident, once again, those must have been the people who are very unconcerned on the first question, because either they have extremely well segregated networks, or really, really good security. And they are, I would say, 1% of enterprises that should have a high confidence level. We've got 25% are confident, 63% not confident. Think that explains why there's so many people on the call.
 
Paul Zimski: Yeah. So, I mean, I think those numbers aren't surprising. And I think, you know, really where we are is going back to an understanding that there is no one technology that's gonna protect you. There's no magic bullet or protection layer that's just gonna stop all these attacks. They're blended, they're using unseen or previously unseen techniques, they're not necessarily targeting the network as a whole, or the enterprise as a whole. Sometimes they're just going after individual endpoints or laptops or people. There's a combination of physical and technological sort of access and attacks to...behind these scenarios.
 
And where we are is going back to saying, "Okay, we're back at risk management." We're back at saying, you know, "We are managing risk, and risk mitigation on an endpoint level." And we're going, "What are the technologies and processes, and how can we equip our people in a manner that makes it more difficult to carry out the targeted attack on us?" But there's no single technology that's out there. And, you know, every endpoint is sort of this autonomous enterprise of one at this point. If one of your endpoints gets compromised while it's out on the road, or mobile, or a USB stick is just plugged into it, it could be game over.
 
So being autonomous, having the layered approach, and ensuring that every endpoint is protected is where we are. And how do you do that with a limited number of resources, and an organization to protect? And I'll sort of open that question up to both of Paul and Richard.
 
Paul Henry: Well, to myself, automation is absolutely the key there. Again, we are finally, you know, we've moved up the OSI model itself. We all recognize that the application layer is a primary vector, and, you know, we're also realizing that putting all of our defenses on a gateway is a no-win situation. We really do have to move security, you know, back down to those pesky endpoints, okay? And it must absolutely be automated today.
 
Richard: Automated and monitored.
 
Paul Henry: Oh, yeah.
 
Richard: So, you can see what's, you know, the next level on that OSI stack is the user in the application. And, you know, we're gonna build, you know, trust blockers, I guess. So, we've done it at the gateway, we're gonna do it at the endpoint, you know, turn it around to a only run applications that we trust, but now we're gonna trust the users to use those applications, you know, honestly and correctly within the bounds of their job description. And of course, you can't do that. You'll have to apply controls at the application layer, too.
 
Paul Zimski: Right. So, when we look at what a layered defense looks like on an endpoint, one of the first and foremost, you know, things we have to consider and deal with is how do we remove the known attackable surface area on our systems? So what are the vulnerabilities that are out there, and configuration, misconfigurations that are out there that are making it easy for attackers to get their weaponized malware, or malware just in general onto our endpoints? And really, that goes back to one of the basic foundations of endpoint management, and that's patch and configuration management. That's saying what sort of processes do I have in place, and technologies do I have in place that I am ensuring that my operating system vulnerabilities, my native OS applications, and my third-party applications are all being patched efficaciously and across the board, so that as many of the opportunities that are out there that I know I can control are plugged up and people can't attack me. That's one of the...
 
Paul Henry: And of course, this layer's been so compromised by Flame. Now we have the additional worry, how do we know that the patch is okay?
 
Paul Zimski: Mm-hmm. Mm-hmm. And so things like, you know, when you compromise a digital certificate, then that becomes pretty tricky. We like to think that we can trust signed code if we trust the vendor that we think signed it. If we can't be confident of that, then it's, you know, it's game over.
 
Paul Henry: Yep, and Microsoft's addressed that by moving away from MD5, because so far, you know, the new hash algorithm they use, SHA-1, hasn't been shown to be as vulnerable. But, you know, I don't know about Oracle, and Adobe and, you know, all the other enterprise software vendors have [inaudible 00:44:59] . A lot of them are probably using MD5.
 
Paul Zimski: So, a second layer to consider on top of the patch and configuration management is there's a concept of application control, is is it time for organizations to start putting some bounds on what kind of applications, or what new pieces of software and code can enter their system? So, you know, is it signing a trusted ecosystem? There's challenges behind this, as far as some assets or some systems need to be quite flexible, and are subject to change in order for users to be productive on them. But other systems which are much more static, servers, workstations, kiosks, point of sale systems, have a pretty specific role in life. And they don't need to have new applications installed outside of regular maintenance windows, so there's an interesting opportunity, interesting layer for application control to play inside of the endpoint, but once again, nothing's gonna be a silver bullet, but this idea of multiple layers and multiple, interrupting multiple vectors is really where we need to be heading.
 
Keep building this out a little bit, and then I'll open it up for Richard and Paul to comment on, but, you know, hard drive and media encryption. This is a pretty much a no brainer. We wanna make sure that our data is as protected as it can be on the hard drives and removable media that it exists on.
 
Now, if your endpoint's compromised in run time, or real time, by a piece of malware, this might not necessarily protect the data that's on there, but it's definitely a good step for powered down offline systems, lost USB keys etc.
 
Device control. This is an interesting layer to consider, especially with the use of USB keys in some of the more recent attacks that we've seen, and, you know, you can put phenomenal physical security in place and have very sophisticated gateway security in place, so you think that it's pretty difficult to actually land a piece of code onto an endpoint that's protected, but what we've seen in some of these examples is that a simple USB key, you know, plugging it into a device is what's launching the malware, the attack, so it's an easy way to circumvent the traditional controls.
 
And then finally, antivirus definitely plays a role in protecting the endpoints. I think it's easy to sort of pick on antivirus, as saying, "Okay this is a blacklisting technology, or reactive technology that isn't stopping these new sophisticated attacks." But antivirus plays a role in the security stack on an endpoint. And really, the strategy isn't about what's the one layer that's gonna protect me from an attack, it's how am I managing and securing my endpoints on a day to day basis that mitigates risk for me, and that puts me at a level of acceptable risk for the asset, and for the criticality. And I'll open it up to Paul and to Richard, sort of comment on a layered or defense in depth approach to endpoint management.
 
Paul Henry: Sure, I agree it'll...go ahead Richard, I'll let you go first.
 
Richard: All right, thanks. So, I've just got a question. You know, I've heard it said before, and I might even be guilty of it, but why deal with all these layers? Why not just get, you know, an Apple product, and you don't have to do any of this?
 
Paul Henry: Well, bottom line is, there is no Holy Grail. And I could spend the next hour just talking about, you know, the Apple side of the house. You know, they got away with security by obscurity for many, many years. It's not always technology that drives the generation of malware. Popularity is a primary driver, and Apple is starting to feel the pain of that now. Again, they are subject to the same risks as anyone else, as they're now learning. But back on the layers, I just wanted to comment on that. You know, there is, again, no Holy Grail. There is no product that's gonna prevent an APT attack. There is no product that's gonna, you know, standalone block something like a Stuxnet.
 
Today, you absolutely have to approach it with layers, and those layers, again, not one, by and of itself is gonna be capable of protecting you from everything that can be, you know, thrown down the pipe at you today. You have to look at your layers of security as being nothing more than speed bumps in the road in front of the bad guy. If nothing else, as the bad guys traverse those layers, hopefully, you're gonna hear a little bit of a rumble off of the speed bumps, and that's gonna give you the ability to, you know, counter the attack that you're under. But again, relying on any one technology today is foolish from the defensive perspective. And for that matter, relying on solely on the gateway is a foolish methodology for defense. Again, I mean, look at RSA. They blew right past to the gateway with an email, okay? Any of the attacks to date, we have seen a failure, a failure of a primary layer.
 
And again, it's all about multiple layers today, and the multiple layers may in fact not stop the attack, but hopefully, the bad guy is gonna generate enough noise as he's coming through those layers that you will have the opportunity to afford some level of defense.
 
Richard: I'm thinking in terms of Stuxnets. You know, if these layers had been deployed at Natanz, the nuclear refining facility in Iran, I think of where, you know, you would have stopped Stuxnet, and certainly the patch and configuration management might not have helped, because they use zero day and they've used signed software. But certainly at the application control, there could have been some defenses there, and certainly at the reception point, with device control, you could have prevented USB tokens from installing the software in the first place. So they probably, if they had been doing all these layers, Stuxnet probably would not have been effective.
 
Paul Henry: Well again, I just think it's dangerous to claim any given technology could have prevented it. I mean, if we look at a bigger picture, it all tied back to the user in that specific case. So I guess if we simply eliminated the users, we could finally end this whole network security problem once and for all.
 
Richard: [inaudible 00:52:09]
 
Paul Zimski: Yes, exactly. So, you know, and I think what we're really keying on here, or talking about, is this concept of managing risk at a larger layer, or larger level, and that is that it's, you can't simply go and assess machines, put controls in them, and rely on technology. You have to understand, you know, that it's layered, and no one technology is going to defend you. But you also have to know what your business interests are.
 
So, you know, how important are these machines or assets to you? What information do they hold? And, you know, how does this overlie on top of your compliance initiatives? And looking at any one of these silos alone, you really aren't gonna get into this concept of risk management. You have to understand what's important to your organization, core to your business, the technology, the processes, and the people that are in place, and the goals are the [inaudible 00:53:13] of security that you're trying to meet. And thinking holistically, particularly on endpoints, which I don't think we necessarily do as a community as much as we do think about risk management for the overall organization.
 
And this is one of the major shifts that is going to be taking place from the way that we manage endpoints, that in the past, where it's, "Oh here, just update the antivirus software, make sure it's patched, and we're all good to go."
 
And I think of a final, or if not, maybe should have been the first line of defense, is employee education. You know, you can throw as much technology as you want in place at these, the problem of weaponized malware, but if you aren't educating your users, going back to the fundamentals of how do you ensure, how do you do risk management for an organization, it really has to start at end-user level. And this is another aspect to really go back and look into, from an organizational perspective. Don't just listen to your vendors trying to push whatever next technology that they have, that they say could have stopped Flame or could have stopped this or that. You've gotta go back to basics, back to the way that you're managing your organization, the way that you are educating your employees, and the way that you perceive and deal with risk as a whole.
 
And I'll open that up to Richard first and then Paul Henry, and then we may have a few minutes left for questions.
 
Richard: Yeah, just when it comes to awareness training, I'm a big proponent of actually training IT staff, because they're the super users, and the most knowledgeable, but if you expose them to hacking techniques and give them some of these ethical hacking training classes, that turns them into the paranoid security guys you want. Even if they're your developers and your DBAs, you want them all to be aware of, you know, some of the times, how simplistic it is or how these automated tools work in order to breach a system. And that gives them that level of paranoia they need to do their jobs.
 
Paul Henry: Yeah, I've got to agree again. You know, in my view, everyone needs to somewhat, you know, take a look at the bigger picture, step back and reassess what they've been doing for the last decade, and really think about how well it's actually worked out for 'em. You follow where I'm going with that? You know, it really does all start again with awareness training for your end users, you then build out the necessary policies to protect what you deem is worth protecting within your environment. And then you implement the necessary technical safeguards, to in fact make certain that that policy is in fact being enforced. But hey, if nothing else, you know, with what we're seeing today in weaponized malware, it absolutely is a wake-up call for the enterprise, and, you know, we really should perhaps revisit our overall security programs within our environments, and make certain that they are up to the challenge of today's threats.
 
Paul Zimski: Yes, yeah, exactly, Paul. And so, with that summary, I just want to, you know, thank everyone for being on this webinar, we do have additional information at lumension.com/weaponized. I think right now what we'll do is go to a couple of the questions that we have with the minute or two that we have left, and wrap up.
 
Richard: Yeah, a quick one probably, well for both of you, and that is maybe a tough one. What is the minimum that you can do to protect the enterprise from weaponized malware? In other words, you know, you've spelled out, Paul Zimski, a huge problem, and it looks like it's gonna take a lot of effort. But what would the minimum be? Or maybe it's easy to put it as first steps?
 
Paul Zimski: Well, yeah, I'll take a crack at minimum. You know, I do agree, if it's the absolute minimum low bar, I would say that it's a process and people issue that you'd have to tackle first. And that's going back to, you know, employee education. And it's not to say that employee education isn't very important, it's just saying if you're looking for the absolute minimum, minimal that will have a measurable impact, it's probably that.
 
From a technology perspective, it's really looking at what's in place. As Paul Henry described, you know, what are those speed bumps that you've put in place on your endpoints, on your systems as a whole, to make life a little bit more difficult for targeted attacks? And go back to basics, go back to fundamentals. Patch management, configuration management, just visibility of what applications are installed in your environment. Trying to go straight to the tip of the spear and say, "I'm gonna get the best darn, you know, detection and protection promise technology from a vendor that's gonna knock these things out of the sky," isn't gonna be as effective as really sort of circling the wagons, going back to the fundamentals, and really trying to mitigate risk wholesale.
 
Paul Henry: I've got to agree. Yeah, I'll jump in there real quickly here to close. You know, I have to agree. Again, I think one of our biggest failings over the last decade has been putting all of our eggs in a single basket. We tend to migrate to these, you know, Holy Grail, $100,000 boxes that can stop, you know, attack X, Y and Z. And, you know, they let us down each time.
 
It is critically important that we really take a holistic view of this, we go back and we revisit the basics, hardening the servers, keeping them patched and up to dated, ensuring that policies are being pushed out using your GPOs etc. in a Windows environment, so that we're all working off of the same page. You know, you've got a good base to start from, and then you begin applying additional technology layers above and beyond covering the basics. But again, over the last decade, we've skipped the basics. We've tried to put that Holy Grail solution out there, and man, we're paying the price for it now.
 
Richard: Well thank you very much, Paul Henry for that, and Paul Zimski, for leading us through the Lumension weaponized malware era that we are in. And it's really just the first of many topics, or many presentations that you'll hear over the next couple years about weaponization of software, because this is truly a new era. Thanks, gentlemen.
 
Paul Zimski: Thanks, Richard.
 
Paul Henry: Thank you.