The Security Kitchen

Yesterday, the cute toddlers over at ‘Zero For Owned’ collectively shoved their diapers onto their ankles and shat all over the ‘white hat’ community in the form of a ‘zine’ (which allegedly is 1337-speak for magazine) in which they published information about recent ownage they performed on sites of renowned (and respected) security peeps.  Among the victims were Dan Kaminsky, Kevin Mitnick, the guys and gals of Hak5.

Looking through the contents of the file, it’s very easy to get distracted by the (to say the least) entertaining writing.  I must admit that some of it had me laughing out loud, but I disgress. Much to my disappointment, the sons-of-heffas do not reveal anything about 0day pwnage, there is actually 0 I can learn from them and yet, it reminds me of my early days in security.

Some years back, I was doing a presentation for a customer about how they should implement least-privilege for their administrators, how to approach it, etc … etc … I was on a friggin role right there when one of the managers asked me : “What privileges does YOUR account have on YOUR computer” … I must admit that the silence was deafening.

Lucky for me, this personal pwnage came very early and it taught me to try and practice what I preach as much as I could.

If you read through the zf05.txt file you will see that almost all of the meat comes from basic security mistakes : simple passwords, password schemes and reuse, unencrypted storage of passwords, lack of segmentation, … , …

I personally enjoy reading about the possibility to forge a certificate with 200 playstations, the intricaties of listening in on babyphone communications (heck I might hear some zfO members chat up !) or how I should place my feet and shake my hips to break encryption algorithms.  I do not deny those are problems, but if we keep on making the basic mistakes, we are going nowhere. Moreover, there will be no rock to go hide under.

The basic lessons I take from this are clear :

a) practice what you preach and do it religiously.
b) rockstar status is nice but you might end up like Bitbit (pwned) a bit quicker than you expected.
c) you will be pwned eventually, make it as difficult as possible though.

The least we should expect from the expert victims is to share with the community HOW it went down.  We’re in this game together and as we’ve learned from eachother in the past year, we should continue to share knowledge, even if it proves that the smart people can be outsmarted too.

And for whatever it’s worth, to the Zero For Owned crew : pull up them diapers, ditch the pacifiers and come out to prove you can do it better than those people that put loads of energy in trying to keep the mantrain rolling. Maybe it’s time to put your money where your mouth is, and make a change.

You can find more insights on zf05 over at :

http://countermeasures.trendmicro.eu/zf05-kaminsky-0wned-mitnick-0wned/
http://www.liquidmatrix.org/blog/2009/07/28/doxpara/
http://preachsecurity.blogspot.com/2009/07/learning-lesson-hard-way.html
http://www.wired.com/threatlevel/2009/07/kaminsky-hacked/

I’ve been digging into the FAIR (Factor Analysis of Information Risk) methodology for risk assessment recently and I was captivated immediately.

Factor Analysis of Information Risk (FAIR) provides a framework for understanding, analyzing, and measuring information risk. The outcomes are more cost-effective information risk management, greater credibility for the information security profession, and a foundation from which to develop a scientific approach to information risk management.

With the information available on the FAIR wiki and the walkthrough created by Kevin Riggins available on infosecramblings.com I compiled this quick and dirty BRAG (Basic Risk Assessment Guide) spreadsheet that you can use to try some FAIR scenarios for yourself.  You can reuse the file, if so desired.

Thanks to Kevin for the quick review, Mr Jack Jones for all the work on FAIR and Mr. Alex Hutton “The voice of FAIR”.

FAIR <<– THE FILE

I’ll throw out newer versions as I build upon the foundation.

(For those of you using excel, I guess it should work … There is no macro’s yet, only messy formulas. I’ve completely migrated to oOo for over a year now …there is no way back.)

Maybe it’s just me … but some people really tell me just too much about their infrastructure.  Today I received a mail of a friend of mine, who works at a very well known company and I decided to look at the mail header. I don’t do that all the time, just sometimes, mostly when I’m bored … Lo and behold, I learned a lot from that simple mailheader.

a) they name their mailservers by location and by type. If I take the time to learn about their other global offices, I can probably guess the names of all of their servers … NICE !

b) Internally, they use an ip range assigned to the headquarters … for their outgoing traffic however, they use a range assigned to their European branch.  This allows me to draw up their network architecture quite effectively. All up to their DMZ … WIN!

c) The internal mailserver shows the domain name !! Yeah, they really accomodate my laziness …

d) The mailserver shows that it is Lotus Notes … and which version … it doesn’t get any better, right ?

e) and then … I notice the name of their mail security server/appliance/whatever … I vaguely remember a press release from a certain vendor in that space from a few years ago.  A quick google on $certainvendor and $certaincompany confirms my line of thought.  Bingo !!

That’s all the information I need to craft an effective spear-phising attack  Shikata ga nai !!

I’m a father of 3 cute boys. Twins age 5 and a younger boy age 3. Yes, I’m totally overprotective and if my wife would let me, I’d probably pack them in bubblewrap every time we go out.  I hate it when they fall, probably hurting more than they are at that moment.  I would wish I was there every time they come within a 20 mile distance of harm’s way.  That’s how dads are … I guess.

Unfortunately, in (information) security we tend to go down that same path.  We want to make our controls transparant to the end-users, we want our development framework to provide security services so our developers don’t have to worry about it.

I’m afraid that, by packing every single subject that (chooses to) interact with our security system in virtual bubble wrap, we risk to actually lower the security posture of our infrastructure/information. Why ? In my (extremely) humble opinion, first and foremost, by taking away the visibility of security measures, users will take them for granted.  It is no longer their responsibility but that of “the security guys”.  By relying on a development framework to *provide* security, it is no longer the developers responsibility to take care of security: “The framework will handle it”.  You’re seeing where I’m getting at ?

When building a security strategy, user education and awareness is one of the most important parts of your project.  At certain points, you just need to have users, administrators, developers, contractors, etc … run face-first into a concrete wall.  Not because you’re a sadistic pig, but because in a secure environment, there are limits, everybody has responsibilities and they better be aware of them.

It certainly isn’t because I rejoice in preventing people from doing what they are hired to do.  Au contraire, I believe security should enable people to do their job better. In the end, the responsibility of protecting the information they work with is part of their job.

I guess that what I’m trying to tell is simply that, after all, I’m not your daddy.