Network Forensics Vendors: Get in the Cloud!

I know some of us worry that the advent of the "cloud" will spell the end of Network Security Monitoring and related network-centric visibility and instrumentation measures. I have a proposal for any network forensics vendors reading this blog: get in the cloud!

For example, imagine you are a proxy-in-the-cloud (PITC) provider, like ScanSafe, now owned by Cisco. You provide a Web portal to your customers so they can see what bad sites employees were not allowed to visit. But what about all the subtle traffic that evaded your filters, block lists, heuristics, and other defensive mechanisms? What about the insider stealing intellectual property, indistinguishable from a "normal employee?" How does your abuse-centric Web portal address the sorts of threats that really matter?

To me, one answer is to deploy a network forensics solution like NetWitness or Solera in front of your PITC infrastructure. The PITC vendor must have a way to identify legitimate clients, or else you've created the world's greatest open Web proxy. Use the identity information to tag the traffic collected by the network forensics product.

When a customer needs to analyze an intrusion, or conduct an investigation, he can connect to the hosted network forensics platform.

I also like this approach because it helps address the consumerization of IT. You can create a policy (weak I know, but it's an option) that Company users must point any device that processes Company data to the PITC infrastructure for Web access. By doing so you can collect the network forensic data you need.

Of course, encryption is always an issue, but if really necessary I'm sure you can work with the PITC vendor on a MITM approach.

I'm sure I'll get a few comments from critics saying "NSM is dead," "network traffic is worthless," etc. It's just a sign you don't know how to use that sort of data effectively, and probably never will. After evangelizing for 10 years, I've given up trying to convince critics like that.

I also don't intend for this post to be a signal that I hate logs or host-based evidence. It's just another piece in the puzzle.

So, network forensics vendors, who will be the first to publish a press release saying you've partnered with a PITC provider?

Read More

Initial Thoughts on Cloud A6

I'm a little late to this issue, but let me start by saying I read Craig Balding's RSA Europe 2009 Presentation this evening. In it he mentioned something called the A6 Working Group. I learned this is related to several blog posts and a Twitter discussion. In brief:

• In May, Chris Hoff posted Incomplete Thought: The Crushing Costs of Complying With Cloud Customer “Right To Audit” Clauses, where Chris wrote Cloud providers I have spoken to are being absolutely hammered by customers acting on their “right to audit” clauses in contracts.


• In June, Craig posted Stop the Madness! Cloud Onboarding Audits - An Open Question... where he wondered Is there an existing system/application/protocol whereby I can transmit my policy requirements to a provider, they can respond in real-time with compliance level and any additional costs, with less structured/known requirements responded to by a human (but transmitted the same way)?


• Later in June, Craig posted in Vulnerability Scanning and Clouds: An Attempt to Move the Dialog On... where he spoke of the need for customers to conduct vulnerability assessments of cloud providers: A “ScanAuth” API call empowers the customer (or their nominated 3rd party) to scan their hosted Cloud infrastructure confident in the knowledge they won’t fall foul of the providers Terms of Service.


• In July, Chris extended Craig's idea with Extending the Concept: A Security API for Cloud Stacks, building on the aforementioned Twitter discussions. Chris mentioned The Audit, Assertion, Assessment, and Assurance API (A6) (Title credited to @CSOAndy)... Specifically, let’s take the capabilities of something like SCAP and embed a standardized and open API layer into each IaaS, PaaS and SaaS offering (see the API blocks in the diagram below) to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.

Still with me? In August Network World posted A6 promises a way to check up on public cloud security, which said:

What cloud services users need is a way to verify that the security they expect is being delivered, and there is an effort underway for an interface that would do just that.

Called A6 (Audit, Assertion, Assessment and Assurance API) the proposal is still in the works, driven by two people: Chris Hoff - who came up with the idea and works for Cisco - and the author of the Iron Fog blog who identifies himself as Ben, an information security consultant in Toronto.

The usefulness of the API would be that cloud providers could offer customers a look into certain aspects of the service without compromising the security of other customers’ assets or the security of the cloud provider’s network itself.

Work on a draft of A6 is posted here http://www.scribd.com/doc/18515297/A6-API-Documentation-Draft-011. It’s incomplete, but offers a sound framework for what is ultimately needed.

So let's see what that says:

The A6 API was designed with the following concepts in mind:

1. The security stack MUST provide external systems with the ability to query a utility computing provider for their security state. Ok, that's pretty generic. We don't know what is meant by "security state," but we're just starting.


2. The stack MUST provide sufficient information for an evaluation of security state asserted by the provider. Same issue as #1.


3. The information exposed via public interfaces MUST NOT provide specific information about vulnerabilities or result in detailed security configurations being exposed to third parties or trusted customers. Hmm, I'm lost. I'm supposed to determine "security state" but without "specific information about vulnerabilities"?


4. The information exposed via public interfaces SHOULD NOT provide third parties or trusted customers with sufficient data as to infer the security state of a specific element within the providers environment. Same issue as #4.


5. The stack SHOULD reuse existing standards, tools and technologies wherever possible. Neutral, throwaway concern.

That's about it, with the following appearing below:

In classic outsourcing deals these security policies and controls would be incorporated into the procurement contract; with cloud computing providers, the ability to enter in specific contractual obligations for security or allow for third party audits is either limited or non-existent. However, this limitation does not reduce the need for consuming organizations to protect their data.

The A6 API is intended to close this gap by providing consuming organizations with near real-time views into the security of their cloud computing provider. While this does not allow for consuming organizations to enforce their security policies and controls upon the provider, they will have information to allow them to assess their risk exposure.

Before I drop the question you're all waiting for, let me say that I think it is great people are thinking about these problems. Much better to have a discussion than to assume cloud = secure.

However, my question is this: how does this provide "consuming organizations with near real-time views into the security of their cloud computing provider"?

Here is what I think is happening. Craig started this thread because he wanted a way to conduct audit and compliance (remember I highlighted those terms) activities against cloud providers without violating their terms of service. I am sure Craig would agree that compliance != security.

The danger is that someone will believe that complaince = security, thinking one could conceivably determine security state by scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc..

This is like network access control all over again. A good "security state" means you're allowed on the network because your system is configured "properly," the system is "patched," and so on. Never mind that the system is 0wned. Never mind that there is no API for quering 0wnage.

Don't get me wrong, this is a really difficult problem. It is exceptionally difficult to assess true system state by asking the system, since you are at the mercy of the intruder. It could be worse with cloud and virtual infrastructure if the intruder owns the system and the virtual infrastructure. Customer queries the A6 API and the cloud returns a healthy response, despite the reality. Shoot, the cloud could say it IS healthy by the definition of patches or configuration and still be 0wned.

I think there's more thought required here, but that doesn't mean A6 is a waste of time -- if we are clear that it's more about compliance and really nothing about security, or especially trustworthiness of the assets.

Read More

Enterprise Data Centralization

I've written about thin client computing for several years. However, I haven't written about a natural complement to thin client computing -- enterprise data centralization. In this world, the thin client is merely a window to a centralized data store (sufficiently implemented according to business continuity processes and methods like redundancy, etc.). That vision can be implemented today, albeit really only where low-latency, uninterrupted, decent bandwidth is available.

Thanks to EDD Blog I just read an article that makes me think legal forces will drive the adoption of this strategy: Opinion: Data Governance Will Eclipse CIO Role by Jay Cline. He writes:

In response to the new U.S. Federal Rules on Civil Procedure regarding legal discovery, for example, several general counsels have ordered the establishment of centralized "litigation servers" that store copies of all of the companies’ electronic files. They think this is the only way to preserve and cheaply produce evidence for pending or foreseeable litigation. It’s a very small leap of logic for them to propose that all of their companies’ data, not just copies, should be centralized...

Data must soon become centralized, its use must be strictly controlled within legal parameters, and information must drive the business model. Companies that don’t put a single, C-level person in charge of making this happen will face two brutal realities: lawsuits driving up costs and eroding trust in the company, and competitive upstarts stealing revenues through more nimble use of centralized information.

The rest of the article talks about the role of CIOs, CTOs, "chief information strategists," etc., but I don't care about that. I care about the data centralization aspect.

For me, data centralization will be a major theme in my new job. If only to meet ediscovery requirements, at the very least, copies of all business information will need to be stored centrally. This strategy will give users of any computing platform the flexibility to create information locally, but that data will quickly find a second home (at the very least) in the central data store. Ideally (once bandwidth is ubiquitous) all business data will reside centrally, from creation to destruction (in accordance with data rentention and data destruction policies). Furthermore, that data will be subjected to protections at the document level, not just at the application, OS, and platform level.

This strategy addresses many problems very nicely.

1. Ediscovery: With at least copies of all data stored locally, all relevant data can be searched and produced.


2. Business Continuity: If your computing platform is destroyed, all your data (or at least a copy) is stored elsewhere.


3. Incident Recovery: As I said in my Five Thoughts on Incident Response:
   
   Today, in 2007, I am still comfortable saying that existing hardware can usually be trusted, without evidence to the contrary, as a platform for reinstallation. This is one year after I saw John Heasman discuss PCI rootkits (.pdf)... John's talks indicate that the day is coming when even hardware that hosted a compromised OS will eventually not be trustworthy.
   
   One day I will advise clients to treat an incident zone as if a total physical loss has occurred and new platforms have to be available for hosting a reinstallation. If you doubt me now, wait for the post in a few years where I link back to this point. In brief, treat an incident like a disaster, not a nuisance. Otherwise, you will be perpetually compromised.
   
   With thin client computing and data centralization, incident recovery means discarding the old computing platform and starting with a fresh one.


4. System Administration: We will avoid Marcus Ranum's "Infocalypse," preventing every man, woman, and child from becoming a Windows system administrator. Scare IT staff will administer centralized systems and end users will no longer have the power or need to install software. The Personal Computer will be replaced by a window to the Business Computer, although the platform itself might be a consumer platform like a smartphone. (Of course, PCs will still be options outside business needs.)


5. Information Lifecycle Management: ILM includes data classification, defense, retention, and destruction. With all data in a central location, it will be easier to classify it and apply classification-appropriate handing and defense tools and techniques. It is important to remember that not all data is worth the same value and trying to protect it all with the same tools and techniques is too costly. (Did you know the US Postal Service will carry up to Secret classified data within the US, provided it is wrapped appropriately and sent via registered mail? The idea is that the risk of interception is worth the savings over having a courier transport Secret material.)

What data centralization and/or thin computing is your organization pursuing, and why?

Read More

Security in the Cloud

A blog reader recently asked me to comment on this Security in the Cloud debate. First, a word on the opposing sides. The Yes proponent, Brad Miller, is CEO of Perimeter Internetworking. His company looks like a managed security services firm, except they are latched onto Gartner's security in the cloud idea. That is derived from MCI's (now Verizon's) concept of filtering traffic on its backbones. I find it odd that a company like Perimeter Internetworking can ride the cloud bandwagon when they are not in the cloud!

The No proponent is Bruce Schneier, CTO of Counterpane. He is not exactly saying no to the idea though:

[A] choice between implementing network security in the middle of the network - in the cloud - or at the endpoints is a false dichotomy. No single security system is a panacea, and it's far better to do both...

I'm all in favor of security in the cloud. If we could build a new Internet today from scratch, we would embed a lot of security functionality in the cloud. But even that wouldn't substitute for security at the endpoints. Defense in-depth beats a single point of failure, and security in the cloud is only part of a layered approach.

So perhaps the argument should have been framed "security only in the cloud"? In that respect, Bruce would obviously disagree because (1) it is a bad idea, due to the security necessity of layered defenses; and (2) as a MSSP, Counterpane would lose business. Counterpane will lose business anyway, since ISPs like Verizon, Sprint, and at&t are offering cloud-based security services. Mr. Miller foolishly favors the abolition of end-user , or "CPE" (Customer Premise Equipment) security:

The bottom line is that the superior protection, economics and speed of deployment of security in the cloud will further marginalize CPE-based managed security. Large carriers will embrace security in the cloud and will obviate the need for CPE systems.

This statement demonstrates Mr. Miller has no concept of security principles.

In any case, I see fewer ISPs offering unfiltered, "clean" pipes, even though the term "clean" seems at odds with carrying "dirty" DoS traffic, spam, and the like. ISPs are already filtering common Microsoft Windows ports. This trend will only continue.

Read More