This is an incomplete thought experiment.
First, some premise stuff:
John Boyd posited the concept that one's orientation is the significant factor when making decisions. Orientation combined with observation creates a feedback decision loop (the OODA Loop). If you can either act unexpectedly, faster, or more correctly than an adversary you can 'operate inside an adversary's OODA loop'. Once you can begin down that path it will disorient the adversary which will make the adversary slower or incorrectly respond as the conflict changes. Continue on and it'll get to a point where the adversary simply can't make decisions based on accurate observations. End game.
This is all neat stuff but that's beyond what I want to talk about. I want to talk about orientation. Orientation (per Boyd) includes an individuals experiences, cultural heritage and traditions, synthesis of information and new information. This set of attributes has a large bearing on which decisions are made. I want to talk about the defender's orientation. Incident handlers are trained to understand and use the response lifecycle:
prepare, detect, contain, eradicate, recover, lessons learned.
There's a few minor variations of this, however it's in all coursework. My experience suggests that this lifecycle is the framework that nearly all security industry products, incident response plans, incident handlers, and organizations use. In short, it's part of our training and traditional thought process and has an influence on our orientation.
Every phase of the traditional response life cycle imples an inward focus. If one is so internally focused then one is not observing new information and unfolding circumstances. This seemed reasonable in 1998 when defensive tactics were against self propagating malware DoSing servers left and right. This is no longer the world we live in; now it's theft, extortion and espionage. We must additionally be outward facing and better engage the adversary. Note the lack of questions surrounding who initiated a compromise or why. These are not philosophical (or law enforcement) questions, but focus on the very real concern of uncovering "who was the operator behind this? what was she seeking? did she achieve her goals? is this part of a larger sequence of events? what can I do to break her OODA Loop?".
Let's tinker with a different incident response approach.
Trigger -> Operational Response -> Tactical Response -> Prepare
Trigger. Observe, Detect, etc.
Consider the trigger as all observations. It begins at the traditional 'detect' phase of the doctrinal lifecycle. This is stuff like IDS events, AV alarms, SIEM alerts, and end user or third party notifications. It's also searching for unknown unknowns through both automated and manual system or network profiling. This includes another set of data including network traffic, filenames, hashes, domains, or IP addresses.
Operational Response. Contain -> Eradictate -> Recover -> Lessons Learned
After the trigger is initiated we move into operational response. This is the traditional response mechanisms on removing the active threat and recovering to full business measures. See NIST SP 800-61. Or the CISSP coursework, or any security 101 book. Clean up your systems, get them back to operational status, figure out if there's a way to prevent it from occurring again.
Tactical Response. Gather and Characterize Indicators -> Integrate and Analyze -> Confuse & Disorient
Next we move to tactical response. This is using threat intelligence by identifying new indicators of the compromise and rating, classifying, and assessing those indicators. Integrate and Analyze. We begin to integrate that dataset into our standard detection and protection controls. At the same time an analysis is performed against other compromise datasets to determine any similarities, odd dissimilarities, and draw conclusions and future use. For example, recon activity X is linked to Exploit Y which was also seen in Incident case numbers 43, 71, and 72. A more aggressive example: monitor adversary's suspected infrastructure for changes. A new or expired IP address or domain can be interesting and suggest upcoming changes. And finally, Confuse & Disorient. Feint weaknessness, show unexpected activity, make the adversary know that you know she knows you know what is going on, use misinformation. Maybe you should click any malicious link, lots of times from lots of locations. Do several layers of active DNS lookups, possibly query the webserver as to it's version. Turn the target into a honeypot. Contact owners of external systems affected. Plant passwords, files, fake contacts, pgp keys.
This is what's been rattling around in my head for the last week. Ultimately, we need to analyze not just our weaknesses, but our adversaries weaknesses. We need to fix our orientation to allow better decisions. We need to stop crippling our capabilities.
Friday, June 25, 2010
Thursday, June 24, 2010
Charmsec
I skipped up an opportunity to do a "lightning talk" while at FIRST 2010 this year. I came up with the idea of talking about citysec, charmsec and how things have progressed. I backed out since I didn't have time to put my thoughts together in any sort of coherent talk. This post is instead a preemptive attack if I do have another opportunity and prevent me from backing out.
CitySec meetups. A simple concept of regular meetups at a bar by security geeks to talk about whatever they'd like. I'm not sure who came up with the idea or where they started. I know that Boston, Chicago, San Fransisco, and NYC all have been doing citysec meetups for several years now. There was a website and forum setup several years ago that appears to be completely stagnant.
In 2005ish @reyjar started Charmsec. After two or three months it faltered. I never attended. In 2008 a friend and I agreed we should revive the Baltimore meetup. We announced our first meetup on the DC security geeks mailing list. Charmsec 4 had three attendees, including my friend and me. Charmsec 5 had three attendees. This continued for some time. We changed bars, we had maybe 6-8 attendees. We changed bars again, time passed. We're now up to averaging two dozen folks attending each month.
If you live near a city look for a citysec. If none exists, think about setting one up. Here's some lessons we've learned:
CitySec meetups. A simple concept of regular meetups at a bar by security geeks to talk about whatever they'd like. I'm not sure who came up with the idea or where they started. I know that Boston, Chicago, San Fransisco, and NYC all have been doing citysec meetups for several years now. There was a website and forum setup several years ago that appears to be completely stagnant.
In 2005ish @reyjar started Charmsec. After two or three months it faltered. I never attended. In 2008 a friend and I agreed we should revive the Baltimore meetup. We announced our first meetup on the DC security geeks mailing list. Charmsec 4 had three attendees, including my friend and me. Charmsec 5 had three attendees. This continued for some time. We changed bars, we had maybe 6-8 attendees. We changed bars again, time passed. We're now up to averaging two dozen folks attending each month.
If you live near a city look for a citysec. If none exists, think about setting one up. Here's some lessons we've learned:
- Think of citysec as using the Open Source model. That means a few things:
- Low level of entry. It should be easy. Don't have RSVPs, don't have membership, don't have a steering commitee. Be informal and ask people to show up.
It should be evident what citysec means to you. Charmsec is just charmsec and modeled on what we thought it should accomplish and look like. In another words: this is Baltimore's citysec. There may be many like it, but this one is ours.
- Provide and recognize the value. charmsec provides value by offering a chance to get out of the house/office and drink beer and network with fellow like minded individuals. It's not on vendor presentations, job hunting, or gaining CPE points.
- Low level of entry. It should be easy. Don't have RSVPs, don't have membership, don't have a steering commitee. Be informal and ask people to show up.
- Twitter is a multiplier. The level of participation you can gain by announcing and leveraging twitter royally trounces any mailing lists, forums, websites, and generates more word of mouth.
- Location, Location, Location. Be central and fairly easy to get to. The bar should not be loud. It should have a decent beer and food menu. It should have table service. It should take reservations. Bonus points if it takes reservations via tweet like @slaintepub.
- Consistency. Use the same location, and pick a day of the month and stick to it. Don't be afraid to experiment to find a better venue or time but it should be irregular and include lots of reminders of such a change.
- Expect low turnout for the first several. Charmsec didn't get any consistent level of participation past 5 attendees until at least charmsec 10.
- Expect to lead and direct the conversation until the meetup finds it's legs. Ask questions, introduce folks, and play host until you're not needed to. Then stop.
- Don't be harsh to vendors, hackers, govies, risk managers, auditors, college kids etc. Avoid geek wars.
Subscribe to:
Posts (Atom)