Topic 5 : Security is not fleshed out as far as the other four topics, so I thought I would tackle it first.
- Explain the impact of security availability design in the characteristics of a network.What does this mean? Let’s dig into the subtopics and see if we can find an explanation.
- OOB Access – out-of-band access to devices. If your network goes down or if a device is unreachable, you may need some way of remotely logging into the device. A good example would be a modem connected to the AUX port on a router.
- Decoupling – This probably refers to the separation of control/data planes in routed networks.
- Paul Baran Model – according to Wikipedia, Paul was one of the thought leaders in distributed networking as an answer to reliability. Building networks that could withstand nuclear attack, etc.. This shows some mathematical rigor for communications networks.
- Compartmentalization – this probably relates to Schneier’s book Beyond Fear where he states that:
All systems have a weakest link, and there are several general strategies for securing systems despite their vulnerabilities. Defense in depth ensures that no single vulnerability can compromise security. Compartmentalization ensures that a single vulnerability cannot compromise security entirely. And choke points reduce the number of potential vulnerabilities by allowing the defender to concentrate his defenses. In general, tried and true countermeasures are preferable to innovations, and simpler overlapping countermeasures are preferable to highly complex stand-alone systems. However, because attackers inevitably develop new attacks, reassessment and innovation must be ongoing.
I’m a huge fan of Bruce Schneier. I highly recommend crypto-gram and Beyond Fear.
Another issue Schneier talks about is ‘brittleness’:
Brittleness refers to the way a system fails. Microsoft Windows is a brittle system. A small insecurity breaks the entire system, and often the entire network. The credit-card system is resilient. It can tolerate all sorts of insecurities and still work profitably.
- Use available tools in a network security design to address identity, monitoring and correlation aspects.
- SNMP: This falls under the ‘monitoring’ requirement. Keep in mind that SNMP is by default not very secure, and you should be using SNMPv3 if at all possible.
- NetFlow: You can use records generated by NetFlow to look for all sorts of security events in your network. Normally the data generated is too much and you’ll have to use a third party tool to analyze it. NetFlow uses port 9996/udp by default so designing a system that can accept all of the NetFlow records without dropping is essential if you’re to use it for auditing.
- Syslog: Obviously, syslog is something you should have enabled in your network. It runs on udp as well, so all the usual udp rules apply. It’s also unencrypted by default.
- RMON: I’ve not used much RMON in the past, but this falls under application classification/utilization. Third-party tools are best for RMON probes and analysis.
- DNS: DNS can help to correlate – if for example all of your routers and switches are in DNS and you source records like Syslog and NetFlow, if you have everything defined to do so the IP addresses will resolve in your logs/reports.
- Radius/AAA: Authentication/Authorization/Accounting is a requirement for any large-scale network. You’ll have to audit the logs for events in this as well.
- Full Packet Classifiers: They probably refer to NBAR (network based application recognition). It is a tool built in to the routers and switches that will classify your application based on its behavior. It can, for example, classify P2P applications. It does increase the load on your infrastructure, so be careful when implementing it. NBAR can be used to classify and then police/shape applications like P2P, etc.
- Explain the impact of control plane design decisions on the security of a network; implement security mechanisms to protect the control plane.
- Use and impact of addressing: This may refer to the concept of infrastructure hiding, where you assign addresses to your devices that are unreachable from outside your network. You could assign all RFC1918 addresses to your loopbacks and refuse to NAT/advertise these networks. This does not automatically hide the infrastructure addresses from your internal users and devices, so you would have to apply inbound filters to prevent access. You can use control-plane policing for this (COPP)
- Use and impact of area (flooding domain/summary points) placement.
- Route/Topology/Link Hiding
- Adjacency Protection (MD5, GTSM, etc.): you should be using MD5 to authenticate links between adjacent neighbors. All of the major dynamic routing protocols support MD5. GTSM stands for Generic TTL Security Mechanism. Defined in RFC3682, it outlines the use of the TTL as a way to ensure your updates are coming from directly-attached neighbors. If you receive an update with a TTL
- Route Validation: probably a manual process, anyone have any ideas?
- Route Filtering: filter updates from your neighbors that you don’t want. Or just allow those that you do want.
- Routing Plan: You need to know where your packets will route in steady state.
- Other routing techniques: unsure of what they mean here.
- Explain the impact of data plane design decisions on the security of a network; implement security mechanisms to protect the data plane.
- Infrastructure Protection: Think COPP
- Policy Enforcement (QoS, BCP38): Probably just want to read BCP38
- Prepare and explain security incident preparation and response strategies in a network.
- Reaction Tools (Identification and Classification): IDS/IPS
- Traceback Tools: not Cisco tracebacks, look here.
- Remotely-Triggered Black Holes (RTBH) (destination, source, rate limit, etc.): good whitepaper here.
- Sink Holes: paper here.
- Reactive ACLs: this may refer to installation of ACLs by a third-party IDS/IPS tool.
2 thoughts on “CCDE Written Outline Topic 5 : Security”
Route validation may refer to validating BGP Origin and path discussed in the following paper. But this is just for BGP.http://www.cisco.com/web/about/security/security_services/ciag/research/CRP_route_validation_graphs.htmlSriram
thanks sriram, I’ll check out this paper and update my post.ryan
Comments are closed.