Linux.com

The increased reliance on the Internet and other networked systems makes developing a real and workable preventive solution for computer security an economic necessity. A security process that can keep systems secure in spite of their vulnerabilities is becoming a necessity. The current vulnerability-driven security process is just not up to the challenge.

Human errors create security holes

It's a basic fact: Mistakes are inevitable. People make mistakes when they design, write, install, configure, and use software.

The engineers who design mechanical systems assume that defects will exist and design products accordingly. Software engineers, on the other hand, seem to assume that the software they produce will be 100 percent defect free, installed perfectly by customers, and used precisely according to the manual. In reality, software:

1. Contains design and implementation defects.
2. Is often installed incorrectly.
3. Is used in ways unexpected by the designers.
4. Is subject to malicious use.

The total number of defects in a given piece of software is unknown. Some of these defects lie dormant for the entire life of the application and never become security, reliability, or availability problems. Other defects are discovered and the security vulnerabilities they cause immediately become growing sources of risk. Each defect has the potential to become a problem, but only if the defect is actually encountered.

The recent vulnerabilities with OpenSSH software demonstrate that even intensive auditing cannot 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 cannot be relied upon to find all of the security vulnerabilities in any given system.

Making the situation worse, unforeseen software usage by legitimate users and malicious attackers can cause programs 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 usage of network software systems and the rapid time-to-market schedules demanded by businesses have caused a dramatic increase in the number of vulnerabilities discovered and security incidents that occur each year. In just the past two years, these numbers have doubled, according to CERT. Because it is highly unlikely that the trend toward inter-networked systems will halt or even slow, or that the market pressures on software manufacturers will subside, preventive security has become a must for those who need to reduce their security risk exposure.

Preventive security techniques

The preventive security techniques discussed in this paper 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 the administrator cannot prevent people from running malicious code or tampering with data, their systems will not be secure.

Preventive security techniques are subject to some a priori limitations and conditions. The methodologies for preventive security need to meet the following requirements:

1. Techniques must prevent attempted breaches from succeeding.
2. Techniques must be implementable.
3. Techniques must be manageable. <lii> Techniques should err on the side of caution.

Because 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 real time.

These breaches must be spotted whether they are a previously known breach, or a completely new type. Second, these attempts must be stopped before they succeed. Finally, the technologies must be accurate. False negatives (failing to spot an attack) and false positives (spotting an attack where there is none) must not occur or occur very rarely.

Stopping attacks before they are able to succeed requires machine-time response. It is not feasible to place a human in the response loop because 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 automated responses to ensure conformity with 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 capable of being implemented without affecting proper system and service usage.

Further, the protection must be easy to manage. IT departments need to be able to integrate preventive security management into the standard network and system administrative tasks. Currently, security administration is an irregular and unpredictable task relative to normal administration. This is one of the major reasons security is not kept up to date -- updates cannot be scheduled because outside entities dictate the schedule by finding vulnerabilities, attacking systems, and releasing patches.

Preventive security management must be just another routine administrative task similar to 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 holes. 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 having the ability to create tightly constrained temporary holes that close automatically. The continual goal should be to prevent attempted security breaches from succeeding.

Human and technological aspects

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 usage. 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 from the policy to its implementation, the lower the likelihood for implementation mistakes and the easier it will be to identify implementation mistakes. The final human component is the routine management of the technological components of preventive security.

There are three technological components to preventive security: authentication, behavioral control, and access control. Each of these components 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. Behavioral control constrains execution and system usage 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. Access control constrains the usage of data by the authenticated users of a system in accordance with the security policy.

By working together, the three technological aspects of preventive security are able to control and constrain the activity of the system. 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.

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.

Organized around four activities

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. It should also define the usage to which systems will be constrained.

Instead of sitting on a shelf being pleasantly ignored, the security policy should be actively enforced and updated as the authorized usage of the system changes.

Second, decisions must be made about allowing people and systems access to resources and which resources they will be allowed to access. These authorization decisions need to be revisited at predictable intervals such as when people are hired or fired, when their tasks change, when new outsourcing vendors are chosen, and when new internal or external services are rolled out.

Behavioral and access control constraints tend to need to be updated together at predictable intervals: when new applications or services are deployed, when new versions of applications are deployed, or when an application's legitimate usage changes. These events correspond with the events that require updating the detailed security policy. In fact, successful behavioral and access control techniques should be able to assist in the creation of a fine-grained security policy by auditing the accesses and behaviors needed in the course of authorized usage.

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 would be necessary for an organization that does not deploy new services and software as often. Contrast this with current approaches to security that are driven by the frequency of vulnerability discoveries, frequency and type of attacks, and the time lag for releasing 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 approach is that organizations are able to accurately predict what their security workload will be at any given time. Such predictability should make security work boring for security professionals: No tracking down attackers, studying packet dumps for attack analysis, or all-night software patch fests. Boring is good for CEOs and CFOs.

Conclusion

Preventive security presents a different security process. Instead of being driven by vulnerabilities, preventive security is driven by legitimate changes in system usage. Because of this, preventive security techniques can keep systems secure in spite of vulnerabilities. That 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, clients, customers, and partners grows, the need for a truly secure computing platform will only increase.

Scott Wimer is chief technology officer of Cylant, a division of Software Systems International The company is the developer of CylantSecure, a Linux host-based intrusion detection software product that takes a proactive, rather than reactive, approach to security. Through behavioral measurement, CylantSecure is able to detect malicious activity in real time and control the operation of the software to report and immediately stop any aberrant behavior.

"Commentary" articles are contributed by Linux.com and NewsForge.com readers. The opinions they contain are strictly those held by their authors, and may not be the same as those held by OSDN management. We welcome "Commentary" contributions from anyone who deals with Linux and Open Source at any level, whether as a corporate officer; as a programmer or sysadmin; or as a home/office desktop user. If you would like to write one, please email editors@newsforge.com with "Commentary" in the subject line.

Share    Print    Comments