RealSecurity

First of all... HEY! I’m back! Well, at least the one or two of you out there may have noticed I wasn’t writing for the last week or so. My previous web host was r-e-a-l-l-y slow so I decided to switch… and it was actually more economical anyway. This one is a bit better. I think some of my performance issues are actually due to the code I use to generate this site. Anywho… nothing ventured, nothing gained. Through the transition the site was always up, but very complicated to keep content flowing, so I just took a break. Nevertheless, what’s up with all those CDs getting shipped out from whitehat MicroSolved out of Ohio?

Back on Aug 25, the National Credit Union Administration (NCUA) issued a fraud alert to all federally insured credit unions of a letter and two CDs that were being circulated claiming to contain anti-fraud training materials and stated that running the CDs "could result in a possible security breach to your computer system, or have other adverse consequences."

While technically true, it was the result of a sanctioned social engineering test by MicroSolved against a bank. Now, everything I’ve read about this contain quotes from everyone from NCUA to SANS that are not much more than an “awe shucks” and “gee wiz the system works” type of attitude and nothing on the complete disregard for professionalism. Of course, Johannes Ullrich from SANS capped it off by saying he is not aware of any cases where bogus CDs were actually used to compromise a computer network. Well, that is comforting, thanks for the fuzzy feeling.

Ok, I’ll dispense with the sarcasm for the moment… it’s late and I’m feeling prickly. I ran a global Ethical Hacking business for years. On many occasions customers asked for this type of test. Yet upon further investigation – and I’ve written extensively about social engineering my Ethical Hacking book – what was truly being tested was a human’s reaction to a particular presentation of information. How that information is presented has a great deal to do with the results. In their zeal to do a “kewl test” MicroSolved ignored professional curtsey in working very closely with the customer to truly understand the intent of the test and simply focused on the testing strategy. This is far too common in penetration testing services. It’s always about the “how” as opposed to the “what”, or especially the “why”.

This is easy in technical terms. There is a system, the system may have a vulnerability, so we interrogate it, simple. It’s simple because computers don’t think, they respond and respond consistently over and over. Therefore the “why” is well defined and so is the process. But people are not computers and will do things differently even when presented with the same problem. Mood, time of day, environment, medical state that day, stress, blood pressure, and even temperature of the room will add nuance to a decision for the same problem. Spread this across a test targeted at 5000 employees and there are virtually an endless number of possible outcomes. So in social engineering, the formation of test has to be highly targeted at “what” particular human error you are wishing to expose.

Human interaction is complicated and this is especially true in determining risk. If you want to read about the meta-meta risk thinking process, check out Bruce’s stuff, which is quite interesting. But, when you come down from that level and get to the reality of testing human interepretation of risk you have to consider the form of information. For example, physical security of an office will be different from an airport. Forget about threat for a moment and just thing about the process. To break into an office that supports simple badges, it would be trivial to present yourself as a policeman and get in easily. This is not the case in the airport because there are more controls that add layers to verification. With more controls means greater complexity in forging credentials. I know I’m taking the long road to explain what I’m trying to say, but if you present something that is complete and accurate for the condition you have completely failed to test the target and only tested your ability to copy the control.

For example, when I personally setup and/or performed social engineering tests I purposefully used bogus looking credentials, such as using my driver’s license as a name badge or some variation on this theme, to access a building. Or I may have dressed like the janitor with no name badge at all. The point is I was testing the person’s reaction to interrogating the control, not my ability to copy it. If the security of an office is based on having a badge then it is assumed that the badge will be interrogated. Once interrogated the authenticity of the badge is then verified – visually or by a computer. Now, if you are testing people in this environment – specifically the people who exist to interrogate badges and you are specifically testing that they are performing this function (the “what”) - then a perfect forgery is simply not testing them. They may stop you, see the badge looks perfect and you’re through. In this case the guard performed exactly the prescribed process that you were testing. However, if you got past him with a perfect badge you weren’t actually testing the guard or the process; you were testing how well you mimicked the badge.

Testers today completely miss this point and go for the “kill”. It’s all about finding new and interesting ways a hacker may use. But that’s not really the point in a testing scenario. There is simply no way to perfectly mimic a hacker/attacker and even if you could what science did you use to determine the exact threat type to mimic? The point is to test the security controls as defined and in a manner that tests them specifically. Now, of course there have been many scenarios where the client says, “Just come at me with all you have.” I say, “Them why bother, we’ll get what we want and probably will with massive limitations anyway. What are you really testing with an open test with no holds barred?” They eventually “get it” and realize that the threat that would do anything to get in is not only a rare one, but not one they could afford to stop anyway.

Security is full of neatly package conundrums. In one way we say you can be perfectly secure, and then in testing we display no control by testing the craziest scenario and come back with “See, we got in.” Well no kidding, because creating enough security to stop that type of attack would cost millions. And that is what happened here. Sending out a letter with CDs wasn’t a good test and it went well beyond what I suspect was the intended scope. Look, you don’t have to be in security or the ethical hacking business long to come across some very, very dangerous individuals. I know several and can tell you with great confidence that they could easily crush anything you have to put in front of them. So, you might as well target that energy in a direction that tests the controls you can afford and have in place. Otherwise, it’s a waste of money.

I can write about this all night, but I already have, it’s called The Ethical Hack: A Framework for Business Value Penetration Testing, my book. Get the book and read it. Or drop me a note and I’ll send you the chapter on social engineering. When it comes to testing computers, the same logic of what and why applies, but is typically embedded in our common thinking and strategy. However, all that changes in social engineering and for some reason people lose sight of the what and why and zone completely in on the how. And the how is always something extreme that doesn’t really prove anything because it’s not representative of a threat that the target organization has identified as something they weren’t ready to accept the risk of. It’s just that simple.

This over simplified, geek approach to testing is ineffective within th context of providing meaningful value to the business for their investment. It’s a collection of recently trained whitehats fresh from Blackhat that want to show how cool they are and how imaginative they can be. I get it, I’ve been there. But, when a company hires you to test their security you have to take the time and help them understand what it is they want to accomplish and tune the test to that need. Otherwise, you’re no better than the real hackers and the company didn’t get any meaningful value from the test.