Security Vulnerabilities Decomposition

What is the work you're doing today?

Today I work as an application security consultant at Veracode. As part of my job, I help developers and software architects to secure their software. I work with development teams and help them fix correctly the security flaws identified by automated tools, to ensure that they have been remediated in a secure manner.

What are the goals for your talk?

This talk is based on my experience from the work I do. What I see a lot of, is when companies are implementing application security, they are primarily checking the software for most common vulnerabilities, like the OWASP Top 10, for example. The problem with this approach is that you can check for these vulnerabilities only at the end, after the software has been developed. After all, you cannot test for SQL injection before you have written the software which connects to the database. My primary goal for this talk is to empower developers to look at application security from another point of view. If we go back to some basics, security vulnerabilities are just software flaws which have been introduced at various stages of the software development: either at architecture, at design or at the code level. The concept I will explore as part of this talk is to analyze these software vulnerabilities, to decompose them to identify the security controls which prevent them,  are familiar to developers, and can be used on a regular basis when writing the software. The final goal is to give the audience, the developers, another view where we flip the security, and instead of focusing on the vulnerabilities (which can be measured only at the end) to focus instead on the security controls which prevent these vulnerabilities and can be used in the software from the beginning.

What key takeaways do you want people to leave the talk with?

What I like the attendees to take away is that in order to build more secure software, we should focus on one category of vulnerabilities at a time. And for each category of vulnerabilities, we should first identify the security controls which prevent the vulnerability. Then, identify the best place to apply those security controls in the software to effectively prevent that vulnerability. For example, in the latest OWASP Top 10, there have been few new entries. One of them is A4-XML External Entities where by default, older XML processors allow specification of an external entity. If developers want to prevent their software having this vulnerability, the first thing is to identify the security control. For XXE,  the control is hardening the software by disabling parsing XML external entities. Next, is to identify the best place to apply this control when writing the software. It depends on the framework/language. For example, in Java, the best place is before parsing the XML document. There we need to harden the configuration by writing few extra lines of code. And by doing this every time an XML document is parsed, we ensure that the software will proactively prevent this particular vulnerability. This angle of securing the software, by identifying the security controls which must be used, is what I would like the attendees of this conference ( senior developers, tech leads, and the software architects) to take back to their teams and start applying in their software development cycle.