The first of my Infrastructure Security Research Agenda 2011 posts, introducing the concept of positivity, generated a lot of discussion. Not only attached to the blog post (though the comments there were quite good), but in daily discussions with members of our extended network. Which is what a research agenda is really for. It’s a way to throw some crap against the wall and see what sticks.

Posturing

So let’s move on to the next aspect of my Ingress research ideas for the next year. It’s really not novel, but considering how awful most organizations are about fairly straightforward blocking and tackling, it makes sense to keep digging into this area and continue publishing actionable research to help practitioners become a bit less awful.

I’m calling this topic area Posturing because it’s really about closing the doors, battening down the windows, and making sure you are ready for the oncoming storm. And yes, it’s storming out there. We did talk about this a bit in the Endpoint Security Fundamentals series under Patching and Secure Configurations. There are three aspects of Posturing:

  1. Vulnerability Management: Amazingly enough, we haven’t yet written much on how to do vulnerability management. So we’ll likely focus on a short fundamentals series, and follow up with a series on Vulnerability Management Evolution, because with the advent of integrated application and database scanning – combined with the move towards managed services for vulnerability management – there are plenty of things to talk about.
  2. Patching: No it’s not novel, but it’s still a critical part of the security/ops guy’s tool box. As the tools continue to commoditize, we’ll look at what’s important and how patching can & should be used as a stepping stone to more sophisticated configuration management. The process (laid bare in Patch Management Quant) hasn’t changed, but we’ll have some thoughts on tool evolution for 2011.
  3. Configuration Policy Compliance: Pretty much all the vulnerability management players are looking at auditing device configurations and comparing reality to policy as a logical extension of the scans they already do. And they are right, to a point. In 2011 we’ll look at this capability as leverage on other security operational functions. We’ll also document the key capabilities required for security and an efficiency – beyond managing configuration changes for policy compliance.

To be honest I’m not crazy about the term Posturing, but I couldn’t think of anything I liked better. This concept really plays into two aspects of our security philosophy:

  • Reduce attack surface: A configuration policy with solid vulnerability/configuration/patching operations help close the holes used by less sophisticated attackers. Positivity falls into this bucket as well, by restricting the types of traffic and executables allowed in our environments.
  • React faster: By watching for configuration changes, which can indicate unauthorized activity on key devices (generally not good), you put yourself in position to see attacks sooner, and thus to respond faster. Yes, we are doing a lot of research into what ‘response’ means here, but Posturing can certainly be key to making sure nothing gets missed.

React Faster and Better

We beat this topic to death in 2010, so I’m not going to reiterate a lot of that research beyond pointing to the stuff we’ve already done:

We’re also working on the successor to Incident Response Fundamentals in our React Faster and Better series. That should be done in early January, and then we’ll focus our research in this area on implementation and success, which means a few Quick Wins series. These will probably include:

  1. Quick Wins with Network Monitoring: You know how I love monitoring, and clearly understanding and factoring network traffic into security analysis can yield huge dividends. But how? And how much?
  2. Quick Wins with Security Monitoring: Deploying SIEM and Log Management can be a bear, so we’ll focus on making sure you can get quick value from any investment in this area, as well as ensuring you are setting yourself up for a sustainable implementation. We have learned many tricks over the past few years (particularly from folks who have screwed this up), so it’s time to share.

Once much of this research is published, we’ll have a pretty deep treatment of our React Faster and Better concept.

Share: