Security Best Practices for Your Ignition System

Speakers

Kent Melville

Director of Sales Engineering

Inductive Automation

Don Pearson

Chief Strategy Officer

Inductive Automation

Joel Specht

Lead Software Engineer

Inductive Automation

Cybersecurity is a moving target. The techniques and technologies of yesteryear won’t necessarily protect your system in this highly interconnected era of IIoT-enabled systems. As attacks on industrial control systems become increasingly commonplace, it’s more vital than ever to stay up to date on the latest in security best practices to mitigate risk and maintain peace of mind.

Join Inductive Automation’s Don Pearson, Kent Melville, and Joel Specht as they take a look through the new-and-improved Security Hardening Guide, plus recent major security updates for the Ignition platform, to help you stay well ahead of any potential threats.

• Learn how to lock down every part of your system
• Discover new authentication tools
• Explore Ignition’s built-in security features
• Understand the importance of constant vigilance

Webinar Transcript

00:00
Don Pearson: Good day, everyone, and welcome to today's webinar, “Security Best Practices for Your Ignition System.” My name is Don Pearson. I'm Chief Strategy Officer here at Inductive, and I'll be serving as the moderator for today's webinar. With me is Kent Melville. Kent is the Sales Engineering Manager at Inductive and he'll be the webinar presenter today. So Kent, why don't you take a minute and do a little better introduction of yourself than I just did?

00:28
Kent Melville: Yeah, sure. Thanks, Don. Yeah, here at Inductive Automation, our Sales Engineering team is responsible for meeting with customers, talking to them about best practices, architectures, design guidance, all that kinda stuff. And so, I get the privilege of working every day with all of our great customers and integrators and helping them make the most of Ignition. So, it's a lot of fun.

00:48
Don: Thank you, Kent. Thanks for being here today.

00:51
Kent: Yeah, my pleasure.

00:52
Don: Alright. Also joining us is Joel Specht. He's the Lead Software Engineer at Inductive Automation and he's here to offer some insight from the team responsible for upgrading Ignition's security. So, Joel, why don't you do the same as Kent, just tell us a little more about yourself and what you do at Inductive Automation?

01:12
Joel Specht: Hi, Don. Yeah, thank you. So, as you mentioned, I'm a Lead Software Engineer here at Inductive Automation. I've been with the company for about five years now. I primarily work with the core Software Engineering team responsible for Ignition. My subject matter expertise is security. I work with the team to design and implement Ignition's security features. I also work with the team to continually and proactively improve the overall security of Ignition and to prioritize any security vulnerabilities we discover in the product.

01:49
Don: Thanks, Joel, and thanks also for being here today. I appreciate it very much. Let's take a look at today's agenda. I'll quickly tell you about our software platform, Ignition. Then we'll briefly discuss a recent US government cybersecurity advisory. Then that will lead us into talking about the recent Pwn2Own competition held in Miami, that Ignition was a part of and how we responded to the results of that event. And then we'll look at the new Authentication Challenge feature that was added to Ignition in 8.1.16, before getting to the main topic of today's presentation, the newly updated Security Hardening Guide. After that, we'll wrap up with some audience Q&A.

02:34
Don: So as always, if you have any questions during the presentation, just type them into the questions area, you know, the GoToWebinar control panel. We'll answer as many questions as we can at the end, but if we don't get your question, as always, we will follow up and we will get to that question. We'd like to call Ignition the “unlimited platform” for a lot of reasons, and that's because while it's pretty great for HMI and SCADA software solution, it can also do a whole lot more than that. Ignition provides one central hub for everything on the plant floor. It lets you easily create any kind of industrial application like HMI, MES, IIoT and a whole bunch more than that. You can instantly web deploy clients to desktops, industrial displays, and mobile devices. It's unlimited licensing, lets you have all the clients, tags, and connections you need at one affordable price. And it's got the industrial strength, security, and stability that today's world just simply demands.

03:37
Don: And that's why Ignition is trusted by thousands of companies worldwide, including 54% of Fortune 100. I think about 42% to 43% of Fortune 500 companies use Ignition. If you wanna learn more about it, you can try it for free. Visit us at inductiveautomation.com. But to today's topic. Just last month, the US government agencies issued a joint cybersecurity advisory about APT cyber tools targeting ICS SCADA devices. APT actors have developed custom made tools for targeting ICS SCADA devices and enabled them to scan for compromise and control affected devices once they have established initial access to the OG network.

04:25
Don: These tools have a modular architecture and enable cyber actors to scan for targeted devices, conduct reconnaissance on device details, upload malicious configuration code to the targeted device, backup and restore device contents, and modify device parameters. And as you can see, even as security practices become more sophisticated, so do hackers and bad actors. The release of the TISA advisory shows that SCADA systems continue to be at risk. Luckily, the actions you can take to actually protect your system from these specific tools are all covered in today's presentation. Plus, we're gonna cover a whole lot more besides that. With that in mind, I just wanna pass things over to Joel so that he can discuss Ignition's involvement in this year's Pwn2Own competition. Joel?

05:21
Joel: Thank you, Don. Alright. So on April 19th through 21st of this year, Trend Micro's Zero Day Initiative brought their Pwn2Own competition back to the industrial control systems world for a second time at the S4 2022 conference in Miami. Inductive Automation eagerly participated after a successful ICS Pwn2Own at S4 2020. Ignition was registered in the control server category as one of 10 products selected as competition attack targets. Rules of engagement dictated that attempts be launched against the target's exposed network services or by opening default file types from the contestant's laptop. An entry is deemed successful by resulting in arbitrary code execution. It may sound a little counterintuitive, but participating in events like Pwn2Own is actually incredibly valuable, both for us on the design side and end-users, because it offers a safe way to test defenses and make improvements without high stakes consequences, which is a good thing since industrial systems are among the highest of value targets for malicious hackers and unfortunately, also among the most vulnerable.

06:46
Joel: The Pwn2Own competition resulted in 32 entries registered by 11 contestants. Of six entries total targeting Ignition, four were successfully demonstrated as unique exploits. One was a duplicate and one failed to be successfully demonstrated in the time allotted. All six entries targeting Ignition were responsibly disclosed to Inductive Automation. One additional finding was also responsibly disclosed to Inductive Automation by researchers who were unable to compete in this year's competition. Inductive Automation thoroughly analyzed each researcher's findings and concluded there were four critical vulnerabilities, which were prioritized and patched immediately. In response to Pwn2Own 2022, we strongly recommend all Ignition users upgrade to Ignition 8.1.17 or 7.9.20 for the 7.9 LTS users. These versions include patches for the four critical security vulnerabilities I mentioned on the previous slide.

07:52
Joel: Inductive Automation has prepared a detailed technical advisory addressing the vulnerabilities resulting from Pwn2Own and we will publish the advisory next month to give time for users to upgrade to the latest secure version. Inductive Automation thanks the Zero Day Initiative for choosing Ignition in the competition. Inductive Automation also thanks all participating researchers for responsibly disclosing the vulnerabilities to the ZDI and Inductive Automation. We may be on 8.1.17, but I want to talk about a really exciting feature that was included in 8.1.16 called the Authentication Challenge. The Authentication Challenge allows an operator who is currently logged into a system to document supervisor approval without logging out, which is beneficial for both security practices and 21 CFR Part 11 regulated industries, where these kinds of sign-offs are common.

08:53
Joel: The Authentication Challenge concept is made up of several new features that work together. Perspective redirects the user to the IDP, just like any other login, another person, such as a supervisor, then provides their user credentials on the IDP's login page. The IDP validates the credentials and redirects back to the session after the challenge. What makes this so useful and time-saving is that the whole workflow occurs without ever logging the operator out of the session or IDP, while still allowing the system to generate proof that the two people were present. Alright, now I'll hand it over to Kent.

09:32
Kent: Yeah. Thanks, Joel. So before we get on to the Security Hardening Guide, I wanted to let all of our Ignition 7.9 users know that support for 7.9 is ending very soon. Hopefully, this is not a big surprise, we've been talking about this for a year and a half or more. But at the end of June, 2022, this year, so in about a month, Ignition 8.0 and newer will be the only supported versions of Ignition with 8.1 being a long-term support release LTS. End of life versions of Ignition will no longer be supported by development or support teams and will not receive security updates. If you're using an older limited support version of Ignition and want to continue receiving support and security updates, you should move to a newer LTS version before June 2022. If you have any questions about migrating a system to a newer version of Ignition, please contact us and we'll do everything we can to help.

10:22
Kent: You can see we have this diagram here on the screen that kinda helps you understand how these support cycles work. But essentially, LTS versions are supported for at least five years plus a guaranteed two years after the release of the next LTS version, so you've got time to upgrade to the next LTS version. For non-LTS versions, they're just released until... Or supported until the next LTS version, and then they go into limited support. All of these have two years of limited support after them. That means that after you're not getting patches, you can still call in to tech support and they'll help you out with issues that you face or questions that you have. And so, all of this is outlined inside our support policy on our website, so you can check it out there. But if you're on 7.9, highly recommend you upgrade to 8.1.

11:08
Kent: Recently, we at Inductive Automation, went through and updated the Security Hardening Guide, and for those who are unfamiliar, the Security Hardening Guide is a document that we put together to provide general guidance on how to set up and secure your Ignition installation, and we've laid out the entire process over a course of 10 steps. And the document includes guidelines specifically for the Ignition software, as well as general suggestions regarding the hardware and network where Ignition is installed, the operating environment. As we get into the 10 steps, I will note that we're gonna pause in the middle to allow time to answer a few questions, we'll try to get to those today throughout the presentation. Security Hardening Guide starts kind of an introduction section, talking about a good foundation. And I wanted to mention that it goes over a couple of concepts that you should keep in mind as you're establishing security, not just for your Ignition projects, but within the context of its greater environment.

12:04
Kent: And so Defense in Depth is a strategy that uses overlapping protective mechanisms supporting the ability for defenders to monitor and respond. So, instead of relying on a single point of security, you should have layers of hardened security, and multiple layers requires a much more sophisticated hack to compromise a system. One example of this is the Purdue Model, our ISA 95 provides a reference model for a layered OT/IT approach to segmentation. The other concept I wanted to talk about is called a cybersecurity framework. And it's a system of standards, guidelines, and best practices to manage risk with computer network or information systems. And frameworks should align with organizational objectives. These are appropriate for larger regulated organizations, but can also be useful for any organization regardless of size, because the framework offers tailor-able common language and systematic methodology for risk management.

12:58
Kent: So you don't have to necessarily adopt all of it, you can tailor it to your needs within your context, your scope. And so, it's designed to complement an organization cybersecurity program and risk management process, not replace it. And the Department of Homeland Security Industrial Control System Cyber Emergency Response Team, it's a mouthful, we call ICS-CERT, is a great resource for recommendations and additional information. With those concepts in mind, let's look at the actual 10 steps, starting with step one, which is Securing the Gateway. And so, forcing secure communication with HTTPS using an SSL or TLS certificate, is the first and most important step towards securing the gateway, 'cause this ensures that all subsequent steps towards protecting your gateway are being communicated across the secure channel.

13:48
Kent: So what SSL or TLS does is it encrypts the data sent over the HTTP protocol and WebSockets that are used for all traffic between the Designer, Vision clients, and Perspective sessions in the Gateway. It also helps thwart security vulnerabilities, known as session hijacking, like man-in-the middle attacks, cross-site-scripting, and sessions sniffing. And just as a terminology note, probably heard I was saying SSL or TLS, SSL, Secure Socket Layer, is the predecessor to the Transport Security or TLS protocol, and so, SSL is a deprecated technology. We don't use SSL, Ignition blocks all SSL by default now inside the platform, however, SSL is still widely used to refer to secure communication. And even though TLS has replaced it, often people will say SSL meaning TLS. And so, I just wanted to make sure we're all on the same page.

14:47
Kent: SSL and TLS will be used kinda interchangeably in our document and in this presentation today, but when we talk about it, we do mean TLS. And so for example, modern digital certificates supporting TLS are commonly referred to as SSL certificates still in the world today. In order to enable secure communication for Ignition, you'll need to obtain and install one of these SSL certificates, and rather than using the Self-Signed Cert, we recommend that you purchase an SSL certificate from a Certificate Authority or acquire a valid SSL certificate from your IT department if you intend to enable SSL. And you will then want to force an SSL redirect, and so you can go into our settings on our Gateway and you can do a force secure redirect. You can go also set up headers and do HSTS and do a pre-load and sign up for all that, all of that is outlined in the Security Hardening Guide, but essentially that's gonna make it so that all traffic that tries to come in over an unsecure port will be automatically redirected and forced to use TLS.

15:53
Kent: So after SSL is enabled, that includes all Clients, Designers, and web browsers will be redirected to that SSL port if they're trying to use that standard HTTP port. And by default, when you install Ignition, the SSL port is 8043, but you can certainly change that to whatever you want including the standard SSL port 443. Now you got this SSL certificate, most traditional SSL certificates have a cumbersome life cycle that needs to be renewed often. Now this can be simplified and automated by using a certificate renewal process like the Automatic Certificate Management Environment protocol called ACME. ACME is an automated framework for obtaining and renewing SSL certificates for your domain so that SSL can be enabled on your web server, and we recommend using Let's Encrypt, which is a free automated and open Certificate Authority that uses this ACME protocol to handle these SSL certificates.

16:53
Kent: And that makes it so that any domain administrator can spin up an ACME client that points to the Let's Encrypt ACME server to obtain and auto-renew these SSL certificates. It just makes your life a little easier to maintain. Alright, so your Gateway is secure, time for step two, which is Locking the Gateway. In the Gateway, as many of you know, you have your Gateway web page where you go to do your initial configuration and on that Gateway web page, there are three tabs, there's Home, Status, and Configure. And by default, when you install Ignition, the Configure and the Status tabs are password protected, they're locked down by the administrator security level. And so, for additional protection, you can go and modify that security level, add additional security levels if you want.

17:36
Kent: You can also lock down the Home page, so this is where the various launchers are, how you navigate to different applications that you host on your Ignition system. And Security Levels and role-based user authentication can be to lock all of these down as well as the Designer. Step three here is Device, OPC, and MQTT Security. Traditionally, PLC native device communication protocols don't support encryption, they don't support certificates, they don't even support authentication, and so, best practice has been to pull these devices from as close on the network as possible. And these have often been kept on isolated controls, OT networks. And then when the data needs to be collected across a broader network, you run into problems and you have to do all these pass-through and all this stuff, and you have all this middleware that can come into play and it can make your architecture kinda crazy.

18:29
Kent: One thing to consider is Edge Gateways, they're becoming really popular these days, certainly, we have our own edge solutions for Ignition, that you can put in the field, they can pull locally and then they can publish data up over a more secure protocol, and which can help bridge that gap across networks. Ignition can provide a layer of separation between the OT or private and the IT public networks to make tags in Ignition available securely without exposing the devices behind the scenes and direct connections from Ignition to OPC UA and MQTT devices are generally the most easily secured connections, but we can still secure other connections as well. But talking about OPC UA and MQTT, let's go into those a little bit.

19:15
Kent: So OPC UA provides built-in security at the server level and also embedded directly on a device. When you connect, you can choose the Sign and Encrypt security mode to ensure that all data sent over OPC UA will be encrypted, and the OPC UA communications also support user authentication, so make sure you use a strong password and don't forget to change passwords periodically as defined by your organization's IT standards. And we talked about ICS-CERT and different advisories that have gone out, there's been a lot of talk recently about default passwords, especially for OPC servers, so make sure you're changing yours, when you install Ignition there are default passwords and you should change those, even though we do default to require a certificate to be approved for new connections, so it's not like somebody can just connect your OPC server willy nilly using that password, but you should still absolutely change that. Another way, other than OPC, to transmit data is with MQTT.

20:12
Kent: MQTT is a pub/sub protocol, if you haven't heard of it, you should definitely go and learn more about MQTT, we have entire webinars dedicated to this topic, but essentially it transfers data from a transmitter, a publisher up to a broker, and then any application can subscribe to that broker. So you have publisher to broker and broker to subscriber. And all of that should be sent over TLS, SSL. MQTT also supports username and password authentication as well as access control lists ACLs which limit user access based on a topic namespace. One of the great things about MQTT is that it can be hosted in the cloud, but certainly if you're going to host in the cloud, security measures should be implemented, whether it's local or in the cloud. So like I said, we talk a lot about MQTT in a lot of other webinars. I highly recommend you check those out.

21:05
Kent: On to step four: Identity and Access Management. When securing an application, you need to consider both authentication and authorization. So authentication is determining who's logging in, who can get onto the system. So often this is usernames and passwords and then authorization is once they've logged in successfully, what privileges do they have? What can they do once they're logged in? So if you look at these two concepts within the scope of Ignition, let's start with authentication. And so Ignition manages usernames and passwords through IDPs which stands for Identity Providers. And we have a built-in IDP, but we can also connect to third party IDP such as Okta or Duo via SAML or OpenID Connect. But the built-in Ignition IDP supports three main user sources. Internal Authentication, meaning you just manage users and roles directly inside Ignition or Database Authentication or Active Directory Authentication.

22:08
Kent: The Internal Authentication is kind of just the default that you'd use, you'd manage all the users and roles inside Ignition directly. It can be really handy and really useful to use that. Where it starts to break down is where you say, I have multiple Gateways across my network and I want them all to have shared users that sign in. And I don't want to have to manage the user separately on each Gateway. And so then you can start looking at other options. And so one is Database Authentication, which uses an external database to store data and user management. And then all that's done with direct interaction with the database and that database could be connected up to multiple Ignition Gateways. So now you have a single spot where you can manage users across your network.

22:58
Kent: But rather than just managing them in a database, often what we see are people using Active Directory Authentication. So the Active Directory Authentication profile uses Microsoft's Active Directory over LDAP to store all users roles and more to make up an authentication profile. And Active Directory Groups are used for Ignitions, roles and user role mappings. When using an Active Directory user source, the administration of users and roles is through the Active Directory interface itself rather than managing them within Ignition. So it requires all modifications that are done through Active Directory. Often that means that you're submitting a request to IT and then IT is making those changes. So it has pros and cons, but certainly it's beneficial to use Active Directory as now multiple Gateways can all connect up to the same Active Directory and there's one single source of truth to go and update for all you users.

23:55
Kent: Now, the LDAP protocol specifically, there's just like you have HTTP or using SSL, you have, HTTPS. Same thing applies to LDAP here. There's LDAP and there's LDAPS. LDAPS meaning it's encrypted, it's going over a secure port, all that kind of stuff. So to prevent snooping on authentication, encryption should certainly be implemented. Coming on to another point within internal authentication for our IDP. In addition to just supporting the username and password, we do support Badge Authentication as well. This is using RFID badges. And so when RFID is enabled, users do not have to enter their username and password, but instead have a physical badge in order to log in to the client or session. And it's recommended that Badge Authentication Method, the Badge Authentication Method be enabled and set to 'Default and Badge Secret' which means that in addition to opting to scan their badge, they will also then have to type in their password. So you get a little bit of multi-factor authentication there.

25:02
Kent: You don't have to. You can just use the badge or just use username and password. But using them together, both is certainly the most secure. That's kind of Ignition’s built-in IDP with those different user sources within that IDP. But what if your organization already has an IDP like Okta or Duo? Well, Ignition can leverage those for authentication as well. So utilizing a third-party identity provider, it can be really useful because it lets you utilize features that Ignition doesn't support natively, such as multi-factor authentication from push notifications or biometrics. And while IDPs were initially only available in Perspective as of 8.1, they can be used throughout Ignition, including in the Gateway, Vision, and the Designer.

25:48
Kent: Couple of general authentication suggestions here. When it comes to user accounts, a strong password policy should be defined, including password length and complexity requirements. So if a password... So a password may need to include letters, numbers, special characters, things like that. You should also establish a password expiration schedule and also quickly remove former user accounts, meaning when people leave the company, certainly you need to go disable those accounts quickly. And also, that's why you should avoid using generic accounts. Don't have people all log in as “operator,” they should be logging in as “John” or “Mike” or whatever.

26:22
Kent: And following the same line of logic, these generic logins pose a security risk if Auto-Login is enabled because that's what a user launches a project, they're granted a basic level of access, so Auto-Login should be disabled, then each user should have their own unique credentials. So you're logged in now, you're authenticated. Now it's time for authorization. Each user is granted privileges through the assignment of Roles or Security Levels, so Roles are customized during development and can be defined inside Ignition or mapped to Active Directory Groups or to an IDP’s attributes. Sometimes, in addition to knowing who the user is, it's important to know where they're sending a command from. So Security Zones define an area of the network into these manageable zones that can have a security policy set on them.

27:12
Kent: And so what this means really is that when somebody logs in, we can look at their domain name, their IP address, their sub-domain, and we can grant them specific privileges based on that so that a user who is logging in on a device right next to a piece of equipment may have read-write control, they have line of sight, they can control that, that's great, but if they're logging in from their desk, that's a different IP address, we know they don't have line of sight, we don't want them to turn things on and off, so even though it's the same user, would have the same Roles, they have a different level of access based on where they're logging in from. I mentioned Security Levels, Security Levels are a new concept as of 8.0, but Security Levels are a user set hierarchy that defines access permissions or Roles inside a Perspective session and now throughout the rest of Ignition as well.

28:04
Kent: And these provide a way to map user roles defined from an identity provider to Ignition Roles or to create your own custom security tiers, and with Security Levels, you get an inheritance model where more specific Security Levels means that you have more generic Security Levels above it. This inheritance now means that you can set up powerful permissions model where all employees can access a page in read-only mode, but only plant floor operator employees can read-write, and since plant floor operators are employees, they can do everything under the employees Security Level plus the things that are under the plant floor operator Security Level as well. So this inheritance means that you can just keep getting more detailed, a supervisor may have more privileges, but they also have all the privileges of an operator and so on instead of having to define it in multiple places.

29:00
Kent: Another note here is that complex Security Level Roles can be created using Ignition's expression language, where a Security Level can be derived from the authentication or authorization context itself. This context can take into account who you are, your logged in user identity profile attributes and so on, where you are, your Security Zones that are assigned to you, and what Roles do you have and also take into account current time of day incase users can only log into a system between the hours of 8.00 AM and 5.00 PM Pacific, for example, etcetera. You're only limited by your imagination. So it can be really powerful here to write these expressions to have even more granulated security. But that was a lot of content, we're gonna pause here in the middle and Don I'll turn it back over to you to moderate some questions here.

29:45
Don: That was a lot of content, but from the amount of questions in the queue, I can see there's a lot of interest. So I think it is a good time to take just a short break, ask a few questions, I'll remind people again, if we don't get to your question now, we'll try again at the end, but to just get a couple of them here. I think these are maybe more the ones I'm asking for Joel, but if not, I'll let you chime in also on a couple of these, Kent. Let's go to this one from Chris, he says, "Is there a secure way to get information on the four critical vulnerabilities that were patched?" And it says, "What those system vulnerabilities are or were?" So is that a question for you, Joel?

30:24
Joel: Yeah, so I can answer that. We will publish the details next month, but until they're fully disclosed to the public, we cannot share that information 'cause we need to allow time for the broadest amount of users to be able to upgrade their systems before it's known every little detail of how to exploit those vulnerabilities, so it's kind of a common practice in the industry and that we're following there.

30:49
Don: Makes total sense. Another question, "With security updates going to 8.1.17, will the image at HTTP, anyway the docker.com/kcollins Ignition be getting an update to 8.1.17?"

31:04
Joel: Yeah, so yes, it will be. As a general rule, those images are open source and there's parameters where you can take the image and build your own image and point it to 8.1.17, the actual built 8.1.17 image is not published at this point, but it's gonna be very soon from what I hear, so.

31:26
Don: That's great. And maybe one more, we'll try and get to now then, "Considering the technical advisory regarding Active Directory and SSO, is Inductive Automation considering removing this feature for good or bringing it back reinforced without having the end-user editing ignition.com?"

31:44
Joel: Yeah, good question. So the feature as you know it today will likely never come back in its current form and it will likely be removed altogether, but down the road, we plan on investigating how we may introduce Kerberos support, which would give users a more secure industry standard method for achieving the same desktop SSO experience. So no concrete plans there yet, but just something we wanna research and that would kind of re-introduce a secure version of that.

32:14
Don: Okay, cool. A couple of just housekeeping questions, "Will there be a recording of this available to attendees?" Yes, we archive all of our webinars, there definitely will be one available, I am not sure within a day, I guess maybe by this afternoon, but certainly within a day, and then, "Is there a downloadable PDF of the presentation slides?" I think we usually just do the archive, but if I'm wrong, that can be corrected, I don't think there's any reason why you can't end up getting the slides. If you need something more than the archive, you just have to let us know. So I think with those couple of things, I think I'll just leave the rest of the questions for the end, but I wanted to get to those that mostly addressed from Joel's part earlier. Kent, do you wanna take back over here and continue?

32:57
Kent: Sure, yeah, thank you, Don. And so, step five here is Defining Application Security, so now that you've got Security Levels defined, you've got your Roles defined, coming up with your users, how do you actually go and determine what that actually means as far as restrictions inside the application? So Ignition allows for security to be defined at any level from clients and projects down to individual tags, for Vision client security, settings can be applied to individual windows or components, and functionality and accessibility for the same project can change based on the user's assigned Roles. In Perspective, security being taken down to the Views level, which gives you more granularity when it comes to the security in a Perspective session. Now, operators can be granted access to that session, but the user management view for example, could be restricted to a higher Security Level.

33:46
Kent: Both Vision and Perspective contain role-based component security and component scripting security to ensure that non-privileged users are not allowed to run potentially harmful scripts. Granting someone access to the Designer here is another point we wanted to talk about which as many of you know, the Ignition is a development environment. And so when you get into the Designer, you're giving somebody access to a full development IDE with the ability to execute scripts at the permission level of the user running the Ignition service, and so it's often preferred to have a separate development system with a limited number of people who can migrate changes into a production environment. But, by default all the users with Designer access can modify, delete, save and publish all resources, but Ignition has several built-in Designer restriction methods to limit what each user can do in the Designer as well.

34:37
Kent: Tag security, the best way to configure security for data access to do it directly on the tags because when you apply at the tag level, it'll automatically carry across to all windows and components for that specify the tag in the project, and you can also add read-write security to individual tags to the Designer. Another security measure is through Named Queries, so Named Queries here are talking about the interaction with the database, and that can be limited to defined queries on the Ignition Gateway, which can be called from clients based on the credentials of the user. And so essentially you're creating functions that you can call that are queries rather than writing all the queries in line and inside your scripts and your buttons and so on.

35:21
Kent: And it's recommended to just use parameters to allow for dynamic database interaction, voluntary and only relevant data is accessible, and this can also be turned off if needed to allow any SQL query to be run directly from an open client, but doing so potentially leaves you exposed. Step six here is Setting Up Audit Logging, so Audit Profiles allow Ignition to record details about specific events that have occurred, and they keep track of who did what, when they did it, by default, we have some things listed here that are recorded. There are actually more things that are recorded, and if you go on to our usermanualdocs.inductiveautomation.com and you do a search for audit reference, it will have a list of every single thing that gets audited inside the Designer, inside Clients and Sessions, inside the Gateway web page, and so on, and so. Lots of good information there for you to check out.

36:20
Kent: It's also worth noting that this is just written to a standard SQL database, and as such, it's extensible, so we do have scripting functions where you can create your own audit-able events inside your applications, and then also you can just write to the database directly as needed. Step seven here is Protect the Database, and so Ignition does not ship with a built-in database, instead you connect up to a SQL database of your choice, and then you connect Ignition to it. For Ignition connecting to the database we do need certain privileges, being able to create tables and altar tables and things like that, but we don't need a full database owner account such as root or sa so we recommend creating the specific user just for Ignition to connect.

37:07
Kent: You can also do mixed authentication and things like that for a Windows user, and so on. Another big thing is any time we're connecting to anything, we keep talking about using encryption, SSL, TLS encryption there between your Ignition server and the database, and as you do that, the actual method is gonna be a little different for each database. And so you're gonna wanna look at the information around your databases, JDBC driver and its internal security settings, but generally there's a separate port, a secure port, and then maybe there's an additional flag you put into your connection screen that goes in and alerts them that you're connecting SSL and encrypts all the traffic.

37:48
Kent: Step eight is Locking Down the Operating System, because Ignition is a distributed development environment, that means, once again, like I said, when somebody gets access, they can do a lot within the environment. And so as we mentioned before, Ignition Privileged Users, are users who can directly or indirectly modify projects in the Designer and in the Gateway, and these people are able to write Python applications that will be executed on the Ignition Gateway with all the privileges granted to the Ignition process. So just be aware who you're giving that level of access to and use a separate dev environment as needed, but it also means that we should take a look at the user that is running the Ignition service 'cause Ignition is designed to run 24/7 with a persistent OS. Means entrusted communication protocols plus connecting to devices and databases, and so as such, it's running as a service and you can specify an account that runs that service.

38:45
Kent: And so for this, it's important to apply the Principle of Least Privilege, and consider the following tips; don't use root or domain admin accounts for your Ignition service account, minimize the privileges of the Ignition computer and the service account on the larger network, minimize Ignition permissions on external databases and systems and keep in mind the API access is often safer than direct access, and then finally, segment your network with zones and conduits and accreditation boundaries. Also for your OS, this is just Security 101, remove all unnecessary programs 'cause each program is a potential entry point for an attacker. Removing unnecessary software and having a vetted list of allowed software can limit vulnerabilities. Not all programs require administrative access and should be run using the minimum credentials required. And to limit operating system vulnerabilities, certainly keep up-to-date on OS patches and service packs. And for remote services on Windows, remote registry and Windows Remote Management should be disabled and on Linux and macOS you should often disable root for everything, but ‘physical’ console.

39:54
Kent: Step nine is Hardening the Environment, and so this is looking broader on the network here, so a firewall should be in place to restrict network traffic, and when you're starting a new Ignition project, close all the ports and only open those that are necessary and in use. And as your architectures get more complex, it's important to pay attention to which ports need to be open and in which directions. You may also be able to restrict traffic through the firewall to specific servers. And a couple architectures to keep in mind would be, one, redundancy, really common with Ignition, that you have a redundant server and redundant servers are connected up over our Gateway network. There should be a firewall between these servers and then you just need to open up port 8060 between those, our Gateway network port. That's the default port, you can certainly change that port as well, but you should restrict access that only those servers can talk to each other over that port. You reject communication from other sources.

40:53
Kent: And then the other architecture I wanted to mention briefly was this DMZ architecture. And so a DMZ, or “demilitarized zone,” contains a sub-network to accommodate exposed outward connecting services as ... And acts as a point of contact that buffers the organization's internal network from untrusted networks, such as the internet or maybe just a broader business network. And so adding a DMZ in the middle can add an extra layer of security to the network. Ignition certainly is compatible with DMZs, whether that's just network routing going through that, or you put Ignition as a proxy in the DMZ. There's lots of ways you can handle that, but certainly something to consider. And our last step, Step 10, is Keep Ignition Up-to-Date. Inductive Automation recognizes that software security requires constant effort and maintenance. Security updates are released periodically to ensure continued protection and keeping up to date with these updates is strongly recommended. And this is evidenced by what we talked about today with the Pwn2Own event and different articles that have been released in different publications.

42:01
Kent: And so we are constantly looking to improve the Ignition software, but that only helps you if you install those updates when we release them. And so this is true of any software, updating your software is your best bet. I know that there's hesitance inside the OT space at times, people want to... If it's not broke, don't fix it, don't touch it. But there are certainly things you can do with redundancy and other things like that to make it so that you can still have upgrade cycles without causing a bunch of undue downtime. Highly recommend you stay up-to-date. If you follow these 10 steps, you can be confident in the security of your Ignition system. Another thing you can do is sign up for an account with Inductive Automation and set your email preferences and subscribe to our Security Newsletter to stay up-to-date on the latest in our security. And there's a link to those preferences, if you're not sure if you're signed up inside the Security Hardening Guide, so you'll be able to click on that and make sure you're subscribed to that Security Newsletter. With that, Don, I'll pass it back to you.

43:09
Don: Kent, thank you very much. You've covered a lot of ground. I'm also gonna ask you while I'm just doing a couple of update slides here before we get to Q&A, but look to the Q&A. I highlighted some questions I think you and Joel wanna answer. First off this, you mentioned this more than once, a lot of information today and collected in the Ignition Security Hardening Guide, you can read it and download it at the link on your screen there. In addition to that, if you happen to be by... Never tried Ignition, go download it. Ignition 8.1.17 takes about three minutes. You can use it in trial mode as long as you want, absolutely free. Once again, we recommend that all Ignition users update to 8.1.17 or 7.9.20 to get the latest security features. Also, of course, once you've downloaded Ignition, we've got a free online training website called Inductive University. You can learn all about how to use Ignition, there's hundreds of free training videos there. You can learn Ignition step by step at your own pace, and was also mentioned here by Kent a couple of times, we've got a comprehensive online user manual they can use to refer to at any time.

44:20
Don: I would be remiss if I did not mention Inductive Automation will be hosting the Ignition Community Conference. This year we're giving you two ways to attend. You can attend the live in-person event on September 20th and 21st here in Folsom or virtually or both. Virtual is October 3rd through the 5th. The virtual event will include exclusive workshops for those of you who want some technical training on more complex topics. Our registration page will be up in the next week or so, so keep an eye out and register and sign up when that happens. I also wanna mention, 'cause there's a lot of attendees here from around the world, outside of North America, we want you to know that we have a network of international Ignition distributors who provide business development opportunities, sales and technical support in your language and time zone. If you wanna learn about the distribution in your region, please visit the website or contact our international distribution manager, Annie Wise. With that we are at the Q&A section here, so Kent, I can read a couple of questions here. I also ask you to maybe look at ones you might wanna answer. We got quite a few, so I think, well, I'll just do a couple and then you can also say if you wanna take a few that you noted. Does that seem okay with you?

45:37
Kent: Sounds great.

45:39
Don: Okay, a couple here. For this one says, I have a quick question when time allows; When accessing a rest API using system.net, what secure communication methods does Ignition support? From what we've seen HTTP basic is the most commonly supported authentication method, but it requires a plain text username/password. Is there a secure way in Ignition to store those credentials? What are other authentication options?

46:07
Kent: Yeah, what a question. Ignition has a couple of ways we talked to rest APIs. As far as how those are stored in Ignition, Ignition doesn't have a store currently of where you can put credentials and leave them encrypted and things like that. That is something that we've talked about adding. But yeah, right now they'll be put inside the bindings and they get stored to our internal database which is obfuscated. Yeah, I would say in the future, we are looking at additional options for how you could store credentials like that inside the Ignition system for talking to all kinds of things, but ... Joel, any comments there?

46:49
Joel: Yeah, I agree, I think this is something that is lacking right now. We don't have good first class support and scripting for, "Here's where you should store your secrets and then here's how you retrieve them securely." We kind of... It's kind of put off to the user to build scripts to fetch those secrets themselves in a secure manner. And ideally, you wouldn't just embed them in your scripts because secrets in code is generally not a good idea. So that generally means using our scripting functions to retrieve the secrets either from a vault, HDP endpoint or a database somewhere, where you have to decrypt it during runtime. It's not great right now, unfortunately.

47:36
Don: Thanks guys. The next question, I'll see if I can get something that maybe you can give some quick answers to, but you gotta decide that yourself. Here's one; If you have multiple databases, is there a way to select the database, a named query executes against dynamically?

47:50
Kent: I believe that you can pass in the database, if you put the database inside the query itself and then you don't specify. You should reach out to us, to support. Support would be able to help you with that. But yeah, I know I've seen that done. Yeah, it involves putting it inside the SQL itself and passing as a parameter, so we'd be happy to go over that with you guys some day.

48:06
Don: Here's another one here; Can the project properties be updated to take Security Levels as well as Roles? Currently, this seems to be the only place where Roles and Security Levels are not interchangeable.

48:21
Joel: Yeah, there's currently... Certain areas are Security Level aware and compatible. Perspective, for example, Tag Security, but then there are certain areas that are still... They were built to be Role-based. Say Vision, for example, Vision's permissions model is still Role-based and Security Zone-based, therefore, upgrading that to Security Levels is not something that will be easy and it's also risky. So it hasn't been done yet. I'm not sure if or when we'll do that, but yeah, so you're gonna see a mix.

48:57
Don: Thanks, Joel. Can Ignition use any LDAP IDP or is that only Microsoft Active Directory?

49:07
Joel: It was built for Active Directory however, I have seen customers successfully use open LDAP before using our AD profile. We didn't really build it with that in mind, but we did kind of use generic LDAP APIs so just kinda test it out and see if it works. If there are things that are lacking, just make us aware so that we can improve it. You can post an idea in the ideas forum if you want us to support a specific type of LDAP product, and if there's enough demand for it, we'll certainly investigate it.

49:47
Don: Thanks Joel. This one might be for you, Kent. You stated the connection between the Gateway and the Edge Gateway was secure. Can you talk to how it is secure?

49:58
Kent: Yeah, so an Edge Gateway will publish up to a central Ignition system over one of two protocols. It will either use our Gateway network, which is a proprietary Ignition to Ignition protocol that goes over a single port and that's encrypted and you approve certificates on each side for that communication. Or it'll use MQTT; which also can leverage certificates and access control limits and all that kind of stuff that we talked about before. That does go to a broker, and then the central Ignition system subscribes to that. But both of them are using an encrypted path and are using certificates, which is gonna be much more secure than, say, pulling a PLC over a broad network that doesn't support any encryption and all that. You're having to set up a VPN tunnel or something like that to try to have traffic encrypted. It's not ideal, so yeah, Gateway network or MQTT, both encrypted.

50:43
Don: Cool. So Kent, I asked you to look at some questions. You see the queue is long. Do you have a couple you might... We only got a couple of minutes left here and then we'll get to the rest after the webinar. But do you have a couple three you wanna sort of answer and take us to the end here?

51:00
Kent: So somebody asked: Does updating cost money? And we have support contracts. When you're on support contracts, upgrading to major versions is always free. If you're not on a support contract, minor version updates are free, so going from 8.1.16 to 8.1.17 or anything along the 8.1 line would always be free. But for major versions, in order for that to be free, you do need to be on a support contract. Well, we appreciate you guys had lots of questions. Are we pushing our third party module providers to update and be compatible with 8.1.17?

51:32
Kent: Absolutely, we've been collaborating with them, just trying to make sure that there's support. That's also one of the reasons why we don't release all the details right now, we do a delay on some of the details of these things so that... Yeah, all the different modules, all the different solutions out there can all be updated and supported before a lot of information is out there for potential hackers. Final question here; Will Ignition follow IEC 62443 guidelines? Great question. We're actually in the process of that right now. We just got our gap analysis back and we're doing any final things there, and then we will be... What was it called? 4-2 compliant, I believe is what it's called. But 62443 is certainly something that's an active... It's an active effort for us right now, so, good question.

52:20
Don: Thanks, Kent. Thanks Joel. Totally appreciate everyone's time today and interest. Repeating one last time that we will follow up and get to all your questions, so they will get answered. Appreciate very much the interest in this, it's obviously critical to us too, that's why we wanted to do it in this format. And I think with that, all I have left to say is, thank you. Stay connected to us on social media and subscribe to our newsfeed and have a great day.