Let's be realistic: The discussion of network security configuration management doesn't make security pros excited to jump out of bed in the morning. It's simply one of those tasks that must be done.
The problem is it should be top-of-mind, as a failure to properly manage network security configurations can be a career-ender, or as the security community calls it, a "Resume Producing Event (RPE)."
Why? In my experience, misconfiguration-based attacks, malicious network penetrations caused by improper network configurations, are second only to software bugs as an attack vector. In fact, attackers now use search engine APIs to automate the network misconfiguration search and reporting process. This sort of "Google hacking" has become a mainstream hacking technique and offers a wide array of attack vectors. For example, misconfigured servers can be found using queries like "intitle:index.of" or "inurl:index.of admin". Often in as little as 30 minutes, a malicious hacker can initiate a search, find a vulnerability announcement and begin active scanning and exploit.
Compounding this is the large mismatch seen between hardware and software platforms. Many business-critical systems are simply a patchwork of interfaces, communication channels and control systems. This becomes a security bottleneck, as some systems only support an eight-character password, but the application being hosted requires 10 characters. (An extreme example to be sure, but it makes the point.)
Security teams must choose to enable the easier password -- or the default settings -- simply to make the process work as the business requires. This makes the risk and regulatory profiles higher and in turn makes the incident-response time shorter. The key then is proactive configuration management, and today platforms exist to automate much of this process.
Automating network security configuration management
So why automate? Vendors are slowly leading us to a cross-functional world where security management, patch management, change management and help desk systems are all interconnected, which makes manual configuration management impractal. For instance, it's common to receive notification that a new application patch is available, but may need to be configured before it's implemented. The patch management system notes the new patch and makes a change request that generates a help desk ticket. The security configuration system is then instructed to make the needed policy update to the end users affected by the patch. When all of this is done transparently by the policy servers of each management system, the number of man hours is reduced, speed to deployment increased and risk profiles lowered.
While it may seem complicated, fortunately getting started with network security configuration management automation doesn't mean reinventing the wheel. There are a number of vendor products available to make the process easier. But as with any product selection, it's important to determine how the vendors and their products stack up. The following questions should serve as a starting point for those discussions. A solid network security configuration management product should offer:
- Policy modeling, visualization and verification of a security configuration.
- Distributed policy editing, delegation and distribution. This is crucial in large distributed enterprises with multiple offices, where ensuring a consistent policy is implemented across various network segments is crucial.
- Discovery of existing security configurations, policy conflicts and suggested resolution paths. It should also be capable of adaptive and/or context-aware security configurations.
- Testing, validation and enforcement of the security configuration once created to ensure compliance.
- Configuration-based security risk measurement and auditing or forensics tools.
- Security management for wireless and mobile networks.
There are a number of non-product-specific best practices to remember as well. First, the organization must have business-centric security policies that will provide a basis for the required configurations. While vendors provide policy templates, none of them know your business as well as you do. Start with policies that guide the security configurations to be managed by the system. Review compliance and regulatory requirements, as these are likely to offer insight into areas of your security profile that require improvement. Lastly, make use of existing security baselines already in the public domain to measure your risk profile before, during and after deployment of the system. Examples here include (but are not limited to):
Look for security configuration guidelines under each of these resource sites.
The good news is many of the vendors in this market take a holistic approach to configuration management and combine elements from vulnerability assessment tools, patch management with automated remediation and configuration compliance. This enables a proactive approach to building and managing configurations, enabling security teams to meet compliance guidelines, providing auditing capabilities, measuring configuration risk and ultimately lowering an enterprise's risk profile. Additionally with the burgeoning confluence of network and security management suites, today's products make it easier to establish a flexible, self corrective infrastructure that makes changes and improvements to the efficiency of security operations.
However, it's not all fun and games. As an experienced project manager, I can tell you that a network security configuration management implementation -- or any product implementation for that matter -- never goes quite as planned. With this technology, it is the inconsistencies between platforms that will cause the most grief during deployment. In other words, not every network security configuration management product is capable of working seamlessly with the devices and systems on the network. The vendors are doing a much better job in this area, but they don't always have the exact template needed for a particular router, server, application, etc. Some manual configuration will be necessary to make all devices speak the same language. This means man hours, and that means project budget. Still, despite the costs that come with deployment, the savings in operations will add up over time.
Network security configuration management projects are often driven by the need for compliance, but once you start realizing lower operational and incident-response costs, you'll wonder why you hadn't done it sooner. So use compliance (or whatever means available to you) to get initial funding, and then demonstrate to management that network security configuration management can drive down costs and improve efficiencies. You might even find it is a RBE (Resume Building Event).
About the author:
Tom Bowers, managing director of security think tank and industry analyst firm Security Constructs, holds the CISSP, PMP and Certified Ethical Hacker certifications, and is a well-known expert on the topics of data leakage prevention, global enterprise information security architecture and ethical hacking. His areas of expertise include aligning business needs with security architecture, risk assessment and project management on a global scale. Bowers serves as the president of the 600-member Philadelphia chapter of Infragard, is a technical editor of Information Security magazine, and speaks regularly at events including Information Security Decisions.
This was first published in May 2009