Columns

Don't Ask, Don't Tell

When mainframes ruled supreme, it was security through obscurity. Today we need better systems for keeping the entire enterprise secure.

• By Roberta Bragg
• 08/01/2001

In the days before desktops, when IT was MIS and the words computer and mainframe were synonymous, non-MIS employees weren't supposed to understand, let alone attempt to learn about, anything digital. They weren't supposed to ask, and MIS wasn't supposed to tell.

Part of the benefit of this "security through obscurity" was that since few people knew how systems worked, equally few could access them in any form other than the carefully prescribed venue meted out to those with a "need to know." When I first worked with computers, punch cards ruled. Do you remember that? We punched customer orders, inventory totals and shipping information data. Later, we did the same thing online, but we could access only specially constructed pages and enter only designated types of information. Oh, we could make mistakes, but we couldn't enter data that was too long or put a name where a date should go. No buffer overruns. Call up a report on a customer? Print out a list of order information? Not from our terminals, not with our log-on IDs.

Enter the desktop and the desire, nay, the "right" of all to access data. Midrange systems sprouted where once manual systems reigned. Mighty battles raged over who had access to what and when. The mainframe guys looked down their noses at the Unix folks. The Unix people sneered back. Both camps considered PCs to be toys. Women? There weren't enough of us to register on the charts.

Few of these systems could talk to each other. In the early 1980s, my team celebrated wildly and earned a significant bonus for figuring out how to use a Kaypro (those early, pre-IBM, CPM-based PCs) and a 900-baud modem to connect to a Honeywell mainframe. Remotely accessing the mainframe from a branch office—exciting stuff!

Now systems are expected to work together, and everyone wants to constantly access data of every kind from anywhere. Is the information in a legacy database on the mainframe? No problem. Is it spread across S/390s, AS/400s, with a Solaris and plenty of Windows NT servers sprinkled in? Piece of cake. Some VP wants to know if you can share information with business partners across the Internet, maybe even partner with suppliers on a b-to-b site. It's all expected as part of the confluence of business and technology.

What all this means is that information on technology and how to use it is readily available to the curious, serious and delirious. There's a multitude of products and a plethora of consultants to help you out, and there are products to do almost everything you can imagine—everything but assure you that what you do is secure.

It's not that top management thinks security is unimportant. The problem is determining how security can be achieved in today's complex technological environment—and who pays for it. Where can you find information on keeping your mainframe and midrange systems secure? How do you harden an AIX or an AS/400? Why don't these systems get the media attention that Windows does?

Do global management systems weaken or strengthen system and enterprise security? What about Web-based access to data sitting on your S/390? Will an IBM iSeries or your existing S/390 make a more secure Web server? Which should you recommend for your company's latest e-business push? Do your mission-critical applications, Web and e-commerce solutions integrate their security with your mainframe RACF implementation, or do these apps maintain their own, less well-protected security controls? Are new gateways and the use of protocols like RPC ensuring connectivity between Web browsers and CICS systems or opening up new vulnerabilities?

What's the best firewall for your enterprise? Who should the chief security officer report to? How do you write security policies? How can you meet the requirements of HIPPA? What security conference is a must to attend this year? Should you send someone on your staff for a CISSP certification, or maybe SAN's GIAC? What about PKI, biometrics, file encryption and VPNs? How do you get funding for all of these projects, and how do you decide which should be implemented first?

In this new monthly column, I'll be discussing these enterprise security issues and many more. I've been blessed in my long and checkered career in information systems by working with, around and for world-class experts in a variety of systems, networks and applications—everything from mainframes to pocket PCs, Terminet to Telnet, SNA to DNA, centralized administration to distributed control, private networks to the Internet.

For the last several years, I've focused on information systems security, and I see this column as an opportunity to give a little back. In each issue, I'll dig deep into a security issue and provide you with facts and figures, thoughts and references. My list above reflects some of the concerns my customers are voicing—and I welcome your e-mail on what else you'd like to see covered. Security through obscurity is behind us. Just ask—and I'll tell.

How to Beef Up Your Security Budget Convincing the CFO to cough up more dollars for security is simple. You're just using the wrong method to ask for money. Instead of raising the specter of various disasters, you need to make a hard-hitting business case. That means laying out the dollars and cents. Stop asking for expensive "security" solutions to risks that few understand and fewer still believe will impact the company. Instead start asking for solutions to business issues by portraying security as something that will ultimately save the bottom line. Let me give you a couple of simple examples. Does your company specify that all servers have at least hardware-implemented RAID drives? RAID drives are usually implemented to support fault tolerance, as you know. In multiple-drive configurations, if a single hard drive fails, the data remains available. Sure, you could restore from backup-but can you justify the extra hardware by estimating how much business you'd lose during that restore time? While RAID arrays can be expensive, their cost often pales next to the cost of downtime-a fact that you can effectively point out to the CFO. How about blocking employee access to stock ticker downloads, Internet broadcasts of radio programs or music downloads? Implementing a port screening router-or better yet, a firewall-will block this kind of non-business use and probably greatly reduce bandwidth needs, which can translate into big savings. You might also budget to send the firewall administrator to training so he can learn this and many other essential techniques-thus saving the company money. In addition, having staff selectively screen the data you allow to enter the network reduces the risk of Trojan horses and other attacks. Given all this, exactly how do you move focus away from the fear of what might happen and into the realm of statistical projections? You need to translate this, after all, into terms that the business side will understand. Here's where the Business Impact Analysis (BIA) comes in handy. BIAs have been done for years on such things as the loss to business after a tornado levels a manufacturing plant. The calculation includes much, much more than the cost to rebuild the plant-it includes the loss of business during the rebuild. Likewise, since the information in your data systems is critical to business operation, the impact of loss or downtime can be calculated. Financial institutions like banks and insurance companies have estimated that a day's outage, or even less, could easily precipitate bankruptcy. Now think for a minute about the impact of 12 hours of downtime on a key set of servers in your division. That's the start of your Business Impact Analysis. —R.B.