Research

Sometimes things don’t go your way. Maybe it’s a promotion you don’t get. Or a deal you don’t close. Or a part in the Nutcracker that goes to someone else. Whatever the situation, of course you’re disappointed. One of the Buddhist sayings I really appreciate is “suffering results from not getting what you want. Or from getting what you don’t want.” Substitute disappointment for suffering, and there you are. We have all been there. The real question is what you do next. You have a choice. You can be pissy for days. You can hold onto your disappointment and make everyone else around you miserable. These people just can’t recover when something bad happens. They go into a funk for days, sometimes weeks. They fall and can’t seem to get up. They suck all the energy from a room, like a black hole. Even if you were in a good mood, these folks will put you in a bad mood. We all know folks like that. Or you can let it go. I know, that’s a lot easier said than done. I try my best to process disappointment and move on within 24 hours. It’s something I picked up from the Falcons’ coach, Mike Smith. When they lose a game, they watch the tape, identify the issues to correct, and rue missed opportunity within 24 hours. Then they move on to the next opponent. I’m sure most teams think that way, and it makes sense. But there are some folks who don’t seem to feel anything at all. They are made of Telfon and just let things totally roll off, without any emotion or reaction. I understand the need to have a short memory and to not get too high or too low. The extremes are hard to deal with over long periods of time. But to just flatline at all times seems joyless. There must be some middle ground. I used to live at the extremes. I got cranky and grumpy and basically be that guy in a funk for an extended period. I snapped at the Boss and kids. I checked my BlackBerry before bed to learn the latest thing I screwed up, just to make sure I felt bad about myself as I nodded off. That’s when I decided that I really shouldn’t work for other people any more – especially not in marketing. Of course I have a short-term memory issue, and I violated that rule once more before finally exorcising those demons once and for all. But even in my idyllic situation at Securosis (well, most of the time) things don’t always go according to plan. But often they do – sometimes even better than planned. The good news is that I have gotten much better about rolling with it. I want to feel something, but not too much. I want to enjoy the little victories and move on from the periodic defeats. By allowing myself a fixed amount of time (24 hours) to process, I ensure I don’t go into the rat hole or take myself too seriously. And then I move on to the next thing. I can only speak for myself, but being able to persevere through the lows, then getting back up and moving forward, allows me to appreciate all the great stuff in my life. And there is plenty of it. –Mike Photo credits: 24 Hours Clock originally uploaded by httsan 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. Building an Early Warning System Internal Data Collection and Baselining The Early Warning Process Introduction Implementing and Managing Patch and Configuration Management Configuration Management Operations Patch Management Operations New Papers Defending Against Denial of Service Attacks Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments Pragmatic WAF Management: Giving Web Apps a Fighting Chance Incite 4 U Who sues the watchmen? Whenever you read about lawsuits, you need to take them with a grain of salt – especially here in the US. The courts are often used more as a negotiating tool to address wrongs, and frivolity should never be a surprise in a nation (world, actually) that actually thinks a relationship between two extremely wealthy children is newsworthy. That said, this lawsuit against Trustwave and others in South Carolina is one to watch closely. From the article it’s hard to tell whether the suit attacks the relationship between the company and lawmakers, or is more focused on negligence. Negligence in an area like security is very hard to prove, but anything can happen when the call goes to the jury. I can’t think of a case where a managed security provider was held liable for a breach, and both the nature and outcome of this case could have implications down the road. (As much as I like to pick on folks, I have no idea what occurred in this breach, and this could just be trolling for dollars or political gain). – RM What does sharing have to do with it? Congrats to our buddy Wade Baker, who was named one of Information Security’s 2012 Security 7 winners. Each winner gets to write a little ditty about something important to them, and Wade puts forth a well-reasoned pitch for more math and sharing in the practice of information security. Those aren’t foreign topics for folks familiar with our work, and we think Wade and his team at Verizon Business have done great work with the VERIS framework and the annual DBIR report. He sums up the challenges pretty effectively: “The problem with data sharing, however, is that it does not happen automatically. You hear a lot more people talking about it than actually doing it. Thus, while we may have the right prescription, it doesn’t

The key high-level difference between configuration and patch management is that configuration management offers more opportunity for automation than patch management. Unless you are changing standard builds and/or reevaluating benchmarks – then operations are more of a high-profile monitoring function. You will be alerted to a configuration change, and like any other potential incident you need to investigate and determine the proper remediation as part of a structured response process. Continuous Monitoring The first operational decision comes down to frequency of assessment. In a perfect world you would like to continuously assess your devices, to shorten the window between attack-related configuration change and detection of the change. Of course there is a point of diminishing returns, in terms of device resources and network bandwidth devoted to continuous assessment. Don’t forget to take other resource constraints into account, either. Real-time assessment doesn’t help if it takes an analyst a couple days to validate each alert and kick off the investigation process. Another point to consider is the increasing overlap between real-time configuration assessment and the host intrusion prevention system (HIPS) capabilities built into endpoint protection suites. The HIPS is typically configured to catch configuration changes and usually brings along a more response-oriented process. That’s why we put configuration management in a periodic controls bucket in the Endpoint Security Management Buyer’s Guide. That said there is a clear role for configuration management technology in dealing with attacks and threats. It’s a question of which technology – active HIPS, passive configuration management, or both – will work best in your environment. Managing Alerts Given that many alerts from your configuration management system may indicate attacks, a key component of your operational process is handling these alerts and investigating each potential incident. We have done a lot of work on documenting incident response fundamentals and more sophisticated network forensics, so check that research out for more detail. For this series, a typical alert management process looks like: Route alert: The interface of your endpoint security management platform acts as the initial view into the potential issue. Part of the policy definition and implementation process is to set alerts based on conditions that you would want to investigate. Once the alert fires someone then needs to process it. Depending on the size of your organization that might be a help desk technician, someone on the endpoint operations team, or a security team member. Initial investigation: The main responsibility of the tier 1 responder is to validate the issue. Was it a false positive, perhaps because the change was authorized? If not, was it an innocent mistake that can be remedied with a quick fix or workaround? If not, and this is a real attack, then some kind of escalation is in order, based on your established incident handling process. Escalation: At this point the next person in the chain will want as much information as possible about the situation. The configuration management system should be able to provide information on the device, the change(s) made, the user’s history, and anything else that relates to the device. The more detail you can provide, the easier it will be to reconstruct what actually happened. If the responder works for the security team, he or she can also dig into other data sources if needed, such as SIEM and firewall logs. At this point a broader initiative with specialized tools kicks in, and it is more than just a configuration management issue. Close: Once the item is closed, you will likely want to generate a number of reports documenting what happened and the eventual resolution – at least to satisfy compliance requirements. But that shouldn’t be the end of your closing step. We recommend a more detailed post-mortem meeting to thoroughly understand what happened, what needs to change to avoid similar situations in the future, and to see how processes stood up under fire. Also critically assess the situation in terms of configuration management policies and make any necessary policy changes, as we will discuss later in this post. Troubleshooting In terms of troubleshooting, as with patch management, the biggest risk for configuration change is that might not be made correctly. The troubleshooting process is similar to the one laid out in Patch Management Operations, so we won’t go through the whole thing. The key is that you need to identify what failed, which typically involves either a server or agent failure. Don’t forget about connectivity issues, which can impact your ability to make configuration changes as well. Once the issue is addressed and the proper configuration changes made, you will want to confirm them. Keep in mind the need for aggressive discovery of new devices, as the longer a misconfigured device exists on your network, the more likely it is to be exploited. As we discussed in the Endpoint Security Management Buyer’s Guide, whether it’s via periodic active scanning, passive scanning, integration with the CMDB (or another asset repository) or another method, you can’t manage what you don’t know exists. So keep focus on a timely and accurate ongoing discovery process. Optimizing the Environment When you aren’t dealing with an alert or a failure, you will periodically revisit policies and system operations with an eye to optimizing them. That requires some introspection, to critically assess what’s working and what isn’t. How long is it taking to identify configuration changes, and how is resolution time trending? If things move in the wrong direction try to isolate the circumstances of the failure. Are the problems related to one of these? Devices or software Network connectivity or lack thereof Business units or specific employees When reviewing policies trends are your friend. When the system is working fine you can focus on trying to improve operations. Can you move, add, or change components to cut the time required for discovery and assessment? Look for incremental improvements and be sure to plan changes carefully. If you change too much at one time it will be difficult to figure out what worked and

Now that we have provided the reasons you need to start thinking about an Early Warning System, and a high-level idea of the process involved, it’s time to dig into the different parts of the process. Third-party intelligence, which we’ll discuss in the next post, will tell you what kinds of attacks you are more likely to see, based on what else is happening in the world. But monitoring your own environment and looking for variation from normal activity tell you whether those attacks actually ARE hitting you. Internal Data Collection The process starts with collecting data from your internal sources for analysis. Most of you already have data aggregated in a log management environment because compliance has been mandating log management for years. More advanced organizations may have a Security Operations Center (SOC) leveraging a SIEM platform to do more security-oriented correlation and forensics to pinpoint and investigate attacks. Either way, you are likely collecting data which will provide the basis for the internal side of your EWS. Let’s take a quick look at the kinds of data you are likely already collecting and their relevance to the EWS: Network Security Devices: Your firewalls and IPS devices generate huge logs of what’s blocked, what’s not, and which rules are effective. The EWS will be matching attack patterns and traffic to what is known about other attacks, so recognizing port/protocol/destination combinations, or application identifiers for next-generation firewalls, will be helpful. Identity: Similarly, information about logins, authentication failures, and other identity-related data is useful for matching against attack profiles received from the third-party threat intelligence providers. Application/Database Logs: Application specific logs are generally less relevant, unless they come from standard applications or components likely to be specifically targeted by attackers. Database transaction logs are generally more useful for identifying unusual database transactions – which might represent bulk data removal, injection attempts, or efforts to bring applications down. Database Activity Monitoring (DAM) logs are useful for determinining the patterns of database requests, particularly when monitoring traffic within the database (or on the database server) consumes too many resources. NetFlow: Another data type commonly used in SIEM environments is NetFlow – which provides information on protocols, sources, and destinations for network traffic as it traversing devices. NetFlow records are similar to firewall logs but far smaller, making them more useful for high-speed networks. Network flows can identify lateral movement by attackers, as well as large file transfers. Vulnerability Scans: Scans offer an idea of which devices are vulnerable to specific attacks, which is critical for the EWS to help pinpoint which devices would be potential targets for which attacks. You don’t need to to worry about Windows exploits against Linux servers so this information enables you to focus monitoring, investigations, and workarounds on the devices more likely to be successfully attacked. Configuration Data: The last major security data category is configuration data, which provides information on changes to monitored devices. This is also critical for an EWS, because one of the most important intelligence types identifies specific malware attacks by their signature compromise indications. Matching these indicators against your configuration database enables you to detect successful (and even better, in-progress) attacks on devices in your environment. After figuring out which data you will collect, you need to decide where to put it. That means selecting a platform for your Early Warning System. You already have a SIEM/Log Management offering, so that’s one possibility. You also likely have a vulnerability management platform, so that’s another choice. We are not religious about which technology gets the nod, but a few capabilities are essential for an EWS. Let’s not put the cart before the horse, though – we don’t yet have enough context on other aspects of the process to understand which platform(s) might make sense. So we will defer the platform decision until later in this series. Baseline Once the data is collected, before it is useful to the EWS you need to define normal. As we mentioned earlier, ‘normal’ does not necessarily mean secure. If you are anything like almost every other enterprise, you likely have malware and compromised devices on your network already. Sorry to burst your bubble. You need to identify indications of something different. Something that could represent an attack, an outbreak, or an exfiltration attempt. It might be another false positive, or it could represent a new normal to accept, but either way the baseline will need to adapt and evolve. Let’s highlight a simple process for building a baseline: Pick data source(s): Start by picking a single data source and collect some data. Then determine the ranges you see within the data set. As an example we will use firewall logs. You typically have the type of traffic (ports, protocols, applications, etc.), the destination IP address, the time of day, and whether the packet was blocked, from the log. You can pick numerous data sources and do sophisticated data mining, but we will keep it simple for illustration purposes. Monitor the patterns: Then collect traffic for a while, typically a few days to a week, and then start analyzing it. Get your inner statistician on and start calculating averages, means, medians, and frequencies for your data set. In our example you might determine that 15% of your inbound web traffic during lunchtime is SSL destined for your shipping cart application. Define the initial thresholds: From the initial patterns you can set thresholds, outside which traffic indicate a potential problem. Maybe you set the initial thresholds 2 standard deviations above the mean for a traffic type. You look at the medians and means to figure out which initial threshold makes sense. You don’t need to be precise with the initial threshold – you don’t yet have enough data or knowledge to know what represents an attack – but to give you a place to start. Getting back to our firewall example, a spike in outbound SSL traffic spike to 30% might indicate an exfiltration. Or it could indicate a bunch

Now that we have gone through all the preparation, deployed the technology, and set up policies, we need to operate our patch management environment. That will be our focus in this post. As we discussed in the Policy Definition post, there isn’t a huge amount of monthly leverage to be gained for patch management. You need to do the work of monitoring for new patches, assessing each new patch for deployment, testing the patches prior to deployment, bundling installation packages, and then installing the patches on affected devices. You will be performing each of those activities each month whether you like them or not. We have already delved into those monthy activities within the context of defining policies, so let’s take things a step deeper. Troubleshooting The biggest issue with Patch Management Operations is that a patch may not install properly, for whatever reason. So the first operational task is to ensure the integrity of the process – that the patch was installed and operates properly. As we described in Patch Management Quant in great detail, once the patch is confirmed the tool also needs to clean up any patch residue (temp files, etc.). In the event the patch doesn’t deploy properly, you go to a clean up step – which involves identifying the failed deployment, determining the reason for the failure, adjusting the deployment parameters, and eventually reinstalling. For instance, here are three typical patch failure reasons which can be isolated fairly easily: Relay fail: If you have deployed a hierarchical environment to better utilize bandwidth, your relay points (distribution servers) may not be operating properly. It could be a server failure or a network issue. If an entire site or location doesn’t successfully patch, that’s a strong indication of a distribution problem. It’s not brain surgery to diagnose many of these issues. Agent fail: Another likely culprit is failure of an endpoint agent to do what it’s supposed to. If installation failures appear more random this might be the culprit. You will need to analyze the devices to make sure there are no conflicts and that the user didn’t turn off or uninstall the agent. Policy fail: As unlikely as it is, you (or your ops folks) might have configured the policies incorrectly. This is reasonably common – you need to set up policies each patch cycle, and nobody is perfect. There are many other reasons a patch might not deploy properly. The point is to address one-off situations as necessary, but also to make sure there isn’t a systemic problem with your process. You will use this kind of troubleshooting analysis and data to move on to the next step of operating your patch environment: to optimize things. Optimizing the Environment Just like any other optimization process, this one starts with a critical review of the current operation. What works? What doesn’t? How long does it take you to patch 75% of your managed devices? 90%? 100%? Is that increasing over time, or decreasing? What types of patches are failing (operating systems, apps, servers, endpoints, or something else)? How does device location (remote vs. on-network) affect success rates? Are certain business units more successful than others? During the review, consider adding new policies and groups. Though be careful since patch management requires a largely manual effort each month, there is a point of diminishing returns to defining very rigid policies to achieve better automation. If you find the environment reasonably stable, periodic reviews become more about tuning polices than overhauling them. This involves revisiting your deployment and figuring out whether you have the right hierarchy to effectively distribute patches. Do you need more distribution points? Less? Are you optimizing bandwidth? Do you need to install agents to achieve more granular management? Or perhaps remove agents, if you can patch without persistent agents on the devices. You look for incremental improvement here, so changes should be highly planned-out and structured. This enables you to isolate the effect of each change and reevaluate each aspect iteratively. If you change too much at one time it will be difficult to figure out what worked and what didn’t. Also pay attention to maintenance of your environment. The servers and distribution points need to be backed up and kept current, along with updating the agents as needed. Obviously you need to test infrastructure software updates – just like any other patch or update – prior to deployment, but the patching system itself could be an attacker’s target, so you need to keep it up to date as well. We tend to be wary of automatic updating for most enterprise security tools – there are too many example of bad updates wreaking havoc for it to feel comfortable. Improvements in quicker implementation can easily be lost if you take down your environment while you try to back out a busted patch. Documentation Finally, you defined a bunch of reports earlier in the process, to run on an ongoing basis. Obviously you need these artifacts for compliance purposes, but pay attention to the operational data they generate yourself. Feed that information back into the process to continually improve your patch management. Share:

We are pleased to put the finishing touches on our Denial of Service (DoS) research and distribute the paper. Unless you have had your head in the sand for the last year, you know DoS attacks are back with a vengeance, knocking down sites both big and small. It is no longer viable to ignore the threat, so we all need to think about what to do when we inevitably become a target. This excerpt from the paper’s introduction should give you a feel for what we’re talking about. For years security folks have grumbled about the role compliance has assumed in driving investment and resource allocation in security. It has become all about mandates and regulatory oversight driving a focus on protection, ostensibly to prevent data breaches. We have spent years in the proverbial wilderness, focused entirely on the “C” (Confidentiality) and “I” (Integrity) aspects of the CIA triad, largely neglecting “A” (Availability). Given how many breaches we still see every week, this approach hasn’t worked out too well. Regulators pretty much only care whether data leaks out. They don’t care about the availability of systems – data can’t leak if the system is down, right? Without a clear compliance-driven mandate to address availability (due to security exposure), many customers haven’t done and won’t do anything to address availability. Of course attackers know this, so they have adapted their tactics to fill the vacuum created by compliance spending. They increasingly leverage availability-impacting attacks to both cause downtime (costing site owners money) and mask other kinds of attacks. These availability-impacting attacks are better known as Denial of Service (DoS) attacks. We focus on forward-looking research at Securosis. So we have started poking around, talking to practitioners about their DoS defense plans, and we have discovered a clear knowledge gap around the Denial of Service attacks in use today and the defenses needed to maintain availability. There is an all too common belief that the defenses that protect against run of the mill network and application attacks will stand up to a DoS. That’s just not the case, so this paper will provide detail on the attacks in use today, suggest realistic defensive architectures and tactics, and explain the basic process required to have a chance of defending your organization against a DoS attack. Direct Download (PDF): Defending Against Denial of Service (DoS) Attacks We would like to thank (in alphabetical order) Arbor Networks, Corero Network Security, F5 Networks, and Radware for licensing the content in this paper. Obviously we wouldn’t be able to do the research we do, or offer it to you folks for this most excellent price, without clients licensing our content. If you want to go back through the archives to see the blog series that formed the basis for this paper, here you go: Introduction The Attacks Defense, Part 1: the Network Defense, Part 2: Applications The DoS Defense Process Share:

Yesterday was Election Day in the US. That means hundreds of millions of citizens braved the elements, long lines, voter suppression attempts, flaky voting machines, and other challenges to exercise our Constitutional right to choose our leaders. After waiting for about 3 hours in 2008, I got smart and voted early this year. It took me about 45 minutes and it was done. Luckily I don’t live in a swing state, so I think I saw maybe 1 or 2 political ads throughout the cycle when I was traveling. I know folks that have been pummeled by non-stop robocalls, TV ads, radio blitzes, and annoying canvassers knocking on their doors will appreciate the relative silence they’ll hear tomorrow. But that’s all part of the process. US presidential candidates have the most sophisticated targeting and marketing machines in existence. Think about it. Each candidate probably spent $1B on the campaign, funded largely by big donors, and spent largely over the past 3-4 months. That’s a similar spend to what a Fortune 500 consumer products company spends on marketing, if not more. And all that marketing is to influence the “story” told by the mass media. Trying to manipulate press coverage to portray momentum, define story lines about candidates, and ultimately rile up the base and depress the competition. Amazingly enough, it’s very effective. Talking heads (many on the payrolls of political parties or specific candidates) appear daily to talk about how everything is rosy in their world, how their candidate has the momentum and will win in a landslide. There really is no unbiased view of a campaign. Then there are the polls. Hundreds of polls. Every day. With different results, all seemingly within the margin of error. And the polling numbers spun however they want. Let’s be clear about polls. They are biased because they take a statistical sample and apply certain voter turnout estimates to derive their numbers. That’s why some polls are consistently skewed towards one party or the other. But what happens if you average all the polls, build a big-ass model, and apply defensible algorithms to eliminate perceived poll bias for a decent estimate of the current state of the race? You get a predictive model of a likely outcome of the election. Which is exactly what Nate Silver has built. He was a former baseball analyst who built sophisticated models to estimate baseball player performance, and then applied his sabermetric kung fu to politics. His website was acquired by the NY Times a few years ago, and his accuracy has been uncanny. He called 49 out of 50 states in the 2008 presidential election and did well in 2010 as well. Could it be luck? Maybe, but probably not. Not if you believe in math, as opposed to punditry and hope. Since early in the Spring he’s shown the incumbent President as a solid favorite to be re-elected. Turns out he was right. Absolutely, totally right. Of course, throughout the campaign he became a target of folks on the other side of the aisle. Similar to the Salem witch hunts, folks who understand math have had to convince luddites that he isn’t a witch. What these folks don’t understand is that Nate Silver may have a specific ideological bent, but that’s not what his model is about. The data says what it says, and he reports a likelihood of victory. Not a projection. Not a guarantee. A likelihood. Models don’t lend themselves to exact precision. Nate would be the first to say there is a likelihood that his model was wrong and the election could have gone to the other candidate. That would have given his detractors the ability to put him and his models in a box. But it didn’t happen. Math won because math works. Models get better over time. They are never exact – not on complex systems anyway. Silver’s a numbers guy, which means he will continue to refine the model in every subsequent election. But it’s pretty close now, and that’s very impressive. The baseball pundits hated it when the math guys showed up and proved there is something to quantitative analysis. Now all the other sports are embracing the concepts. And yes, the politicians will pay more attention to quantitative methods over time as well. Anecdote is fine. Qualitative research has a place. But over time math wins. Which scares a lot of people because then pundits and other qualitative windbags have a lot less to talk about. When math wins, we all are winners… Especially guys like Rob Graham, who understand the models and how to game them for fun and profit. –Mike Photo credits: Math Doesn’t Suck originally uploaded by John Baichtal 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. Building an Early Warning System The Early Warning Process Introduction Implementing and Managing Patch and Configuration Management Defining Policies Integrate and Deploy Technologies Understanding and Selecting a Key Manager Introduction Understanding and Selecting Identity Management for Cloud Services Introduction Newly Published Papers Defending Against Denial of Service Attacks Securing Big Data: Security Recommendations for Hadoop and NoSQL Environments Pragmatic WAF Management: Giving Web Apps a Fighting Chance Incite 4 U Taking the path of least resistance: If I was a bad guy (and yes, I’m a bad guy, but I’m not a bad guy), I’d go after small business. Maybe that’s because I know too much. I know how much effort and money is spent by enterprises to protect themselves. They still stink, but they try. PCI guarantees that. But small business tends to spend far less and take security far less seriously. That means they are sitting ducks. And as Krebs shows time and time again, those ducks get slaughtered. This latest story

In the Introduction to the Early Warning System series, we talked about the increasing importance of threat intelligence for combating advanced attackers by understanding the tactics they are using right now against our defenses. With this intelligence, combined with information about what’s happening in your environment, you can more effectively prioritize your efforts and make better, more efficient use of your limited security resources. We also point out that law enforcement has been using this concept doing for decades. A critical infrastructure or high-profile tourist target has a deployed set of internal security controls (such as security guards, video surveillance, etc.). Police implement these controls based on their best assessment of the risk – within the constraints of their funding, resources, and expertise. Of course they cannot cover everything – nobody can. An attacker using fairly simple reconnaissance tactics can understand the visible controls and build an attack plan to evade them. Sound familiar? Police need something to help focus their efforts. Something to give them a clue about where to look for the next attack. That’s where threat intelligence comes in. In this case, law enforcement has folks who monitor threat sources (radical groups, weapons purchases, etc.) in order to identify patterns that could represent a tangible threat to a specific target. When law enforcement finds something they may act directly to neutralize the threat, or work with the targets to ensure they improve controls and watch for that particular class of threat. Of course commercial entities operate under different constraints – they cannot rely on an external party like government to provide sufficient threat intelligence. So commercial enterprises need to both deploy controls and build their own analysis capabilities to gather and process threat intelligence, which is neither easy nor quick. Investment and commitment are required, to look beyond your walls and try to become a bit less reactive to the attack space. You also need a structured process, to focus only on what you see internally, but also what’s happening externally. That what the Early Warning System is all about. The Early Warning Process An Early Warning System (EWS) involves implementing a systematic process to collect data internally, gather intelligence from third parties, and then analyze the information for particular dangers to your environment. We will first list each part, and dig into the functions through the rest of this series. Internal Data Collection/Baselining The first two steps in the process involve looking inward. We have done a ton of research over the past few years into technologies that enable you to analyze your security data. Whether your aggregation platform comes takes the perspective of SIEM / Log Management, Vulnerability Management, or even network forensics doesn’t really matter. But you need a tool to aggregate your security data, with the ability to also handle external information. Once the data is aggregated, the next step involves establishing a number of baselines to identify ‘normal’ for your environment. Of course normal is not really the right term – no environment is really normal. But you need to start somewhere. So equipped with baselines describing what typically happens in your environment, you can start looking for anomalies – deviations from those baselines – which may indicate something funky and thus bear further investigation. As a technology foundation for EWS, your existing tools could be entirely suitable. But most data aggregation tools are built to specifically for compliance. They are designed to put a lot of security data in one place and generate reports, but not so good at analysis or pattern detection – especially if you don’t know the patterns to look for in advance. Your EWS needs to be built on strong analytical tools – with a threat-centric view of the world rather than a focus on compliance reporting. External Threat Feeds Once you have your internal data in order, you cross-reference it against attacks seen in the wild via external threat research. You will quickly learn that there is no lack of threat data. Every vendor has a security research team, and they are constantly generating content – both for external consumption (mostly public relations) and for integration into their own products and services. There are also providers who generate stand-alone threat data feeds for integration into existing tools. So you need to identify the threat intelligence sources to use and manage the overlap between different sources. Finally, you need to integrate your feeds into the tool(s) you use to aggregate security data. Analyze The next part of the process is to provide context, for both the internal and external data you gathered, and systematically apply it to your specific situation. This requires not just data and an analytics engine to evaluate the data and find patterns. But the key is to interpret the data, and determine the degree of risk posed by each threat you analyze – to your environment. This is neither cheap nor easy to automate. We know of several organizations, each with dozens of folks processing threat intelligence and assessing the risk to their respective organizations. This is not common (and these folks have very mature security programs), but it’s simply not realistic to buy a toaster and expect it to pump out actionable threat intelligence. Act Finally you have information which might indicate an attack is coming. Of course you won’t have precision on when or where. So what do you do? Do you take action? Do you just monitor for indicators of the attack commencing? Do you do nothing and wait until systems are down before mopping up the mess? At one time or another you will likely find yourself doing each of the above. Equipped with contextual threat intelligence from your EWS, you can implement workarounds and remediations to address the issues you found. Or not, depending on your culture and ability to make bets that might be wrong. Of course that is an important concept, now and through the rest of this series. Building an Early Warning System doesn’t mean

We are pleased to announce the release of our white paper on securing big data environments. This research project provides a high-level overview of security challenges for big data environments. We cover the ways big data differs from traditional relational databases, both architecturally and operationally. We look at some of the built-in and third-party security solutions for big data clusters, and how they work with – and against – big data installations. Finally, we make a base set of recommendations for securing big data installations – we recommend several technologies to address specific threats to the data and the big data cluster itself, preferring options which can scale with the cluster. After all, security should support big data clusters, not break or hamper them. Somewhat to our surprise, a major task for this research project was to actually define big data. None of our past topics caused so much trouble identifying our topic. Big data clusters exhibit a handful of essential characteristics, but there are hundreds of possible functional configurations for creating a big data cluster. A concrete definition is elusive because there is an exception to almost every rule. One euphemism for big data is ‘NoSQL’ – which highlights big data’s freedom from traditional relational constraints, but there are relational big data clusters. In general we are talking about self-organizing clusters built on a distributed file model such as Hadoop, which can handle insertion and analysis of massive amounts of data. Beyond that it gets a bit fuzzy, and the range of potential uses is nearly limitless. So we developed a definition we think you will find helpful. Finally, I would like to thank our sponsor for this research: Vormetric. Without sponsorship like this we could not bring you quality research free to the public! We hope you find this research – and the definition – helpful in understanding big data and its associated security challenges. Download the research paper: Securing Big Data. Share:

So far we have focused on all the preparatory work and technology deployment that needs to happen before you can finally flip the switch and start using an endpoint security management tool in production. With the pieces in place it is now time to configure and deploy policies to prepare for the inevitable patch cycles, and to start monitoring configurations on your key devices. The first major choice is between the Quick Wins and Full Deployment processes – Quick Wins is focused on information gathering and refining priorities & policies – proving the tool’s value and making sure your results from initial testing weren’t misleading. Full Deployment is all about full coverage for all endpoint devices and users. We generally recommend you start with Quick Wins, which produces much more information and treads a bit more lightly, before jumping into Full Deployment. Who knows – you might even realign your priorities. But even after a few Quick Wins, a structured and (somewhat) patient path to Full Deployment makes the most sense. Iterative Deployment Before we get deep into staging your deployment, keep in mind that we break things out with extreme granularity, to fit the full range of organizations. Many of you won’t need this much depth, due to organizational size or the nature of your policies and priorities. Don’t get hung up on our multi-step process – many of you won’t need to move this cautiously, and can run through multiple steps quickly. The key to success is to think incrementally – too often we hear about organizations which can pump out a bunch of agents quickly, so they think they should. Endpoints can be finicky devices, and you should be sure to provide adequate time for testing and burn-in before you go all-in on deployment. So it’s prudent to pick a single device type or group of users, create the appropriate policy, slowly roll out, and tune iteratively until you attain full coverage. We are not opposed to deploying quickly, but we have a keen appreciation for the challenges of fast deployment – especially in managing expectations. Better to under-promise and over-deliver than vice-versa, right? So here is a reasonable deployment plan: Define the policy: This involves setting policies based on the type of device and what you are doing on it – patch or configuration management. We will dig into the specific policy decisions you need to make later in this post. Again, we suggest you start with a single device type – possibly even for a specific group of users – and expand incrementally once the first deployment is complete. This helps reduce management overhead and enables you to tune the policy. In most cases your vendor will provide prebuilt policies and categories to jumpstart your own policy development. It’s entirely appropriate to start with one of those and evaluate its results. Deploy to a subset: The next step is to deploy the policy to a limited subset (either device types, groups of users, or both) of your overall coverage goal. This limits the number of deployment failures, and gives you time to adjust and tune the policy. The key is to start small so you don’t get overloaded during the tuning process. It is much easier to grow a small deployment than to deal with overwhelming fallout from a poorly tuned policy. Analyze and tune: During analysis and tuning you iteratively observe results and adjust the policy. If you see too many deployment/remediation failures or false positives you adjust the policy. Expand scope: Once the policy is tuned you can start thinking about expanding the deployment scope and size. You can add additional devices and groups of users, expand the number of applications being patched, etc. Full deployments should rarely happen as a big bang, so grow it slowly and surely to ensure you don’t risk the perception of deployment success by going too far too fast. Smaller organizations can often move quickly to full deployment, but we strongly suggest starting small – even if it’s only for a day. When setting up the policies it makes sense to revisit the processes for both patch and configuration management – as they govern what the tool does, what you and your staff do, and what outcomes you can expect. So let’s touch on each process and the associated policy decisions you need to make. Patch Management Policies In a perfect world, the patch management engine would just run and you could get back to World of Warcraft. Alas, the world isn’t perfect and patch management isn’t nearly as automated as we would all prefer. You can automate some aspects of the process (including monitoring for new patches), but ultimately you need to define which patches get applied in what order and build the installation packages. The good news is that once this is done the tools generally do a good job of automating installation, confirmation, and tracking. But there is still significant work to do up front. Put another way, patch management policies are unique for every patch cycle. Of course you can define consistent aspects of the process (such as maintenance windows and user notifications) for every cycle, but every cycle you need to decide what gets patched and what doesn’t. 1. Discovery and Target Definition Depending on whether you are rolling out a Quick Wins limited deployment, extending an existing deployment, or going all-in with a big bang full deployment, the first step is to load up the system with the devices to be managed. Besides loading up the assets you need to decide what to do when a new device is found to be out of compliance with policy. Do you force a patch deployment right away? You also need to define the frequency of revisiting the asset list (daily, weekly, monthly, etc.), because new devices need some endpoint security management love as well. 2. Obtain Patches The next step in patch management is actually finding the patches applicable to your environment. Here

My kids love Halloween. They obsess about their costumes for weeks ahead of the big day. They go back and forth with their friends to coordinate their looks. Sometimes it works (XX2 will be a candy corn with all her friends), sometimes it doesn’t (XX1 couldn’t gain consensus amongst her friends). They love to collect all sorts of candy they won’t eat and await the sugar rush when we let them partake in a few after trick or treating. They like to swing by the awesome haunted house in the neighborhood. It’s a day when they can forget about their issues, challenges, homework, and hormone drama, and just be kids. Of course, a quarter of the country won’t have that option this year. Hurricane Sandy wreaked havoc on the Northeast Monday night and into Tuesday. It wasn’t pretty. The wrath of Mother Nature can be very destructive. Transformers exploding, hospitals being evacuated, flooding subways, trees down everywhere, and millions without power. They have bigger issues to worry about then whether the pumpkin outfit makes them look fat. One of the things I did notice about the real-time Twitter driven news cycle is the amount of faulty stuff out there. A hospital was on fire, except it wasn’t. The NYSE was flooded, but it wasn’t. Workers were trapped in a Con Ed facility that exploded, except they weren’t. We have known for a while that fact checking has gone the way of the Dodo, but this was ridiculous. Just more stark evidence that you can’t believe everything you read. It also pays to think about your disaster plan every once in a while. I know Rich has a bag ready to go in case aliens attack, which shows his early responder training and mentality. I thought my Dad’s wife was crazy when she installed a natural gas-powered generator at their house in NY to remove dependence on the power grid. She looks pretty smart today, as their entire town in Rockland County is dark. Except their house – and others with generators. Estimates are that it will take a week to restore power. Not fun. We all owe a debt of gratitude to the folks who will spend the next month cleaning up debris, opening up roads, restoring power, and getting things back to normal. And the construction business will likely see an uptick rebuilding a whole mess of the Jersey shore and Long Island. I know that’s trying to make lemonade out of a very sour lemon (especially to those whose houses floated away). But the area will recover. It always does. Thankfully we escaped the storm in ATL. The biggest issue we have to deal with is that it’ll be little cold tonight as we trick-or-treat, but it will be dry. I am hoping that all of you affected by the storm recover quickly and get power back in the near term. You wouldn’t want to miss out on the final week of Presidential Election politics, would you? –Mike Photo credits: Green Goblin originally uploaded by Javi M 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. Building an Early Warning System Introduction Implementing and Managing Patch and Configuration Management Integrate and Deploy Technologies Preparation Introduction Understanding and Selecting a Key Manager Introduction Understanding and Selecting Identity Management for Cloud Services Introduction Newly Published Papers Tokenization vs. Encryption Pragmatic Key Management for Data Encryption Incite 4 U Guidance on how to SecaaS: Sometimes I scratch my head wondering how acronyms happen, but since the Cloud Security Alliance has dubbed Security as a Service with the catchy term SecaaS (possibly pronounced “suck-aas”) I’ll go with it. It will give me a joke to use in speaking gigs for years. But Security as a Service actually is happening, and you probably should get a feel for what to look for. Kidding aside, the CSA just published a mess of implementation guides and the like to help you understand what you’re buying, what to expect from your provider, and how your operational environment needs to evolve to handle some SecaaS. I only had time to go through one of the documents (Security Assessment) and it’s pretty comprehensive and useful. I can’t speak to the rest of the documents yet, but this is good stuff. – MR Re-architect what exactly? Killing the Computer to Save It is a short – and interesting – bio of Peter G. Neumann, but the article focuses on his desire to rearchitect the Internet to make it secure. And this is the same line of reasoning I see from a lot of early Internet pioneers who lament the exclusion of security from the beautifully simplistic design of the Internet. But I still maintain that “We have not fundamentally redesigned our networks for 45 years, …” is not a problem. We cannot trust networks in a system which is open to every adversary who choses to participate, so I see no point redesigning the Internet in a pointless attempt to rectify that problems somehow. But if we learn one lesson from the Big Data security survey we did last month, it is that security cannot be bolt-on – it needs to be systemic. That’s not what we call “App Sec” today – system and application architectures that self validate – and hopefully that is the “Lessons From Biology” hinted at in the article. – AL Numb: I don’t normally highlight our own stuff in the Incite, as there is usually too much external stuff to poke fun at. But I don’t want to let a very important post fly by without some additional commentary. Rich recently wrote on Dark Reading about How the World Ended and No One Noticed. It’s true – the world has become