However, the vast number of ‘moving parts’ in a DX initiative presents new levels of complexity. And with it, the potential for exposing your organization to cyber risk. While it’s important to manage all elements within a DX project correctly, the focus of this white paper is on applications. We discuss why you are more vulnerable to cyber risk from the moment you embark on your DX journey and the strategies you should put in place to protect your project, customers, and organization.
Understanding the prerequisites of a DX initiative before you start is crucial. A failure to get the fundamentals right will undermine the success of the entire project - and amplify the impact of any 'speed bumps' along the way, to the point of possible derailment.
As you and your project team embark on the all-consuming DX journey, you likely have a finite amount of time to achieve your transformation goals, possibly to the detriment of your business-as-usual tasks.
Given that a DX journey can take months or even years, and requires a seemingly endless investment of cash and available resources, you risk allowing your existing infrastructure to deteriorate. With all hands on deck for the DX project, everyday applications are often left to tick over unsecured and unmonitored, updates and patches are not applied, and security reviews set aside.
Sadly, a strong focus on the future state of the business leaves doors ajar for those keen to exploit any sign of neglect. It could be a bot, a drive-by attack, a malicious third party, or a disgruntled employee. Whatever the threat, it's important to remember DX is an inline business activity and until it earns its keep, you are still dependent on your existing infrastructure to help the business generate that all-important revenue.
In summary:
Your DX journey can be a major distraction, leaving your current infrastructure unsecured, and your business vulnerable. The first step to minimize risk is to protect what you have before building on it.
How do you reduce cyber risk during digital transformation initiatives?
Anything left unsecured, from networks, to endpoint devices and applications of all sizes, can endanger the larger DX project and take your focus off your end goals. So while securing your existing environment is a good first step, it's merely a prerequisite to an ongoing security strategy.
DX is unlikely to be the only technology project you have on the go at any one time. You need to consider how you are going to safeguard the business against new and unexpected risks as your DX initiative progresses.
For example, COVID-19 encouraged the rapid adoption of Teams, Zoom and other virtual meeting and collaboration tools. While essential for enabling businesses to continue operating during lockdown periods, Zoom was outed for numerous security and privacy flaws, including account hijacking and file-sharing vulnerabilities. Then there was the privacy policy which allowed Zoom to share users' personal data with third-party marketers, including Facebook. Microsoft Teams wasn't exempt either, with a vulnerability that allowed hackers to take over entire rosters of Teams accounts.
While addressing security flaws in the platform is the responsibility of the vendor, the damage done to your business in the meantime can be hard to recover from financially and reputation-wise, and is rarely adequately compensated for – if at all.
In summary:
The second step to reducing the risk of DX derailment is to immediately secure anything else that's introduced to your environment during your journey.
The decision of when to apply security to the components of your DX project can be driven by your business model and industry, your investment in legacy software, and your (hopefully non-existent) appetite for risk.
Your choices are to:
By comparison, a process of baked-in security or 'secure by design' from the outset ensures that when the code is released into your live environment, it is both secure and to standard. Which leads us to DevSecOps.
In summary:
The right time to apply security is now.
In the past, when development cycles took months or years, security was an afterthought in the development process. Now, with agile development teams, and commercial demand for shorter development cycles, security has been 'baked-in' or integrated into the DevOps process to ensure that DX projects and the like are not derailed by security issues.
This practice is referred to as DevSecOps.
A fundamental principle of DevSecOps is that the responsibility for security is delineated from one team to everybody. Security is no longer the exclusive domain of the security team. Now the developers, project owners and stakeholders, the business analyst – in fact, everyone involved in the whole pipeline of development - is responsible for building things securely.
By moving to a DevSecOps approach, you're making everyone aware that security is equally their domain, and that there's a structured framework to work within. The SecOps team is fundamentally responsible for outlining the pipeline, the environment, coaching, and providing the constraints to work within.
However, DevSecOps isn't without its challenges. There is no one are no set of definitive standards to deliver to, so the quality of output will vary, and on occasion, code will be compromised, depending on the skill levels and experience of the individual.
In summary:
While DevSecOps is best practice, it relies on everyone in the team having the same degree of knowledge, ability and skill, and the organization applying its own strict frameworks, policies, and procedures to produce quality outcomes.
While we've talked of speed bumps and derailment, those terms do understate the serious impact a cyber-attack can have on your organization.
There are three key imperatives to observe and apply throughout your DX journey:
And these apply to everything, in preparation for, and throughout your DX journey: Your existing infrastructure, any new applications, and all DX development work.
Given this, what principles should you apply to ensure your DX is approached securely?
As you start your DX journey, you will never be more aware of the finite nature of your budget, resource capacity and capabilities. And the infinite nature of cyber risk.
The traditional approach to fixing vulnerabilities or addressing security breaches is to identify what's gone wrong and allocate resources to build code to address the problem. Then test the code, get a release cycle, have it urgently approved by a change approval board, push it through to production, and then retest it. This can take anywhere from days to months even - if you need to start again from scratch. So unless you can afford to simply turn the application off in the meantime, your DX journey is effectively derailed.
Or, you could be in the position where you rely on a third-party application which has had its vulnerabilities exposed, but has no current fix. Every moment it sits unpatched is an opportunity for someone to exploit it, yet you are unable to replace it as it supports a business-critical function.
A security breach will cost your business dearly. Instead of an uptake in revenue, your budget will be diverted into fixing security issues, and opportunities are lost. Making the right decision about how you will manage security from the outset will help your DX journey become a success, not a PR crisis.
What are your options when you identify an application security issue?
In summary:
One of the challenges organizations face today is balancing the need to maintain security with focusing more aggressively on digital transformation efforts—likely with resource constraints.
To do this effectively, organizations need to enable security and development resources to focus their time on digital transformation and innovation efforts - and limit the time they’re distracted by patching application vulnerabilities.
Virtually Patching vulnerabilities can help here as it removes the vulnerability risk straight away and gives organizations time to decide when they might fix the application itself. And it means development and security teams aren't constantly distracted, so they can focus on more commercially productive tasks.
As is clear from what we have covered in this white paper, aiming to achieve digital transformation alone is simply not an option in today's cyber threat landscape. The goal needs to be to enable a SECURE digital transformation above all else.
Before embarking on your digital transformation initiatives, ensure you can reduce cyber risk during this journey.
Be ready to adopt a DevSecOps approach and implement the high-level principles for secure digital transformation detailed above - that is: monitor, verify, and encrypt everything.
Freeing up your security and development teams to focus on digital transformation - rather than chasing after bugs - is also crucial to a successful DX journey. Be sure to invest in tools which will enable your resources to apply their skills where they are most needed - delivering a secure digital transformation.
RedShield is a Managed Web Application Security Service. We help secure your perimeter, your applications, your data, and users’ sessions – at all stages of your DX journey – allowing you to continue to the finish line and arrive on time, and without risk. The RedShield approach is different – we fix your known findings, fast. We eliminate all known vulnerabilities, then we add additional protections, and then we monitor and manage future threats.