© Vladimir Balas shipwreck_102858955
© Vladimir Balas

Last month a much-reported blog – included in The Loadstar – claimed “sinking ships [via hacking], really wouldn’t take much”.

Not only was that overly dramatic and not helpful for safety of life at sea, but it was irresponsible as well as being fundamentally flawed: the input assumptions were totally incorrect.

The blog jumped around without a logical flow and appeared to conclude that if you corrupted the stowage or Bayplan, via the BAPLIE message – which is given by the terminal to the ship on a USB – that containers could be stowed erroneously to such an extent that it would seriously jeopardise the stability of the vessel.

The Bayplan given to the ship is an output from the process. The determination of where specific containers, or categories of containers, are to be loaded is several steps prior to this output.

The standard process actually makes data manipulation relatively difficult, as you have two completely different data sets within different organisations and offices, and these need to match at more than 99.5% before loading will be planned or can commence. If you corrupt only one of them, this will trigger a reconciliation process where the error will be detected and corrected with relative ease and in little time.

VGM (albeit perhaps not as well enforced as it should be) actually adds an additional layer of security now – although that was not the real purpose of it.

In most container terminals, (and the same is likely true at many ship operators’ offices), planning and scheduling software is usually run from networked PCs, which do not have general internet access, partly for security, and partly to keep employees off Facebook or YouTube, This is clearly best practice, and as a policy reduces phishing risks. So it is highly unlikely that one of the two data sets would be deviously manipulated.

But this blogger did not stop there: now providing advice to potential criminals as to how they can either pilfer containers or, worse still, get them to explode on ships.

He writes of the BAPLIE (Bayplan) message – but makes no mention of the EQD segment, the container number, which would be mandatory. There are many other segments related to intimate consignment details and prices, but you will not find these in any live BAPLIE.

EDI messages are somewhat bespoke by design and to implement one, both the sender and receiver need to define the content, while the vast majority of the segments are merely optional. So a successful hack could likely only be made if specific knowledge of an EDI-partnership was known – ie, an inside job and not a random hack.

You could amend the discharge port, but the container will not get out from that new port due to other separate security processes, such as BL submission, Customs and ship operator releases. You could also amend the IMDG details in one or other system, but unless they match 100%, the container will not get loaded.

It is fine to promote products through the media, but basic facts must be correct, and bloggers must not propagate “fake news”.

Comment on this article

You must be logged in to post a comment.
  • Miles Varghese

    December 06, 2017 at 3:17 pm

    Great post, Andy. Huge respect to CTI, but I feel as though this piece in itself may let down the guard of an industry that is severely exposed.

    The technicalities and strategies will vary, but legacy systems are easy to hack. Bay plans included. We’ve seen and worked with the EDI systems in place with many liners and were appalled by the lack of security and actually trying to change that by explaining what the cloud and SaaS really means.

    The risk is huge especially when so much is done by email. The industry is easily 10-20 years behind and if a hacker were to set his sights, it would be far easier to breach than what exists today.

    Liners are liners, not technology companies despite their best efforts. They know only what they know, and we’re doing what we can at Octopi to educate and explain how modern software (i.e. the terminal operating system) should be handled.