Businesses are implementing open source governance programs to ensure data protection and compliance with Article 25 of GDPR.
With GDPR coming into play in May 2018, companies that do business in the EU are faced with the prospect of fines and damaged reputations if they cannot prevent vital corporate and customer data from falling into the wrong hands.
However, while innovation and speed may be critical, they cannot come at the expense of risk management, which has become a huge challenge for developers and the growing DevOps community. Now more than ever companies are reliant on open source software to drive their business processes, applications and even offerings, consequently quality assurance and software supply chain management have become vital to prevent organisations being exposed to massive risk.
The situation has been compounded by companies having to comply with new regulations, none more so than GDPR (General Data Protection Regulation) that will strengthen EU data protection legislation and subject businesses to severe penalties should they fail to comply. With the fines for a data breach standing at $20 million, or 4% of annual turnover (whichever is higher), the protection and security of data is now of paramount importance for businesses.
The severity of the potential fines was put into perspective recently when Equifax delayed the public disclosure of a massive security breach by a month. Under GDPR rules the credit provider would’ve been fined $60 million for withholding details of the breach for that amount of time. In fact, GDPR demands businesses inform the public within 72 hours. A security breach can come from anywhere and may be the result of a malicious attack but there is an issue that runs much deeper and that is to ensure software and applications are secure throughout their lifecycle.
An issue that is covered by Article 25 of GDPR, which states data protection must be by design and by default, which means that businesses need to implement data protection measures when they’re designing IT systems and infrastructure from the outset, rather than adding them later.
This has serious implications for how businesses manage their software supply chain effectively, it has to be continuously monitored closely to ensure quality assurance and to identify any flaws or vulnerabilities. There are vast pools of open source components available to developers and DevOps teams through numerous open source projects.
However, there is no standardization of components and quality control is left to the supplier and while some suppliers are active in addressing known vulnerabilities, the majority of suppliers are slow to remediate issues or in some cases fail to remediate issues altogether. Consequently, businesses need to actively manage the open source projects they engage with. This process will ensure they have greater awareness of supplier performance and be in a better position to select the open source components required to build software applications and comply with Article 25.
Open source at the heart of the enterprise
What many organisations may not be aware of is that open source components comprise up to 80% of the makeup of enterprise service software applications. Whilst this means that there is far more opportunity for collaboration and development internally, there is an inherent security issue when it comes to creating new applications within the business. For example, a 2016 analysis of 1.8 million Java components housed in the Central Repository revealed that 5.9% contained a known vulnerability. In short, ensuring security and compliance with GDPR at every stage has become more important than before. GDPR becomes fully implemented in under seven months, which doesn’t leave a lot of time for even the most agile and forward -thinking of enterprises to get compliance programmes in place, apply them, and make changes where needed to fully protect the data that they hold.
This leaves organisations in a complex state of affairs: on the one hand they can’t afford to stop providing the services they do whilst they analyse, update, and redeploy all aspects of their applications, but they also need to secure themselves enough, or have a way of knowing which parts of their software is vulnerable, in time for GDPR to be fully implemented. The question, is which option do they chose? They have to choose one, quite simply, to avoid the colossal fines that will be coming their way if a breach occurs.
All of a sudden, Article 25, the Privacy and Security by design clause in GDPR, has become of critical importance to enterprises, and therefore to their entire software supply chain. Implementing the correct governance programmes to float on the rising tide of IT Risk management will be critical for businesses going forward into next year.
Moving security to the left, all the way to the left
From the beginning, security needs to be ingrained when it comes to developing and deploying new pieces of software. It needs to start with the developers, whether in house or out of house, and kept in a continuous loop when analysing and monitoring software throughout its lifecycle.
Without sounding too much of a harbinger of doom, if companies want to avoid financially and reputationally costly breaches, they’re going to have to perform continuous health checks on their applications to see where may need to be altered to become compliant. Software doesn’t age well after all; think milk rather than wine.
This way organisations can start the process of software development, whilst keeping security at front of mind from the very beginning and then throughout an application’s entire lifecycle, to make sure that their open source – driven services are secure.
So how can they do this? There are four things to consider:
1. Developers need to source secure components from the start of design, and use parts that meet security and compliance rules of their own organisation.
2. If a component becomes insecure later in life, they need to have access to intelligence about what alternative versions of the component are available to them, in order to update it. The sooner they have that intelligence, the faster their mean time to repair.
3. Web application firewalls, network and endpoint security tools, and even hardened operating systems are not enough to defend against attacks that are aimed at the application layer and exploit popular and widely used open source components like Struts2.
4. Automated governance tools must also be evaluated throughout the application lifecycle, so that security is integrated into every single phase of the software development life cycle.
The Information Commissioner’s Office states in their FAQ that “In light of the tight timescales for reporting a breach – it is important to have a robust breach detection, investigation, and internal reporting procedures in place.”
This is DevOps in practice, and making its way into regulation. For Equifax it was too late, but for organisations the world over, there is the chance to get the correct and robust software supply chain monitoring procedures and governance programmes in place, to help avoid another catastrophic breach such as this one.
To thrive in our application driven economy, modern IT teams must therefore continue to accelerate their own innovation through the adoption of all the good that open source software has to offer, but also have continuous governance programmes in place to monitor quality of components and automate the enforcement of security policies to bring themselves into line with GDPR.
Article 25 stipulates that data protection shouldn’t be an afterthought, it should be a core business process and going forward all companies dealing with the EU will need to ensure this critical process is at the very heart of system design.
Source: Information Age