Perimeter
7/17/2009
03:06 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Defensible Network Architecture Ideal For Incident Response

In my last blog, I talked about how incident response is more than just preparing your first responders by training them and providing them with the tools. Your network and systems need to set up in preparation, too, so that you have the information you need when handling an incident. It wasn't until yesterday that I remembered what I think is one of the best models of network design that fits the mold of what I mean by having your environment ready for an incident.

In my last blog, I talked about how incident response is more than just preparing your first responders by training them and providing them with the tools. Your network and systems need to set up in preparation, too, so that you have the information you need when handling an incident. It wasn't until yesterday that I remembered what I think is one of the best models of network design that fits the mold of what I mean by having your environment ready for an incident.Richard Bejtlich's Defensible Network Architecture 2.0, an updated model of the defensible network architecture (DNA) he defined in his books, describes an environment that is monitored, inventoried, controlled, claimed, minimized, assessed, and current. If only we could all be so lucky to achieve that type of environment one day -- then we'd be in great shape to handle nearly any incident that comes at us.

I'll leave you to go and read Richard's blog entry, but to hit some highlights: Monitoring is an absolute must if you want to know what's going on in your network. The more content you can capture for looking back on when an incident occurs, the better. Just keep in mind that some of the content you capture could be sensitive, so take the necessary precautions to protect your monitoring systems. I know that sounds like a no-brainer, but I saw a group have nearly every one of the IDS hosts owned by a worm because they weren't fully patched and were accessible from the workstation network.

Inventorying and claiming systems go hand in hand. If you can inventory all of your systems and find out their purpose and what they store, you can respond more effectively to incidents. Likewise, knowing who they belong to is huge, yet not always an easy task in a large, diverse enterprise.

I could go on and on about Richard's DNA model and how important trying to achieve it is when preparing to handle incidents, but I think as you read through the different sections, you'll realize it yourself. When you're done, ask yourself how your current environment stacks up and what would it take to get you there.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2015-4231
Published: 2015-07-03
The Python interpreter in Cisco NX-OS 6.2(8a) on Nexus 7000 devices allows local users to bypass intended access restrictions and delete an arbitrary VDC's files by leveraging administrative privileges in one VDC, aka Bug ID CSCur08416.

CVE-2015-4232
Published: 2015-07-03
Cisco NX-OS 6.2(10) on Nexus and MDS 9000 devices allows local users to execute arbitrary OS commands by entering crafted tar parameters in the CLI, aka Bug ID CSCus44856.

CVE-2015-4234
Published: 2015-07-03
Cisco NX-OS 6.0(2) and 6.2(2) on Nexus devices has an improper OS configuration, which allows local users to obtain root access via unspecified input to the Python interpreter, aka Bug IDs CSCun02887, CSCur00115, and CSCur00127.

CVE-2015-4237
Published: 2015-07-03
The CLI parser in Cisco NX-OS 4.1(2)E1(1), 6.2(11b), 6.2(12), 7.2(0)ZZ(99.1), 7.2(0)ZZ(99.3), and 9.1(1)SV1(3.1.8) on Nexus devices allows local users to execute arbitrary OS commands via crafted characters in a filename, aka Bug IDs CSCuv08491, CSCuv08443, CSCuv08480, CSCuv08448, CSCuu99291, CSCuv0...

CVE-2015-4239
Published: 2015-07-03
Cisco Adaptive Security Appliance (ASA) Software 9.3(2.243) and 100.13(0.21) allows remote attackers to cause a denial of service (device reload) by sending crafted OSPFv2 packets on the local network, aka Bug ID CSCus84220.

Dark Reading Radio
Archived Dark Reading Radio
Marc Spitler, co-author of the Verizon DBIR will share some of the lesser-known but most intriguing tidbits from the massive report