December 29, 2004

Securing Windows Server 2003

I am a big fan of OR&A books. If it has an animal on the cover and is from OR&A, chances are I have read it, or plan to.

Today I read a book review of "Securing Windows Server 2003" over at Smallbiztechnology.com. I never realized this book got published. I would have asked for it for XMas.

From the look of things, this sounds like a good book. Some of the topics covered include:

  • Understanding the capabilities of the Windows Server 2003 system
  • Learning the basics of security, from encryption to account password protection
  • Derailing low-tech intrusions by making systems physically secure and by using smart cards
  • Securing Active Directory and using Group Policy and Security Templates as security tools
  • Securing the core Windows Server 2003 networking services, including DNS,DHCP, IIS, IPSec, and remote access
  • Using Windows Server 2003 authentication and authorization protocols, including Kerberos, PKI-based cryptography, and certification-based cryptography
  • Solving the knotty problems of patch and update management, and implementing administrative security and auditing
  • Stopping bad programs from running on your server

Looks like I will have to give a call to my favorite local computer books store and see if they have it in. (Half price Computer books). Short of that... time for some one click on Amazon.

If you have read this book and have something to say about it, please feel free to comment, or write a review and trackback it here. Would love to hear what others thought of the book.

For the SBSers out there... remember the core of SBS2003 is Windows Server 2003. So this book is just as applicable to you. Something to consider as you think about security on your systems.

Posted by SilverStr at 10:45 AM | TrackBack

Hacking bluetooth

Just got a heads up from the guys over at F-Secure that the Trifinite group has today held an interesting presentation on Bluetooth hacking. This was in the 21st Chaos Communication Congress, which is currently underway in Berlin.

Their slidedeck in pdf format has some interesting tidbits on hacking bluetooth.

Enjoy.

Posted by SilverStr at 10:00 AM | TrackBack

Exploits on the Loose Against Unpatched Bugs in Windows

WindowsITPro reports that researchers have posted "proof of concept" code that can take advantage of vulnerabilities in Windows platforms. The concept code works against vulnerabilities in the Windows help subsystem and in code used to load desktop icons and the Windows help subsystem. Even systems with Windows XP with Service Pack 2 are affected as Internet Explorer can be used as a vector in exploits. Systems could become compromised without any user interaction if a user simply visits a malicious Web page.

At least one exploit has already been released into the wild of the Internet. No patches are available yet for these newly reported problems. WindowsITPro says that "Administrators can help protect their networks by ensuring that their intrusion prevention systems are update to date".

Ahh... music to my ears. Writers are starting to get it. IPS is a great asset in the digital defences, reducing the risks in the "Exposure Window" until patches and antivirus signatures can be deployed.

Posted by SilverStr at 07:57 AM | TrackBack

December 28, 2004

Secure programmer: Call components safely

David Wheeler has released a new article on how to call components safely. He posted this abstract on SCL this morning:

Application programs typically make calls to other components, such as the underlying operating system, database systems, reusable libraries, Internet services (like DNS), Web services, and so on. This article explains how to prevent attackers from exploiting those calls to other components by discussing the use of only secure components, passing only valid data, making sure the data will be correctly interpreted, checking return values and exceptions, and protecting data as it flows between applications and components.

It was a great article. Good insight. Happy reading.

Posted by SilverStr at 10:52 AM | TrackBack

December 26, 2004

SBS 2003 Revisited

OK, its been some time since my last update on my SBS deployment, and since I am at my wits end, Susan recommended I blog about what is going on so she can point people at the entry with some recommendations.

Although my blog is riddled with little pieces of what I have went through, I thought I would take this entry to start over. So without further adeu, here we go...

I have a need for a SBS 2003 machine that is hosting Outlook Web Access (OWA) and Outlook Mobile Access (OMA) for external parties, clients and virtual employees around the Net. The idea is that I can create a virtual office in our DMZ without having to expose critical business resources not needed by these users to the outside. SBS 2003 looks like a perfect solution for this.

To reduce the attack surface of the machine while ensuring strong audit trails, I require that ALL connections coming into these services (actually ALL services except incoming SMTP) be authenticated to Active Directory. My goal is to eliminate the potential compromise of unknown threats that may be exposed from vulnerable code or services that may exist along the code execution path between the OWA front end with IIS to the Exchange backend. It also reduces the risks of poorly configured or unknown services that may be running when they shouldn't be. Since the circle of trust for this group of users is quite small, I have a relative level of assurance that I can mitigate most risks by simply removing the ability to connect to the server anonymously and do bad things that they shouldn't. Be removing the ability for an adversary to even throw a connection request to the IIS box without authenticating, I get that assurance level.

I don't want to be forced to put a dedicated ISA box in front of this machine to accomplish this. SBS2003 has ISA2000 built in and I would like to take advantage of this. I have gotten ISA 2000 set up enough to accomplish the required authentication by setting the "Ask unauthenticated users for identification" in the Incoming Web Requests "Connection" section, and I can indeed verify that I am authenticating correctly to Active Directory.

So now that I am an authenticated user against Active Directory I get introduced to the OWA login screen. I don't mind typing in the credentials again here, and do so. (Although in the future it would be nice to have SSO between the FW and OWA)

So I log on, and it simply hangs at https://my.domain.com/exchweb/bin/auth/owaauth.dll with a blank page.

I then hit Refresh (F5) and repost in which the OWA interface loads up and all I see in my Inbox is "Loading..."

That is where I am currently stuck. I am not sure WHAT is going on at this point. To cut you off short from the obvious recommendations:

* The system has all patches and Service Packs as of Dec 26th, 2004. This was verified with thanks to Shavlik's great software.
* Yes, that includes the gzip patch
* Yes, if I turn off the Incoming Web Requests "authentication" checkbox it works. But the point is... I WANT IT ON.
* Yes, I have the Exchange SP installed.

Anyone have any ideas on what could be the problem? If you have SBS2003 hosting OWA just fine, try turning on the "Ask unauthenticated users for identification" in the Incoming Web Requests "Connection" section and see if you can repro this issue. (You can get there in the ISA Manager by right clicking on the server and selecting Properties)

Would love some help from the SBS MVPs out there. Your recommendations welcomed.

Posted by SilverStr at 03:57 PM | Comments (4) | TrackBack

December 25, 2004

Merry Christmas

Thank you for being a regular reader of my blog, providing great insight and comments on various security topics. Keep the emails coming, and don't forget to use the comments.

Have a Happy Holiday and prosporous New Year. May this entry find you and your family in good health, and great spirits for the season.

Sincerely,
Dana

Posted by SilverStr at 12:00 AM | Comments (3) | TrackBack

December 24, 2004

Open Source Security Testing Methodology Manual

Now this sounds interesting.

The Open Source Security Testing Methodology Manual (OSSTMM) is a peer-reviewed methodology for performing security tests and metrics. The OSSTMM test cases are divided into five channels (sections) which collectively test: information and data controls, personnel security awareness levels, fraud and social engineering control levels, computer and telecommunications networks, wireless devices, mobile devices, physical security access controls, security processes, and physical locations such as buildings, perimeters, and military bases.

The OSSTMM focuses on the technical details of exactly which items need to be tested, what to do before, during, and after a security test, and how to measure the results. New tests for international best practices, laws, regulations, and ethical concerns are regularly added and updated.

Happy reading.

Posted by SilverStr at 08:26 AM | TrackBack

December 22, 2004

When the winter cold takes a turn for the worse

Sorry for the lack of posts. This has been the first time in the last 6 days that I really had enough energy to get up and actually think about blogs.

Why?

Well, I was hit with the common XMas cold, which quickly turned into the worst bronchial infection that doctors have seen. Now fully filled with the heaviest antibiotics known to man (well, they sure seem that way.... they look like frigging horse pills) my body is starting to win back. I don't need to go into the details... you can get the picture in the fact I WASN'T at the computer. I only wish I could have SLEPT in the 6 days, rather than being crunched over coughing up the vileness that was in my airways.

Luckily I should be good to go for XMas. Good thing is I don't have an appetite for food, which should mean I won't 'indulge' to much during the holidays.... except for my mandarin oranges of course. Now that I am actually walking around I can actually go grab one!

Posted by SilverStr at 10:17 AM | Comments (1) | TrackBack

December 15, 2004

Designing for Failure

When designing secure systems, a critical component is understanding failure code paths. This is something woefully neglected in software systems of today, which is really to bad.

Today I read an interesting interview with Bruce Lindsay (an IBM fellow who is one of the guys behind the original RDBMS concept) about designing for failure. Although its riddled with thoughts on databases, the principles about designing for failure are just as applicable in secure systems.

Have a read. A very interesting article.

Posted by SilverStr at 02:43 PM | TrackBack

December 13, 2004

Quote of the Day: You deserve to be Hacked

"If you spend more on coffee than on IT security, then you will be hacked. What's more, you deserve to be hacked."

Richard Clarke
Former Special Advisor to the President on Cybersecurity

Posted by SilverStr at 08:06 AM | Comments (1) | TrackBack

How to handle and interpret BSODs on Windows

Today I read a post by Susan in which she makes some good recommendations on how to get a dump when a system crashes. I found a few of her points could be expanded upon and slightly modified, and started to comment on her blog. Then I realized it might be useful to others in the community, and decided to post it here.

There are a couple of things to consider when dealing with a kernel crash dump. You should read Susan's article first in order to understand her recommendations on setting up kernel dumps on Windows.

  1. Turn OFF the "Automatically restart" checkbox. When the system BSODs you will then be able to SEE the crashdump on screen. This is important as you can typically SEE the offending driver that is causing the fault. More importantly is that it allows you to see the TYPE of fault. If you don't do this, the system will automatically restart and you will miss this vital information. NOTE: If this is a headless server hosted somewhere, you may not wish to do this... your system will not reboot until told to.. which means it will hang forever.
  2. Turn OFF the "Overwrite an existing file" checkbox. Otherwise, if you have multiple faults you will never know about them since you would overwrite the previous crash dump. In some cases where "Paged Pool" is corrupted due to an offending driver, you may trigger a secondary fault that is harder to track down if you try to rectify it before it can be pushed to OCA. If you overwrite the file, you will be out of luck in comparing the dumps.
  3. In a pinch a minidump is fine. 9 times out of 10 having the complete dump of memory is useless unless the debug team require to debug virtual memory issues (like BAD_PAGED_POOL_HEADER faults). A little known fact is that the data Microsoft fires off to OCA is actually a bastardization of the minidump, which is then sent to code on the OCA server which goes through a filtering algorithm to determine the true cause of the failure, and is then placed into the buckets for each vendor. If they need more information (like the full dump) you get routed to a special web page, and are then asked to upload it.

If you want to get geeky and LOOK at the fault (in case you skipped point one and the system rebooted), it is possible. To do this you will need to download Microsoft's kernel debugger called WinDbg. Then take the following steps:

  1. Start WinDbg
  2. Create a directory in the root of C: and call it "symbols" (mkdir c:\symbols)
  3. Click on File, Symbol File Path. Here you will enter the symbols path, which is needed to effectively read debug information. Since Microsoft makes its public symbol server available to us, lets use it.

    The path will be: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols

  4. Once you apply the symbol path, select the "Reload" checkbox and then hit Ok.
  5. Now go File, Open Crash Dump and load the file you wish to view. The minidump will typically be located in %systemroot%\minidump (in my case C:\windows\minidump).
  6. When you hit Ok, the debugger will contact the symbol server, sync the data and load the debug screen with the data that it can read.
  7. Now at the cmd prompt type !analyze -v
You now have a full debug of what has faulted, with all the information you need. At this point you can check information on the stack, look at the last instructions before fault and do all the magic a kernel guy does. Chances are, most of the information will be foreign to you. Don't fret. That's what people like me are for. Just look for something that says:

Probably caused by : foodriver.sys  ( foodriver+4f20 )

Chances are, THAT is your offending driver (and the offset is the location, so if you let the vendor know they will know right down to the line number).

What do you do now? Well remove it. If the driver loads on demand, not a problem, you can simply remove the offending software. But what if the driver loads at boot time? You will never be able to do that, since the system will constantly crash on startup!

That is why the "Recovery Console" exists. Stick in your W2K3 or XP CD and boot from it. When asked, hit "R" for Recovery Console. When prompted type in your Adminstrator's password. Once logged into the console type net stop <drivername>. This will set the driver to NOT load on boot. You should then be able to boot up, and remove the offending driver.

Susan, tell your friend there is no need to reformat and reinstall. Just use the tools available to you to remove the offending driver!

Posted by SilverStr at 07:37 AM | Comments (5) | TrackBack

December 10, 2004

Book Review: The Art of The Start

While sitting on Scoble's "Red Couch" on Sunday I noticed an interesting book under his coffee table called "The Art of the Start: The Time-Tested, Battle-Hardened Guide For Anyone Starting Anything". It is written by Guy Kawasaki (from garage.com fame) and should be essential reading to any entrepreneur who is starting up a new company. Every night as I was winding down I took a couple hours to relax and read this book. It was such an easy read that I finished it last night.

Guy does a great job in not only talking about what you need to do, it also gives good examples of what NOT to do. Personally I enjoyed his chapter on the "Art of Bootstrapping" the most. Mostly because he debunks the myth that you HAVE to go raise money when building a company to succeed. I have been trying to explain to some in my circle of influence about WHY I bootstrapped my latest company, and why I declined investment from some parties early in its inception. The days of funding vapourware are gone, and if you want a decent valuation for your company if and when you DO look for money, you need to have a working product with sales and a good pipeline. It's the old addage that when the VC's want to fund you, you don't need the money. Makes good sense. And done right, you might not actually NEED that type of money.

There are some interesting tidbits all through the book. If you are a CEO of a startup company, or are considering being one, you should really check out the book.

Good read. Really enjoyed it. Thanks for lending me the book Robert.

Posted by SilverStr at 01:05 PM | TrackBack

PlugFest Day 5

Well, what a difference a day makes. Seems most people are flying out today and the lab is pretty empty. It's kind of nice actually as its now tolerable in the lab heat wise. All week its been EXTREMELY hot and stuffy with about 40 people running over 60 computers and about 20 laptops in this small room. The other test room that is doing interop isn't as full, and was much cooler. Coming early, I didn't realize it was going to be so full.

My tests are all done now, with the latest set running on W2K, WXP and W2K3 for over 20 hours without fault. Kinda funny watching the stuff get beaten on like that. And the interops went well. Didn't do as many as I would have liked, but thats ok. I will do that next time.

I think I am going to leave early and head home while there is still daylight. I wanna stick around for a debug training session that is about to begin, but otherwise have wrapped up this week. Its been great fun. There were a few people who apparently read my blog regularly here at the event, and I want to say hi before I leave. Can't remember who it was, but they introduced themselves over the week. (My apologies if I don't find you guys.)

Thanks for the invite Microsoft. It was a great experience.

Posted by SilverStr at 12:34 PM | TrackBack

December 09, 2004

Building Security In - Penetration Testing

The latest article in Gary McGraw's column in IEEE Security & Privacy magazine is on "Software Penetration Testing". It was co-authored by Brad Arkin and Scott Stender and goes into good detail on the benefits and drawbacks on using pentests as part of quality assurance tests for secure software engineering.

There was one part that really sums up the article.

However, itís unreasonable to verify that a negative doesnít exist by merely enumerating actions with the intention to produce a fault, reporting if and under which circumstances the fault occurs. If "negative" tests don't uncover any faults, we've only proven that no faults occur under particular test conditions; by no means have we proven that no faults exist. When applied to security testing, where the lack of a security vulnerability is the negative we're interested in, this means that passing a software penetration test provides very little assurance that an application is immune to attack. One of the main problems with today's most common approaches to penetration testing is misunderstanding this subtle point.

Amen. Well said.

Happy reading!

Posted by SilverStr at 11:30 PM | TrackBack

PlugFest 4

As the week starts to come to a close, I am sure happy I got this opportunity to work with Microsoft. When I left the lab this evening, my driver had been banged against the IO Stress tests for 4 hours without skipping a beat. Thats right, I fixed the deadlock issue that was causing issues on the multiproc boxes in the lab.

I really like the stress tests Microsoft wrote. They push the limits of the driver in a way to follow every code execution path that it can interrogate. Thats really kewl. Whats even cooler was that I talked to the guys at Microsoft, and they are going to let me take it back to my lab. 2.5 gigs of testing sweetness to add to our development process. I already figured out how to add it too. I will have nant check out and build the latest driver Friday nights, and then run IO Stress for 48 hours on the weekend, fully interrogating the most recent codebase, reporting back to the build system and finally push out the results to the developer rss feed.

Tomorrow is the last day. It will be sad to leave the lab and access to the Microsoft team and other companies that we are interoping with, but at the same time exciting to get home to family. As I look back I see that I significantly increased the quality of our driver, learned some new techniques for driver debugging (and how to use more in WinDbg) and gained access to better tests. Not bad for a week of work.

Posted by SilverStr at 10:45 PM | TrackBack

December 08, 2004

Plugfest Day 3

I'm not sure, but each day seems to be getting harder and harder. And much more interesting.

Got in today to test against my latest fix, which passed all the stress tests. I thought that was just great. Then I ran them on a multi processor system.... hmmmm... not so good. Not sure what the issue is, but I have scheduled some time tomorrow morning to figure it out. Since I don't HAVE any development resources using multi processors, I haven't had the opportunity to try this hardware configuration. That makes it a really interesting issue to debug. Should be a lot of fun!

Robert came by the test lab with the Channel 9 crew to do an interview with Neil Christiensen, the dev lead for the Filter Manager team. It will be interesting to see, as I got asked to sit in during the interview. Robert expects that the video will be up in a few weeks.

Had some good lectures on TxF support in the filter manager, and the new virtual memory management stuff in Longhorn. Some interesting performance advancements that Microsoft has added that should significantly increase performance. You know, like going from 64K writes on disk to having the ability to do writes at 4 GIGS at a time. Thats going to be interesting to see in a production environment.

Over all, its been a good day. Can't wait to see how much tougher the testing is going to get. Once I fix whatever this issue for multiproc is, I will have to start thinking about the tests against the 64bit systems in the lab. I think I might pass on that this time around.

But hey, who knows. I'm a sucker for punishment! :)

Posted by SilverStr at 09:43 PM | TrackBack

December 07, 2004

Plugfest Day 2

Oh what a day. The discussion on Transactional NTFS was awesome. Can't talk about it of course, but there is some kewl stuff coming down the pipe.

Found an interesting problem in my security driver today, exposed thanks to the IOStress test that Microsoft has as part of the tests of the Winqual group. IOStress beats the hell out of the driver with insane tests that purposely cause the driver to go through as many code execution paths that it can... stuff you don't normally see with every day use or even testing of the driver.

The result? A Programming 101 bug that I missed. ALWAYS ENSURE YOUR FAILURE CODE PATH FOR FAILED MEMORY ALLOCATIONS ACTUALLY RECOVER!

I'm screaming because I know better. Of course, this little issue now shows me about a couple of other concerns I have, and tonight I went through the debugger to ensure I have enough info for tomorrow to do more aggressive tests. I expected that ExAllocatePoolWithTagPriority ALWAYS allocated the memory as expected. Not always the case. Don't know if this would even be seen to fail in a real world environment, but no matter. It should be fixed.

God am I happy that I came down to Microsoft to run these tests. Finding these things help to increase the quality of the product, which helps everyone out. From my customers to Microsoft. Less crashes means less BSOD, and that even makes Microsoft look better. Here is an interesting stat to walk away with. Of all the BSODs in the world on more recent Windows operating systems, 82% of the crashes are caused by 3rd party kernelmode drivers, NOT Microsoft product.

Makes sense why Microsoft throws these PlugFest sessions. It helps everyone out. I know its helping me! I even was assigned an Online Crash Analysis (OCA) team member so I can directly communicate with Microsoft about crashes reported to Microsoft. Thats pretty kewl. I will be sending them my symbols so that if a customer ever crashes, Microsoft will be able to quickly diagnose the issue and get me a bucket of the crash. Of course, you as the customer would have to agree to send the crash dump; ALWAYS hit "Send" please. You help us increase the quality of our products. :)

Posted by SilverStr at 11:58 PM | Comments (1) | TrackBack

December 06, 2004

Plugfest Day 1

Well, the day is winding down a bit and I finally have time to open up Bloglines and catch up on my feeds.

The day was REALLY intense in the Microsoft lab. I fought with a major bug I have had in my Windows 2000 driver for months now. With Microsoft's latest security patched kernel release for W2K I can finally use the IoCreate*Hint stuff to normalize paths and ensure long file name conversions. After some tweaking and a change to how my logging code works, I now have it handling the heavy stress tests that the lab puts against the driver.

The interop testing is also going pretty good. Its neat watching all the AV companies eyeing each other up. Although we are all under heavy NDA to allow for sharing of information, its funny to watch all the companies be so guarded. Don't really blame them, just a funny observation.

Tomorrow we are going to learn about how the new Transactional NTFS in Longhorn may break our drivers. Should be interesting. Although thats a ways off, its good to know in advance.

Posted by SilverStr at 09:53 PM | TrackBack

December 05, 2004

The Red Couch Comeths

So I made it to Seattle. Had a small incident at the border. The US border guard thought coming down to Microsoft required some sort of paper work. As I had very little beside my schedule that Microsoft sent me, they thought they better do a thorough car inspection. After about 15 minutes they decided I wasn't a terrorist out to kill Bill, and they stamped my schedule and let me go on my way.

Arrived at Robert's house and enjoyed "The Red Couch". A nice leather couch while I got to try Halo2. OMG, what awesome graphics and story line. I could stay here for HOURS playing. Thankfully Robert and Maryam arrived back from Silly Valley and saved me from being sucked into the XBox vortex.

Moving on we went to wine and wireless. Nothing like enjoying some gwertztrameiner and apple smoked chedder cheese while surfing the Net and watching TV. Heck, Robert even has a neat Comcast PVR that seems to be TIVO on steroids. He even pulled up the Apprentice I missed this week and we checked that out while catching up on blogs.

I love coming to see Robert. Lively discussion has ensued about the power of podcasts, and blogging in a corporate environment. I explained how our company is integrating a heterogenous solution for corporate communications using blogging technology... from Press Releases and Event announcements in RSS to customer interviews with podcasts through enclosures. I think I am one of the few people that actually uses the terms blog and podcast in my business plan and DON'T actually sell "conversational software" itself. :) Ya, I AM in my own world.

To me blogging is simply a tool. I am tired of hearing most blogs be ABOUT blogs. No one just talks about what they know, and use the technology as a tool to allow them to communicate effectively. I hope to change that. I am betting my entire corporate communication strategy on it. We will see what happens.

Anyways, time to get something more to drink and head over to Robert's blog to see what the heck he is up to. He has been typing with such fury I am scared to see what the heck he is blogging about.

Posted by SilverStr at 11:37 PM | TrackBack

Scott Adam Rocks!

I'm sorry, but I just spewed coffee all over my keyboard. Has this ever happened to you???

Thank god I am not a BOFH anymore. This would have to be plastered on a cubical or something.

Posted by SilverStr at 09:57 AM | Comments (5) | TrackBack

December 04, 2004

Look out Microsoft. Here I come!

Well, I am just packing up and getting ready to head down to Redmond. Have been waiting a few months for this, but Microsoft has invited some kernelmode developers to the Microsoft campus to do interop testing against each others products. Nothing like spending an entire week looking in the kernel debugger (WinDbg) at registers and drawing truth tables to match against assembler instructions. I am not to worried about testing against Longhorn or 64bit processors, but do want to get some time deep in the Windows 2003 kernel with my IPS security driver and Symantec's Antivirus product. (Norton triggers a BSOD on NAV.exe at weird times on 2000, but never on 2003. I wanna know WHY.)

Ahhh, to be men at ring0; to watch a BSOD by simply flipping a register. Ain't it the life. *shudder*

Actually, it should be fun. I enjoy kernelmode development, and enjoy learning more from the kernel guys on Microsoft's campus. While most of you revel at sitting in .NET all day... something is satisfying when you work this close to the metal. Of course, if I had it my way no one would be allowed on the Internet unless they could telnet to port 25 to send a message. You know the days... when gopher was god and "mosaic" was a term used to describe tile in your bathroom!

Anyways, I have a couple of nights still open that are not set up with plans. Feel like hitting a Jazz club or two? Have an idea for something interesting to do in Seattle while I am down there next week? Drop me a line and let me know.

Robert has been kind enough to let me crash at his place again, so there will be wine and wireless for the picking. Actually Sunday I get to check out his tricked out XBox and play Halo2 before he gets back from Silly Valley (assuming of course I get to his place before he does). We will have to see if I got the Halo2 twitch out of me before he arrives. *lol*

Anyways, if you want to hook up let me know. I'll be on campus all week in Building 20.

P.S.

On an aside, I was listening to Adam's podcast today and heard about how Lee Wikins needs some help to get his dogs out of Delta Airlines kennels and sent back home to the UK. I threw a couple bucks to Lee for his Alfie and Benson Fund and suggest that if you have animals you care for and understand his predicament, do the same thing.

Posted by SilverStr at 12:12 AM | TrackBack

December 01, 2004

Mitigating the Exposure Window of Sasser with Host IPS

One of the things that drives me on a daily basis to build and refine our Host-based Intrusion Prevention System (IPS) for the Windows platform is that the Exposure Window of a vulnerability continues to grow. New unknown threats to critical business resources continue to expose businesses to larger risk across a greater timeline which is just unacceptable. Recently I had the pleasure of sitting down to dinner with Rob Clyde (CTO of Symantec) and listen to him talk about the fact that the time between a patch release and a new attack pattern utilizing the vulnerability is now 5.8 days from announcement. With most patch management release cycles for businesses EASILY 30 days or more (his stat, not mine), and antivirus signatures taking days after the attack is understood, antivirus and patch management alone is NOT an effective barrier to reduce the risk to acceptable levels for most businesses.

PC World published an article last month on the case of Sasser. (Found through F-Secure's blog). What I found interesting was the timeline they produced.

Here are some interesting stats:

  • In 2003/2004, it took Microsoft 188 days from the point the vulnerability was reported to the point a patch was rolled out.
  • It took 18 days from the point the patch came out that the first attack occured that the public knew about.
  • It took 6 days after the attack occured that someone rolled over on his buddy and the original author was arrested by German police.
  • There was a 206 day "Exposure Window" where critical business resources were exposed to a threat that their antivirus could not protect against, which some people in the industry knew about. EEye (the original analysts that found the vulnerability) had posted on their Upcoming Advisory site anonymous info about this critical bug (without releasing real details). Heck as of today EEye has other advisories like EEYEB-20040802-C which are over 120 days.
  • It took approximately 220 days from the finding of the vulnerability to having most systems patched against this threat vector.

And you wonder why I am working on Host IPS? Resiliency in systems needs to defend against the UNKNOWN, not just the known. We have to throw out traditional thinking about how we patch and pray while we are at risk. We have to have a higher level of thinking about infosec and mitigate the risks by understanding how our systems work and consider anything anomolous to be hostile until otherwise proven not to be... and ALWAYS block such behaviour... reducing the impact of threats in the Exposure Window. We need to apply least privilege containment to processes to limit the damage that can occur on a system, and ensure system and data integrity by protecting HOW the host acts.

The result? A safer computing environment for our critical business resources... the very Windows servers that run the IT infrastructure of our organizations. Host IPS gives administrators a chance against the Exposure Window to properly roll out their patches and get their antivirus signatures in place.

And thats a good thing. And that is what drives me each and every day.

Posted by SilverStr at 07:47 AM | Comments (6) | TrackBack