One size doesn't fit all

I was talking with a student recently who was has a management directive to implement DLP in his network.  We talked about some quick wins that can move you towards DLP success.  One such idea is using group policy to restrict CD/DVD burning.  Another is preventing the use of removable media (USB).  The student pointed out tons of reasons that this wouldn't work for his entire organization.  I proceeded to explain that's what a well engineered group policy hierarchy is for.  However, I'm not naive.  I understand that a hierarchy engineered before DLP might not meet all of the granular DLP requirements.  For instance, one person in an OU may need to perform data transfers but the OU implements a no override policy (for some other setting).  The student then proceeded to explain how these GPO settings could be circumvented anyway if an attacker (or insider) elevated privileges on the endpoint (arguing that they were therefore ineffective).  Of course he's right - they can be implemented.  But is he missing the point?

In DLP, as in security, one size doesn't fit all.  Just because you can't implement a control everywhere in your network doesn't mean it can't add protection in those areas where it makes sense.  Maybe restricting USB use globally can't work, but restricting it in the HR department can.  For these solutions, I say don't let perfect stand in the way of good enough (or even better).  Evaluate whether a quick win can provide added security today and implement it where it will work.  This can provide some stopgap protection even as you search for a better solution that can:

1. Cover all (or a larger percentage) of the network
2. Cover the nodes not protected by some other control

I like to analogize this to the use of a bulletproof vest.  Police wear bulletproof vests when on patrol.  In fact, policy makers (supervisors, chiefs, etc.) usually force them to be worn.  They force their use even though it is well known that they don't cover the entire body.  Not only that, but the don't even cover all of the critical areas (groin, head, etc.).  To make matters worse, for the areas they do cover, some large caliber and specialty bullets cut right through them!  And yet, we would question the judgement of a police chief who said "because this solution isn't perfect and doesn't protect our officers from all potential bullet hits, we refuse to invest the time and money to implement it."  Why do we treat our network security controls any differently?

Straight out the "you can't make this stuff up" file

I saw a lot of people tweeting about  this article yesterday.  It's about a forensics examiner who lied about her credentials.  Shame on her.... for more reasons than one.

The article mentions that when interviewed, she thought that only two of twelve jurors were required to find her guilty.  She claimed that's why she plead guilty to the charges.  Now listen, you could be the best forensic examiner in the world, but I quite frankly don't want you on the stand if you don't know how our legal system works.  I mean seriously, just how good of an expert witness can you be?

Another thing that disturbed me about the article was the fact that she had worked on 10 cases for the indigent defense fund since 2006.  These 10 cases resulted in payment of $23,000.  But in 2000 she claimed to be billing $254/hr.  Assuming that bill rate, she worked each case for 9 hours.  I'll assume that a few of those cases plead out.  But come on now, nine hours per case?  To investigate and write the report?  Seriously?  What about trial prep for those cases that didn't plead out?  If I am ever accused of a computer crime, I sincerely hope that my forensic examiner spends more than nine hours on my case.

This class act also said that in three years she can have her misdemeanor record expunged.  That's a horrible thing to say on the record.  The idea that she would ever work again in this field if laughable.  Anyone who hires her after she lied about her credentials deserves a conviction.  It's one thing to not know she's a fraud.  It's another thing entirely to hire someone after you know they are willing to lie on the stand.  Of course, if you are caught red handed and clearly guilty, maybe that's what you need...

How to fail at Incident Response

I'm a firm believer in having a sound incident response plan (and policies to go with it).  One big piece of this is having a plan with regards to how the IR team should communicate.  How should you communicate?  Well, that's going to depend on your situation.  But let me first answer the easier question: how you should not communicate.

Whatever you do, don't count on your main method of corporate communication during an incident response
There are many reasons for this, but a big one is that the main method of communication may have been compromised by the very attackers you are trying to repel.  If you continue to communicate over compromised channels, you're violating some pretty fundamental tenets of OPSEC and giving your playbook to your attackers.  Where I come from, that's a huge fail.

Why do I bring this up now?
Well, I bring this up consistently when I teach SEC504 (Incident Handling and Hacker Techniques), because I've seen organizations fail at it repeatedly.  I've also been on some "red team" exercises and benefited from these failures. One high profile failure happened over the weekend though and that's what inspired me to write this blog post.  The Syrian Electronic Army (SEA) compromised the UK sites of PayPal and Ebay.  Obviously these organizations were quick to respond.  Unfortunately, they coordinated communication (presumably a conference call) over their standard email system.  But the SEA had access to the email of one of the incident responders.  How do we know?  Well, they were daring enough to tweet about it after one of the employees commented what a bad idea it was to use their standard email to coordinate the response.

Most attackers are not this brazen and many IR teams give their playbook to the intruders every step of the way.  Unfortunately, coordinating out of band comms during an incident is not easy.  This is something that you plan before the incident occurs. 

Most corporate phone systems are VoIP now, so even trusting these phones is sketchy at best.  I recommend some out of band email through a provider like outlook.com and some burner phones to be safe.  Obviously common sense applies here.  If you deal with regulated data, understand the implications of communicating that data through a third party provider (i.e. not your internal email system).

Out of band comms - good for more than just security
Did I hear someone say DRP?  Yeah, out of band comms are good for that too.  I'm a firm believer in having a good disaster recovery plan.  How will you communicate if the email system is down because a fire took out the power panel that feeds that server rack?  Not everyone needs a secondary mailbox, but at a minimum every key member of the IR team should have one.  It sure would be good if the people coordinating the response had access to communications that were per-configured.  

And what about the VoIP system?  When that goes down, communicating to fix it can be hard.  Sure everyone has cell phones, but having a few dedicated cell numbers ready to go that are tied to a position (rather than a person) is a real win.  I've used this very successfully during large responses.  We have a few cheap burner phones with prepaid plans.  Then we distribute the numbers and say "if you have something to report about X, call this number... Y, call this number... etc."  Then you can staff a 24x7 response simply by handing off the phone.  You can set up call forwarding to private lines too, if appropriate, but there's no guessing who to call.  The key points are:

1. You aren't dependent on your internal phone system for IR.  This may not be present in a disaster or may not be trusted in a compromise.
2. Staff knows what number to call.  No more disturbing off duty personnel to see who's responsible for an item right now.  This is a real problem during active IR and I can say that adding these burner phones has increased morale every place I've worked.
3. The price is so reasonable it's within the reach of any IR team.  Worst case cost: burner phone $50, monthly prepaid service, $600/yr.  If that's not in the budget to at least get one phone for the IR lead, you need to seriously consider IR priorities (i.e. find a new job).