ECM And Security

It looks like James McGovern is back at it again... criticizing ECM bloggers for not caring enough about security...

I do blog about security a bit... just check my security topic feed for some examples... but I intentionally limit the number of times I do so.

Why? Firstly, my wife thought I was attracting the wrong element with my posts about how Phishers could use anti-spam technology to hack URLs to look like they came from Amazon or Google. That attracted some unwanted attention.

Secondly, I'm keenly aware that the security of the application is secondary to the security of the solution. ECM is one piece of the puzzle... I've been privy to three separate reports from security firms who did penetration tests against Stellent solutions. Two from government agencies, and one from a major financial institution. Of the dozens of holes they found, only one was due to a problem in the core product (now patched)... the rest were problems with the configuration and design choices by the implementation team. I also felt proud that afterwards I tracked down two security holes that three specialist firms failed to find... one esoteric SQL injection vector, and another cross-site scripting attack with improperly-encoded URLs that only worked in IE... because IE was trying to be 'helpful.' Both have been patched for some time...

Thirdly, perhaps because of my disappointment with implementation teams, I've addressed a lot of these security risks and countermeasures in my Stellent book, and my Stellent security presentation from Crescendo 2006... and I find it a bit dull to repeat myself...

I would agree that the OWASP Top Ten are important for everybody to know, but then again, so are the fallacies of distributed computing. If you ignore the former, your solution might not be secure... but if you ignore the latter, your solution won't work at all.

Personally, the I think the OWASP top ten is a bit off... I doubt even Bruce Schneier would put 'cryptography' in the top ten, while leaving out such monsters as input validation, improper UTF8/URL decoding, configuration management, and denial of service. Cross Site Request Forgery is almost exactly the same attack vector as cross site scripting, so calling it out as a separate issue is kind of silly...

Anyway, I restrict myself to one security post per month... so I'm categorizing this as an "Oracle" post so I can sneak in two for February 2008 ;-)

comments

What's the basic practise for penetration tests?

Hi Bex, another nice post, very informative!! Since I am not an expert in security area, I was curious how usually this type of test gets done. Do the testers need to have the source code before doing the test or they just use whatever tools or methods ?

Cheers, Kent

hard to say...

I'm not a security expert either... its probably more correct to call me a security hobbyist ;-)

From what I know, these folks use lots of different techniques. A full-code audit is usually prohibitively expensive... Automated penetration tests are common: they look for common holes (cross-site scripting, SQL injection, encoding, etc.) and hit them with a battery of tests until something breaks.

Of course, these penetration tests are tricky... they're akin to demonstrating that glass is bulletproof by firing bullets at it. Its easy to do before a system goes live, but systems evolve... what if you introduce a new security hole? Should you run the automated test weekly on a live system? Well, what if your test succeeds, and you break your system? Testing web apps is generally harmless, but expanding your tests to the OS, database, routers, etc., gets riskier...

There's no replacement for being mindful about security and system complexity.

Recent comments