The balance between Information Security (Infosec) and a good Developer Experience (DevEx) is a crucial aspect of modern-day businesses. Whilst Infosec is crucial for the protection of sensitive data and intellectual property, good DevEx helps to increase productivity and employee satisfaction, and hence also retention. When the balance isn't quite right, it can lead to unapproved technology resources, also known as Shadow IT, which presents a significant challenge for both Infosec and DevEx.
Shadow IT: welcome to the dark side
Shadow IT refers to the technology resources created by employees that are not part of the official inventory. These resources are created without the approval or knowledge of the IT department. They can range from simple applications and software tools to complex IT infrastructure, and may also include physical devices such as smartphones and computers. Shadow IT often emerges as a result of employees seeking to solve a particular challenge or improve their productivity using tools that are not available or approved by the IT department.
Corporate processes and frameworks, especially around Infosec, are not always the most convenient to follow. Who hasn’t faced a situation where a task that should have been easy turned out to be amazingly complex thanks to company restrictions? In such situations, one faces a dilemma: should I follow the standards and procedures even if that means failing to deliver on time, or should I find a creative solution to be able to reach a successful outcome. The latter might seem reasonable, but what if it led to the unintended introduction of malware inside the company's infrastructure?
The first step to avoid this kind of issue is to work with employees to identify the reasons why they would like to turn—or are already turning—to Shadow IT in the first place. Maybe they have the perception, real or imagined, that the existing tools are too cumbersome or don't meet their specific needs. Whilst differences can be overstated, it is equally true that different people have different needs, and it's especially true in a company with multiple departments. When not taken into account, these sorts of differences can lead to frustration.
By addressing these concerns and finding ways to improve the official IT offerings, companies can help reduce the temptation to use unauthorised tools. During his recent WTFinar Designing for Habitability, Sam Newman explained that it is also important to propose solutions to employees instead of trying to force them to follow a certain route. This way, the proposed solution will be better as it will need to be thought of as a product trying to reach a specific goal, and employees will be more likely to actually use it. As Sam puts it:
“Develop your internal platform in exactly the same way you would develop a customer-facing product. Talk to people, understand what they want, sell to them, help them understand why you might be able to help them. And if you can't help them understand why you can help them, maybe you are not helping them, and change what you're doing.”
Standardising technology solutions can help organisations provide a consistent and secure IT environment, with good support for employees. It also makes things easier to manage on the IT side. But, as mentioned earlier, too much standardisation, particularly when imposed from on high or across departments, can lead to frustration which will negatively impact developer retention. In some cases, the best solution may be to embrace the use of certain Shadow IT tools or devices and make them part of the official IT landscape. This might mean adopting and supporting a tool that was previously used unofficially, or sanctioning the use of such tools or devices without direct management from the company, i.e. without any IT support.
Of course, any time a company decides to embrace Shadow IT, it needs to do so in a way that ensures security and compliance to any relevant regulations. That might mean setting up rules around which Shadow IT tools and devices are allowed and which are not, as well as monitoring and auditing the use of those tools to make sure that sensitive data isn't being put at risk. Those rules and policies must be communicated to employees and enforced to ensure compliance. This way, companies might be able to allow employees to use personal devices for work purposes, but only if those devices meet certain security standards, such as being password-protected and encrypted.
The importance of education
You might be thinking this all sounds nice in theory, but in reality some somewhat painful processes can't be avoided. And you’d be absolutely right!
It is essential to recognise that Infosec and DevEx are not always in perfect alignment. There may be times when security measures need to be more stringent than one would like, such as when handling sensitive data or complying with regulatory requirements. In such cases, it is important to communicate clearly with employees and help them understand why the measures are necessary. Providing context and showing the potential risks of not following security protocols can help them see the bigger picture and recognise the importance of maintaining a secure environment.
That said, whilst timely explanations are important, they will only be useful if everyone in the company is generally aware of Infosec, the core concepts around it, and why it is so important. Providing education and training on the risks associated with Shadow IT and the importance of Infosec in general can be effective here. Luckily for us, Security Awareness Training is a concept that is, slowly but surely, becoming more broadly accepted as of paramount importance to avoid being hit by ransomware, or another type of data breach, that could lead to devastating consequences.
New solutions in the field propose an approach that is much more dynamic and interesting than in the past, avoiding the traditional death by PowerPoint. This can lead to tremendous results whilst reducing the amount of time spent by employees on training, as well as significantly improving their satisfaction and, again, helping with retention.
Platform Engineering: just a buzzword?
In the software industry—which arguably touches almost all companies these days, at least partially—adopting a Platform Engineering approach to software development can help to streamline the development process whilst also incorporating security and compliance from the outset. By building security into the development pipeline, teams can catch vulnerabilities earlier in the process and avoid costly rework later on, which is more commonly referred to as Shifting Left.
So, it seems this would improve DevEx and Infosec, right? Right?
It would indeed! But, as you might have imagined, there is still a catch. (sorry)
First, let's make things a bit clearer. What is Platform Engineering? Why are we not talking about DevOps? There is no consensus yet on a proper definition for these terms and different people might have a different understanding of them. For the sake of this article, we'll define DevOps as a development approach that aims to improve the collaboration and communication between the development (Dev) and the operations (Ops) teams in an organisation. It is a set of practices and cultural values that enable teams to work together more effectively to deliver software applications and services quickly, reliably, and with high quality thanks to, among other things, automation. On the other hand, we will define Platform Engineering as a practice following DevOps, that involves designing, building, and maintaining the foundational infrastructure and systems that enable the development and delivery of software applications and services. This includes the design and implementation of hardware, operating systems, networks, databases, and middleware, as well as the deployment, configuration, and monitoring of these systems. Its goal is to create a reliable, scalable, and secure platform that can support the delivery of software applications and services across an organisation.
Where is the catch then? It all seems fantastic!
It all seems, and it all is, if implemented properly. But getting there isn’t easy., As with so many things in Cloud Native, it doesn’t just require technical changes, but also cultural ones. As you can imagine, changes of such magnitude are always a challenge, and can feel rather like climbing Mount Everest when trying to implement them in older and/or larger companies that already have (very) many processes and practices in place. If this is your situation then I strongly recommend reading the book Cloud Native Transformation, by Michelle Gienow, and CS co-founders Pini Reznik and Jamie Dobson. At the time of writing, it is available as a free download.
Implementing automation tools and processes embedding Infosec can help reduce the burden of manual security checks and allow developers to focus on their core tasks. Providing easy-to-use security tools and interfaces makes it simpler for employees to follow security protocols and stay in compliance.
Finally, it's important to measure the effectiveness of any Infosec or DevEx initiative and make adjustments as necessary. Regular feedback from employees and stakeholders can help identify areas where improvements can be made, and data on security incidents and DevEx metrics can help track progress and identify trends.
When it comes to balancing Infosec and DevEx, we should keep in mind that the two are not mutually exclusive. In fact, they can—and should—complement each other. Finding the right balance requires a collaborative approach that involves all stakeholders, from the IT department to business unit leaders to end-users. By working together and maintaining open lines of communication, companies can create an IT environment that is both secure and flexible, supporting DevEx while minimising Infosec-related risks.
The way to find this balance is a perilous quest, but it is a worthy one that will pave the way to painless days.
Previous article
