Malware Counts – Shock, Yawn, or a Useful Reminder of Today’s IT Security Reality?

November 16, 2011 by Leave a comment

5 million new threats in Q3 2011!

This was one of the hot lead statistics from the Q3 2011 PandaLabs Report released at the beginning of this month.  Instead of pondering that number, I found myself pondering how the market reacts to that number as we move toward the end of 2011.  Shock? Knowing nod of the head? Yawn?

When I joined Triumfant in November of 2008, the world had entered that year with less than 1 million signatures according to Symantec’s Internet Threat Report series.  Those were simpler times.   In 2009, the number of new signatures exceeded the number of total signatures reported in 2008.  The statistics were sobering and captured the attention of the market as organizations began to internalize that the malware game had changed dramatically across multiple dimensions – volume, velocity, and sophistication.  Threats were also shifting from broad, opportunistic blunt instruments to targeted attacks, some written for a single target.  The term Advanced Persistent Threat moved from the MIC into the broader consciousness.

As we close out 2011, my impression is that the 5 million number by PandaLabs generates very little response and such numbers numbers no longer resonate.  Maybe these numbers have gotten large enough where they loose a sense of connection.  Maybe the numbers have been overused to the point that they no longer have any impact (the marketing bashers so prevalent in IT security will quickly form a line here).  Or maybe most right thinking people have seen the weight of evidence and have accepted the new threat reality.  Regardless, they appear to no longer capture the imagination.

What the numbers continue to say is that the world of IT security has changed dramatically and continues to rapidly evolve.  The numbers dictate that organizations need to be open-minded to new solutions and must stay nimble to keep up with this evolution.  For example, I think organizations now academically understand that the notion of the 100% shield is obsolete, but far too many have to emotionally accept that reality and take action accordingly.

The numbers also remind us of the relentless nature of the adversary, who never stop trying to broaden the always-present gap between offense and defense.  The numbers indicate that your defenses have plenty to do, so make sure that they are stood up and properly configured on every machine so as not to give the bad guys a beachhead.  There is no 100% shield, but you should ensure that your shields stop what they can.

The numbers reinforce the fact that you should expect to be breached.  Accept that there will be attacks written specifically to evade your shields and get to your sensitive data and IP.  Think beyond shields and have rapid detection and response software in place for those times when you are breached.

In the end, the only real number that is truly significant is how many breaches that go undetected and result in loss of revenue, loss of customer confidence, or loss of intellectual property.  All you have to do is read this very frank assessment of the cost of the RSA breach to know that the number “1” may be far more impactful than 5 million.

Filed under Endpoint Security Tagged with , , , , ,

You Need a Plan B for Endpoint Security

September 20, 2011 by 5 Comments

You need a Plan B.

Plan A in endpoint security is to prevent malicious software from infiltrating a machine.  Most of the software on the exhibit floor of any IT security show is Plan A software with the remainder aimed at identity management.  As the number and complexity of attacks steadily increase, the amount of Plan A tools deployed at any given site has gone up proportionately.  Every year brings out a new “it” Plan A product and another layer of shields.

In spite of all of this Plan A activity, the number of successful infiltrations is on the rise.  Malware detection rates vary from study to study, but if you are RSA, NASDAQ, Sony, or any of the scores of recent breaches you realize that the bickering over the numbers on these studies is meaningless once you are attacked.  Add targeted attacks and the Advanced Persistent Threat to the mix, and the picture is less than rosy.

You need a Plan B.  Plan B is not a difficult concept to grasp or justify.  It simply says that there are no 100% shields, no fool-proof Plan A.  It accepts the hard truth that motivated, well-funded attackers will infiltrate your systems.  Therefore, you need a Plan B to detect the attacks that evade your Plan A software and so you can take informed action based on that knowledge.

The “Verizon Business 2011 Data Breach Investigations Report”, Published May 2011 had two interesting facts that scream for the need for a Plan B:

  • 60% of the breaches they studied went undetected for over a month.  The bad guys had free access to internal systems for extended periods.
  • 86% of the breaches were discovered by an external party.  The organizations would have never known they had been breached if someone from the outside had not told them.

Don’t take for granted that you have not been infiltrated because your Plan A software has not detected the presence of an attack.  That is self-deceiving logic.  If the attack gets past the protection of Plan A it has already evaded the detection capabilities of Plan A.

Here is something else to consider:  most of the Plan A software are shields to defend the increasingly porous perimeter.  Successful infiltrations are obviously at the endpoint.  Furthermore, the shields are often concerned with the attack vector and not the payload.  Once an attack makes it to the machine, it is all about the payload.  So again, we are back to the need for a Plan B that has a different focus and methodology than Plan A.

Having a Plan B is not an admittance of failure or running up a white flag on the idea of prevention.  It is a prudent, pragmatic and necessary response to the current threat environment.  You need a Plan B that focuses on detecting successful attacks and provides the analysis necessary to take immediate and informed action.  You need a Plan B that is not tied to traditional techniques that rely on prior knowledge such as signatures.  Finally, you need a Plan B that lives where the attacks happen – the endpoint.

It all goes back to the opening line: You need a Plan B.

Filed under Endpoint Security Tagged with , , , , ,

Needle in a Haystack? How to Find an Unknown in an Ill-Defined, Shifting Maelstrom

March 18, 2011 by Leave a comment

In the March 17,2011, post, I demolished the “Finding a Needle in a Haystack” analogy by pointing out that in IT Security we don’t know what we are looking for (the needle) and our haystack is not a homogonous pile of hay but is instead a continuously changing, utterly non-homogenous population of one-off configurations and application combinations.  We went from “Finding a Needle in a Haystack” to “Finding an <unknown> in a <ill-defined, shifting maelstrom>”.

I ended by promising you a solution and that is where I begin.

The first step toward a solution is getting your hands around the “ill-defined, shifting maelstrom” that is your endpoint population.  To find what is unwanted or anomalous in that population, you first need a way to establish what is normal for that population.  You could build and dictate normal, and then enforce that normal in a total lockdown.  That is expensive and hard to do, and in my many travels, I have seen exactly two such environments.  The alternative is to monitor the machines in that population, and accurately create a baseline learned from the environment itself.  One that captures all of the exceptions and disparity in all of its glory.  The end result is a normalized, well defined representation of your ill-defined, shifting maelstrom.  A normalized haystack, as it were.

Easy, right?  Not really.  You have to remember that your target is unknown, so you have no idea where it will appear and in what form.  You must also consider that whoever is putting the unknown in your haystack does not want it to be found, and will so design the unknown to evade detection.  Zero day attacks don’t show up as shiny needles.  You can assume nothing; therefore, you must monitor everything as part of your normalized haystack.  You must also remember that the population shifts (wanted change) and drifts (unwanted change) by the moment, so you will need to keep it current.

In short, you will need continuous monitoring that is comprehensive and granular.  Not the kind the scanner vendors sell you that sees some of the machines in weekly or monthly increment, or the kind the AV vendors sell you that sees parts of the machine and not the entire picture.  You will need comprehensive and truly continuous monitoring.

In yesterday’s post, I noted that if you had a homogonous haystack you could remove everything that was hay and what is left should be the thing you are looking for, even if you do not know what that thing was.  Our haystack is not homogonous, but now we have created a baseline that provides the next best thing.  We can’t throw out the hay, so we need a slightly modified approach that uses changes to the machines as our potential indicators to compliance issues and malicious attacks.

If we are smart, we can use this approach to our advantage because once we establish our normative haystack we can continuously monitor the machines and identify changes.  This fuels our detection process and drives efficiency in managing the shift (we want to control the drift, but that is another post) in the population.  By capturing changes, we can keep the image of the population current with minimal drag on the endpoints and the network by moving changes across the wire.  No need to move large images when incrementally smaller change captures will do.

Once we identify the changes, we will need analytics that assess the impact of those changes to the associated machine.  These analytics will leverage the context provided the normalized model of the haystack to identify those changes that are anomalous.  Changes identified as anomalous are further analyzed to gauge their effect on the state of the machine and identify those changes believed to be malicious.  We can use the context and other analytic processes to group changes so that we see the malicious code and all of the damage done to the machine by the malware.

We have successfully identified the unknown in our ill-defined, shifting maelstrom, which, like I said yesterday, is infinitely harder than finding a needle in a haystack.  We did not just find the unknown, we have detailed its composition, analyzed the effect to the machine, and identified its path of destruction.

I think we are onto something here.  This could revolutionize malware detection, creating a detection capability that is agnostic to attack type, vector, and delivery.

But wait, there is more…

Filed under Continuous Monitoring, Endpoint Security Tagged with , , , , ,

The Nasdaq Breach Illustrates the Need for Continuous Monitoring

February 6, 2011 by Leave a comment

Dear Nasdaq, call me.  I am here to help.

The Wall Street Journal reported late Friday that Nasdaq had discovered that they had been hacked.  The hackers never made it to the trading programs, but instead infiltrated an area of Nasdaq called Directors Desk where directors of publicly traded firms share documents about board meetings.

What caught my eye was the following quote from the AP story filed about the attack: “…Nasdaq OMX detected “suspicious files” during a regular security scan on U.S. servers unrelated to its trading systems and determined that Directors Desk was potentially affected.”

People, people, people.  You have got to get on the continuous scanning bandwagon.  Seriously.

Connect the dots.  The story says that “the hackers broke into the service repeatedly over more than a year”.  Notice that the scans that found the suspicious files were “regular” meaning periodic.  Monthly? Quarterly?  How many of these regular scans were run before the activity was discovered.  I understand the need for network based, agentless scans.  I also know their limits, and deep down inside in a place most IT security people don’t want to admit, so do you.  “Regular” is not continuous.

Don’t stop yet, because the story says that the scan determined that the systems were “potentially affected”.  The diagnosis was partial because agentless scans, even credentialed scans, only get part of the story and therefore can only point out “potential” exploitation.

I have zero data about the actual attack and therefore am speaking in general terms.  But I am confident that a granular, continuous scanning tool should have been able to detect enough anomalous and exceptional artifacts on the Nasdaq servers to spot an attack like this.  The story says that suspicious files were ultimately discovered, so we know that there were persistent artifacts created by the attack.

This is a prime example of why you must have continuous, granular monitoring of endpoints and servers.  Periodic scans, while effective, leave too many blind spots.  A continuous scanning tool should have fond the artifacts.  And if the tool used change detection like Triumfant, it would have flagged the files as anomalous at a minimum within 24 hours of the attack.

Don’t throw the shield argument at me here.  These attacks went on for over a year.  Triumfant would have spotted the artifacts in 24 hours or less.  If you can’t see that difference and want to live the lie of the perfect shield, you are on the wrong blog.  In fact, if those files triggered our continuous scan that looks for malicious actions (an autostart mechanism, opening a port, etc.), Triumfant would have flagged the files within 60 seconds.

Regardless of which of our continuous scans would have detected the incident, Triumfant would have performed a deep analysis of the files and been able to show any changes to the affected machine that were associated with the placement of the suspicious files on the machine.  You likely could have deleted the word “potentially” from the conversation almost immediately.  I would also add that we would have built a remediation to end the attack.

Strong words for someone who has no details?  Perhaps.  But I would bet the farm that we would have found this attack in less than a year.

I don’t understand where we have arrived in regards to why organizations don’t implement continuous scanning.  Innovative solutions like Triumfant get throttled by old predispositions and the disconnect between IT security and the operations people who manage the servers and endpoints.  The security teams are forced to use agentless tools because the ops people refuse to consider a new agent, even if that agent is unobtrusive and allows them to remove other agents in a trade of functionality.  As a result, the IT security people to protect machines with periodic scans that cannot possible see the detail available when an agent is used.

Machines get hacked, the organization is placed at risk, countless hours and dollars are spent investigating the problem and then more hours and dollars are spent putting useless spackle over the cracks.  This is worth dismissing even the consideration of an agent?

Let me put it a different way.  We allows users to run whatever they want on endpoint machines, yet block IT security from deploying granular, continuous scanning tools that can actually detect attacks such as the one we see in Nasdaq.

What am I missing here?

Dear Nasdaq, call me.  Don’t rinse, repeat and be in the WSJ again.  I can help.  Promise.

Filed under Continuous Monitoring, Endpoint Security Tagged with , , , , , ,

Triumfant and Operation Aurora – Detecting the Advanced Persistent Threat

February 16, 2010 by Leave a comment

When new malicious attacks get a lot of attention in the press, we get asked the same question: “would Triumfant have seen that attack?”. Such is the case with the recent Google Attack, aka Operation Aurora. Given the discussions around the Advanced Persistent Threat (APT) and attacks like Aurora, I asked our CTO, Dave Hooks, to analyze the available data and provide details on how Triumfant would respond if Resolution Manager had been deployed on an endpoint machine or server that was exposed to this attack.   Dave’s response is illustrative of how Triumfant works in the context of an actual attack and how our unique capabilities enable Triumfant to detect an attack with characteristics common to those attacks seen in APT.

I offer Dave’s analysis with the full disclosure that it is based solely on detailed analysis of the attack, and that we had no firsthand exposure to the attack itself.  Dave broke his analysis into four parts: initial detection, diagnosis, knowledge base, and remediation, showing how Triumfant can identify an attack without prior knowledge, diagnose the attacks and correlate all of the changes to the machine associated with the attack, and build a situational and contextual remediation to return the machine to its pre-attack condition.

———-

Analysis of Operation Aurora

Initial Detection

Operation Aurora creates several service keys during three specific steps: execution of the dropper, the first stage of installation, and the second stage of installation.  Some of these keys are subsequently deleted but at least one is persistent.  The appearance of one or more of these keys would trigger the Triumfant agent’s 30 second scan cycle for markers of malicious activity, resulting in the agent requesting permission to execute a fast scan.  The Triumfant server would respond within seconds, green lighting the scan.  The agent would then capture the state of the machine immediately after infection and send the data to the server for analysis within 3 minutes.

Diagnosis

The Triumfant server would receive the snapshot, recognize that is was executed as a result of suspicious behavior, and immediately compare it to the adaptive reference model (the unique context built by our patented analytics).  The result of this comparison would be a set of anomalous files and registry keys.  The fact that the files and keys associated with Operation Aurora have random names would guarantee that they would be perceived as anomalous despite the fact that humans might tend to confuse them with legitimate Windows services.  Further analysis would then be applied to the anomaly set to identify important characteristics and functional impacts.  In this case the salient characteristics would be an anomalous service and a number of anomalous system32 files.

The discovery of an anomalous service would cause the Triumfant server to launch a probe requesting the Triumfant agent to explore the service further.  The probe would contain a list of all of the anomalous attributes found by the server during its analysis.  The Triumfant agent would activate a series of correlation functions to partition the anomalous attributes into related groups.  In this case it would group all of the anomalous attributes related to Operation Aurora.  It would then perform a threat analysis on this group and discover, for example, that it was communicating over the internet.  The results of the correlation and threat analysis would then be sent back to the Triumfant server.

At this point the diagnosis would be complete and the Triumfant server would alert the appropriate personnel that an “Anomalous Application” had been discovered and the data would be available on the console.  It would then be possible for an analyst to view all of the persistent attributes of Operation Aurora as well as the corresponding threat analysis, as well as readily share the data with CIRT and forensics teams.

Knowledge Base

An analyst can save the analysis for an Anomalous Application such as Operation Aurora to the Triumfant database.  This would allow the analysis to be converted into a new recognition filter.  Recognition filters have a number of benefits.  First, they provide a very precise mechanism for storing and sharing knowledge about an incident.  Second, they allow the system to search for any other instances of that particular condition in other environments.  Third, they enable the operator to pre-authorize automatic responses such as remediation should that incident be detected again in the future.

Remediation

If a Triumfant server detected Operation Aurora as an anomalous application, it would have sufficient knowledge of the anomalous attributes to synthesize a remediation response.  This remediation would be custom built to exactly match the attributes of the anomalous application on an attribute by attribute basis.  The ability to create remediations on the fly would enable the Triumfant system to surgically and reliably remove the components of Operation Aurora without reimaging the machine.  It would also enable follow on variants to be addressed without the need for new signatures.

———-

Again, let me state for the record that this is based on Dave’s analysis and not actual “live fire” data of our software responding to an actual attack.  But we are quite confident that Triumfant would have responded as described, detecting the attack and building a situational and contextual remediation.

Filed under Endpoint Security Tagged with , , , , ,

More Thoughts on the Advanced Persistent Threat (or Adversary) Discussion

January 29, 2010 by Leave a comment

Following up on my previous post about the Advanced Persistent Threat, I continue to enjoy the discussions that have emerged from the recent Google/China incident.  The past week has seen by far some of the best analysis of APT I have seen in some time.

One line of conversation has been about how APT, specifically the threat component, is not about malware.   Specifically, this addresses the positioning around by the antivirus vendors who continue to perfect their defenses around older attack forms - a process I call “Perfecting the Obsolete” – and look to defend market position by framing APT as malware.  In Mike Cloppert’s blog he notes in a post about the Google incident that the “defense industrial base has been pleading with the AV industry for innovation to address more sophisticated threats and detection resiliency for at least 5 years, likely longer”.  The A/V vendors will continue to characterize APT as malware largely because they have no effective answer, in spite of the wildly inflated claims of their love affair with recently acquired/developed whitelisting tools and prevalence data. 

Eventually the dialogue went to the suggestion (Threatpost blog entry by Scott Crawford and Nick Selby) that APT should be called Advanced Persistent Adversary, ideas similarly expressed by an Andy Jaquith blog post and a great post by Richard Betjlich).  I have no issue with that line of thinking, because I think the nature of the adversary is what has changed IT security so dramatically, not the attacks themselves.  The new adversary is organized, skilled, relentless, opportunistic, and enormously resourceful.  They are also patient, willing to invest time in research and planning to create breaches that get to the information they want without detection and hopefully opening up a long-term conduit for extraction.  Again, it is this change in the adversary that the traditional AV suites have failed to embrace. 

I also agree on the notion that the actual attack process does not have to be exotic or elaborate.  Why spend time going through the trouble of designing and engineering a zero day when there are numerous exploits created and widely deployed through production software?  The time and energy is better spent gaining information about how and what to attack and what to do when successful.  Which of course supports the APA notion: it is the advanced profile and skill of the adversary that makes these attacks so problematic, not the attack. 

Here is where I wade into danger.  The most common thread among of these posts is the notion that there is no one vendor-produced solution for APT (or APA).  Crawford and Selby warn of the vendor “easy button” and Rich Mogull notes on an associated blog entry that “Every vendor who tells me they can ‘solve’ APT instantly ends up on my snake oil list. There isn’t a tool on the market, or even a collection of tools, that can eliminate these attacks.” (emphasis from Mogull). 

We agree.  Let me state for the record that Triumfant is most certainly not a solution for APT nor can we eliminate these attacks.  What we do have is a tool that takes a completely different approach to detection, identifying changes at the granular level to trigger analysis.  And we think this approach has solid applications in detecting APT activities (or the work of the APA).

I will stop here hopefully short of pegging Mogull’s snake oil sensors.  Yes, I am a vendor and yes the company stands to benefit from using APT as a discussion point for selling our product.  But I have talked to enough people here in the DC area engaged daily against the APA that I understand that and effective method of anomaly/change detection is a necessary tool in detecting the work of the APA.  I will go deeper into our detection capabilities specific to APT in a later post.  Until then, I will continue to read the ongoing discussion with interest.

Filed under Endpoint Security Tagged with , , , ,

Why I Have Doubts About Whitelisting – The Reliance on the Carbon Based Lifeform

January 25, 2010 by Leave a comment

In 2009, we heard a lot of noise about whitelisting.  Whitelisting vendors and the companies that bought whitelisting products and added then to their suite have positioned whitelisting as the panacea of all of our endpoint protection problems.  The noise got so loud you would have sworn whitelisting would cure world hunger, end male baldness, and single-handedly wipe out the national debt.  Throw in the hoopla over community based prevalence data and it sounded as if we would never have malware on any endpoint again. 

I have been on record as a doubter of these magnificent claims, largely because the tools base a lot of their efficacy on one highly flawed component – the carbon based life form. 

Let me explain.

If you read the vendor’s own materials closely, whitelist and prevalence products cannot block bad things unless you lock down yourr endpoint environment.  I know there are some organizations that have such an environment, but they are certainly not the norm.  So for the rest of the world who are not locked down, these tools can only warn.  And who do they warn you ask?  The end user – the very person who got the machine into trouble in the first place. 

I have a very dear and old friend that told me something that has stuck with me for a very long time:  “remember,” he said with total authority, “half of all people are below average.”  (Note: If you find yourself either thinking too long about that last sentence or find it really insightful, please call your PC support staff and have your admin rights revoked.)  But cynicism is not enough to prove my point.  Luckily, a new study was recently released in the New York Times that provides some real insight into the mind of the end user. 

The article speaks to a study done by software maker Imperva that examined a list of 32 million passwords from RockYou (software for users of social networking sites) that was hacked and subsequently posted on the Web.  Imperva’s research on the data shows that one out of five people use easily hacked passwords such as “123456” and “password”.  I would submit that these types will be the first in line to get to places on the web that are dodgy or fall victim to social engineering.  Gartner analyst John Pescatore has some thoughts about this study from the viewpoint of passwords, but I think the study speaks to the bigger issue of having end users involved with security processes.

I do not think that it is a reach to believe that users who would pay so little mind to their passwords will blithely skate right past any warning from a whitelist or prevalence tool.  Why stop?  I clicked on it, didn’t I? After all, there is a free iPhone waiting on the other side of that warning screen. 

My cynicism is not just genetic – it is founded by years of hard-won experience.  In the 80’s I spent some of my formative years supporting some new wild idea called the Information Center where we placed user friendly (as friendly as any mainframe tool could be) tools into the hands of the end users.  Every Monday morning I spent the first hour of my day resetting scores of passwords of people who simply could not remember their password from the previous Friday.  And I knew easily half had it written on a post-it note on the monitor. 

If you need further proof simply get on any major road during the morning or afternoon commute.  In spite of warnings that texting makes you more dangerous on the road than being intoxicated to twice the legal limit, I spend my drive dodging people who are clearly engaged in critical text conversations.  Shoot, I saw someone this morning with the newspaper opened on their steering wheel.  If these people don’t care about their physical safety, why would we believe that they can be part of the security process on their endpoint computer? 

And there you have my doubts about whitelisting and prevalence tools.  It would be fascinating to do a study on the reaction of users to warnings from such tools to really support my point, and I am confident what the results would show.  After all the proof is all around us every day.  Just ask the 1% of people that use “123456” as their password.

Filed under Endpoint Security Tagged with , , ,

Antivirus Detection Rates Study Shows the Real Exposure to Your Organization

December 23, 2009 by Leave a comment

I came across a blog entry from Cisco regarding malware detection rates that I found quite enlightening. My intent is to draw it to your attention now and come back to discuss it in more depth after I have a chance to review the study further. The blog entry is called “The Effectiveness of Antivirus on New Malware Samples” by Kevin Timm of Cisco.

What I really liked about the study was the portion that showed the “detection over time” chart that captured the sliding risk as new attacks are assimilated into antivirus offerings. One of the critical differentiators of Triumfant is the ability to detect malware without any prior knowledge of the attack. This graph shows how much coverage gap exists for a new attack and how long Triumfant would be standing as the first line of defense against the attack.

Posts to our blog that deal with antivirus detection rates such as “Antivirus Detection Rates – It is Clear You Need a Plan B” are consistently the most viewed entries, so I thought this study would prove a popular read.

Filed under Endpoint Security Tagged with , , ,

Security Fails of 2009 – Conficker Becomes a Media Darling

December 16, 2009 by Leave a comment

Today is my third in the series of Security Fails of 2009.  As 2009 draws to a close I think no one would argue that this has been an extremely eventful year for IT security.  While others will soon be trotting out their “best of 2009” lists, I thought I would instead visit some of the prominent fails of 2009. 

Conficker made the jump from malware attack to media darling in 2009, finding its way onto the front page and 60 Minutes.  For those of us who work in the general anonymity of IT security, Conficker (aka Downup, Downandup, Conflicker, and Kido) was one of those things that took on a life of its own and rose quickly into the public consciousness.    

To be accurate, Conficker actually surfaced in November of 2008, but its effect really peaked in 2009.  The Conficker Working Group estimates that 9 million to 15 million PCs are infected with the worm.  Costs have been placed at a wide range of numbers with some estimates reaching $9B.  The worm was noteworthy from its use of sophisticated techniques to avoid detection and its ability to morph via commands from a well designed command and control process.  It has been through three iterations, each making it harder to detect and defeat.  It spread rapidly – in May it was reported to be spreading to 50,000 new machines a day - and is widely believed to be the largest worm infection since Slammer in 2003.   

What became almost humorous was the effect it had even when it did not do anything.  When the command and control elements of Conficker would stir, there was rampant speculation as to what it would do.  Conficker appeared to be readying for something big on April 1 and the speculation became somewhat comical as predictions ranged from minor attacks to global Armageddon. Eventually people became to see Conficker in every shadow, with the paranoia coming to a crescendo when Conficker was suspected as the cause when Big Ben stopped just before midnight on March 31.  I wrote then that such blame “makes sense – build a worm, get it distributed to millions of computers worldwide, have it confound the best and brightest of IT security, and then instruct it to stop Big Ben.”

The real lessons of Conficker are many.  First, the worm took advantage of an exploit that Microsoft patched in October of 2008 and many noted that the infection vector was not exceptional, just opportunistic.  The fact that it spread so rapidly and continues to spread illustrates the issues we have in patch management and maintaining the security readiness of endpoint machines.  In spite of all research and recommendations, business and government agencies still take far too long to close well known, dangerous gaps in their security.  Second, the sophistication of the worm, the command and control structure and its evolving nature all are illustrative of the growing sophistication of malicious activity.  Conficker is an attack with the careful engineering of a commercially available application.  Third, the traditional endpoint protections have long been left behind by the growing sophistication of the current attacks.  It took far too long to come up with a viable detection process for Conficker, and even longer to come up with a fix.  Most have to re-image and start over at enormous costs when one considers 9M computers.

Finally, Conficker brought IT security issues to the masses.  Lots of people that never considered the security readiness of their PC began to ask some serious questions.  The size and scope of the infection woke people up to the enormous potential of a mass attack.  And the sophistication was instructive to the public as to how malicious attacks have evolved from the days of the Anna Kournikova virus.   

Conficker is a noteworthy fail because it all started by leveraging a known exploit that savvy malware writers saw as an easy path to a significant infection that will cost the world billions of dollars.  Best of all, Conficker is still out there on a very large number of machines.  Even in its most benign state, the fact remains that someone controls a huge botnet that has the potential to be used for harm.

Filed under Endpoint Security Tagged with , , , , ,

Why Bad Things Happen to Good Endpoints

November 12, 2009 by Leave a comment

I was with a prospect the other day and was asked what, at least for me, was a very thought provoking question.  We were discussing the two major areas of application for Triumfant – continuous enforcement of security configurations and real-time malware detection and remediation – and he asked why you would need the latter if the former was done properly.  In other words, if all of my endpoint protections are in place and everything is properly configured, why am I still getting attacked?

Simple and logical question, right?  But it led me to think long and hard why attacks happen at a very elemental level.  We in security face this question from the powers that be because they cannot understand that attacks still come even though we have added multiple layers of defense. 

After consideration I came up with three reasons.  For perspective, my reasons are very much endpoint centric and presume the attacks have already made their way through protections on the network level, so this is not a cloud to ground holistic view.  Each reason is based on the assumption that the preceding reason(s) have been fully addressed and the represented gap is closed – each reason stands on its own as a problem.  And I will resist the urge to plug in how Triumfant addresses each gap, but I have noted blog entries that do if you care to read on.

Here are my three reasons:

  1. Attacks get through because the machines and the protection software deployed to protect them are not configured to be secure.  The analogy is simple: the most well designed and secure deadbolt lock only secures a door when the deadbolt is engaged.  Too frequently, endpoint protection tools are either improperly installed or improperly configured to perform the tasks for which they are intended, so attacks make it through.  For how Triumfant addresses the configuration management gap see “A New Approach to Configuration Management”.
  2. Attacks get through because traditional endpoint protection tools miss known attacks even when there is a signature for that attack and the protection is properly configured.  The failure rate depends on whose statistics you chose to use, but Gartner puts the detection failure rate at two to ten percent while other studies show failure rates exceeding fifty percent.  Given there will be well over 5M signatures by the end of 2009, ten percent is non-trivial.  See “Antivirus Detection Rates – It is Clear You Need a Plan B”.
  3. Attacks get through because they have been carefully designed and engineered to evade traditional endpoint protections.  These include zero day attacks, rootkits, targeted attacks and the work of the maliciously intended insider.  Zero day attacks are more generic in nature and broker on the fact that most tools require prior knowledge to detect an attack.  Targeted attacks are designed to specifically infiltrate networks and applications to retrieve sensitive information or financial data.  See “It is Raining and You Will Get Wet”.

I am not saying this is groundbreaking thinking here, but if you put things into this perspective, it clearly defines the gaps in protection and subsequently provides a roadmap of what must be done to protect your endpoints.  Reducing the attack surface is clearly not enough.  Antivirus is not getting it done – even the AV vendors say so.  And the bad guys are relentless in their pursuit to exploit any crack in the defenses. 

So what do you think? Too simple or simply brilliant?

Filed under Endpoint Security Tagged with , , , , , , ,

← Older posts

Follow

Get every new post delivered to your Inbox.

Join 439 other followers