Security by Committee: A Lose/Lose Proposition

An overengineered design derails a simple user request, but Jude gets thumbs-up for smart cards

I was looking through the Computerworld Security Watch forums just before starting my column this week when I found this post from Neil Taylor: "If you want an effective security officer, you have to make damn sure [the security officer will] treat it as equally important to get information to those that need it as to withhold access from those that don't."

Absolutely spot on, Mr. Taylor. I agree that our job is not to get in people's way, but to help them achieve their business objectives in a secure fashion. Unfortunately, it doesn't always happen that way.

Security's Split Personality

My job can be divided into two parts: finding existing or potential problems, and fixing those problems. Despite the fact that it sometimes takes a great deal of specialist knowledge to find problems, I believe that fixing them is more difficult by far. Finding a practical solution that balances functionality and control - and then actually implementing that solution - always seems to be a much more difficult process than you would ever imagine.


This Week's Glossary

Integrated Services Digital Network (ISDN): A dedicated digital circuit available from telephone companies. ISDN provides a single network connection for a PC or other network device. Users generally pay a monthly fee plus usage charges. The circuit is relatively secure compared with running a virtual private network over the Internet, but the total available bandwidth for a basic circuit caps out at 128K bit/sec.

The following are some of the resources Jude is using as he researches his smart-card security project:

Irvine, Calif.-based Litronic Inc. is a provider of public-key infrastructure products and services. This white paper overview of smart cards is refreshingly clear and lucid - and an excellent place to start.

Another white paper, at the TechNet area of Microsoft Corp.'s Web site, offers details on the smart-card support included in Windows NT and Windows 2000 servers, including a description of related application programming interfaces and the Smart Card Software Development Kit. It also lists all the other members of the International Standards Organization's PC/SC working group.

Honeywell Westinghouse Security Electronics' site includes information on physical access-control products, including proximity card systems, which use card readers and other devices to control users' physical access to building areas.

Eric Murray, an independent security consultant, posted this academic paper on smart-card security threats on his personal Web site. The paper focuses on one specific intelligent card reader but also includes useful information on security risks inherent in different smart-card models and how to plug those holes to prevent attacks.


Here's an example: One of our business teams gets regular data feeds from an external supplier. At the moment, the supplier sends this data over an Integrated Services Digital Network line, but for reasons of convenience, speed and reliability, the team wants it sent over the Internet.

We initiate all the downloads from our end, so we have control over what gets sent, and when and how it gets sent. And all of the data is in the public domain, so we really don't care if someone eavesdrops. This should make it very simple to secure.

Unfortunately, when the business team sends the request to IT audit and global IT security for approval, a long e-mail conversation starts. Gradually, every person who might have the faintest interest in the outcome - and an awful lot of people who don't - receive a copy of the message. As soon as one person suggests a possible solution, another points out some technical or procedural drawback that limits the security.

By the time this process of decision-by-committee reaches its conclusion, the solution that is being proposed involves changing the network topology, upgrading most of our firewalls and re-engineering the original application.

The resulting design is, admittedly, quite secure and would be extensible to similar cases in the future. But because it's so complex and would require so many resources, it would take months - if not years - to implement, even if there weren't a long list of other projects that take priority.

In the meantime, the business team that requested the change has given up on the whole idea on the grounds that it takes so much effort to get a straight answer out of the security department that it isn't worth doing.

Not an Isolated Problem

This is a classic example of a lose/ lose situation. The business unit has lost out because it failed to get the improved functionality it wanted. The security department has lost out because the business is still using the old, insecure solution.

The problem doesn't seem to be limited to my company. I had a similar experience when I tried to view my United Air Lines frequent-flier account on the Web. I opened the account by filling out a paper form, and I received with my new account number an invitation to check my balance on the company's Web site.

However, the United Web site demanded that I reregister all my personal details in order to get an account on the company's servers, and it included the ominous warning that if I already have an account, all the personal details I register on the Web server must be identical to those I have already registered in the past.

If they've already got my personal details, why waste my time typing them in again? If they haven't yet, how are they going to check that the two sets are the same?

When I finally reregistered, I found out that I couldn't access the account until United mailed me an access code for validating the password that I had entered, which they required in order to verify that I'm the holder of the appropriate account on the Web site, which must be the same as the account that I was already given. Get it? To cap it all, this access takes up to five weeks to activate!

I can almost hear the security guy who dreamed up all these restrictions. I'm sure it's a pretty secure approach. But the frequent-flier scheme was designed to be a marketing program to attract and retain customers. Putting so many obstructive and unhelpful security precautions in the way has quite the opposite effect.

Yes, United needs security to prevent fraud, but that security should support the program's aims, not damage them.

A Green Light for Smart Cards

In a previous column, I mentioned my idea to use a smart card to control access to both our buildings and each user's PC, thus removing the need for those annoying, insecure passwords.

I spent a fair amount of time this week putting some flesh on the bones of the idea, writing up a project proposal and pitching it to management. Every manager I spoke with liked the idea and then referred it upward, so I ended up pitching it to the global chief technology officer, about five management levels above me. He was enthusiastic, so I have the go-ahead for the project.

The first step is the proof of concept. So far, I have only verbal assurances from the vendors that they can provide the main component: a proximity card for the doors to the building and a smart card for the PC itself, combined into one unit.

Also, I have only limited knowledge of how to integrate smart-card-based authentication into Windows 2000. Before I ask anyone to commit significant amounts of time, effort and money, I have to show that it can be done.

My goal for the next three months is to do all the background research, then produce one card that will give me access to one Windows PC and one building. Now I need to get my hands on some real hardware and software and start trying to make something work. Technical work, at last!

• This journal is written by a real security manager, "Jude Thaddeus," whose name and employer have been disguised for obvious reasons. It's posted weekly at and at to help you and your security manager better solve security problems. Contact him at or head to the forums. (Note: Registration required to post message; anyone may read messages. To register for our forums, click here).

Copyright © 2000 IDG Communications, Inc.

8 highly useful Slack bots for teams
Shop Tech Products at Amazon