Preventive Security
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.
- Software contains design and implementation defects.
- Software is installed incorrectly.
- Software is used in ways unexpected by the designers.
- 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:
- Techniques must prevent attempted breaches from succeeding.
- Techniques must be implementable.
- Techniques must be manageable.
- 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
- "Closing the Window of Exposure", Bruce Schneier, Counterpane Internet Security, 2000: http://www.counterpane.com/window.html
- OpenSSH remote exploit vulnerability, 2001: http://online.securityfocus.com/advisories/3726
- "Put Your Bugs To Work", Stephen Shimeall & Timothy Shimeall, Software Developer Magazine, 1999: http://www.sdmagazine.com/documents/s=750/sdm9913j/9913j.htm
- "CERT/CC Statistics 1988-2001", CERT, 2002: http://www.cert.org/stats/cert_stats.html
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.
good start
I like the start of the article, but the conclusions are incorrect. The article talks about the systemic flaws in how things have been designed, both network and software. This is due to the 'easiest way' of current software and network development. He contrasts this to formal (physical) engineering that allows for design flaws.
If you'll replace instances of 'software' with 'hammer' you'll see the complexity of doing what he's suggesting comes through -- redesigning every hammer to work everywhere all of the time (and have redundancy built in) is impractical. Our security people are currently attempting to do what he's suggesting; more due diligence. However, they're all burning out, as they can't keep up.
As an alternative, I propose a fundamental shift in security. The main problem in my mind is the ability to look at packets on a wire; e.g. unencrypted network and software files. Security must be treated as an onion; each deeper layer is more difficult to penetrate. To emulate this in network and software, encryption at each level in the onion must be done. This will trade the current 'see everything at the wire (or in the config file)' to 'see multiple levels of gobbly-gook at every level'. This is a major deterrent to anybody beyond a VERY serious persion (e.g. no more teenage script-kiddies).
Of course, the feds don't want anything to do with this, as it makes their jobs that much harder. However, I maintain that the feds deterrence of encryption has hurt us far more than they will ever admit.
Just my $.02.
Good old containment is the answer, but without user competence
The issues raised in this article are completely true, but the
security focus being on bugs and patches is just something of the last few years, and although the bugtraq list has done some great work on getting this part of security noticed, it has by
being so popular made many newcomers to the security field
beleive that this 'maintenance' part of security is the major
security concern.
Having said this, and looking at your article for solutions, there seem to be non there that would be able to do more than ad
to the security in a minor way.
The best way to think of security is in the old way of using containment measures, but combined with newer techniques
that pressent operating systems offer or should offer.
You must just try to accept the fact that if you are running a
service, than at some point in time people will be able to breach the security and gain access to the resources that the
software running the service has access to. Having said this,
it is clear to see that the best way to work with this is by
limmiting the resources the software has access to by using
old-fasion, and new containment and sandbox techniques
like chroot enviroments, running services as unpriviledged users, user based firewalling etc.
Now comes the main problem:
Setting up these containment meassures is hard for the averadge user, and many users will not do so, or fail to
fully do so. The only way to fix this problem is for the
instalation scrips of software that offers a service to set up
these containment meassures themselves, thus not having
any need for user competence.
If you further combine this with a pull-the plug intrusion detection system, that will try to monitor for atempted access to resources the software should not need, and that will
effectively pull the plug if such is detected, you will have 99%
of your security in place, and can move the bug driven
security back to the place where it belongs, the 'maintenance' phase, but now needing only a small part of the resources.
For more information you can look at this article, or look at my proof of concept implementation of such meassures in service providing software (for the Linux platform) that is part of the CDUCK project.
Preventitive Security is nice..
You didn't describe how to apply your 'Preventitive Security' techniques to real-world problems. For example, how would your techniques have solved the OpenSSH bug? People always propose "solutions" that don't fix the problem. You have to ask: "Will this solution prevent the problem from recurring?" Usually, the answer is "NO!"
Can we fix e-mail viruses by telling users "not to open attachments from strangers" and running anti-virus software? No. Neither solution addresses the problem, hence we have Melissa, ILOVEYOU, Nimda, etc. Just get rid of outlook.
Can we can stop code-red worms with more patch awareness? No. I still get code red scans after code red was in the news for weeks. Just get rid of IIS.
Can we fix the server by rebooting it? No. Computers are deterministic. The bug will triger again eventually. Just fix the damn bug.
Can we stop terrorists at the airport by taking away their plastic knives? No, that wouldn't have prevented the 9/11 attacks. Just secure the cabin doors.
Can we stop remote exploits with better authentication/authorization and well-written security policies? No, that wouldn't prevent a worm based on the OpenSSH exploit. Just run non-public services on non-standard ports. (A worm may still propogate, but it will be LOUD and SLOW.)
Re: good start
> Our security people are
> currently attempting to do what he's
> suggesting; more due diligence.
> However, they're all burning out, as
> they can't keep up.
Can't keep up? Maybe that's because more bad software keeps getting written. Anyone who has written software for a long enough period of time can attest to the fact that properly designing your app from day one to be fast, scalable, secure, etc. is much *much* less stressful than trying to fix design and security flaws in the field.
What the author was suggesting was that (for example) if a program needs to run on a port lower than 1024, since it must be owned by root, that the design plan should include provisions for changing the process ownership to a non-root user as soon as possible. In addition, if a network-aware program is being written, the feasability of setting up a chroot environment for that program should be looked at. If you reduce what your program can do to the minimum amount of what it needs to do, possible exploits are reduced before it hits the outside world.
It's the recognition that a speed reduction is less severe than a denial of service is less severe than a remote exploit is less severe than a remote root exploit and architecting (most appropriate word I think) your project so that risk is reduced even when confronted with a bug.
Re: And the solution is?
> So only those people
> not running software on their networks
> will
> be able to prevent security
> breaches?
It's the recognition that "security" is not a boolean value. No computer is absolutely secure except when unplugged and encased in concrete.
Security breaches are a fact. No puzzle devised by a human mind will avoid being solved by another human mind. No marginally useful firewall will be devised that is absolutely and forever impervious to attack. The article was describing vigilance and noting that vigilance begins with programs that not only have a minimum of bugs but that also expect to be compromised and look for ways to minimize damage.
Sometimes this can be as complex as a code/security audit or can be as simple as choice of language (not using C when doing string manipulation can be very effective when avoiding buffer overflows for example).
Preventive security is a long and tedious effort, but worth the time
The OpenSSH worm is a good example of how we could do
things differently. If security persons had mad sure
that the SSH server was only available to known trusted
parties, and those trusted parties had made sure that
they are just as secure as the systems they are logging
in to, then the OpenSSH worm wouldn't have had much
effect on commercial servers. As for the personal
users, they want flexibility. As such, there is little
chance that they are going to limit their SSH access to
a few source IP addresses. These are the users to be
concerned with. Here is an example:
John Doe, a programmer for Anonymous Software, works
from home a lot at night. John usually uses SSH to
connect to the office network. The office network has a
very restrictive firewall policy. John's home computer
is wide open (because he likes to be able to log in
wherever he goes). Now, John's computer gets
compromised, that computer is a trusted source for the
office network and the office network gets compromised.
This is a perfect example of the statement that you are
only secure as the least secure system connecting to
your network. Either the user's home system needs a
firewall configured just as tightly as the one in the
office, or the user's computer should not be trusted.
Re: Preventitive Security is nice..
> Can we stop remote exploits with
> better authentication/authorization and
> well-written security policies? No,
> that wouldn't prevent a worm based on
> the OpenSSH exploit. Just run non-public
> services on non-standard ports. (A worm
> may still propogate, but it will be LOUD
> and SLOW.)
>
It would apear to me that most worms around are loud and slow even without checking for non-standard ports, and this does not much to stop their spreading. It might be that the
non-loud/fast worms are just not geting noticed, but a well
designed worm that checks random ports could be either loud
OR slow, but will still propogate. But what is worse, by laying
down obstacles that would requira a worm to be loud, the
worms will eventualy become louder, and the resources drawn
from non vulnerable systems by the loudness of a large amounth of infected systems will be even bigger.
The main idea for effectively working with security should be that "If we can't stop something comming in we should limmit the resources available to what it is coming in to".
For worm propagation prevention this would mean that
if you will eventualy not be able to keep atackers out,
you should make sure they will after this not be able to get
out again. Next to this you should monitor for atempts made by the server software to act like a client, that would indicate that
the server is compromized and that should trigger some
automated 'pull the plug' action.
What would effectively be needed to do this in a waterproof way would be that that the server would before getting on with its business be able to tell the operating system: 'Expect me and my children to access this and that resources, and please kill me if I access anything else'
For most services you can get to the same result by using conventional containment and sandbox techniques, and
I would like to advocate that setting up these measures should be the job of the instalation softwar for the software providing the service, but for services like ssh, this would
probably require not yet existing containment and sandboxing techniques that should be offered by the operating system.
Re: Preventitive Security is nice..
> You didn't describe how to apply your
> 'Preventitive Security' techniques to
> real-world problems. For example, how
> would your techniques have solved the
> OpenSSH bug? People always propose
> "solutions" that don't fix the problem.
> You have to ask: "Will this solution
> prevent the problem from recurring?"
> Usually, the answer is "NO!"
I guess that my goal was to describe the conceptual aspects of preventative security and how they created a controlled environment for software to run in. The name of the software being controlled through preventative security is arbitrary. If you can control the execution behavior of a piece of software (ie, spot when it deviates from the norm, and then apply whatever corrective actions your policies define) and if you can control the resources that it is allowed to touch, the vulnerabilities in the software aren't really relevant to security anymore. The vulnerabilities are still likely to present a reliability problem (having a server segfault is probably not at the top of the "Things we want to happen" list), but the cost associated with the server crashing tends to be less than the cost of the server being replaced through execve(2) with something else running at the same privleges.
%
> Can we fix e-mail viruses by telling
> users "not to open attachments from
> strangers" and running anti-virus
> software? No. Neither solution
> addresses the problem, hence we have
> Melissa, ILOVEYOU, Nimda, etc. Just get
> rid of outlook.
We can't stop them by telling the users what to do, because they won't listen. The computer on the other hand, had better be under your control, or you have bigger problems, specifically, the problem set that exists today. 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.
> Can we can stop code-red worms with
> more patch awareness? No. I still get
> code red scans after code red was in the
> news for weeks. Just get rid of IIS.
The alternative, is to use behavioral control and access control to constrain what IIS is allowed to do. That's really all you need. Switching web service platforms can be very difficult for organizations that integrate tightly with the features the platform provides. The point of preventative security is that since developing feature-rich vulnerabilty-free software is probably impossible, find a way to secure the vulnerability laden sofware that people use.
> Can we fix the server by rebooting it?
> No. Computers are deterministic. The bug
> will triger again eventually. Just fix
> the damn bug.
> Can we stop terrorists at the airport
> by taking away their plastic knives? No,
> that wouldn't have prevented the 9/11
> attacks. Just secure the cabin doors.
> Can we stop remote exploits with
> better authentication/authorization and
> well-written security policies? No,
> that wouldn't prevent a worm based on
> the OpenSSH exploit. Just run non-public
> services on non-standard ports. (A worm
> may still propogate, but it will be LOUD
> and SLOW.)
>
If you control the behavior of a program, and its behavior under exploitation is not part of the set of allowed behavior, well... Then the exploitation sets off red flags, and depending on your policy, stops the program. The sshd worm won't travel very far or fast if the sshd process is killed and restarted when somebody tries to exploit it. It is the area of response mechanisms that I think is going to be the most interesting as people develop rigorous techniques for behavioral control and access control. Modern response mechanisms are very draconian (send TCP Fins, kill the process, shun the IP at the firewall). In the future, I think we will see much more fine grained attack responses (close the file descriptor, route the traffic to a honeynet, slow the process way down, strace the process, inject noise into the IP session.... who knows).
Regards,
scottwimer
Preventative Security Example: snmpd vulnerabilities
An snmpd exploit through the eyes of preventative security.
Lately, we've seen that most snmpd implementations have a host
of security vulnerabilities. These generally fall into the
category of buffer overflows, but that isn't really relevant.
(This is a major challenge of preventative security --
the realization that the nature of the vulnerability does
not matter).
By manipulating the vulnerability, the attacker is able to
run their own code in the snmpd process space. The code
they run is going to change the execution behavior of snmpd.
Depending on how close you are monitoring its (snmpd's)
execution behavior, you will be able to spot this change.
This is the role execution behavioral control plays in the
preventative security process. However, execution behavioral
observation can only really happen after the fact though, so
we need a way to protect the resources of the system during
those critical milliseconds after snmpd's execution changes
and before the change is observed.
Enter access control. Properly configured access control
rules will not allow the snmpd process (which now happens to be
running somebody else's code) to touch system resources that
it does not normally access. Access control also comes in
handy when we realize that a program's behavior isn't likely
to change due to the files it opens and reads; we need to use
access control to protect these resources.
Throughout the attack on snmpd, the vulnerability was exploited,
but the attacker is unable to obtain any benefit from doing so.
The risk of a simple example such as the above is that it
demonstrates such a small portion of preventative security.
Firewalls implement access control. So do encryption techniques
(they control the visibility and the silent mutability of data).
Network scanners can do behavioral control of the traffic
on the network. There are a whole host of techniques for
authentication, from the basic passwords to key cards to
fingerprints and retina scans.
I'd be happy to describe as many other examples as people are
interested in -- just ask.
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
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
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?
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
Re: Preventitive Security is nice..
couldn't agree more