The AppSec Blame Game - Part 2

It's Time for Software Development to Get Rugged
The AppSec Blame Game - Part 2

In Part 1, we discussed what's wrong with organizations that can't seem to create secure code, no matter how much they spend or how many tools they use. The kneejerk approach to application security is to start a program to find and fix vulnerabilities. The problem with these reactive programs is that they end up being expensive witch-hunts that don't change the way code is built. Instead, we need to think of those vulnerabilities as symptoms of a deeper problem that lies somewhere in the software development organization.

See Also: Live Webinar | Navigating Identity Threats: Detection & Response Strategies for Modern Security Challenges

Application Security Problems Aren't Technical; They're Cultural

With due respect to Schneier, security isn't a product or a process, it's a property of the software produced by an organization. We need a word to describe an organization that reliably produces secure software - let's call it "rugged." Rugged is NOT the same as "secure." Secure is a possible state of affairs at a certain point in time. But rugged describes staying ahead of the threat over time. Rugged organizations create secure code as a byproduct of their culture. You become rugged as you run the gauntlet, instrument your organization and your code, constantly experiment to see if anything breaks, and survive the process of hardening yourself through real-world experience.

Think of getting rugged the same way you think about getting fit. It's a lifestyle, but it's not necessarily more expensive. For a moment, I want you to imagine a software development organization as though it is a machine that produces software. You build this machine out of people, processes, and technology. If you design the organizational structure, communications mechanisms, interactions, tools, and activities right, you can make your machine reliably produce secure code. Here are some ideas for designing your "rugged" organization.

  • Communicate via a Concrete Security Story - As Denzel Washington put it in Training Day, "It's not what you know; it's what you can prove." Most organizations are simply incapable of communicating about security - knowledge is spotty and disorganized, people aren't aligned, and it's impossible to establish a line-of-sight from risks to defenses. Try creating a structured security story that starts with your most important security concerns and proceeds through strategies, defenses and assurance. All of your security activities need to support your story or you should cut them. You may find that much of what you are currently doing isn't helping, and that there are many less expensive ways to achieve your goals.
  • Gather Application Threat Intelligence - If your applications are going to be in service for 10 years, you can't defend against yesterday's threats. Your organization needs a capability to gather information about the threats your applications are facing. It's not enough to rely on compliance standards that capture well-understood risks years after they are discovered. Neither are tools that find only those vulnerabilities that are easy, instead of the ones that are important to your business. You're going to need to monitor research, attend conferences, and participate in communities like FIRST and OWASP.
  • Aggressively Strengthen and Simplify - When Cross-Site Request Forgery (CSRF) was discovered, did your organization analyze the application portfolio, evaluate the aggregate risk and start developing a defense strategy? Or, did you do nothing for years, and rely on annual penetration tests and spot fixes? If you've captured your security story, are you proud of it? Enough to make it public? If not, aren't you really relying on security-by-(not-so)-obscurity? Strategic, proactive, security defenses are not only better at countering risks, they are also far less expensive to build, maintain, and operate. Security thrives in sunshine, and organizations that are aligned on an honest security story will naturally seek out ways to improve.
  • Test Yourself in Battle - When "builders" and "breakers" battle back and forth, the result is a battle-hardened application. When you design your organization, you should strive to establish a culture that allows these two groups to both compete and collaborate. Think of the cryptographic community, which has a thriving ecosystem of both builders and breakers and a history of evolving the state-of-the-art. You should aim to replicate this culture in your organization by setting up roles, responsibilities, communications, reporting structure, incentives, etc.
  • Fix the Machine - Truly rugged organizations are continuously improving their software development "machine" so that it reliably produces secure, resilient, available software. When a vulnerability is discovered, they don't just fix it...they fix the machine so that it will never produce software with that flaw again.

If you focus on creating a rugged culture, all of the requirements, standards and activities will follow naturally. But many companies attempt this backwards, pushing security compliance standards and process models onto development teams that aren't designed to handle them. The result is often a bankrupt security culture that relies on blame and intimidation and produces software with a confused, tangled and often invisible security story.

Consider the software development culture and ask yourself if your software development organization is rugged - designed to produce secure code. What are you doing to nurture secure coding practices? Are developers incentivized to create secure code? Or, are they pilloried when a mistake is made? Ask yourself if you've done everything possible to make secure coding simple and fun. For more ideas on improving security via your organizations software development culture, visit ruggedsoftware.org and check out the free and open Rugged Handbook and Rugged Implementation Guide.

Jeff Williams is the co-founder of both OWASP and Aspect Security, a consulting company focused exclusively on application security and training services.



About the Author

Jeff Williams, Co-Founder and Chief Technology Officer, Contrast Security

Jeff Williams, Co-Founder and Chief Technology Officer, Contrast Security

Co-Founder and Chief Technology Officer, Contrast Security

Jeff brings more than 20 years of security leadership experience as Co-Founder and Chief Technology Officer of Contrast. Previously, Jeff was Co-Founder and Chief Executive Officer of Aspect Security, a successful and innovative application security consulting company acquired by Ernst & Young. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for eight years and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many other widely adopted free and open projects. Jeff has a BA from the University of Virginia, an MA from George Mason, and a JD from Georgetown.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.eu, you agree to our use of cookies.