Articles / Preventive Security

Preventive Security

Each year, more money is spent on security, and each year, there are more incidents, more losses, and greater average losses. 2001 set records for security spending, security vulnerabilities, attacks, and security losses. 2002 is expected to be worse. It should be obvious that the security industry is missing something critical when it comes to reigning in the losses caused by security incidents. The potential for tens or hundreds of thousands of systems to be compromised literally overnight is a systemic failure that must be corrected. 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

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[1]. 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[2]. As software systems become larger and more complex, intensive auditing becomes more expensive and more difficult[3]. 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[4]. 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.

Preventive Security Techniques

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.

  1. Software contains design and implementation defects.
  2. Software is installed incorrectly.
  3. Software is used in ways unexpected by the designers.
  4. Software is subject to malicious use.

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:

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

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.

Preventive Security Has Human And Technological Aspects

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 Is Organized Around Four Activities

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.

Conclusion

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.

Footnotes

  1. "Closing the Window of Exposure", Bruce Schneier, Counterpane Internet Security, 2000: http://www.counterpane.com/window.html
  2. OpenSSH remote exploit vulnerability, 2001: http://online.securityfocus.com/advisories/3726
  3. "Put Your Bugs To Work", Stephen Shimeall & Timothy Shimeall, Software Developer Magazine, 1999: http://www.sdmagazine.com/documents/s=750/sdm9913j/9913j.htm
  4. "CERT/CC Statistics 1988-2001", CERT, 2002: http://www.cert.org/stats/cert_stats.html

Recent comments

08 May 2002 03:04 Avatar ph1sh

Re: Preventitive Security is nice..
couldn't agree more

09 Apr 2002 12:13 Avatar scottwimer

Re: Preventitive Security is nice..

>
> % If behavioral control were implemented
> on the Windows platform, then you
> could constrain the execution behavior
> of Outlook so that it wouldn't spew
> email out in response to opening an
> % attachement. These two actions
> % shouldn't be related.
> %
>
> But an email program should be
> expected to send and receive email,
> read attachments and access the users
> address-book. How would behavioral (
> and/or access) control help in this
> case?


Access control wouldn't be able to do much in response (since the accesses being made are entirely normal). Properly implemented behavioral control takes into account the temporal relationship of the various execution activities of the monitored program. In the Outlook example, a behavioral control system trained to recognize normal usage as "Okay", and abnormal usage as "Bad" would spot the difference in execution. Why, because while the user may quite often access the address-book, the code that deals with processing attachments does not tend to be used immediately prior to accessing the address book and sending email. More to the point, when the user does these tasks manually, Outlook will execute differently than when they are done automatically.

Regards,
scottwimer

09 Apr 2002 05:54 Avatar pythoneer

Re: Preventitive Security is nice..

> If
> behavioral control were implemented on
> the Windows platform, then you could
> constrain the execution behavior of
> Outlook so that it wouldn't spew email
> out in response to opening an
> attachement. These two actions
> shouldn't be related.
>


But an email program should be expected to send
and receive email, read attachments and access
the users address-book. How would behavioral (
and/or access) control help in this case?

08 Apr 2002 14:29 Avatar scottwimer

Concrete Methods for Preventative Security (under Unix).
What do I do to secure my systems?

Preventative security has three key areas:

1. Authentication
2. Access Control
3. Behavioral Control


1. Authentication

A variety of authentication techniques exist, ranging from
standard passwords to token cards to retina scans. The one
you choose will depend on the level of trust you need to have
that the person who logs onto your systems is the same person
you authorized to log on with the given identity. If you use
passwords, you need to require and enforce strong passwords.
A variety of tools exist to help you manage passwords.


2. Access Control

The discretionary access control provided by Unix is
insufficient. Too much vulnerable software runs as all
powerful root -- able to simply ignore the permissions on
files and directories. Mandatory access control is necessary,
especially for protecting the critical files on your system.
One set of critical files your ACL system will protect
is the password files, or the files used by the particular
authentication system you have chosen. The files used by your
behavioral control system also need to be protected by your
ACL system. The ACLs you use should be as tight as possible.
Ideally, they will be the derived from the actual accesses made
by the privileged processes on your system. Access control
should be done at the lowest level possible to make malicious
manipulation of the access control system more difficult.
Tools like grsecurity do this with kernel-level ACL enforcement.


3. Behavioral Control

The programs that you run must also have their execution
behavior confined, in addition to mandatory access control.
Behavioral control protects the processes that perform the
authentications. It also detects rogue programs trying to
get around the access control rules. Your behavioral control
system should at as a minimum detect and stop attempts to
change the execution behavior of any of the privilege programs
on your system. Like access control, behavioral control needs
to be done at the lowest level possible to prevent tampering.
CylantSecure does this with in-kernel behavioral monitoring.


These three techniques provide overlapping defense
against malicious system use. They prevent attackers from
capitalizing on the vulnerabilities in the software that
you run. Preventative security gets your organization out
the chase-the-vulnerability cycle.


Additionally, administrative activities need to be easy to
perform without opening the system to attack. If you have
to turn off the ACL and behavioral control systems to add
new software, you've introduced an undesirable window of
vulnerability. So, some way of allowing an administer to do
their job though a privileged shell needs to be introduced.
The administrator's actions under this shell would not be
restricted by the access control or behavioral control rules.
Access to the admin shell would in turn be governed by strong
authentication (the files and processes of which would be
protected by access and behavioral control).

scottwimer

08 Apr 2002 13:45 Avatar scottwimer

Re: And the solution is?

> 4. Software is subject to malicious use.
>
> ...
> If administrators cannot prevent
> people from
> running malicious code or tampering
> with data,
> their systems will not be secure.
>
> So only those people
> not running software on their networks
> will
> be able to prevent security
> breaches?
>
> Whilst the issues raised in this
> article are
> important to security, I don't see how
> they
> specifically address the problem of
> keeping a
> system secured without having to do a
> mad "rush
> to patch" with each new vulnerabilty
>
> announcement. Surely this is what
> people want to
> prevent, and what is suggests in the
> articles
> lead-in.
>
>
>
>


Keeping a system secure requires 3 things.
1. Authentication sufficient for your trust requirements.
2. Tight Mandatory Access Control on system files.
3. Execution behavior control of the running software.

The access control rules need to be tightly coupled (1-to-1) with the actual accesses that the system makes of critical files. The behavioral control rules also need to be as tightly coupled with the actual behavior of the software as possible -- especially for privledged applications.

The discretionary access control system provided by Un*x isn't enough. Tailing the log files looking for suspicous entries is a good thing, but is also insufficient. You need to do execution monitoring at the lowest level possible. This will let you catch the change in execution caused by vulnerability exploitation.

Regards,
scottwimer

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.