Stop muddling through and start working under architecture
Last year showed how vulnerable our infrastructure sometimes is as a result of cyber attacks. For example, PETYA caused non-functioning cranes at Maersk's container terminal, and non-functioning sorting machines at TNT. Also recently, some banks have proved inaccessible due to a DDos attack. Until now, mostly technical and related organizational measures have been taken to deal with such cybersecurity threats. However, it is slowly dawning on us that reactive measures will not be sufficient in the future if we want to guarantee the continuity of such infrastructure. So how do we really get our Operational Technology (OT/ICS/SCADA) properly secured?
Long-term vision
Many ICS/SCADA systems were developed in the past to perform a task. Today's ICS/SCADA systems have mostly been further developed based on designs of their predecessors. Never was any thought given to how the ICT landscape around these systems might change. It is now clear that change is rapid. This requires a clear long-term vision regarding ICS/SCADA systems and their design for: links with office automation, and thus with the Internet, links with ERP systems, wireless control; all application areas that were not included in a design 10 years ago but are now proving increasingly relevant! A long-term vision of how ICS/SCADA systems should function in the future is therefore indispensable. Such a vision leads to new (functional and technical) requirements that should be included in new tenders. Of course, this also includes requirements for security and continuity.
Working under Architecture
- In the ICT of office automation and automation of large systems with an administrative function, it has been normal for years to work under architecture. This means that the architect thinks about which functional and technical building blocks are needed, how they fit into the long-term vision, what the mutual coherence of the required systems is, which links are needed and with which standards the systems function. In short: architecture provides a good overview in the coherence of all ICS/SCADA systems. Working under architecture has a number of important advantages, I will mention three:
- Business requirements, IT/OT requirements, development, procurement, management and maintenance of systems are well aligned; The building blocks that (will) form the ICS/SCADA systems are thus easier to develop further, because the architect has thought in advance about decoupling them into 'smaller' and 'adaptable' units that can continue to work together. In the ongoing development of these 'adaptable units,' lifecycle management plays an important role. Suppliers and customers are slowly adapting to this, such as with the development of building blocks and central network solutions for control and logical access, logging and anti-malware. Breaking it up into smaller units makes it possible, to also work with other vendors who provide a solution for such a unit. In short, less vendor lock-in.
- And last but not least: A better security of the ICS/SCADA systems is possible under architecture; because it is easier to think in advance, how the threat images can be translated into technical solutions, in order to mitigate them.
Working under Architecture, but how?
Working under architecture is not new. This means that there is already a lot of experience, just not (or less) in the ICS/SCADA corner. A well-known framework for this is the architecture framework TOGAF. TOGAF provides a structure and governance processes through which the architecture can be governed. However, it is necessary to supplement TOGAF with best practices and standards for architecture and governance, as we already know from the ICS/SCADA world. Consider NIST (SP800-82), Center for the Protection of National Infrastructure (CPNI), NCCIC/ICS-CERT and TOGAF, incorporated into one toolbox.
Related articles
