Seventy percent of executives want more oversight and participation from board members, chairpersons and CEOs for data breach preparedness, according to a Ponemon study. While this is a good step to align security priorities, executives need to not only look up, but also ensure that those on the frontline—application developers—are in the know about security and breach preparedness.
By including developers in decision-making conversations, businesses can communicate their concerns directly to the people creating and executing code, those who are responsible for the first piece of application security. Moreover, opening the channel of communication provides the opportunity for developers to also communicate what they see up the ranks so that it can be considered along with larger strategy discussions. This is highly consistent with the approaches of the DevOps movement, which is helping to transform monolithic IT organizations into nimble and effective delivery engines.
This mode of operation mirrors closely the building of a house. For instance, you wouldn't rely solely on the plans provided by an architect. You would communicate directly with your contractors to let them know your concerns about the project. Additionally, a worker's opinion on what they're seeing on the ground—is there enough material, is it strong enough, are their problems found during excavation, etc.—would generally hold more weight compared to that of someone who never visits the build site. This process results in livable homes, and could be looked to as a model to begin developing secure applications.
It's also important to note that the issue of security extends beyond the lack of developer inclusivity in high-level discussions. The process that businesses need to undergo to better secure their applications reaches all levels of the development process, just like the construction of a home doesn't end once the structure has been finished. Investment of time and money along with a conscious evaluation of practices are also needed to achieve a strong security posture.
By including developers in decision-making conversations, businesses can communicate their concerns directly to the people creating and executing code...
So how can you ensure that your developers are coding securely? Map the dollars of fraud and invest accordingly. How much money do businesses actually lose to breaches? What is their risk tolerance? How much would it cost to take steps now compared to what a breach could cost down the line? By mapping out these kinds of questions, businesses can rationalize time and money spent on security and make it easier to convey that urgency to all levels.
For example, although training for developers to code securely can be pricey – a public SANS course can cost more than $4,000 a person and even OWASP courses run about $800 a person – every tool out there is often exponentially more expensive while still having its flaws. There wouldn't be a slew of new breaches flooding the headlines everyday otherwise. Yet companies pay upwards of $150,000 for app-level scanning per big applications and sometimes pay tens of thousands per seat of static analysis tools, even though developers don't necessarily know what to do with the results – which themselves often contain false positives. And comparing training now versus the potential cost of a breach later would show even more disparate numbers.
As a result, many people would argue that you're better off with Burp ($300) or ZAP (free) and somebody that knows what they are doing, and they're right. To go back to the home analogy, it's not about what brand of drill is being used or having the best hammer, it's about having workers that know what they're doing and how to use what's at hand. This could prove to be difficult considering the current skills gap, but this is an even further reason to begin training your developers to be both builders and breakers.
Training. Developers might be master coders, building the most effective application from the front end to the back end, but they are not security experts. If we've learned anything from the slew of breaches caused by application vulnerabilities this year, it's that we can't assume any code is safe. Traditionally, the education of coders does not include security best practices, especially for app developers in organizations where a good job is measured in deadlines. They can deliver a functioning application but they still have a knowledge gap that could have unwanted security repercussions down the road. It's also a major reason for the ongoing use of flawed frameworks, which lead to vulnerable applications every day. Proper training could have helped prevent major security issues like Heartbleed and Shellshock.
On the other hand, developers trained in security could help identify vulnerabilities and better understand and relay the story of what transpired if a breach were to occur. Security training would not only help developers build securely, it would create a baseline that developers could leverage to assess and understand risk. Training creates an underlying context for an organization's security maturity, leveraging developer knowledge to mark when organizations are diverging from a proper security stance.
Develop a standard of checkpoints and assign actions. In addition to training, there need to be measures to ensure processes are standardized and up to par, much like building codes do for construction. OWASP's ASVS serves this function. Establishing a system of checkpoints and assigning actions throughout development and leadership keeps priorities aligned to create effective and secure applications. In the case of a home under construction, inspectors need to periodically verify that building codes are being met by contractors to determine whether buildings are safe. Applications should also face the same scrutiny.
By auditing the application build process, businesses can establish whether they need to circle back and evaluate where changes need to be made and how to make those changes. Security bugs would be identified long before they become threats on a web-facing application. I am not advocating for a testing heavy process, but one that accounts for the need for change often found in the rapidly evolving technology market. Assessing applications would allow for organizations to pivot when needed and right size their work depending on what's lacking and what threats are found in the wild.
Ultimately, we need to nip the issue of security in the bud. Reacting to threats means is too late, so enterprises must ensure that their applications are secure as they are being developed. As I've pointed out, you can do this by mimicking the longstanding practice of building codes and inspection as well as the working structure for contractors. By implementing a system that maps security needs, provides the right training, and assesses the process along the way, organizations can ensure that their assets and customers stay safe in today's volatile security landscape.
With software projects, it seems we all too often find ourselves in a situation where we don't have enough money to do it right but then in the end, we find ourselves blowing our budget doing it over again. Imagine doing that with a home construction project!
Matt Konda is a global board member of the Open Web Application Security Project (OWASP), an online community dedicated to web application security.