RFIs – You Don’t Know What You Don’t Know

RFI’s drive me crazy.

First, I think the concept is a Gordian knot.  I need to learn about something I do not know.  I will learn by asking questions in a static, rigid format.  Okay, but if you don’t know about something, how can you hope to ask the right questions to get the information you need, or hope that your questions don’t inhibit receiving the real information you need, which you don’t know you need because you don’t know.  You don’t know what you don’t know, so how do you expect to ask questions so you will know.  See – Gordian knot.

Second, the amount of bias is staggering.  I will ask people who have a vested interest in swaying my thinking for the answers I need.  I will ask the vendors.  The vendors that are in a daily dogfight in a crowded and often confusing market where every vendor tells much the same story.  Vendors that hold Maslow’s proverbial hammer and will therefore put every answer in the context of the nail for which their hammer best drives.  Vendors that know before you ask that the answer to every RFi or RFP question is – surprise! – yes.  Vendors that are on commission for heaven’s sake!

Well, Jim, why wouldn’t I ask the vendors?  They are most helpful.  Some offered to actually write the RFI for me.  I see your point and that seems perfectly reasonable.  It frees you up to interview foxes to watch your hen house.

What really frustrates me about RFIs is the lost opportunity to get exposed to truly innovative solutions that the organization could actually use to fill very real gaps in their IT security.  Why?  because most RFI writers don’t know what they don’t know and therefore ask questions about what they do know: the same tired technologies that are at the heart of the very gaps that need to be filled.  RFIs are written from the sound bites from analysts and vendor web sites and industry pundits.  So what comes back is the same tired answers and nothing new is discovered.

You don’t know what you don’t know.  But what you do know is your problem, and that is where you should start.  You may not be ready to admit it publicly, but you know what gaps your organization has.  You know malware is getting past your shields, and you know that you are not equipped to know when and where. RFIs should not use vendor terminology or be bound by the solution de jour.

Write your RFIs to real, unfiltered gaps and problems, and provide a framework for vendors to provide solutions, but stay away from pre-dispositions.  Doing so will quickly sort marketing speak from real, innovative technology that is not more of the same.  Questions should be heavy on detail about the problem, but not have artificial fences or filters as to how the problem can be solved.  Old assumptions should be abandoned, because those assumptions were largely forged about attacks and attack techniques that have evolved exponentially and have shattered those assumptions.

Tell me your problem and open your mind to the answer.  Am I biased about my product?  You bet I am.  But give me the opportunity to honestly (yes, there are more honest vendors out there than you may think or have been led to believe) provide you alternatives that you may not have even heard about, much less considered when writing the RFI.  You may be surprised what is out there.  After all, isn’t that the point?

That is all for now, as I have some RFI’s to compete.  Let’s see. Question 1…(thoughtfully pondering)…”Yes”.

The American Airlines Phishing Attack – Front Row Seat to the Psychology of an Attack

Today I came face to face with the phishing attack and was able to watch firsthand as the attack worked on the human element of IT security.  This morning I contacted by a friend who had received an email that confirmed the purchase of a flight on American Airlines.   The friend was now convinced that a credit card had been compromised and that immediate steps were necessary.

Savvy IT security guy that I am, I immediately smelled a rat and asked that my friend (who lives close by) bring the PC with the email to me.  After all, I did not want potentially malicious stuff on my machine.

Sure enough, everything about the email spoke of fraud.  The appearance and format of the email was not even close to looking like a professional email from a large company that does lots of business online.  The email address was suspect, and having been on an airplane or two (or a thousand), I noted that the flight number was not even close to the American Airlines flight numbering system.  Lastly, there was the ubiquitous .zip file attached, just waiting to be clicked.  An example fo the email can be found on the American Web site here.

What was an interesting study was the reaction of my friend to all of this.  I have had a credit card stolen so I knew it was not the end of the world.  I also knew that the credit card companies actually handle fraud pretty well, so every second did not really count.  My friend was very nervous about the credit card being used to buy all manner of unseemly things all the while laying waste to credit ratings.

But most of all, I noted that the .zip file hung like a ball of yarn in front of an over-caffeinated kitten.  My friend so wanted to click on that file.  The psychological pull was palatable.

I walked my friend through the process of recognizing such an attack, and went to the American Airlines web page to demonstrate that the flight number on the email did not exist.  In fact, it was a digit longer than the field on the site for the flight number status.  Next I listened as my friend called American, and then the credit card company.  Both verified that no transaction had occurred and that this was part of a wide reaching scheme.  The American agent actually spent a lot of time walking my friend through the phishing concept at a high level an provided steps on how to dispose of the email without releasing the malware.  I was impressed.

I had several takeaways from the experience.  First, while the attack seemed amateurish and hackneyed to me, I was taken by how quickly my friend swallowed the hook and was quickly prepared to react.  The simple psychology involved was brutally effective, and I saw why such attacks succeed.  If a wide enough net is cast, someone will react the way the bad guys want.

Second, it reinforced the critical nature of the human element in IT security.  My friend is bright, educated, and computer savvy.  Yet that same person immediately and kinetically reacted to what was a cut-rate phishing attack.  People will always be the X-factor in IT security whether it be opening .zip files, shutting off their AV software, or gleefully inserting USB devices from any and every source.

Lastly, the experience screamed for the need for Rapid Detection and Response, because in spite of shields and protections the human factor can be leveraged to bypass or evade those protections.  Stuff gets through, and in front of me was a simple example of how.

I have to go, I just received another email from another friend who says he just got a confirmation for a flight to Atlanta he did not buy.  Seriously.

iPads, Angry Birds, and an IT Security Christmas Shopping Recommendation

One of the interesting phenomenon about working in the computer industry is that people will ask your guidance when considering purchasing anything computer related, including smart phones and tablets.  It of course matters not to them that your job responsibilities are not related to that part of the computer industry.  They are buying a piece of technology they do not understand and you are the closest thing to a lifeline that they have, especially during the Christmas season.

I find in such occasions that people ask about devices rather than about purpose – Nook, iPad, Kindle Fire.  I responded by asking them about what they wanted the device to help them do – what is the third level of why behind considering the device.  More times than not, that question is met with a confused gaze and a shrug.  My best guess is that this person has fallen for the marketing hype behind the device rather than fitting function to need.  The iPad is a great tool, but I know plenty of people who have their up for sale because they found it to be either less than they expected or a very expensive platform for Angry Birds.

The funny thing is that when I try to help people think their question through they sometimes become a bit put off at me because they have emotionally sold themselves on the device, often irrespective of that device’s real ability to perform useful tasks that would justify the purchase.

I see the same thing in the security market as new “it” (silver bullet) technologies come and go.  Executives read the magazine in the airplane seatback, see some well-turned advertising, or get swept into the analyst hype cycle.  They conclude that they need the new bright shiny object to (choose one or more)

  • Make them “more secure”
  • Protect them from the advanced persistent threat
  • Shield them from the Cybergeddon (actually taken from a Web Site)
  • Lower cholesterol, cure male pattern baldness, and end the common cold

My advice is to decide what it is you need from a security product, and then evaluate products against that need.  Whitelisting has been getting a lot of hype these days.  I have been at organizations where whitelisting is a perfect fit for their culture, their security philosophies, their staff, and their relative threat profile.  And I have been to organizations where it is easy to predict that whitelisting will not be a success for many reasons unrelated to the product itself.  I will also tell you that at many organizations, even a fabulously successful implementation of a perfectly good whitelisting tool will not ultimately fill the real needs of that organization.  And no, this is not a whitelist bashing as I could have chosen any number of technologies.

This is not, as they say, rocket surgery.  Step back from product hype and ask yourself what you need.  Determine your areas of risk – the gaps in your security.  Examine broader approaches to filling that need.  Only then should you begin to look at products within those broader approaches.  Steel yourself against the marketing hype of the latest bright shiny object and focus on what you want the tool to do. Don’t buy the latest bright shiny object and try to bend your problems to that product – the results will be predictable.

Don’t get me wrong – I am sure Angry Birds on an iPad is a great experience.  But budgets are tight, the adversary is relentless, and resources thin.  Shop wisely.

Exhibit Hall Hard Truth – Buy One of Everything and You Will Still Be Breached

This week I spent the day at a table at an exhibit hall at a conference.  Traffic was light in the exhibit area and it gave me a lot of time to think, which is often dangerous.  The show is was one of egalitarian exhibits where everyone gets the same six foot table, so there was no little vendors being dwarfed by massive booths with overwhelming A/V systems and elaborate staging.  Mostly pop-up banners and table covers.  The somewhat equal playing field allowed for some interesting observations and one important epiphany.

First, IT security is the land of really bad company names.  I won’t call out any here.  But, really?

Second, if it were your first time in an exhibit hall how could you possibly come to any rational conclusions?  Every booth seemed to promise the same thing and share the same set of bulleted claims to the point that I think you could have randomly redistributed banners and most booths would have not missed a beat.

Finally, I was struck by the fact the emphasis on prevention and the pursuit of the perfect shield is really sending a very loud message if the attendees were willing to see the forest for the trees. Of the 50 tables at the show, 47 were about preventing attacks, 2 were consulting shops, and one, Triumfant, was about detecting breaches.

Notice I said breaches.  I realize that everyone talks about detecting attacks as the recognition needed to prevent attacks.  Triumfant is distinguished in that we detect successful attacks – the ones that get through the defenses.  Therefore, we detect breaches.

And now for the epiphany: shouldn’t the vast number of prevention solutions and all of the noise really tell you something about prevention?  If shields are working so darn well, then why do we have hundreds of shield solutions in the market?  Why does your endpoint solution (AV vendor) continuously have to add layer upon layer of new technology?  Why are you neck deep in the spent shell casings of silver bullet technologies that will finally provide you with the 100% of myth and legend?

Repeat after me: Attacks get through your shields.  Attacks get through everyone’s shields.  You have been breached.  You can buy every prevention product on the market and you will continue to be breached. And no, this is not all about exotic targeted attacks and the advanced persistent threat.  Sometimes it is just basic, opportunistic malware that gets through.

It gets worse.  You are not prepared.  You do not have the tools in place to detect a breach.  The Verizon Business Data Breach Investigations Report showed that you will only find it yourself 6% of the time.  You are unprepared to detect successful attacks, yet you continue to shop for silver bullets instead of facing the hard truth.

I am talking about the ability to detect a breach within minutes of infection, alert the proper personnel, and return detailed actionable information. If you choose wisely, you may even get a solution so sophisticated that it can build a remediation for the breach, stop the malicious software, and repair the machine (including collateral damage) also within minutes of the infection.

My big takeaway from my time at the shows was really quite simple: the noise and confusion of the security shows and the broad infosec market is actually telling you something if you step back and listen.

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

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.

Nitro, Duqu, Poison Ivy, Video Proof, and the Advanced Persistent Threat as Industrial Espionage

In a recent post, Duqu Enables Stuxnet Level Complexity Against Commercial Targets, I made the case about the advanced persistent threat in the context of commercial targets and industrial espionage, specifically in the wake of the Duqu attacks.  I also went on record as saying that Triumfant will detect the Duqu attack, but, in fairness, I offered no real proof of that claim.

Then along came news about Nitro.

On October 31, Symantec release a whitepaper about a new attack called Nitro that initially focused on human rights organizations and then moved on to the auto industry and then to the chemical industry.   According to a story about Nitro on eWeek.com: “At least 48 companies are believed to have been targeted across various industry verticals, including 29 companies involved in research and development of chemical compounds and companies that develop materials for military vehicles. The other 19 were in other sectors, including defense.”

Symantec reports that the purpose of Nitro was to collect information, specifically intellectual property that could be used for competitive advantage.  That would certainly seem to fit under the definition of industrial espionage.   The attacks collected user IDs and passwords to sensitive systems so they could be accessed for later attacks and exfiltrations.  Which is exactly the case I made about the significance of the Duqu discovery.

The Symantec report also stated that Poison Ivy, a product available off the shelf to create Trojans and other malware, was used to created Nitro.  Which leads me back to the claim that Triumfant could see Duqu.  I made the assertion that Triumfant would see Duqu based on a study of the analysis provided about the attack.  I am quite confident, and other technical people in our organization are quite confident, that Triumfant would detect Duqu, but I had no proof as I do not have the attack to test.

In the case of Nitro, I know for certain that Triumfant has successfully detected malware created by Poison Ivy.  Third party testers have used Poison Ivy to validate the efficacy of Triumfant and we passed when other tools failed.  We use Poison Ivy to test internally.  And I can offer proof – a video demonstration where we infect a machine with Poison Ivy we created and show Triumfant detecting and repairing the attack. You can watch the video here.

Obviously I take no satisfaction in hearing about a successful attack like Nitro.  I do think that Nitro reinforces my position that the advanced persistent threat can no longer be treated as a problem for the NSA, CIA, and the DoD.  Commercial organizations ate at risk and must take stapes to put solutions in place that will provide rapid detection and response to these threats.

I will be shamelessly opportunistic to leverage the fact that Nitro used Poison Ivy to add credibility to the ability of Triumfant to see the attacks that evade other defenses.  This time I have video proof.

The Emotional Barriers to Embracing the Presumption of Breach Doctrine

Every day, another breach.  For every breach story we read, what would you guess is the number of known breaches that do net get reported? 1? 5? 100?  Then there is the big unknown.  The “you don’t know what you don’t know”.  How many breaches are there that will go undiscovered for yet another day?  I have used the following numbers from the  Verizon Business 2011 Data Breach Investigations Report (published May 2011) times: 60% of breaches go undiscovered for a month or more and 84% are discovered by someone outside of the organization.

I witness a very interesting response to the inescapable reality of today’s IT security environment every day from a somewhat unique position.  How Triumfant works and what it does requires organizations to make the fundamental recognition that attacks are getting past their shields and therefore they are getting breached.  In the overwhelming face of the available evidence this would seem to be an easy and completely defensible position for any organization to take.  Yet I consistently see a resistance that seems to be rooted in emotion rather than reason.

As Commodus put it in Gladiator: “It vexes me. I’m terribly vexed.”  So much so I have thought long and hard about the emotional side of this problem and have come to what I think are interesting and valid conclusions.

First is the inability to let go of the notion of full protection against attack and embrace the “Presumption of Breach” doctrine.  It is far more comforting to have 100% faith that your shields will protect your systems without fail and without regard to the attack or attacker. Everyone wants to be protected, and is far more comfortable thinking about prevention versus detection.  When you have spent 20+ years building walls and feeling protected (albeit a false comfort) behind those walls, a conversation about breaches rocks that world profoundly.  Another paradox is that the more organizations are in denial, the less likely they are to have detection capability, which means they won’t know they have been breached, which only feeds their denial.

The IT security market feeds on the myth of the 100% shield and continually sells the next layer to organizations with the promise that this time, THIS TIME, we have the answer.

If an organization faces the uncomfortable reality that they have been breached, then there is an emotional backlash: “How could this be?  My IT security team assured me we were protected!  My vendor partner also assured me we were protected! Who is to blame?”  The problem also cuts across personal boundaries to the heart of the reputation and job security of key people in the organization, because assuming that the organization has been breached creates the misconception that someone has to be at fault.

Let’s address these backlash issues directly.

This is not the fault of the CSO/CISO or the IT Security team, nor have these people failed the organization.  They are up against a motivated, organized, and relentless adversary who benefits from the advantage that offense always has on defense.  A motivated, well-funded and patient adversary that wants to target a specific network for a specific organization is really hard to stop.  The roster of recently breached organizations is a who’s who of the most sophisticated and disciplined security practitioners on the planet.  If they were breached, why would your organization be different or exempt?  Doing the prudent thing and putting a solution in place to detect breaches and provide a rapid response is not an admission of failure by IT security.

This is not the fault of the shield software in place.  At least not completely. There is no 100% shield and in spite of vendor claims there is no silver bullet.  If you bought a shield product believing to be 100% effective, then the fault is yours.  Embracing the cold hard fact that every shield can be evaded is the first step toward progress.  This logic also applies to the notion that getting breached does not imply that the person who bought the shields failed.

This is not the fault of IT management.  Pushing through a new tool that detects successful breaches may raise all manner of questions to the executive level and the board who likely received assurances that the necessary shields were in place.  Breaches now bring reputational risk that could negatively affect consumer trust and even business valuation.  Getting breached is a business risk as well as a security risk, and executive management and the board must be educated accordingly.

This is not going to happen to our organization.  Hope is not a strategy.  Neither is denial.  There are two types of organizations: those who know they have been breached and those who don’t yet know.  The Advanced Persistent Threat is not just a problem for the DoD or the NSA.  The recent Duqu attack is yet another wake-up call that organizations can no longer gnore.

Uncomfortable realities are, well, uncomfortable.  But they are reality nonetheless.  Organizations need to embrace the reality of the moment, get past the emotional objections and associated finger pointed, and face the challenges that this new reality brings.  You will get breached.  Attacks will evade or get past you shields.  You must have a tool in place to perform rapid detection and response to those breaches.

Sayano-Shushenskaya Accident A Model for What a Duqu/Stuxnet Combo Could Mean

On August 17, 2009, a 900 ton hydroelectric turbine was torn from its moorings at the Sayano-Shushenskaya hydroelectric power plant and dam in Russia.   The 900-ton unit actually lifted high enough (40-50 feet) to crash into the ceiling of the turbine facility.  The accident ultimately cost 75 people their lives.  Every one of the ten power generation units in the plant was damaged, some irreparably.  The 6,500 MW power station will not return to full capacity until 2014.  40 tons of transformer oil was released into the surrounding ecosystem, killing an estimated 400 tons of trout in two fisheries.  Untold hours of production capacity of surrounding businesses were lost due to the interruption of power to the area.  You can get a full picture of the event from a DOE presentation.

Before picture of the turbine generator hall of the Syano-Shusenskaya Plant

Before picture of the turbine generator hall of the Syano-Shusenskaya Plant

In my last post I defined how Duqu is a notable shift in the malware game, most notably as a precursor to carrying out Stuxnet level complexity attacks without the need for human intelligence gathering.   The ability to potentially affect and disrupt industrial controls in turn creates the potential for industrial blackmail and potentially cyber-terrorism.

For the record, I abhor peddling fear and in my time in the IT security space I have never used that tactic, and I am not using it now.  I do think what I described is a very real threat that is at our doorstep right now.  Duqu rang the doorbell.

I spent Wednesday at the SINET 2011 Showcase put on by the Security Innovation Network.  Triumfant was honored to be recognized as a SINET 2011 Innovator at the event, and General Keith Alexander, the Commander of the U.S. Cyber Command gave the closing keynote.   General Alexander used the Sayano-Shushenskaya accident in his talk, and it immediately struck me that the General had provided me with the example I needed for this conversation.

Post-event view of the turbine generator hall.

The Sayano-Shushenskaya plant had been a place of historical operational problems, and the specific turbine (Turbine 2) at ground zero of the accident was particularly problematic.  The turbine had a history of vibration issues that kept it from safely operating at capacity, and a new vibration controller had been installed in 2009.  This controller was offline on the fateful day when another plant experienced problems and Sayano-Shushenskaya was asked to raise capacity to make up for the shortfall.  When the load on Turbine 2 was increased, vibrations steadily increased to over 5 times the load limit, and the structural integrity of the unit ultimately failed.

Back to Duqu.  Introduction of Duqu into the Sayano-Shushenskaya would gather the data needed on not only how to infiltrate the plant systems, but where the plant was most easily compromised.  Hacking into maintenance records would readily pinpoint Turbine 2 as the weakest physical link.  The keylogging capabilities could gather the necessary access to the industrial controls of the plant, including the vibration control process.  The bad guys do not need human intelligence from the plant – Duqu provides all the data they need.

The information to disable energy production in hand, a Stuxnet level attack can be written to infiltrate the industrial control systems of the plant.   The low effort approach would be to disable the vibration control system for Turbine 2 at a time when peak capacity was required and wait for the failure.  A more aggressive approach could actually manipulate the demand on Turbine 2 to force it to run beyond established limits and, with the disabling of the vibration control system, guarantee an event on demand.  This is no different than what Stuxnet did to the centrifuges in the Iranian nuclear sites – it made them spin beyond operational tolerances and destroyed the devices.  The difference is that this attack sends a 900-ton turbine structure 50 feet into the air.

NOTE added 11/18/2011:  Since this post went public on 10/28/2011, it was reported that a water plant in Springfield, Illinois was impaired when the SCADA industrial controller from a water pump was hacked and manipulated to damage the pump and render it operational.  The hackers simply turned the system on and off until the pump overheated and burnt itself out.  Details can be found at Krebs on Security and on Wired.

Too much physical destruction for you to consider?  How about infiltrating the industrial controls of a pharmaceutical company and changing the machines that control the flow of ingredients.  No explosions, no floods, no fires.  But a disturbing bit of potential terrorism.  And not just an Advanced Persistent Threat stealing intellectual property.

Now do you see the connection? Was that the doorbell?

(Triumfant has gone on record as saying we would detect Duqu and would be able to stop the attack before it collected the data it seeks.)

 

Duqu Enables Stuxnet Level Complexity Against Commercial Targets

In my opinion, the recently discovered Duqu attack is more significant on a broad scale than the discovery of its predecessor, Stuxnet.  I think Duqu will force a much broader re-examination of IT security philosophies, particularly those commercial organizations that felt removed from Stuxnet grade attacks.  Duqu is the clear wake-up call that no one should feel immune from the Advanced Persistent Threat or well-crafted, targeted attacks.

Those who have investigated Stuxnet have noted that there was a tremendous amount of intelligence required to make Stuxnet so effective in disabling the Iranian nuclear program. The nature of this intelligence led investigators to conclude that humans were the source for this intelligence.  This finding was significant because the need for human intelligence gathering was obviously a limiting factor for even the best organized and well-funded cyber criminals to successfully launch an attack of that level of complexity and reach.

Duqu is evidence that the adversary is developing tools to automate the intelligence gathering process.  Duqu is designed to infiltrate the same industrial control systems as Stuxnet, gather information for 36 days, exfiltrate the gathered data, and then destroy itself.  One of the programs eventually activated by Duqu is an infostealer that is used by the adversary for “enumerating the network, recording keystrokes, and gathering system information” (according to the Symantec analysis). Even the 36-day window is designed to bridge the 30-day password change requirements in place for many organizations.

All of this information is collected and sent to the command and control site before the attack destroys itself.  The collected data provides the adversary the information needed to penetrate the intended victim’s network and the insight needed to build the malware to perform the intended purpose. It demonstrates a patient, deliberate, and calculating adversary that is willing to write a sophisticated piece of code to gather information to maximize the second wave of the attack to reach the attacker’s ultimate end game.

If attacks like Duqu succeed in eliminating the need for human intelligence gathering activity, then the game changes.   While Stuxnet was a leap forward in malware technology, you essentially had to be a nation state with human intelligence operations or at least an organization capable of somehow accessing such information to implement the attack.  If attacks like Duqu can gather that intelligence through automated processes, then the barrier for entry (human intelligence gathering) is greatly reduced or eliminated, allowing a lot more bad guys into the game.

I don’t deal in fear – never have.  But with a Duqu to gather intelligence, it is conceivable that cyber criminals could gather the information necessary to blackmail industrial organizations by building attacks aimed at the industrial controllers at the core of their operations or production. Remember that Stuxnet caused industrial devices to operate in a way that was destructive to those devices.  The physical destruction set back the Iranian nuclear program three to five years by most assessments.  It is therefore conceivable that similar damage could be wrought at assembly plants and operational locations, impairing the ability of companies to do business.

With the discovery of Duqu, commercial organizations no longer have the luxury of viewing Stuxnet as an aberration played out on the world political stage by nation states.   Duqu brings Stuxnet to their back door.  The Advanced Persistent Threat is no longer about the loss of confidential information or intellectual property, but about actual interruption of operations.  And I can assure you these businesses can put a hard dollar figure to interruptions of operation.

Organizations that were slow to adopt the assumption of breach doctrine and put tools in place for rapid detection and response, must now rethink their approach.  Organization will need to detect attacks that get through their defenses and be able to rapidly respond to address those attacks.  I think we will look back in several years and see the discovery of Duqu as a significant milestone when attacks like Stuxnet stopped being the concern of the NSA or the DoD and became a threat to the broader commercial realm.

(Triumfant has gone on record as saying we would detect Duqu and would be able to stop the attack before it collected the data it seeks.)

Yes, Triumfant Will Detect Duqu

The Duqu attack has been gaining a lot of attention this week, and when an Advanced Persistent Threat like Duqu is announced, I get the inevitable questions of “Would Triumfant detect this Advanced Persistent Threat?”  Based on a review of the research presented by Symantec, the answer would be yes.

For those not familiar, Symantec researchers discovered the Duqu attack and released the details in a bulletin “Symantec Security Response: W32.Duqu“.  Duqu is being called a precursor attack for Stuxnet, because it was written to gather information about the applications and networks of an organization to provide the data necessary to execute a future attack on an industrial control facility.  The report notes that Duqu uses much of the same logic as Stuxnet without the destructive capabilities.  The attack exists for 36 days and then destroys itself.

In the Symantec Security Response is the following description of how Duqu infiltrates the targeted machine:

“Duqu consists of a driver file, a DLL (that contains many embedded files), and a configuration file. These files must be installed by another executable (the installer), which has not yet been recovered. The installer registers the driver file as a service so it starts at system initialization. The driver then injects the main DLL into services.exe. From here, the main DLL begins extracting other components and these components are injected into other processes.”

After reviewing this with Dave Hooks, our CTO, I can tell you that Triumfant will detect this attack and present it to the attention of the administrators as an anomalous event.  There are several triggers that will initiate the Triumfant analysis process, but I will use the one we can present with the most certainty based on the information available.

The Symantec report cites that  “The installer registers the driver file as a service so it starts at system initialization”.  A new service will be detected by the Triumfant agent running on the attacked machine the next time the machine is restarted, and detection of this service will trigger Triumfant’s real-time analysis.  When the agent contacts the Triumfant server to begin the real-time analysis, the Triumfant’s server will in turn initiate probe requests to the agent on the attacked machine.  These probes are sophisticated algorithms designed to correlate changes to the infected machine for the purposes of identifying all of the damage from the attack.  These probes would identify the injection of the main DLL into services .exe, and the other DLLs injected into the other processes.  Triumfant would also correlate the internet traffic tied to the attack with any affected ports and IP addresses.

Triumfant will perform this analysis and return a comprehensive report that shows an anomalous application with the new service and the related services that had been corrupted.  We also suspect that the installer would likely have been an autostart mechanism which would trigger the same analysis, but since the report gave no details about the installer we can not make that claim with certainty.

In summary, based on the Symantec analysis we believe that Triumfant will see Duqu and will build a remediation to stop the attack and repair all of the associated damage to the affected machine.  We think this is notable given that most articles I have encountered about Duqu say that there is no tool that will detect and/or stop the attack.  The ability to detect and remediate Duqu is also a great example of what we call Rapid Detection and Response.

Will Triumfant detect Duqu? Yes.

Follow

Get every new post delivered to your Inbox.

Join 439 other followers