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



Network Security Architectures
Network Security Architectures
ISBN: 158705115X
EAN: 2147483647
Year: 2006
Pages: 249
Authors: Sean Convery

Flylib.com © 2008-2020.
If you may any questions please contact us: flylib@qtcs.net