Lessons Learned from the AS/400 Breach

Hello and welcome to this session on “Lessons We Learned From an AS/400 Hack”.

My name is Robin Tatam. I am the Global Director of Security Technologies here at HelpSystems, and my role is to share information with as many people as possible about vulnerabilities that we experience and see very frequently in the power systems space.

This is my direct information. Feel free to reach out at any time. I am always happy to answer questions, and if you're going be attending COMMON here in the spring, I'll be there as well and would love to visit with you and say hi.

So why are we talking about hacking of an AS/400? I think that's certainly not a headline we see very often, but Verizon did announce that an AS/400 was hacked. They had a document “smoke on the water plant” within their data breach digest that laid out information about a hack that had been experienced by an organization running on the AS/400. Now if you've been around the platform for a little while depending on how up-to-date your terminology is, I do want to spell out because I always take some slack when I do this presentation, about the fact that I'm calling it an AS/400. Now here's an AS/400. It was typically a white box as you see in the slide here. It was a very cool server, but the reality is that that is the predecessor to what we're running on today. So the AS/400 term speaks more to that. When we talk about the current technology of course we talk about a Power Systems Server, the operating system being IBM i. This is the same technology that ran Watson. So, if you've ever seen that Japan and witness those episodes of almost artificial intelligence, Watson was the server, and it was running on a power platform.

This is the coolest server on the planet now. Because Verizon referred to it as AS/400, you're going see some terminology throughout this presentation of the fact that it was an AS/400, but the issues that we're going to talk about are not unique to the old white boxes that do not exist any longer. That technology is extinct, but it does apply even to the latest and greatest version 7.3 power systems server running IBM i. A little bit of a mouthful there, but the reference to AS/400 is purely to be in line with Verizon’s report. So, what happened in this hack? Well, a hacker was actually able to take advantage of some known vulnerabilities in the payment software, that they were using and was able to extract more than 2 million records out of that database.

Now, what's interesting was that during that hack it was discovered that there were some credentials stored within an INI file on a web server that was running on the AS/400, and these user ID or this user ID and password was actually belonging to an administrator, and they were there in the background to allow that connection to happen. Now, once the user ID and password were disclosed of course, they were then exploited in this case. The organization was a water supply utility company, and the hacker was able to gain access into what's known as the SCADA (Supervisory Control and Data Acquisition) application, and that application was really designed to control the flow of chemicals into the water supply for maintaining, of course, good water quality.

The problem is when somebody is maintaining that with very minimal changes in that mixture when somebody comes in and decides that they're going to make changes to it however they feel, there's obviously a significant amount of concern as to the integrity now of that water supply, and it could have been extremely damaging. Now fortunately, they were able to catch this issue prior to that water actually being contaminated and affecting anybody. But of course, that does raise definite questions with regards to infrastructure.

Now in this case, there was no network segmentation. The AS/400 was directly connected to the internet, and while you might think that is crazy, it is something that I see. And so, we have to acknowledge that that type of configuration is not completely unheard of. Now, in this case, the internal network was now exposed. And if you think “Well, but I have a firewall”. That's great, but it's not unheard of also for a firewall to be circumvented or for a user, somehow to find a vulnerability either in a mistake made in configuring that firewall and gain access to the internal network. In fact, virtually every breach that you have seen or heard about over the past couple of years, obviously involve somebody getting inside, and so while we do like to appreciate the maturity of a good perimeter, we have to acknowledge that there is possibility that somebody could gain access.

So, when we ask the question, of course, is this a failure of the technology of the AS/400 or anything that's followed it?

The resounding answer is no, it is not.

Now, we've had the benefit of enjoying a very solid reputation as being one of the most securable operating systems on the market and as a security person and somebody who's been on the platform for many, many years, I would absolutely concur with that.

But when we talk about secure-able it implies that there are no changes that need to be made. That the operating system is just inherently secure and that all of the applications that we use within that environment are also secure.

The reality is that it's more secure-able, meaning that it does not come pre-configured in its optimal state. You have to take responsibility for configuring that.

Now, it's not just you, you have to, of course, have an operating system that supports good integrity and good security controls. Fortunately for us, we have an operating system that, while not always optimally configured for that, does have the capability of being placed into that state.

We also have to look to the software vendors who supply our core business applications to ensure that they are upholding these intentions and that they also have their environment configured appropriately. They give you direction with regards to how you set up your users and ensure that everything is in compliance with best practices, but ultimately you as the organization owning that server have to be responsible for pulling all of those pieces together and ensuring that they are correctly implemented. And this is something where we saw definite break down in this particular example.

So, here we talk about the fact that there was a failure to use those features that were built into AS/400, and these are not new features in many instances, a lot of them have existed since AS/400 1.0. That was back in 1988.The latest Power Systems Server has many of those same controls, but we have a tendency to see people not taking advantage of them. And that was definitely the case here. We also saw a failure to follow any sort of security best practices. In this case, the Verizon write-up pointed out that the administrator of this system had really not considered the security implications of the configuration that he had chosen. Putting his credentials into that INI file so that the application could seamlessly connect to the server was convenient, but, from a best practices standpoint, obviously violated many things. He also failed to keep his applications patched. In this case, the SCADA application was dangerously out-of-date. Arguably, they also failed to use common sense. Having an IBM i server connected directly to the Internet with open ports and other things is going to lead to challenges, and I have discovered situations where there are servers connected to the Internet with open Telnet ports, open HTTP ports, and that is really not conducive to generating a secure environment. Now, hopefully, most people are not in that state, but that's not to say that there aren't places where we can improve that configuration.

Now, I've always found this scatter diagram to be very interesting. It's generated from the IBM X–Force Threat Intelligence report, and it gives us indications of where the incidences occur and the scale of the incidences that were based on different attack types. Now, what you'll see as we get to the end of 2015 because I haven't seen the 2016 report yet, is that there was a significant increase in not only the frequency, but also the size of data breaches that were tied back ultimately to mis-configuration.

Now, if you're interested in how IBM i sometimes sees miss configuration, then we have a great resource that we publish every year. We have been doing so since 2004, and it is the State of IBM i Security Study. Within the study, we analyze several hundred IBM i environments or AS/400s and look for common vulnerabilities. So, we have a lot of insight into the state of play when it comes to security of these servers.

If you are interested in this, it's available from our website and has a lot of statistics in it, but I'm just going to focus on a few here.

So, this is IBM i environments, or AS/400 environments, running at the wrong security level. Now, IBM has five different security levels, and to be really assured that you have the capability to secure the system, you should be at least at level 40; 40 or 50 is acceptable. Anything below that, there are known vulnerabilities, but we still see that almost a third of the systems we looked at last year, excuse me 2016, were actually not meeting that minimal requirement.

Now why is that?  IBM actually changed that default many years ago.

But, if you think about the last time you did a system upgrade you probably took a tape off of your old system and restored it on to the new one. There by overlaying all of the defaults that IBM had changed. So one of the things that we need to do is actually circle back around and see if your current system, no matter how new, is still running with some of the old default and has room for improvement. Now, there's a lot of other configuration elements that come into play with the integrity of the system and the applications beyond the system security level, but this is a good overall indicator as to whether you are going to be able to meet those requirements.

Another thing we see on IBM i is that we have too many users with large privileges or powerful privileges.

Now this is a view here of the profiles that have an administrative privilege. There are eight of them. We call them special authorities in our environment, but, in essence, what happens is that these are granted to a user again, often through duplication of the privilege, but also potentially through the saving and restoring of that during any upgrade.

Now, as you can see on the graph here, the *SPLCTL and *JOBCTL privileges are just off the chart, almost, with an average of almost 450 profiles running with these types of authorities, and this is on each system. Now in the case of *ALLOBJ on the far left, that is by far the most powerful privilege of all. This one if you are familiar with the UNIX environment, is deemed as the root level privileges, administrative level privileges, basically makes you virtually unstoppable on the system. We see an average on each system of almost 150 profiles running with this level of authority, quite startling really.

Now, one of the causes is that many people had that privilege many years ago when it really was an AS/400, but back then we were able to corral the users within the application environment by assigning them to a menuing system. They could sign on, they could take an option, and that was really all they could do.

There's lots of other ways now to access the system beyond a green screen and arguably most environments are not going to be breached, based on somebody loading a version of client access and signing onto a green screen. No, hackers are not going to use that type of technique; they're going to come in, and they're going to attack through FTP, through ODBC, through DDM and other types of standard data interfaces. So, we have a distinct requirement to reduce the number of users operating with these types of authorities on the system to bring them down, ideally somewhere around single digits. If you're on a really big system, maybe that's a tough objective to achieve, but at the end of the day, what I want to know is are you viewing this? Are you looking to see which uses are privileged on your systems? Do you know if they have a requirement for that level of privilege, and, ultimately, do you know what that privilege is enabling that user to do?

Now, another thing that we hear often in discussions is that obviously the profiles are associated with hopefully actual people, but that's not to say that a hacker can't compromise those credentials. Now when a user has a lot of authority, even if we trust the users that are signing on, that's not to say that the user who is signing on is the one that the credentials were given to. One of the most easy to resolve, low-hanging fruit, items of IBM i Security is the fact that we too frequently give a user profile a password that matches the name of the user. So, in this case, my name would be Robin, my profile name would be Robin and my password would also be Robin.

That's one of the easiest things to guess, of course. But that's often followed by the most frequently assigned password in the world, which is password, followed by one, two, three, four.

Password practices make a significant amount of difference, but in the IBM i environment, what we see is on average 140 profiles on each system have a password that mirrors the name of the profile. Even when we throw out to the disabled accounts, and we look at the average here with still at 76 enabled profiles with a default password, and that really is a problem. That number should be zero. IBM profiles do not have nor need a password that matches the profile name. So, if you think that you can't change it because it was supplied by somebody else, that's not the case. Now, if you have application profiles or service accounts, just be careful that obviously those passwords aren't in an INI file somewhere and would cause the application to break. But of course, as I've mentioned, best practices state that we would not be putting credentials in the clear within an INI file anyway.

One of the areas that we talk about as being a risk within IBM i, which is arguably a little bit controversial, is the risk of viral infection. Now many years ago, I think we heard as a community collectively that you couldn't get a virus on the AS/400 - sounded great.

IBM said, "Yep our native objects cannot be infected with the virus.” And we took that ball, and we ran with it, but I would say we ran a little too far and stretched the truth in our own mind. The  Integrated File System (IFS), which was incorporated into the system back in version three is a file system, and it contains Word documents, and PDFs, and JPEGs, and mp3 files and all of those can be just as infected in the IBM i world as they can in a Windows world. Now, I think people have kind of come to the realization that any file system can be infected, but with the AS/400 we have at least segmented that in our minds. The integrated file system is an island, it's something else, we don't overly use it. A native environment is safe, and we don't really see any bridge between the two, but the reality is, the integrated file system is not an island. It actually encompasses the entire system including the native environment.

If you get a virus in the integrated file system, it can propagate out to other servers kind of a Typhoid Mary, if you will, making us the host to end all hosts. We also have to recognize that the integrated file system is used and needed by the operating system, so if a virus does attack and do sufficient damage to the IFS, your server is going to have trouble even functioning. If the virus actually drills into QSYS.LIB, which is your native structures, then while the infection will not follow into those objects, that's not to say that the recent prevalence of Malware and Ransomware cannot do damage. In fact, Ransomware and Malware are perfectly able to do damage to native objects, including deleting, rename, or even encrypting those objects.

So yes, we agree. Objects will not be infected in the native side of the house, however that does not mean they can't be just damaged or destroyed.

IBM acknowledged this back in version 5 release 3 of the operating system, which was clear back in 2004, and they created integrated antivirus controls. There are two exit points: scan on open, scan on closed. And as you can see from the graph here, they are largely dormant. Most people are not doing any type of native scanning within their IFS environment, so they are vulnerable to the idea that Malware, Ransomware, or even traditional viral infections are perfectly able to take hold. Now, because these controls are there, why are so many people not using them?

The reality is that IBM didn't want to be in the anti-virus business, so they created the infrastructure they built the foundation, but they turned to the business partner community to create the actual scan engine. That was something a company called Bytware created. There's a Powertech Antivirus for IBM i (formerly known as Stand-Guard Anti-Virus) engine that you can load to run natively on IBM i, fulfilling the missing link to this chain. In fact, Bytware engine is built from the enterprise scan engine provided by McAfee, who's owned by Intel.

But that wasn't the only acquisition that happened. HelpSystems actually acquired Bytware, many years ago now, and so, that Powertech Antivirus for IBM i engine is within our portfolio.

If you are interested in learning more about the risk of virus and the easy steps that could be taken to solve this problem, we would absolutely be happy to give you more information, but it's definitely something you want to have on your radar, especially if you have applications that are utilizing the IFS or especially if you have users mapping drives to the IFS.

Now, if you think this is all theoretical, think again. This is a green screen that was sent to me by a customer who, unfortunately for them, did not have antivirus scanning active, until after they were hit with Ransomware.

They had a document management system comprised of many many PDFs, and almost 250,000 of those were infected one day. We were able to actually help them get that system recovered. It was a painful process. They had to go out, back up to tape, and restore those IFS objects, and they were lucky that they had a recent save. If your inclination is, “Well, we'll just do a roll swap to our back up machine,” just bear in mind that if the infection is on the IFS of one system, the chances are it's been replicated over to the other system and you could be just as at-risk there, as well. So true antivirus, anti-Malware detection is a much better approach.

The other area of weakness that we see very commonly, and this was true, especially with the breached AS/400, is that the expectation was that everybody was using the approved application, and traditionally, in the AS/400 world, that's going to be a green screen. It's going to provide a menu to a user, they're going sign on, and they're going be corralled by that menu option and the application security itself.

Of course, as I mentioned, most people that are hacked are not hacked through somebody manipulating a menu, they're hacked through other data manipulation techniques. FTP, ODBC, DDM are all typical avenues of attack. Unfortunately, or fortunately depending on how you look at it, these interfaces are also very beneficial. There's a lot of value that they bring to the table. So, how do we open the doors to the legitimate business functions and the user activities without making it high risk, free for all type data access? Thankfully, again IBM provided the answer. They built a number of exit points into the operating systems that allow the invitation of an application program that can oversee these connections.

Now, IBM doesn't provide the exit program, so one of the things that we do in our State of Security Study, is we look to see if those exit programs do actually exist. And unfortunately, when we set the bar at the highest level, saying, every one of those 30 approximately exit points are covered with an exit program, we see less than 10 percent have succeeded in accomplishing that.

The other 90 plus percent are fully reliant on object-level security, which is very good, but is rarely implemented. So, we do see very frequently that there is little to no control or audit visibility to data flowing on or, of course, off the AS/400 platform, and this is low-hanging fruit, as well, easy to fix and definitely recommended. IBM does not provide the exit programs, so you have two choices: One, to write your own, or to purchase them from a security vendor. If you want to write your own, I would say that is probably a viable approach if you want to simply prevent these interfaces from being used. If you are actually indeed using them for legitimate business purposes and, therefore, the restrictions and the auditing function, needs to be a little bit more selective, I would say that that is complicated enough as a process that you should look at that as an application type function and invest in a commercial exit program solution.

Unencrypted sessions. That was definitely something that came into play here, and it's something that I see very frequently.

We utilize emulation, we utilize interfaces that request us to provide a user ID and password, but a lot of times we are not using encryption to ensure that those credentials are protected. Likewise, once the user connects into the application, of course, the data is flowing back and forth. It may not be an actual file download, but if you think about it, even if you pull up application data on a screen, it's actually resident in memory on your laptop or your workstation, and it's had to flow across the network, and if that's happening in clear text, then there is the possibility that someone could collect that data. If, of course, that is private or proprietary information, we really have a problem on our hands.

Now, if you think nobody would ever be monitoring that, then you haven't met this guy. He's actually somebody that has worked with our team, and one of his hobbies is to try to find unencrypted data sources. So, when we do pen testing, for example, one of the things that we can look at is whether that traffic is flowing in clear text, and, if so, it becomes very easy to just scrape that out of the sky and pull that data down.

I talked about viruses attacking the integrated file system, and one of the primary causes of that is users who are able to map drives into the IFS. Now, there's nothing wrong with that actual approach when it's done legitimately, but how do you differentiate? Well, it's a little bit difficult although an exit program can actually provide value here because there is a net server exit point, so very beneficial use of exit programs, but you want to ensure that you are mapping in an appropriate way. The root folder of the integrated file system is probably not somewhere where you want to bring a user into because one of the branches of the integrated file system from the root is called QSYS.LIB, and, per its extension there, it is a library, and it is your QSYS library. That contains your operating system, as well as all the other application libraries, so it becomes very easy to drill down into the native environment, and if your users can drill down, then so can a virus or a piece of Malware. Very few occasions where I've seen justified need for a user to go through the IFS panels to get to the native structure. So, one of the things that we can do to protect any type of intrusion, is to ensure that they only go to the appropriate folders. That can be done through some Unix techniques read, write, execute type authorities or, again, you can do it using an exit program. Usually, I prefer to do both, but the exit program is a much quicker way to do it.

One big recommendation that came really to light as part of the breach was the fact that it's very important to stay current. In this case, the SCADA application devices were extremely out of date, and so they weren’t really maintaining them, but we have to take this even at the server level. Maintaining a supported operating system is a requirement of virtually every regulatory mandate that's out there and for good reason. They want to ensure the patches that are available are being released, and so we want to make sure that everything that we can do is available to the release that we're on.

If you are running anything prior to version 7 of the operating system at this point, you are unsupported, unless you have an extended maintenance contract of course, but we have to bear in mind that there are certain features of the operating system that are not typically back leveled into those older releases. It's more of a support statement.

For example, one of the things that came to light within the last year, or 18 months, is the fact that SSL is no longer deemed a supported or a secure transport mechanism.

The recommendation is to go to TLS. Now early TLS was vulnerable, as well as SSL. So, we want to get to at least TLS1.2, and that's not available unless you are at least at V7R1, TR6.

Alright, so if you're not at that level, then it's going to be very difficult for you to create a transport mechanism for your data that is actually secured and not easily broken.

We also want to make sure that we maintain currency of our PTFs. The Java PTFs are released quarterly, and we also typically want to put on the security group and hyper-PTFs. All of these things are going to address any weaknesses or vulnerabilities that may be exposed, typically going to be in more of the Java space than the native side.

The other thing is if you're using IBM i access or client access, as it's often known, know that it's no longer supported once you get to Windows 10 or beyond. So, we want to switch over to Access Client Solutions, which there’s a lot of good reasons to do that. Not least of which is I no longer have to open 15 windows if I want 15 sessions, I can have tabbed sessions for my connections, which is a fantastic benefit. But you have to be able to support and update this, just like any other desktop application. So, we want to make sure that the system is using the latest technology to ensure that anything that has been discovered in the past, has been worked out and remediated.

Now, a lot of times people in the IBM i environment, they're a little overwhelmed in where they should begin. They find that 20, 30 years of bad practices has really left us in a state where it's an uphill battle, but my recommendation is don't be overwhelmed. There are lots of things that can be done that don't take 20, 30 years to implement. They can take hours, maybe days. Certainly, there are other things that may take weeks, months, or years, but it's not going happen overnight. So, like anything else, we have to start taking those steps in the right direction, and certainly we have a lot of folks here that can help give you some direction with regards to where you should start, based on the vulnerabilities that may exist in your environment.

Every step is a good step if it is made in the right direction.

Our overall goal here of course is to reduce risk. Now, if you work in the risk space, you'll know that risk is not an on-off-type switch. It is a scale, so we want to reduce risk from high down to low.

You're never going completely eliminate it, but it doesn't make sense to do so, anyway. You just have to get down to a level that is acknowledged and accepted by the business as being reasonable. Now in order to help organizations reduce risk in their environment, we have a suite of more than a dozen different types of solutions that can help in the space, ranging from encryption to antivirus running natively, as well as intrusion, detection, and prevention.

Now, all of these solutions run on IBM i, but in some instances they also run on AIX, Linux and Windows. If you have a mixed environment, as most people do, we have taken the expertise that we've developed over many years, and we've started taking that out to give to the benefit of the other communities, as well.

It's not all about product. We have a lot of people that are extremely experienced in the operating system. 

That team is able to perform services, ranging from initial risk assessments to architecting a good security model to implementing that security model, and then eventually managing and reviewing your system on your behalf. If you find that you have not a lot of time on your hands, like most people, or you don't have the skills necessary to oversee your IBM i security environment, we absolutely can take that for you.

Now the nice thing about this cycle here is that it's much like a bus ride. You can get off the bus at any point you want. We can build the architecture, you can remediate it yourself, and you're absolutely able to take advantage of all of those segments.

What we've ended up with in the IBM i environment is, of course, a lot of valuable data being stored here. This is a line of business application server for many of us. Presumably, you're on this webinar because you are interested, and this server is a viable entity for you.

Unfortunately, security awareness amongst many professionals in the IBM i space is pretty low, it's not a discipline we're typically trained in. Ultimately, of course, having open security doesn't prevent the server from running, or the applications from working. Usually it's quite the opposite. While we know that it's important, we acknowledge that it is out there, it's not a pressing issue right up until the point we find that we've been breached, of course. In most server environments, audit professionals are driving a lot of change.

We have no choice. The auditor has discovered that we're using best practices or not, and if we're not, they're going force us to make change, but unfortunately, the audit community is not typically very deeply aware of the IBM i, AS/400, environment. So, a lot of this is not being driven by the audit community.

Now over time, that's changing, we're improving there. We're actually helping auditors better audit their environment. Don't hate me for that. Hopefully, that means that they're making better suggestions in the process.

The State of Security Report we publish tells us that most of that data is not secured. It is open and the users that we have on the machine are far too powerful. Meaning that the data that we have is easily accessible through PC interfaces that may just be simply included on the PC, or example a DOS prompt, and there is very little, if any, oversight to transfers that may be happening. For example, there is no FTP log, there is no ODBC log built into the operating system. You have to use additional stats to have that visibility and to contain those types of connection methodologies. As I said before, those connection methodologies are often the highest risk to you because that's the type of approach that either an unauthorized user or a hacker is going to use or even a user in the environment who is trying to abuse their credentials. And it's critical, absolutely critical that we have visibility to those connections.

If you're not really sure where your system lays in this discussion, then you'll be interested probably in the fact that we have the capability to tell you. Now this is great because this is an offering that we have to the IBM i community. Utilize some software we wrote specifically for this task. It is fast, it runs in usually about a minute or so, it provides very interesting statistics as you can see in some of the thumbnails here, and it is totally not intrusive. You can run it in the middle of the day on a production server, and it's going to give you that feedback almost instantaneously.

The best part from your perspective is that there is no cost and no obligation to use this software. You are welcome to run it against any or all of your IBM i partitions and formulate good visibility of your risk level. Now, one of the things that I do a lot of is actually review these with people. So, what we do is offer up to about an hour worth of security expert time in order to review the findings. Again, no charge or obligation associated with that, but it ensures that you are correctly interpreting exactly what the tool is telling you. A great first step when we talk about discovering where your system lies before you start trying to remediate the items. If you would like to learn more about IBM i security, then we have a couple of recommendations for you. One is download The State of IBM i Security Study. I'm starting to work on the 2017 study now from the data that we've collected, but that will be published in the spring, typically at COMMON or a little bit before but take advantage. The 2016 study is still extremely pertinent. I will be honest that it doesn't change a lot year in, year out, which is more a message of the IBM i community than it is the report itself. So, take advantage of that.

For resources come out to HelpSystems.com. You'll find demo videos of our software, you can even download trial 30-day copies. Of course, we have data sheets or slicks on those products, but we also have a number of articles and blog entries that talk about even the controls in the operating system. We've been doing this a long time. We know that buying a product doesn't magically make you secure, it's about how it gets integrated into the environment using best practices of the server and we know that, we understand that, and we promote that idea. So, we have a lot of resources out there that can help you understand more about the operating system that you're using.

You can also go out there, of course, and request a free scan at any time. Now, I'm going to go ahead and open up for question and answer, please use the chat window for that. I know we've got a couple of comments and questions here.

Julio looks like you were asking if you could ask a question. Absolutely I invite you to do that. While you're formulating those questions or if you don't have a question, but you want to see what other questions are asked I'm going to go ahead and shoot out poll for you, just a three-question quick poll.

I'm interested in whether you believe that your IBM i server is at risk, whether you feel that you need to improve the security on that platform, and if you are interested in one of those no-cost scans, let us know. Save you from going out to the website and signing up. If you'd like more information about that scan, just tag that as well. We would be happy to give you some insight into how it works, what it looks at, and how it runs. That way you can make a more informed decision as to whether that's something you may be interested in.

Just going give you a few minutes here, so go ahead and answer those up. In the meantime, I know several of you did ask about a replay of this webcast. This is actually the second time I've done it, today. So, this is the replay, but we did record it and hopefully the recording is good, and we will distribute a link to that to you after the event. Then you can share that or replay it, whatever you want to do, absolutely. And just as a side note, anything that we do from a webinar perspective, typically is available as an on-demand replay from our website as well, and you are welcome to access that information. Alright, so, Phillip is remarking that SCADA devices should be segmented from absolutely everything else. So my guess is that you use those types of devices and are probably very aware that the segmentation is absolutely critical. We appreciate that insight there. It's always good when somebody's using those applications and can give us some insight that perhaps we don't even see. Julio looks like you maybe have a question that you want to take offline. Absolutely, you can give me a call, I'll go ahead and put my telephone number into the chat window here. It's hard to talk and think of your phone number at the same time. This is available to anybody who has a question that they'd like to ask. You are welcome to give me a call or to use the email address. I know that was on the intro slide, so I will go ahead and pop that up for you there, as well, and I'm always happy to answer questions, so feel free to use this as any type of resource in the security space. We probably have somebody on the team that can answer the question for you. I'm going to go ahead and close the poll that will just give you about 20 more seconds to wrap up, if you have indeed started it.

It does look like about 52% of you do believe your IBM i server is at risk, so that's certainly something that you want to work on. 40% not really and 7% of you are not sure either way. 71%  think some improvements can be made to your IBM i security configuration, so as a security person that's very reassuring. I'm glad that you do acknowledge that because quite honestly until there is an understanding of the fact there could be weaknesses, not in the base operating system itself, but just in the implementation or configuration of those things that there may be some things to work on, so that's great.

Looks like 12% of you were already secure, so congratulations.

I still offer up in that scenario, take advantage of the scan. It will simply confirm for you that, everything is good and sometimes you don't know what you don't know. So having another set of eyes look at it can be beneficial, and we're happy to do that.

Alright, for those of you that did request to scan or would like more information, I will absolutely reach out to you after the event and give you that info and show you how you go about doing that.

I'm going do one quick pass through the questions again just to see if there's anything that I missed. Michael, you're asking about performance of exit programs, you said exit points, but I'm assuming you mean exit programs. Really the only interface that ever sees any type of consideration of performance is the ODBC exit point, just because of the nature of ODBC, but it's rare that the server can't keep up with it. But there is a call being invoked every time the transaction comes in, so that the exit program can determine if it's a desirable or authorized transaction. There is definitely a consideration, but typically it's not an issue. Mike, I do see your note here and absolutely we’ll reach out to you and check with you on the date that you requested there. Mike you are clarifying for the virus scan. Okay, for the virus scan. Again, it's an exit program. The scan engine is being invoked by the operating system, so just like any operating system, when you add additional code, there is a consideration. Now, I don't call it necessarily a problem because for many systems, it's pretty transparent, but what I will tell you the benefit that we get with our scan engine is provided by IBM.

What I mean by that is a non-native scan of the integrated file system, let's say, for example, you have a Window Server mapping a drive-in and you're doing a remote scan using some type of virus engine on that Windows workstation or server. There are seven or eight significant disadvantages and risks associated with doing that. In fact, controversially I would offer that I would prefer people not scan then scan remotely. The reason is that you actually end up opening the door wider sometimes than you would if you weren't scanning.

So native scanning is the way to go. The operating system can scan in several different ways. One, of course, is you can say, I want to scan the whole system or select directories on a scheduled basis.

So, Sunday at 2 AM, I want to start the scan. But the real benefit of native antivirus is that the operating system integration points allow us to scan in a live environment. Meaning that the scan engine knows when a file is about to be opened and the operating system will invoke it before the file is or has a chance to deliver its payload. Now of course there's some overhead associated with that open, but it's only going to apply to the files that are being touched and only if that file has not previously been scanned, so we have that benefit there and it really does help minimize that. Easiest way to find out, quite honestly, load up a trial. We can show you a scan, you'll get a free scan if nothing else out of your IFS, and we can show you exactly how that integrates in with the great functions that IBM added.

Alright, I don't see any other questions there, so I appreciate it. Looks like we're about 12:45 here, so we're wrapping up, I think perfectly on time. I appreciate the questions, as well as the attendance. I hope to see you on an upcoming webinar. If you do have any questions that you think of afterwards, or if you're a little bit shy, feel free to reach out to us, and we’ll be more than happy to answer those questions for you. Again, we love this stuff, we work on it day in and day out, and there's nothing more satisfying than helping somebody through a pain point that they're having. I appreciate your time, have a wonderful weekend, and we hope to see you on an upcoming webinar soon.