Some remarks from John Jorgensen (ABS) on future developments in maritime cybersecurity
We have to think differently with this set of problems.
Relationships among systems, components and networks (arguably, systems, but with different composite behaviors) might be shown in a graph database to illustrate how unexpected connections can impact the whole (to your design plus implementation point).
I always default to a position of ‘what do I DO?’ in considering how to address this thorny set of problems.
I’m within a couple of weeks of starting experimentation in a graph DB environment to see how we can represent connected data without the baggage of tables.
Network analysis is too far afield for actual use at this time, in my opinion.
It may be absolutely required, however, as a test and assessment basis for interoperability verification in highly-automated systems.
As we progress toward more autonomous systems on vessels, it could be a parallel path forward to understand behaviors.
Combine an asset management / configuration management database built in a graphDB environment with network analysis, and you can now model the entire smart vessel in one place.
We – as a community – have to center efforts on outcomes, not on technical means.
Threat mechanisms (mention in an earlier part of the thread about unclassified attacks; see cwe.mitre.org for the authoritative source) are part of the architecture and design process, then figuring into DT, OT and final pre-deployment testing.
Of course coding must be included; but that is another topic by itself.
Ship cyber requirements are not particularly important.
What is URGENT and entirely lost is the potential impact on a port, coastline, or other ships if a ship is rendered ‘not under command’ by an automation incident, either error-caused or intrusion-caused.
Not to minimize hazard to crew, but the really important risks are those that can cascade into larger events.
I will forcefully assert that our task is to ensure designers, builders and operators use good engineering methods, sound risk assessment and management techniques, and widely-applied automation monitoring processes and procedures to ensure the eventual ship/crew combinations have the ABILITY to be safe.
This applies to regulators, Flag States, port authorities, owners, insurers, cargo carriers, the whole lot – they have to understand the implications of automation.
This gets back to DEPSECDEF’s comments.
One must be cognizant of the ownership of data just as one is responsible for custody of physical gear.
That means all players in the chain must understand what goes where, who can access what, and what they do in case an unexpected event (unauthorized access, intrusion, human error exposing data, etc.) occurs.