It is true that performance requirements, protocols, network architecture and priorities of the cybersecurity triad (confidentiality, integrity, available) do not align, but there are other aspects that reveal more similarities than may be obvious at first glance. The linchpin may be a major cultural difference. Those who work with ICS are operational people; they understand the purpose and processes of the systems and know the systems down to the device level. They have to, because lives are often at stake. On the other hand, many IT professionals have a focus that is system or task-specific. This compartmentalization is reinforced by many operating system (OS) and software certifications.
The following section takes a deeper look at, and sometimes challenges, some of the differences that
have been defined between the two technologies. The intention is not to discount any efforts to distinguish between the two disciplines, but rather to provide additional context where possible to explore similarities or explain distinctions.
Access to components—Regardless of technology, components may or may not be difficult to access. Due to the unique roles that ICS often serve, authorized technicians are often needed to diagnose, repair and/or replace components. This is prevalent in SCADA systems and BAS. The same can be said for backhaul and even backbone trunks laid underground.
Availability—Little can be disputed about the importance of ICS availability. ICS are designed
to monitor and respond to abnormal conditions and unavailability may jeopardize life, safety, and often expensive equipment and/or processing plants. (No reports of death from a system reboot were found in the research for this publication.) Alternatively, IT outages affect productivity and customer
satisfaction. The notion that only ICS outages must be planned well in advance and changes
thoroughly tested is false. Generally speaking, people have grown to accept lower IT system up time, also known as availability, likely in part because instabilities in non-nix environments have led most
to freely adopt the three-step troubleshooting technique: Refresh, reboot, reload.
Change management—It is ironic that NIST’s comparison of the two systems made no mention of thoroughly testing changes prior to deployment on an IT system. Outages to Facebook, Bing, eBay and Google reinforce the need for change management.
Communication—Although protocols do vary, they are simply a means for devices to communicate.
One way of thinking about this is to compare protocols to spoken languages. For example, Ethernet is like English: Regardless where one is in the world, many can speak it. On the other hand, ICS protocols areproprietary and thus foreign to those outside of the industry.
(This is an excerpt from ISACA report which can be downloaded from here)
Comments
Post a Comment