Research

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