Navigating ICS Security: Best Practices for ICS Decision-Makers

Image

As a security consultant, I’m not going into an environment to design and build an organization’s network from the ground up in most situations. For the majority of the time, I’m working with legacy environments where some old technologies might be phasing out and newer ones joining the mix of solutions. In the case of one environment I went to, for instance, it was all of this plus a variety of Shadow IT that was so business-critical that the operations team was anxious about investigating at the risk of causing disruption. To add complexity to this issue, organizations with Industrial Control Systems (ICS) (therefore Operational Technologies (OT)) that are mixed in with their Information Technology (IT) have to balance an even more complex landscape. If any of this sounds familiar, don’t worry. Whilst it can be frustrating, it’s not impossible to improve. Often, we have heard the ‘basics’ of security—more recently, security ‘foundations’ because honestly, the word 'basic' gives the illusion of simplicity, which it is not. Instead, I prefer discussing it as the resilience foundations of IT/OT infrastructure. In order to break it down into distinguishable pieces, we can focus our conversations and planning within the following six points:

1. Documentation and asset management: To start off, you need to understand what is on your network. This is as critical as data classification because it’s a central point of embedding resilience. What is required to actually be resilient? Identify the hardware and software assets and then realize the capabilities of said assets. For example, legacy systems may be limited to passive scanning such as listening to the existing communications vs. poking them with questions. Identifying these systems that must be restricted is a key piece to step three: ability to separate.
2. Restrictive mappings: As I noted in the first paragraph, I rarely am called in to create the initial design. I more often re-design the environment in a cost-effective and resilient way. Therefore, after assets have been identified and recorded, we sometimes have to listen in and see who/what they’re communicating with. Just like mapping out a person’s workflow, we need to identify that system and/or services workflow. Once this has been completed, we can start to reduce the access to unneeded resources. On top of understanding what access they need in an ICS environment, you will also need to identify the capability of said systems by adding in restrictions and even tailoring the allowed forms of monitoring on some.
3. Segregation of assets and networks: A potential surprise to some, not all areas of the network require communications with everything else. Further still, some areas actually would benefit from complete lockdown from the internet. This sounds like the opposite of what we often assume, especially regarding the direction that IoT has thus far taken us, but once you identify your assets and requirements in step one and two, you can begin to effectively map out the future of the network in a much more restrictive and resilient architecture by focusing on the in-depth approach to security. Once you know what systems and restrictions you have, you will be working within the Purdue Model and what connections your systems require to finally align the design. Such an effort must include the processes on how to migrate existing setups to this new more resilient solution.
4. Configuration and change management: Would it surprise you to hear that, according to the 2019 Verizon Data Breach Report, errors are the fourth highest cause of a breach? It wasn’t a massive surprise to me, as I have often seen configurations within organizations that are extremely concerning. Legacy tech from previous operating system versions that are changed without documentation, temporary solutions that are never removed, and more, just to name a few examples. Not to mention the configurations that are simply accidental or incorrectly applied. Authorized configuration changes should always be documented thoroughly along with the restriction of unauthorized changes. In order to do this effectively, you must have a robust change management process in place and maintain it.
5. Patch and vulnerability management: Whilst completely separate processes, patch and vulnerability management work together quite closely. Consider this: every time an issue is found, the vendor comes out with an update; each time a system patch is installed, the automated vulnerability scanner should be checking to see if this accidentally introduced another issue. You should, therefore, consider it as a vulnerability and patch circle.
6. Resources: When hired to assess an existing environment, I am also rarely alone. Completely understanding these processes and systems requires engaging with the persons who are working on them. It requires senior management to make the final decisions and sign off on remediation actions, for instance, and it requires operations teams to be able to maintain this more secure configuration after I have left. It requires all of this work, on top of these professionals’ daily roles. When identifying required changes and building road maps to the target operating model, it’s important to realize that this is going to require not just system changes but also people resources. Further still, once these new systems and configurations are implemented, the new processes need to be documented; in some cases, they may require up-skilling of teams.

I remember someone telling me earlier this year about a compliance requirement they worked within years ago was all organizations had mandatory two firewalls implemented. Instead of a detailed configuration of both, separate audits, and robust solutions - it led to one configured firewall, and one set to pass through, which I believe all of us can agree was not the intention of the regulation. When I think of security in-depth, I think that many requirements and designs were originally created with the best intentions in mind. Over time and with a gap between our legitimate needs, system restrictions, and ease of use, however, yesterday’s security efforts have proven to be insufficient. Which, to me, is why every organization could benefit from steps one and two of the above. Re-assess what you have. I promise that even your environment has shadow IT. Even if it’s small, it exists. Most importantly, re-assess what each workflow doesn’t require access to. If you haven’t heard, there’s a ‘Principle of Least Privilege’ that says give as much access as required to complete a role but no more. This can apply to all systems, accounts, and services. Understand their requirements and their access needs before removing all else. Read the latest Tripwire ebook Navigating Industrial Cybersecurity for more in-depth knowledge regarding ICS here.

Further reading in this series by Zoë Rose: Navigating ICS Security: The Threat Landscape Navigating ICS Security: The Value of Frameworks Navigating ICS Security: Having your Action Plan Ready

Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.