BSidesCincy Follow up

I had the distinct honor of speaking at @BSidesCincy this past weekend, and I greatly appreciate the opportunity that Justin, Josh, and the entire crew provided for me to speak.

In my time, I've been to a number of conferences.  I started with Usenix back in '99, and that experience was a bit different for me, in that the vast majority of my public speaking to that point had been in the military (during training, and while providing training).  Over the years, I've attended (I prefer to speak at conferences in an attempt to keep costs to my employer down...) several conferences that left me wondering what the point was.  Sometimes, what the speaker actually spoke about had little or nothing to do with the advertised title of their talk, and in a few cases, with the conference theme itself.  With BSidesCincy, it was clear that folks from the same community, with similar experiences and concerns, were coming together to share and discuss those experiences and concerns., and IMHO, that's the real way to make forward progress in this community.

Unfortunately due to flights (or rather, the lack of direct flights), I had to depart the venue after scarfing down lunch.  I did get to see John Davidson's presentation, and I've got to say, it was pretty fascinating.  Even though I'm more of a DFIR guy, my day job does include hunting (albeit largely from a host-based perspective), so a lot of what John talked about made complete sense, as at one point or another, I had some similar thoughts.  John took those thoughts and then took them further.  From a 50,000 ft view, John's presentation was about "here's the issue I ran into and here's how I addressed it...", which resulted in a really good presentation.  Further, it addressed something that I've heard over the years throughout the community...that folks don't want to hear, "...this is what you need to do...", as much as they want to hear, "...this is the issue I faced, and here's what I did to address it...", illustrating their methodology and thought processes throughout.

Thanks to Adrian, here's a link to the video of my presentation.

Again, to Justin, Josh, Adrian, and everyone on the BSidesCincy crew...thanks so much for having me out and for giving me the opportunity to share a bit with everyone.  I had a really great time engaging with everyone I got to speak with and meet.  I hope that for you, it was worth it and that some folks came away with something that they could use.

Addendum, 30 July: I was asked recently via Twitter if I was going to post the slides somewhere, and to be honest, I really don't see the point.  First, I don't read off of my slides...most of what I talk about during a presentation isn't in the slides (on the screen or in the notes).  Second, if you're looking to use the slides as a reference, the information that is posted in the slides is already available in my blog, or someplace else.  Many of the event IDs mentioned in this presentation were taken from eventmap.txt.

Finally, slide 4 of the presentation is to the left.  I used this slide to illustrate a point I was trying to make...that is, the annual reports that we see from some security companies tell us that when these consultants respond to a breach, they're able to see something (some indicators, artifacts, etc.) that allow them to populate the "dwell time" statistics.  The thought that I shared was that if the consultants can find this, what's stopping the local IT security staff from finding these things earlier in the game?

I didn't get many comments on this thought at the time...am I on target, or am I way off and clearly making things up?  Does it make sense?  Does it generate any additional or follow-on thoughts?

So, what would be the point of releasing the slides?  I talk to this slide in the video, and so far, haven't heard any comments or feedback on the point, so why release the slides, just to get...well...still NOT get comments or thoughts?  So far, there have been a good number of RTs and "Favorites" for the original version of this post, but as of yet, no comments regarding the content of the video.

Ghost Busting

First, read Jack's post, Don't wait for an intrusion to find you.

Next, read this post (The Blue Team Myth).

Notice any similarities...not in content, but in the basic thought behind them?

Yeah, me, too.  Great minds, eh?  Okay, maybe not...but

So, you're probably wondering what this has to do with Ghostbusters...well, to many, an intruder within the infrastructure may seem like a ghost, moving between systems and through firewalls, apparently like an apparition.  One thing I've seen time and again during incident response is that an intruder is not encumbered by the artificialities of an infrastructure, where someone shouldn't be able to access systems, due either to policies and roles, or to local laws (European privacy laws, etc.). Yeah, that doesn't stop an adversary.

Jack's right about a number of things.  First, the old adage about an intruder needing to be right once, and a network defender needing to be right all the time is...well...wrong.  Consider this...prevention, by itself, is ineffective.  In defending a network, you need to include prevention, detection, and response in your security plan.  Given that, what is the adversary's definition of success?  What is their goal?  Once you arrive at what you believe to be the adversary's goal, you'll realize that there are plenty of opportunities for defenders and responders to "win", to get inside the adversary's OODA loop and disrupt/hamper/impede their activities.


Jack is exactly right...an intruder needs to accomplish five stages in order to succeed, and all five of those stages require one thing in common...execution of commands.  Something has to run on the systems.  Doesn't it then make sense to have some sort of process creation monitoring in place, such as Bit9's Carbon Black, or MS's Sysmon?

Here's another way to look at it...in the beginning of my blog post, I mention two annual security/threat reports, and describe what some of the statistics mean.  In short, one metric that the investigators report on is dwell time...how long (as far as they can tell based on the artifacts) a targeted actor was embedded within the infrastructure before being detected.  What this means is that when investigators look at the available data, they're able to determine (at least up to a point) the earliest indicators of the adversary's activities, be it early indicators (use of web shells), or the actual initial infection vector (IIV), such as a strategic web compromise, or an email with a link to a malicious site, or with a weaponized document attached.  The point is that the investigators are able to find indicators...Registry keys/values, Windows Event Log records, etc...of the adversaries activities.  And all of these are indicators that could have been used to detect the adversaries activities much sooner.

Finally, one other thought...Jack's steps 4 and 5 are cyclic.  Wait...what?  What I mean by that is that following credential theft and establishing persistence, the adversary needs to orient to where they are and begin taking steps to locate data.  What are they looking for, what are they interested in, and where is located?  Is the data that the adversary is interested in on a server someplace (file server, database server), or are there bits of the data that they're interested in located on workstations, in emails, reports, spreadsheets, etc.?  So, what you may see (assuming you have the instrumentation to observe it) is the adversary collecting data for analysis in order to assist them in targeting the specific information they're interested in; this might be directory listings, emails, etc.  You may see this data exfiltrated so that the adversary can determine what it is they want.