Security ROI - Time to Think Differently
How many times have you been asked about the Return On Investment (ROI) for some security product you were thinking of purchasing? For most of you, it’s probably a great deal. And determining ROI has likely not been easy either. How much productivity might be lost due to a breach? How do I count the time? Do I base it on wages, lost sales, reputation, or damage?
Perhaps, however, you’ve been approaching the question from the wrong perspective. Try asking yourself what you might NOT be able to do if you had a system completely devoid of any security. Would it work at all? The answer is probably not.
The problem has been that security has been an afterthought for far too long. Our thinking goes something like this: “What do I need to get done, and what should I buy to help me do it?” Historically, that’s where the questions end. This it typically true whether you were purchasing a new computer to roll out to your company or designing a new piece of software at Microsoft.
Again, what if you consider your requirements from a different perspective? Many years ago at MCI, I was contracted to be part of a team working with British Telecom and Microsoft. Our job was to try to create “hosted intranets.” If we hosted your servers and you could connect to them from anywhere, bingo, we’d have a huge seller (this was 1997, so it was a pretty brazen idea).
Anyway, my job was to be in charge of the security for the project. I was going to secure “Hosted Intranets.” Uh huh, ok…hmm…how??
If memory serves, our inaugural meeting for the project was at the Ritz-Carlton, Pentagon City. In a grand ballroom we brought all the teams together; those devoted to the hardware, the network, the software, and me. Every team had numerous members (except for mine). At some point we were told to prepare for a brief presentation. “Tell us what you’re going to do to get your part of the project over the finish line.” Given the fact that I had been hired for the job by Vint Cerf, I was feeling pretty intimidated. “What the heck am I going to say?”, I thought.
Well, eventually my turn arose, and I noticed Vint standing in the back of the room. I answered, “Me, well, I’m not going to do anything…you’re going to do my work for me.”
I went on to explain that there was nothing for me to do, but sit in on all of their meetings and ensure that they each considered all of the security aspects required for their components of the project. By designing security into the specifications, we could ensure there would be no holes anywhere that would later need to be filled. Networks needed firewalls and ACLs on routers, servers needed to be hardened or have functionality designated to different adapters each serving a different realm of connections, software needed to enforce authorization and authentication, etc.
Once the security was designed into the other components, the actual cost of security became zero. There was no security that was just there for security’s sake. It was present to augment, or support, some other feature of the whole. As each security requirement was introduced to the individual teams it was discussed both from the perspective of cost versus benefit, and operation versus function. Could we use a cheaper product? Could we do it with less security? Could we manage it with fewer people? In essence, we discussed all of the things you’d do if you were talking about a non-security component. After all, where’s the difference once you understand the feature’s need within the entire scheme of things?
For example, I don’t need authentication just for security’s sake, I can’t produce assured billing if I can’t back up my claims of your access, so authentication is as required to make money as it is to assure only your employees can access your Intranet. Try and identify a security feature that doesn’t have an operational function similar to this. You won’t be able to because they all do. I need AV to avoid the costly restoration of files on a file server, conversely, I need AV to ensure the availability of files on a file server. Call it semantics if you want, but the difference in wording means the difference between justifying ROI of AV versus justifying the ROI of file servers. It’s far easier to justify the cost of a file server with AV than it is to justify AV on its own.
Public Key Infrastructure (PKI) is another one of those security topics that suffers enormously due to the security ROI bunk. Introducing PKI can have significant up-front costs; however, when you realize that’s simply because you’ve probably been lacking in your infrastructure prior to it, you may find it can be much easier to justify the cost of PKI. Abuse of reusable passwords is probably one of the oldest, and most common, sources of breaches. Many have gone to tokens to avoid this problem (at no small cost I might add). More often than not it is because PKI was not well understood by the people entrusted to implement a new scheme, or because tokens appear cheaper than PKI up-front. It can also be due to the fact that tokens seem to be more easily bolted on to existing environments without having to make changes to that environment.
If you actually look closely at PKI, and talk to people who really know, you’ll soon see that an infrastructure that has PKI available has many more capabilities, yet have so much less modification and cost, than any other environment. Not only will you exceed all standards or regulations that might impose on you, but you’ll have the flexibility to do pretty much anything you want easily. So, with a minor perspective shift, you can view the costs of PKI not as standalone costs, but, more accurately, as an augmentation to the cost of your network, servers, desktops and software. You would also see that the minor increase is significantly offset by the reduced cost (and headache involved) in help desk, software maintenance and licensing.
Intrusion Detection/Prevention Systems are probably the most difficult to justify. Typically they do very little out of the box, and require an investment in training and deployment to provide much use. Not that this is terribly different from any other component of your environment, but they are so often not dealt with appropriately that, in the long run, they typically provide the least benefits versus cost. This doesn’t need to be the case, but for you not to fall into this common trap you have to fully appreciate the purpose of such tools, and know how you’re going to incorporate them into your regular operations. Having them managed by a third party is often more cost effective, as it helps you to avoid having to have trained personnel and maintain updates.
Whichever way you go, if you’ve considered the components functionality and operational requirements carefully, and decided it is a requirement of your environment then its cost is merely another add-on to the whole.
So now the problem becomes “How do I get these new infrastructure components if I have to justify them using the cost of the entire environment?”
Well, the answer to this is fairly obvious. You need to revalue your environment and show how, without these components, the risk you’re presented with outweighs the cost of bringing it up to snuff. In other words, show how the costs in the future are going to be reduced due to the increased capabilities of the network. You won’t have to purchase something to comply with a new regulation; you’ll simply be implementing some new aspect of your PKI. Since new deployments of PCs will incorporate a swath of security features such as AV, client-side certificates, and other agents, the management and maintenance of those PCs will be easier. Audits will be cheaper because you’ll have a far better understanding of what exists, where the transaction zones are, and how they’re being managed securely.
So while it is a very old adage, its time for you to build security into your environment rather than try to bolt it on, and get everyone to agree to forget about security ROI.
Tags: Information Security, InfoSec, risk
