Offensive Coutermeasures

Just finished taking SANS SEC504 (instructor: John Strand).  Good class but more on that later.  During class John brought up the concept of Offensive Countermeasures.  He has created a site dedicated to the topic http://www.offensivecoutermeasures.com/ . He related to the class a frightening case he was involved in that had a positive outcome through the use of these measures.  I will leave it to him to make the details public if he so chooses.

Avoiding the topic of "hacking back", I thought I would touch on another aspect of countermeasures.  The idea of honey tokens is nothing new but here is one with a twist.  Why not include several fake user accounts.  Using statistical analysis or simply cracking, create a few accounts with passwords of varying degrees of difficulty.  Include several that are slightly easier to crack than the real users.  The theory being, the attacker will jump on the low hanging fruit.  Any activity on the fake accounts should sound the warning alarm.

Another even more intriguing way to handle this is to create a large user base of fake accounts.  Perhaps a 90% fake to 10% real ratio.  In this case, we are creating white noise and increasing the chance the attacker grabs a land mine rather than a pot of gold. The second case will almost certainly require a method of tracking the real users to ensure inactive accounts are being deleted in a timely fashion.  You don't want to be that guy who left an account active for a former bitter employee.

First Post - Thoughts on BSidesLV 2010.

 I helped for a few hours each day with security and it was a great experience.  I was working the door and I got to meet everyone who attended the event without having to tap them on the shoulder and introduce myself.  For you introverts out there, give volunteering a thought, it can lead to anxiety free networking!

One of my primary motivations for attending the conference  event was to participate in the infosecmentors project.  It did not disappoint.  I cannot say enough about what Marissa and company are doing with this. 

On day one I attended David Rook aka securityninja  's talk titled "Injecting Simplicity not SQL".  He compared educating drivers to teaching developers to code securely.  His premise was, teaching developers to securely code by teaching them about hacking is like teaching safe driving by teaching how to crash.  The analogy met with crowd approval but it is not one I would have made.  We as a society haven't figured out how to teach people to drive safely, just check the number of fatalities each year  We license drivers and we show them examples of the devastating results of unsafe driving.  We limit the speed they can drive and enforce traffic rules.  We hold drivers accountable when they act irresponsibly (civil, criminal or both).  Doesn't matter, many people die.

Do we have any of the above controls placed on developers?  License required?  Held liable for poor code if it results in loss?  Rules that must be followed which are enforced?  I'm not advocating tossing coders in jail or implementing any of the other controls,  particularly as it appears they do not work.  What I am saying is we need to be careful about oversimplifying the problem and dismissing the concept of teaching developers where common weaknesses lay.  Teach developers how to use a hacker tool? No.  Teach them how an exploit works or how to write one? Maybe.

 Perhaps a better analogy would have been to compare developers to the engineers who design the cars.  What controls are in place when an engineer submits plans for development? 

Overall, I thought the talk was good and despite my misgivings he had some statistical evidence that the methods he was employing to educate developers was working.