Data Leak Protection... Gah!

Six Ways To Stop Data Leaks
I can tell this won't be the first or last rant I post about data leak protection if it turns out to be "The next Big Thing(tm)"
Ultimately I think that a lot of magic bullets are going to be sold in this field, and a lot of companies are going to end up disappointed.
Lets look at this article though. it lays out some ways to stop data leaks.
Point 1. - Get a Handle on the data. Yep the idea that if you don't know where you're critical information is you can't protect it. Fair point, although in reality it's a lot harder than it sounds in a large environment.
Point 2 - Monitor Content in motion. Now here's where I start getting a bit cynical. the idea that you can monitor all your content as it leaves your company is frankly silly. Here's a couple of examples of ways that data might leave your company that most of these solutions aren't likely to address.

  • do you allow Internet access for your staff? If so do you use white-list or black-list filtering. If you allow access for your staff to the Internet (as almost all companies do) and you don't use white-list filtering (so only allowing access to approved sites on a list), then how do you monitor content leaving over the web... do you intercept and read all content on the Internet channel? Do you intercept all SSL traffic and look inside? If you find encrypted traffic inside the SSL session do you just block it? If not you're not monitoring the single biggest conduit for data out of your company.
  • Here's another One. Do you have desktop machines with nice large hard drives? Can people work out of hours in your offices? now.. how good is the physical security on all your desktops... could a user just open one up take the hard drive out copy it and put it back?

to be fair to them points 3, 4 and 5 are pretty reasonable, IT Security best practice.
point 6 Centralize your intellectual property data - Just not practical for most companies. Companies at the moment are looking to make working more and more flexible and information easier to access. The idea of putting it in one big vault so it can be protected just ain't gonna fly.

Pen Testing A go go

Lots of interesting chat on the reasons to Pen Test, or not from various blogs starting over here at techtarget then rapidly spreading out over the blogosphere (hate that word but it's the only one going) to Matasano mcwresearch, Security Incite and in a bit of a divergence from topic layer 8
And what does all this tell us.... Well there's a lot of confusion around what a penetration test is and at lot of divergence over the value they provide.
So anyway here's my 0.02 on the subject. Penetration tests are not a good way to prove the security of a system, if possible and the application is under your control go for developing good secure coding standards and develop a good Security Development lifecycle including elements like threat modeling.
However in the real world, life doesn't work like that all the time, you'll get applications which are legacy and may not have been securely developed, you'll get 3rd party applications that you've no idea how they've been developed, and at times like that a penetration test is a reasonable way of getting some level of assurance that they're reasonably secure, and there probably aren't any glaring holes there.
A couple of other points that emerged from all this reading is

  • I definitely agree with Marcus Ranum that the PCI in particular look like a penetration testers (and code reviewers) full employment act. Every website that processes cardholder data (and that's a lot of sites) needs an annual penetration test and code review (unless they're using a web application firewall)
  • I definitely don't agree with Bruce schneier's point about using penetration testing to identify items on the SANS top 20 list. For that if I've got any access to the systems I'd much prefer a patch management and security policy compliance tool, 'cause they're way less hit and miss than a penetration test
  • Dave G at Matasano's probably right about a lot of bad penetration tests, although I think a lot of the problem is people not understanding what they're being sold (ie running nessus on someone's site is not a penetration test. Perhaps what's needed is a well accepted certification for penetration testers in different technologies like Nick Baskett talks about.
  • Michael at mcwresearch's got an excellent point about using successful penetration tests as a marketing point. I'm constantly surprised at how many companies who are selling web based products, haven't had any penetration testing done

Web 2.0 security it's not going to be pretty

1 Raindrop: Understand Web 2.0 Security Issues - As Easy as 2, 1, 3
Very good points made in this post. At the moment the probablw saviour for a lot of transactional sites is that they've been really slow on the bandwagon, so are still running web 1.0 style sites!
That said, the more information that comes out from researchers like Jeremiah Grossman and RSnake the less faith people can really have in the browser security model that most E-Commerce sites rely on.
What's been missing to date is the Slammer or Nimda of the web application hacking world. Without a wide-ranging attack like that, it will continue to be very difficult to convince a lot of businesses to take these threats seriously...

Holy Apples to Oranges Comparison Batman

Security Scanners Comparison Test Results | SecGuru
Why do organisations persist in comparing tools that aren't in the same market...
Lets look at this little list
We've got O/S Vulnerabilty scanners, Port scanners and Website Vulnerability scanners... how can you compare a network portscanner to a tool that looks for SQL unjection vulns in websites...

One of those Articles...

When disgruntled employees get clever - Network World
This was definitely one of those articles that I read in the sure and certain knowledge that the person writing it would be selling the solution to the problem they were laying out... Now a lot of the time people who work for vendors have some of the most valuable insight as they're fully focused on a particular technology area, but you also get a number of articles like this one that create an artificial scenario, avoid any mention of related problems that the technology they sell won't solve and then seem to think that because they don't mention their product by name, you wont twig..
In this case the author sets out that simple e-mail filtering won't catch intellectual property theft, but that "fingerprinting" intellectual property and looking for those fingerprints will allow companies to catch that leakage...
I've not thought too long on this but it seems there's a couple of holes in this as an idea... firstly E-mail encryption... you'd expect users to be encrypting sensitive documents that they send externally so unless the software has the right position in the network and the company has the right kind of encryption setup, it's not going to see much in the way of fingerprints.
Secondly and perhaps more seriously, I'd have thought most employees might be a bit smarter than to try and e-mail themselves intellectual property that they want to take. Instead why not just put in on a data key, or put it on your laptop and take it home, or go really low tech and ... print it out and put it in your briefcase...
Oh one other slight problem with this article .. on the first page there's a throw away line "First, you have to be able to identify the data you want to protect when it is at rest, before it leaves the network." !. Companies spend a huge amount of resource trying to classify data just to the server or perhaps the share/directory level and then keep that classification reasonably up to date in the very fast moving business environment that most operate in these days. The idea of a large company that knows where all it's valuable data is exactly is to me, not very likely.

Pen Testing Tools aren't always the best solution

Fave raves - Network World
Now I know that Core Impact is a really cool tool, though I've not had a chance to play with it directly, but it's not always the right tool for the job.... Like in this case, we have a network manager who's using this as what looks like a vulnerability management tool and even saying you can give it to a junior engineer to use... D'oh!
Surely the best way as a network manager to do this is through patch management or vuln. scanning tools which you run regularly over your whole estate, not through pointing a Penetration testing tool at some servers...
No matter how many exploits Core have for their product they're never going to find as many holes as a tool that authenticates to the box and enumerates missing patches and security policy non-compliances..
Apart from anything else actually exploiting vulnerable services always runs a risk of crashing the service or indeed the server, which a patch scanning/security config scanning tool wouldn't.
The really bizarre part is that core actually use this as a case study on their site...

Security products != Secure products

Here's a thought. If you look at large software providers code base, Microsoft, Oracle or Cisco (even though they're known as a hardware company all those switches and routers run software), you'll see that they've had vulnerabilities found in them, and for that trio a fair number.
Well now think about all the new vendors that spring onto the market with each new trend in the security market. This year it's NAC, in previous years it's been IDS, A-V and Anti-Spyware, Endpoint security... the list goes on.
Now here's the thing, I've never in reading the websites or promotional literature for security product providers heard them say anything about their development practices or methodologies, which need to be top notch to reduce the chances of vulnerabilities cropping up.
Obviously security flaws in any software can be bad.. but it your security software isn't securely developed you're in a whole load of trouble.
So next time you're going to buy some security software, don't just ask about all the whizzy features and how compliant it'll make you. Ask about their development practices, what code reviews are carried out, do they get external parties to validate their code, that kind of thing...

Why Microsofts SDL may not lead to secure Microsoft Products

I was reading this article on Wired.com about this months Microsoft patches when something occurred to me.
Microsoft have done a huge amount of work on the security of their development practices and ensuring that there are fewer vulnerabilities in their products but what about "bought in" code?
The reason this occurred to me is that the one vulnerability from this months set that affects Vista is in some of the A-V technology that they've acquired with companies like Sybari.
So every time Microsoft buys a company and integrates their products into the existing Microsoft ones they potentially introduce a load of new vulnerabilities in code that probably won't have been through the same rigours as the internally developed code. This is especially relevant where they are integrating products in security sensitive areas of the operating system like A-V and Anti-Spyware.
Now Microsoft could of course re-write the codebase of any acquired technology before integrating it, but that would kinda' defeat the purpose of buying the company in the first place!

Very nasty solaris telnet bug

There's some information on a very nasty Solaris telnet vulnerability over at the Computer Defense blog.
Now hopefully this'll have limited impact 'cause all the solaris admins out there are running SSH already...
Doubt it though, I've heard quite a few unix/router guys argue against dropping telnet in the past, so there's probably quite a few boxes out there using it...

The Final Frontier for Microsoft Security - Complexity

There's a really interesting posting at Visual Complexity that provides a good illustration of what I think Microsofts main remaining problem in regards to security is.
MS have done tons of work in improving their code quality, improving their default builds and adding features like Address space layout randomization (ALSR) to make hacking into their products harder.
The one area that's left is complexity. Ultimately the more code that is installed on a system the more code there is to be attacked, either remotely or locallly. what the graphs from visual complexity show is that for web servers IIS on windows has more potentially active code that Apache on Linux.
Hopefully some of the other stories that have surfaced recently will lead to the possibility of having a very stripped down Windows OS if you need it...