From Fortify Software comes this trailer called The New Face of Cybercrime. The part that really spoke the loudest, in my mind, was near the end when Ranum came in to essentially say that no software is so trivial that it can be made without security in mind. Who knows when that software will be picked up and used in a way that people’s lives depend upon it. It looks like this full video might be a staple of any corporate bookshelf for awareness training.
My only beef on this? It appears sponsored by Fortify Software, and they definitely have a stake in saying the security of tomorrow is not in the network but rather in the software and the software development lifecycle. This could turn out to simply be a big budget advertisement…
One thought on “the new face of cybercrime, trailer”
How could the network possibly have anything to do with the security of tomorrow?
I understand the WAF’s and proxies can sometimes see inside SSL, but who says that SSL is the only secure network channel?
Some people think that Fortify, Ounce, or Veracode are the answer with “security review tools”. Others feel that formal methods (specification languages along with verification tools) are better than AST-based security review tools. In formal methods verification tools, it appears that few agree that ATP’s provide much value, but many agree that model-checking does, hence the success of bug-finding tools such as Coverity Prevent. Certainly SPIN and Java PathFinder are also lightweight model-checkers that can be used for bug-finding.
The thing we’re lacking is not with secure code inspection tools (or testing/fault-injection/fuzzing tools), but with secure design inspection or formal-methods verification languages/tools. Nobody is going to create a full BAN logic written in Z notation for their new sparkly web framework. Well, ok Microsoft is going to continue to use SAL for some of their projects, and a few other people might explore similar ideas.
Speaking of frameworks, some people feel that the speed with which frameworks are adding defenses against security-related bugs outclasses secure code inspection or software security functional testing (fault-injection/fuzzing). In particular, cost is assumed to be lower. However, I caution that these frameworks only prevent some semantic vulnerabilities in the same way that WAF’s do (actually in the same way that WAF’s that get close to the code such as Fortify Software Defender, CORE GRASP, or Imperva SecureSphere — or possibly VMWare/Determina Memory Firewall or DieHard-Software.org in the case of fat applications). Just because you’re using HDIV with PMD and FindBugs doesn’t mean that your JEE application is protected from all semantic security-related bugs, let alone design issues.
In order to solve all of these problems and in particular design issues, I suggest looking at the software architecture and not the development framework. Components and connectors should undergo secure design inspection, which is easily accomplished if they are written in UML 2.0 (or any ADL) with Klocwork K7. We’re talking about large, SOA-based applications that have two year or more lifecycles. But to not build on such a “secure software architecture” would incur many more risks. The only fitting project that I’m aware of is the OWASP ESAPI Project, but it’s relatively new. I’m also currently reading, “Documenting Software Architectures: Views and Beyond” on SafariBooksOnline for more perspective.
Comments are closed.