If I ever cheated on a school test--and I'm not admitting that I did--it would have been in shop class. I'm all...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
thumbs with tools, and, without a bit of help from one of my more gifted friends, I might still be stuck in the 8th grade. Ironically, I later spent six summer and winter vacations working in a machine shop.
I learned that an unskilled person can do consistently useful work when a skilled person takes the time to provide some sort of jig, template or fixture--mechanisms to capture and share both knowledge and ability. Workshops are full of them--clamps, outlines, cutting squares, by-the-number diagrams.
Security is no different. We can use jigs and templates to provide unskilled users with a means for doing higher-level tasks, only we often call them "best practices." Rather than relying exclusively on skilled workers, they're the best way to do production work in the infosecurity shop. Inexperienced employees can perform more sophisticated tasks, and the C-suite loves them because it knows what to expect each time. It's no different than color-coded guides for cabling PCs, or wizards for installing new applications.
A great first "they know what to expect" template is a process used to evaluate the security ramifications and risk acceptability of applications. The business really doesn't want to buy insecure applications, and developers and application owners are naturally hesitant to do risk assessment because they want to avoid two extremes: an ever-changing set of requirements, or an overly long security checklist.
Security managers should be able to develop a one- or two-page form that captures all significant information needed for an initial assessment of a deployment or upgrade.
Can such a form capture all the information that could ever be needed to evaluate a product's security? No. But a well-designed template can capture enough information that the infosecurity staff can be 99 percent confident in allocating their limited time to a further review of the applications that are most at risk. The business will be much keener to support the in-depth reviews when it understands that you're using a documented process designed to avoid unnecessary data collection and debates over risk.
At a higher level, best-practice standards, such as Cobit and ISO 17799, are like kits, providing both the appropriate scope and the necessary functionality of repeatable processes that are typically required in most organizations. It's a myth that only feeble security managers use such process standards.
It's also a myth that the best infosecurity work is ad-libbed. There are certainly times when you need to use a master craftsman, but most ad hoc security work is perceived by the business as amateurish. It's good sense to avoid reinventing existing wheels, and much easier for external auditors and partners to evaluate the maturity of your program when it's based on generally accepted standards.
Maybe the rest of IT and the users aren't highly motivated to make security a top priority, but they really don't want to create security risks. They'll work with you if you work with them. Encourage cooperation by taking the guesswork out their dealings with infosecurity and using template-based processes.