20 Critical Security Controls: Control 19 – Secure Network Engineering
Senior Manager, Corporate Communications
Today’s post is all about Control 19 of the CSIS 20 Critical Security Controls – Secure Network Engineering (the last post pertained to Control 18). Here I’ll explore the (9) requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found [*].
Key Take Aways
- If you’re just starting out: DO THIS NOW. If you can get the design secure from the outset, your life will be easier down the road. If you doubt me, ask some veteran IT folk about this. Just strike up a conversation about broad, flat networks and security and see where it takes you.
- If you’re just realizing this is good: Take it slow. You’ve been operating without a secure design for a while. Start it slow, but within reason. Look for the most critical business processes you support and secure those. Have a roadmap. Execute. Plan to change.
- Get Configuration and Asset Management Under Control. If you want to react quickly and smoothly, then you’re going to want to ensure that you’ve got a well-oiled machine in place to handle your assets and their configurations.
Potential Areas Of Improvement
- Add Metrics And Tests. There are no metrics presented for Control 19. Again, dumbfounded here, but perhaps this isn’t a mortal sin like the lack of metrics for Control 18. There must be something of use that can be measured here. How about the percentage of network expansion/updates that undergo a security design review?
- Include Small-Fry Guidance. From what I hear and read, most of the struggling organizations are small or at least smallish. They may not run a lot of services in-house, and therefore may not have a real need for three tiers. Are there other architectures equally effective for this different case?
Requesting Feedback On
- See Areas of Improvement. If you have comments, by all means fire away!
- Description: The network should be designed using a minimum of a three-tier architecture (DMZ, middleware, and private network).
- Notes: I wonder how many small shops leveraging outsourced Web, storage, and e-mail providers would like to use a three-tiered architecture? I think I would have this anyway (I even have this at home). But, I can’t justify the additional layering with any real-world data. For example, the Internet connects to the router, the router connects to the firewall, the firewall connects to everything internal. The DMZ would be the router-to-firewall portion of the topology, and may contain no hosts at all, and that’s OK.
- Description: Any system accessible from the Internet should be on the DMZ, but DMZ systems never contain sensitive data.
- Notes: Of course, they do contain sensitive data if you’re offering services to customers over the Web. This sensitive data may not be permanently stored in the DMZ, but it certainly transits the DMZ, resides in memory, and may be paged out to disk. Use of the word ‘contain’ is ambiguous.
- Description: Any system with sensitive data should reside on the private network and never be directly accessible from the Internet.
- Notes: See the comment above. Sensitive data should be ‘permanently stored’ behind the DMZ and served through the DMZ to properly authenticated entities over properly secured communication channels. Long-term (might be better than ‘permanent’) storage and/or processing of information should be behind the DMZ.
- Description: DMZ systems should communicate with private network systems through an application proxy residing on the middleware tier.
- Notes: For those who are more advanced. Here the three tier system is in full effect. I imagine that small-office/home-office users won’t do this and will instead have the ‘sensitive’ network behind the DMZ. Larger users can accommodate this heavier architecture.
- Description: To support rapid response and shunning of detected attacks, the network architecture and the systems that make it up should be engineered for rapid deployment of new access control lists, rules, signatures, blocks, blackholes, and other defensive measures.
- Notes: I’m really not sure what to say about this other than that you must have excellent configuration management (and therefore asset management) practices in place. When you make a change and need it to take effect, you’ll have an easier time if you’ve paid close attention to Controls 1, 2, 3, and 10.
- Description: DNS should be deployed in a hierarchical, structured fashion, with all internal network client machines configured to send requests to intranet DNS servers, not to DNS servers located on the Internet.
- Notes: Again, this is pretty good advice. Even for home users. The routers they use should act, at least in some small way, as a DNS server.
- Description: These internal DNS servers should be configured to forward requests they cannot resolve to DNS servers located on a protected DMZ.
- Notes: Forward requests up the appropriate chain – you don’t want unresolved DNS queries going directly from the sensitive tier to the Internet.
- Description: These DMZ servers, in turn, should be the only DNS servers allowed to send requests to the Internet.
- Notes: I think this means that DNS servers in the DMZ are the only allowed to query service provider DNS servers. I would additionally state that such communications be performed over a secure channel.
- Description: Segment the enterprise network into multiple, separate trust zones to provide more granular control of system access and additional intranet boundary defenses.
- Notes: This has become an effective practice, but it does require that you really understand your business and its operational needs and habits. It doesn’t make any sense to segment your networks if the organizational processes will just end up transiting those different ‘trust zones’ to get things done. That said, proper segmentation can work wonders for your compliance regime.
Esta noticia ha sido vista por