IDG Contributor Network: Why executive orders aren't enough to fix cybersecurity

Cybersecurity has spent a lot of time in the national spotlight over the last year, with major breaches revealed at Yahoo and the DNC, not to mention the thousands of connected devices being repurposed into botnets to take down the internet. But all this rising awareness hasn't yet translated into serious action from lawmakers to address the new wave of cybersecurity threats, particularly in terms of application security.

An executive order may be pending, but what I have seen from the previewed drafts so far is little more than history repeating itself. Rather than accept the work of the previous administration's review on cybersecurity, President Obama ordered a 60-day review in order to get his own perspective. Current drafts of this executive order look like they are following the same path.

Unfortunately, identifying the vulnerabilities in our country's infrastructure is the easy part. Making effective recommendations that organizations will be able to follow is the challenge. A general directive will do little to help the need for a more granular approach to high-risk spaces like the application layer.

What cybersecurity legislation looks like now

The good news is that there are certain regulatory groups headed in the right direction. One such group is New York's Department of Financial Services . It should be commended for getting the ball rolling on this front by proposing stricter cybersecurity regulations that include several standards surrounding application security.

Once it is final, the regulation is scheduled to go into effect on March 1, 2017. In terms of application security, covered entities will have to:

Implement a cybersecurity program with written policies and an audit trail Identify cyber risks and conduct penetration testing at least annually and vulnerability assessment at least quarterly Secure applications by ensuring the use ofsecure development practicesfor in-house developed applications, and implement procedures for assessing and testing the security of all externally developed applications Assess risk to non-public information and information systems accessible or held by third parties, and conductthird-party security assessmentsat least annually

These application security regulations will be looking at the full software lifecycle -- from development to QA to production. We are finally seeing a shift away from thinking of AppSec as only a QA activity and right on time.

For instance, with the increasing adoption of development practices like devops, trying to tack security testing on to the end of the development cycle is no longer feasible. We have to start baking security into early development stages. At the same time, it's unrealistic to think that perfect prevention is possible. We also need to implement security controls in apps in production.

These regulations are also noteworthy in their focus on the safety of applications purchased through third parties, not just those developed internally. The speed of innovation today means that developing all software from scratch in-house is not a sustainable model. Organizations will increasingly rely on third-party applications and code and will need to assess the security of this code in the same way they assess their internally developed code.

What we can do better

But despite the progress, there's room for improvement with these regulations. Namely, we need more details about what good application security looks like. Rather than simply telling organizations what types of testing and controls to implement, we need to give them an end goal, or specifics about the types of attacks they should be preventing.

Just as food safety regulations give organizations guidelines to avoid specific food-borne illnesses, application security regulations could provide guidance for avoiding the most common types of attacks. This is grossly oversimplified, but some food safety regulations follow this general outline: "This is what causes listeria, here are steps to avoid it, and you will be held accountable if the food you manufacture causes listeria." Application security regulations could follow a similar model. For instance: "This is what causes SQL injection, here are steps to avoid it, you will be held accountable if your customer data is breached through a SQL injection attack, and you haven't done everything reasonable to eliminate this threat."

Ultimately, regulations forbidding all types of attacks aren't realistic, or even possible. But there are plenty of attacks that we know how to prevent, and aren't even all that complicated to prevent. Application security regulations should at least provide guidelines about how to avoid the most common and preventable types of attacks -- such as SQL injection -- and offer a picture of what good, effective applications security looks like. In this way, we'll start to move from regulations that organizations forget after checking the box, to regulations that make a real difference in securing organizations and protecting data.

This article is published as part of the IDG Contributor Network.Want to Join?