As you learned in Chapter 16, "Secure Network Management and Network Security Management," these issues (hereafter simply called management) are a difficult problem without a singular answer. I expect management to improve eventually, but the problems are rooted so deeply that they will continue for some time. The days of an intelligent system being able to make decisions about security on the network without your involvement are a long way off. As a security professional, you should therefore focus on systems that allow you to manage devices as cleanly as possible using the fewest number of tools and interfaces. The best practices in Chapter 16 provide some guidance in this area. Focus on the ease with which systems can be configured and the reliability and usefulness of the alarm data they generate.
NOTE
Although it is unlikely that an intelligent security system, one that can make attack response decisions for you, can be deployed in the near future, there are specific areas in which some intelligence might be possible. For example, a network device might be able to make assumptions about security posture based on the quantity of log messages generated on a device. If a system were under a denial of service (DoS) attack and dropped a huge number of packets based on access control list (ACL) violations, the number of Syslog messages generated by that host could rise dramatically. An intelligent management system could notice that trend and look at other nearby devices for further evidence of the nature of the problem. Some aspects of this "managing by exception" described here are already in use.
Management problems are caused by several factors, not the least of which is that security is not an absolute. The world would be a lot better if attackers agreed to set the "evil bit" in their packets before sending them on the wire, as Steven Bellovin suggests in the April Fools RFC 3514. Instead, security-monitoring tools are left the difficult job of assessing the malicious nature of inspected traffic on a sliding scale. Everything suspect can't receive the same amount of attention, or else management tools would project a constant state of hysteria. Also, for all the advancements security has made over the years, it is still a fairly new concept compared to the long history of IT in general. As time marches on, organizations such as the Internet Engineering Task Force (IETF) will drive standards that vendors will slowly adopt, thereby making interoperability (for example, with security events) easier.
The vendor community can take steps to improve management, too; some have already happened, and some are slowly happening. All revolve around making systems require less management as opposed to requiring smarter management tools. First, the tendency of newer operating systems to update themselves automatically should be viewed as a good thing. Although large enterprise networks certainly want to control when the operating system (OS) executes the update (to allow time for testing), the idea that my mom's computer at her home will periodically "phone home" to check for security updates is a step in the right direction. This not only helps consumers but small business as well. Scores of organizations do not have IT staff and require the ability to have reasonable security without lots of deliberate effort.
What would help even more is the configuration of more secure defaults into all networked devices. Great strides have been made in making network systems (particularly user PCs) easy to configure. With this ease of configuration, it should be easier for software vendors to ship systems in a more secure state by default. Because configuration is not difficult, the user experience should not be significantly affected. In addition to more secure defaults, vendors must invest in more security testing. I long for a day when old problems such as buffer overflows (Chapter 3, "Secure Networking Threats") are no longer a common sighting on security vulnerability mailing lists.
Part I. Network Security Foundations
Network Security Axioms
Security Policy and Operations Life Cycle
Secure Networking Threats
Network Security Technologies
Part II. Designing Secure Networks
Device Hardening
General Design Considerations
Network Security Platform Options and Best Deployment Practices
Common Application Design Considerations
Identity Design Considerations
IPsec VPN Design Considerations
Supporting-Technology Design Considerations
Designing Your Security System
Part III. Secure Network Designs
Edge Security Design
Campus Security Design
Teleworker Security Design
Part IV. Network Management, Case Studies, and Conclusions
Secure Network Management and Network Security Management
Case Studies
Conclusions
References
Appendix A. Glossary of Terms
Appendix B. Answers to Applied Knowledge Questions
Appendix C. Sample Security Policies
INFOSEC Acceptable Use Policy
Password Policy
Guidelines on Antivirus Process
Index