Filtering by Tag: security

Is Big Data Analytics for Security really just SIEM 2.0?

A lot of companies are now touting big data analytics that will find badness that your other security tools do not find.   Almost every pitch I see has something very much like the SIEM Funnel from 2005.  The assertion tends to say these solutions would have bubbled those two or three compromised Target servers up to the top.  It will be interesting to see what this segment of the security market looks like in two years. For those of us that bought into the SIEM market, we found out that a SIEM is very needy in terms of man-hours.  There are several reasons for this:

  • Getting all the data feeds going (no small feat in most companies)
  • Building network and asset models
  • Creating rules, dashboards, reports, etc
  • Tuning out false positives
  • Troubleshooting the inherent performance problems of processing hundreds of millions of events per day

In short, you spend a lot of time up front getting the system going and on-going effort to keep it running.

These new products want all your SIEM data plus many other sources like DNS queries, and netflow.  Think about that volume of data for a second.

Here are the typical promises for today's big data security platforms:

  • No rules to create
  • Zero (or very few) false positives
  • Scalability - these systems will not be over-run with data
  • Little to no analyst time required to find badness
  • Full kill chain visibility for compromises

I suspect the majority of these systems will fall short of the promises laid out above.  However, I do believe we will have some great tools a couple of years from now that will make us wonder if we really do need that SIEM.  Oh, and by the way, this is not a "SIEM is dead" post by any means.  There will almost always be a place for SIEM in the SOC environments.

How did Target get hacked?

Protection of windows means different things in different environments! If you follow the news, you know that Target got hacked to the tune of at least 110 million credit card numbers (and some PINs) lost.  But, how did it happen?  Hardly anyone is asking or answering that question.  You can find plenty of articles that tell you what happened once the attackers go in:  Memory scraping on the POS devices and servers, a Russian teenager, famous coders, etc.

My question is different.  How did they get in initially?  I think as an industry we focus too much effort on what happened after the attackers get it.  Do not misunderstand me.  We absolutely need to scope the breach, determine what happened, what was stolen, changed,  and such.

We need to spend more time, money, and technology on understanding exactly how the compromises are being made.  I was just talking with another security professional recently who was telling me what versions of Java that current variants of Zeus was exploiting.  Guess what?  Zeus doesn't exploit anything.  It does not take computers over.  Zeus is just a piece of software that can get installed by anyone with administrative access to the computer.  It is what some people call "Stage 2" malware.  In the Cyber Kill Chain, this would be the Install phase.

There is a whole world of what we call "Stage 1" malware.  Some of these software packages are also called "Exploit kits" as it has gotten pretty commercial.  Ones that come to mind are Blackhole, Cool, Phoenix, and others.  There are custom exploit tools as well.    In the Cyber Kill Chain, I'm talking about the Exploit phase.

The problem with what I'm asking is that it is not easy to find out how computers got exploited.  There are very few tools on the market that help give you visibility into Stage 1 malware.  FireEye and Mandiant (now one company) create tools to help.  Most of your anti-virus vendors really focus on Stage 2 malware.  In other words, they are looking for the malware that makes the news like Zeus and others.

Typically, Stage 1 malware (the real exploit) is deleted from the box after it's job is done and the Stage 2 (Zeus, BlackPOS, etc) malware is installed.  That's why it is hard to determine how the computer got "infected".

If we take the money we would spend on that latest silver bullet security product and double down on visibility and process, we can really cut down on large intrusions like the one at Target and now Neiman Marcus.

Here is a list of action items off the top of my head.  I'd like to drill into these in later posts.

  • Build visibility into networks and computers
  • Design an ecosystem to capture that visibility
  • Make it easy to search and narrow down events by time
  • Have your users send you anything they feel is suspicious
  • Determine what exactly got exploited each both by analyzing the events and user input
    • You need people to do this:  Analysts
    • This is where you get some of your best threat intelligence, by the way
  • Measure and track the exploits seen on your network
  • Research what vulnerable pieces of software are hit most often on your network
  • Uninstall that vulnerable software OR put a lot of rigor around patching those vulnerable applications
  • Feed current threat intelligence (not lists of 90000 bad IP addresses) into your detection platform
  • Measure time to detect and remediate exploits and work hard to lower that time.
  • Look for data leaving your company.   Show that to management.  Often.
  • Demonstrate the tie between the trend of exploits and data leaving the building.

There are companies and vendors that get this and are working hard to solve the problem as stated above.  Other companies just want to sell you "signature update" subscriptions on an annual basis and are not really interested in solving the problem wholesale.  The companies most interested in selling subscriptions are short sighted because there will always be a better mouse no matter how good we build the mouse traps!

Just remember:  Stage 1 malware (aka - The exploit) and kick-butt Incident Response is where the money is.  If you cannot get access to the computer, you cannot install your cool botnet or memory scraping software.  When the bad guys are successful, they will have time to stage these large hacks (ala Target, TJX, Sony, etc)  if the Incident Response team kicks them out quickly.

Until next time...

Wyman

MIRcon 2013 Day One overview

logo_mircon2013Richard Bejtlich (CSO) kicked off the Mandiant's MIRcon 2013.  He talked briefly about the past year including overviews of two public incidents and introduced Kevin Mandia (CEO). The two incidents Bejtlich described are:

Kevin Mandia talked about the evolution of computer incidents from both the attacker and defender perspectives from when he started in security (1993) until today.  Good stuff.  He even talked a little about the old Air Force system that we used to use back in the 1990s, ASIM (Automated Security Incident Manager).  I remember when they started rolling those out.  If memory serves, it was around 1996 or so.

Two points that Kevin made stood out in my mind:

  • Defenders should align vertically the way attackers tend to do.  Bottom line:  Share with like-minded folks in your industry or sector.  He noted that attackers tend to align on sectors and build expertise on like companies.
  • We need to reduce containment times down to ten minutes.  Yes, that is aggressive.  Is it fast enough?  Kevin's simple answer:  Yes.  :-)

Grady Summers hosted a panel of folks that do real-world response for Mandiant.  Keeping with my theme of two's.  There were a couple of things I took away from this panel.

  • Trends show a decrease in the use of malware for maintaining persistence in organizations.   What this really means is that attackers are obtaining and using legitimate user credentials much more often.  This really raises the complexity for incident responders.
  • Attackers are using legitimate sites to get around domain blocking or blacklisting.   Sure, this one is in the weeds, but it just struck a chord with me.  The primary example they mentioned was using Google Translate or Babelfish to get C2 from online discussion forums.  That is beautiful in it's simplicity and effectiveness.  Our global economy requires language translation from time to time.    Another reason it struck me, after the fact, is that Mike Siko blogged about this almost two years ago and I missed it!  Bottom line:  Make sure your web proxy is configured to look for URLs in GET requests.

There are two main tracks for the conferece:  Management and Technical.  I attended sessions from both tracks and will put out some thoughts from those sessions if anyone is interested.

Former FBI director, Robert Mueller gave a late afternoon keynote.  His talk warrants a dedicated blog post.  Lots of wisdom from him.  It was a great way to close the day.

My Security Mantra - "Nothing sells tires like nails."

If you've talked with me much about security, then you've heard the phrase, "Nothing sells tires like nails."   I use it all the time.  It's been written on my white board in the office for a long time.  But, why? I grew up near an old country store.  The guy running the store made his money selling tires.  He attracted customers, mostly farmers, by having a good supply of snacks along with a few seats around a heater in the back of the store.  Everyone knew everyone.  Small town.  The farmers would sometimes give the store keeper a hard time.  They would playfully accuse him of throwing debris on the road out in front of the store when business was slow.  He would jokingly respond by saying, "Nothing sells tires like nails."

I heard this phrase many times in my youth.  As I got older I found this principle applies to many things and especially to security.

How many times have you bought tires because they were cool or sexy?  Probably not many unless you are really into cars in some way.  Most people buy tires for one of two reasons:

  • A blowout  - Think security Breach
  • Failed inspection - Think Compliance

Security is pretty much the same way.  Companies tend to spend more on security when they get hacked or they fail an audit.  This may sound sad, but it is true.  Companies manage risk and spending in many areas.  Security is just one of them.

Security folks would do well to keep this in mind when both running and justifying a security program.   No manager wants a big fail on their resume.  Be truthful, realistic, and keep in mind why companies typically decide to spend money on security (or anything really).  This will help you scope the type of information you report up the management chain.

Custom Email Notifications with ArcSight ESM

Email notifications from your SIEM can be very useful especially if you have a small team.  The default in ArcSight ESM is to dump every event field into an email.   While better than nothing, the format is hard to read and forces you to search for the information you need to work the event.  Enter custom notification templates. Disclaimer:  This works as of ESM 4.5.  I have not tested it on ESM 5.0.  Would love to hear your experiences!

There are a few of moving parts and I'll go through each below.

  • Rule Actions- You need at least two rule actions.  See screen shot below for an example.
    • Send Notification - Set AckRequired as you wish.   The NotificationMessage is what will ultimately be the subject line of the email.  Resource is where you pick what group of users the email will go to.  This will have to be a group.
    • Set Event Field Actions - This is the secret sauce.  You can technically pick any field name.  I typically use one of the flexString fields to avoid a conflict of that field being used in some other way.  For agentSeverity, it really is up to you and does not affect the email.

  • Notification conf file - This file is in $ARCSIGHT_HOME/config/notification/ and named Email.vm and has logic to help it decide which template to use when sending the notification.  In a clean install of ESM, it only has one option, the default template I mentioned at the top of the post.  It makes decisions based on a particular field.  In this example, it is the flexString1 field shown in the screen shot above and code snippet below.  The decision works from top to bottom using Velocity, so make sure any custom entries are above the default entry.  Add an entry like the one below to the file for each custom template you have.  The #parse field will be the name of the Notification Template File described in the next section.
#if($introspector.getDisplayValue($event, "flexString1") == "malware")
#parse ("Custom-Email-Malware.vm")
#end
  • Notification Template File - This is the file that will literally be a template for the body of the email.  Remember the subject line of the email is set in the Rule Action.    For this example, the template file name is "Custom-Email-Malware.vm".  The file format again uses Velocity and is pretty straight-forward once you have seen one.  See example below.
Description: $introspector.getDisplayValue($event, "name")
Event Time:  $introspector.getDisplayValue($event,"endTime")
--------------------------------------------------------------

User Name:  $introspector.getDisplayValue($event,"sourceUserName") 
IP Address: $introspector.getDisplayValue($event,"sourceAddress") 
Host Name:  $introspector.getDisplayValue($event,"sourceHostName")
Location:   $introspector.getDisplayValue($event,"sourceZoneName")

Target Port: $introspector.getDisplayValue($event,"targetPort")
Event Count: $introspector.getDisplayValue($event,"baseEventCount")

Extra Information (where applicable)
---------------------------------------------------------------
$introspector.getDisplayValue($event,"message")

Description of Event
---------------------------------------------------------------
This computer appears to be infected with malware 

Why this is Important
---------------------------------------------------------------
Malware can take complete control of a computer remotely.

Next Steps
--------------------------------------------------------------
Start the malware infected procedure on this computer.

Note all the field names in both the config file and template file start with a lowercase letter, have no spaces, and each word is capitalized except the first one.  This can bite you if you are not careful.

Good luck!  If you have questions, comments, or suggestions, please leave comments below and I'd be glad to help.

What should I learn to get into IT security?

Several people have asked me over the years some variation of "What should I learn if I want to do IT security work?" This is a hard question to answer without knowing your goals and interests.   However, most people I talk to only have one very high-level goal:  Get into security.

Here's what has been most beneficial for me on the technical side in no particular order.

Operating systems:  Not just windows versus UNIX.  But, how they work.  Learn about IPC, pipes, what really happens at boot times, how things get started at boot, etc.   You can bet that attacks know how systems boot inside and out.  It's called maintaining persistence.  Also, Linux != unix.  Yes, it is a unix variant.  But, I have seen "Linux gurus" get totally lost when trying to show someone something on Solaris.  Don't be that person.  Learn at least on distro/flavor of Linux, BSD, and take a look at Solaris.  They are different yet the same.  Do not try to figure out the difference during an incident.

- Learn how to interpret logs:  Seriously.  Make for darn sure, you know where the logs are on every OS and application you touch.  Look at the logs every day and after making any OS or application changes.  How did that affect the logs.  This may be the difference between an making a timely intrusion detection and an attacker having free reign on your network for months.  I am amazed when something serious has gone wrong how many people reply, "I have not looked yet."  when I asked them what's in the logs.

Networking fundamentals:  Beyond three-way handshake and default gateway.  How do network connections make their way up each layer of the network stack on an OS, how does a given program bind a network port in order to accept connections, know subnet masking inside and out.  Make for darn sure you can make sense of tcpdump output.  Learn the structure of basic protocols:  HTTP, DNS, SMTP, FTP, IRC, etc.

- At least two scripting languages:  One portable like Perl or Python and know some unix shell type stuff (bash, csh, etc).  Get cygwin and play with it if you have not already.  Think tool building and quick and dirty text parsing.

- At least one compiled language:  C is a good choice.  C++ or C# would be a good second for any GUI stuff, but C will suffice.  Visual Basic or similar if you must.  Again, think tool building.

- Learn basic unix (and cygwin) utils like the back of your hand: sed, awk, grep, sort, uniq.  These will save you one day while one of your coworkers is working on some fancy formula in Excel.

- Databases and Web Development:  SQL.  You'll need it for tool building if nothing else.  Learn PHP while your on SQL.  They go together like peas and carrots.  PHP could easily be swapped out for AJAX, Ruby on Rails, etc.  The point is learn what it takes to get that data out of the database and on the screen of someone across the network.  This is literally where the money is.  Think e-commerce, online banking, etc.

But, wait, Wyman.  What about Firewalls, Intrusion Detection, Virtual Private Networks, Identity Management, Data Loss Prevention, Security Information and Event Managers, etc?  I want to do security!  They will come.  Wax on, wax off.   Trust me.

Build a foundation on what makes your computer and the Internet work.  Only then are you adequately prepared to start defending it.  Otherwise, you'll see something in your IDS and have no clue if that is normal or malicious.   You do not have to be a guru at any of the items above, but be average in all of them and you're way, way ahead of the game.

I'd love to hear other thoughts and suggestions.