Can regulatory mandates secure software development?

Software vendors have long offered incomplete and insecure products. This happens for several reasons. Speed ​​to market has always been a business priority, taking precedence over security, especially as DevOps has become the norm in software development methodologies. And software, by its nature, is easy to update and change, so some flaws or oversights might be allowed to creep in thinking “we can always fix it later”.

Unlike automakers who prioritize including security features from the start (or face the heavy hand of regulators), software makers have generally emphasized speed to market as a way to stay competitive.

But the other shoe often falls on this approach in the form of costly recalls, extensive patch programs, cybersecurity breaches, and other issues. The fix later mentality in software has become increasingly difficult in recent years with the emergence of connected/IoT devices which are harder to keep up to date and have a greater impact. Connected CCTV cameras, for example, are frequently hunted and exploited on the Internet to spy on people. Internet of Things (IoT) devices operating in dams or nuclear power plants can now be hacked (as seen at the Bowman Avenue dam in New York, or three utility companies in Ukraine hit by BlackEnergy malware) . And, from one end to the other, the cost of data breaches keep going up.

A White House andexecutive order (EO) from 2021 is also putting pressure on software makers, DevOps and DevSecOps professionals to improve quality, with a mandate for US federal agencies to mandate secure software development through their contracts and acquisitions as part of efforts to secure the software supply chain. The main difference between this effort and previous attempts such as FISMA is visibility into the software development process.

The focus on secure software development is a step in the right direction, but ultimately it’s still up to industry rather than regulators to change the mindset towards software creation. secured from scratch.

Technology is faster than money orders

OE represents a shift in the landscape, requiring not just secure products, but secure development practices. Although it officially applies to federal civilian agencies and their contractors, federal regulations and other government mandates often become global standards, as happened with the General Data Protection Regulation (GDPR), the European privacy and security law.

But regulatory mandates are not enough. They often evolve too slowly to be a real solution, especially in a software development environment that is gradually moving towards more agile and fast-paced environments where continuous integration and continuous delivery (CI/CD) are the norm. Timelines for new regulations generally require a two-year implementation window; if a business is already using an applicable product, it can take up to five years before it is required to be in full compliance, such as in the payments industry. By then, the key elements of industry best practices have already changed. Simply put, technology is moving too fast for regulators to keep up.

What’s more, the regulations themselves could ultimately fail if they are perceived to have a high cost of compliance. This is especially true if the technology used in the software development lifecycle cannot keep pace with compliance needs. In support of OE, the National Institute of Standards and Technology (NIST) has published Special Publication Project (SP) 800-218and, as is routine, accepted open public comments. Comments from industry consortia in these situations often include considerations of the costs of implementing new regulations and can sometimes lead to mitigating certain aspects, arguing, for example, that the new regulations place an unfair burden on small and medium-sized enterprises. companies. The final set of regulations can sometimes leave the door open for ways to address compliance without addressing the issues that led to the regulation in the first place.

For example, the California Consumer Privacy Act (CCPA) is widely hailed as the strongest set of privacy protections in the country, but it still has its weaknesses. The most frequently cited weakness is that the law makes extremely difficult consumers to take advantage of the new regulations when they feel wronged.

The industry must make it happen

Ultimately, it is up to software manufacturers and industry to improve the security of their software. They should adopt best practices to embed secure procedures in the design, development, testing and validation of new software, as well as its deployment and use. NIST Secure software development framework is an example of advice taken from recommendations by groups such as BSA, OWASP and SAFECode. Industry groups, such as the International Organization for Standardization (ISO), could adopt development and certification standards similar to those universally accepted UL standards for electrical products.

The growing demand for secure development necessitates a substantial change in attitudes towards the way software is created. Many of these things can be implemented more easily if organizations invest more quickly in adapting new technologies.

The threat landscape has become too sophisticated and pernicious for the problem of insecure software to be ignored. Fix it later is no longer a viable option if organizations want to protect their networks and, in particular, their data, which has become the backbone of operations across all industries. While regulatory mandates are helpful, the job ultimately falls to the software industry itself and its consortium of like-minded people who are bridging the gap between developers and competing companies’ DevOps teams to ultimately deliver what is best for consumers.

Comments are closed.