The Security Skeptic

The evolution of "dining alone"

Since I've traveled on business for much of my adult life, I have had ample opportunities (heh) to dine alone. On some occasions, I enjoy the solace. On others, I read a book between courses. Certain occasions, intentional or not,  reinforce my belief that social engineering is a rather easy art form to master, largely because most people talk to loudly, too long, too intimately, and too oblivious to the fact that in many dining establishments, you are typically inches from other diners, a.k.a., listeners. At some point I should write an article about the worst offenders in both the "too much information!" and "have you any clue how much damage a miscreant could do with the information you just blurted out?" categories. Alternatively, I could write a series for Fox Reality channel.

Some solo dining occasions, however, are simply lonely. On these occasions, I miss my wife, my kids, and my dog. Enter mobile broadband. I'm not dining alone any more! With iChat, I not only have a text channel, but a video stream of a dining partner. I even have voice. Note that the combination of text and voice allows me to type what I don't want to have overheard. (Yes, I can encrypt the chat... )

So I'm not dining alone but instead with my daughter. Admittedly, my technology footprint is out of place in tonight's venue, a restaurant called Mosto in Marina del Rey (very good gnocchi, by the way). On the other hand, my "presence" is nowhere near as annoying to the other diners as the overly loud blonde sitting inches away, extolling her day's frustrations with her BFFL on her iPhone.

Reasons to Avoid Hiring Hackers

In an earlier post, I mentioned that Mich Kabay had written an article about hiring hackers. Mich, by the way, uses the popular press interpretation of the term hacking. Since I cut my teeth in this industry as a programmer, I remember when the term was reserved to distinguish good programmers from bad.  I prefer to use the terms cracking and cracker. Since computer criminals are convicted for destroying or misusing information, and breaking into systems, they are closer in character to safe crackers than hackers.

Mich provides a list of precautionary measures you should consider if you have a candidate for hire who has a record of cracking. Today, I'll ask some tough questions and reassert reasons why you should avoid hiring crackers. In the process, I'll offer measures to consider beyond Mich's fine list for those who remain more convinced by Mich's arguments than mine:-)

Does good at breaking imply good at building or defending?

A cracker may be good at compromising computers, circumventing network defenses or breaching databases, but he may not be capable of designing complex, multi-tiered, multi-organizational security systems or even writing quality, secure code. As you interview a candidate, bear in mind that a cracker hasn't necessarily demonstrated personal competency by successfully attacking a system. He's demonstrated competencies such as the ability to break into systems, for example, but he may have used exploits commonly available from the underground network for the break-in. These were written by others and come with better instructions than your DVR. So don't presume competency based on a successful attack. Rather, test the candidate. For example, if you are hiring for a position in network security, consider creating a subset of questions from the CISSP study guide and ask all your candidates to take a short test. If you are hiring for a position in system administration, test the candidate's knowledge of your OS and application environment.

Can your candidate play well with others?

Crackers are notorious loners. From the reports Mich cited, we can expect that a candidate with a computer criminal past is likely to have a quick temper or likely to be vindictive. He may lack social and team skills. Consider subjecting the candidate to a professionally conducted personality assessment.

Is the cracker "out of the business"?

What assurances do you have that the cracker you hire or employ isn't still probing systems without authorization, using your systems and networks? Could your company be complicit in a criminal act? Consult with your attorneys and insurance providers to determine whether your hiring practice affects your insurability and liability.

Earning or lending trust

Mich lists character flaws from several reports written by psychologists who have studied computer criminals. I'm not eager to *meet* folks like this at parties, much less hire them to hack code or support systems and networks. But if you insist on taking this path, your biggest oncern should be trust. Trust is better managed as something one earns, not lends (think of reputation based systems). By hiring this hacker, you are preparing to trust that a former gray- or black hat will wear a white hat, only and always. If you make him responsible for vulnerability assessment, you are trusting that he will reveal everything discovered during a penetration test. If you hire him to administer servers, you are trusting that he won't create backdoors or copy sensitive information. I honestly don't have a practical suggestion for how to give a candidate the opportunity to earn trust that can't be circumvented.

Who else is affected by your hiring decision?

Your decision to employ crackers may not be acceptable to business partners, insurers, shareholders, and regulators. If your business partner has a strict policy regarding the employment of convicted computer criminals, how will that company react to your decision? And as I mentioned in yesterday's article, how will your customers and users react? Are you going to withold the fact that you are hiring hackers from these folks? This is probably not the best place to choose to ask forgiveness rather than permission. My recommendation from yesterday's article stands. If you're hiring hackers, disclose your hiring practice to all potentially affected parties and partners.