Research

As we discussed in the introduction post of our Ecosystem Threat Intelligence series, today’s business environment features increasing use of an extended enterprise. Integrating systems and processes with trading partners can benefit the business, but dramatically expands the attack surface. A compromised trading partner, with trusted access to your network and systems, gives their attackers that same trusted access to you. To net out the situation, you need to assess the security of your partner ecosystem; and be in a position to make risk-based decisions about whether the connection (collaboration) with trading partners makes sense, and what types of controls are necessary for protection given the potential exposure. To quote our first post: You need to do your due diligence to understand how each organization accessing your network increases your attack surface. You need a clear understanding of how much risk each of your trading partners presents. So you need to assess each partner and receive a notification of any issues which appear to put your networks at risk. This post will discuss how to assess your ecosystem risks, and then how to quantify the risks of partners for better (more accurate) decisions about the levels of access and protection appropriate for them. When assessing risks to your ecosystem, penetration tests or even vulnerability scans across all your partners are rarely practical. You certainly can try (and for some very high-profile partners with extensive access to your stuff you probably should), but you need a lower-touch way to perform ongoing assessments of the vast majority of your trading partners. As with many other aspects of security, a leveraged means of collecting and analyzing threat intelligence on partners can identify areas of concern and help you determine whether and when to go deeper and to perform active testing with specific partners. Breach History Investors say past performance isn’t a good indicator of future results. Au contraire – in the security business, if an organization has been compromised a number of times, they are considerably more likely to be compromised in the future. Some organizations use publicly disclosed data loss as a catalyst to dramatically improve their security posture… but most don’t. There are various sources for breach information, and consulting a few to confirm the accuracy of a breach report is a good idea. Besides the breach disclosure databases, depending on your industry you might have an ISAC (Information Sharing and Analysis Center) with information about breaches as well. Although there are some limitations in this approach. First of all, many of the public breach reporting databases are volunteer-driven and can be a bit delayed in listing the latest breaches, mostly because the volume of publicly disclosed breaches continues to skyrocket. Some organizations (think military and other governmental organizations) don’t disclose their breaches, so there won’t be public information about those organizations. And others play disclosure games about what is material and what isn’t. Thus checking out public disclosures is not going to be comprehensive, but it’s certainly a place to start. Mapping Your Ecosystem The next step is to figure out whether the partner has current active security issues, which may or may not lead to data loss. The first step will be to associate devices and IP addresses with specific trading partners, because to understand a partner’s security posture you need an idea of their attack surface. If you have the proverbial “big bat” with a partners – meaning you do a lot of business with them and they have significant incentive to keep you happy – you can ask them for this information. They may share it, or perhaps they won’t – not necessarily because they don’t want to. It is very hard to keep this information accurate and current – they may not have an up-to-date topology. If you can’t get it from your partner you will need to build it yourself. That involves mining DNS and whois among other network mapping tactics, and is resource intensive. Again, this isn’t brain surgery, but if you have dozens (or more) trading partners it can be a substantial investment. Alternatively you might look to a threat intelligence service specializing in third party assessment, which has developed such a map as a core part of their offering. We will talk more about this option under Quick Wins in our next post. Another question on network mapping: how deep and comprehensive does the map need to be. Do you need to know every single network in use within a Global 2000 enterprise? Because that would be a large number of networks to track. To really understand a partner’s security posture you should develop as comprehensive a viewpoint as you can, within realistic constraints on time and investment. Start with specific locations that have access to your networks, and be sure to understand the difference between owning a network and actually using it. Many organizations have large numbers of networks, but use very few of them. Public Malaise Now that you have a map associating networks with trading partners, you can start analyzing security issues on networks you know belong to trading partners. Start with Internet-accessible networks and devices – mostly because you can get there. You don’t need permission to check out a partner’s Internet-facing devices. In-depth scanning and recon on those devices is bad form, but hopefully attackers aren’t doing that every day, right? If you find an issue that is a good indication of a lack of security discipline. Especially if the vulnerability is simple. If your partner can’t protect stuff that is obviously be under attack (Internet-facing devices), they probably don’t do a good job with other security. Yes, that is a coarse generalization, but issues on public devices fail the sniff test for an organization with good security practices. So where can you get this information? Several data sources are available: Public website malware checking: There are services that check for malware on websites – mostly by rendering pages automatically on vulnerable devices and seeing whether bad stuff happens. Often a trading partner will buy these services themselves

Every company makes mistakes, especially when it comes to researchers disclosing security bugs and/or vulnerabilities. And when the frustrated researcher goes public and makes a scene, the company has a few choices. Break out the lawyers. Throw mud at the researcher in the press. Own the mistake and try to fix it. Yes there are other options. But we tend to see #1 and #2 a lot more than we see #3. Which is why I “like” (to use Facebook’s terminology) how they responded to the issue. The researcher in question basically showed how he could post to Zuckerberg’s timeline (yes, the CEO). That would usually cause some lawyerly type of activity from a company. But this was their response: I’ve reviewed our communication with this researcher, and I understand his frustration. He tried to report the bug responsibly, and we failed in our communication with him. Um, that’s pretty clear. Facebook accepted responsibility. They took their lumps, which is what they should do. They did explain that there wasn’t sufficient detail in the bug report, so it got routed incorrectly. But all the same, they didn’t shy away from their part in the situation. But far too many company’s don’t do that. But it gets better because Joe Sullivan, Facebook’s CSO, commits to a few changes to the program. We will make two changes as a result of this case: (1) We will improve our email messaging to make sure we clearly articulate what we need to validate a bug, and (2) we will update our whitehat page with more information on the best ways to submit a bug report. Now they still won’t pay a bounty because the vulnerability was proven against a real user (yes the CEO). But some folks in the security community, lead by Marc Maiffret, banded together and raised over $12K for the guy anyway. Win win. Which rarely happens when you are talking about vulnerability disclosure. Share:

Our updated and revised 2014 Endpoint Security Buyer’s Guide updates our research on key endpoint management functions, including patch and confirmation management and device control. We have also added coverage of anti- … malware, mobility, and BYOD. All very timely and relevant topics. The bad news is that securing endpoints hasn’t gotten any easier. Employees still click things, and attackers have gotten better at evading perimeter defenses and obscuring attacks. Humans, alas, remain gullible and flawed. Regardless of any training you provide employees, they continue to click stuff, share information, and fall for simple social engineering attacks. So endpoints remain some of the weakest links in your security defenses. As much as the industry wants to discuss advanced attacks and talk about how sophisticated adversaries have become, the simple truth remains that many successful attacks result from simple operational failures. So yes, you do need to pay attention to advanced malware protection tactics, but if you forget about the fundamental operational aspects of managing endpoint hygiene, the end result will be the same. The goal of this guide remains to provide clear buying criteria for those of you looking at endpoint security solutions in the near future. The landing page is in our Research Library. You can also download The 2014 Endpoint Security Buyer’s Guide (PDF) directly. We would like to thank Lumension Security for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our work. Share:

I spend a lot of time in public places. I basically work in coffee shops and spend more than my fair share of time in airports and restaurants. There is nothing worse than being in the groove, banging out a blog post, and then catching a whiff of someone – before I can see them. I start to wonder if the toilet backed up or something died in the wall. Then I look around the coffee shop and notice the only open table is next to you. no. No. NO. Yes, the sticky dude sits right next to you. Now I’m out of my productivity zone and worried about whether the insides of your nostrils are totally burned out. Sometimes I’m tempted to carry some Tiger Balm with me, just to put under my nose when in distress. Yes it would burn like hell, but that’s better than smelling body odor (BO) for the next couple of hours. It’s not just BO. How about those folks that bathe in stinky perfume? Come on Man! The Boy had a tutor once that just dumped old lady perfume on. I wonder if she thought we were strange because we had all the windows in the house open in the middle of winter. Finally the Boss had to tell her the perfume was causing an allergic reaction. Seems we’re all allergic to terrible perfume. I just don’t get it. Do these folks not take a minute to smell their shirt before they emerge from the house? Do they think the smell of some perfumes (like the scent that smells like blood, sweat and spit) is attractive or something? Do they have weak olfactory senses? Do they just not care? I know some cultures embrace natural human smells. But not the culture of Mike. If you stink, you should bathe and wear clean clothes. If you leave a trail of scent for two hours after you leave, you may be wearing too much perfume. There’s got to be a Jeff Foxworthy joke in there somewhere. What should I do? There are no other tables available in the coffee shop. I could throw in the towel and move to a different location. I could suggest to the person they are hygienically challenged and ask them to beat it. I could go all passive aggressive and tattle to the barristas, and ask them to deal with it. Maybe I’ll get one of those nose clips the kids wear when swimming to keep my nostrils closed. But I’ll do none of the above. What I’ll do is sit there. I won’t be chased away by some smelly dude. I mean, I paid my $2.50 to sit here as long as I want. So I pull the cover off my coffee and take a big whiff of java every 10 seconds or so to chase away the stench. By the way, it’s hard to type when you are inhaling coffee fumes. It’s unlikely I’ll get a lot done, but I have no where else to be, I can just wait it out. Which is stupid. My ridiculous ego won’t accept that body odor is likely covered under the 1st Amendment, so I couldn’t make the guy leave even if I wanted to. I’ll suffer the productivity loss to prove nothing to no one, instead of hitting another of the 10 coffee shops within a 5 mile radius of wherever I am. Thankfully I have legs that work and a car that drives. I can just go somewhere else, and I should. Now when the stinky dude occupies the seat next to you on a 7 hour flight, that’s a different story. There is no where to go, but 30,000 feet down. In that case, I’ll order a Jack and Coke, even at 10 in the morning. I’ll accidentally spill it. OOPS. You have to figure the waft of JD > BO every day of the week. -Mike Photo credit: “body_odor“_ originally uploaded by istolethetv Heavy Research We’re 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. Ecosystem Threat Intelligence The Risk of the Extended Enterprise Continuous Security Monitoring Migrating to CSM 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 The CISO’s Guide to Advanced Attackers 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 Define “Integration”: So Forrester’s Rick Holland took the time machine for a spin advocating for security solution integration and the death of point solutions. Nothing like diving back into the murky waters of the integrated suite vs. best of breed issue. It’s not like a lot has changed. Integration helps reduce complexity, at the alleged cost of innovation since it’s mostly big, lumbering companies that offer integrated solutions. That may be an unfair characterization, but it’s been mostly true. Then he uses an example of FireEye’s partnerships as a means to overcome this point solution issue. Again, not new. The security partner program has been around since Check Point crushed everyone in the firewall market with OPSEC in an effort to act big, even as a start-up. But the real question isn’t whether a vendor has good BD folks that can get contracts signed. It’s whether the solutions are truly integrated. And unless the same company owns the technologies, any integrations are a matter of convenience, not necessity. – MR Movies are real: Yesterday I had an interview with a mainstream reporter about some of the research presented at DEF CON this year. Needless to say, there was the ubiquitous “terrorism” question. It

Last week, IBM announced a deal to acquire Trusteer, an Israeli company focused on advance endpoint malware detection. The price tag was reported to be $800MM – $1B, so it was a pretty healthy 7-8x multiple of rumored 2013 bookings. Trusteer’s technology fills a huge gap in IBM’s advanced malware story. They do some stuff on their network (IPS) box, but without a real presence on the endpoint, their solution is limited. And for company pushing a total security solution story like IBM, you can’t really have holes. Not obvious one’s anyway. IBM has been selling Trend Micro’s endpoint security suite for years, but it hasn’t been a focus of their story and since the new security regime came in with the acquisition of Q1 Labs, any mention of endpoint security has largely been muted. Obviously that will change now that they have Trusteer (and their emerging enterprise capabilities) in their bag. To be clear, Trusteer didn’t get a huge valuation based on their story of disrupting the anti-virus market. They had built a signifiant market licensing their anti-malware toolbar for distribution through financial institutions. Basically, a bank provides Trusteer’s toolbar to their customers for free and a percentage of customers would use it, resulting in dramatically lower fraud rates for those protected customers. Of course, a bank can’t mandate the use of any technology to their customers, but the reduction in fraud for even the minority of protected devices was significant enough it became a no-brainer for the banks to write a very large check to Trusteer to cover their entire customer base. If anything after the deal closes, IBM’s global channels and presence selling technology to other financial institutions should provide a boost to Trusteer’s existing FI business as well. That’s how you justify writing that kind of check. This was a new path to market for security technology, and that provides a bulk of Trusteer’s existing revenue. But they had bigger designs to target the broader enterprise anti-malware market with a still raw, but interesting set of technologies for advanced malware protection. It’s early, but there is a clear opportunity for someone to totally disrupt the endpoint protection racket. Similar to what Palo Alto did to the perimeter firewall. IBM is betting on being able to spur that disruption. By combining Trusteer’s advanced endpoint protection capabilities with the BigFix endpoint management suite, they have pretty much everything the existing EPP vendors provide with better advanced malware protection. So getting rid of the incumbent is much more achievable, rather than asking a Fortune-class enterprise to trust a start-up. But IBM still has work to complete their endpoint security offerings. As described in our recent Endpoint Security Buyer’s Guide series, IBM now has better heuristics and some lockdown technologies. Though we expect endpoint activity monitoring to become a significant requirement over the coming few years, so that remains a gap in their offering. IBM also has to ensure they keep a good portion of the Trusteer expertise and DNA after the acquisition. They’ve been able to do so with the Q1 Labs acquisition, and as with most big M&A this is a critical success factor to get the value out of the deal. The fact that IBM has already made it clear that Trusteer’s Israeli-based research team will become a key part of a new IBM cybersecurity lab should help keep those folks for a little while. So is the beginning of the end for EPP? If you take a step back, EPP has been on a path to irrelevance for years. More than a few large enterprises have commented on how they are using the absolute cheapest means possible of checking the compliance box requiring AV and deploying these advanced products on critical endpoints. Providing years of suspect value will get customers to think like that. The good news for the existing EPP vendors is that their existing suites integrate some (but not all) of the advanced technologies needed to really address advanced malware. They’ve just done a very poor job at describing how their products have evolved, and that’s resulted in a clear negative market perception of the technology. We’ll be doing a more in-depth analysis of advanced endpoint protection starting next month, but suffice it say all the EPP guys don’t necessarily have to die during the transition. Yet the fact remains, they need to kill their golden goose if they are going to get there. If Big AV continues to position these new technologies as a minor upgrade with just a few added features to their existing offering (not to antagonize their installed base), they won’t create enough urgency to upgrade to the current version of the EPP suite. As we saw with the NYT breach (missing 44 out of 45 attacks) earlier this year, deprecated EPP is not much of a defense against modern, advanced attacks. These vendors basically need to make it very clear that the old stuff doesn’t work and make it very attractive to upgrade to the new stuff. This probably requires pulling support from the old suites despite the clear risk of customers picking a different solution when facing the upgrade. But we believe it’s a bigger risk to let 80% of their installed base use obsolete technology. We also should mention other huge winners as a result of this deal are the folks that do advanced endpoint protection, like Bit9, Bromium and Invincea. And Cisco gets some of these capabilities via the Sourcefire acquisition (who has bought Immunet a few years back). These emerging vendors have different approaches to solve the advanced malware problem, but with the valuation Trusteer was able to get they should feel pretty good about having a high value comp when they inevitably shop their companies. Photo credit: “Scrooge McDuck’s money bin for DuckTales Remastered at iam8bit gallery” originally uploaded by insidethemagic Share:

Much of the security industry spends significant time and effort focused on how hard it is to deal with today’s attacks. Adversaries continue to improve their tactics. Senior management doesn’t get it, until there is a breach… then your successor can educate them. And the compliance mandates hanging over your organization like albatross remain 3-4 years behind the attacks you see daily. The vendor community compounds the issues by positioning every product and/or service as a solution to the APT problem. Which means they don’t really understand advanced attackers at all. But complaining doesn’t solve problems, so we put together a CISO’s Guide to Advanced Attackers to help you structure a programmatic effort to deal with these adversaries. It makes no difference what a security product or service does – they are all positioned as the only viable answer to stop the APT. Of course this isn’t useful to security professionals who actually need to protect important things. And it’s definitely not helpful to Chief Information Security Officers (CISOs) who have to explain their organization’s security programs, set realistic objectives, and manage expectations to senior management and the Board of Directors. So as usual your friends at Securosis are here to help you focus on what’s important and enable you to wade through the hyperbole to understand what’s hype and what’s real. This paper provides a high-level view of these “advanced attackers” designed to help a CISO-level audience understand what they need to know, and maps out a clear 4-step process for dealing with advanced attackers and their innovative techniques. The landing page is in our research library. You can also download The CISO’s Guide to Advanced Attackers (PDF) directly. We would like to thank Dell Secureworks for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you without cost, without companies supporting our efforts. Share:

A key aspect of business today is the extended enterprise. That’s a fancy way of saying no organization does it alone anymore. They have upstream suppliers who help produce whatever it is they produce. They have downstream distribution channels that help them sell whatever needs to be sold. They outsource business processes to third parties who can handle them better and more cheaply. With the advent of advanced communication and collaboration tools, teams work on projects even if they don’t work for the same company or reside on the same continent. Jack Welch coined the term “boundaryless organizations” back in 1990 to describe an organization that is not defined by, or limited to, horizontal, vertical, or external boundaries imposed by a predefined structure. They are common today. In order to make the extended enterprise work, your trading partners need access to your critical information. And that’s where security folks tend to break out in hives. It’s hard enough to protect your networks, servers, and applications, while making sure your own employees don’t do anything stupid to leave you exposed. Imagine your risk – based not just on how you protect your information, but also on how well all your business partners protect their information and yours. Well, actually, you don’t have to imagine that – it’s reality. Let’s do a simple thought exercise to get a feel for the risk involved in one of these interconnected business processes. Let’s say that for cost reasons the decision was made to outsource software maintenance on legacy applications to an offshore provider. These applications run in your datacenter, and maintenance only involves pretty simple bug fixes. You can’t shut down the application, but it’s clearly not strategic. What’s the risk here? Start getting a feel for your exposure by asking some questions: Which of our networks do these developers have access to? How do they connect in? Who are the developers? Has the outsourcer done background checks on them? Are those checks trustworthy? What is the security posture of the outsourcer’s network? What kinds of devices do they use? Even if the developers are trustworthy, can you trust that their machines are not compromised? Yes, you can segment your network to ensure the developers only have access to the servers and code they are responsible for. You can scan devices on connection to your network to ensure they aren’t pwned. You can check the backgrounds of the developers yourself. You can even audit the outsourcer’s network. And you can still get compromised via business partners, because things move too fast to really stay on top of everything. It takes seconds for a machine to be compromised. With one compromised machine your adversary gains presence on your network and can then move laterally to other devices with more access than the developers have. This happens every day. The point is that you have very little visibility into trading partner networks, which means additional attack surface you don’t control. No one said this job was easy, did they? These interconnected business processes will happen whether you like it or not. Even if you think they pose unacceptable risk. You can stamp your feet and throw all the tantrums you want, but unless you can show a business decision maker that the risk of maintaining the connection is greater than the benefit of providing that access you are just Chicken Little. Again. So you need to do your due diligence to understand how each organization accessing your network increases your attack surface. You need a clear understanding of how much risk each of your trading partners presents. So you need to assess each partner and receive a notification of any issues which appear to put your networks at risk. We call this an Early Warning System, and external threat intelligence can give you a head start on knowing which attacks are heading your way. Here is an excerpt from our EWS paper to illuminate the concept. You can shrink the window of exploitation by leveraging cutting-edge research to help focus your efforts more effectively, by looking in the places attackers are most likely to strike. You need an Early Warning System (EWS) for perspective on what is coming at you. None of this is new. Law enforcement has been doing this, well, forever. The goal is to penetrate the adversary, learn their methods, and take action before an attack. Even in security there is a lot of precedent for this kind of approach. Back at TruSecure (now part of Verizon Business) over a decade ago, the security program was based on performing external threat research and using it to prioritize the controls to be implemented to address imminent attacks. Amazingly enough it worked. Following up our initial EWS research, we delved into a few different aspects of threat intelligence, which provides the external content of the EWS. There is Network-based Threat Intelligence and Email-based Threat Intelligence, but both of those sources are more about what’s happening on your networks and with your brands. These really help you understand what’s happening on your partner networks, which clearly pose a risk to your environment. So we are spinning up a new series to continue our threat intelligence arc. This series is called Ecosystem Threat Intelligence and will delve into how to systematically assess your extended network of trading partners to understand the risk they present. Armed with that information you will finally have the information to block a trading partner or tune your defenses based on the risk they pose. As with all our research, we will focus on tangible solutions that can be implemented now, while positioning yourself for future advances. As a reminder, we develop our research using our Totally Transparent Research methodology to make sure you all have an opportunity to let us know when we are right – and more importantly when we are wrong. Finally, we would like to thank BitSight Technologies for potentially licensing the paper at the end of this process. Our next post will delve into the types of information you need to assess your trading partners, and how it

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

Let’s wrap up our use case discussions for Continuous Security Monitoring by digging into how CSM can contribute to your compliance efforts. We know the way we staged these use cases (first attack, then change control) is bass-ackwards from how most folks implement monitoring. Compliance is typically the first use cases implemented, mostly because PCI-DSS mandates it. Regardless of how you adopt the technology, what you want to do is make sure whatever monitoring infrastructure you put in place will be extensible and relevant to all your use cases. We described the compliance use case as: Compliance 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. Dissecting the language above, you see that the goal of compliance is to document and substantiate the controls you have in place to pacify an auditor. It is not to solve actual security problems. Yes, that is a nuance, and if you adequately protect information assets you are likely be able to prove compliance. But the converse is clearly not true. Just being compliant does not mean you are secure. In terms of frequency of monitoring, you have a lot more leeway in this less-stringent use case. In the attack and change control use cases, you need to constantly monitor critical assets to identify dangerous situations. But to be compliant you basically need to assess devices quarterly or so. As long as you are collecting and parsing event logs on protected devices in a secure fashion (PCI Requirement 10), you’re good. Well, in terms of compliance, but not necessarily actual security. To be clear, logging is good. It helps when you have this information during incident response or investigation, so we are happy that PCI and other compliance hierarchies mandate it. PCI also specifically requires assessment after ‘significant’ change (Requirement 11.2.3), but what does that mean? That kind of nebulous verbiage both gives you the leeway to assess and monitor the devices when you want to, and it also gives the PCI council (and card brands) the leeway to string you up during a breach. Compliance mandates like PCI may also specify a more ‘continuous’ monitoring approach such as an IDS (Requirement 11.4), which is also a good practice. But remember – this use case isn’t about being secure – just meeting the base requirements expressly mandated by regulation and/or guidance. So putting up an IDS to monitor your perimeter and fire one alert meets the requirement. Compliance is great, right? We will get down off the soapbox now. Smart security professionals realize that compliance is a means to an end. They can use the compliance mandate to free up budget for equipment and processes that also assist with the attack and change control use cases. Data Sources The data sources you use for compliance tend to be pretty consistent with the attack use case, though without the more sophisticated telemetry and forensic data to really figure out what happened: Assets: Your asset base is the fundamental data source for all use cases. At least that’s consistent – you need an ongoing discovery capability to detect new devices on your network, and then a mechanism for profiling and classifying them. Events & Logs: Pretty much everything can and should be logged as part of the compliance use case – including security gear, network infrastructure, identity sources, data center servers, and applications, among others. This is helpful to demonstrate that the controls in place work, which is the goal of this use case. Patches: Keeping a device up to date is typically mandated by compliance regulations, so you need to generate reports showing which devices were updated when. Configurations: Another aspect of compliance is implementing and maintaining secure configurations. You will need to document the posture of protected devices periodically. Differentials and history are less important because compliance is based on a point-in-time view at your infrastructure. Vulnerabilities: Mandates also require periodic vulnerability scans of protected devices. So you need to document what was scanned, what was found, and eventually what was fixed, if the scan showed clear deficiencies. Other Documentation: Some mandates also require periodic penetration tests and other less automated functions. So you need the ability to store this unstructured data in the CSM repository as well, if it will be used as a compliance automation platform. Preparing for the Audit As opposed to a more action-oriented decision flow, as you saw with the attack and change control use cases, compliance is all about using data to prepare for assessment. You know when you need to be ready – it’s not like auditors show up as mystery shoppers to surprise you. You also know the nature of the documentation you need to provide. Shame on you if you aren’t prepared for an audit, when you know exactly what’s expected and when you need to be ready to deliver it. To help you prepare for an audit and make it as painless as possible, here is a streamlined process adapted from Mike’s Pragmatic CSO methodology. Describe Your Security Program: Wait, what? What about blasting the auditor with all sorts of reports to convince them you know what you’re doing? There is plenty of time for that, but only after you provide context for your security program – specifically how your CSM capabilities provide an accurate and timely view of information needed to understand your compliance posture. Address Past Deficiencies: This is probably not your first audit, so you need to update the auditor on how you addressed previous findings. Here you can leverage your CSM platform to search for specifics and substantiate fixes for issues pointed out in the last assessment. One of the best ways to build your credibility with the assessor is to own your past mistakes and prove that you have fixed things. Substantiate Your Controls: Now you can work through the data, showing the assessor that you have implemented the necessary controls effectively. This documentation should be