Distributed Security

An Approach to Finding and Filling Security Holes.

As companies begin to rely more and more on the Internet and distributed systems, the need for increased security is becoming more important than ever. Every week, it seems, I hear about another security breach. Sometimes the amount of money lost through fraud related to a security breach is staggering. In other situations, the results are merely embarrassing or disruptive. These situations can occur in a traditional system as well, but the potential risk is multiplied in a distributed environment. The Internet is especially vulnerable to security risks. This lack of action results from confusion about security issues and products. Often, managers don't know what they need and which types of products will address those needs. When they do implement a security product, it is often the wrong product for the task. For example, organizations may try to implement an authentication product to manage user accounts and user access. However, authentication products only ensure that the users are who they say they are. You need a different tool to administer end-user security.

Such confusion occurs because organizations lack a way to identify, categorize, and prioritize their security needs and to map their situation to the available tools. Managers need a structured approach for identifying pressing security requirements and classifying, categorizing, and comparing the ever-diverging security solutions.

To understand better the security market and which products solve specific problems, I've divided the distributed security environment into five related areas containing 12 segments:

• network integrity -- firewall and communication security
• system integrity -- virus detection and prevention, risk assessment, intrusion detection, and centralized auditing
• user account integrity -- user group administration, single sign-on, and authentication
• Application/data integrity -- access control and authorization
• data confidentiality and privacy -- encryption.

Some of the 12 segments are already familiar to you. I don't expect, for instance, that anyone today puts up a gateway to the Internet or any other external network without a firewall. Similarly, any organization that is considering electronic commerce is already planning its communication security with some level of encryption. Customers are not willing to pass information about themselves or their credit cards over the network without encryption.

Given that you have already started to address your network integrity requirements by implementing a firewall, you are no doubt wrestling with prioritizing which of the other security requirements to address. Should it be data confidentiality for the extensive amount of email that your company seems to generate and has grown to depend upon? Perhaps you should target application integrity because of that SAP decision you just made. In light of all the system break-ins in the press recently, it would be wise to concentrate your efforts in the short term on building a defensible security perimeter to maintain your system integrity. So instead of going through each of these 12 segments individually, I am going to focus on a few key areas that are of maximum concern to the integrity of your business systems, some of which have not gotten the attention they deserve.

The first issue with maintaining system integrity is that of performing risk assessments. Risk assessment refers to the process of inspecting the distributed environment in search of security weak spots and outright security holes. The products in this category, such as Veritas Software Corp.'s Axxion-SecureMax and Axent Technology Inc.'s OmniGuard/ESM, provide proactive inspection of systems, databases, and applications. They look for weak security configurations and known security holes that could be exploited. The outputs from these products are commonly referred to as security audits, but they should not be confused with the centralized audit trails that are part of a different market segment.

The need to do risk assessment has become apparent with the growth of distributed computing. Users are sending names and passwords in the clear, over the network. Suddenly, organizations find that they have users accessing vital databases from their PC across the network, unchecked and unprotected, bypassing the database server operating system altogether. The problem isn't limited to databases. Users are doing the same with powerful, mission-critical production applications such as SAP.

Risk assessment doesn't fix the problem. It only tells you that you have a problem by pointing out the security holes. You'll have to use other tools to close the hole, but at least you'll know what the hole is and get the right tool.

The second issue with maintaining system integrity is intrusion detection. If risk assessment tells you where you have unlocked windows, intrusion detection alerts you that someone has tried to open the window and crawl through.

Intrusion detection tools, such as Internet Security Systems Inc.'s Internet Security Scanner, Intrusion Detection Inc.'s Kane Security Ananlyst, and Axent's OmniGuard/ITA, provide realtime monitoring of attempts to penetrate security perimeters and circumvent security policies. These tools provide a broad spectrum of reactive techniques, ranging from sending simple notification and taking evasive maneuvers to actively trapping an intrusion and tracing it back to its point of origin.

From a technical standpoint, intrusion detection tools aren't hard to implement. The real challenge comes in determining the rules that constitute an unauthorized intrusion. A typical rule, for example, might be three strikes and you're out: three failed logon attempts within five minutes. While legitimate users will, indeed, screw up their logon periodically, do you want to allow three chances? Maybe it should be two. Maybe five. Somebody has to decide, based on who the users are and what is at risk. And once an intrusion has been detected, a rule tells the system what to do. Somebody has to make a management decision. Different systems, databases, and applications will require different rules. It isn't hard, but somebody still has to sit down and think through the issues and review the rules periodically to make sure they are still appropriate as things change.

The third issue with maintaining system integrity is the security of the systems management tools themselves. The danger here is that these tools carry full authority. A user can shut down systems, delete files, and stir up a wide range of trouble. Worse yet, these tools give a user intent on causing trouble the means to cover his or her tracks. Having entrusted these tools to a few reliable administrators, most managers don't give them a second thought. But these tools are as vulnerable as any other system.

For example, a former database administrator at a Wall Street firm became a trader and managed to embezzle millions of dollars by collecting commissions on phony trades. Auditors suspected the trader but couldn't catch him because the tools gave him the ability to cover up his trail by deleting transactions from the database after the commission had been recorded for payment but before the transaction executed. It was a very slick scheme. The DBA finally solved the mystery by stumbling accidentally upon the management system when it was being used illicitly by the trader.

Because we don't want to rely on accidents to safeguard our systems, how do we protect our organizations from the very tools we depend upon to ensure the reliability, performance, and integrity of our distributed systems? We have to apply risk assessment to the tools themselves to identify security holes, aim intrusion detection at those systems, close the holes we find, and then remain vigilant.

Tools to implement effective security for the distributed environment are here today -- and more are coming. Before you run out and start buying tools, however, map your own environment to the security areas and segments I've identified. Then start to make intelligent evaluations, addressing your most critical needs first. If you don't already have risk assessment and intrusion detection, they should be high on your list. And don't forget to apply them to your management tools.

Finally, pay attention to security administration, which includes the statement, implementation, maintenance, and monitoring of security policies across a distributed environment. Perform security administration across all 12 security segments identified earlier. Only then can you ensure, for example, that in accordance with policy, user JDoe can only log into the accounting systems between 8:00 a.m. and 6:00 p.m. and that this policy will be implemented and enforced by a combination of user/group administration, access control, auditing, and intrusion detection products. Similarly, if a security policy states that user JDoe should have only one password (rather than the four or so that is the current norm), this policy would need to be implemented using user/group administration, authentication, single sign-on, and encryption products.

Security is a complex issue for organizations to comprehend. Therefore, it is important to start with the fundamentals outlined in this column. But this is only the beginning. You will have to address all 12 of the segments of security I have mentioned. While it may seem overwhelming, it is imperative that you don't delay. Without sufficient attention to security, you will invariably put your organization at risk. The investment you make in a security policy and practice will protect your organization and your job.