Research

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

As we described in the Introduction to Implementing and Managing Patch and Configuration Management, endpoint hygiene is key to endpoint security management. WIth the product (or service) in hand, it’s time to get the technology implemented and providing value as quickly as possible. You know the old saying, “if you fail to prepare, you prepare to fail.” It’s actually true, and the preparation in this situation involves ensuring your processes are solid, defining device coverage and roll-out priorities, figuring out what’s already out there, and finally going through a testing phase to make sure you are ready to deploy widely. So, let’s revisit the patch and configuration management processes. Determine Processes We are process centric at Securosis. We admit it, but only because we understand the folly of trying to implement and manage technology without proper processes and accountabilities defined before products get installed. So we start most activities with a check to ensure the process supports the problem to be solved. With patch and configuration management, you are looking at two distinct but tightly intertwined processes. To be clear, you don’t have to do all the functions described below. Figure out which will work for your organization. But you do need to make sure everyone understands what they are supposed to do – especially when it comes to remediation. If the operations team is expected to run through the patch process, open up the maintenance windows, and confirm the successful implementation of each patch, they need to know that. Likewise, if the incident response team needs to investigate strange configuration changes found during assessment, the handoffs must be clearly defined, as well as your ability to remediate a device under investigation. Patch Management Discover and define targets: Before you jump into the Patch Management process you need to define which devices will be included. Is it just endpoints, or do you also need to patch servers? These days you also need to think about cloud instances. The technology is largely the same, but increased numbers of devices make execution more challenging. Obtain patches: You need to monitor for release of relevant patches, and then figure out whether you need each patch, or you can work around the issue. Prepare to patch: Once the patch is obtained you need to figure out how critical the issue is. Is it something you need to fix right now? Can it wait for the next maintenance window? Once priority is established give the patch a final Q/A check to ensure it won’t break anything important. Deploy the patch: Once preparation is complete and your window has arrived, you can install. Confirm the patch: Patches don’t help if the install fails, so confirm that each patch is fully installed. Reporting: Compliance requirements for timely patching make reporting an integral function. Obviously this is a very high-level process description. If you want a much more granular process map for patch management, with metrics and cost models, check out Patch Management Quant. Configuration Management Establish configuration baselines and/or benchmarks: First define acceptable secure configurations for each managed device type. Many organizations start with benchmarks from CIS or NIST (PDF) for granular guidance on how devices should be configured. Discover and define targets: Next find the devices that need to be managed. Ideally you can leverage an endpoint security management platform with an integrated asset management repository. You will also want to categorize and group assets to avoid unnecessary services. Engineering workstations, for example, require different configurations than Finance systems. Assess, alert, and report changes: Once devices are discovered and categorized, define a frequency for assessments. How often will you check them against policy? Some vendors use the term “continuous assessment”, but their assessments aren’t really continuous. Fortunately this isn’t normally a problem – not least because most operational groups wouldn’t be able to validate alerts and correct issues in real time anyway. Remediate: Once a problem is identified, either it needs to be fixed or someone needs to grant an exception. You are likely to have too much work to handle it all immediately so prioritization is key. We offered some perspective on prioritization for vulnerability management, but the concepts are the same for configuration management. You will also probably need to verify that changes actually took place for the audit, as well as plan for a roll-back in case the change breaks something. Define Initial Priorities/Targets and Deployment Model After gaining consensus on the applicable processes and ensuring everyone knows their roles and responsibilities, it’s time to determine your initial priorities/targets to figure out whether you will start with the Quick Wins process or jump right into Full Deployment. Most organizations have at least a vague sense of what types of devices they need to patch and manage, but translating that into deployment priorities can be tricky. Let’s highlight some of the categories of things you can manage, which should help you figure out the best direction. Servers: (OS) Keeping server devices updated is essential for protecting them. Look to group servers logically based on function, so you can identify typical configurations and applicable patch windows for each class of device. Also factor in whether you are dealing with physical servers, private cloud instances, or public cloud instances, because managing each type differs dramatically. PCs: (OS) Though non-server PCs are rarely the ultimate target of an attack, they provide a way for attackers to gain a foothold within your organization, so they can jump laterally to attack servers. Group PCs logically based on job function and need for access to critical data stores. Keep in mind that laptops create unique problems for to patch and configuration management because they may connect to the network infrequently, so consider whether you want to tackle that as part of the initial deployment. Mobile devices: (OS) Quicker than you can say BYOD, you will need to more effectively manage the mobile devices (including smartphones) that access your network. The smartphone vendors provide utilities to update and enforce configuration policies

We are relaunching one of our more popular white papers, Tokenization vs. Encryption: Options for Compliance. The paper was originally written to close some gaps in our existing tokenization research coverage and address common user questions. Specifically, how does tokenization differ from encryption, and how can I decide which to use? We believe tokenization is particularly important, for several reasons. First, in an evolving regulatory landscape, we need a critical examination of tokenization’s suitability for compliance. There are many possible applications of tokenization, and it’s simpler and easier to use than many other security tools. Second, we wanted to dispel the myth that tokenization is a replacement technology for encryption, when in fact it’s a complimentary solution that – in some cases – makes regulatory compliance easier. Finally, not all of the claimed use cases for tokenization are practical at this time. These questions keep popping up, so we feel a relaunch is in order. This paper discusses the use of tokenization for payment data, personal information, and health records. The paper was written to address questions regarding the business applicability of tokenization, and therefore far less technical than most of our research papers. The content has been updated slightly to reflect some of the changes in the PCI Council’s stance on PCI and address some questions which arise when considering tokenization for PHI and PII. I hope you enjoy reading it as much as I enjoyed writing it. A special thanks to Intel and Prime Factors for sponsoring this research! Download: Tokenization vs. Encryption: Options for Compliance, version 2. Share:

Some days I miss when the kids were little. It’s not that I don’t appreciate being able to talk in full sentences, pick apart their arguments and have them understand what I’m talking about, or apply a heavy bit of sarcasm when I respond to some silly request. I don’t think I’d go back to the days of changing diapers, but there was a simplicity to child rearing back then. We don’t really appreciate how quickly time flies – at least I don’t. I blinked and the toddlers are little people. We were too busy making sure all the trains ran on time to appreciate those days. The other day the Boss and I were franticly trying to get dinner ready. Being the helpful guy I am (at times), I asked what was for dinner, so I could get the proper bowls and utensils. I think it was hot dogs, corn, and fruit salad. Once she said, “fruit salad,” I instinctively blurted out “Yummy Yummy.” She started cracking up. Those of you not going through the toddler phase over the past 7 years probably have no idea what I’m talking about. Those who have know I am talking about the Wiggles. I remember back to the days of watching those 4 Australians dance around to silly, catchy songs – and maybe even teach the kids a thing or two. But far more important at that time, the Wiggles kept the kids occupied for 30 minutes and allowed us frantic parents to get a little of our sanity back. So in a strange way, I miss the Wiggles. I don’t miss the time we drove up to Maryland for the holidays and the kids watched all of the Wiggles DVDs we had in a row. After 10 hours of that, if I saw any Wiggles I certainly wouldn’t have been wielding a Feathersword. And now that I think about it, most of the songs were pretty annoying. So I guess I don’t miss the Wiggles after all. But I do miss that stage when the kids were easier. When it was about learning the ABCs, not putting competitive grades on the board to get into a good college. When we could focus on learning T-ball skills, not what sport to specialize in to have any hope of playing in high school. When the biggest issue was the kids not sharing the blocks nicely, rather than the $tween hormonal mayhem we need to manage now. As I look back, the songs may not actually have been yummy, yummy, but those times were. –Mike Photo credits: Ben-Anthony-throw-fruit originally uploaded by OneTigerFan 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. Implementing and Managing Patch and Configuration Management Introduction Understanding and Selecting a Key Manager Introduction Defending Against Denial of Service (DoS) Attacks The Process Defense, Part 2: The Applications Understanding and Selecting Identity Management for Cloud Services Introduction Incite 4 U It’s about finding the unknown unknowns: I seem to constantly be talking to enterprises about SIEM, and they seem surprised when I state the obvious. Deploying this technology involves knowing what question you’re trying to answer, right? The idea of finding a targeted attack via correlation rules is pretty much hogwash. Wendy makes a good point in her recent Dark Reading post. She’s exactly right that having a lot of data doesn’t mean you know what to do with it. Data aggregation and simple correlation is only the first wave of the story. Harnessing new data analysis techniques, for those willing to make the investment, enables interesting technologies to identify patterns and indicate activity you don’t know about. Of course you still need some HUMINT (human intelligence) to figure out whether the patterns mean anything to your organization – like that you are under attack – but the current state of the art is finding what you already know, so this makes a nice improvement in the impact of analytics on security operations. – MR Ignorance is bliss: A recent study suggests that small organizations are confident in their security without any real plans. These results are really not surprising, and closely match my own research. Just about every small firm I speak with has no idea about what protections they should have in place. They also have no clue about possible threats. Sure, some are vaguely aware of what could happen, but they generally choose not to take the time or spend the money on security controls that could be ‘better’ spent elsewhere. But I worry more about the dozen or so small merchants I have spoken with, who must comply with PCI-DSS, but don’t understand any of the items described in their self-assessment questionnaires. It might as well be written in a foreign language. And of course they don’t have security policies or procedures to achieve compliance – they have passwords and a firewall, all managed by the same guy! Failure just waiting to happen. – AL 2008 called, and it wants its whitelist back: I read this announcement of new Forrester research calling for increased use of application whitelisting. Wait, what? I thought that battle was over – and we had all agreed that AWL is a good alternative for fixed function devices like kiosks, ATMs, factory floor equipment, and call center devices – but for knowledge workers not so much. At least that’s what Mr. Market says. To be fair, I agree with the concept. If malware can’t execute that’s a good thing. But the collateral user experience damage makes this a non-starter for many enterprises. Especially when there are other alternatives refining the behavioral approaches of the past. – MR Elephant in a box: While it’s not a security related issue, Teradata’s (TD) announcement