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.
 |
|
Rate this Tip
|
To rate tips, you must be a member of SearchSecurity.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
|
