Bring in the developers: Application development
Bring in the developers: Application development
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.