Those of you who have been reading the IT Security Weblog since I started writing for it in July 2007 probably find my emphasis on learning principles over techniques, as a means of ensuring quality and depth of ongoing security practice, quite familiar by now. The overall message is, in many ways, that techniques are ephemeral and you should be able to construct good practice from a solid understanding of principles; understanding principles is more important than memorizing "industry best practices."
That doesn't mean one should ignore those "industry best practices," however. Even if you find that they miss important points that an in depth understanding of security principles can provide, the very process of picking apart the flaws in widely accepted (but suboptimal) security techniques or checklists can provide one with an improved understanding of the principles involved.
Furthermore, the "industry best practices" approach to security is the standard by which the less enlightened judge security professionals. Like it or not, to be able to make ourselves heard when we attempt to educate others on good security practice founded on a principles-based approach, we must be able to present ourselves as knowledgeable experts according to the standards accepted by the majority population of the IT industry and those who deal with IT professionals on a daily basis.In "Why you can't get management on board," I discussed some of the reasons security-conscious IT professionals find it difficult to garner management support for policy enforcement, technology implementation, and new initiatives, for purposes of improving IT security in the organization. A follow-up article, "What do you do if management won't get on board?" addressed some career protection measures you can take to defend yourself against the ultimate fallout of working in an organization that refuses to take good security practice seriously. As TechRepublic community member Dana44 pointed out, the article didn't give any advice for how to get management "on board."
Frankly, attempting to provide comprehensive advice along those lines in a single article would be the height of folly. Volumes could be filled on the subject, and I must admit that the social aspect of IT security -- corporate politics, in short -- is not my area of expertise. You aren't likely to see books appear on the shelves of Barnes and Noble, authored by yours truly, that purport to explain how to maneuver and manipulate management's support for IT security initiatives. My usual approach is to simply know so much more about the subject than management that, if they're willing to pretend to listen to reason and I do a decent job of expressing myself, I run a pretty good chance of being able to get through to them.
Just to get my foot in the door with that kind of argument, however, I have to know more than the right answers to the right questions. If someone in upper management at some client corporation or in an organization where I'm employed starts spouting buzzwords as counterarguments without even knowing what he's talking about, I need to know these terms; if I say, "I haven't heard of cloud-based antivirus systems," I'll quickly start losing the attention and confidence of the manager, and any advice I give after that point will lose potency no matter how well researched and thought out it may be.
If you're just interested in security for purposes of securing your own resources, focus on principles, and on how to apply those principles in practice. Learn about software architecture as it applies to security, learn about networking systems, learn the basics of cryptography, and so on. You don't need to know terms like "Smart Protection Network" to know how to secure your laptops to the best of current ability to do so -- and, depending on how these pie-in-the-sky marketing schemes pushed by Trend Micro work out, you may never need to know.
If you're a security professional who has to deal with managers or clients whose security "expertise" comes from BusinessWeek, on the other hand, you need to be aware of the "cutting edge" in security buzzwordism. An abridged list of important things to know, if only so you know how to deconstruct them and counter them with a more solid, principles-based, analytical approach to solving a security problem, includes:
- The most popular tools of your trade -- both good and bad: You need to know about what people are using right now, what's being pushed at CIO conferences and in CIO periodicals, and what's in full-page ads in trade rags that managers mostly read for the pictures. This includes things like Secunia PSI and NSI (see Tom Olzak's coverage of Personal Software Inspector for more details on that tool), MS Exchange Server Intelligent Message Filter v2, and MOICE. You need to know about such tools that pertain to your current areas of security focus, even if you've already determined that the ideal software choices for the task at hand make such tools inapplicable, because if someone less knowledgeable than you brings them up you need to be able to give a convincing explanation from a perspective of educated authority to inspire confidence in your professional opinion.
- The popular topics in discussion of the future of security: I've already mentioned the Trend Micro CEO's preemptive marketing strike in favor of a "cloud" oriented antivirus plan for the future. Anything any of these security industry executives tells the trade press is fair game for managers to bring up and ask what you're doing to address the issues these tools supposedly solve. It's not enough to say, as in the case of the Internet "cloud," that even Eva Chen, the CEO of Trend Micro and the person who offered all those juicy quotes for the Register to report, doesn't know what that really means in practical terms yet -- that it's just a bunch of hand-waving so far, and hints at future product offerings from Trend Micro. You have to be able to identify probable solution characteristics in such an approach, and explain how they don't apply to your situation or are rendered moot points by the security plan you'd actually like management to support. Merely contradicting such people makes managers and executives question your competence even when you're right, because to them, the CEO of a security industry heavy hitter must be an expert to have gotten that far.
- The buzzwords and process framework terminology of a "best practices" approach: Anything that sounds like a buzzword is likely to come up at some point and bite you, if you aren't ready for it. Know the hot terms in security right now, starting with the term "industry best practices," and know how to use them to your advantage. Similarly, while you may be able to explain good practices backward and forward, if you don't know the terminology used by the "industry best practices" people, you may find yourself confused at the topic area of discussion even if, divested of OSTs and TLAs, it's actually a subject you know a lot about. It's important to recognize the appropriateness of the term privacy and to know why protecting it is an integral part of good security practices, to know how to protect your data from bad luck and malicious vandalism, and to understand how to ensure the security status of your IT resources, but that's not all you need to be able to discuss with management. You also need to know how to explain all that in terms of "componentized security models" and "security analysis frameworks" like the CIA Triad.
- The applicable checklists: Checklist approaches to IT security are a favorite target of ridicule for me when I'm discussing security with other security-conscious IT professionals, and it's a peeve of mine when it comes to the weak explanations people give for how secure their systems are even if they haven't performed the most rudimentary risk analysis for the system. You still need to research the most well-known and relevant "security policy frameworks" and other security checklists for the problem you're currently addressing. An approach I tend to prefer is to perform an initial risk assessment, determine a preliminary estimated best approach to securing systems, then research security checklists in that area. Once you've got a good solid collection of the things, see if there's anything in those checklists you can use to improve on your preliminary approach, then pick out a generally respected checklist that fits with your approach. Then, when some manager or executive starts waving around something like a Microsoft Operations Framework diagram, you can explain in fine detail how the security model and checklist you're using is a better fit than MOF's model and checklist for solving the problem that you need to address, and how you're not only addressing the requirements of this competing framework, but going above and beyond it to "cover needs and contingencies that no generalized framework can reasonably address."
- The opposing arguments: Finally, of course, when you run up against some conflict of ideas between an in-depth principles based approach to security you choose to champion and a half-baked, attention-grabbing bit of hand-waving intended to grab headlines and build mindshare, you need to be aware of the core arguments for the opposing viewpoint. If you don't know the common arguments in favor of "industry best practices" that simply won't effectively address your security issues and understand their failings sufficiently well to be able to cut them down when they spring up like weeds in the middle of your security strategy meeting, you may have big problems making a case for good security practices with upper management.
Without such knowledge of what most people in business think "security" means, you may find yourself unable to "get management on board," and that's not a situation in which you want to find yourself.
Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.