Tuesday, April 24, 2007

malware will thrive in vista and whatever comes after vista

... and whatever comes after that, and whatever comes after that, and whatever comes after that, etc., ad infinitum...

so some experts are saying vista will have malware problems and a bunch of people are talking about it...

can an expert possibly tell me why this is news?

follow me on this one: we know that all general purpose computers (note the alternative) that accept new software are able to support viruses (something that's been known for some 20 odd years now)... we know that self-replication (the ability to make possibly evolved copies of oneself - the defining characteristic of viral malware) is not magical or special in any way so it's reasonable to assume those same general purpose computers will support non-viral malware as well... further, we know that a computer with windows vista loaded on it (or really, any computer with a range of functionality sufficiently broad enough to warrant ANY operating system) qualifies as a general purpose computer...

so the fact that vista will have malware problems shouldn't be news, it should be a forgone conclusion... just as the fact that linux can (and to a certain extent does) have malware problems, and mac os x can (and to an increasing extent will) have malware problems, and smartphones can (and to an increasing extent will) have malware problems should be forgone conclusions...

why has the industry forgotten this? why does the IT industry seem to keep forgetting the past? if it's not viruses then it's DRM or the finer points of key management or shannon's maxim... it's frustrating to watch a collection of supposedly smart people be so dense...

10 comments:

Unknown said...

We can totally rest assured that there will always be malware with computers. I don't really care how stringent we get with security or even underlying architecture, we'll still have something unless our devices are so rigid and one-task-only that they're not computers anymore anyway, or not networked together. But those are part of a past reality.

Oh! And I hear you about the alien virus, but even then, it is dubious to think we'd be able to understand alien thinking and language enough to build a virus. I think we'd be lucky to get their system to say, "Hello world" on the screen. :)

kurt wismer said...

yeah, the one-task-only computers are the ones that don't meet the requirements of the general purpose computing platform, so the things we know for sure about general purpose computers are not guaranteed to apply there....

as for not being networked you'd also have to cut out sneakernet, which basically implies that people would be unable to share content, which in turn violates some of the fundamental principles of how we get work done... most work involves at least some collaboration or division of labour - there's very little that is done entirely by one person on one computer...

Anonymous said...

I have to disagree with you both. Our Trustifier technology protects systems and networks against virus, malicious code, spam, or any other nastie that you throw at it by a controlled gateway at the kernel level. We are protecting MS networks and have been for over 3 years, against malware and worm outbreaks.

This security sub-system is usable for standard Linux and windows systems, and does not create problems with rigidity or interoperability.

It controls data access on a user privilege basis though, and this is called multilevel security. Id does not restrict legitimate data flow. It sets boundaries for authorized use of sensitive data, which is really the goal of IT security isn't it?

kurt wismer said...

@rob lewis:
the goal of IT security is to minimize risk, not eliminate it completely (because risk cannot be completely eliminated)...

you may disagree with the inevitability of malware susceptibility in general purpose computers but as far as i'm concerned the principal stands until someone can debunk fred cohen's results with respect to viruses...

setting up privilege requirements and access controls can certainly minimize the chances of malware being able to operate, but they're only as good as the people who configure them and modern systems are sufficiently complex that no one can set up perfect restrictions...

Anonymous said...

Just as in risk management though Kurt, you don't necessarily have to set up perfect restrictions. You get as close as you can and then you use tamper proof audit trail and other tools to refine the data flow over time. Few can get the ball in the hole on the very first swing; you try and get closer with every shot.

This technology is user-centric at the data level, and uses a its own plain english syntax, reducing configuration errors. It makes data flow understandable and intuitive so that non-technical people can understand the rules. (John can access these files from this system at this time for this purpose-is an example).

Since Trustifier controls all executables and operates from a white list, it is not possible for malware to affect a Trustified system. They may get past AV defenses, but they can not execute.

If it worked the same way as everthing else, it would not be innovative, would it?

kurt wismer said...

@rob lewis:
"Just as in risk management though Kurt, you don't necessarily have to set up perfect restrictions."

you do if you want to address the issue of susceptibility to malware, which is what we're talking about here...

"Since Trustifier controls all executables"

this is the classic false assumption that is made by defenders of whitelist-type technologies (yes, i recall that trustifier is far more granular than what is conventionally thought of as whitelist technology)... trustifier aims to control all executables, but since determining what is or is not executable code is undecidable there will be areas where it fails to do so...

Anonymous said...

In a world of absolutes, even an EAL 7 system would still be crackable, eventually, but it would be expensive and time consuming to do so.

Trustifier converts a stock commercial system into a trusted environment. It may not be quite as secure as the built from the ground up TOS, but it can still make it difficult and expensive enough to attack that one would probably decide to focus on easier targets.

I feel that your views are based on pattern matching or signatures, which Trustifier does not use. The privilege list uses a 0 or 1 algorythm, and is user centric. If that malware is not on the white list or is is something not recognizable by Trustifier, it is simply denied.

As you know I am still learning as I go. Could you suggest a kind of virus or malware that might fool this kind of control system, so I can think about it?

kurt wismer said...

@rob lewis:
"In a world of absolutes, even an EAL 7 system would still be crackable,"..

all the more reason for people to have intuitively known that vista would have malware problems... so why do they need to be told?

"Trustifier converts a stock commercial system into a trusted environment. It may not be quite as secure as the built from the ground up TOS, but it can still make it difficult and expensive enough to attack that one would probably decide to focus on easier targets."

if trustifier had the market share that microsoft has, people would not choose easier targets because the real value would be tied up in trustifier protected systems... they'd focus on that, they'd find the weaknesses (there will be some, no protection is perfect) and they'd exploit them...

"I feel that your views are based on pattern matching or signatures, which Trustifier does not use."

when i say that determining what is or isn't executable code (the prerequisite for "controlling all executables") is undecidable it has nothing to do with signatures or pattern matching... i'll put it another way, it's reducible to the halting problem...

"As you know I am still learning as I go. Could you suggest a kind of virus or malware that might fool this kind of control system, so I can think about it?"

imagine a new scripting engine is created - because it's new trustifier won't recognize the scripts as programs, only the engine itself... the engine is allowed to run because it's being used for some sort of automation on some production system and part of that automation requires access to write into a certain folder... a script that copies itself into that folder will run because that behaviour has been authorized for the scripting engine, but such a script also technically qualifies as a virus because by copying itself into that folder it is self-replicating...

Anonymous said...

Kurt,

In a trusted environment, where services are compartmentalized or quarantined, where does a new scripting engine come from? Out of the blue?

Would it have to be created by a user?

For that to happen in a Trustified environment, it would have to be verified as allowable. It could not be just dropped in unnoticed.

Trustifier's tamper proof audit trail audits everything about all transactions. If a user tried to add something new that wrote to a secret directory, it would quickly be flagged by security officers. This is how a high security environment works.

By the way, just to clarify, we are not advocating that AV and so on is no longer needed. Trustifier just provides the missing essential core layer of security that has been missing until now.

kurt wismer said...

@rob lewis:
"For that to happen in a Trustified environment, it would have to be verified as allowable. It could not be just dropped in unnoticed."

and if you had read my comment you would have seen that i specified in the hypothetical situation it was not dropped in unnoticed but rather explicitly allowed because it was being used for some sort of automation in a production environment...