Tuesday, May 27, 2014

Hacking the Registry to Keep WindowsXP Updating - A Bad, Bad Idea

When WindowsXP officially expired on support a while back - I wrote a post blog post titled "The Great WindowsXP Cataclysm" which talked about some of the reasons organizations had for staying on the antiquated operating system. Some of those reasons were valid, especially if you were running a Point-of-Sales (POS) terminal system which is based off of WindowsXP Services Pack 3 called "Windows Embedded POSReady 2009". According to this Microsoft lifecycle support site, this POSReady system runs embedded WindowsXP, and is supported until April 9th, 2019.

Leave it up to the security community to figure out that a simple registry key which identifies the POSReady 2009 operating system could be hacked into the registry of a WindowsXP machine to keep it getting updates. Well ... sort of. This is where it gets weird. Read this ZDNet article with Microsoft's response carefully... and notice that while they admit this will update WindowsXP systems, there is a  string of caveats that should make you think twice.

It's important to acknowledge that this hack (and that's all this really is) essentially tricks the update service into thinking your OS is a point-of-sales WindowsXP embedded device. The essential questions, which Microsoft hints at, is just how different is WindowsXP from WindowsXP Embedded? The answer is - quite a bit, actually. Check out this paper on the difference between WindowsXP Professional and WindowsXP Embedded and decide for yourself if you're willing to take that risk. Architecturally, the two operating systems are close, obviously since they're both based off the same kernel. Once you start getting into the add-ons and run-time environment options Professional and Embedded start to look dramatically different - in my opinion. This means that if you start applying patches and bits meant for the embedded operations system onto your corporate desktops at very least the results would be unpredictable...

So let's summarize my thoughts here.
  • some organizations are still on WinXP on the corporate desktop (and elsewhere, obviously)
  • for those that haven't migrated, excuses are critical... not necessarily valid, but critical
  • a quick registry hack is available which tricks Windows Update into pushing patches and updates meant for a variation of your WindowsXP operating system onto your machine(s)
The hack is a bad idea for the following reasons:
  • potentially de-stabilizes your WindowsXP operating system
  • necessitates significantly more testing to ensure compatibility
  • quite obviously breaks your software agreement
  • could potentially get you into a CFAA or other legal situation
Essentially, my thoughts are this - if you're resorting to hacking the registry to get patches which are meant for an OS similar to yours onto your machine for security - you've got a big, big problem. The energy you're expending, and potential hazards you're creating on top of system stability and unknown security issues ...should get you fired. Immediately.

Folks - this isn't a viable work-around to keep WindowsXP alive. It's a bad, bad idea.

Tuesday, May 13, 2014

Enterprise Security Tools Vendors' Big Problem

I’ve spent a substantial amount of time helping organizations justify enterprise security software purchases, specifically software security testing tools, in my career. Over that time it was common to run up against the question of “Why buy an enterprise tool when we can use open source?” The answer at the time, which was almost 5 years ago at this point, was that the maturity of the open-source tools wasn’t there. That argument, in recent years, has all but vanished, and enterprise security vendors which have open-source or inexpensive alternatives are in trouble.

The most immediate effect I’m seeing is in the testing tools space. Penetration testing tools are the natural target for erosion of market-share by open source simply because these type of tools are generated in large volumes by testers as they work through engagements and it’s natural for people to want to share. Take for example the most popular penetration testing platform hands-down right now – Metasploit. HD Moore’s community-sourced platform has grown into a monster, with code commits in volumes that would make even the most diligent enterprise security software shop blush. Now – not all this code is clean and brilliantly functional, but it does the job and most of all it’s on the leading edge of innovation as ideas can quickly be pushed to the code base, and taken up and built upon by members of the community. A brilliant approach that a closed-source enterprise software shop will struggle to match. Tools in this space that have price tags north of $10k, $20k are struggling for the very simple reason that even though the open-source equivalent isn't necessarily as polished and pretty – in many cases technically it’s more advanced, more up-to-date, and as a result of being community driven ... more innovative.

I don’t think this means certain death for the big closed-source enterprise security vendors though. It would appear that there is still a customer demand for the tools that these shops release – but it’s a matter of understanding your target market. As I see it there are at least three classes of users: specialist, expert, and master ranked by the person’s abilities.

At the specialist level you’re typically not getting someone who can write their own complex scripts, or exploit code. In fact they’re generally just looking for a blunt implement to do the job…with no requirement to do it exceptionally well. In software security these people manifested as an analyst who was tasked with a series of tasks and one of them just happened to be testing the organization’s web applications. These people weren't testers by skill or trade, nor were they particularly knowledgeable about penetration testing, or even coding web applications. They needed to do a job and that job was to test the app with the least amount of pain. They would look at low-cost or open-source alternatives which weren't particularly polished, required lots of manual work/scripting, and buckets of knowledge and (generally) understood that this wasn't going to be a relationship for them. They sought out the enterprise software which gave them push-button results, and did some of the thinking for them. No assembly required, batteries included.

The next rung up the ladder was always tricky – because the expert class was just smart enough to be dangerous to themselves. What I mean by that is these people knew a little bit about software development, they knew the basics of security and were willing to tinker. They still had a job to get done, and the enterprise software path would have been more productive in many of these cases, but either because they had a passion and desire to learn, or because they simply wanted to see if they could do it – they would compare open-source to closed-source tools (apples and pumpkins) and not fully understand that these were different. This user was tricky because they often times felt that the open-source alternatives were “good enough” even though their skills wouldn't be good enough to produce value from the tools they were using. This as you can guess produced scary results.

The third category was the master class. I met only a handful of these types in my time in that supporting role. These people had no desire or need for enterprise-built security testing tools… they were too constraining, too slow-moving, and just not good enough. They could do run into a problem the enterprise software couldn't tackle and effectively code their own way around it… which allowed them to move faster, be more agile and adapt to the changing nature of the target better. I stress that there were very few of these people out there…and most fell into the expert class. Master class is typically achieved after years of experience immersed in technology and focused work. Generalists rarely get to this level of skill – and it’s really the enterprise’s fault for pushing people to perform 3-4 different roles on average … only 1-2 of them really fall into the person’s wheelhouse.

“Horses for courses” one of my colleagues would say. Make sure you’re advising intelligently so that the right person has the right tool in their hand for their skill set, and the job at hand.

The interesting thing, I think, is that as more security professionals flood the market there dynamics are being skewed. I believe that the distribution between specialist, expert and master is dramatically dramatically changing. A few years ago I would have said that we had 50% specialist, 40% expert, and 10% master class out there. Today’s security industry is becoming more community-enabled and driving that distribution to the right more. So now I think we’re closer to 30% specialist, 50% expert, 20% master and continuing to shift towards master at a good pace. This is both good for the overall state of security, and bad for enterprise security software companies which relied on the specialist and expert classes as a target buyer.

The good news is that enterprise security software isn't dead, it’s just being forced to re-evaluate its value propositions. Enterprise software shops need to re-focus their efforts to engage the community more, make their tools more open (one of the biggest gripes ever is proprietary closed formats of data) and extensible and start to think about lowering their costs… or maybe shift their licensing models to the as-a-Service model. I’m not saying I have the answers, but these shifts are happening and they’re not asking for permission. Enterprise security software shops, if they wish to stay relevant, need to address the shifting sands of skills, needs, and community. Or they can become irrelevant …

Google+