Changing Your Perspective on Security

Speakers

Jason Waits

Chief Information Security Officer

Inductive Automation

Travis Cox

Co-Director of Sales Engineering

Inductive Automation

Joel Specht

Senior Software Engineer

Inductive Automation

As cyber threats against industrial control systems increase, security becomes a more urgent priority with every passing day. At Inductive Automation, we’ve always worked hard to improve security by bringing tried-and-true IT features into the domain of OT. To keep your system safe, however, you need more than the right features: you also need to have the right mindset and take the proper steps to prepare before implementing a solution.

In this webinar, Inductive Automation’s top security experts will discuss our company’s approach to security and the steps that we recommend users take. They will also show you the security features of Ignition Perspective, such as encryption, federated identity, and the new permissions model, which allow you to easily build mobile-responsive, pure-web industrial applications and deploy unlimited mobile clients in a secure manner.

Whether you’re a developer or an operator, the concepts shared in this webinar will expand your view of security vulnerabilities and solutions.

• Watch a demo of security practices in action
• Learn how to enable SSL encryption
• Find out how to set up authorization
• See how to create access levels

Webinar Transcript

0:00
Jason Waits: Hello and welcome to today's webinar, “Changing Your Perspective on Security: Strengthening Security Procedures with the Ignition Perspective Module.” I'm Jason Waits, the Cyber Security Risk Officer here in Inductive Automation and I'll be the moderator for today's webinar. I'll briefly introduce you to our Ignition software and the other speakers, then we'll talk about Inductive Automation's approach to security, security features in the Perspective Module and four steps that we recommend taking, including enabling SSL for encryption, setting up authorization, enabling auditing, and identifying access levels. We'll give you a short demo of each of those processes, then we'll finish up with a Q&A period. 

Jason: Our software platform, Ignition, turned 10 this year and it's used by 54% of the Fortune 100 companies. Many companies are choosing Ignition because it provides a universal industrial application platform for HMI, SCADA, MES, and IIoT. It's got an unlimited licensing model, cross-platform compatibility, IT standard technologies, scalable server-client architecture. It's a web-based and web-managed with a web-launched designer and clients, modular configurability and rapid development and deployment tools. You'll learn more about Ignition at inductiveautomation.com. 

Jason: The panelists on the webinar with me are Travis Cox and Joel Specht. Travis is the Co-director of Sales Engineering here at Inductive. He started with the company in 2003 and previously served as Director of Training and Director of Support. Joel is a Senior Software Engineer here at Inductive. Since 2017, he's been a part of the core Ignition product development team and he previously worked as a software engineer in security at Cisco. So, Travis, Joel, can you tell us a little more about yourselves and your role in security for Inductive Automation? Let's start with you, Travis.

1:37
Travis Cox: Alright well, thank you, Jason. I'm happy to be here. So, my role in Sales Engineering is we work with end users and integrators directly on putting best practices in place in architecting systems, as well as overcoming any technical challenges and we are very focused on security, and a lot of questions come in from customers on security. And so, we really are happy here, so we can show the best practices that we're putting forth and the customer is using every day.

2:03
Joel Specht: Thanks, guys. Hi, everybody. I'm Joel Specht, I'm Senior Software Engineer here at Inductive Automation. I am on the core Ignition product development team and with the focus on security. I'm responsible for the design and implementation of identity providers and security levels. I maintain these, as well as other features such as user sources. I am also typically involved in handling any new security issues that come over our way and providing guidance on how best to defend against certain vulnerabilities or sometimes fixing the vulnerabilities myself.

2:37
Jason: Awesome, thanks, guys. So, as for my role as Cyber Security Risk Officer, I'm currently responsible for the overall security vision, strategy and policies for Inductive Automation and Ignition. My duties include security engineering, security analysis, threat hunting, digital forensics, and incident response and penetration testing.

Our Approach to Security

Jason: So now that we've introduced ourselves, let's get into today's topic, security. Over the past decade, security and technology has been a hot button issue, to say the least. With the rapid acceleration of technology such as the internet and mobile devices, apps and cloud solution, data drive is so much of what we do today. A lot of this data is sensitive and requires extra measures to keep it safe. The growth of such technology also brings with it increased security threats from many sources such as cybercriminals, malicious or negligent insiders, organized crime and foreign governments, intelligence agencies or militaries. The security threats come in many forms from such as phishing, malware and ransomware, account takeovers, data breaches, supply chain attacks, rogue devices, denial-of-service and many more.

3:35
Jason: Inductive Automation takes security seriously and I'm here to ensure that we follow the best security practices. We are committed to lead the industry in security best practices and provide education and resources that help our users be as secure as possible. Our approach to security is to bring the best practices of IT and to bring it into the world of OT. One example is building the Ignition using Java. Java offers protection against many classic attack vectors and because it's the most popular language, it benefits from a high level of attention, research, and scrutiny. These are secure software development lifecycles and we put a lot of effort into building security and quality into our development process. This ensures that we find any issues before a build hits production. We utilize many tools in this process, including software composition analysis to warn us about vulnerable libraries that we're using, we use static application security testing tools to warn us about coding flaws and dynamic application security testing tools to find vulnerabilities and weaknesses like cross-site scripting or SQL injection. Additionally, the software development department provides a code and development guide to all software engineers which has been written to provide guidelines and best practices for all developers of all levels.

4:40
Jason: We also hire external firms to do annual penetration testing of both Inductive Automation and Ignition. So, a common adage in security is that the detection and response are more important than prevention. Since no security controls are perfect, it's paramount that we can detect and respond to any issues as fast as possible. The development team has worked hard over the last two years to refine our build process resulting in faster and more secure releases. We also post nightly builds on the website which allow us to quickly roll out security fixes if necessary. Having the mechanisms and infrastructure to effectively respond is the other half of the equation in leading the way in security. As an example of our commitment to quickly respond to security issues is the recent S4 Pwn2Own ethical hacking competition. Since Ignition was one of the industrial platforms being tested there, we sent a team of developers to analyze the results once the competition was completed. For each vulnerability that was identified, our team analyzed and responded with a fix within hours.

5:35
Jason: By the end of the conference, we delivered an early-access build of Ignition with the competition's organizers and teams and made it available on our website and then pushed it into version 8.0.8. Due to our processes and commitment to security, we were the only vendor to respond and address the discovered issues within a week. We do everything we can to provide our users with tools to implement security, but we also like to educate our users about the basic security steps that they should follow. We have an Ignition Security Hardening Guide that provides users with guidelines and suggestions to protect and secure an Ignition installation. You can find the hardening guide in the resources section of our website under articles. We encourage you to review it. So now that we've explained our overall approach to security at Inductive Automation, let's take a deeper dive into the specific features of the Perspective Module. To talk about that, let me turn it over now to Travis.

Security in Ignition Perspective

6:23
Travis: Alright, well, thank you, Jason. I would like to go over the Ignition Perspective Module in more detail. The module adds a lot of flexibility and adds a lot of power to Ignition and we from the very beginning, built Perspective with security in mind. So, first, let's talk about the purpose of the Perspective Module which we released last April. Perspective is all about making it easier than ever to turn data into action. It's an ideal tool for building mobile-first applications that are native HTML5 and CSS.

6:55
Travis: Perspective lets you design applications for any screen size. You can streamline your development process with robust design components. You can design for mobile, desktop, and display screens all at the same time. And you can easily customize user experience with mobile optimized container types. Perspective puts your manufacturing and plant operations at your fingertips. You can run it on any modern browser, and that could be on phones, tablets, laptops, desktops, TV screens, or any smart device that has a modern web browser. You can see your entire system at a glance. You can control it with intuitive touch commands. And you can complete instantaneous plant floor control with bidirectional data binding. Perspective lets you add the magical versatility and convenience of mobile devices to your applications by leveraging the native apps for iOS and Android. With that, it's the wrappers around the browser that lets you leverage the GPS, accelerometer, camera, barcode scanner, touch gestures, and many others that the phones can provide.

8:01
Travis: You can create the next generation of smart industrial applications by extending it to those devices. Perspective runs on any device, you can easily deploy an unlimited number of Ignition Perspective sessions from any location with a single click. The licensing model for Ignition is unlimited and that goes for everything. And it's easier than ever to get a Perspective session open: Simply open your browser, point it to a URL of your server and you have the application available. You can even send secure web links through applications that anyone can use and click on to get access to it in their browser. Along with all these mobile-first capabilities, we've built the Perspective Module from the ground up with modern cybersecurity in mind. It supports industry-leading protocols and standards. It's compatible with many federated identity providers, such as OpenID Connect and SAML. I'm gonna go into more detail on those. It supports two-factor authentication, and has a permissions model that allows you to secure Perspective apps with flexibility and ease.
 

9:05
Travis: So I wanna take a deeper, closer look at how Perspective was constructed. We don't often get to go through some of the underpinnings of how Ignition is built. But I think it's very important to understand that to really get a sense of how Perspective was built with cybersecurity in mind. And this is how you can contrast this to any traditional client that communicates through the server. So with Perspective, we are simply using our browser to open the application. And we're going to a URL, an IP address or a host name of the server to get access to that. And the entire application is running there in the web browser. You're very familiar with this by going into any cloud application or web application that you may have. And you're seeing all of that, interacting with that in your browser. Of course that session though, in the browser is communicating back to that server to get information. And that's no different here for Perspective. But with Perspective, it's very limited in how it can interact with the Ignition server. So when you open up an application you built, typically the first thing you're gonna do is go and log in. You're gonna establish a session with the server, so we can verify who that person is before we can grant any access to any data.

10:24
Travis: Once we've established that session, basically, the entirety of that application is, it lives on that Ignition server, from the page that we're on to all of the components, the properties, all the events, everything that's gonna — all the models of that screen will be represented in that session. And as you can see in the diagram here, there are only two points where the actual session interacts with the Ignition server. And that is one for synchronizing properties. So if we have a tank level that is bound to a tag, we wanna make sure that as that tag changes, that we synchronize that property to the browser so that of course, we can see the proper level indicated there, or vice versa. If I were to go and write to a tag to change the set-point that we want that, we wanna let the server know that, "Hey, I've changed this particular value." And we only do that through property syncs. And it's a really important distinction here because once we synchronize that property, there's a whole layer, or sets of layers that are there to protect whether or not that can actually occur down to the device.

11:36
Travis: So there's a lot of protected things that the Ignition server is talking to, things like PLCs, or other devices, databases that it's working with, other Ignition servers through the gateway network, of course, the operating system itself, any other projects or files that may exist on there. There's a lot of things that the server is talking to, and you wanna protect those connection points as much as possible. And so we don't want to expose any of that to the actual person that is using the application in a day. And that is not how it works here. Perspective has this whole layer of security that's right in front of all those protected resources. And when you establish that session, you are doing that, and we know who that person is. And we know what levels they have. We did that through our federated identity providers, which we're gonna go into more detail here. And so as they synchronize a value, if I was to want to try to write to a tag, that has to go through this layer, to on the server check whether or not they are allowed to do that. And if not, it's rejected.

12:40
Travis: There's no way for that browser session to be able to do that. So that's one way where we can really restrict what people are allowed to do and how that interacts with the server. Second, is that there are also events that we wanna respond to. So somebody may click on a button and we want to have it do some action, or they may wanna navigate. Or of course, we may have them upload a file. We want to know that the file was uploaded and events are also sent to the server so that we can respond to those events with various handlers and maybe go off and get data or do something with that. And so these two areas are very, very low risk. And as you can see, they're going through a TLS secure tunnel, essentially, so that there's no way that a bad actor there could inspect what's going on or inject something different.

13:32
Travis: Or do something that's harmful in that way, and we're gonna talk more about TLS here in a moment. So the architecture, the way Perspective was built, really we thought about security from the very, very beginning. And the most important thing is to protect these resources over here so that there's no way for a bad actor to be able to get access to that without going through these really secure layers and having the verifications that are in place.

Step 1: Enable SSL

14:03
Travis: So there's a couple of things that really make this happen and that in order to have this picture in the most secure way, you have to enable some features inside of Ignition. So we're gonna walk through some of these important security steps, and there's really four things that we recommend you do on the Ignition server, and that is to enable SSL, second is to set up proper authorization systems, third is to enable auditing, and fourth is to identify access levels or permissions for who can do what in the application. So let's first start with enabling SSL. So in that diagram, we had a few moments ago, you saw that secure tunnel between the browser and the Ignition server, and that secure tunnel is SSL and it's HTTPS.

14:50
Travis: And when you go to any browser, any web application in the cloud, if you go to log into your bank, whatever it might be, you and your browser will see HTTPS and you'll see a green check up there that lets you know that you can trust that connection and that you can enter in sensitive data, like your passwords or your credit card information or whatever it might be. In fact, your browser makes it very clear if it's not secure and you shouldn't trust it and it makes you go through extra steps if you wanna get access to it because there are potential vulnerabilities that exist if you go through untrusted connections. So, turning on SSL in Ignition is actually quite simple, and it's really something, it should be like the first step within the system. And that is what allows it to run on port 443, that's kind of the default port for HTTPS. You can change that port in Ignition if you'd like, but that is the port that is standard, and then that way with firewalls, that is what IT departments already lock down. They lock down these servers to only that port, so that the only way into a server is over that secure connection and have that one point of access. So to show you how we can actually enable SSL in Ignition, I'm gonna turn over to Joel to demonstrate that.

16:07
Joel: Thanks, Travis. So, before I switch over to Ignition, I'm just gonna talk a little bit about what our goal is here and what the process is to get to our goal. So our end goal is to turn on SSL and TLS in Ignition. We need a certificate trusted by the web browser in order to do that. Web browsers, they trust a certain set of certificate authorities and so we need to build a certificate signing request, and present this to our certificate authority of choice, and then the CA will review our CSR and make us prove ownership of our domain name and finally generate a certificate chain which we can install into Ignition to turn on SSL and TLS. The certificate chain builds a chain of trust between Ignition's certificate and the root certificate authority trusted by browsers. You can think of a certificate as a driver's license or other type of ID, and the certificate authority as the DMV or the issuer of the ID to kinda get a sense of what these things are.

17:18
Joel: So I'm gonna switch over to Ignition now to demo this. So we're gonna go to the Ignition config page here and log in, and we're gonna go over to the web server page here to configure SSL and TLS. Here's where you set it up, you can see it's not enabled right now, so we're gonna fix that. So we go to set up, and in the beginning here, we don't have the certificate chain from the certificate authority so we need to generate a certificate signing request, and Ignition will help us do that. So we'll say here, "I don't have the items above," and then we have to fill out a few required fields in order to generate the request for the certificate. So the first thing is the common name and the common name is typically the domain name where Ignition is installed, so in our case, we have a secure.ia.io, so we're gonna go ahead and put that in the common name. We'll tick away the protocol there so it's just the name.

18:25
Joel: The organization name, that's typically your company name, so I'm gonna put IA for now. This is usually the department under your company, so I'll just put software engineering. And then the only other required field here is Country, so I'm gonna put just “US” here. And then I'm leaving everything kind of defaults. We have pretty secure defaults in here. So we have more details on these settings if you wanna do some advanced configuration in our documentation. But down here, the subject, alternative names, we need to put the IP address that our domain name maps to as well as sort of copy our domain name again under the DNS name. So what we do here is I'll put that DNS name here, and hit add and that adds it here and then our IP address, we have as well. So I'm gonna go ahead and grab that and place that here, hit add. So now you can see we have those added.

19:31
Joel: If you have additional IP addresses or domain names that could be used to access your Ignition installation, and you want the certificate authority to sort of sign off on all of those, then you can enter additional ones here. For now, this is all we have, so I'm just gonna hit generate certificate signing request, and you'll notice that you have a file here, the CSR file that was downloaded from your browser. And so this is a step where you go to your certificate authority, you take that file and every certificate authority sort of varies in their process in what they're required to prove ownership of your domain. So that's sort of out of scope for this demo. I just wanted to show you that first step. And then now we're gonna show you the steps that you take once you have the certificate chain from your certificate of authority after they've vetted the process or the request, and they've given you that chain. This is where we upload this and install it into Ignition to turn on SSL and TLS. So this time we say, "I have all the items." The private key that was part of the certificate signing request is already installed in Ignition and it's safely stored there. So you don't have to worry about that. We just need to upload our certificate chain.

21:01 
Joel: So we start with the server certificate. I'm gonna drag and drop that into this area. Ignition validates that it matches up with the private key and it does, so that's good. We then have an intermediary certificate, and then finally, the Certificate Authorities certificate there. And so this is your chain of trust starting with the server certificate signed off by an intermediary which is then signed off by the trusted root certificate that browsers trust. And so we'll hit continue. And now, you can see that SSL and TLS is enabled. You can see in the browser now, we have the walk there which indicates that the connection is secure. You can see the certificate chain here. In our case, we used Let's Encrypt as our certificate authority. And so now, it is secured. And the other thing I will show is there are some settings down here where you can set the ports for HTTPS. So this is the standard 443 that Travis was mentioning. But right here is this forced secure redirect check box. I'm gonna go ahead and enable that because what that does is, if somebody were to try to access Ignition over just the plain HTTP port 80 which is not secured, Ignition will just redirect that person to the secure HTTPS 443 port. So that way, you can ensure that all traffic is going to the secure port. So I'll hit save there. And now, that's all set up. So I think we're all good with our secure communications. And back to you, Travis.

22:44
Travis: Alright. Well, thank you for that demonstration. One: A couple of important things to note with that is that that one step secures the entire Ignition server. So any connections into that server, whether that is a Perspective session, that's a one access there or the Gateway Interface that we have directly for the configuration or the designer, of course, that gets access, or even of course, Vision clients. All of the connections to that server are gonna be secured and encrypted. So it's just one step to put in place that really can protect you. Now, you mentioned in that, Joel, about the CSR taking it to a security certificate authority. I just wanna mention that there are certificate authorities that you can purchase from, that he was mentioning. But a lot of the industrial organizations, their IT teams for Active Directory are their own certificate authority. And we can bring that to those teams, and they can generate those certificates that we can bring on. So they add themselves in your network, they add themselves as a trusted authority so browsers know that they're good, and they're the ones that wanna be responsible for managing all of those certificates. So just a couple of things to look at. There is where you wanna get it, but it's a really important step as you can see, very, very simple to set up on that.

Step 2: Set Up Authorization

24:02
Travis: The second part is setting up authorization. And so this is, now, we've got the server encrypted, we've got to figure out who is gonna be accessing the system, how are they gonna be logging in to Ignition? And there's two different kinds of users in Ignition. We have people that are accessing the configuration environment. So that's our web interface, as well as the designer so they can make changes or they can maintain the system. And typically, that is only for a very small select few of people or maybe vendors who are actually doing that. And you wanna protect that probably separately in terms of who can access. Then of course, the applications that you're putting in place. So that's the other kind. The projects you're building, you're going to allow people to log into that. And you are in complete control of what authentication systems you wanna use and how you want to lock those down.

24:48
Travis: But one of the great parts about Ignition 8 with Perspective is that we have now the ability to use federated identity providers. And these are providers that provide a single source of truth for the users. It's one place. And so, this is where we are all used to Active Directory. Active Directory was a great way of having a single source. And all of our computers, our applications can use LDAP to query into that and that's a great way. But now, a more modern approach is to use a federated identity provider. And Microsoft has ADFS. ADFS, there is Okta, Duo, and many others. And chances are your organization already has one of these providers in place for all the business applications that you have. So if you're accessing maybe your Google or your Gmail account within your organization or accessing some other systems, they would want all the authentication to go through one system. So there's a single source of truth and it's... Provides single sign-on as well. So you can log in one place and have that, and access any application in your organization.

25:52
Travis: It's a very important thing to ... And a very secure thing to have set up because it does also provide two-factor authentication. And that is that it requires two forms to verify the user's identity. One is, of course, the username and password to get access. And the second would be sending a push notification to their phone that they have to accept, or a PIN that was emailed to them or sent as a text message. That they could enter in that PIN to be able to gain access, or in some cases, a YubiKey or something they have to plug-in that provides that second form. In all these cases, the having two forms give us a much better piece of mind that we are, we know who is getting the access to the system, and we can lock things down appropriately based on that. The days of having a shared accounts or something like admin-admin or operator-operator, that needs to go away.

26:47
Travis: We need to have every single user have their own authentication so that we can know who's getting access and we can lock it down appropriately and we can also see... If you go look back in history, who did what? And it's very important for everybody to have theirs. And this is a really easy step to make that happen. And we're used to this in our personal lives where we can use Facebook to log in to other websites, that is a federated identity system, and you can also piggyback on some of the systems within Ignition, but it just makes it very, very simple to get access and the simpler we can make it means that users will actually log in as themselves. And so it's a really important step here and right now our federate identity providers only works for Perspective, but we are in the process of bringing that back to the rest of Ignition so that we can have it with the Designer phase or Vision as well. But to show you how to set up federated identity providers, I'm gonna turn it back over to you Joel.

27:44
Joel: Thanks, Travis. Go to the identity providers area here within the config page and we're gonna go ahead and create a new identity provider. And so, Ignition supports three types: There's the Ignition type of identity provider which is sort of just a loopback into Ignition itself and its user sources as a way of authenticating. So it's kind of an internal identity provider. We have two main well-known standards that we implement. So there's OpenID Connect and SAML. We're gonna go with OpenID Connect. And so the identity provider we're using today is Okta, so I'm gonna give our identity provider name of Okta here. And then there's a bunch of configuration here below, sort of technical details here that can be automatically filled out for you, other than your credentials here to connect with Okta. So the way we can speed this up is we just provide a metadata URL here pointing to your Okta account, and once you hit import it'll actually fill all that stuff out for you. So let me demo that. Let me grab the URL here, and then we'll hit import. And you can see it was successful and here's all the details that it filled out so you don't even have to worry about that.

29:15
Joel: The only two important details you need to add are the client's ID and the client's secrets, which is sort of like the username and the password for Ignition as a client to Okta. So I'm gonna go ahead and fill out those details now. And you get this information, typically, when you register with Okta. They'll provide these details for you in your Okta account. So there we go, filled that out and we're good to go. So I'll hit save and it's been created, so now we can do a quick test. This is a nice feature we added here so that you can verify that the connection to Okta actually works. So we'll hit Test to log in, and you can see it redirected us to Okta's website. So I'm gonna go ahead and log in as one of our users in Okta. And this is the two-factor authentication step that we've configured in Okta. So this is how we do 2FA. And so, in this case, we have a push notification set up and the user is configured to push to Travis’ phone, and so Travis has to actually accept the login from his phone in order for us to log in to Ignition. So let's go ahead and send the push to his phone.

30:40
Travis: And you can't see this part, but it just gave me a notification and I'm gonna say, "Yep." Did you just try to log in? Yep, that's me and so I accepted that and it should allow us to get in.

30:50
Joel: And there we are, we're in. So this is some technical information as you're doing any debugging that you need to do with the connection to Okta. This is OpenID Connect response information, but over here you can see the mapped user information. So you can configure the identity provider to get the first name and last name and other details from the identity provider as well as any security levels that were granted to the user. So with that, I think I'll pass the mic over to Travis for the next demo.

Step 3: Enable Auditing

31:26
Travis: Alright, well, thank you, Joel. So as you can see, turning on the identity provider is quite simple and is powerful. Especially working with Perspective because you can leverage that single sign-on and use the ... Leverage that provider that your entire organization is already using for all the other applications that are there. And so once we have ... Here we've shown SSL was to encrypt the server, the connections to the server, we then have a proper authorization system, where we at least thought about how we're gonna activate or how we're gonna, sorry, log in to the system. The third is to make sure that we are auditing what people are doing in the system. And this is one that often gets neglected. It's a really simple thing to set up in Ignition and is a built-in feature that we can turn on and we will audit all of the important auditable types of actions. So from people attempting to log in, whether they're successful or unsuccessful, if they're logging out, if they're writing to tags or writing to databases or executing reports or if they're in the Designer phase and they're saving their projects or they're publishing things or if they're modifying tags and/or if they're doing anything on the gateway, any gateway scope action that needs to be audited. So there's a lot of auditing. And we've recently increased or have added a lot more functions or features to the auditing system in Ignition 8, starting with 8.0.7 going forward.

32:47
Travis: And it's, like I said, easy to turn on. So to demonstrate that I wanna give you a sense of how you can go from scratch, how you can get that working. I'm gonna come back here to our gateway interface. And on this server, under security, is a bunch of security related settings, we talked about the data providers already there. And you can see there's auditing here. And so this is where we can create an audit profile. And I'm gonna go ahead and do that, create a new profile. And our profile will store all the audit events in an external SQL database of your choice. So you can do MySQL, Microsoft SQL Server, Oracle, Postgres, whatever database you'd like. And ahead of time, I already created a connection to a MySQL database. So it's a blank database in there. Once we create this provider or this profile, it'll automatically create the table for us and start logging the events. So I'm just gonna go ahead and go next. I'm gonna call it audit, going to that MySQL database and this is a table that we're gonna create for you automatically. Go ahead and create the profile and that's it.

33:46
Travis: Now you've got the profile ready to go. And there's two important places in Ignition, where you need to set up the use of that profile. And the first is on the gateway. So under gateway settings, there's the gateway scoped actions that we need to set up. And for that, all we got to do is simply put in the name of that profile here under the gateway audit profile. And so I actually had that in already ahead of time. But you just type that name in press save, and now all the gateway scoped things will get logged automatically for us. And that's the first place. The second place is within the projects that we're building. And with this, I already had a project created ahead of time called demo. And we can actually go in and attach auditing to this project, or to all of our projects that we have, and use that same profile. And we do that in the actual designer. So let's go into our designer launcher. And now that Joel set up the HTTPS on the server, I can actually use my designer launcher to go to this, over the security port there. So launching this, the communication to that server will be encrypted, which is great. Now I can go ahead and log in.

34:53
Travis: Go into the demo project that we had. And with that, I go up here to our project properties and simply under the general, I can enable auditing, I can select the audit profile. And now that project is ready to go. I'm gonna go ahead and save it. And in fact, anything we do will now be audited. So just by doing that, if I go look real quickly at my database, there's a little query browser we provide inside of Ignition, I can see the audit events table and in fact, there's gonna be a couple of rows already in there because I did a project update, I modified the global properties there for this project. So anything that we do from this point forward will automatically get audited. So let's just say that I'm in the designer, and I actually want to write to a tag. Let's go over here and write to Boolean 2, that got audited. You can see it just popped into the audit profile. Now, of course, not only in the designer but from the application, all those events are getting audited as well. So a very important step, and we provide all this information to you. And you can easily then go back and have that accountability. But it's important that we know who that user is, if we have a shared account, then it's really hard to understand who did what? And where they did it? But if I have the actual users authenticating individually, we can then trace it back to exactly what they're doing individually, or if we had some issue, we can see if it was something that somebody did inside of Ignition, or if it was external to Ignition. So auditing is a really crucial step, as you can see, pretty easy to get going.

Step 4: Identify Access Levels

36:25
Travis: Once we do that, we do need to identify access levels and permissions for who's allowed to do what inside of Ignition. It's really important to understand how people are interacting with the system and where they're getting access to Ignition from. Are they doing it from the HMI that's on the plant four? Are they doing it from their PC in their office? Are they doing it on their mobile device? Are they doing it at home through a VPN connection or on the road? We need to kind of think about that, with ignition being server-based and unlimited licensing, it's really easy to get the access out there. And with the authorization we put in place, we have people that can log in, we have to know who is logging in and so that we can lock it down properly. And that's really about identifying access levels or these levels that you can allow or disallow for various actions.

37:18
Travis: Another thing to consider with Perspective is that there's now a true public mode, meaning that we can actually get into an application, a project, without having to authenticate, it can just be anonymous, public. And the reason for that is there's some data you want to have on TV displays, or others where, you show some, read all the information and you don't want anybody to have to log in, you wanna be able to just easily open it up. But then when you have actions or things that require these access permissions, you need to authenticate at that point so we can then know who that person is. And we can lock it down based on the roles that they're assigned to, what groups they're in, or what zone they happened to do it from. Meaning where they're at within Ignition? And so it is something that is pretty easy again to set up inside of Ignition. And I wanna give you a sense of how this works. So let's go back to this application. Now, we built that demo project ahead of time. And so I'm gonna go and launch that project as a client. And you'll notice right away that when I launch it, it is set to use the public mode.

38:23
Travis: So I'm actually writing to the application right here, I didn't have to log in, of course, it's encrypted and secured to the server, but I didn't have to log in. So that means that anything I put into Ignition that is in public mode is available and you definitely don't wanna do anything where you're writing to tags or exposing sensitive data. You wanna protect that as much as possible. But here I have some actions, I have this unsecured button that I could certainly press, oh great. But then I have secured buttons and screens that are not accessible. So if I look at that I get an access denied on the secured button. If I go to the control or audit log screens, I get access denied here. So that is because we have set up the permissions inside this project to respect that. And I'll just kind of show you where these things are. But before we really do that, we have to identify those security levels and all those roles and zones that are allowed to do different things. So if I go back to the configuration, we have within our identity provider, you can bring back when the user authenticates, you can bring back the set of roles that a user has, so I can then know right from there what they're allowed to do. You can also then identify security zones within Ignition, where there is a list of IP addresses or hostnames where we can restrict people based on where they're located.

39:35
Travis: So you can use a combination of roles and zones to qualify what that person's allowed to do. And with Perspective, we do it through security levels, it's kind of a way of abstracting that into you define the levels that you want. And then we can qualify those levels behind the scenes based on some various rules to determine if they are allowed to do, to be in that level or not. So what we did ahead of time here, we created an operator level that is under the authenticated. So they have to be authenticated and they would have this operator role in certain situations. So we just defined the levels and then on our identity provider, that's where we can actually go in for the Okta one. We can easily grant certain levels to individual users if you wanna do it manually, or you can define rules that would allow — it's automatically based when it logs in or run that rule to see, “Does it qualify or not?” And so in my particular case, I'm gonna do a pretty simple rule here where I can just see if it's that particular user ID but you can look at their roles that came back from the identity provider, you can look at the zones, there are special functions we have. And if you look at the documentation, you can use ANDs and ORs, and all sorts of things to verify what that person is.

40:51
Travis: Plus, there can be other attributes that come back from the IDP, the federated provider that we can use in here as well. So we just simply put that rule in place. And now, when I authenticate, I would know whether I have the operator level or not. And so I'm gonna come back here. So again, I've locked this button and these two views to that. And we simply do that by... In the designer. We're using those levels on our actions and our views within Perspective. So I'm gonna go first and foremost, open up the view that had those two buttons. And so here is the secured button. And if I look at it, look at the events that we've got configured this main one, like the security settings, it is set to use that operator level that we identified. So they have to have that in order to run that event. And that's all checked on the server, there's no way that a person in the browser could do this action without going through this authorization on the server side because there's no way for them to poke that into the server. It's only to say, "Hey, I want to run this, here's the event that I want to run," the server determines whether it can do it or not. And that's what makes Perspective so much intrinsically secure from the beginning. So that was on the button there.

42:07
Travis: The second piece is on the actual view of themselves. So if I look at this control view, or the audit view, any of these views, I can see that there's a little shield right here. So if that means their security configure permissions, it's also locked down the operator. And so then if I go back to the application, that's where, again, I get that access denied because I'm not logged in at this point, and I can't view these particular views. So let's go ahead and sign in. We're gonna go through that same process of Okta, I'm gonna send that push. So then, alright, I just got it on my phone, I'm gonna say, "Yup, that's me."

42:42
Travis: It's gonna come back, we now know that I am logged in to the system. So Travis is now logged in. And I have that role... That level, so I should be able to click on that secure button and now I should also be able to see these other two screens. And so, if I look at the out-log that we set up previously, I can see all the audit events that have happened so far, is that they've been able to log in and that we did those changes in the designer, all of that. And so further if I do any actions like writing to a tag, so here to the control and turn this machine status off, change the setpoint here to say 30. Those are now audited. And so if I look at the audit profile, I can see that this user did that write to those particular tags with those values. And there's other information behind the scenes as to where they did it from as well. We get all of that data.

43:31
Travis: So it's really important to kind of identify these levels, figure out who's accessing the system and from where, so that we can properly set that up inside of Ignition. And so these four steps that we took, that we showed here today are four important, necessary steps to really secure Ignition in your environment. And it's something that shouldn't be thought of way down the road, it should be thought of at the beginning and then setting them up early so that we give it the best chance. The worlds of OT and IT are colliding, we have to make sure we're putting our best foot forward in securing our system. Now, we're just software, of course, there's a lot of other things to secure in the OT side of the fence but we got to think about every connection point and every place that these things happen. And so it's just to kind of, hopefully illustrate that. So with that, I'm gonna turn it back over to Jason here for closing remarks.

Closing Remarks

44:21
Jason: Alright, Joel, Travis. Thank you for explaining and demoing those features. So to wrap up our presentation, could you share any additional thoughts about improving security, whether in terms of technology with hardware or software or in terms of people at the organizational or individual employee level? Joel, let's start with you.

44:38
Joel: Yes, definitely, I think what Travis kind of closed with there is important, it's one thing to secure down Ignition, but you have to think of where Ignition is deployed, and sort of the other components in your network and securing those down because what can happen is an attacker could leverage another component in the network, say, another server, and sort of pivot into Ignition that way. So it's just kind of important to think about the whole picture when you're securing things down. And then just, as far as Ignition itself, just looking at our security hardening guideline, just following basic IT best practices with security. I think, that'll get you to 90% there.

45:28
Travis: Yeah, I think exactly that and Ignition is running on a server operating system and that operating system also needs to be looked at, patched regularly. There was a Windows vulnerability that was there with being able to spoof any certificate. And that just can change the whole game, right? We are dependent on that operating system. So it is important to kinda keep these things up to date. We do our due diligence here to make sure that Ignition will be compatible with these future patches, with these things that are going forward. And so you have to... It's a lot of maintenance but we try to make that as simple as possible. So there's a lot to consider within security but these are some easy, small steps that people can start taking.