Building the foundations of a good security management program is much like building an ice cream sundae. Not to imply that building a mature security management process is as easy, but quite honestly both have been around for long enough that we have some good guidance to rely on. Given that everybody’s tastes are different, and the same goes for their risk appetite, the programs that result from going through this process are generally the same but always slightly different.
My analogy is from the perspective of the ice cream shopkeeper, although this may work from the customer point of view as well. I’m behind the counter and my job is to make the sundaes when a customer orders. A customer comes in, reviews my menu, and places an order. The key is that I have a menu. Compare that to the “catalog” your security function has created. If you don’t have a menu how do your customers (i.e. the business, IT, outsourced customers, etc.) know what you can provide and at what level?
1. Consider creating a security services catalog to outline the services your security organization can provider to its customers.
Next, after I have the order, I need to know where everything is in order to start making the sundae. I need to first grab a bowl which will hold the contents of the sundae I’m about to create. I compare the bowl to the asset management function. I need something to base my sundae on, and having a nice solid bowl instead of one that is cracked or has holes in it will make my job easier, my customer’s happier, and probably result in fewer stains on clothing. Now consider your “asset management” bowl. How solid is it? Do you know where your assets reside, who owns them, what data they hold or process, or their level of criticality to your organization?
2. Ensure asset management is mature to create a solid foundation upon which to build your security management process.
If you ordered a sundae the next logical ingredient is the ice cream…so let’s go with two scoops. And let’s pretend one is your patch management process and the other is configuration management. Once we have a comprehensive view into our portfolio of assets through asset management we can now ensure that these are configured securely and consistently and that they are up-to-date with patches. This is my equivalent of making sure the ice cream is not spoiled by checking the expiration date on the containers, but also that my scoops are round and of the same size every time I make a sundae. I like this from an owner’s standpoint because sick customers don’t buy much ice cream and I also have a repeatable process to better understand pricing and profits…after all, I’m in this to make money. So start asking yourself, is the ice cream spoiled and if not, am I consistently scooping the right size servings? A better question may be, do all of my deployed (and future) technologies have a configuration standard? Are my patching processes mature enough to ensure that all of my OS’s, applications, and devices are patched in a timely manner?
3. Configuration management and patch management are key areas in a mature security management process. Ensure that all systems are deployed following a secure and consistently applied baseline standard and that teams responsible for patching have the right processes and technologies.
To add to the above statement, many people believe configuration management is a function of security only. And for some organizations this may be true. I’d contend that configuration management should be a function of IT. From an operational standpoint ensuring systems are consistently configured cuts down on change control testing since we can test on a known configuration and our tests and back out plans are now more accurate. This has implications on patch testing as well. How many times has your organization deployed a patch to 10 systems and 2 went down because of the patch? I’d venture to guess the 2 that went down, even after “successful” QA testing, were the result of some configuration inconsistency from the other 8 that had no issues. This only hinders patch application and makes IT, whose job is mainly to keep systems available, less likely to deploy that off-cycle patch…which is ironic since those tend to be the vulnerabilities that are more critical. Finally, patch application is no walk in the park either. We tend to lack agentless solutions that patch both the underlying OS as well as the application layer.
Back to my sundae. Now it is time for the whipped cream and a cherry on top. The whipped cream is comparable to the vulnerability management process. It blankets the ice cream, and hence ensures that patch and configuration management are “covered” and that we haven’t missed anything. My opinion is that vulnerability assessment (not management) is the check to ensure that configuration and patch management are effective. If they aren’t then I have holes in the whipped cream and I start to “see” the issues at a layer deeper. Think about this, how does your organization use vulnerability management, or even assessment? As a way to make up for a lack of mature asset management? Are you even checking configuration compliance at this point? Do you have so many vulnerabilities “out for remediation” that you can’t keep track of the current state of vulnerabilities in your environment? Think about how many of those are related to patch and configuration issues…what, almost all of them?
4. Vulnerability management and the assessment process should be used as a check to ensure that patch and configuration management are effective. If you’re using this process as a gap-filler for poor asset management, patch, and configuration management then you’re doing it wrong. You’ve probably created an unrepeatable and very heavy vulnerability management process that is ineffective (read: everyone outside of security despises you).
Let’s not forget the cherry…which is nice to have but if you didn’t get one you wouldn’t be too upset…which in my analogy is pen testing. I’m sure there are many “pen testers” that will disagree with that statement. My opinion is that pen testing is a nice to have and I’d challenge those who feel otherwise to explain the value from a pen test. Given enough time, money, and effort everything is breakable. Someone created it therefore someone else will, given my statement above, break it. Where I do believe pen testing is of value is in examining a critical applications in more depth and detail than a vulnerability assessment would. Keep in mind that VA tools only check from known vulnerable conditions and it is possible, although rare, that new vulnerabilities are identified through pen testing. There are also those who say “it shows the impact”…well, if you’re forced to show someone in management there is an impact then you haven’t done a very good job of relating technical vulnerabilities into business impacts and terms they understand. I’m sorry to say that this happens quite too often and in that case maybe a pen test is exactly what you need to bridge that gap. I’d put it this way:
5. Pen testing is a nice to have. If my asset, patch, configuration, and vulnerability management processes are mature and effective the pen tester should be extremely bored during my assessment. If you can’t explain the technical risk in terms of business risk (or you don’t have a risk management group) then hire a pen tester, but only as a last resort.
One caveat in all of my statements is that secure application development and strong network architecture exist. In addition, I’m also assuming that you have defined remediation processes, the right technology and people, and some repeatable processes as well. A stretch I know, but I can’t cover everything in one post J
Comments