2014 Converge Detroit: Reality Checking Your Security Testing Program
The 2014 Converge Detroit conference did exactly that; it brought together business professionals, developers and hackers in the information security industry for two days of keynotes, sessions and networking at the COBO Center in Detroit, Michigan.
Reality Checking Your Security Testing Program
Speaker: Darren Meyer, Senior Security Researcher of Veracode
This talk covered developers and security testing - developers hadn’t been previously concerned with security. Justifying your security testing program is easy, as the usual answer is compliance. Any type of application linked to your core business, meaning, any mission critical apps need to be designed with security in mind.
There are a few things developers probably didn’t considered, when it comes to developing with security in mind, and those are:
- Agility - the ability to move quickly from idea to market is a huge concern
- Program elasticity - the number of developers, budget and time constrictions can stop a company from doing extensive security testing that takes weeks or more
- Third-party components - how many developers have trusted third-party apps or components? And how do you know they’re secure?
- Discovery - Do you know if you’re testing all of your apps in your environment?
The reality check - and how to do better:
With development and security, you’re on the same team, since you both want to deliver software that doesn’t suck. Developers care about performance, scalability and maintenance, but they’re not always thinking security all the time.
The stages of development usually include:
- Idea
- Resource
- Requirements
- Build & Test [best to do security testing at this stage]
- Certification
- Warranty & Support
It’s key to do security testing at the building and testing stage - but usually we end up doing security at the certification level. Being ‘lean’ and ‘agile isn’t a good excuse - if you’re actually agile, then you should be in QA and Operations.
Most of your problems, as a developer, are not unique - security should be about community, meaning, if you know what you’re doing, you should share what you know. And, if you don’t you should ask for help.
For developers, security is about quality as it affects the delivery of a product and software. Developers do care about security, including performance, reliability, maintainability, usability and time-to-market.
They also need clear and testable requirements to weigh security against. There’s a difference between quality assurance vs. quality control, which comes from the manufacturing industry. Much of that comes from the fact that if they need to replace something after it gets shipped out, it costs them a lot. Quality control measures products to ensure its good enough to ship.
Quality assurance is about detecting problems before they shipped down the manufacturing line - similar to building security into the design of the product. The key is to determine what’s achievable within an organization, and then set out to achieve it.
Check out the full slide deck of Darren’s talk here.
Darren Meyer, Senior Security Researcher, Application Security, Veracode
Darren P. Meyer is an AppSec professional with a passion for closing the gaps between development, operations, business, and security. His background in software development has informed his security experience, which includes building a security testing program for a Fortune 50 retailer, and security instruction at dozens of organizations around the world.