Problem solve Get help with specific problems with your technologies, process and projects.

Art of budgeting: How to ask for money for information security (Part 2)

Part 2 deals with how to explain the risks of not investing in security

All great ideas ultimately regress into budgets. That is the cast-iron law of corporate and governmental conduct....

It particularly applies to all matters of the technological persuasion. It guides any pleadings to spend on information security. Information security programs will choke without an adequate and steady supply of cash. That is just like trying to live on rarified oxygen. The difference is that a strangled information security program is not only dangerous but can also produce unpredictable consequences costing far more than anybody can imagine. Therefore, the art of securing money for information security is perhaps the most important skill if you are to safeguard the information assets of an organization.

This story is a sequel to what I wrote at the end of September for I explained that you do not apply the same logic as when asking for protection against a bank hold-up. Just consider that your networked information systems contain thousands of cracks open to electronic intrusions. What you most likely have are millions of lines of shantytown quality codes, mostly exposed to destructive infections. As compared with your problems, the job of securing a brick bank building is easy, except that your budget-time examiners will continue to reflect a banker's mentality. That's why trying to get money for information security is tough.

In the preceding story, I explained that you must start the budget-pleading process by following the principle: "If you wish to justify it, you must be able to value it." I pointed out that the information security business is actually a peculiar form of an insurance business where the worth of the insured property must be set before you can start talking about the insurance premiums. That leads me directly to the next steps in the budget justification process: How do I explain the inherent risks I am supposed to protect against?

Step #3: Security risks from compromised hardware and communications

Chances are that the flinty-eye financial experts who must pass over your requests do not have much of an appreciation for the improvised characteristics of your server, modem, router, desktop, laptop and palm-top configurations when they are all strung together. Your inquisitors will find it incomprehensible to imagine all of the combinations of snafus that can occur when you make it possible for your consultants, customers, suppliers, temporary workers and workers-at-home (including their occasional surfing teenager) to plug into your network. The mentality you must overcome is one that still sees computer network security as something analogous to protecting a hard asset. The idea that all that you need is a fortress never goes away. It is very hard to get across that there are no fortresses where you can pile up your information assets. What you are trying to do is to protect tribes (sometimes wild) wandering through a jungle.

The last thing you should ever to do is try to "educate" your audience. By the time you get to your 60th slide your listeners' eyes will glaze over. The best you can accomplish is to extract token funding that is sufficient to shut you up.

My advice is that you should take everyone for an excursion through a listing of the latest security infractions. You must do this in the most gory detail possible, explaining for instance how one of the central routers, while under emergency maintenance by the vendor, left the president's e-mail naked to examination. After you do a few of more of such autopsies, preferably affecting the individuals in the room, everybody will get the message. To get your point fully across you can then cheerfully conclude that what you displayed was a poor sample because your information security spending is inadequate. Tell them that when you find five cockroaches in a basement you can be certain you may have hundreds!

My "cockroach" demonstration method always works, but is risky. It will be like spitting into a soup prepared by a gourmet cook who happens to be your cousin. Your position as a person of integrity, of independence and with good job security must be unquestionable. Under no circumstances can you pull this off if you report to anyone who may be accountable for the goofs that you have paraded before the moneybags. You will need partners who will share whatever you will be getting. Make sure that under the title of "security" there is also money for fancy new black boxes for those managers who can excuse their lapses by not having those.

Step #4: Security risks from compromised software

Trying to explain the security vulnerabilities of Microsoft NT is even more hopeless than trying to explain why only one modem in a huge network is sufficient for total corruption of everything. The simple fact is that software security risks are largely a matter of faulty design. They are largely committed errors, not mishaps. The widely accepted fiction about software failures is that they originate from unscrupulous and undesirable nerds from Mensa. These perpetrators prey on scout-like, well-meaning Joes trying to make a decent living as computer professionals, the best they know how. Nothing could be further from reality. It is the Joes, especially undisciplined programmers, software contractors and software vendors, who try to rush a software patch into a computer in order to fix something that does not work or to be able to collect for it, or both. If you get a chance to talk to hackers, they will tell you that their craft depends on exploiting known gaps in poorly constructed computer programs. Professional hackers exude with pride in showing off how the stupidities of their better-paid victims make their exploits feasible.

To secure the crumbling footings supporting your software shantytown requires funding that should not be peddled as "information security" but as "independently verifiable software engineering." Your principal effort should be to instill into your software sources the fear that their transgressions will be always noted and never forgotten. Your executive management should see you as the supreme Auditor that safeguards their shareholders' interests and not as just another short-tenure techie who speaks incomprehensiblese.

When it comes to budgets, you should realize that management rarely debates well thought out money requests from the Comptroller and the Auditor (or Inspector General). The designation for such classes of people is that they are "fiduciaries." Well, it will ease your budget-period pains if you can clothe your information security budget requests into such packaging.

For another installment of budget survival instructions, please tune in next month. December is hacker-month because kids are on vacation and nobody talks budget X-mas time!

To read the preceding article, click here.

About the author:

Paul A. Strassmann ( services as the chief information systems executive started in 1957. Since his "retirement" in 1993, he has continued engagements in matters related to information security.

This was last published in December 2000

Dig Deeper on Security vendor mergers and acquisitions

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.