Securing other peoples software - Part 1

Spend enough time working in any industry – especially utilities or manufacturing – and eventually, you’ll find yourself tasked with deploying someone else’s software.

In my current field, power generation and distribution, this software usually comes bundled with physical technology. The primary focus is almost always on the physical asset itself; the software is a secondary concern, a means to ensure the physical technology achieves the intended outcome.

For IT Architects, Security Engineers, and Operational Systems Specialists, this presents a major responsibility. You are tasked with not only deploying the software in a way that meets business needs, but you must also unpick the software’s weaknesses and manage the corresponding cyber risks that come with it.

Don’t get me wrong, this work is incredibly rewarding! Helping to build new business capabilities is what motivates many in this industry. For me, seeing inanimate systems come to life, embedding new technologies, and helping my colleagues work smarter and more efficiently is what gets me out of bed in the morning!

So, how do you securely deploy someone else’s software? In this post, I’ll walk through some of the key questions I typically consider. In a follow-up post, I’ll share a practical example related to a third-party battery energy storage system.

Here are the questions I typically ask myself each time I think about onboarding new software:

1. What is the system capable of doing, who will use it, and how does it align with the organisations strategy?
2. How could this system be intentionally or unintentionally misused (i.e. what are the risks)?
3. What IT security controls can be applied from our existing toolbox?
4. What new and/or novel IT security controls might we need to address any residual risk?
5. And at the end of this process, will the system we’ve designed still provide the intended business functionality at a reasonable cost?

Function and Form

First and foremost, no business deploys software because they enjoy shepherding computers – software is there to fulfil a business function. To fulfil that function, it (software) typically requires some level of user interaction.

Your first task will be to understand what function the software plays within your business, how it is going to be used, and by whom it will be used. Only once you’ve built a clear understanding of the form, function, and use, can you then start to build a picture of how the system could be misused.

Understanding the Risks

Every system carries risk… Your job is to NOT get lost trying to quantify every possible risk.

The FAIR model is particularly helpful: focus on what’s probable, and less on what’s possible. Too often, I see analysts fall down the rabbit hole of endless “what if” scenarios. While creative thinking is important to ensure we’ve covered all probable scenarios, it’s vital to stay grounded.

Use tools like the MITRE ATT&CK framework, industry threat intelligence, and your knowledge of the business to identify realistic threats. Think about likely vulnerabilities, the actors who might intentionally or unintentionally exploit them, and the odds of those two aspects aligning.

At this point, you might ask “Should we quantify and record the unmitigated risk level, even if we know they will always be mitigated?” My answer is yes – Tracking both the unmitigated and mitigated risk levels is important because it allows you to:

1. Quickly identify risks in your risk register that have a high unmitigated score and should be monitored more frequently to ensure the corresponding controls remain effective.
2. Highlight risks with a high unmitigated score that are being successfully reduced, demonstrating the value of maintaining a cyber risk management and assurance program (some organisations have a short memory, and forget the value of a good cyber programme).

Applying Standard IT Security Controls

Your business must have a set of baseline IT security controls — tools that are applied consistently across all systems because they’re both effective and cost-effective. Controls in your toolbox should include:

• A change control policy and the processes, culture, and behaviours that flow off the back of it.
• Defined RACI models for each new IT system and documented standard operating procedures (SOPs).
• Vulnerability management and regular patching practices – again, with the culture and behaviours that this practice drives.
• Access control policies with strong authentication requirements and following the principle of least privilege.
• Network segmentation to isolate systems that don’t need to communicate with one another.
• Ensuring audit logging is enabled, and log are being written to an immutable store.
• Running an endpoint detection and response (EDR) system.

By 2025, every mature organisation should have these basics in place by default.

Considering Novel IT Security Controls

If your organisation is mature, you should rarely need to look beyond your standard IT controls toolbox to manage risk. However, with ongoing advancements in AI, the increasing reliance on SaaS, and the convergence of OT and Cloud environments, there’s a growing need to carefully consider new controls, ones that may be novel to your organisation, to better manage cyber risks.

When thinking about novel controls, stay focused on the risks you’re trying to mitigate. It’s easy to get swept up in flashy vendor demos, but remember: security tools must address real risks effectively, with minimal ongoing human effort. Balancing Functionality and Security

Wrapping up

Lastly, when you think you’ve arrived at an approach that’s workable, step back and evaluate the bigger picture: Does the system still deliver its intended function? Do the security controls I’ve introduced unreasonable burdens on end-users? administrators? the security team?

Cyber risk management is all about balance. Some risk is inevitable — and that’s okay. Don’t become so focused on eliminating every risk that you end up damaging budgets, overloading teams, or losing goodwill within the organisation. Two can be easily repaired, the other cannot.

Watch this space. In my next post, I’ll work through my organisation’s deployment of third-party software for the management of a grid-scale battery inverter fleet. Fascinating technology when it works well, but some serious risks if it were ever to be misused.