SESSION + Live Q&A
Security Vulnerabilities Decomposition
In most companies security is driven by compliance regulations. The policies are designed to contain the CWEs each company is interested to comply with. The result of this approach is a high number of insecure applications are still produced and injection is still King. Is there another way to secure the software in a more developer friendly manner?
This presentation will look at security vulnerabilities from a different angle. We will decompose the vulnerabilities into the security controls that prevent them and developers are familiar with. We will flip the security from focusing on vulnerabilities (measured at the end) to focus on the security controls which can be used by developers from beginning in software development cycle.
Recommended to all developers looking to integrate security in their software applications.
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.
Speaker
![](https://archive.qconlondon.com/sites/qcon_london/files/styles/240x240/public/katyanton-headshot.png?itok=yFknn3B1)
Katy Anton
Principal Application Security Consultant @Veracode
Katy Anton is a security professional with a background in software development. An international public speaker, she enjoys speaking about software security and how to secure software applications.In her previous roles she led software development teams and implemented security best...
Read moreFind Katy Anton at:
From the same track
Designing Secure Architectures the Modern Way, Regardless of Stack
This talk aims to attack two typical conflicts any security architect is well familiar with: 1. Most of the design thinking for preventing security incidents and performance bottlenecks focuses on avoiding known risks in a known way. However, most of the time this approach leads to...
![](https://archive.qconlondon.com/sites/qcon_london/files/styles/240x240/public/eugeneuk20.jpg?itok=RqhKyuaS)
Eugene Pilyankevich
CTO @cossacklabs, Building Applied Cryptographic / Data Security Tooling
Reconciling Performance and Security in High Load Environments
Most perceive security fixes and improvements as a necessary evil, because security is much “less tangible” than primary product functionality in terms of potential revenue. On top of not bringing any “meaningful” value to the overall system, security comes at a cost of...
![](https://archive.qconlondon.com/sites/qcon_london/files/styles/240x240/public/Ignat_Korchagin.jpg?itok=C2qyMSQG)
Ignat Korchagin
Cryptographer, & Security Software Engineer @Cloudflare
Keep Calm and Secure Your CI/CD Pipeline
Shifting left significantly reduces costs and diminishes release delays. Continuous security validation should be added at each step from development through production to help ensure the application is always secure. We can then switch the conversation with the security team from approving each...
![](https://archive.qconlondon.com/sites/qcon_london/files/styles/240x240/public/sonya.moisset.jpg?itok=peDjlete)
Sonya Moisset
Lead Security Engineer @Photobox / Tech Lead @PrideInLondon
The Quantum Risk & Future Post-Quantum Standards
This talk will describe the risk of quantum computing to cryptography, in a way suitable to an audience without quantum physics nor cryptography background. We will present the mitigations available today thanks to research in the field of post-quantum cryptography, and we'll...
![](https://archive.qconlondon.com/sites/qcon_london/files/styles/240x240/public/img_0659.jpg?itok=yU0qp6mp)
Jean-Philippe Aumasson
Author of "Serious Cryptography", Designer of Hash Functions BLAKE3 and BLAKE2