This post is a guest post by Daniel Lewis, an subject matter expert on industrial cyber security, industry 4.0 and smart cities, written specifically for Blue Ocean Autonomy (formerly ACUA Ocean).
Let’s talk about DefenceTech systems within a larger autonomous system, and in particular the risks associated.
Firstly, what is DefenceTech?
DefenceTech, or DefenseTech for our American readers, is any technology-based solution which attempts to solve defence and security related problems. It could include robotics, it could include weaponry, it could include cyber capability and/or many more other things.
Many cyber security product businesses could be classed as DefenceTech, but also many companies like ACUA Ocean could be classed as DefenceTech when their Uncrewed Surface Vessels are used for Defence & Security applications such as monitoring the security of harbours.
What is a communications denied environment, and why is it interesting to us?
A communications denied environment is any environment where it is not possible for people or machines to communicate wirelessly (including satellite-based communication).
Within the military, these environments require (human) troops to have as much knowledge of the environment in advance as possible before entering it, they need to have planned for the operation to the best of their ability, and included redundancy plans. During the mission they need to be perceptive, alert and agile. There is no option for communication back to a centralised location during these missions, so prior intelligence and active agile is key.
As DefenceTech often requires communications on-field and/or back to centralised operations centres, this is key to consider when we need to deploy DefenceTech products within communications denied environments.
What are the risks associated with an autonomous system operating in a communications denied environment?
In essence, an autonomous system working within a communications denied environment has no less requirement than the human troops working in the same field. An autonomous system will need to have a knowledge-base full of as much intelligence as possible of the surroundings, it must have sensors capable of perceiving changes to that environment as well as potential threat, and it must be capable of changing its plans in an agile autonomous manner.
The risk impact of the capture or damage to the autonomous environment varies depending on what the payload is on the vehicle or vessel, however, the inability for communication back to a Remote Operation Centre (ROC) or another person/device in the field means that the risk cannot be mitigated by a third party in-action. The effect of an attack on the system could therefore be very high, within the context of the payload.
Designers of autonomous systems within these environments will need to consider how best to secure them from a cyber security perspective, particularly in regard to data confidentiality and integrity.
Let’s talk about solutions
There are many questions to be asked when it comes to the digital security of the autonomous system within DefenceTech:
Do you know exactly what components and assets are included in the solution, and are they being swiftly patched with security updates?
Is data stored encrypted (“at rest”)?
Is data communicated onboard encrypted (“in transit”)?
Is data communicated externally also encrypted (“in transit”)?
Are encryption keys created and stored using best practice guidance?
Is there adequate authentication and authorisation?
Are there firewalls in place?
Who has access to the device before entering the environment, and during presence within the environment?
Are there physical access control systems (e.g. locks) which might help to prevent or deter access to the onboard digital systems?
Are there physical defence mechanisms which can be employed onboard (e.g. electrified barriers, shielding welded on to form a barrier, etc)?
Has a third party independently penetration tested the product, both digitally and physically?
Is there any form of Data Loss Prevention (DLP) included?
Is there an intrusion detection system in place (if possible)?
What sensitive information/data is on the device which we might want to shield at all costs in the event of a successful attack?
In the event of successfully penetrating into the system, what can the system do to respond?
An intrusion detection system (IDS) might be useful in these cases, and our partners at Microsec have a lightweight IDS which can be embedded on such systems.
In the event of a successful intrusion on such an autonomous system within a comms denied environment, we might decide that all data (or just data categorised as sensitive) must be destroyed to avoid it landing in a nefarious actors hands. An IDS could trigger this event, but it will also need to be weighed up with the overall risk of losing that data completely in relation to the mission itself.
Finally, a note on standards and frameworks. There are cyber security standards and frameworks out there which can be useful in providing some assurance into how safe and secure products and their vendors are:
ISO 27001, which is a standard ensuring that information security is managed well within the business
IEC 62443, and in particular it’s product/vendor section, is a way to ensure good practice within control and automation systems cyber security
ISO 9001 and ISO 45001, for quality management and occupational health & safety respectively - these are not cyber security specific but should be an additional indicator on how the business in question is thinking about safety and security
Please note that standards can be applied, but never really “lived” - they need to be “lived” in order to be effective, and so they should never be relied on solely as an indicator that the company is safe and secure.
This post is a guest post by Daniel Lewis, an subject matter expert on industrial cyber security, industry 4.0 and smart cities, written specifically for ACUA Ocean.