The Human Side of Security

Mi2g's response to the SANS Top 20 list generated an entertaining discussion on the Dshield mailing list (http://www.dshield.org/mailman/listinfo/list). The discussion was winding down when a post by David Rice suggested an appendix be added to the Top 20 list to address Mi2g's concerns. For those of you unfamiliar with the Top 20 list, it is formatted like a Top 20 item.

Quoted in it's entirety (with Davids' permission)...

"I would recommend ammending the SANS Top 20 to include the following:

H1. Humans

H1.1 Description:
The species Homo sapiens supports a wide range of intellectual capabilities such as speech, emotion, rational thinking etc. Many of these components are enabled by default - though to differing degrees of success. These components are implemented by the cerebral cortex, and are under the control of the identity engine which runs as me.exe. Vulnerabilities in these
components are the most common avenues for exploitation.

The human brain is both locally and remotely exploitable through techniques such as unhealthy self-talk, low self-esteem, government propaganda, commercial marketing, sales representatives, phishing, social engineering, and magic tricks. For most of these vulnerabilities, exploit code is publicly available. Attacks exploiting these vulnerabilities have been seen
in the wild. An example of a large-scale attack involved exploiting a flaw in the brain's music handling routine where thousands of people purchased David Hasselhof's album "Looking for the Best."

Earlier versions especially Neanderthal and Homo Erectus do not enable rationality and intellect by default and are therefore considered "secure by default" (of course, extinction dramatically reduces a species' attackable surface area). Due to environmentally-derived improvements, Homo sapiens have a much broader mental capacity which increases the exploitable surface
area significantly.

H1.2 Systems Affected
All versions after Homo sapiens 1.3.27.5234a

H1.3 How to determine if you are at risk
- Ask yourself the question, "Who am I?" If answered, the system is at risk.

H1.4 How to Protect Against Vulnerabilities
- Unfortunately, patches to Homo sapiens have resulted in significant and harmful sequela such as holy wars, cola wars, communism, reality TV, and global warming; therefore, the current version of Homo sapiens is considered unstable and non-patchable. An upgrade/replacement from the open-source genomics community is eagerly awaited. In the mean time, consider the
following:
- Deny yourself admin rights.
- Determine if the vulnerability exists in a non-essential component that can be removed. Please take caution when determining this as it could break functionality if there are other services that depend on the component in question. If necessary, consult a physician.
- In some cases, exposure to the vulnerability could be removed by disabling the corresponding service. Please note: disabling me.exe will make the system unrecoverable. Make sure a backup disk is available. "

Thanks David for a great laugh!

Rick

Mi2g and the SANS Top 20

First we have to get this out of the way...I have been a contributor to the SANS Top 20 for the last 4 years. I think it is a great piece of work, with a very specific focus...to help system administrators focus their efforts.

Which brings us to Mi2g...http://www.mi2g.com/cgi/mi2g/press/221105.php

This has been headlined in at least one place as "Mi2g disputes SANS Top 20". I don't see it that way at all. I will not get into what reasons Mi2g has to release this article. I am sure they did it for purely altuistic reasons. Once you filter out the sensationalism and obvious self-promotion, the article is bang on. Security is not a technical problem, it is a system that starts with people, policy and processes. Technology is merely the means to support the 3Ps.

The interesting thing is that during the deliberations for this years Top 20 list, we talked about all of the human side of the security equation, and whether or not to include it in the list. But in the end we decided that that wasn't the point of the project.

It is my fervent hope that small companies and novice admins will address the human side of the equation, but if they don't, the Top 20 is a great start.

Rick

SANS Top 20

The SANS Top 20, 2005 edition has been released. It is available at:

http://www.sans.org/top20/

For those of you who are security neophytes, or those of you who have just been hiding under a rock, The SANS Top 20 list is a collection of vulnerabilities that have been released in the last year which you should have already remediated. If you haven't remediated them by now, you are probably dealing with the aftermath. (-8

Even so, it is excellent reading. Of course I am biased. (-8

Rick

SPAM, SPIM even SPLOG, but what do you call SPAM messages in blog comments?

As a security professional I have heard of SPAM, SPIM, even SPLOG, and Phishing and Pharming, and lots of other seemingly nonsense names, but today I may have found a new one.

Since posting my previous blog about DRM and rootkits, I have received two SPAM messages via anonymous comments to that blog post. I have since deleted them. Is there a name for that type of SPAM or do we need a new name? Perhaps BLAM? (-8

Rick

Digital Rights Management as a RootKit?

I was reading Mark Russinovich's column on the SysInternals blog at http://www.sysinternals.com/blog/2005/10/sony-rootkits-and-digital-rights.html

Let me start by saying that in this case Sony's DRM definitely crossed the line, by modifying the system to hide itself from the users. They need to be stomped upon. End of story.

But it got me to thinking about a basic premise of Rootkits, or more precisely about the premise of detecting Rootkits.

First a little background. For those or you who are security neophytes a Rootkit is (To use Mark's own words)"

"Rootkits are cloaking technologies that hide files, Registry keys, and other system objects from diagnostic and security software, and they are usually employed by malware attempting to keep their implementation hidden."

So what this basically (or maybe not so basic) means is that Rootkits utilize capabilities which exist on a system to modify the system to subvert the normal capabilities of the system in order to hide stuff (files, executables, back doors, etc) that the installer of the RootKit doesn't want people to find and/or remove.

The assumption behind RootKit detection software such as chkrootkit, or RootKitRevealer is that even though the capabilities utilized by the RootKit could be utilized by legitimate applications, that there is no legitimate reason why legitimate applications would want to or need to utilize these capabilities.

Forgetting about the ethics of DRM utilizing these capabilities, it does shake this premise. DRM is a legitimate application, and it is utilizing capabilities that were considered to have no legitimate use. Does this mean that applications should avoid utilizing these capabilities, or does the security world have to reconsider whether those capabilities have a legitimate use?

For reference, F-Secure has waded into this debate and decided that Sony's DRM stuff this is malware.
http://www.f-secure.com/v-descs/xcp_drm.shtml

Myself, I have to agree!

Rick