1: |
If you have limited resources, which kinds of devices should be hardened first? |
A1: |
Since applications are the most common conduit for a network intrusion, securing critical hosts and their applications should be the top priority. Following that, the devices you rely on to perform security functions should be hardened. |
2: |
Out of the box, are servers or desktop PCs more vulnerable to attack? |
A2: |
There isn't a hard-and-fast rule here, but most often it is servers that are the most vulnerable. For example, installing a standard Linux system might leave lots of services running, all of which must be disabled or hardened. A desktop OS such as Microsoft Windows 98 isn't usually running any listeners that can be attacked directly. Most vulnerabilities in desktop OSs require the user to do something wrong (open an infected attachment, browse a malicious website, and so on). |
3: |
How should the documentation for device hardening be tracked within an organization? |
A3: |
Remember from Chapter 2, "Security Policy and Operations Life Cycle," that there are three elements to a security policy: policies, standards, and guidelines. Your device-hardening documents should be standards for all required steps and guidelines for any optional hardening tasks. Both of these can be contained within the same document by embedding the guidelines as optional elements within the standards. |
4: |
Can you think of any ways in which proper host hardening might help identify rogue systems? |
A4: |
If you are able to implement host hardening for IT-managed servers and hosts, it should be much easier to identify rogue systems on the network through automated scanning. Say, for example, one of your host-hardening techniques is to turn off the Telnet listener on all systems in favor of SSH. One easy way to find rogue systems is to search for Telnet listeners on the entire network. Any that respond will fall into one of three categories. First, it could be an IT-managed system you missed fixing. Second, it could be an IT-managed system that is a security policy exception. Third, it could be a rogue system. |
5: |
As an exercise to learn more about the hardening process, go online and find information about hardening the OS you are running. Implement the hardening tasks. How difficult was the process? Are there any tools for your OS to make the hardening process easier? How secure was your system before you started the hardening process? |
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