When reviewing publications and commentary about security principles, you frequently encounter the postulate "security through obscurity is not security." Although it is said often, it is frequently misunderstood and is used as an excuse or justification for all sorts of security ills. Let's consider a few scenarios to better understand this axiom:
The preceding example focuses on obscuring the knowledge of the brand of a security technology you deploy. The next example considers the value of obscuring the fact that you use a security technology at all in your network:
Although you should not deploy a NIDS if someone who knows it is deployed could get around it, you should keep its specific configuration and location private. Here, you are not practicing "security through obscurity," you are practicing common sense.
There is a good paper on defeating an NIDS at the following address: http://secinf.net/info/ids/idspaper/idspaper.html.
Also realize that NAT (and, to a lesser extent, firewalls) can make your overall network less secure since the applications your users run will try to tunnel over ports you are permitting (such as TCP port 80). This makes it harder to categorize the traffic. Certainly, the benefits outweigh the drawbacks of firewalls in most cases, but be aware of these issues when designing your access control policies.
These cases are intended to show the importance of making sure your design is as indifferent as possible to what others know about it. Consider cryptography: it is an accepted practice in the security community to vet algorithms to broad audiences and thus ensure that the strength of the cipher stands on its own, not on whether the attacker has figured out the algorithm.
This does not mean you should never make use of obscurity mechanisms. It means you should never rely on them. If using an obscurity feature or design element is free of administrative burden, it is practical to use it. But if benefiting from an obscurity capability means shouldering an administrative burden, often it is not worth the little added benefit.
For example, obfuscating the login banner on devices causes little administrative hardship, so it is generally a good idea. It is also a good idea to keep your system design and device selection confidential. Conversely, deciding that you are going to change all of your internal Simple Mail Transfer Protocol (SMTP) servers to operate on TCP port 2525 instead of 25 is of questionable value. All host applications will need to be modified to use the new port, and this will only add to the complexity of any help desk call from your users to you or from you to your security vendor.
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
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
Appendix A. Glossary of Terms
Appendix B. Answers to Applied Knowledge Questions
Appendix C. Sample Security Policies
INFOSEC Acceptable Use Policy
Guidelines on Antivirus Process