System iNetwork

August 18, 2008

True Security Requires Philosophical Shift

Today's security is not your father's security. For a company to be thoroughly secure, a paradigm change from "IT and software create the solution" to "business needs define and shape the solution" is essential, according to Group8 Security, Inc. To explore this philosophical shift and get some tips for you on how to accomplish it within your organization, I spoke with Pat Botz, Group8's vice president of security consulting and formerly IBM's lead security architect for the System i platform and i5/OS.

What is your biggest challenge when it comes to helping customers understand the importance of security?

Botz: The biggest challenge tends to be helping the technical folks understand the difference between applying technology to enforce behavior versus defining the behavior that needs to be enforced. The biggest mistake I see most customers making is with the IT department thinking they're responsible for defining the business behaviors.

That whole philosophy is what Group8 Security is based on: To improve security, we all need to take security out of the "it's a technical problem" realm and take it into the "it's a business problem" realm.

Do you get resistance?

Botz: It depends on the audience I'm talking to. If I'm talking to the more technical leadership, I tend to get resistance. If I'm talking to the higher-level management, either in IT or at the CIO level, there is less resistance. I have a presentation that I give, Demystifying Security, that goes over all this with both audiences. I have been told by at least one CIO after this presentation that I was the first person that he ever talked to about security that actually said anything he could understand. The point is that Demystifying Security isn't a technical presentation. The definition of security is specific to each organization, and unless an organization actually defines what security means, there's no way anybody can measure whether they've achieved the objective of "securing" their business assets.

With the technical people, when I talk to them about this philosophical shift, most of the time their reaction is, "That's fine and good, but our business guys won't get involved." My response is that it's a communication problem. The way to overcome that is not to have the tech guys speak in tech lingo but rather have them speak in business lingo. I always encourage technical people to never use words like "database" or "entries" or "objects." I encourage them to speak only in terms of business assets. So whatever application you're using for the finance department, you should speak in terms of that application and the business function it performs.

I believe one of the reasons that business has abdicated its rightful role in all this is because the terminology that's been used has always been extremely technical. Here's an analogy I like to use:

Before computers, how was information stored and managed? It was on paper, and that paper was stored in filing cabinets. When the information was in filing cabinets, which department was responsible for the filing cabinets, to make sure they opened, they didn't squeak, and the locks worked? The facilities department. But which department was responsible for determining which employees had keys to those cabinets? The managers of the departments that owned or managed the various data. When we moved to computers, somehow we decided it was the IT department that should be responsible for figuring out who gets the keys to the data. And that's always been wrong. Because of the way computers came in to business and the way the industry grew, organizations lost sight of the fact that IT facilitates the management of information; it doesn't own the information.

Do you feel like you're making progress in helping companies shift their philosophy about security?

Botz: Yes, not every client, but I think in general we have made progress, because every client I work with, the first thing I do is help them define what the business requirements and business assets are, which typically coincide with the applications they have. Then I help them define the various employee roles that interact with those business assets, and next I help them define the limits of those interactions. Once these are defined, it's typically easy to show them how to most cost effectively manage access to their assets in a way that enforces those business rules.

Does Group8 have any security software products?

Botz: We do not sell software, but we do develop software, and typically we'll retain the rights to that software so that we can use it with all our customers. There are a couple of ideas behind that. (1) We don't intend to build monolithic solutions. In fact, I believe that there are enough monolithic solutions out there, and there's a problem with them, in that many are sold under the claim that "you need only one tool for security, and ours is that tool." The reality is that most of those products are good and perform a useful and vital function, but they're not the total solution. (2) The software we build--I call it utility software--is the stuff that ties existing functions--be they operating system, third-party solutions, or home grown--together in a way that helps these monolithic solutions integrate more effectively or cost efficiently with the customer's environments. Often we'll pull together disparate functions that on the surface may not seem to be security centric but that when you pull them together provide a very useful security function. I think that's really an important distinction: We don't sell software licenses; we provide our utilities as part of our consulting engagements, and mostly with the source code. They are utilities with very specific functions and are not full-blown apps, so the support isn't nearly as critical as it would be for a very large, general-purpose app.

We have been building and will continue to build up a whole set of these utilities for our customers, and the customers can use the ones that make sense for them. They're not betting the farm on our software at all.

What kind of software utilities have you been building?

Botz: One of the recent ones that I find really interesting was for a customer who had a lot of image data stored in the IFS, and that data contained credit card numbers. The customer was using IBM's Content Manager to manage that information and wanted to be able to encrypt/decrypt that information in the IFS without having to change Content Manager and without having to change apps--and do it in a way that didn't require a bunch of front-end or backend processing on the data. We designed and implemented a mechanism that did that transparently with tie-ins through IFS exit points. Now at the OS level, we transparently encrypt image data being stored in specific directories and only if being stored by the Content Manager application. On the other end, we will decrypt that data transparently, only if it is being read by Content Manager. Content Manager makes all access control decisions as it normally does. And that's done through just a couple of rather small programs. We provided a way for data stored in specific IFS directories to be encrypted/decrypted transparently without changing any applications.

Another utility we built in effect securely propagates adopted authority from one job, submitting another job, to the submitted job. This functionality makes it much easier and cheaper to build role-based accessed control models by using adopted authority. The utility actually adds the adopted authority back at the time the submitted job is executed, but the effect is the ability to propagate adopted authority to submitted jobs.

We have several other utilities related to password elimination and single sign-on also.

What do security software vendors think of Group8?

Botz: We don't sell software, and we wouldn't sell software that competes with existing vendor solutions. Our goal is always to help customers use whatever tools or solutions they have as effectively and efficiently as possible, or to select solutions that best fit their needs, in order to help them accomplish their security needs. In a competitive environment, third-party solutions get sold as, "Our solution is the best one out there." But sales folks often take this further to imply that you cannot be secure without their software. The claim that software alone makes you either secure or not secure is invalid. The only reason to buy or use any security software is if that software makes it cheaper for you to enforce the behaviors that you need to enforce. Software doesn't make you secure; enforcing the appropriate business behaviors makes you secure. Software's purpose is to make it cheaper and easier for you to enforce desired behaviors. If you enforce the right behaviors, you are "secure." Software merely impacts the cost of enforcing the right behaviors.

For example, theoretically, you could hire an army of people to check every TCP/IP packet that comes in on your network. But that's not cheap. That's an example in which software, a firewall, makes it less costly for you to enforce the behaviors that you want to enforce.

In general, I think you'll find that the technical people at those vendors would agree, at least to a high extent, with what I'm saying. And I think in lots of cases the sales forces will go with the messages that they've been successful with.

Something I run into all the time is that a lot of companies in the System i space have exit-point solutions. One statement I hear is, "We bought software x because it covers more exit points than software y." That is a moot point because exit points are only one piece of your security, and if you are managing security correctly, you probably don't even need to cover all exit points. Exit point programs are just one of the tools you can use to reduce the cost of enforcing the behaviors you need to enforce. There are other ways to protect interfaces associated with exit points--for example, don't start them. The fact that one product covers more exit points than another is not really a valid point on which to make a purchase decision. The only valid consideration is, "Can we use this product to more efficiently and cost effectively enforce the behaviors we need to enforce?"

Does Group8's clientele consist only of System i customers, or is its clientele broader?

Botz: It's broader than System i. We're working with a large US retailer right now, and that project includes some System i work but also AIX and Solaris work.

What types of companies are asking for help?

Botz: What's been interesting and gratifying to me is that we've worked with all sorts of customers--for example, from a five-person IT shop to a very large 2,000-person IT shop. So we're able to help at a number of different levels. When we work with the larger customers, most often we're helping those customers determine the best way to technically enforce policy. When we work with smaller companies, often we're helping them understand exactly what their policy is or should be and helping them make business decisions about policy, not just technical decisions.

--Linda Harty, security & networking/connectivity editor

Posted by lharty at August 18, 2008 5:10 PM