The CTO of WebRoot is talking about applying Software as a Service to email and web security. It’s a good pitch, delivered to a small audience late in the afternoon.
- Because business-relevant content creation is shifting from “trusted providers” to semi-anonymous collaborations like wikis, blogs, and social networks, the focus is shifting away from blocking and allowing entire sites and toward figuring out how to deal with the possibility of Facebook (e.g.) as a malware vector
- Spam messages per business user in 2008: 42,000, based on their internal statistics.
- Because of #1, outgoing URL filtering no longer works (at least by itself). You have to combine anti-spyware, anti-virus, anti-phishing, and access control with high performance requirements.
I’m at the Gartner IT Security Summit today and tomorrow (alas, I missed Bruce Sterling on the panel yesterday), and have been splitting my time between the show floor and a few of the sessions. I attended a few sessions on application security testing and on ITIL v. 3 this afternoon that sparked a few responses based on my combined security and ITIL experience.
Basically, the challenge to IT organizations who are doing any level of application management — change management of internally managed apps, purchasing COTS apps — is to figure out how to integrate application security into their software development and purchasing lifecycles. The two concrete recommendations that jumped out for me were:
- Don’t treat purchased software differently, from a security perspective, than you treat internally developed software. Hold both to the same standards and demand the same security certification from both. While this has traditionally been harder for COTS software, where source code is usually unavailable, binary analysis techniques such as those provided by my firm enable some level of consistency across these two categories.
- Bake security into your service management lifecycle. From design to transition to continuous improvement, security should be architected in and designed into the process. One way to consider how security can dovetail with ITIL is considering the role of security audits, whether binary or otherwise, as part of change and release management criteria. While secure development practices and source code tools should certainly be part of the SDLC process, release criteria should include security testing as well as functional testing requirements. Again, automated scanning can greatly assist with this process.