Request For Comment - Security Hardening Guide ideas

General Discussion
1

Seeking community feedback on the Security Hardening Guide. Specifically, security content that broadly applies to Ignition users across industries, relating to product configuration, environment recommendations, or useful external resources.

My "seed" idea relates to hardening "auditing". Creating a separate db/schema (optional), using a dedicated database user with limited permissions (SELECT, INSERT on minimal DB areas), and a dedicated restricted Ignition Database connection with that user. Note, more permissions are likely needed for initial table creation. I'll provide additional context such as recommendations of using a DB in a separate security domain (preferably one that is already being maintained and monitored).

Ideas? Thanks for your participation!!!

2

  • Consider a logback configuration that will forward log entries to an external, separately secured agent. This will prevent malware from covering its tracks. This sort of thing is common in the Linux/Unix world.

  • Take care Forbid ever using the OPC/UA server's feature that exposes Ignition's tags. It has defaults to essentially zero security.

3

A more nuanced restriction is needed. It has security, what it doesn’t have is access control for devices.

You do have access control on all exposed tags. If you expose tags from a gateway that has no devices (say, a central gateway where the device tags come from a remote gateway), then it all depends on whether you’ve configured tag access controls and set the server to use an appropriate auth profile.

1 Like
4

@pturmel - I appreciate the feedback. I'm focusing on documentation recommendations, but am willing to discuss feature requests.

  1. External logging integration is a great idea (IGN-6036, Submitted internally by Kevin C, linked to the Ideas post below). It needs some design work given possible areas of coverage (Ignition system/gateway logs, user auditing (Audit Profiles), Wrapper log) in a way that could support multiple gateways and external SEIM systems and Windows "System Monitor" and Linux "Syslog".

"Up vote" the idea here if interested:

  1. I'm interested if tag security in the way that Kevin describes, when properly configured, is capable of providing a high level of assurance and covers adequate use cases. I am partial to discussing similar capabilities, such as a "read only" project capability by using a frontend Ignition gateway with a "read only" Gateway network connection using remote tag providers. This needs to be balanced with practicality.

2a. I am a proponent of security architecture - breaking up roles, segmentation, and controlling interfaces. This is somewhat described in the "Ignition Server Sizing and Architecture Guide". I'd like to offer an accompanying product that is more security focused. I don't think this currently fits in the Security Hardening Guide.

  1. For this document, do we then need to discuss more about locking down (or not using) the OPC-UA server to cover this concern?

3b. Is access control for devices needed? Other security features?

Can we realistically get to strong through "best practices" alone? Keep in mind that many Ignition users use a "Standard" (1 gateway) architecture.

5

  1. I think logback configuration is already possible and highly customizable, covering all normal gateway logging. The wrapper can divert to syslog, leveraging existing syslog shipping options. (Though I haven't actually done any of these.) Auditing can already be cascaded through suitable database replication technologies, but another method would be nice.

  2. The concern for the exposed tags feature is that new tags default to full read/write access. That default is fine within Ignition itself, but not fine for exposed tags. Some possibilities:

  • Require opt-in by tag provider to the exposed tags subsystem.
  • Create an inheritable security property for tag folders so a root could be set to no access by default.
  • Create a completely separate set of tag security properties for use with exposed tags, defaulting to no access.

2a) Entirely with you.

  1. Varies. Within Ignition, a designer must configure something that will write to tags. With exposed tags, writes are entirely driven by external users. That is the root of the issue.

3b) Some possibilities exist with the new Device model. I'm not up to speed on it yet.

{ Hmm. Markdown doesn't like the suffixes. }

6

If the "best practice" is to not use certain features....

I'm not a fan of that.

7

Very interested in this topic as I have to build a new locked down gateway for use by a partner organisation via DMZ gateway network connections to our internal central gateway
So need to take every procaution and demonstrate its secure following the hardening guide, but need to show compliance reporting and be able routinely assess and report easily.

Many distros now support the openSCAP tools which are very useful for compliance reporting to various security profiles.
You can read more about its capabilities here.
https://www.open-scap.org/
https://www.open-scap.org/security-policies/choosing-policy/

The workbench tool is excellent for running a scan against a security profile and producing reports which include remedial scripting. This can be applied to a un hardened OS
or to one which is built with a security profile enabled which should equate to less remedial work later.

For context running on AlmaLinux9.0 with latest release Ignition 8.1.21.
For openSCAP profile used Australian Cyber Security Centre (ACSC) Essential Eight, but other NIST profiles are available for other regions.

The openScap tools require GUI support, so the full ISO linux image is needed at the initial build or augment all the relevant GUI packages later to a minimal build.

So I wanted to explore if its possible to install Ignition to a pre-hardened AlmaLinux 9.0 os instance and then resolve any remaining vulnerabilities leveraging the openSCAP workbench tools.
Hope being that it might be less work to harden everything post ignition install working from a pre-hardened OS base.

Turns out to be not straight forward :frowning: here are two results:

Scenario 1: Pre-Hardened Linux build with openSCAP profile enabled, then install Ignition, then audit again and remediate
result: Ignition installer fails with error.
xhost: unable to open display ""
runtime/bin/./java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
This occurs for interactive mode and also the command line options of unattended installs.
Most likely need to relax some locked down packages/permissions to allow installer to run and then remediate afterwards.
Have raised tech support case with IA to identify dependencies (WIP)

Scenario 2: Unhardened linux with Ignition installed, then run openSCAP workbench to assess vulnerabilities
The assessment report identifies 44 non compliances out of total 97 criteria, so its a huge job to remedy that to meet an openSCAP profile.
Concern is will Ignition stay working if I remediated all the 44 issues to satisfy the openSCAP profile ?

Has anyone else had success with openSCAP tools with Ignition environments?
Perhaps there might be other paths to achieve this?

Any feedback and suggestions will be greatly appreciated.