William Gunaratne's Blog : Security

TechEd Follow up, further reading on device security...

wigunara — Wed, 08 Nov 2006 20:20:00 GMT

Marcus Perryman's blog has a great article on Windows Mobile 5.0 Role security

http://blogs.msdn.com/marcpe/archive/2006/10/24/windows-mobile-5-0-role-security.aspx

Security for Windows Mobile devices

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce51conSecurityRoles.asp

and of course you can find my session on the postshow DVD.

Thanks

IT Security: It's not just about software!

wigunara — Fri, 04 Aug 2006 12:00:00 GMT

Security: Recent exploits hint at a shift in focus?

wigunara — Wed, 19 Jul 2006 00:05:00 GMT

Seems to me that the Malware community behaves like electricity - it will follow the path of least resistance.

With the huge drive around securing Windows and Internet Explorer delivering results, are virus writers simply going for lower hanging fruit? Applications were traditionally not as tempting a target as an operating system for several reasons, ubiquity and access to the system being the two main ones that I can see.

As we reduce the attack surface of software like Windows, SQL and Exchange we may be forcing the hand of the dark side of the force to find opportunity elsewhere.

With recent attacks focusing on members of the Office family (e.g. Excel) has the malware community shifted their focus higher up the software stack? Can we expect many more data-document delivered payloads?

Time will tell...

The Goal Keeper Approach to Security

wigunara — Mon, 10 Apr 2006 20:39:00 GMT

In my previous blog I made the case for a paradigm shift in the anti-virus industry. Today I found an interesting article that helps support my case. The article examines whether anti-virus engines (and their creators - the anti-virus vendors) are really doing anything useful, and do they really care?

http://www.emailbattles.com/archive/battles/virus_aadddbhadc_ia/

It seems that anti-virus engines and their parent companies are failing to protect us properly, so you are left with is a good old goal keeper approach to security on which anti-virus is based. It's a black-listing technology and black-listing is just not good enough when the stakes are so high

Does the Anti-virus industry have "The wrong end of the stick"?

wigunara — Mon, 06 Mar 2006 17:30:00 GMT

My previous blogs have brought up an interesting debate about white-listing vs. black-listing. To recap, white-listing is the process of explicitly listing what is good and assuming everything else is not. Black-listing is the process of explicitly listing what is bad, and assuming everything else is good.

The Group Policy article concludes that white-listing is the better approach in the case of Software Restriction Policies, and if you have developer background then the Least Privilege design principle also suggests white-listing is better.

The principle also applies "in the real world" where you require a passport before you can pass through airport security (although often countries also operate a black-list of passports they do not trust)

White-listing examples

· Passports/Driving License/ID Cards

· Security clearance for MOD/DOD

· Software restriction policies

· Credit

· Firewalls

· Operating System File Security

Black-listing examples

· Anti-virus

· Most Website filtering software

· Passports (again)

· Night-club/Bar security

· Police records

· Software restriction policies (again)

· Society in general (innocent until proven guilty)

· Countries

What I want to understand is, fundamentally, are there any criteria to consider before deciding on a white or black listing policy for any given need?

I think so, I think it comes down to

· Average trustworthiness

· Complexity to implement a black listing policy

· Complexity to implement a white listing policy

· Consequences of misplaced trust

Take driving licenses for example

· How much would you trust the average person with a automobile?

· How difficult would it be to implement a black-listing policy for drivers who cause accidents?

· How difficult would it be to implement a white-listing policy, which requires training and a test in order to obtain a license?

· What happens if we don't train and test people before letting them drive?

My answers would be,

· not very much

· very difficult

· even more difficult

· people may not be able to drive at all and may cause fatal accidents.

Given the first and last answers, driving licenses (a white-listing policy) makes sense and overcome the inherent difficulties of a white-listing policy.

Anti-virus and Website Filtering software work on the assumption its good unless the vendor has black-listed the site.

Spam filtering software is an interesting one, typically spam filtering has been a black-listing process, but as spam spiraled out of control there were a number of initiatives (some by Microsoft) to move to a white-listing system. Although ultimately the spam problem is about lack of accountability, and out of the scope of this article, most spam filtering is a mixture of black-listing and heuristics.

Perhaps there should be an anti-virus product for lockdown environments that works on a white-listing principle - for the uber security conscious.

Here is a call for comments- why don't Anti-Virus companies work in reverse and publish a list of known good software. I suggest that, by using the criteria above, there is a case for a white-listing anti-virus product -

1. Average trustworthiness of software is good

2. Difficulty to maintain a black-listing policy - black-listing is a reactive process for anti-virus. As viri come out, the anti-virus vendors must respond, they have no control over the process.

3. White-listing could be managed proactively, scheduled submission dates for testing. The AV vendors do not expose their customers to risk if they don't create a virus definition quickly enough.

4. The consequence of not catching a virus quickly enough, or failing to produce a virus definition update or the customer failing to download the update means the customer could be exposed to malicious code.

This makes a strong case for a white-listing solution, only point 1 defends the existing model.

In addition, consider the following -

· Bad guys don't want their software found. Good guys want everyone to get hold of their programs (usually for commercial reasons).

· IT administrators can simply integrate the list of known good software with their software restriction policy.

· It finally brings anti-virus in line with other white-listing IT security technologies, such as firewalls.

Anti-virus is potentially hit and miss, as there could be a delay between a virus being released into the wild and each anti-virus vendor publishing an update. This is akin to a goal-keeper in soccer (Football to us Brits), if your lucky the goal-keeper will stop the ball (virus), if not the other guys score.

I suggest the industry needs an all-encompassing solution that works using technologies from software restriction policy, anti-virus and Authenticode to provide a white-listing solution. As more and more businesses and governments run their processes on computers - the risk of malicious software running on some computer systems is just too high for a "goal-keeper" approach to defense.

Security and stability improvements unique to Windows Vista x64

wigunara — Thu, 16 Feb 2006 17:09:00 GMT

Windows Vista x64 will mandate all kernel modules are digitally signed by Microsoft. This is unique to the x64 (AMD64/Intel EM64T) build of the software, and does not apply to 32-bit (x86) builds or IA64 (Itanium) builds.

By doing this, vendors who write code that runs in kernel mode will need to get there code certified by Microsoft. In essence - if it's running in Kernel Mode - it's been checked by Microsoft. (UPDATE: Or the publisher has been issued with a Publisher Identity Certificate by Microsoft, which allows them to sign their own software)

Even users with administrator privileges cannot load unsigned kernel-mode code on x64-based systems. This applies for any software module that loads in kernel mode, including device drivers, filter drivers, and kernel services.

What this amounts to is both a security and stability enhancement because unsigned kernel modules will be blocked from loading (period).

Malware designed to use kernel modules and run in kernel mode will have a hard time in the x64 Vista timeframe.

This latest change, combined with enhancements that prevent kernel patching in x64 (since Windows Server 2003 SP1) will help reduce the attack surface for kernel mode malware in Windows Vista.

That's great news and another good reason to evaluate both x64 hardware and Windows Vista.

References:

Patching Policy for x64-Based Systems http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx

Digital Signatures for Kernel Modules on x64-based Systems Running Windows Vista
http://www.microsoft.com/whdc/system/platform/64bit/kmsigning.mspx