Large Organizations Need Open Security Intelligence Standards and Technologies

A few years ago, Trend Micro announced that it would enhance its on-site AV products with cloud-based intelligence it called the “Smart Protection Network” (SPN). I’m not sure if Trend was the first, but it certainly wasn’t the last vendor to embrace this type of architecture. In fact, just about everyone now has a toe in the cloud-based security intelligence pool. For example, Blue Coat promotes its WebPulse security intelligence, Cisco champions its Security Intelligence Operations (SIO), and Symantec trumpets DeepSight. Security intelligence sharing initiatives (like CISPA) are also a big part of the Federal government’s cybersecurity initiatives. What does cloud-based security intelligence entail? In many cases, it takes advantage of the proverbial “network effect” (sometimes referred to as Metcalfe’s law and attributed to Ethernet inventor Bob Metcalfe). According to Wikipedia: Metcalfe’s law states that the value of a telecommunications network is proportional to the square of the number of connected users of the system (n2). Each instance of the vendor’s product acts as a sensor for security intelligence (i.e. malware detection, rogue URL detection, rogue application detection, etc.). The vendor then implements a cloud repository, to publish, analyze, and distribute this information to all other customer nodes around the network. In theory, everyone benefits from the “network effect” while each vendor adds its own secret sauce in the forms of things like automated analysis, reputation data, and global honeynets, to increase its security intelligence value. This type of security intelligence sharing is a very good thing because it:1. Increases the number of collectors in the intelligence network.2. Provides for real-time (or near real-time) intelligence sharing3. Can be used as input for hardening security controls and supplementing internal security intelligence.Good stuff, but I see some imminent downside. First, it won’t be long until enterprises have to manage security intelligence feeds all over the place from AV vendors, web threat management gateways, advanced malware vendors, networking vendors, SIEM vendors, etc. Of course, a lot of this intelligence will be redundant and some vendors will provide better and timelier intelligence than others. Some vendors will also have intelligence that is a better fit for certain geographies or industries. Additionally, there are a number of emerging security intelligence vendors that specialize in advanced security intelligence alone. I recently met with a firm named Norse that exemplifies this business focus. This potpourri of data will likely present a series of challenges as security professionals try to manage, compare, integrate, and act upon a growing avalanche of security intelligence feeds from an assortment of sources. So this brings up a fundamental question: Should security intelligence be baked into products or should enterprise organizations have an opportunity to choose and integrate the security intelligence that offers the best data, intelligence, and integration capabilities for their particular industry, compliance, risk management, and threat detection/response needs? Today, vendors view their security intelligence as product differentiation, are already pushing the product/security intelligence model and will likely continue to do so in order to protect their installed base and compete in the market. That’s okay in principle, but if vendors insist on charging for this type of product/security intelligence integration, then CISOs should push back and demand security intelligence standards and product APIs to create a more open security intelligence market model. In other words, products should “plugin” to any open security intelligence feeds that their customers select. To pull this off, security intelligence must be based on standard data formats and secure transport protocols. I suggest STIX and TAXII being developed by DHS and Mitre. Vendors compete in hand-to-hand combat with each other on product features, functionality, and useability. My point is that they should also compete on the overall accuracy, timeliness, and scope of their security intelligence as well. Products should have standard APIs for open security intelligence integration and security intelligence should be offered up in a standard format. This will bring the efficiencies of the market to security intelligence and force vendors to innovate, specialize, and compete for business. Laggards will be forced out of the market entirely — after all, how many security intelligence feeds do we need for IPv4 reputation or rogue URL detection? To make this happen, CISOs should also become active lobbyists for an open security intelligence market. This could help them avoid the coming deluge of security intelligence, as they select the right feeds that align with their businesses. This will also help enterprises use this intelligence for its intended purposes – to lower risk and accelerate incident detection and response.