Re: proposal: "security spectrum scale" (SSS)

Vlad Nuri writes:

> it seems to me what is lacking in all this is a *security spectrum*.
> unfortunately security experts sometimes have a tendency to equate
> *any* security weakness with a catastrophic one. while this is a good
> approach in general, i.e. to be as conservative as possible, in 
> practice there can be no doubt that some security weaknesses are far
> less severe than others.

Unfortunately, severity is a question of perspective.  In some
environments, an operating system crash could be considered catastrophic.
In others, it just means reboot and continue.  I'm not a policy wonk,
but security is relative to what you care about.

> to aid this serious problem, I propose the creation of a 
> UNIFIED SECURITY SPECTRUM RANKING.

There already was a USSR, but I think it ultimately failed :-}

For some starters, you should check out:

   A Taxonomy of Computer Program Security Flaws
   Landwehr, C.E., Bull, A.R., McDermott, J.P., and Choi, W.S.
   ACM Computing Surveys, Volume 26 Number 3, September 1994

Which organizes flaws according to how they enter a system, when
during the lifecycle they enter, and where in the system they
manifest themselves.  Some additional papers are available at the
NRL web site.

> this would be a list of all the different types of security weaknesses
> a system can have, and their LEVEL OF SEVERITY. it would attempt to 
> rank every type of security breach possible. then, when a new
> security weakness is discovered, it could be ranked A1 or B5 or C6
> or whatever. this would be a sort of technological "richter scale"
> that would allow the novice to immediately understand that a given
> bug that was recently discovered (say, the recent netscape bugs)
> was, say, not really as potentially severe as the Morris worm.

To whom?

The only way to unify security rankings is to constrain the problem by
assuming an environment and intended uses for the system.  It sounds
like you are assuming a low assurance workstation with an internet
connection which is used for non-critical home or business purposes.

Ironically, the digraphs you propose look sort of like Orange Book
ratings.  Evaluation results, however, tell you something (not everything
by a long shot) about how trustworthy a product is.  Your rating seems
to indicate the exact opposite.  How about a B2 product with a G3 flaw?

I believe that that flaw rating is *exactly* the same problem as product
security rating.  But that's a different discussion.

> however, if we do this, I hope that a good scale that is pretty general
> and doesn't need extensions can be done from the start, before its
widespread
> usage, so that later changes do not confuse users. there is already 
> confusion in the media about two slightly different richter scales, this
> is a pity.

Any flaw rating system needs to consider how it will deal with advancing
protection technology.  For example, susceptability to viruses is much less
critical than it would be if there were no anti-virus software available.
Similarly, having a microkernel operating system makes me less susceptable to
crashes.  Should a flaw rating decrease as technology adapts to deal with it?

Also, how do you rate situations where flaws are combined to mount an attack?
For example, I crack a weak password to get a guest account.  Then I snag an
unprotected password file and crack it to get root.  Then I leave an
undetected
trapdoor to get back in later.

--Jeff Williams  <mailto:williams@arca.com>

>> it seems to me what is lacking in all this is a *security spectrum*.
>> unfortunately security experts sometimes have a tendency to equate
>> *any* security weakness with a catastrophic one. while this is a good
>> approach in general, i.e. to be as conservative as possible, in 
>> practice there can be no doubt that some security weaknesses are far
>> less severe than others.
>
>Unfortunately, severity is a question of perspective.  In some
>environments, an operating system crash could be considered catastrophic.
>In others, it just means reboot and continue.  I'm not a policy wonk,
>but security is relative to what you care about.

I gave some examples in the initial message. the rating would not
be overly sophisticated, but would cover situations where it is 
pretty obvious which is more insecure than something else. for example
submitting arbitrary code is far worse than merely crashing a server.
or, messing up a client is generally less severe than
crashing a server (which potentially affects a lot more people).
being able to do something *undetected* is
much worse than being detected (during or after the fact). 
viruses are pretty much worse than stuff that can't repropagate
itself, etc.

an example of this is that one article compared netscape
buffer overflows to the Morris internet worm. this was pretty
obviously way out of line IMHO.

>The only way to unify security rankings is to constrain the problem by
>assuming an environment and intended uses for the system.  It sounds
>like you are assuming a low assurance workstation with an internet
>connection which is used for non-critical home or business purposes.

well, this would be a ranking for the general public to help them
understand security problems, so yes, I think it would generally
apply to commercial or internet type environments.

the orange book rating is a reasonable start as you mention. also,
thanks for the paper reference. actually what I am hoping is that
someone from, say, CERT picks up the idea and uses it in their
security bulletins. this would be a good place to bootstrap it
into security consciousness.

>Any flaw rating system needs to consider how it will deal with advancing
>protection technology.  For example, susceptability to viruses is much less
>critical than it would be if there were no anti-virus software available.

I disagree. this rating would apply to potential problems. a virus is
a very serious matter regardless of anti-virus protection software.
but you raise a good point in that the same bug could have different
seriousness in different environments (say one where the virus checking
is good). that's more complexity than the rating would try to address,
I would imagine.

>Similarly, having a microkernel operating system makes me less susceptable to
>crashes.  Should a flaw rating decrease as technology adapts to deal with it?

my example would be the recent netscape bug. an article might say
the bug was rated G2 on some systems, and say it could be potentially
as bad as A6 on some operating systems. "for comparison, the internet
worm was ranked A2".

>Also, how do you rate situations where flaws are combined to mount an attack?
>For example, I crack a weak password to get a guest account.  Then I snag an
>unprotected password file and crack it to get root.  Then I leave an
>undetected
>trapdoor to get back in later.

the rating would only apply to flaws. if you have more than one flaw,
a different rating would apply to each flaw. what you are showing is
that again, system configuration could make the same flaw much worse
on one system than another. I don't deny, this is a very tricky
rating scheme. it is only meant to be general however and give the
public an idea of how bad a weakness is. 

the security rating would not be particularly useful to security experts,
other than giving a rough idea of the potential severity of the problem.

again I still believe that
major security categories are being conflated to the point that it
might sound, to Joe Sixpack, that the latest netscape bug could bring
down the entire internet. this gross misperception is easily rectified.

I find this kind of alarmism very counterproductive to improving 
the internet. the internet will not gain widespread acceptance if
there is a *perception* that it is unsafe (regardless of how 
solid it really is). this rating would be an attempt to help the
public understand security issues beyond a very rocky level of
granularity. if something is not done to help convey accurate information,
a void occurs and potentially "urban myths" 
such as "the internet steals your credit cards" would tend to 
arise.