Confusing Strategy with Tactics

This seems to happen all the time. I, personally, encounter it with disturbing frequency. One of the most common mistakes I see made is the mixing of strategy and tactics by managers. I can feel some of you pulling away from me. Before you do that, though, let me explain. It is the job of management to enterprise strategy or "corporate vision," if you prefer cheezy management buzz phrases. With that, I couldn't agree more. Management has the encompassing goals and they are the ones who must solidify these goals and transmit them to the rest of the enterprise. In short, they define the "what" portion of the overall equation, in the sense of "Here is what we are going to do." Where I often see things go awry, though, is when management then goes into micromanagement mode and proceeds to tell the engineers how to meet these goals.

It is important to understand that I'm not saying that management should be completely hands off. It is their job to provide guidance and to set the rules of engagement, so to speak. Once those rules are set, though, they should step back and let the engineers work their mojo. Having been given the strategy ("what"), which includes the rules of engagement, it is the job engineers to determine the tactics ("how") appropriate for accomplishing that strategy. Let me provide an example to illustrate my point.

I once worked for Company X in the capacity of information security analyst. Though the company was fairly large, there were only two of us who were security analysts, so we were stretched pretty thin. We had a monthly enterprise vulnerability assessment that required sifting through a mountain of data. We were using a commercial vulnerability scanner that could only export the data as PDF files or as HTML files, so to do any real work with the data, PDF was out of the question, so we had to dump the data as HTML files. Fine. An inelegant solution, but still workable. Once exported to HTMl files, though, each file had to be opened individually and certain rows of data had to be exported to Excel. From there, we performed some calculations and data normalization (much of which had to be done by hand), and they that data was copied into a Word document, which was, in turn, converted into a PDF file for the final report. When I first encountered this absurd series of events, my first thought was "wow...too much effort. I'll put together a Linux box with Nessus and then I'll write some Perl scripts to parse the Nessus data and create the reports." So with the approval of my manager, I did this and I successfully reduced the amount of time required to collected the data and generate the final report from several weeks to a little more than a day. I showed the end result to my manager and he was pleased, so we were poised to roll out the new solution. As luck would have it, just prior to the roll out, the CIO decided to put forth a new corporate vision: we were to be a 100% Microsoft shop. I assumed that he meant that we were to use Microsoft products except for those cases where there was no Microsoft product, as in the case of the vulnerability scan and the subsequent report. As it turned out, I was wrong. So we had to scrap the whole project just before it was ready to go into production. The situation was explained to the CIO by my manager, at which time the CIO actually became somewhat combative and slammed his fist on his desk saying "I said that we are going to be Microsoft only, and I meant it!"

So there I was, back to having to jump through a comical number of hoops to generate what ended up being a report of less than 10 pages. "Well," I thought, "instead of having to extract this data by hand from these HTML files, I'll put together a perl script to do it for me. That'll speed things up a little bit." It was at this time that I got a call from another of the managers.

"Uh, yeah, you can't do that."

I blinked, stunned. "Can't do what, exactly?"

"Those scripts. Yeah, you can't write those in perl."

"Why not?"

"Perl isn't an approved language here at Company X."

"But they're just for my own use on my own machine. I'm just going to use them to parse some data that I'd otherwise have to parse by hand."

"Yeah, I know, but you still can't write them in perl. If you want to write them in Javascript, which is approved, that'd be ok. But you just can't write them in perl."

So there you have it. What I desperately wanted to say (and rightly did not) was "I have a job to do. If you want me to do it, then get out of my way and let me do it." This is what happens when management confuses strategy with tactics.

Managers: set the strategy, define the goals, set the rules of engagement, and convey that information to the masses. Then kindly step back a little bit and let the engineers do their jobs. Don't micromanage. It is irritating and insulting to the engineers and doesn't speak too well of your management skill.

Engineers: listen carefully and respectfully when you are given strategy, goals, and rules of engagement. Then do everything within your power to achieve those goals as quickly, efficiently, and effectively as possible. Play by the rules and give regular progress reports. And don't be patronizing. It gives us all a bad name. Besides, it never pays to antagonize management.

Integrity and the lack thereof

Recently, I ran into a situation that highlights the absolute necessity for integrity among information security professionals. Unfortunately, in this case, I got to see what could happen when someone else demonstrates a significant lack of integrity.

In many regards, security professionals are not unlike attorneys or psychiatrists in the sense that during the course of your duties, you may become privy to certain information that, under no circumstances, can be shared. Obviously there are certain ethical obligations that come into play here. If you become aware of illegal activity or something along those lines, you are duty-bound to report it. However, when the information is clearly sensitive and there is no reason to divulge such information (other than to attempt to display to others how much you are "in the know"), to reveal such information is egregiously unethical. Here's the story that brought this to light. I'll try to keep it brief. All names have been removed from the information below.

I currently work for Company A. Several months ago, Company B, a consulting firm, approached me and asked if I would be interested in looking at a few positions they had open. Let me emphasize that they came to me. I was content with my work at Company A, but in my experience, it always pays to keep your options open. So I agreed to hear about these positions. Here's where an unfortunate series of coincidences comes into play. A person currently working for Company B (whom I have never met, by the way) used to hold my position at Company A. Let's call him Bob. Further, when Bob held my position at Company A, he worked for the same manager that I currently work for. Let's call the manager Tom. So Bob is a security person. His focus in the security field is substantially different from mine, but a security person nonetheless. For reasons I don't entirely understand, Company B asks Bob to take a look at my resume. At this point, Bob, who is ethically obligated to keep company-sensitive information private, promptly gets in touch with my manager (and his former manager, Tom) and says "Hey, Kurt is looking for a new job." So a couple weeks later, Company B makes me an offer that I'd have been a fool to decline, so I took it. I then go to my manager, Tom, and put in my two week notice. Imagine my surprise when it became clear that he already knew about this position. I did a little investigation and quickly discovered the chain of events outlined above. By blind luck, there don't appear to have been any negative ramifications of this. (Or, at least none that I'm aware of at the moment.) But that doesn't excuse the fact that it happened in the first place. If I'd had a different manager (I have a pretty good professional relationship with Tom), this could have gone very bad, very quickly. I could have been fired, it could have besmirched my professional reputation, etc., etc. In this particular case, I appear to have dodged a bullet, but I'm still pretty ticked that I got shot at in the first place. I'm reminded of the line from Shakespeare's Othello: "...he who filches from me my good name, robs me of that which enriches him not and make me poor indeed."

Here's the deal. Those of us who are security people need to hold ourselves to a very high ethical standard. Let's be honest...at some point in the past, we've all probably done things (hopefully very minor things) we shouldn't have or possibly used our position to our advantage. To some degree, that's human nature. (Think of a police officer pulling strings to get out of a speeding ticket, for example.) The key words there, though, are "in the past" and "used our position to our advantage." In this case, Bob had absolutely nothing to gain by releasing this information, other than to attempt to impress his former manager, Tom, with how "wired-in" he is. Were there some sort of governing body for security professionals, I would have reported Bob in a heartbeat. There isn't, though, so Bob gets to go on his merry way, coming into contact with sensitive information and potentially divulging it to others as he sees fit. In short, Bob should be ashamed of himself. It is incumbent upon us as professionals to give careful thought to the potential ramifications of leaking information to which we become privy. The actions of Bob were disgraceful and we, as professionals, must do our best to to stamp out such behavior whenever and wherever we find it.

An Open Letter to the Open Source Community

Sorry for the delay between posts. Between the whole holiday season thing, having a cold, having a 1st birthday for my younger daughter, etc., time sorta got away from me. So I figure I'll get things restarted with something that has irked me for quite some time, and it came to the surface again this morning.

This morning, I got an IM from a friend of mine. Here it is: "...but I'm NOT using ANYTHING called Ubuntu: Feisty Fawn. What kind of idiot slapped that on?" My friend touched upon something that is, I think, indicative of a significant hurdle that Open Source projects will need to overcome if they ever expect to be taken seriously and to ever have even the tiniest chance of being able to step out of the shadows. Before I dive in, let me state for the record that I am a die-hard member of the Open Source community. I am an ardent supporter of Open Source; if there is an Open Source equivalent for something, I'm using it. That being the case, while the following may come of as a bit vitriolic here and there, it is not to be taken as a slap at the Open Source community in general. It is merely an attempt at a wake-up call to the community members, and, hopefully, a call to action.

In short, I humbly ask the Open Source Community to please, please, please stop giving software (and branches, tags, and sub-versions thereof) stupid names. Seriously. I know that you may think it is funny, but it really isn't. The aforementioned "Feisty Fawn" thing just illustrates the point. There are tons of such names out there, ranging from absurd to, quite frankly, offensive. Every place I've worked, I have been a major advocate for Open Source software. It is very difficult to be taken seriously in meetings with management when you say "I have a potential solution," and then explain that your solution involves the use of Feisty Fawn, Tiny Sofa, Oinkmaster, BitchX, SheepShaver, awffull, lame, moomps, seahorse, smeg, gimp, spit, yoltia, suck, torsmo, valknut, vomit, and/or zile. Naming things, whether we're talking about naming software, children, or pets, can be a difficult process. When giving something a name, though, you have to ask yourself a few simple questions.

1. Am I using this name because I think it is clever or cute? If the answer is "yes," then keep looking. You might think it is cute or particularly clever today, but odds are that you won't always find it so amusing. (Here I cite a person my sister-in-law knows whose first name is Frodo. Yeah, as in Baggins. I'm sure Frodo's parents thought the name was funny and probably even a little cute. I've got a dollar, though, that says if we asked our friend Frodo what he thought of his name, he'd have a somewhat different opinion.)
2. Am I using this name because it is an inside joke? This is really just a slight variation on the previous question. Again, if you answer "yes," do yourself and everyone else a favor and keep looking.
3. Is this a name that I'll be happy with 10 years from now? This one seems pretty obvious, but I'm always shocked at the number of people who don't really think this one all the way through.
4. Is this name something I would be embarrassed to say in front of my grandmother? I like to call this one "the grandma rule." Here I cite such names as "suck" and "vomit." Inherently offensive? Not necessarily. Good names for software? Not even close.
5. And finally, is this a name that I'll get tired of hearing?

While we're still on the subject of what is and isn't good naming style for an Open Source project, let me touch briefly on the subject of acronyms or initials. In general, try to avoid it. Sometimes it works, take PERL and even NATO for example. Most of the time, though, it doesn't. It usually ends up producing some sort of gibberish that is difficult to spell, impossible to pronounce, and equally impossible to remember. Even in cases where you can pronounce and remember the acronym, it still may be a bad idea. The definitive example of this is GIMP (GNU Image Manipulation Program). This acronym is derogatory and offensive. I can hear people already "but it was a joke," (see question #2, above) or "it isn't intended to be insulting." To this I reply that, in general, things operate not on reality but on the perception of reality. It may not have originally been intended to be insulting, but it is. So change it, simple as that. Ethereal successfully changed its name to Wireshark, so if they can do it, so can GIMP. (The Wireshark name change came about for legal reasons so they had no choice but to change, but the name change concept applies equally well to GIMP.) And then, of course, we have the matter of recursive acronyms. Once upon a time, this was a strange tradition and apparently seemed like a good idea at the time. Here are a few examples of recursive acronyms: GNU stands for "GNU's Not Unix." Clever, huh? And PHP stands for "PHP Hypertext Preprocessor." And LAME stands for "LAME Ain't an MP3 Encoder." Please oh please oh please put an end to this. It never was funny or clever and over time, it has only become more and more annoying.

So what conclusions can we draw from all of this? Basically, take care when naming Open Source projects. If Open Source is ever to come into its own, it must be taken seriously by those who develop it. While GIMP and PHP and Oinkmaster may have become serious, production-quality software, their names suggest that at the early stage, they were each named because someone thought it was funny. If we, as members of the Open Source community, want our efforts, our software, and our plight to be taken seriously by the industry at large, we must first take ourselves seriously. This is the root of much of the resistance to Open Source software. Even Microsoft's previous attempts at disinformation about Open Source software hinge upon this. How could we expect others to take us seriously when we (apparently) don't even take ourselves seriously? Am I saying that Open Source software needs to become stuffy and boring? Of course not. But the Weltanschauung of the industry at large stems predominantly from how we perceive ourselves. Times have changed and as Darwin suggests, we must either adapt or die. As such, we must treat our work within the Open Source community with care and humility, and perhaps even a touch of reverence. To do otherwise is a disservice to our work, to ourselves, and to our community.

---

References
Don't Kill the Penguin!
Recursive Acronym
Ubuntu Development Code Names

About @#$%ing time...

Microsoft has finally released a Hotfix for the Windows XP Wireless Client, and all I can say is that it is about friggin' time. Internet Storm Center has a description of the Hotfix HERE. Among other things, this fix addresses one of the most annoying things (from a Windows XP wireless perspective) I've encountered in a long time: the random Windows XP wireless network. If you've ever used Kismet in the vicinity of Windows XP machines, you know what I'm talking about. Not only does XP continue to cycle through its list of preferred wireless networks (leaks far too much information and makes it waaaaaaay too easy to determine whose laptop you're looking at), but you also get the weird random SSID strings. If you just let Kismet run for days or weeks at a time, it isn't at all uncommon to have a list of several hundred or even several thousand probe requests just because of this odd XP behavior. Here's a little piece from the Hotfix page:

In Windows XP with Service Pack 2, Wireless Auto Configuration tries to match preferred wireless networks to wireless networks that broadcast their network name. If no network matches a preferred wireless network, Wireless Auto Configuration sends probe requests to determine whether the preferred networks are nonbroadcast networks. In this manner, a Windows XP wireless client advertises its list of preferred wireless networks. An observer may monitor these probe requests and configure a wireless network by using a name that matches a preferred wireless network. If the wireless network is not secured, this network could enable unauthorized connections to the computer.

I understand Microsoft's intent in designing their wireless client to work this way. Obviously, they are trying to make the connection to wireless networks easy. They've made it easy at the expense of security. And on an OS that is notoriously difficult to protect without extensive 3rd party software.

By strange coincidence, this Hotfix was released almost to the day of the 5th anniversary of the release of Windows XP. This unusual wireless behavior has been a known issue since that time. Why in the world did it take 5 years to release a fix for this? Ok, I grant you that some of the other things that this Hotfix addresses weren't big issues 5 years ago. But that strange "parking" behavior? C'mon. If I'm a Bad Guy, all I have to do is sit in the parking lot with Kismet running and listen for Windows XP machines to start cycling through their list of preferred networks. Depending upon the number and frequency of these probes, I can start making some fairly educated guesses about these wireless clients, and with a little extra effort on my part, I could setup my trusty Linux laptop in AP mode and start trying to trick unsuspecting users into connecting to me, at which time I can start collecting usernames and passwords and whatnot. If I'm so inclined, I can then take this information and compare it to data that I pull down from WiGLE and I can even start making guesses about where these users are located and places they frequent, based solely on this hemorraghing of information from the Windows XP Wireless Client. If you use Windows XP wirelessly, install this Hotfix immediately. In addition, be very careful with who you are talking to wirelessly. You never know who might be listening.

Well Said

Let me begin by saying that I've be a big fan of Richard Bejtlich's TaoSecurity blog for quite a while. If you've never visited his site, go there now. Truly excellent information from a man who clearly knows what he's talking about.

I started this morning as I do every morning: by reading about 2 dozen security related RSS feeds. After glancing at the latest crop of exploits and vulnerabilities, I saw that there was a new post on TaoSecurity. Bejtlich does a fantastic job of responding to a number of posts made on the DailyDave list. In short, he responds to a number of assertions that traditional IDS (particularly Snort) is of no value.

<rant>
My feeling is that if you think it is of no value, it is probably because you aren't using it correctly, aren't using it in the proper manner, and/or aren't using it in the correct location. It reminds me of when I was a kid and used to try to help my dad when he was working on the car or the lawnmower or whatever. I remeber him telling me that "a lot of it boils down to using the right tool for the right job." Can you just throw a Snort sensor any ol' place on your network and expect it to do everything? Of course not. You place them strategically, significantly modifying the rules policy based on where you're placing them and what you intend the primary purpose of the sensor to be. Should you use Snort or Bro or SHADOW exclusively? Again, of course not. The key here is an integrated approach, using a number of different tools that cover a lot of different potential attack vectors and have all of the logs and alerts sent back to a central aggregation point for detailed analysis. Event correlation using something like OSSEC (see my previous post) can go an awfully long way toward providing accurate detection of anomolies.
</rant>

Thanks, Richard, for a great, thought-provoking post on your blog.

Link

Brief Rant

<rant>
Every blog should have a good rant, so I figured it was time for me. In my day job, we've got several application vendors who have these GIANT applications that require telnet and don't support SSH. Personally, I think these people should be ashamed of themselves. One of the applications is a big financial system used by our HR department. The vendor flat-out won't support SSH. Let me repeat that: financial system, supports only telnet, won't support SSH. Am I the only one who has run into this? Not only do they not support SSH, they have no plans to support SSH. How a major vendor can have an application like this that doesn't support SSH is beyond me. Once again, we have a case of people who clearly don't understand the ramifications of their security-related decisions. I mean, their software ain't exactly cheap and they have very specific requirements in terms of the hardware and OS and whatnot. Ok, fine...up to this point, their requirements, though not the requirements that I would use for an application, are not without merit. But they think that it is just fine that the financial information from their system is floating around the local network in clear text. Now our network is switched, so that makes it a little better. But still, it only took about 10 seconds using Ettercap to demonstrate to the folks here how terrifying this fundamental lack of security really is. Everyone was suitably shocked, yet nothing changes.
</rant>

There. I feel much better now. Thank you for allowing me to vent. I'd love to hear if anyone else has run into this sort of problem or something similar.