Part 1 - Overview
There isn’t a security threat that you can think of that some security company’s marketing literature doesn’t promise a solution for. But despite the zeal of marketers and the production of many great security solutions, there are still many threats to enterprise IT that simply cannot be offset, mitigated or prevented by a single technology solution.
There also is a lot of misinformation out there that makes for uninformed security professionals and software developers. It’s not uncommon to hear things like "well, I run a web vulnerability scanning tool that catches the majority of vulnerabilities", or "my Web Application Firewall mitigates any security holes in my applications" or "the frameworks we use prevent developers from writing insecure code”. I cringe when I hear this because I know from experience that tools, frameworks and technologies can only automate, protect, and sandbox your software applications so much.
As the manager of a group of active application security practitioners and researchers, my team is often asked to find ways to break into applications from the outside (beat the IT defense) and provide suggestions on how to write more secure code and find vulnerabilities faster and easier. We witness first-hand how easy it can be to circumvent perimeter defenses and the failures of tools, frameworks, and IDE’s to produce vulnerability-proof software applications.
Because this topic is so important to the industry (and to me, personally) I’m going to write a series of blogs that cover four genres of tools and technologies. The blogs will discuss pros & cons; and, most importantly, what each genre can and cannot protect against. Here are the upcoming 4 genres about which I will blog:
- Development tools
- Integrated Development Environments (IDEs)
- Security Frameworks & Libraries
- Object Relational Mapping (ORM) Software
- Test tools
- Static Analysis Security Test (SAST) tools
- Dynamic Analysis Security Test (DAST)
- Fuzzing tools
- IT/Network defenses
- Web Application Firewalls (WAFs)
- IDS/IPS (including Snort)
- Application Whitelisting (AWL)
- Standards, Policies, and Maturity Models
- Defensive coding principles
- Generally available "best practices" (OpenSAMM, OWASP)
- Threat modeling and free resources (Microsoft Threat Modeling tool)
I’d like to reiterate that all of these solutions these are good, and should be used as part of one’s overall security hygiene. However, none of these solutions stand on their own -- even if you leverage all of them, if not used properly and supported by good development, testing, and design principles, you’re still bound to suffer insecurities.