Security¶
We live in a connected world. This chapter gives an insight to the security aspects of the DashT overlay plug-in for the popular OpenCPN chart plotter. It presents the software security policy and explains its implementation.
TIP: Even if you are not that much of interested in this type of talk, please quickly take a look at the data flow diagram and you can spot out is your boat’s infrastructure concerned with any potential security issues. If it is, you have certainly already given a thought to the security aspects and can adapt DashT, accordingly. See also: Privacy.
Data flow¶
The diagram below depicts the data flow in and out from the overlay functions.
DashT C++ (plug-in) part receives data from following sources:
From OpenCPN
NMEA-0183 messages ;
GPS fix and magnetic deviation ;
Routing and waypoint change information.
From Signal K server node
Signal K delta channel by subscription - nothing if no instruments subscribing.
DashT C++ (plug-in) part sends data to following destinations:
To OpenCPN
Route and waypoint creation and modification requests via the ABI ;
Storage of data from historical instruments into the files under the responsibility of OpenCPN ;
Storage of all data from all sources into a InfluxDB line data file under the responsibility of OpenCPN.
To InfluxDB v2 Time Series database
All received data or a selection of that data.
DashT TypeScript/JavaScript (web-based instruments) part receives data from following sources:
From InfluxDB v2 Time Series database
Read back any selected data from the data written into it by the C++ (plug-in) part.
Security Policy¶
The security has an uttermost priority. The user’s computer or infrastructure security shall not been compromised or the system integrity threatened - not directly or indirectly - because he or she is using DashT plug-in.
The security implementation of DashT shall meet the SMART criteria, taking into account the surrounding FOSS and commercial ecosystem and putting those in balance with the very limited development and maintenance resources.
The achievability shall be described by an implementation plan.
The implementation plan shall clearly define the interfaces, to demonstrate how those “doors” are kept closed and how the own code base is kept safe.
The implementation plan shall demonstrate constant measurability by describing automated inspection against the currently applicable advisory.
The security threat shall be communicated to the end user via GitHub project security page by publishing a security advisory.
It shall be under each end user’s own responsibility to follow the security advisory.
The security fixes, if applicable are implemented only in the latest development version.
The security fixes or patches are no applied to earlier versions of this software.
User shall be therefore obliged to upgrade to the latest published version or to an intermediate development version to get the applied security fix if he or she deem necessary to do so.
There is no guarantee in time when the security fix will be applied; or that it will be applied at all.
Security Implementation¶
Please see the dedicated document in the software package’s documentation (the link is pointing to dedicated document in source code repository, see docs/security).