Research

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

Getting ahead of the attackers is the holy grail to security folks. A few years back some vendors sold their customers a bill of goods, claiming they could “get ahead of the threat.” That didn’t work out so well, and most of the world appreciates that security is a reactive situation. The realistic objective is to reduce the time it takes to react. We call this React Faster and Better. The foundation of the philosophy is an effective incident response process. But you can shrink the window of exploitation by leveraging cutting-edge research to help focus your efforts more effectively. You need an early warning system for perspective on what’s coming at you. Pragmatic Intelligence Back in 2007 when the Pragmatic CSO was written, prioritization was a key part of the operational methodology espoused as part of the P-CSO process. Over the past 5 years we have kept focus on the importance of prioritizing your limited funding, resources, and expertise, on the highest-value activities. To get a feel for how this concept works, let’s excerpt a small section from the Pragmatic CSO: [A key operational discipline is] figuring out the most likely exposure and working to eliminate it. This is particularly hard because many CSOs run from emergency to emergency without ever getting a chance to manage their security environment or even spend 10 minutes thinking about what is next. Unfortunately, what’s next has already happened. Clearly this situation must be addressed. “A good hockey player plays where the puck is. A great hockey player plays where the puck is going to be.” – Wayne Gretzky The great ones, in whatever pursuit, figure out how to anticipate what is most likely to happen, so they are ready if it does. Some think it’s luck, others figure it’s a talent bestowed by a higher power. Actually, in most cases, it is the result of a tremendous amount of hard work. The ability to anticipate is especially critical in security because of the unlimited number of possible attacks across an infinite attack surface. You cannot cover all the bases, so you need to be focused and choose correctly. What is the best way to choose correctly? You need an “inside man” working on your behalf to figure out what the bad guys are working on. Thus, security research plays a critical role in the life of a Pragmatic CSO. It’s hard to believe, but Pragmatic CSOs read a lot. They are plugged into the underground networks of researchers that spend time penetrating the hacker networks and tracking down the bot masters to figure out what they are working on. If you know what the bad guys are focused on, you can get a real good idea about what they are planning to strike next. Even though you don’t have to spend money to get connected with the research folks, a number of services focus on reporting new exploits and figuring out what is most likely to be attacked on any given day. Of course context is everything, so although third party research may give you a clue to what the next exploit or botnet looks like, it cannot tell you how it will be used against your defenses. You need to provide that context, which requires looking at the situation from two different perspectives: In Here: This is the internal perspective gleaned from what’s happening on your network. Whether the platform to aggregate and analyze the data is a SIEM or a Vulnerability Management platform or any other technology, the point is the same. The foundation for context is a clear understanding of what’s going on within your environment. Then you can move on to the next view for an idea of what’s exposed and what needs to be fixed right now. Out There: The reverse perspective looks at the macro environment, understanding attacker tactics and exploits, and then figuring out how they will affect you. If you know about attacks you can preemptively implement protections. Obviously you need to walk before you run, so getting a handle on your internal security data is a necessary first step. But once you are there, factoring in the external view can really help narrow down your attack surface. 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 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. But this approach fell out of favor over the past 5-7 years as the entire industry got weighed down by the compliance albatross. Now that the pendulum is swinging back toward actually securing stuff, we see a resurgence of threat intelligence as a way to make our defenses more effective and efficient. Let’s run through the history of security research, now typically called threat intelligence. The Evolution of Threat Intelligence Back in the day, security research really meant anti-virus research. The AV companies would look at viruses, build signatures, and move on to the next one. It was a fairly collegial environment, and AV companies shared the malware they discovered, making sure everyone was protected within a couple hours. The next wave of research resulted from the avalanche of spam, which required security companies to build global networks of honeypots to capture bad email directly, create signatures to identify it, and distribute the signatures to their gateways. Of course, that lasted only until the spammers became more effective at evading signatures, which drove heavier reliance on behavioral indicators to infer which files were malware and which messages were spam. This required security vendors to spend time evaluating behavior and tuning their detection cocktails to maintain efficiency. At about this time, IP and file reputation started to be more

By this point planning should be complete. You have designed your patch and configuration management processes, defined priorities to manage the devices in your environment, figured out which high-level implementation process to start with, discovered the devices in your environment, and performed initial testing to make sure the new technology doesn’t break anything. Now it’s time to integrate the patch and configuration management tools into your environment. Enough of this planning stuff, let’s get down to business! But you won’t actually remediate anything yet – the initial focus is on integrating technical components, installing agents as necessary, and preparing to flip the switch. Component Overview We are grouping patch and configuration management together, so we will talk about generic concepts like management servers and agents. A management server might be specifically associated with a patch management product and/or the configuration management environment. Obviously you want leverage between the two, but depending on which technologies you selected you might have different consoles and agents. But the deployment considerations are similar, regardless of the specific use case. Before we describe specific components we need to briefly go over the inherent security requirements of the different components. If an attacker can change the configuration of a device or apply a malicious patch, it’s pretty much game over. So it’s important to make sure the components are deployed correctly with appropriate security controls. Most solutions use some type of cryptography, both for authentication and to protect communications between components. We are not religious about specific authentication mechanisms (PKI or Windows or whatever), but be sure to check for recent attacks or vulnerabilities for whichever technologies you depend on. You may also want to consider two-factor authentication or some kind of privileged user management technology to better protect the management console. You will also need to coordinate with the network team to make sure the proper firewall ports are open (and/or proxies identified) to receive updates/new patches from vendors, and to communicate with the relays and/or endpoints using the ports specified by your endpoint security management vendor. Be considerate of the network security team, of course, who will likely resist opening up all sorts of ports throughout the environment. Default deny is still your friend – so when planning the deployment make sure you understand where the servers, distribution points & relays, and agents will be implemented, and how they communicate. Management Server/Appliance The management server is the brains of the operation. It holds the policies and provides the focal point for data aggregation, analysis, visualization, and reporting. You have a few options for how to implement the management server, so let’s discuss the pros and cons of each. Software: The most common choice is to install software on a dedicated server. Depending on your product this might actually run across multiple physical servers for different internal components such as a back-end database, or to distribute functions for better performance. Some products require different software components running concurrently to manage different functions. This is frequently a legacy of mergers and acquisitions – most products converge on a single software base, although integration may not be as complete as you would expect. Management server overhead is generally fairly low, especially outside large enterprises, so this server often handles some network monitoring, functions as the email MTA (for alerting), and manages endpoint agents. A small-to-medium-sized organization generally only needs to deploy additional servers for load balancing or hot standby. Integration is easy – install the software and position the physical server wherever needed, based on deployment priorities and network configuration, ensuring visibility to the relays and/or agents that need to communicate with it. Appliance: In this scenario the endpoint security management software comes preinstalled on dedicated hardware, presumably with a locked-down secure operating system. There is no software to install, so the initial integration is usually a matter of connecting it to the network and setting a few basic options – we will cover the full configuration later. As with a standard server, the appliance usually includes the ability to run multiple functions (though you might need licenses to unlock capabilities). Virtual Appliance: The endpoint security management software is preinstalled into a virtual machine for deployment as a virtual server. This is similar to an appliance but requires work to get up and running on your virtualization platform of choice, configure the network, and then set up the initial configuration options as if it were a physical server or appliance. For now just get the tool up and running so you can integrate the other components. Do not deploy any policies or turn on monitoring yet. Agents (or Not) Endpoint agents are, by far, the most varied patch and configuration management components. There are huge differences between the various products on the market, with far more severe performance constraints running on general-purpose workstations and laptops than on dedicated servers. Fortunately, as widely as features and functions vary, the deployment process is consistent. Test, then test more: We know we keep telling you to test your endpoint agents, but that’s not an accident – inadequate testing is the single most common problem people encounter. If you haven’t already, make sure you test your agents on a variety of real-world systems in your environment to make sure performance and compatibility are acceptable. That’s why choosing test devices in the preparation step is so important. Create a deployment package or enable in your EPP tool: The best way to deploy any agent is to use whatever software distribution tool you already use for normal system updates. There is no need to reinvent the wheel here. This means building a deployment package with the agent configured to connect to the patch and/or configuration management server. Remember to account for any network restrictions that could isolate endpoints from the server. In some cases the agent may be integrated into your existing EPP (Endpoint Protection Platform) tool. More often you will need to deploy an additional agent, but if it is fully integrated