[soen321-f04] building secure software (formatted)[soen321-f04] building secure 
software (formatted)
David K. Probst PROBST at vax2.concordia.ca 
Wed Sep 8 19:09:58 EDT 2004 
  Previous message: [soen321-f04] building secure software 
  Next message: [soen321-f04] material for second lecture (Sep 13) 
  Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 



Building Secure Software
________________________

Network security, as it is commonly understood, is only forced on us by bad
software security.  We need an external security perimeter precisely because
the software inside the perimeter is vulnerable to such things as killer
packets, buffer overflows, and badly designed authentication systems.

Thus, "network security" focuses on such things as firewalls that block
particular types of packets or deny connections to untrusted hosts, and
intrusion-detection systems that generate an alarm when a software
vulnerabilty has been exploited.

But this form of security presupposes that you have a very accurate picture
of what your vulnerabilities are.  And that may be too much to ask.

There is a better alternative.  What if security was designed in correctly
from the beginning?  This is a matter both of code with a higher security
quality and of providing good security mechanisms inside the external security
perimeter.

Designing for security won't happen overnight.  Prerequisites include having
automated tools to do security analysis of code, understanding the principles
of secure (or trustworthy) systems, and developing the proper motivation.
Given the context in which commercial software is developed, the absence of
software liability is a big problem.

Since security should not be all or nothing, we need a risk-management
approach.  Think about deciding on what reasonable steps to take to protect
your home from burglars.  You would have to weigh several factors.

We introduced a small distinction without calling attention to it.  There is a
difference between prevention of attacks by good software, internal security
mechanisms, or an external security perimeter, and detection and response to
an attack in an intrusion-detection system.

As users of software, we should no longer accept the abysmally low security
quality of so much code.  As software developers, we should aim to write
"secure-enough" software.  Security is an arms race in the literal sense of
the phrase, so we should weigh how much money and effort will (or should) be
used to attack or defend.

The "network-security" approach to computer security has some major holes.
For example, suppose you have a superb firewall that only lets outsiders
access one application running on one host.  This seems pretty secure.
But what if the code in that application is remotely exploitable?

If your software misbehaves, you can have problems with reliability,
availability, safety, and security.  Security concerns those forms of
misbehavior that come about because a bad guy is actively trying to make
your software misbehave by exploiting certain software flaws.

This is an important point: attackers do not create security holes; they
merely exploit pre-existing security holes.  The security holes are
created by the software engineers who designed and implemented the system.

The situation is getting worse.  If you plot the number of security
vulnerabilities that are reported monthly against time, you get a curve
which grows without limit.  These vulnerabilities may have been found in
new code or in well-tested and widely used old code that was previously
thought to have been secure.

Another distinction is between remote attacks and local attacks, i.e., from
outside or inside the external security perimeter.  Much experience suggests
that local attacks have a very high probability of success.

What makes security harder?  There are three important factors.  1) Complex
code is hard to understand, analyze, and secure.  2) Extensible code gives
rise to unmanageable interactions between modules.  (Think browser plug-ins
but also dynamically linked libraries).  3) Connectivity makes security harder
for several reasons; one reason is that wide connectivity disrupts trust
relationships.  For example, there is very little in the Internet that should
be trusted.

Of course, there are more obvious reasons.  Being connected to the whole world
means that there are quite a few potential attackers.

Security is a behavioral property of a complete system in a particular
environment.  For example, a collection of security mechanisms designed to
work over a protected, proprietary network may fail utterly when the decision
is made to connect the system to the Internet.  The assumptions made about the
environment no longer hold true.

A quick and dirty definition of security is: enforcing a policy that describes
rules for accessing resources.  The simplest form is dealing with authorized
and unauthorized users.

Another approach that is dominant and unsatisfactory is the
"penetrate-and-patch" approach to computer security.  Here, we plot number of
intrusions against a timeline with some important milestones.  First, there is
the time the vulnerability is disclosed.  Intrusions rise slowly as a few
people learn how to exploit the vulnerability.  Second (we hope it is second!),
the software designers issue a patch for the vulnerability.  This doesn't
remove the vulnerability but, it is hoped, makes the vulnerability harder to
exploit and does not, it is hoped, introduce _new_ vulnerabilities.  Third,
automated attacks on the vulnerability become available on the web as scripts.
The number of intrusions rises markedly, reaches a maximum, and falls off but
never reaches zero.  Scripts make the curve rise and system administrators who
finally get around to applying the patch make the curve fall.

To repeat, patches often only fix the symptoms of a problem; they rarely lead
to the secure-enough code that should have been written in the first place.

What can go wrong with a computer system or network?  Here is a _partial_
answer.  1) It can become unavailable or very slow.  2) It can become
corrupted, so that it does the wrong thing or gives wrong answers.  Think of a
Trojan horse inside 'ls' or stored data that has become corrupted.  3) It can
become leaky in the sense that unauthorized people gain access to some or all
of the information stored in the system.

What can cause something to go wrong in a computer system or network?  Well,
either normal operation or a deliberate attack.  Here is an important
distinction.  A vulnerability may be rather obvious or deeply hidden; this is
a structural property of a complete system in a particular environment.  On
the other hand, a computer failure has a visibility that depends on whether it
was caused by a deliberate attack.  The reason is that an attacker may desire
to hide the fact that a system has been corrupted and may take active measures
to hide the evidence of his successful intrusion.

Visibility of vulnerabilities and visibility of intrusions are completely
orthogonal.




  Previous message: [soen321-f04] building secure software 
  Next message: [soen321-f04] material for second lecture (Sep 13) 
  Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 


More information about the soen321-f04 mailing list