Cloud security tools are hard

There are tools, security tools, and then there are cloud security tools.  Especially in the realm of security orchestration.  Many cloud snake oil tools were never designed for the cloud.  See RSA four years ago when a vendor slapped cloud on their marketing material for pre-existing on-premise software.  Or better yet:  They took their CFEngine instances and applied it to all of their customer's AWS instances.  A great example are the vulnerability managers / scanners.   Setup a DNS hostname or IP to scan.  Then the vulnerability "management" portion of the scanner will track the DNS / IP with metadata about the machine.  But what about when the IP or DNS name changes to a different IP / DNS hostname, but the machine instance stays the same? Many service-based security tools pricing structure are based upon some idea of a static concept (IP address, DNS entry, etc...)  So imagine an infrastructure where new machines are created and destroyed every few minutes.  It will get quite expensive.  Not to mention, the vulnerability / GRC management software doesn't have the concept of a machine instance jumping around the infrastructure with different IPs / DNS names but still representing the same machine scanned moments earlier.  Well, their business model understands this concept and it means more licenses and billable expenses.  This is assuming you are able to scan instances which exist for a few minutes then are terminated; you did solve that problem, right?  

Very few cloud snake oil tools have any type of API or programmatic interface by which to interact with the service or tool.  Imagine if you wanted to correlate information on everyone piggybacking into your office.  A simple correlation involves seeing who didn't swipe into the office but logged on locally to the office networked machine.  If you had to resort to scraping the building access system to get your swipes, then it doesn't have an API or programmatic interface.  One would expect to see start, stop, restart, running status, credential management, alerting, reporting, auditing, etc....  

One's mileage on the time it will take to construct / destroy the cloud security orchestration tool.  For many software-based tools, it will require a complex host or network agent.  Look at the build complexity required to run Chef: MongoDB, Solr, Rails, Ruby, etc...  Best case, the tool will require credentials or be at some trusted point in the architecture.  This is where orchestration tools will succeed.  Once you can do it for another environment, it is simple to transition the orchestration to the new environment.  Assuming one is building a mirror of their other environment.

While interoperability will always be an issue with security tools, orchestration is another beast.  Rarely, one will find one tool to natively interoperate with others.  Hence the business need for Bromium, Cloud Passage, High Cloud Security, HyTrust, and other cloud security entities.  Ask yourself; does your cloud security tool have the ability to push / pull information from your Arc Sight instance, correlate with Splunk's output, push into your GRC tool, pull the latest scan from Qualys, maintain policy compliance, and push out signatures to your Imperva instances?  How about a simpler question:  How will you pull your puppet / chef logs from Splunk or OSSEC and correlate with one's security checklist automation documentation to verify what one is seeing is a policy violation or an intrusion?  By the way, the asset which caused the violation is now destroyed by your orchestration software.  I hope your incident response team understands how to investigate cloud instances and be able to perform forensic investigations.

An unusual rebuttal to Dave's email on the DailyDave mailing list.

"......

Dave,

 

I would love to believe you can speak for all motives within a complex and often changing political bureaucracy. Perhaps you are in a position to explain away concrete evidence of economic espionage by the United States and the motives detailed by a former director of central intelligence:

 

(http://online.wsj.com/article/SB95326824311657269.html)

 

“Why, then, have we spied on you? The answer is quite apparent from the Campbell report — in the discussion of the only two cases in which European companies have allegedly been targets of American secret intelligence collection. Of Thomson-CSF, the report says: "The company was alleged to have bribed members of the Brazilian government selection panel." Of Airbus, it says that we found that "Airbus agents were offering bribes to a Saudi official." These facts are inevitably left out of European press reports.  That's right, my continental friends, we have spied on you because you bribe. Your companies' products are often more costly, less technically advanced or both, than your American competitors'. As a result you bribe a lot. So complicit are your governments that in several European countries bribes still are tax-deductible.”

 

There are many more cases to choose from, yet few as straight-forward as this; a former official of the CIA says the agency justified a policy of American economic espionage because of a belief in the superiority of the American economic model. Thus economic espionage simply has to be justified somewhere within the American chain-of-command to be authorized. Never mind the irony when America says they have used government-sponsored espionage to prove that freedom from government interference is the best economic model. At least we know why and when it will happen, despite an absence of evidence from AV firms.

 

Davi

 

From: [email protected] [mailto:[email protected]] On Behalf Of Dave Aitel
Sent: Tuesday, November 25, 2014 7:05 AM
To: [email protected]
Subject: [Dailydave] Economic Espionage and Regin

 

It's been catchy to look at the Snowden papers and all the trojans coming out from "Western" governments and think that the 5 Eyes does espionage in an unrestricted way the way the Chinese and Russian Axis does. But they don't.

If they did, you'd see crowing reports from Kaspersky and Symantec that they found information being stolen from Russian banks to aide UK financial institutions. You'd see evidence in that M&A deals would be going weirdly well for the UK using information that clearly could only be gotten from hacking in the places Regin is found. This isn't what you're seeing. You're seeing in Regin a focus on looking at cell towers in areas where the UK is at war (Afghanistan).

While Regin clearly can be used to steal information, it's not stealing information from places where economic espionage is done. This is the opposite of what you find when you look at Russian or Chinese hacker teams, which often are clearly using the same toolchain to gather military intelligence and economic espionage. As I pointed out in my Business Insider article,  there's a big difference in the motivations and effects of the respective teams.

Dave Aitel
Immunity, Inc.