1.6 Reasons Why Triumfant’s Automated Remediation Approach is Superior

August 16, 2010 by Leave a comment

Remediation is becoming a hot topic and already the FUD is flying.  Of course, we are excited about our remediation story and I am often asked why our approach to remediation is different from others on the market.  Let me see if I can help by borrowing a statistic.

I was at a meeting at Symantec headquarters on Friday where Francis deSouza, senior vice president of the Enterprise Security Group at Symantec, was first on the agenda.  In his presentation, deSouza noted that Symantec research indicated that attacks are morphing so quickly that any given variation of an attack is used against 1.6 machines before a new variant appears.

Most companies (maybe everyone but Triumfant) employ an approach to remediation that employs previously written scripts that are matched to detected attacks.  This approach of course requires that such scripts can only be written for known attacks.  While there are some generic approaches that may apply to previously unknown attacks, for any moderately complex unknown attack there will likely be no remediation script.

Now let us put deSouza’s statistic to work in the discussion about remediation.  If we put the script-based approach in the context of deSouza’s statistic, we can conclude that any remediation script is good for 1.6 machines.  Makes sense because if the remediation is morphing, then it follows that the remediation needs would also change.  New variant requires a new script.

I am already reluctant to believe that any pre-written script can be completely effective for attacks of even moderate complexity because attacks may cause varying primary and secondary damage based on the unique combination of factors for any given machine such as OS version, installed applications, and differences in configuration.  Adding the restriction to previously known attacks and Mr. deSouza’s statistic and a logical conclusion is that scripted remediations will fall short.  Even if a script will apply, it is reasonable to doubt that the script is capable of remediating the machine without leaving one or more artifacts that will make the machine vulnerable.  This doubt normally translates to organizations re-imaging the machine as a matter of standard.

There are other differences such as the need for context.  For example, a process may be part of an attack.  A generic script may mark that process for deletion, when it may be a process shared by other benign applications.  A script would have to either shoot it on sight, potentially corrupting other applications, or contain the logic required to know what other applications the process shared and then have the ability to determine if those applications were installed on the machine.  Accounting for every “except for” would certainly be aq challenge.

Triumfant constructs a remediation that is specific to the identified incident for that machine and requires no previous knowledge to build this remediation.  We correlate all of the changes to the machine to build a remediation so complete you should not have to reimage the machine.  The remediation is surgical, contextual and specific.  As a bonus, our remediations can leverage our patent pending donor technology to restore deleted or corrupted files.

There is more, but I feel like the point has been made and anything else would be showing off.  The difference between common remediation solutions and Triumfant’s approach are profound.  Now I need to figure out how you attack 0.6 of a machine.

Filed under Configuration and Compliance Management, Endpoint Security Tagged with , , ,

Have No Fear: Triumfant’s Remediation Capability is Automated, Not Automatic

July 9, 2010 by Leave a comment

In my previous blog entry I attempted to unravel some of the fear, uncertainty and doubt around our automated remediation capabilities.  After a week of quiet contemplation at the beach and writing a whitepaper on the subject I had an epiphany.  I think the fear comes from a misunderstanding between the words “automated” and “automatic”.  Allow me to explain.

Triumfant has automated the construction of a remediation for any malicious attack or anomalous incident it finds.  The detail is all there in the blog entry.  But in short, because Triumfant knows what has changed and knows the value of every attribute or file before it was changed, it is a logical next step to build a remediation script to return the affected attributes to their pre-attack condition.  No spooky “thinking computer” stuff, just sound logic driven by the capabilities of our granular change detection.

The automated remediation Triumfant creates is not automatic in its execution.  The Triumfant administrator must perform a one-touch confirm of the remediation before it is sent to the agent for execution.  Triumfant does the heavy lifting of analyzing the attack or problem and building a comprehensive remediation script.  It is automated.  There is still the failsafe of human interaction as a confirmation.  It is not automatic.

There does exist easily implemented mechanisms to make remediations automatic for incidents encountered in the past and for configuration and policy enforcement.  In these cases the remediations are known and the customer is comfortable with their effects.  For example we have customers who identify specific applications they want removed from endpoint machines and these remediations are automatic.  But for anything new encountered by Triumfant such as a zero day attack or an Advanced Persistent Threat type attack, the default is the one-touch confirm by the administrator, providing oversight and control.

Why am I writing about this subject?  People seem to have a love/fear relationship with the concept of automated remediation.  For example, at the NIST Security Automation Conference last October in Baltimore I asked the attendees in my presentation two questions:

Q1: Who wants automated remediation?  A: Every hand in the room enthusiastically shot up.

Q2: Who is ready to implement automated remediation?   A: Crickets.

All I can surmise is that security people suffer from what I have dubbed “SkyNet Syndrome” – the lingering effects of watching science fiction movies and television series that ultimately play the “smart computer comes to life and destroys the world” card.  The list is long and distinguished: M5 and Nomad on Star Trek the Original Series, V’Ger on the first Star Trek Movie, Colussus from Colossus: The Forbin Project, Proteus on The Demon Seed, and, of course, SkyNet from The Terminator.

Notice that I did not include W.O.P.R. from WarGames as he was hacked and did not become sentient.  Of course he was hacked because he had poorly configured endpoint protection that could have been easily recognized through change detection and quickly addressed by Triumfant through an automated remediation.  But I digress.

Filed under Configuration and Compliance Management, Endpoint Security Tagged with , , , ,

Triumfant’s Automated Remediation – Not Voodoo, Sensible Can-Do

June 14, 2010 by Leave a comment

It has come to my attention that many have a hard time getting their heads around our automated remediation capabilities.  The concepts around the way Triumfant performs automated remediation are really quite simple, so allow me to explain:

We know what changed. We continuously scan the machine for changes and if we see an indication that the machine is under attack we perform an accelerated full scan to kick off the analysis process.  So when Triumfant’s patented analytics perform the analysis of a malicious incident, each and every change to the machine is available for consideration.   Triumfant not only sees what has changed, but we are uniquely able to group changes to identify what changes are part of each specific incident.  The analytics leverage over 25 different correlation algorithms to determine all of the primary and secondary artifacts from any given attack.  We identify the attack and all of the changes associated withe the attack such as configuration changes and opened ports.  The changes break down into three basic change types: unexpectedly present means that something new has been added, unexpectedly absent means that something that was there is no longer there, and unexpectedly modified means that the value has been changed.

We know what the attribute or file looked like before it changed. The first step performed by the Triumfant agent is to take a snapshot of the over 200K attributes we monitor.  This includes an MD5 hash of every file on the machine.  A copy of this snapshot is continuously maintained on the endpoint and on the Triumfant server.   Therefore, Triumfant has a very logical and unique set of data that serves as the ingredients to write the remediation: we know what has changed, we know the current (changed) value, and we know the value prior to the change.  Brutally simple in concept, but elegantly and efficiently executed.

We therefore can build a script to modify the things that changed back to what they used to be before they were changed. Once you know what attribute or file has changed and know what the attribute of file looked like before it was changed, it is not hard to construct a script to change things back.  Actually, there are some challenges, but luckily our engineers have made it look simple.  For example, it is easy to delete things that are not supposed to be on the machine, and it is easy to restore modified or deleted attribute values.  It is not that simple to restore missing or corrupted files.  That is why Triumfant’s donor technology (patent pending) is so remarkable.  Triumfant uses our knowledge base (automatically generated) to find a donor machine that has the same missing or corrupted file (version, OS, validated by the MD5 hash) and uses that donor machine to provide a copy to move to the affected machine.  I will explore the donor technology and the context that powers it in a future post, suffice to say the capability is completely unique to Triumfant and is an elegant solution to a very difficult problem when considering automated remediation.

Makes sense when you lay it out this way, doesn’t it?  Triumfant uses this very simple logic flow to build a custom remediation script for each and every incident that is contextual, situational, and surgical.  The script is constructed without the need for human intervention at the server and sent to the agent for execution after confirmation by an administrator.  The remediation only affects those attributes and files that were part of the attack and does not affect any of the changes done to the machine outside of the incident.  None of the user’s work or any of the benign changes to the machine are lost.  And you should not have to re-image the machine out of fear that there may be artifacts of the attack still lurking on the machine.

This is not a rollback to an image, there is no interaction required by the end user, including the requirement (accept in the most extreme cases) to reboot.  We are not pulling from a library of pre-written remediations that can’t possibly know enough to address all of the primary and secondary artifacts of an attack.

This is not VooDoo, but sound, sensible science.  It takes the concepts of change detection and extrapolates it to the logical end – not only can Triumfant see the attacks that evade other defenses, it can build a remediation that stops the attack and removes all of the collateral damage of the attack.   We are not a shield, but we go from infection (not detection, which for many tools takes days, weeks, even months) to remediation in less than five minutes.  So given that the shields miss so much, the fact that malware exists on the machine for five minutes is a more than equitable trade-off for those organizations dealing with the advanced persistent threat, zero day attacks, and rootkits.

Finally, I know the term “automated” gives everyone heartburn.  Everyone likes the concept, but is skittish on actually implementing.  Not to worry.  We build the remediation automatically, but by default it does not run automatically.  The administrator will get an alert that malware has been detected, and the administrator can then evaluate Triumfant’s findings and validate the remediation before it is executed.  And every remediation is completely reversible.  We provide all of the analysis and write the remediation script, you actually put it into motion.

Filed under Endpoint Security Tagged with , , ,

Follow

Get every new post delivered to your Inbox.

Join 451 other followers