People make mistakes. Facing that one fact and its implication to computer security is absolutely critical. People make mistakes when they design, write, install, configure, and use software. Mechanical engineers assume that defects will exist and design systems accordingly. Software, on the other hand, seems to be produced based on the belief that not only is the design and implementation 100% defect-free, but that the final product will be used precisely according to the manual.
The reality is that software has defects. Some of these defects lie dormant for the entire life of the application, never encountered, not becoming security, reliability, or availability problems. Other defects are discovered and the security vulnerability they cause immediately becomes a growing source of risk. Each defect has the potential to become a problem, but only if the defect is actually encountered. The total number of defects in a given piece of software is unknown. The recent OpenSSH vulnerabilities demonstrate that even intensive auditing can not necessarily root out all the defects from software. As software systems become larger and more complex, intensive auditing becomes more expensive and more difficult. Software audits simply can not be relied upon to find all of the security vulnerabilities in any given system.
Making the situation worse, software is not solely used in the way the designers intended or anticipated. Legitimate users and malicious attackers use software in unforeseen and unintended ways. Some of these unforeseen uses can cause the program to execute through defects that had previously lain dormant. These unexpected execution paths are an inconvenience for the innocent user, but a gold mine for the vulnerability seeker.
The increased use of networked software systems and the rapid time-to-market schedules demanded by modern business have caused a dramatic growth in the number of vulnerabilities discovered each year. Not surprisingly, the number of security incidents per year has been growing at a similarly rapid rate. During the past 5 years, these numbers have gone up by an order of magnitude. In just the past two years, these numbers have doubled. It is highly unlikely that the trend toward inter-networked systems will halt or even slow, or that the market pressures on software manufactures will subside, making preventive security a must for those who need to reduce their security risk exposure.
We must start with a set of factual and real assumptions about computer systems if the techniques we derive are to have any hope of success. The assumptions below reflect an observation of the state of software today, and the probable state of software in the predictable future.
The preventive security techniques discussed in this article flow from the following axiom: If you can't or don't control a system, you cannot secure it. Put simply, security comes from control. Therefore, preventive security requires giving administrators real control over computer systems. If administrators cannot prevent people from running malicious code or tampering with data, their systems will not be secure.
The techniques of preventive security are subject to some a priori limitations and conditions. The methodologies for preventive security need to meet the following requirements:
Since the purpose of preventive security is to prevent breaches, that is naturally a mandatory requirement. This requirement brings with it certain challenges that have historically been hard to overcome. First, the technologies we use must be able to spot attempted breaches in realtime. They must be spotted whether they are previously known breaches or completely new types. Second, these attempts must be stopped before they succeed. Finally, the technologies must be accurate. False negatives (failing to spot an attack) must not occur and false positives must be very, very rare.
Stopping attacks before they are able to succeed requires machinetime response. This means that it is not feasible to place humans in the response loop; they simply cannot be relied upon to respond in less than a second to each and every attempt. Human involvement is for oversight and fine tuning of the responses that ensure conformance to the security policy.
Providing this level of protection must not have a substantive impact on the performance, reliability, and availability of the services being protected. The techniques chosen or developed must be implementable such that proper system and service usage is not affected.
Furthermore, the protection must be manageable -- not just manageable, but easy to manage. Preventive security management needs to be capable of being integrated into the standard network and system administration tasks. Currently, security administration is an out-of-band task relative to normal administration. This is one of the major reasons security is not kept up to date -- it is unscheduleable because outside entities dictate the schedule (by finding vulnerabilities, attacking systems, releasing patches, etc.). Preventive security management must be just another routine administrative task, like adding a new authorized user to the authentication system, installing new software, rolling out a new service, or updating a currently-installed software package to get the latest features.
Finally, the techniques used should err on the side of caution. Many security holes exist because people "temporarily" adopt insecure practices, and then forget to close the hole. Computers are very good at remembering to do things, and sealing up "temporary" holes is a good thing to remember to do. Even better would be the ability to create tightly-constrained temporary holes that close automatically. The goal is always to prevent attempted security breaches from succeeding.
Humans and computers are good at different things. Much of what one can do well, the other can do only poorly, if at all. Preventive security techniques rely on both human and technological components. The division of labor needs to reflect the strengths of each.
There are three principal human aspects of preventive security: authorization, policy creation, and management. Authorization determines who is allowed to use a given set of resources, as well as the nature of the allowed use. Creating a useful security policy is also a uniquely human task. The security policy must set forth what activity is allowed and what activity is not allowed. It should do this at a granularity level that makes the implementation of the policy as decision-free as possible. The more direct the mapping between the policy and its implementation, the lower the likelihood for implementation mistakes, and the the easier it will be to identify implementation mistakes. The final human component is the routine management of the technological components.
There are three technological components: authentication, behavioral control, and access control. Each implements a type of control over the behavior of the system. Control is the driving principle of preventive security. Authentication controls system access so that only those persons granted authorization are allowed in. Behavioral control governs what the authorized and authenticated users are allowed to do on a system once they are logged in. It constrains execution and system use behavior so that it stays within the approved behavior set defined by the security policy. Access control governs the visibility and mutability of data resources throughout the system and the network. It constrains the use of data by the authenticated users of a system in accordance with the security policy.
The three technological aspects of preventive security bolster and strengthen each other. For example, the resources (files) used in the authentication process must be protected. Access control provides this protection. The actual process of authentication itself is protected by behavioral control, making sure that the authentication processes execute properly. Authentication, in turn, controls who can update and change the access and behavioral control systems. By working together, these technological components are able to control and constrain the activity of the system.
The assignment of trust and authorization governs the control implemented by the technological aspects of preventive security. People define the security policy and decide who the authorized users of the system are. The technical components provide the mechanisms to enforce the policy and authorization decisions.
Preventive security work is boring. The absence of tracking down attackers, studying packet dumps for attack analysis, and all-night patch fests makes it much more boring for security professionals than the current approaches. Fortunately, CFOs and CEOs will be happy enough to make up for the collective boredom of the security staff. The implementation of preventive security breaks down into four iterative tasks.
First, the security policy must be established and kept up-to-date. In preventive security, the security policy is meant to be a meaningful document. It should set forth the precise levels of access and behavior required for authorized users to perform legitimate tasks; the security policy defines the use that systems will be constrained to. Instead of sitting on a shelf pleasantly ignored, the security policy should be actively enforced and updated as the authorized use of the system changes.
Second, the decisions regarding which people and systems will be allowed access and the resources that they will be allowed to access must be made. These authorization decisions need to be revisited at predictable intervals -- when people are hired or fired, when their tasks change, when new outsourcing vendors are chosen, when new services (internal or external) are rolled out, etc.
Behavioral and access control constraints tend to need to be updated together. They also need to be updated at predictable intervals -- when new applications or services are deployed, when new versions of applications are deployed, when an application's legitimate use changes, etc. These events correspond rather well with the events that require updating of the detailed security policy. In fact, successful behavioral and access control techniques should assist in the creation of the fine-grained security policy by auditing the accesses and behaviors needed in the course of authorized use.
The work aspects of preventive security are driven by the activities of the organization. Preventive security for an organization that is routinely deploying new software and rolling out new services will require more work than for an organization that does not deploy new services and software as often. Contrast this with the current approaches to security, which are driven by the frequency of vulnerability discoveries, frequency and type of attacks, and the time lag for vulnerability patches. One of the main goals of preventive security is making certain that the relevant events are under your control, rather than being controlled by external entities of dubious intent. One of the advantages of this is that organizations are able to accurately predict what their security workload will be at any given time.
Preventive security presents a different security process. Instead of being driven by vulnerabilities, the preventive security process is driven by legitimate changes in system usage. Because of this, preventive security techniques keep systems secure in spite of vulnerabilities. This is crucial, because as long as people produce software, they will continue to make mistakes in the process. As the level of interconnectivity between computers, businesses, and their clients, customers, and partners grows, the need for a truly secure computing platform will only increase. Over the course of the last decade, the current security process has demonstrated that it is not up to the challenge. Preventive security is.