[funsec] standards status in the industry - opinion?
nick at virus-l.demon.co.uk
Sun Jan 8 17:01:01 CST 2006
Barrie Dempster to Blue Boar:
> > Whitelisting would be a huge help.
> Yes it would and it's my preferred option. However, this technology
> already exists for the sysadmins in question, they have software
> restriction policies. ...
Nah -- SRP is very, very much a poor man's form of whitelisting. It
does not work properly and never did. I'm sure it was thrown together
over a sleepless weekend by two drunk lemurs who happened to wander
onto the MS campus with the objective of knocking out a Shakesparian
sonnet or two by engaging in their own form of "a million monkeys
It simply does not know (nor is designed to be extensible to allow it
to be taught) of all the kinds of files it must know about. It also
hooks into the OS in entirely the wrong place and does not load early
It's "Clayton's SRP" at best, and far from proper whitelisting.
> ... The trouble is they just don't take the time to
> create a set of policies and maintain them. Most sysadmins I've asked
> about this say something a long the lines of:
> "If MS provided us signatures of all of their software and produced
> updated signatures when a product was updated, we might try handling the
> 3rd party stuff."
In other words "Ohmigod -- you mean I have to _think_ to use this?
What kind of a piece of crap 'security' is this? Gimme something I
just install so I can turn my back on it and get on with BF II..."
Do these people still wear diapers?
> Which makes sense. So if MS or another vendor (AV vendors have the means
> to do this) produced software that provided the sysadmin with white
> lists and they also provided a signature DB of common software, they
> would aid the sysadmins immensely as it would be a case of just picking
> the signatures to install/enable in their policies. At this point rather
> than asking clients why they don't use this technology I'd change my
> approach and strongly recommend they, giving them the "your networks
> going to be owned" look when they give me excuses.
It is a fundamental tenet of security that I cannot define your
security policy. Neither MS nor the AV vendors nor even a really,
really smart guy like me can do that for you. If you (and I sdon't
mean Barrie, I mean the generic "the rest of you") cannot work out for
yourself what code should be running on your network, then I have an
answer you won't like -- you should be running _NONE_ (with the
exception that _if_ it is an entirely closed system you can do WTF you
like because it won't impact anyone else).
If you don't like that and won't do the work to sort out your own
network you _definitely_ should not be allowed to connet to the
Of course, when I said someone else cannot do your security policy for
you, I mean in the "out of the box" kind of way that Barrie says his
clients/informants expect. Well-informed and trained security
consultants should be able to do a good policy for others after
carefully examining their requirements, but a "one size fits
many/most/all" type approach is not suitable -- it reflects the
opposite of the "security is process" ideal that we espouse so often.
> This isn't a new idea, anyone with a security background (AV related or
> not) should have come up with this the first time they thought about the
> virus problem, because it mirrors other ACL solutions and is a very
> obvious replacement to the current idiocy that is the signature DB.
Well, Fred Cohen certainly came to that conclusion in his thesis where
the term "computer virus" was termed... 8-)
As discussed elsewhere in the thread though, it was somewhat
impractical _at the time_ on the predominant small computers (PCs,
Macs, etc) with their lack of memory protection and other resource
limitations and the larger systems didn't need something like this as
they were (mostly) competently run (and mostly not on or even near, the
More information about the funsec