Security through bureaucracy is pain with limited gain
Since the publication of IMO 2021 and BIMCO guidelines for cybersecurity onboard ships there has been a flurry of activity by class societies to define cyber notations. The aim is to provide a common language to make it easy for owners and managers to understand the recommended standard for cyber securing their vessels. It also provides a standard by which flags, charterers, insurers and other stakeholders can assess the cyber capability of each vessel.
Most have defined at least two levels of security. An entry or retrofit level, which aims to cover the minimum cyber hygiene requirements for existing vessels to comply with IMO 2021, and then one or more advanced levels which aims to impose a “secure by design” approach for new or high-risk platforms.
Notations and recommendations are encouraging bureaucracy
Many of the entry level schemes are heavily reliant on manual processes, checks and audits to achieve their security goals; in other words a bureaucratic solution. To make matters worse, where there is guidance on how inspectors and surveyors should be verifying that these procedural controls are being followed and is working, this imposes further procedures. To be clear, there is very little clarity on the surveying and verification process for cyber security, so we definitely welcome some guidance on this. But “bureaucracy on bureaucracy” has a serious risk of achieving very little actual security.
To illustrate the point, we’ve been assessing the latest IACS Recommendation on Cyber Resilience (No 166), presented as a consolidation of IACS’ previous 12 Recommendations related to cyber resilience (Nos. 153 to 164). The Recommendation starts with a goal-oriented and risk-based approach designed to deliver functional requirements aligned with the NIST Framework’s Identify, Protect, Detect, Respond and Recover pillars. A sensible start.
But look more closely and you’ll find ~80 recommended Technical Requirements, of which just under 50% are procedural. The verification process demands documentation on 32 elements of which, 16 relate to on-going onboard review, rather than one-off at the point of vessel design or equipment installation. That means they need to be updated, checked or verified periodically, with corresponding documentation to evidence having done this for the purposes of surveys and inspections. Copies of the documentation are required onboard the vessel (to be made available on request) as well as back onshore.
Put quite simply, the vast majority of these Technical Requirements result in documentation to demonstrate a significant quantity of mainly procedural controls, rather than any sensible measure of the quality and efficacy of them i.e. paperwork on how many controls have been implemented, rather than any assessment of whether they are working.
Procedures are familiar; it’s the way shipping has always done things
Some ship owners we’ve spoken to are relieved for this procedural approach. While they are
skeptical of the actual value, it’s not difficult to understand why:
– bureaucratic solutions are already accepted by masters, crew and inspectors in other areas of operations such as safety, physical security and port arrangements.
– bureaucratic solutions give the impression of being cheaper and easier to introduce than retrofitting major changes to vessel IT architecture and security controls.
– bureaucratic solutions shift the practical burden of ensuring security on to masters and crewand away from those who architect the policy
We’re not arguing against any form of documentation. A documented cyber risk managementprogram is an absolutely necessary foundation to ensure appropriate identification and treatment of cyber risk.
But avoid being a “busy fool”
If the Covid-19 pandemic has taught us anything, it should have taught us that we must and can do things differently. Randomly adopting a large quantity of procedure-only controls may distract and waste resources, rather than help. Security-by-documentation will get us nowhere. An entirely bureaucratic solution is almost certain to fail for at least one of the following six reasons:
– adopting the entire catalogue of recommended Technical Requirements results in additional
procedures to pile on top of the existing responsibilities of masters and crew;
– lack of visibility makes effective enforcement impossible;
– the volume of logged activity overwhelms the ability to effectively audit;
– burden and expectation on crew disincentives them to support future initiatives;
– bureaucracy lacks the pace required to respond effectively to incidents; and
– malware gives no credit for having patched a fraction of vulnerable systems.
Go for quality, measure, iterate and automate
Assess all proposed procedural controls for practicality and use data to validate assumptions. If the control is put into place, how may it affect the crew and shoreside workflows? For example, if you’re considering a process to manually log every USB device use on the vessel, do you have good data on how many devices are onboard and how often they are used?
Consider how you will get visibility of each defined process. For example, if you require the crew to make weekly updates to onboard antivirus software how can you ensure this is being done more regularly than at a periodic audit?
Gather and communicate evidence to reinforce and encourage the crew to comply. Putting in a procedural control means more work for someone. Even security-conscious individuals would benefit from positive reinforcements. Consider how to gain visibility of how well the crew are complying, communicate this and set stretch targets periodically. Most importantly, use the data to evidence how the processes have been effective in reducing cyber risk.
Take opportunities to automate. If you can avoid a manual process by automating data collection and analysis it will pay dividends. Plus it provides an effective route to improving compliance through real-time feedback and training nudges to crew.
Get in touch with us here ([email protected]), if you have been assessing the IACS Recommendation on Cyber Resilience (No 166) and if you have any questions. Would you find it useful to get access to our detailed review of the recommendations and any tools to help you navigate and comply? We are developing a series of practical advice blogs and tools that are free to access and designed to help fleet operators start or “power up” their journey to managing the cyber risks to their vessels. Check out the other blogs in this series (https://bit.ly/2DERunz) and sign up here (https://bit.ly/2CuH6hH) to be updated on future blogs and tools.