Research

We have discussed why continuous security monitoring is important, how we define CSM, and finally how you should be classifying your assets to figure out the most appropriate levels of monitoring. Now let’s dig into the problems you are trying to solve with CSM. At the highest level we generally see three discrete use cases: Attacks: This is how you use security monitoring to identify a potential attack and/or compromise of your systems. This is the general concept we have described in our monitoring-centric research for years. Change: An operations-centric use case is to monitor for changes, both to detect unplanned (possibly malicious) changes, and to verify that planned changes complete successfully. Compliance: Finally, there is the check the box use case, where a mandate or guidance requires monitoring and/or scanning technology; less sophisticated organizations have no choice but to do something. But keep in mind the mandated product of this initiative is documentation that you are doing something – not necessarily an improved security posture, identification of security issues, or confirmation of activity. In this post and the next we will dig into these use cases, describe the data sources applicable to each, and deal with the nuances of making CSM work to solve each problem. Before we dig in we need to make a general comment about these use cases. Notice that they are listed from broadest and most challenging, to narrowest and most limited. The attack use case is bigger, broader, and more difficult than change management; compliance is the least sophisticated. Obviously you can define more granular use cases, but these three cover most of what people expect from security monitoring. So if we missed something we are confident you will let us know in the comments. This is a reversal of the order in which most organizations adopt security technologies, and correlates to security program sophistication. Many start with a demand to achieve compliance, then grow an internal control process to deal with changes — typically internal — and finally are ready to address potential attacks, which entails changes to devices posture. Of course the path to security varies widely — many organizations jump right to the attack use case, especially those under immediate or perpetual attack. We made a specific decision to address the broadest use case first — largely because even if you are not yet looking for attacks, you will need to soon enough. So we might as well lay out the entire process, and then show how you can streamline your implementation for the other use cases. The Attack Use Case As we start with how you can use CSM to detect attacks, let’s begin with the NIST’s official definition of Continuous Security Monitoring: Information security continuous* monitoring (ISCM) is maintaining ongoing* awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. *The terms “continuous” and “ongoing” in this context mean that security controls and organizational risks are assessed, analyzed and reported at a frequency sufficient to support risk-based security decisions as needed to adequately protect organization information. Data collection, no matter how frequent, is performed at discrete intervals. NIST 800-137 (PDF) Wait, what? So to NIST ‘continuous’ doesn’t actually mean continuous, but instead a “frequency … needed to adequately protect organization information.” Basically, your monitoring strategy should as continuous as it needs to be. A bit like the fact that advanced attackers are only as advanced as they need to be. We like this clarification, which reflects the fact that some assets need to be monitored at all times, and others not so much. But let’s be a bit more specific about what you are trying to identify in this use case: Determine vulnerable (and exploitable) devices Prioritize remediating those devices based on which have the most risk of compromise Identify malware in your environment Detect intrusion attempts at all levels of your environment Gain awareness and track adversaries in your midst Detect exfiltration of sensitive data Identify the extent of any active compromise and provide information useful in clean-up Verify clean-up and elimination of the threat Data Sources To address this laundry list of goals, you need the following data sources: Assets: As we discussed in classification, you cannot monitor what you don’t know about; without knowing how critical an asset is you cannot choose the most appropriate way to monitor it. As we described in our Vulnerability Management Evolution research, this requires an ongoing (and dare we say “continuous”) discovery capability to detect new devices appearing on your network, and then a mechanism for profiling and classifying them. Network Topology/Telemetry: Next you need to understand the network layout, specifically where critical assets reside. Assets which are accessible to attackers are of course higher priority than inaccessible assets, so it is quite possible to have a device which is technically vulnerable and contains critical data, but is less important than a less-valuable asset which is clearly in harm’s way. Events/Logs: Any technological device generates log and event data. This includes security gear, network infrastructure, identity sources, data center servers, and applications, among others. Patterns in the log may indicate attacks if you know how to look; logs also offer substantiation and forensic evidence after an attack. Configurations: Configuration details and unauthorized configuration changes may also indicate attacks. Malware generally needs to change device configuration to cause its desired behavior. Vulnerabilities: Known vulnerabilities provide another perspective on device vulnerability, can be attacked by exploits in the wild. Device Forensics: An advanced data source would the very detailed information (including memory, disk images, etc.) of what’s happening on each monitored device to identify indicators of compromise and facilitate investigation of potential compromise. But this kind of information can be invaluable to confirm compromise. Network Forensics: Capturing the full packet stream enables replay of traffic into and out of devices. This is very useful for identifying attack patterns, and also for forensics after an attack. That is a broad list of data, but — depending on the sophistication of your CSM process — you may not need all these sources. More data is better than less data, but everyone needs to strike a balance between capturing

This morning Cisco made its first decisive move in the network security space in years, acquiring Sourcefire for $2.7 billion. That represents a 30% premium over Sourcefire’s closing price yesterday. But much more importantly it is a clear signal that Cisco hasn’t given up on security and intends to compete as organizations rebuild their network security around the poorly named next generation application awareness technology. This was a move Cisco had to make. Pure and simple. We suspect there were other bidders to drive the 30% premium on an already rich valuation. But Cisco couldn’t lose out, mostly because there really isn’t anything else to buy for as reasonable a price. If you think $2.7 BILLION is reasonable, at least. The trends are clear. Enterprises are rearchitecting their perimeter security. They want application-aware technology for both firewall and IPS to enforce policies on web-based applications. They want the option to consolidate numerous devices and capabilities onto a common platform enforcing a common policy – what we call a perimeter security gateway. This common platform will also have other capabilities, such as advanced malware protection and web filtering. Cisco had none of the above. So they had no choice. I had joked that Chris Young (Cisco’s GM of Security) had a blank check, but it was only good for Starbucks cards. But I was wrong to joke. With one decisive move Cisco is back in the network security game – in concept, at least. Now they can tell their customers a story about how they haven’t abandoned the ASA platform, and can move forward with innovative and competitive technology from Sourcefire. Cisco can leverage their tremendous distribution reach to drive Sourcefire products well beyond what Sourcefire could do themselves, or likely with any other partner. Of course all this unicorn dust is on paper. Now the work begins to figure out how to wedge Sourcefire’s Agile Security strategy onto the latest Cisco marketecture. You couldn’t take more diametrically opposed paths to market. Cisco relied on marketecture to obscure product issues. Sourcefire focused on product and historically didn’t do a good job of painting a broad and compelling picture, although they have improved over the past 18 months. After the deal closes they need to figure out how to migrate the ASA base onto FirePOWER ASAP. They need to communicate a strong message based on product rather than PowerPoint. Job #1 is to protect what’s left of their installed base and ensure Sourcefire maintains their IPS share in a very competitive market. Of course Palo Alto and Check Point will step up their Cisco displacement efforts bigtime, grabbing all they can in the shortening window until Cisco has a competitive product. Big IT (IBM and HP) have IPS platforms. They will maintain that there is still a market for standalone IPS, and for a while they will be right. But that plays right into Cisco’s hands. Now they both get to compete with Cisco, instead of fighting Sourcefire for the chance to rip out existing Cisco IPS devices. On the firewall front Sourcefire is still playing at a disadvantage. They got into the market late and have been building the technology internally, and it takes time to reach feature parity with companies in the firewall market for a decade. But this deal buys Sourcefire time. Most of the folks still buying Cisco network security gear aren’t innovators. They are the late majority, don’t have overly rigorous requirements, and can wait for the integration story. Check Point, Palo Alto, and Fortinet will continue to fight mano a mano for the NGFW business. Due to the vagaries of Finnish public company trading rules, McAfee will actually be starting their true integration efforts with the acquired Stonesoft technology after Cisco completes the Sourcefire deal (expected in late Q3/early Q4). So what’s in it for Sourcefire? Besides $2.7B? They needed to find a partner at some point. They probably could have waited a bit to prove the viability of their NGFW/NGIPS integrated platform story. But there is a definite advantage to getting paid a high multiple on potential rather than on results. As the wise investor says, you never lose money when you take a profit. And Sourcefire investors are taking lots of profit from this deal. So the timing works well for Sourcefire. For this deal to pay off Cisco needs to hand the network security reins to Marty Roesch and his team. The group will report to Chris Young, but if Marty isn’t driving the security strategy for all Cisco they are missing a huge opportunity. And if they can’t keep Marty visible and engaged beyond his contractual commitment there will be a mass exodus, as we saw with all the other big security deals – with the exception of IBM/Q1 Labs. This is not a slam dunk for Cisco – they still need to do the work and regain their network security mojo, which has been long gone. But they really didn’t have a choice. They wrote a big check to solve a big problem. And it is not much more complicated than that. Share: