Perimeter
7/17/2009
03:06 PM
John H. Sawyer
John H. Sawyer
Commentary
Connect Directly
RSS
E-Mail
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
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-2595
Published: 2014-08-31
The device-initialization functionality in the MSM camera driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, enables MSM_CAM_IOCTL_SET_MEM_MAP_INFO ioctl calls for an unrestricted mmap interface, which all...

CVE-2013-2597
Published: 2014-08-31
Stack-based buffer overflow in the acdb_ioctl function in audio_acdb.c in the acdb audio driver for the Linux kernel 2.6.x and 3.x, as used in Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to gain privileges via an application that lever...

CVE-2013-2598
Published: 2014-08-31
app/aboot/aboot.c in the Little Kernel (LK) bootloader, as distributed with Qualcomm Innovation Center (QuIC) Android contributions for MSM devices and other products, allows attackers to overwrite signature-verification code via crafted boot-image load-destination header values that specify memory ...

CVE-2013-2599
Published: 2014-08-31
A certain Qualcomm Innovation Center (QuIC) patch to the NativeDaemonConnector class in services/java/com/android/server/NativeDaemonConnector.java in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.3.x enables debug logging, which allows attackers to obtain sensitive disk-encryption pas...

CVE-2013-6124
Published: 2014-08-31
The Qualcomm Innovation Center (QuIC) init scripts in Code Aurora Forum (CAF) releases of Android 4.1.x through 4.4.x allow local users to modify file metadata via a symlink attack on a file accessed by a (1) chown or (2) chmod command, as demonstrated by changing the permissions of an arbitrary fil...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
This episode of Dark Reading Radio looks at infosec security from the big enterprise POV with interviews featuring Ron Plesco, Cyber Investigations, Intelligence & Analytics at KPMG; and Chris Inglis & Chris Bell of Securonix.