10-21, 13:00–13:25 (US/Eastern), ENG 103
Are you tired of constantly patching vulnerabilities in production systems? Would you prefer proactive security mitigation to reactive response? This presentation explores the lessons I learned building a culture of quality software engineering, and how that culture can mitigate vulnerabilities before they are ever written. The lessons discussed can help your organization break the inertia of endless patching, and instead benefit from consistent, meaningful improvement.
We will begin by exploring what quality means, and how it can be applied to a software world. We define quality as a physical representation of a culture that takes pride in their product. With software, if a team focuses on quality first, it can lead to a sustainable culture of secure software development. When a team writes code, they should invest in doing it once and doing it right.
We will then explore of the lessons I learned building a culture of quality, and how it can be applied to application security. It is based on the “Toyota Way” management philosophy, but has been adopted to be more relevant to the audience.
We will discuss what a culture of quality means, and how it looks in the world of software. This includes encouraging individual developers to take the time they need to build high-quality code, and driving them to want to develop high-quality software. It will also discuss how investing in quality can lead to efficiency and productivity gains in the long-term.
We will then discuss how security teams can standardize technologies, and make them easy for developers to use. When the easiest path for implementation is also secure, engineers are more likely to use that path rather than finding alternates. Teams should use libraries to standardize and abstract high-risk operations to reduce the number of low-quality implementations. These may include ORMs, AAA libraries, input validators, and more.
Lastly, we will discuss continual improvement, and how time can be leveraged to make lasting change. This includes security sprints, which focus on making small changes to developer behavior. As the developers adapt to the workflow changes, more can be introduced. Continual improvement takes SDLC policies and slowly integrates them into the developer workflow. This leads to more lasting change than a quick transition to SLDC policies, which may overwhelm the developers and lead to misunderstandings. It will also discuss the importance of maintaining developer relations and not being too hard-handed, which could destroy trust and lead to hidden risks.
Alexander Beaver is an Application Security Engineer and student at the Rochester Institute of Technology. He has worked in application security for Paramount, Cisco, and multiple start-ups. Alexander received international recognition for his leadership of a FIRST robotics team, including the shift to a quality-first culture. He also was the Tech Lead at RITSEC, a student-run cybersecurity club with over 200 members. At RITSEC, Alexander developed a multi-year plan to lower the barriers to security education. He specializes on Secure Software Development and Trusted Computing. Alexander is interested in the relationship between organizational culture and security posture, particularly SDLC adoption.