Day 12: ITSM Vulnerability Assessment techniques
Lesson 12: Yesterday, I shamelessly recommended to ditch all commercial networking gear. In the same breath, I also made several Cisco configuration recommendations. This is just the way that I work. The idea is that network appliances increase risk, but at the same time -- they also allow you to connect to other networks.
Today we're going to examine the same issues at the host, or system (or OS) level.
Before we do that, I wanted to add a few notes to Day 11. First of all, it's not all about Cisco IOS. Juniper Networks has recently begun to shift features from ScreenOS into JunOS. Certainly other vendors are going to innovate, but be careful to assess each platform as new features are added.
There has been some beat on the blogs lately about BGP, which is very good for business. Most IT/Operations people don't understand how the Internet works, which is a crying shame. While some security professionals tend to read blogs such as Arbor Networks and The Hoff, it takes a few comments from Richard (and hopefully myself) to point you towards Renesys. The commentary from the YouTube-Pakistan incident has spurred lots of other interesting conversation.
My take on the YouTube-Pakistan incident follows. I woke up on Saturday and saw some people talking on the NANOG mailing-list about YouTube. I messaged my friends who are network engineers at YouTube. They were already aware of the problem and were attempting to create their own MSR's (my abbreviation for "more-specific routes") to overwrite the ones from Pakistan Telecom. However, their providers were filtering these MSR's because they were less than /24's. Some NSP's filter routes depending on which classful routing system they fit into, but that's a separate argument.
There are many things you can do to prevent this sort of issue from happening to you. The first step is to make sure that you've hired BGP expertise in-house, and the second step is to listen to them. Finally, some sort of assurance is in order, so try to find an assessor who is qualified to check BGP configurations.
Part I: Information assurance vulnerability assessment — Protecting the systems
ZOMG! Someone could subvert your firewall and network-based IPS! What do you do?
Don't panic. Everything is going to be ok. That is, unless you're running anti-virus software on your clients. Do your clients use a web browser to connect to the Internet? Do your users open PDF's, DOC's, XLS files, and PPT's? You don't let them install IM clients, do you?
Ok, so that's nearly everybody in the corporate world. Client-side exploits are much more real now than they ever were before. Sure, viruses/worms can spread from file shares. Sure, you can read an email and get owned. However, the most dangerous software is your client-side applications and the worst part of it comes from how your users use them on a daily basis.
Not only that, but you have twenty-thousand hosts, half of which were patched last July -- and most of the other half which was patched only because you purchased them new at the end of the September. Certainly some hosts are fully patched to date, but only the people who really are "in-the-know" which turns out to be less than 1%.
At first, I would say: BigFix, Lumension Security, or ConfigureSoft to the rescue, right? Maybe Skybox or RedSeal could help? Maybe you can scan and patch using MBSA and Microsoft SUS? Sure -- all of these are going to go a long way to solving the problem you're in. However, there has got to be an easier way. There has to be something everyone can do to keep and stay out of this mess in the first place.
Recommendation: Using psexec with MBSA/SUS and/or BigFix -- you can get everything patched (except possibly Novell systems and some laptops) and verified within 30 days if you have a commitment from IT and a good change control process.
Once you're patched, then you need to measure your rate of patching. Can you setup Windows automatic updates to install on some critical machines between 2 and 3PM PST on every Tuesday? Yes, you probably can in most cases. Microsoft does test patches before they release them live to the world on Patch Tuesdays.
Maybe if you removed all of the extra crap on your Windows installs, then users and system administrators wouldn't have problems installing the base Microsoft patches. Minimize the applications that your organization is required to run.
Once you have a "patch strategy" and "patch metrics", it's then fine time to remove your runtime anti-virus solutions. Yes, I said it. Remove them. You can always setup automated network-based, or USB-based virus scans when IT encounters one-off problems. Your AV hurts you more than it helps you at this point. Runtime AV is not a good blanket control -- it's a compensating control for "lack of near-perfect, high-quality patch management".
However, there are things you can do to increase the security of your systems even more. Besides "Install Vista" or "Install the latest SuSE/Ubuntu/CentOS with AppArmor, GRSecurity, or SELinux", I can provide some additional suggestions for those of you stuck where I figure most organizations are: in XPSP2-land.
In XPSP2-land, you can turn DEP/NoExecute to AlwaysOn. This means that the Data Execution Protection will always be on. It could break things, but it probably won't. You could always be evil and only enable it across all systems right before the third-party pen-testing team comes in to verify you for that PCI-DSS, S-OX, HIPAA, or BITS Shared Assessments audit (and then turn it off when they leave).
Another benefit to running Firefox in XPSP2 over IE7 is that DieHard-Software.org can be used if the processor supports NO_EXEC_STACK (e.g. AMD NX-bit or Intel XD-bit). DieHard-Software.org appears to userland hook in the same way that most host-based IPS works (which means that it isn't very good), but it's free and better than nothing. DieHard-Software adds another layer of DEP/ASLR protection to the browser, which is the application which usually needs it most. If you can use Hardware DEP, then you can also use DieHard-Software.
Sure, if the processors don't support an XD-bit or NX-bit, you're stuck with Software DEP and no ability to run DieHard-Software. However, very few organizations are going to upgrade all of their laptops just to run a feature that nobody has ever heard of. Don't take this as an excuse not to set /NoExecute=AlwaysOn, because Software DEP is better than no DEP at all.
This brings me to another interesting point: don't buy laptops or desktops. If your organization doesn't have any laptops or desktops, then these machines cannot get owned. Consider purchasing thin clients to replace desktops or SafeBook.Net to replace normal laptops. Users can instead use Windows Server 2003 (64-bit is preferred because it has additional security protections and must run on an NX or XD enabled chip) or the new Windows Server 2008 -- but as a terminal services user. A boot server is required, and this could be 2X, NoMachine, or even the free LTSP on an Ubuntu server.
For more information, be sure to read Linux Thin Client Networks Design and Deployment, and for details on Data Execution Protection -- check out the chapters on Memory Management and the Boot Process from Microsoft Windows Internals, Fourth Edition.
Part 2: Software assurance vulnerability assessment — Web Services
Best Web Services attack tools
SOAPbox, OWASP Interceptor, WSBang, wsScanner, WSFuzzer, SIFT, Wfuzz, OWASP WebScarab, wsKnight, fuzz_wsdl.py
Best Web Services attack helper tools OWASP Interceptor, WSMap, SIFT, wsScanner, Foundstone WSDigger, Wfuzz, wsPawn, web2wall, untidy, Schemer, TulaFale, Web Services Enhancements 3.0 for Microsoft .NET, Ajaxfinger, Scanatlas, SOAPSonar Personal Edition
There has been a lot of discussion lately in a few different places that I've seen (blogs, mailing-lists, IRC channels) on testing Web services for security issues. This is a call out to all of those people. Here's your chance to list your favorite tools before I list them all!blog comments powered by Disqus