Managing Dependencies
Often times when I design secure infrastructure solutions, I find dependencies. Typically, we aim for independent solutions to ensure reliable and stable environments to keep our business running and customers happy. This is particularly important when working with critical infrastructure providers in the electricity, water, and heating sectors which we all rely on and depend upon ourselves.
Island mode often refers to a state in which a system is disconnected from the Internet or the IT network, particularly from an OT perspective. The key concept is identifying the bare minimum required to keep the business and its services operational. This, of course, places an extraordinary burden on the company’s operational resources. The question is whether such a situation is acceptable, or if investments should be made to reduce this burden before deciding to enter island mode. Perhaps some tooling and automation could help here. Know, though, that in order to find the perfect balance between running everything manually vs. building “what-if” solutions, you’ll need to make some tough choices, because:
Every decision obligates
It sounds simple, but be aware that all choices have consequences.
For example:
- Having useful documentation requires you to keep it up-to-date
- Not having documentation is a recipe for disaster
So, with documentation that everybody needs you should ensure that it is available, usable and manageable.
Other examples:
- Disaster recovery plan
This is the mother of all dependencies. What is needed to bring the business back to a working state following a ransomware attack? And I’m not talking about just restoring some data, but what is needed in order to being able to do that? Who should do it? How fast? Which system needs to come up first?
All of the processes involved in such a scenario must be documented before it happens. I always urge my customers to have a disaster recovery plan and re-visit it and rehearse it once a year.
How do you access the information you need when all your data is unavailable and potentially gone?
Besides the terrifying ransomware attack scenario there are smaller things that are important to the general design of an independent infrastructure. Having an out-of-band network is one of those things. Here you create a parallel network that allows you to recover, troubleshoot, and manage your infrastructure in case of incidents that otherwise would require you to drive to a location with a console cable to gain access to a single device at a time. With OoB networks we have lots of dependencies. To begin with how will you securely access the OoB network when/if your production network is down? Which services could you need? Internet, VPN, file services?
I can’t help but compare these DR plans, out-of-band networks, and other measures that keep the business secure and afloat during emergencies to buying insurance. We all need some level of coverage.
Private companies generally aim to be profitable - making money and reinvesting to grow. This often means keeping costs low and making bold, sometimes risky decisions. Choosing not to do something is also a decision, and it carries obligations. Naturally, no one wants to be personally responsible, especially financially, for such choices. Therefore, proper documentation is essential to record the design decisions made - not just the technical ones, but also the business-relevant decisions that shaped the technical design. Having this documentation in place ensures compliance, both internally and with externally imposed regulations. NIS2, for example, requires documentation of network segmentation and related measures.
I should also mention best practices. Use them when applicable, but not at any cost. If there is a specific business requirement of something and best practices doesn’t support the requirement, then deviate and design accordingly. Be aware of dependencies and document not only the solution but why you ended up going that direction.
Dependencies are a major topic that many tend to overlook in day-to-day operations. My advice is to always keep them in mind. This applies to everyone, and remember: dependencies are relevant to all decisions - and every decision carries obligations.
