<img height="1" width="1" src="https://www.facebook.com/tr?id=1879927395628828&amp;ev=PageView &amp;noscript=1">

The missing link in software security is . . . REMEDIATION!

 Jun 19, 2017 10:35:00 AM |    AsTech
Grand Canyon

We have tons of headlines for web sites and applications being hacked: celebrities’ accounts hacked, movies and scripts being pre-released, identity theft, progressively record-breaking credit card breaches. As a computer security consultant, I’m asked by people all the time, “is my computer safe?” Answer: “nope.”

If I have time or they buy me a beer, I try and help. Anyway, here is the state of application security:

Question: How many men does it take to change a lightbulb?

Answer: One but it takes 2 years of nagging to get it done.

Most security people will get the analogy. In one sense, we’re like Dean Wormer in Animal House. Security: “If you don’t fix the vulnerabilities, we’ll put you on ‘Double Secret Probation’”. A developer puts a couple of pencils in his nose and the meeting's over.

I honestly don’t blame development for this (yes I do, but that’s beside the point). Secure programming is not an inherent part development standards, processes, or culture. Secure programming is largely ignored in college computer science classes. During a conversation with two high level CS professors responsible for curriculum at a very large university, one of them told my CEO “undergraduates aren’t ready for secure coding concepts.”

We disagree.

If, as a developer, you bring up securely programming an application, you get blank stares and then everyone gets back to discussing “real” issues. Also, developers generally don’t think like hackers or even testers. Testers are great at breaking applications. It’s what they do. Testing for security is a whole different world and different mindset. Also, when you are developing, you are thinking in a straight line. I need to get this to do this. With the schedules being what they are, developers rarely ask how their code could be attacked or is my code safe. Also, on both of those questions, they are for the most part clueless. “There is trained and untrained” and our developers are for the most part untrained.

So if you want a reason why SQLi is still number one on the OWASP top ten, look no further. We have parameterized queries, stored procedures (these can still be used for SQLi if not done properly) and frameworks that used parameterized inputs. Ditto for XSS. When in doubt or not in doubt, encode. Like any development, secure programming is subject to the 80/20 rule. 80% of the fixes are relatively easy. 20% take a little thought and research. The problem with both the 80% and the 20% is that you need to know how to address them.

The volume of vulnerabilities in the initial scan of almost any application is going to feel overwhelming. If you’re teaching developers, you have their attention early when they learn hacking/security (geeks love hacking). That lasts until they see the work that needs to be done in their own application and perceive security as a competitor for their implementation time. So there is a large expanding gap between awareness of vulnerabilities in the code and having secure code. That is application security’s missing link. Honestly, most companies are not going to fill that gap in-house. It’s difficult to get a bank vault using the same process you used to build a rocket ship. My suggestion is to bring in help. Someone that can fill the gap. Maintaining secure code is easier than making your code secure. Once the code is secure, secure coding can be part of the SDLC. The goal for integrating security in the SDLC should not be just statically or dynamically scanning the application (this is important but it is not an end). The goal should be to integrate security and results from secure coding tools into the development process itself. That means getting the vulnerabilities into the development bug tracking system. Suggesting a dump of 10,000 vulnerabilities into JIRA or any other bug tracker is a sure way to send development staff running for the exits, but entering new vulnerabilities as they come up is perfect for Waterfall or fast-moving Agile development. The key is to build security into the program so that it feels natural.

When developers can produce secure code without it feeling like they are changing tracks or “wasting” time, application security will be a given instead of a goal and the headlines will have to find fresh meat somewhere else.

Topics: Application Development

Want more of the AsTech Blog? You got it.
Blog subscribers get email updates twice a week.