Stop reinventing the security wheel
By Robert Scheier
How many security standards -- official and unofficial -- do you have in your organization? The answer probably is: Too many, and we spend far too much time and effort creating them.
For starters, there's probably a fairly vague enterprise-wide standard, somewhere along the lines of "brush your teeth and be nice to others." At the business-unit level, there's probably a more specific policy, and at the workgroup level it gets more specific and more tightly enforced, especially if the users are handling financial transactions or customer information.
Then there are security policies built around different kinds of data. Top-level, aggregated data about sales should be protected to a certain, definable standard. But a specific customer's sales history should be protected by a different and higher standard of security. You could also argue for user-specific security policies: A distributor who accesses your parts database a few times a year to buy a few commodity items doesn't need the same expensive authentication you'd throw at a contract manufacturer who's working under NDA to build a prototype of your next killer product.
Yes, you could create a different security policy for each of these scenarios. But why should you? Are your different types of security needs -- whether defined by customer, by user or by type of data -- that much different from the rest of the world's?
I got to thinking about this the other day while talking to a start-up developing a set of context-sensitive encryption technologies. Rather than enforce security through the use of individual passwords and authentication, this vendor plans to take an object-like approach where encrypted data would contain security rules about when it would, or would not, allow itself to be decrypted. Rather than rely only on passwords, firewalls or intrusion detection systems, the data object itself would be able to tell whether or not a user should have access to it.
I have no idea how well this would work in the real world. But the idea of an object-oriented approach to security got me thinking about reusability, which is one of the prime attractions of object-oriented development. If we can reuse software components, I thought, why not create reusable security policies that could be applied across applications, across entire companies and maybe across entire industries?
Think about building a Web marketplace, for example. You'll need different security policies for different levels of customers, suppliers and shippers, but that's true whether you're trading semiconductors, energy or chemicals. Or consider an intranet designed to speed the internal budget process. You'll want one security policy to protect top-level departmental spending data and another, tighter policy to guard specific employee salary information. But the requirements for those two security policies will be about the same whether you're the CIA or a chain of pet stores.
For many security needs, I'd argue, you can define a set of common, accepted safe practices much like the building codes in place for virtually every municipality. Such codes specify, for example, how much artificial light must be available per square foot in public buildings. In frigid Maine, such codes might require a certain minimum slant to the roof to prevent ice buildup. In hot and humid Mississippi, the code might specify certain types of treated wood to prevent insect damage.
My point is that any given type of building has a lot of common requirements that can be established once, rather than reinvented by every builder or architect. The architects and builders then compete on extra features such as elegance of design, speed of construction, or quality beyond the minimum called for in the building code.
Of course, the construction industry is far more mature than the software or the security industry. And we do have security standards that have evolved around specific technologies, as well as standards Balkanized across vertical markets, such as Visa's Cardholder Information Security Program (CISP) or the federal government's Health Insurance Portability and Accountability Act (HIPAA).
But I think we have fundamental, common, infrastructure-level security needs that can and should be established and enforced, much like a building code. That will allow security administrators (and vendors) to tackle the very difficult, industry-specific security challenges that remain -- as well as the day-to-day firefighting that is always a security manager's first priority.
About the author:
Robert L. Scheier is a freelance writer based in Boylston, Mass., who writes frequently about security issues.
Dig deeper on Information Security Policies, Procedures and Guidelines