Effective security requires a security policy, an implementation plan to control acquisition and the use of security technology. The acquisition and use of security technology must be controlled and coordinated. Every change should be policy-driven, deliberate, and justified by qualifiable improvement in the security posture. The alternative is ?fly by seat-of-pants? and hope that someone occasionally thinks about worst cases, costs, and the likelihood of a security ?issue?. Technology is precise; people are not.
Risk Management
Risk management is the core of any type of security program. If a company is not prepared to assess risks and base its actions on the results, then any kind of security program (other than seat of pants with worst-case checking) is probably not going to be rewarding.
Risk management is the way that a company gets information about priorities, values, costs, benefits ? all the things it needs to make informed choices about what security tools and techniques to use.
A different approach is to take a best-practices approach: buy and use (to some extent) the products and services that others do, and hope that your intuitive sense of priorities helped you spend the budget reasonably well. This is actually preferable to trying to run a real security program in a requirement vacuum, but less preferable than getting the requirement vacuum filled.
Security policy embodies both information about how costs and benefits should be considered, and information about how to enforce the priorities that result from cost/benefit analysis. A security policy states basic goals, and also elaborates them in the following three ways:
· Roles and responsibilities form management, IT, IT security, end users, etc.
· Issue-specific do/don?t on potentially dozens of issues
· Drive practices and procedures for operational staff with responsibility for IT and IT security
Security policy also maintains the value of the security program. A good policy is itself dynamic, with a well-defined and managed policy review process. The review process ensures that all bases are covered to some extent that was consciously chosen. In addition to policy reviews, compliance audits check that the required security measures are actually in place and are being used effectively.
All these aspects of security are required for the execution of a security program. Without any policy, a security program may or may not be accomplishing anything useful. It is the old GIGO rule ? you may have people responsible for security, but unless there are stated goals and well-defined processes to achieve them, it is Garbage In, Garbage Out. Or to be more precise, a company might be getting some value out of its security measures, but it would not have any way of knowing it.
Perimeter and Policy
Defining a network security perimeter is not always easy. Defining a policy is rarely easy. Implementing a policy is hard. If a policy is correctly implemented, then the only network communications that cross the perimeter are those communications that should be allowed. Then, something changes: new hosts are added, the network topology changes, new applications are installed ? each of which can effect the implementation of the policy, making the implementation incorrect. Then, of course, policies themselves also change.
If an organization is functioning well, then the implementation is audited for correctness, and rigorous change management is in place. Even then, there are security vulnerabilities, even if the policy is correctly implemented ? for example, a bug in the application software or a problem in the system administration ? that allow systems to be exploited.
To construct a policy, the assumption should be: anything that is not explicitly permitted must be denied. This is a simple concept. The default is to ?just say no.? Unfortunately, most systems (from network components to operating systems to the most recent applications) are not built that way. They are built to provide service, and this takes priority over the ability to constrain how service is provided.
Perhaps the simplest instance of this rule can be seen in packet filtering, an essentially simple operation. Each packet of data passing through a filter is examined as it comes in. Unless there is a rule that says it should be sent out, the packet is dropped. Yet even this simple function is governed by system configuration items that are subject to human error (and not infrequently alas) as the rules are updated to account for changes in the network environment.
In other words, security implementation is never easy. Lack of policy means that even when you think you have a correct implementation, you do not have a way of checking. It is the same as with any kind of engineering: if you do not have blueprints or requirements, you cannot know for sure when you are done. That is why, although defining policy can be real work, it is important work that must be done in order to ensure the value of using security measures.
Just as policy decisions are needed for network perimeter security, similar decisions are needed for extranets, Intranets, system security measures, communication security measures, and so on.
Tradeoffs
Implementing a security program involves making choices about using security measures. There are always tradeoffs, and it is possible to bite off more than you can chew. Any security measure is only as good as it is used properly. A good example is intrusion detection products that are deployed, but not used much in the sense that rarely does anyone examine logs to determine whether a serious incident may have occurred. Similarly, a firewall is worse than useless if improperly configured because of the false sense of security.
On the other hand, a properly used firewall is a good tradeoff. For example, most firewalls will block some kinds of remote login functions of operating systems (e.g. implementations of ?telnet?). They may or may not provide a more secure remote access mechanism, but they definitely block attempts from outside to telnet to inside computers. There may be hundreds of inside computers for which telnet would otherwise have to be disabled, and frequently audited. But with a simple firewall rule against telnet, it becomes much less critical to ensure that telnet is disabled everywhere.
The same is true of services like network file systems (NFS) that are useful within enterprises but much too dangerous (because of protocol-level vulnerabilities) to share with others over the Internet. By blocking NFS traffic from the Internet, internal systems are free to use NFS without having to ensure that every system tries to reject NFS communication from the outside.
But every measure, even these good tradeoffs where modest effort saves lots of effort that would otherwise be required, are part of complex systems where every change can have unexpected side effects. For example, if is easy to block NFS by blocking all Internet-based traffic using UDP (the transport protocol underlying NFS). This once was typical because of common security issues of all UDP-based protocols. However, some UDP-based protocols are permitted, especially ones with relatively well-defined (or tunable) port usage. Therefore, it may be acceptable to allow UDP packets, for example, on the port used by RealAudio.
But suppose that a system has the NFS service turned on with unusual port usage. If that port usage includes the ports typical to RealAudio, then NFS may accidentally be shared with the Internet and attackers might be able to attack all files that are shared over the corporate network. Sound farfetched? Well, recall buffer overflow attacks. RealAudio software was recently discovered to have a buffer overflow bug that was demonstrated (together with other common vulnerabilities) to allow attackers to gain control of the target system and turn and/or reconfigure network services. Among the network services is, of course, NFS.
This shows how a change to allow a new kind of application communication (RealAudio) also opened up a new vulnerability (buffer overflow) that allowed the new communication path to be exploited (NFS over the Internet).
Corporations must make tradeoffs between the usefulness and security of technologies. To do this, they must make judgements about what is the acceptable risk, and implement a default policy that denies everything, unless it is explicitly permitted. This is a simple and critical concept, but it is not always easy to implement.
Summary
It should be clear by now that a security program is the set of people and activities in which knowledge of both needs and solutions comes together. An organization can decide what to do, assess its value, and monitor to ensure that the expected value is delivered. The only question is whether people in the organization will make the commitment to positive change, and have the will to follow through.
Security issues include technical issues, business issues, cost/benefit issues and budget issues. Policy and process should stay on target and provide the ability to assess whether the expected value is delivered.
Companies can live without a security program, but at some point, concern over worst cases will dictate some kind of organized attention to security. In most organizations of size, the ?concern? part is well underway. The questions are about how to tackle the concerns constructively and when to start committing efforts within the organization.
?Never doubt that a small group of thoughtful, committed citizens can change the world. Indeed, it is the only thing that ever has.? –Margaret Mead
Bibliographic Citation
Building a Corporate Public Key Infrastructure. INFOSEC Engineering, 1999. *http://www.infoseceng.com/corppki.htm*.
Glossary. Baltimore Learning Center, 1999. *http://www.baltimore.com/library/mn_glossary.html*.
Green, Heather, and Mark France, and Marcia Stepanek, and Amy Borrus. ?Online Privacy: It?s Time for Rules in Wonderland.? Business Week 20 Mar. 2000:82-96.
Levitt, Jason, and Gregory Smith. ?Are You Vulnerable?? Information Week 21 Feb. 2000: 79-88.
Sebes, John E. Seminar. Understanding Computer and Network Security. Teracom Training Institute, 13 Apr. 2000.
Zuckerman, M.J. ?How the Government Failed to Stop the World?s Worst Internet Attack.? USA Today 9 Mar. 2000: 2A.