Research

I remember back in my 20s, when I though my success and wealth were assured. I was a high-flying analyst during the Internet bubble and made a bunch of coin. Then I lost a bunch of coin as the bubble deflated. Then I started a software company, which was sold off for the cash on our balance sheet. Then I chased a few hot startups that got less hot once I got there. None had a happy ending. Maybe my timing just sucks. Maybe I wasn’t very good at those specific jobs. Probably some combination of the two. But at the end of the day it doesn’t matter. I have reached the conclusion, 15 years later, that success rarely happens quickly. Some outliers get lucky, know a guy at Instagram, and walk away with big bucks in 18 months, but that is rare. You have a slightly better chance of quick startup riches than winning the lottery, and slightly worse odds than getting run over by a semi walking to the corner store. For every two steps forward, you are likely to take a step and a half back. Sometimes you have a bad day and take 3 steps back. Overnight success is usually 20 years in the making. Conversely, the express train to the mountaintop usually ends with a fall from grace and a mess at the bottom of the hill. Just check out the horror stories of all those folks who won the lottery… and were broke or dead 5 years later. It comes back to sustainability. If the change happens too fast it may not be sustainable, and sooner or later you will be right back where you started. Probably sooner. Small changes that add up over a long period of time become very substantial. Yes, you learned that in elementary school, or perhaps back when you discovered the magic of compound interest. It seems silly but it does work. Let’s take my weight as an example. I have been in good shape. I have been in bad shape as well. It has been a challenge since I was a kid. When I finally make up my mind to drop some pounds, it’s never a straight line. I lose some. I backslide a bit. I try to have more good days than bad. But if I can stay consistent with small changes the trend continues in the right direction. It’s all about tracking those trends. At some point I will get my weight to the point where it’s both comfortable and sustainable. The same goes for the size of the business. I’m looking for higher highs and higher lows, which we have been able to achieve over the past four years. If you’re trying to grow at 15% quarter over quarter, that’s probably not sustainable… not for an extended period of time. But having bigger quarters year over year? Achievable. Definitely. In other words, remember to take the scenic route. If it happens too fast don’t believe it – it’s probably not sustainable. If the trend starts to go against you think differently – what you’re doing may not be working. But don’t be surprised when an instant change vaporizes into thin air. It was never real to begin with… –Mike Photo credit: “November 7 2007 day 27 – Graphs, trends, averages, numbers…” originally uploaded by sriram bala Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Continuous Security Monitoring The Compliance Use Case The Change Control Use Case The Attack Use Case Classification Defining CSM Why. Continuous. Security. Monitoring? Database Denial of Service Countermeasures Attacks Introduction API Gateways Implementation Key Management Developer Tools Newly Published Papers Defending Cloud Data with Infrastructure Encryption Network-based Malware Detection 2.0: Assessing Scale, Accuracy, and Deployment Quick Wins with Website Protection Services Email-based Threat Intelligence: To Catch a Phish Network-based Threat Intelligence: Searching for the Smoking Gun Incite 4 U It’s you: The slippery use of terminology by the NSA, claiming that they only use metadata and don’t search people’s email content, is ludicrous. In the field of behavioral monitoring we use attributes and metadata (e.g., time of day, location, IP addresses of senders and recipients, type of request, etc.) to detect anomalous behavior – not content! All that’s needed is metadata grouped by or linked to a specific attribute, and then scan for behavioral patterns you deem suspicious. Terrorist detected, right? Keep in mind that an attribute – something like your cellphone number, email address, SIM chip ID, or a random ID token – is used as a reference for you. The NSA neither needs nor wants to read your content, or even know your individual identity, until after they have picked a target, because metadata is all you need for behavioral tracking. This word game is complete BS: saying they are not “reading your email” is a red herring. The fact is you, and your actions, are being monitored. McNealy was right all those years ago. You have no privacy. – AL Pointing the finger at the mirror: Man, Paul Proctor tells the hard truth in No One Cares About Your Security Metrics and You are to Blame. His main point is that senior management asks you for metrics because they have to – not because they want to, or even care. To change this you need to give them information that helps them make better decisions. He then goes through a bunch of metrics that are completely worthless to senior management, including number of attacks and number of unpatched vulnerabilities. Of course Paul doesn’t put any meat into the post because he wants you to become a client, which is fine. There is no free lunch. But I will reiterate a point he makes as well: it’s not that those typical metrics are totally useless. They are quite useful, but only in an operations context.

We spent a bulk of this series defining the major use cases for Continuous Security Monitoring, taking a journey through Attacks, Change Control, and Compliance. We know that many of you tend to be people of action, who want to just get going. But without a proper plan and definition for what you are trying to achieve with your security monitoring initiative, you will just end up with a lot of shiny expensive shelfware. Now you need to decide on the technology platform you will use to aggregate your data sources and perform the CSM analysis. You have a bunch of candidates, and probably a few already operational in your environment – though likely underutilized. We will cover the general requirements you need to cover, and then consider whether an existing platform can satisfy them. Not to spoiler the ending, but shockingly enough it will depend on your use case. Then we will discuss deployment models and the process involved to broaden our use cases. Selecting the CSM Platform Many folks feel their eyes glaze over when someone uses the word ‘platform’. Security folks have a long and tattered history with all sorts of ‘platforms’, none of which have really done what they were supposed (promised) to do. Now we have the opportunity to reset expectations, which is why looking at the CSM platform in terms of use cases is critical. Let’s start with the general platform requirements and what you need: Secure and scalable: Depending on your primary use case and the data sources you choose to aggregate, you may have significant scalability requirements. But for lighter use cases such as compliance, data storage demands are less intense. But we like planning for the future, which means picking a solution that can provide increased scale – even if you don’t need it yet. That comes back to architecture and deployment models, as described in our Security Management 2.0 paper. Keep in mind that the CSM environment includes sensitive data. So you will want to make sure your platform provides adequate security (strong authentication, data protection at rest, data integrity, etc.) to protect your information. Analytics: Monitoring is all about being able to find patterns in disparate data sources, which requires the ability to analyze lots of data. Does that mean you need “big data” analytics? Again it depends on the use case, but make sure you can both look for patterns you already know about (standard attack scenarios) and also unknown situations that are clearly not normal. Agentry: For the attack and change control use cases you will need to get information directly from monitored endpoints, which requires some kind of agent running on the devices. Does it need to be a persistent agent? Not necessarily. You can get much of the data you need via credentialed scans or dissolving agents. But for truly continuous monitoring you will need something on the device looking for indicators of malicious activity. Flexible alerting: Collecting data is good, but alerts make that data useful. You will want to ensure each alert provides enough information for you to actually do something about it. Whether that’s a poor man’s capability to manage an incident, or integration with a broad investigative platform, you will need some way to operationally use the information from the platform. With the increasing availability of third-party threat intelligence, you should also look for the ability to pull in external research feeds to search for specific indicators in the monitored environment. Visualization: A good dashboard environment offers user-selectable elements, and defaults for both technical and non-technical users. The dashboard should focus on the highest-level information (which devices are at risk, aggregate reports, system health, etc.), and provide the ability to drill down as appropriate. Given the current state of technology, a web-based interface with significant customization is now table stakes. Reporting: If compliance is your primary use case, then your requirements are all about reporting. You need to produce artifacts to document how the security monitoring environment substantiates the effectiveness of controls on devices in scope. Even if another use cases is your driver, you will need some measure of ongoing reporting to satisfy compliance requirements. Now that we know what the CSM platform is, let’s take a minute to mention what it doesn’t need to be – at least today: Real time: One of the biggest confusions in security monitoring is ‘real-time’. You are aggregating data from an event that already happened, so it cannot actually be in real time. That said, the sooner you get the data, analyze it, and are able to determine whether you have an issue, the better. Compliance doesn’t require any kind of real-time response. Change control requires more timeliness, for critical devices, and the attack use case can urgently require fast reaction, so the shorter the window between event and alert, the better. But keep in mind that ‘real-time’ alerts aren’t useful if you cannot respond in immediately. If you have a limited triage/investigations staff (and who doesn’t?), that minimizes the relevance of ‘real-time’ response. Big data centric: Big data is all the rage in all sorts of security discussions. But for compliance and change control big data is generally overkill. And depending on the capabilities of your adversaries, advanced analytics may not add value to your efforts. Eventually you may need a true security analytics platform with pseudo-real-time data collection to drive your CSM process. If you are facing truly advanced attackers you might need much more robust searching and forensics capabilities (perhaps including big data analytics). But if you are starting with compliance or change control advanced analytics are likely to be overkill. Doesn’t the SIEM Do This? You could certainly make a case that the SIEM/Log Management product you probably already have in place is in a good position to become the platform for CSM. SIEM does a good job with most of the requirements above. And SIEM already consumes most of the data sources needed for our use cases, with the exception of endpoint forensics and network packet capture… and a number of SIEMs are gaining the ability