=> "Flame" and "Stuxnet"..the new weapons in an arisenal

As information filters out on Flame and the origins of Stuxnet, we are getting a glimpse into the weapons locker of the newest tools of the future in intelligence cyber warfare.  And so far, it’s scary and impressive.

I know a man that only a few years back made the claim that cyber warfare wasn’t possible.  (Which is odd for a security professional.)  The concept of attacking a enemy with computers and malware wouldn’t justify as warfare.  It would only be an inconvenience.  I wonder how many other people share that view?

As I read more on the Flame malware and its a sophisticated attack toolkit.  Its a Trojan, and has worm-like characters, allowing it to replicate in a local network and on removable media if it is commanded so by its master.

Once a system is infected, Flame begins data gathering that includes sniffing network traffic, recording audio from internal mics, intercepting key strokes and screenshots. All this data is available through the link to the bots command-and-control servers.

Flame is a package of modules when, making it difficult to analyze. Flame is larger than most malware in the past because it includes many different libraries for compression and database manipulation.

Flame is simply looking for any kind of data of electronic publications and audio gathered (docs, e-mails, chat messages, etc.) from the analysis reported,

Based on the information from the Kaspersky Lab, they are seeing multiple versions of the malware with different sizes and content.

More malware will be coming and of even scarier payloads.  If these are the know… what is out in the unknown.

=> Information Security and The Myth of Sisyphus.

Myself, like many of us in the security field know, our day to day activities are and endless uphill battles.  As long as there is the human input, there is no "true" security solutions.  There is no way to make anything 100 percent secure.  All we can do is evaluate the risks.  The likelihood that it will happen.  The impact it will make if a breach does occur. 

But as most of us in the field know, the real analysis is not done.  A "gut check" is put to paper with bullet points from like minded white papers to help justify the conclusions they have already made. 

When has it become the best practice to short cut?  The need to rush to market (deliver project on a time that gets the project lead home in time to watch the latest episode of The Big Bang Theory).  And in the process cut corners that can cause harm to the overall structure of the effort.

By now, you have noticed that I am not specifying network security, application security, physical security or countless other types of projects.  The reason is simple... the problem is universal.  As in The Myth of Sisyphus by Albert Camus the parallels are apparent.  By cutting corners in a project it is like Sisyphus cheating Death.  Tricking his way out of what needed to be done to pay later when the gods found out and punish Sisyphus by assigning him a task of futility, push a stone up a hill again and again.  Not too unlike the endless work around and corrections that need to be done to minimize (never eliminating) the risk to a much more perceived state.

Now, as most of you who know me, one of my true underlying beliefs is: Never identify a problem without taking the time to help identify possible solutions.  (I really think the world would be better if more people did this.)

First => Do the proper pre work for anything.  Scope out what you want to accomplish.  Prioritize these goals.  Make sure if you are wanting to deploy a monitoring solution, know exactly what you want to monitor (network traffic, web activity, memory and cpu utilization).  How you want it monitored (actively, passively). Etc.

Second => With each goal in your scope, do a risk analysis.  What is the benefits versus the impact if accomplished.   As you go through each goal within your scope and rate their risks, you get a much better picture of the overall risk of the project as a whole.

Third => Find a solution that meets your scope goals.  There are allot of products in the world with bells and whistles that are "nice to have" but never lose sight of what you want to accomplish and when make sure the "bells and whistles" are not adding more risk. (the product will tweet you when there is a monitored alert.  Telling the world key information on what it is monitoring that a hacker would love to know.)  Also, don't let only the money people decide on a product.  Keep the experts of your environment involved in the decision making process.  They know it best.  (To these experts: Never identify a problem without taking the time to help identify possible solutions.
 It still holds here true here too.) 

Forth => Don't forget the learning curve to own and administer the solution.  The time between deployment and having subject matter experts (SMEs) can be some of the riskiest times. 

I only hope these words help people think about security first instead of as an after thought.  Nothing is 100 percent secure.  But, if we all do our best up front, there are less likely issues to follow-up on. 

And get us out of behind the stone on the hill.