Content Development

I often speak about how streamlining the CIRC/SOC workflow and producing high reliability, high fidelity, low noise alerts is a key element to an organization's success in this arena.  The question I often get asked after this is "Where do the alerts come from?".

Well, that is a very good question.  The answer is that it can vary.  One thing that's for sure though is that the process that leads to the alerts -- content development -- is extremely important.  It's important to assess your organization's risk and exposure, and then determine what you would like to look for (conceptually) to monitor/address that risk.  Once you define what you want to look for, then a careful study of the data needs to be performed in order to guide the organization to alerting that will identify activity of concern with low noise.

It's an art, rather than a science, but allowing the data, risk/exposure, and operational requirements to guide the content development process will produce better results than any other approach I've seen.

Collecting, Vetting, Retaining, and Leveraging Intelligence

If you've done a good job building bridges and relationships for your incident response center or SOC, you will receive intelligence/indicators of compromise from time to time.  Once you receive them, what do you do with them?  If you search back in your logs a few weeks or months to see if you've got any hits, that's a good start.  But what if an attack hits tomorrow, after you've already run your search and (likely) "discarded" that intelligence?

That's where a robust intelligence analysis function and process can help.  Joining information sharing groups, purchasing intelligence from vendors, working collaboratively with peer organizations, and building bridges and trusted relationships can all net you decent intelligence.  Once you collect it, it should be vetted.  In other words, given the context (which is extremely important) of a particular piece of intelligence (e.g., is it a payload delivery site, C2 site, malicious email sender, etc.), is it reliable as an indicator of compromise?  Does it produce a large number of false positives, or is the noise relatively tame (making it more useful/reliable as an indicator of compromise)?

Once an indicator has been vetted and deemed reliable, it should be retained.  I've seen a number of organizations use some sort of an intelligence repository to retain the vetted, reliable, high fidelity, actionable intelligence they have.  Once it's retained, of course, it should be fully leveraged.  This includes writing alerts to check the intelligence repository regularly and run the data against recent logging.

I'm sure that this sounds conceptually simple, but it's amazing how many organizations don't properly retain and leverage the intelligence they receive.  Take a look within your own organization -- if you can better retain and leverage intelligence, it will serve you well in the long run!

Xenophobia

Over the years, I've worked with, developed trusted relationships with, and shared information with people holding a wide variety of passports.  A person's professional work, professional reputation, and trusted relationships generally speak to a person much better than the color of their passport.  Unfortunately, there are some people and organizations who think along the very analog lines of countries of origin/passport in hand.  This is foolish in my opinion -- judge the person not by the color of their passport, but by the content of their work.  To not do so could be to needlessly exclude fresh information/a different perspective so often missing in very insular places.

What's the concern?

I find it interesting that some people have a knee jerk reaction/aversion to information sharing, or proceed to turn any mention of it into an over-complicated mess of a conversation.  I always seem to hear the same types of statements:

"We have privacy concerns"
"There is a lot of regulation that prohibits/impedes information sharing"
"That information is classified/sensitive/protected"
"We are not permitted to share information"

In my experience, when there is doubt or fear of the unknown, it's always easier for people to say no and then provide reasons that appear quite official and legitimate to support that position.  After all, no one ever got fired for not sharing information, right?  These individuals that choose this path, however, put their organizations at serious risk by needlessly limiting the organization's access to timely, valuable, high fidelity information necessary for incident response/security operations.

What's interesting to me is where this doubt/fear comes from.  As far as I can tell, it comes from a profound lack of knowledge regarding what is valuable from an information sharing perspective.  If long lists of sensitive internal assets were valuable from an information sharing perspective, I could totally understand the hestitation.  But, as it turns out, to our fortune, the most valuable information for incident response/security operations is publicly available Indicators of Compromise (IOCs), such as malicious domain names, malicious callback URL patterns, malicious email attachment names/MD5s, etc.!  It takes a skilled analyst and trusted circles of peer review to vet/filter the vast maze of information until it is boiled down to its most valuable essence.  But what is eventually shared is entirely focused on "footprints" that attackers leave in the sand after an intrusion, and contains no sensitive, private, or personal information about an organization.

So, I'm left asking, what exactly is the concern with sharing valuable, actionable, high fidelity IOCs within trusted peer information sharing groups?  Seems to me the concern is a fear of the unknown/lack of understanding what is valuable from an information sharing perspective.  I think it's about time that changed.

IDS

I find it fascinating that although IDS has the potential to be used as a sharpened scalpel to pick out abnormal network activity from various places within the packet, it is mostly used as a packet by packet log collector.  What do I mean by this?  IDS is a technology that can be equipped with a relatively small number of highly potent and actionable signatures designed to look for activity that organizations need to take notice of.  Unfortunately though, most organizations go the complete opposite direction, deploying IDS with thousands of weak/mediocre signatures, perhaps out of fear of "missing something".  The result?  Anything that might have been worth looking at gets buried in 10,000 false positives per day (or more!).  Worse yet, sometimes IDS becomes every analyst's favorite data source to ignore.  It's a shame really -- so much potential in modern IDS devices, yet so underutilized.

BS Filter

It sounds a bit crude, but a good BS filter can be an analyst's best friend.  Analysts are confronted by an overwhelming amount of information on a daily basis.  Whether it be from blogs, mailing lists, management, a vendor, an intelligence feed, a tool, or one or more log sources, it can be overwhelming.  Diving into the wrong lead can tie up precious analyst resources for hours or even days, often taking away from other events or leads that need to be investigated.  So what is an analyst to do?  Follow only the leads most likely to yield fruit!  Easier said than done, of course.  Knowing how to separate out the good leads from those that are a fool's errand is an acquired skill that takes years of false starts to develop.  It can be a skill that is extremely valuable to an organization though and should be respected.

Big Data

There is a lot of buzz lately about big data.  Almost every vendor and most pundits seem to be talking about big data -- and telling us we need it.  While I am seeing a lot of hype and build-up, I'm not seeing a whole lot of useful advice or helpful tips about *how* to actually leverage big data.  Where I work, we've been leveraging big data for over a year now (we just never called it that).  I see this as an opportunity.  We've developed some effective techniques for slicing through big data and producing a reasonable volume of highly actionable alerting from over 4 billion network events a day.  It's time to take this show on the road and share the information.  I've put in some papers for some upcoming conferences -- wish me luck!