2. Ignition’s Security Features
How to Use
Ignition’s Security Features
Kent Melville
Sales Engineer / Inductive Automation

3. What We’ve Already Said
Steps for Protecting Your Ignition System – ICC 2017 (Carl Gould)
Open and Secure SCADA: Efficient and Economical Control, Without the Risk – Webinar (Travis Cox and Chris Harlow - Bedrock Automation)
Ignition Hardening Guide (Website)
Java Security and Ignition (White Paper)

4. Introduction Today’s Focus:
The Application: Ignition’s Security Features

5. Table of Contents Existing Features Upcoming Features
Q/A Security Panel

6. Existing Features Roles Zones TLS Encryption User Sources
Active Directory
7.9.4

7. Roles
Which is the username and which is the role?
Operator
JSMITH

8. Operator JSMITH Not a username Roles
Which is the username and which is the role?
Operator
Not a username
JSMITH

9. Zones
Roles care about WHO.
Zones care about WHERE.

10. TLS Encryption Enable SSL – Get a Cert Certificate Authority
Self-signed Cert
Third Party services (Let’s Encrypt)
OPC UA
Client
Gateway Network

11. User Sources Where to manage your users and roles:
Option #1 - Internal Authentication - Users and roles are stored internally to Ignition. 
Option #2 - Database Authentication - Users and roles are stored in a SQL database. Managing users is done via direct interaction with the database.

12. Active Directory Integration
Option #3 - Active Directory Authentication - Users are managed by Active Directory. Users are authenticated through the LDAP protocol. 
Where are the roles managed?
Active Directory Groups
Internal Ignition
Database

13. 7.9.4 Changes Client Permissions For upgrades from previous versions
all are disabled
For fresh installs all
are Enabled

14. 7.9.4 Changes
Named Queries are defined and run at the gateway but can be referenced from the project.
They accept parameters to be dynamic but prevent the client from running arbitrary queries.

15. Upcoming Features System Commissioning Federated Identities
Multi-Factor Authentication
Security Levels

16. System Commissioning

17. Terminology
Authentication - the process of verifying a user’s identity.
Authorization - the process of determining who should have access to what, or who should be able to undertake what actions.
7.9
Authentication: Internal Ignition User Source or AD
Authorization: Roles and Zones
8.0
Authentication: ?
Authorization: ?

18. Federated Identities
Authentication in Ignition 8 is done through Federated Identity Providers (often shortened to IdP).
What is a Federated Identity?
Federal
State
State
State

19. Federated Identities
Ignition 8 will include three different IdP types out of the box:
Ignition IdP
Legacy User Sources
OpenID-Connect IdP
SAML IdP
Ignition IdP This identity provider will authenticate against any User Source defined in Ignition. This is useful for standalone systems that do not want to integrate with an external authentication system. It also provides backwards compatibility for users who wish to continue using legacy authentication strategies such as LDAP based active directory authentication.
OpenID-Connect IdP This identity provider is used to integrate with an external IdP service that supports the OpenID-Connect (OIDC) 1.0 protocol, which is built on OAuth2.0. OpenID-Connect is used by many third party identity providers,
SAML IdP This identity provider is used to integrate with an external IdP service that supports the SAML 2.0 protocol. SAML is also used by many third party identity providers, in particular: Microsoft Active Directory Federation Services (ADFS).

20. Federated Identites Benefits
Web Single Sign On (SSO) - Better UX and more Secure
Single Source of Record for Identity Data
Simplified Provisioning and De-Provisioning
Benefits
Web Single Sign On (SSO) - Better UX and more Secure
I only need to remember one password
I only need to login once at the federal level in order to login to any states
Session is remembered at the federal level so that you are remembered
Web SSO works on any web-enabled device (phones, tablets, macs, windows, linux, etc.)
Single Source of Record for Identity Data
As a customer: I only have one place to manage my identity data and security and privacy settings
As a business: I only have one place where I need to manage my customer and employee accounts and the policies around how they login (i.e. password strength, 2FA)
Sensitive information no longer needs to be duplicated in many disparate systems
Securely managing sensitive information is complex and should be left to the experts at the federal level
Data becomes stale or out-of-sync over time if replicated in many different systems
Simplified Provisioning and De-Provisioning
When John Doe is hired, he is provisioned in the federal system and therefore gets to login to all states for free
If John Doe is fired, he is de-provisioned from the federal system, which means he can no longer access any of the states in one move

21. Multi-Factor Authentication
Passwords (or any one factor of authentication) alone are generally insufficient in protecting modern digital identity systems
Multi-factor authentication (MFA)
Two-factor authentication (2FA) is a subset of MFA where exactly 2 mechanisms are used to prove one’s identity

22. Multi-Factor Authentication
The three most common types of identity proofing mechanisms are:
What you know
Typically a password or passphrase
What you have
Badge which you can scan
A software or hardware based one-time-password (OTP) generator
A device such as a smartphone which is capable of receiving authentication requests
What you are (biometrics)
Fingerprint
Facial or Voice Recognition
Retina scan
Each Federated Identity supports different proofing mechanisms.

23. Security Levels
Next up - Authorization.
Introducing Security Levels…
A platform-level construct aimed to make the permission modeling inside Ignition more convenient, portable
Introduce a stand-alone permission modeling system for use within Ignition, regardless of how identity was established
Put another way: security levels allow Ignition to have its own authorization system, independent of the authentication system being used.

24. Security Levels Security Levels will look a lot like roles: User
Operator
LineA
LineB
Supervisor
Using security levels makes defining permissions simple: simply pick which security levels have access to parts of your application.
The hierarchy of security levels can be used to simplify the security settings, because users with more specific security levels also “inherit” the more general security levels
For example, a user granted the security level “Operator / LineB” also has the security level of “Operator”

25. Security Levels
There are two “special” security levels defined by the platform
Public
All users are always granted the Public security level, even if they are not authenticated
Demo Project is almost entirely using the Public security level.
Authenticated
If a session has authenticated against the configured IdP successfully, they will have the “Authenticated” security level
All users are always granted the Public security level, even if they are not authenticated
A session that only has the Public security level is not authenticated
Put another way, they are a guest or anonymous
The Public security level is there to remind application designs that, unless another security level is required, guest access will be allowed

26. Security Levels
If the IdP used did provide “role” information, the roles provided will be added as child security levels underneath “Authenticated”
Public
Authenticated A B
The legacy role information underneath Authenticated provides a way to bridge this new method of permission modeling with the role-based permission modeling from Ignition 7

27. Security Architecture
Gateway:
User Sources
Vision Client:
User Sources
Designer:
User Sources
Perspective:
Federated Identities
and Security Levels

28. Demo

29. Cyber Security Risk Officer
Kent Melville
Jason Waits
Joel Specht
Sales Engineer
Cyber Security Risk Officer
Software Developer