How Multi-Factor Authentication Can Prevent an IBM i Data Breach

Robin Tatam: Well, good afternoon everybody. Welcome to this session on why single-factor authentication can be the cause of a data breach. My name is Robin Tatam. I'm the director of security technologies here at HelpSystems and I'm going to be one of two presenters talking to you today about some of the challenges of single-factor authentication as well as an introduction to some options that you have to get away from single-factor authentication. My role here really is as an evangelist of security, so if you do have any security challenges or have any questions, whether it pertains to the immediate topic today, feel free to reach out to ... That's my email address there on the slide, or you can send a note through the chat window. We'll answer the relevant questions at the end but if there is anything outside of that, be happy to follow up with you as well. It's my pleasure today to be joined by Bob Erdman, who is the security product manager here at HelpSystems. Bob, let's have you say hi here. We'll check your audio again and we'll roll right in.

Bob Erdman: Good afternoon, Robin. As you said, I'm the security product manager here at HelpSystems, so I am the product owner for Powertech Multi-Factor Authentication (formerly known as Access Authenticator).

Robin Tatam: Which is the introduction we're going to make to you a little bit later on today, so hang with us. We're going to talk about single-factor authentication and we're also going to give you a sneak peek into something that is on the cusp of being released here at HelpSystems and something we're very excited to share with you. Part of the reason I love working here at HelpSystems is that we have a very complementary staff of security experts, both on the product side as well as on the technical services side. We really have built out a phenomenal team and it's an absolute pleasure to work with all these folks and to be able to help our customers with their security challenges.

Part of that comes from a synergy that we have discovered between security products of course, which we are very well known for, but also a slew of security services both on the managed side, so that we can handle a lot of that effort and workload on your behalf, as well as of course configuration and remediation services. Our reputation in the industry has been built on many years of expertise, and part of that comes from the State of IBM i Security Study that we've published every year now since 2004. It gives this really unique insight I think in a way that nobody else has, and of course allows us to design remediation and mitigation both, again, through services as well as software, on how to address some of these common challenges. We're part of the PCI Security Standards Council, which is one of the driving forces at the moment between single-factor authentication and the alternative.

If you are dealing with credit card information or if you have a PCI mandate or if you simply want to attain that type of security control, just know that what we're going to talk to you about today is actually very relevant for achieving compliance with PCI. HelpSystems is also the only security vendor who is accredited in order to educate auditors. In other words, we are deemed the expert on IBM i and we are gladly sharing that information with other folks out there. Now I know we've got work to do, I know sometimes auditors don't know as much about IBM i as perhaps we wish they did, but we're working on it so we're going to continue to chisel away at that. Now single-factor authentication really is in essence the vanilla ice cream of the authentication space. It's very simple.

I think most of us have dealt with this for many, many years, but we don't necessarily always put a name to it. What is single-factor authentication? Well, the reality is for most of us it's just the knowledge of a password. That's going to provide us with the access to our systems that is deemed necessary. It's controlling our access based on the fact that hopefully we're the only one that knows that password. Unfortunately I think we all are beginning to recognize that that is not always the case. Passwords are often very easy to guess. In fact the most common password is the word "password" or "123456." I think there's always been that technology joke about users writing their passwords down and sticking them on a Post-It note attached to the monitor.

In fact I was on an airplane the other day, noticed a woman with a Post-It note on her laptop screen and she had actually dug out her corporate passwords and had it stuck to the front screen of her laptop monitor, which was quite startling. But the reality is we attempt to make our passwords more manageable, and in the same breath more difficult to guess or break, by implementing various password rules. I think we've all kind of dealt with those challenges. Unfortunately there are of course work-arounds for that, and the classic Post-It note is a big one. If you follow any of the data breaches that have occurred over the last few years you've probably seen a pattern with regards to the fact that oftentimes breaches entail compromise of user accounts.

I think in the IBM i space we have a tendency to think, "Well, our passwords are stored through a one-way encryption so we don't necessarily have to worry about somebody extracting a password file and decrypting it." Unfortunately when we see that there are breaches in places that are perhaps common and may not even be of concern to us overly based on the fact that we feel the information on that particular website perhaps is not overly pertinent or overly personal, we find out that oftentimes when these breaches happen and those accounts are compromised that there is a recurring theme whereby passwords tend to be reused. We take that rule set and we say, "Hey, look, here's a password that I can remember. Even though I have 30 different websites that I log into frequently, I'm going to try and employ that same password or maybe a slight variation of that same password across the board."

That opens us up that if we are actually compromised in one aspect, we open up the doors in many other. In fact we've seen that with the LinkedIn credentials being recycled and other different areas. Of course that ultimately can lead to an open door into the corporate environment, be it a VPN password or a network password. If that mirrors your Pinterest account password, then we may have a problem if that type of site is breached. Now from a hacker's perspective, of course there's always the ability to try to crack a password or to breach that password based on named information. We also of course have seen a significant increase in the number of phishing attacks as well as the sophistication of those attacks. Statistics published last year indicate that upwards of 30% of phishing emails are actually being clicked on.

The irony there is as a person that perhaps markets to a customer base, that type of click rate is absolutely unheard of. It tells me the users are much more likely to click on a focused or speared attack than they are perhaps in something that is advertising to them, which is quite staggering. The sophistication of those attacks of course has evolved. We're not necessarily seeing the rich Nigerian prince offering to give us millions of dollars, but what we are seeing is targeted attacks using information perhaps that has breached from other sites and gives credibility to the email that is being distributed. There's still of course the age-old brute force attack. If your password is not strong, then there's a good chance that eventually that attack will succeed.

In fact with the advances in both software and processing power, even complex passwords now can be broken in a relatively short amount of time. When LinkedIn had their breach recently there was a lot of documentation regarding the fact that even before that was announced to the general public, a lot of those passwords had actually been broken and compromised. In the IBM i space we tend to think of ourselves as protected by the outside. We put a fence up around the perimeter, and we hope and we pray that that fence is going to keep somebody out. The expectation is that anybody on the network does have the authority to be there, but the reality is people get through these fences. Most of the breaches you hear about probably had a firewall around them and a user was able to compromise that, typically through the leveraging of known credentials.

This fence is great. We certainly recommend it, but we can't rely on it entirely to protect all of our elements inside. In an IBM i space we also have a second challenge whereby our users are typically overly privileged. We have power associated with our user accounts that really is not consummate to the type of role or job that they do for us inside the organization. One example of that is a special authority known as *ALLOBJ. This is, in essence, root privileges to the server. It means I can do anything, literally, including deleting the operating system and access any database file on the server. Unfortunately, one of the things the State of IBM i Security Study has taught me over the years is that we have far too many of these types of profiles.

In fact in 2017 the study indicates that there is an average of 200 users operating on each individual system that we looked at running with those root privileges. Now before you start trying to count up faces there, just know there are 200 faces on this slide. If you look at that and think, "That's a lot of administrators," you are 100% correct. The reality is in IBM i, we typically have one if we're lucky. Where do the other 199 develop a requirement for that? Certainly some of that is service accounts. It may be IBM supplied profiles, but probably not a hundred-and-something of them. Unfortunately data breaches all too often come as a result of poor or lacking configuration. It also comes from improper password handling.

Not only the rules that we establish in order to ensure the passwords are strong, but unfortunately the more we make that difficult for our users, the actual handling of those passwords, be it the documentation of them on a Post-It note or some electronic equivalent thereof, we definitely have an issue. Let's take, for example, a password here. We're in good old Vikings country here in Minnesota and this password is very easy to remember, but from a strength perspective it's also extremely weak, not only because it's a dictionary word but because it's probably a fairly common word for any Minnesota football fan. The entropy of this particular password is less than 25 bits, which is typically deemed as a very weak password.

Now it's easy to remember, but we need to do more than that. We have to make sure that it's not easy to guess and that it's not easy to break. What do we often do? Substitution. We take the 1 and we make it an I or vice versa. We put a dollar sign instead of an S. I took my Vikings password and I changed it into GOV1k!NG$. Now the strength has increased. We're actually up to about 42 bits of entropy which is still not very strong, but the ability to remember this password has suddenly become very complex. The interesting thing is when we do character substitutions we actually have a potential of weakening the password. How is that you say? Well, when you think about it, in the English language we have 26 letters in the character set. When we switch to a digit we're now down to 10 characters, 0 through 9.

What we've in essence done is reduce the number of combinations that can be included. Now we want to find a balance there, because of course dictionary words in attacks using things like rainbow tables make it very easy without this type of substitution, but we have to recognize that this is not the answer. Usually what it comes down to is the length of the password has more influence than anything else. Now here I've taken Chevy Corvette and Ford Mustang, two things that are pretty easy to remember, but when I combine the two things together, this password is extremely long. Now if I suggest to people that you go to 30-character passwords, you're probably going to be a little worried that you're never going to be able to remember that.

But even here where we've taken words that are relatively easy to guess by themselves, and we've made this password not only very easy to remember but exceptionally strong as well. The entropy of this particular password is actually approximately 100 bits, which is usually deemed enough to protect financial information. At the end of the day we've got to be very careful with passwords. We want to make sure that we change them on occasion, and there's certainly discussion about whether that is desirable too. But in my opinion if you use the same password everywhere and it's compromised on website A, we've got to make sure that that profile or that password is not accessible on website B through Z. We want to be cognizant of changing that password on occasion.

Of course we want to keep them private. We don't want to share those passwords and most regulations speak to that. Regulations also speak to the idea of authenticating to systems and whether it is PCI or SOX or HIPAA, they're all concerned with the fact that if a user connects to the system we want to be able to authenticate that it is the correct user. GDPR, which is the new European regulation that's coming into effect in the coming months here. PCI, HIPAA, Federal Information Examination Council has established standards as well. At the end of the day they've all determined that passwords are very fragile. For most of us, I would argue that they're even broken. What do we do about this? Well, we've talked about single-factor authentication. We have to talk about multi-factor authentication, which is kind of stepping up the next level.

Here we're going to leverage something most likely that you know. That could be your existing password. Of course hopefully it's only something you know, and it's going to be something that you keep secret. In combination with that, we also then add in the element of something you own or something you have. Could be a smart watch, it could be a cell phone, it could be a USB dongle, but it's something that typically you're going to have physical possession of. So even with the information that you know compromised, without that physical device in hand a criminal or an unauthorized user is not going to be able to leverage the information. Another factor or category of factors is inherence, where typically we're talking about biometrics. It could be a fingerprint scanner, could be a retinal scan. There are different ways.

Most of us have become familiar with fingerprint scanner, especially if you have an iPhone for example. If you travel a lot and you're part of the clear thing at the airport, then you can do a retina scan. There's lots of different ways that we can determine that the person who is claiming the information is theirs is actually the person doing so. A lot of people look at multi-factor authentication and they think, "Oh, well, I'll just ask another password." In fact I see a lot of this on the web where I sign in and it asks me for either a second password or additional information, but the reality is this is not multi-factor authentication. This is multi-verification or justification, meaning that it's still something I know.

If I can compromise one thing I know, then there's a good chance I can compromise two things. Many of us are familiar with resetting passwords, but a lot of people use this as kind of a pseudo-multi-factor authentication. Again, I've got credit card companies that do this on the web. Again, the reality is it's still something I know. The reality is that first car, mother's maiden name may be something quite easily accessed on a person's Facebook page. Again, this is not multi-factor authentication. We also sometimes see the use of images, which can help determine whether the website we're connecting to is actually the one that I should be. If somebody is actually faking a website or taking us from one of those fake emails into a website that perhaps is not the official Citibank or Chase Financial website, we have recognition that the image is not the one we selected when we set up the account.

Again, this is not multi-factor because it's all based on a single factor. It's all things that we know. Now if you don't really have a familiarity with multi-factor authentication, just think of it in these terms because you've been doing it for years, I'll almost guarantee it. Let's take the withdrawal of cash from an ATM machine. First of all we have something that we own. This is something in our possession hopefully and it's a physical object that without having this the rest of the information is not necessarily valid. We insert the ATM card into the ATM and the next thing we have to do is provide the secret information. This is the second factor. I'm combining something I have with something I know. Now this is a big step in the technology space and something that is getting a lot of attention in the regulatory realm because of the fact that it helps verify that the user connecting is the desired user.

We've been very busy at HelpSystems designing a solution that will allow you to do multi-factor authentication to your IBM i and beyond. Now we have a solution today within our portfolio that is tied to the RSA Secure ID solution. The intent with Powertech Multi-Factor Authentication, that we're going to talk about for a few minutes here, is that you don't have to be married up to RSA. If you prefer to do your own authentication, you are now able to do that. With that being said, I'm going to hand control over here to Bob. I'm going to let you speak, Bob, to the product process that we've been going through, give people a little bit of a sneak peek of what we've been doing here in the labs and see what they can do with that particular solution.

Bob Erdman: Thank you, Robin. We are going to take a spin through some of the features and functions of the Powertech Multi-Factor Authentication solution. We will start with the administrative user interface and some of the backend descriptions for you. One very important thing right off the top is you may have more than one Powertech Multi-Factor Authentication server so that you can have a highly available environment if you need to do maintenance or you want to have things in a primary/secondary/DR type situation. When you install the software you'll actually just tell it which system is your primary Powertech Multi-Factor Authentication for most of your traffic. You also will at this point determine if you would use SSL for secure communications. We would of course recommend that but that is optional.

We just install it that way and click the slider and enable your SSL integrations. Powertech MFA's administrative UI is served through our Insite interface, which is our unified solution to give you access to all of your HelpSystems products within that one Insite admin dashboard panel. You'll see here that we have moved on to a screen showing you the agents that you have on your different IBM i servers. Each of those servers will have a small piece of agent software that communicates back to the Powertech Multi-Factor Authentication product and out to your user community from whatever interface they're using to do their multi-factor authentication pieces. You may select one or more of those servers, whatever it is that you're configuring as you build this out.

You can actually disable those if you need to take those back offline at a later time, just by coming in here and enabling or disabling individual systems. When you first bring a system online you can set its default behavior. This default behavior will apply to every server as you enable it, and then you can go in and override and make exceptions on an individual machine basis. But if you're going to be pretty similar or just want some good selected default configurations that you're secure instantly, we allow you to do that initially when you build these out. Will you deny users access to bring these online? That's probably a good idea. You don't want people to just be diving into this before you're ready for them. Maybe you have some administrators or power users. You want them to be your test bed, be their admins to make sure that everything's functioning, and you can put those exceptions in here.

You can deny everybody except the three users that you say, "Hey, you can get in and test box and make sure everything's talking correctly before we open this up to our bigger user community." This is also where you configure your default behavior on the server exit programs within the system. Will FTP access be brought through MSA or Telnet access or you want the executable commands? Once you bring the system online of course the enabled exit points will automatically be hooked into. As you go in and edit that server property, if you need to you can individually enable or disable these on a persistent basis. When you add a new system ... This is just a generic screen that shows you how they come in. This is where you would tell it, "Yes, I want to use or not use the default behavior that we just previously looked at," and that's just the blue slider bar in the center. Should we take that or not?

You'll see it has the exit points as well where you can activate and deactivate, so this allows us to do our overrides and individually configure your systems. [inaudible 00:21:40] here just with the defaults off. We've added some power users to the system to be the initial people that are going to make sure that this is all functional. We're apparently denying all the other users access to this machine, so that this gives us a great way to independently set up and configure these systems as we bring them online within our configurations. The way we get users into the system to access through MSA can be accomplished in a few different manners. We can import from both Active Directory and in from the IBM i user profiles.

When you pull those in through Active Directory it will be through LDAP or LDAPS. If we also pull in from your IBM i profiles, you could enable a smart match function where we will try and take the Bob.Erdman HelpSystems profile from Active Directory and match it up to the B. Erdman IBM i profile. We will of course present the ones that we matched automatically to an administrator to do a manual check and do an override if they need to. Just a way to try and help get people quickly into the system and able to use the solution. You can also of course, if desired, just manually enter users at any point. When you're setting up your LDAP interface you're just going to tell it, "Are we going over standard LDAP or are we going to use LDAP with SSL?" Credentials in to talk to the actual Active Directory, and then we're going to give it the default container that we want to reach into where are we going to get these users from when we initially do our import.

Then "samaccountname" is the field value that we'll be using to pull those in and try and match them against the IBM i side. Same basic look and feel to the IBM i import. We're going to give it the server, the system name, whether or not we want to enable the Smartmatch to try and match up those users to the Active Directory profiles when they're imported automatically. Then we'll take a look at how those view here for you. Once you have your users imported you can individually or bulk perform actions upon them. The top toolbar allows you to select as a group and enable them all in mass, disable them all in mass, set their different authentication parameters, and add them to different groups for easier management. You'll see over on the right side of each of the user rows there's a hamburger menu that allows you to individually take the same actions on a user by user basis.

We're giving you lots of flexibility on how you want to bring users online into the software and allow them to start accessing it with their chosen endpoint devices. Here's your view of IBM i server profiles as they are pulled in. You'll see that two of the profiles have stars next to them. That is the indicator that we attempted a Smartmatch and took that user profile and that Active Directory profile and we think this is who it belongs to, and just asking you to validate that and bring them through. You'll notice there is a user that has the same name on both systems. Since it matched completely we don't really consider that a Smartmatch, so we don't put the star on there. We know that that one's correct. It just gives you a much easier way to bring people into the system, mirror their two different credentials if you are an Active Directory shop, and then IBM i side on the other side, and pull them together.

We have a variety of different methods that you can use for your authentications. These are all controlled by the administrator whether or not they will be allowed for a set of users to access. One-time passwords, which are the rotating passwords on the system, mobile push notifications where you can just confirm on your mobile app on either Android or iPhone, biometric fingerprint scanner. That is on your cellphone device. We are not storing the fingerprints or anything like that. We are simply going out and poking the end user device and having them put their finger on the fingerprint reader if they've already got that stored in their system. We have the user fingerprint sign in instead of punching in their PIN to get into their phone.

We'll just get a simple yes or no, "this is the right person" back. We're not storing any biometric information on those user base communities. YubiKey, which if you're not familiar with those, are personal encryption devices, a variety of USB-type form factors. Once you have those set up, if you're prompting with a YubiKey support, you put that in the USB of the system that you're working on, touch your finger to it to electrically activate it, and it will confirm that you are holding that token and that it is you and that you should be allowed into the system. We also have the ability to do a printed list of one-time passwords. The expiration length on those passwords is controlled by the administrators as well as whether or not they actually allow it to be used.

You may want that if you are maybe going on a trip overseas where you're not going to get connectivity and you just need to make sure that you have that list, or you're going down into the data center where there is no outside mobile wi-fi access and you just need to have a list of passwords that allow you to sign into the system from the green screen. You can take that with you. It has a defined expiration, and then you can use each of those codes one time to get into the system for your account. When new users are enrolled into the system the administrators of course control what they're allowed to do at first blush. You may allow them to only authenticate after they've registered an external device, such as a YubiKey or a cellphone.

You may allow them to directly start using one-time passcodes. You get to choose that. The portal timeout is just how long they're going to be allowed into UI without inactivity. It's pretty self-explanatory before it's going to log them out. Then your printed OTP password expirations. Of course that is only active if you allow that as an authentication method. How many days are those passwords valid for? Could be one day. You may want to set that to a really long, almost unlimited time. We would probably recommend against that. A happy medium value for your organization of how long you'd allow somebody to walk off with those. So if they're going on a three-day trip, give them a three-day worth of passwords. On day four they expire, those type of things.

Administrators get to control that and get to set those values for the users. Users are sent email notifications when they are enrolled into the system so that they know how to jump into the user portal through the link, configure their devices that they are individually carrying. Those will just be directed through your corporate mail system. We just send an email at that user ID and let it get delivered, so nothing super fancy there but just wanted to make sure that we touched on that for you. We'll take a quick look at the major screens of the mobile application if your users are going to be allowed to use the mobile app. The easiest way to enroll your device into the system is when the users go into the portal they will get a QR code on the screen that they can use to automatically enroll their device.

They can just hold their camera up to the screen, take a quick shot of the QR code, and it will automatically give them their secret key, their user ID, and it will fill in the address of the Powertech Multi-Factor Authentication server, its actual DNS name of where they're going to be connecting to across the network. They do of course have the option to key that in, where you can just type in the secret key that's provided on the portal and your ID. What you see on the third screen is the rotating one-time password that would be presented to a user in the app. It's a six-digit rotating code that they get to use when they sign in. You'll notice that the screen is split into blue and black. The black is actually a countdown timer. It matches the little 25-second clock at the bottom of the screen there.

The users don't have to keep watching the clock. They can visually take an easy look at the screen. See, my black bar is almost gone. I should probably just wait for it to rotate a couple more seconds and then I can have a fresh password to use when I authenticate in. We are not sending these notifications over SMS. This is actually just doing a push notification to the phone through the app [inaudible 00:30:19] Google Push services. We're just tagging the phone, saying, "Hey, we've got an authentication request," and they can go out and take care of that from their devices. There is also a green screen-only version of this, so if you are working purely from the green screen terminal you can of course get in, do the MFA authentication codes right through your green screen, not having to use the phone or the desktop application.

I'm now going to share my screen. We'll take a quick look at the Windows desktop version of the application for everybody. Okay, so you should have a beautiful picture of one of the NASA space telescopes here on your screen. Then what I'm going to do is ... Excellent. I am going to make an FTP connection attempt to one of my servers here on the system. You'll see that Powertech Multi-Factor Authentication has popped up. The server I'm attempting to access is HOTEL2. You'll see that I'm coming in through FTP, my profile name BERDMAN, and the date and time. At this point I can deny or allow that connection attempt. Main reasons for denial would probably be I actually did this by accident, or this is coming from somebody who's trying to connect as me that shouldn't be and that gives me an indicator that I should let the security team know.

The software is also watching that and looking for those denial attempts, so we don't really expect to see those very often. Or it can just allow the attempt to go through and that's going to give me some options on how I want to do my connections. Since I have one-time passwords enabled on my system, I could at this point get out my sheet of paper, look for the code that's valid for me today, and I could type that in and submit it to the system to get my full connection through. I'm going to actually do this off of the cellphone side here. On the cellphone side I can either do a push notification to confirm it on my phone, I can do the biometric authentication where it asks me for my fingerprint, or I can just key in the rotating one-time password that is appearing in my app, and that's what I'm going to do here. Once I submit that, if that is actually valid, the system will tell me that that's great. It will let me go on through and get connected the rest of the way into the system.

That gives you a way to really maintain good security on all of those access points. There are also a few settings that you could configure inside of the desktop app. Whether or not you want it to be started automatically when the user starts the Windows system, if it should be allowed to remember their credentials, either Active Directory or IBM i profile that you would like them to always be signed in or if you're going to make them sign into the Powertech Multi-Factor Authentication app every time. Probably depends on how good the security is on the corporate connections on the computers that they're using. And whether or not they want a sound to be played, as I did here when it popped up. You may have heard that through my microphone, that it buzzed my computer and played a sound for me as well as gave me the big visual indicator. Thank for letting me do that, Robin. I'm going to turn this back over to you now.

Robin Tatam: Absolutely, and what a great insight into a tool that I think is really going to become a major player in authenticating users to not only IBM i but as we move forward to other platforms as well. In fact when we get to the end maybe we can talk about that just a little bit with regards to strategy there and kind of what that is going to allow us to do. Just to wrap up then, just really the summary. Users are typically too powerful in an IBM i space, but they demand simplicity. Passwords have always been a dichotomy of trying to make them too complex and that makes them hard to remember, but it makes them no more difficult to breach. We have passwords. Again, they're often weak. They're often easily compromised and we've got to find a better solution in order to be able to not only verify that we have the information necessary to connect, but we can also identify the person as the individual that those credentials were given to.

We need a solution that's going to be flexible and can handle different connectivity methods. I think that's part of what Bob's been able to show today. Certainly not showing all the bells and whistles of course, but giving you at least a taste of where we're headed with this stuff. The goal at the end of the day is to lower risk. The human factor is really what comes into most data breaches. Servers don't hack servers. It comes down to people, and the compromises of those servers often is also caused by those connections. Lot of us are doing this now because we have to. PCI is mandating that we have to use multi-factor authentication. But a lot of us are choosing to do it for best practices. We know that passwords can be compromised and we want simply a better mousetrap. Our call to action today is quite a simple one.

If you've never had the security configuration of your server validated, I'm going to make the same offer I make on all my webinars because I love to do this for people, and that's to review your IBM i server. We can take a look in a very comprehensive but fast manner. It usually takes less than a minute to do this. It doesn't cost anything, so there's no cost or obligation associated with this. If you'd like to see the type of report that you see on the slide here, we'd be happy to provide that to you. It's actually a tangible document that you can then leverage internally. The Powertech Multi-Factor Authentication tool is part of a very comprehensive product set. This is the component that fits within the identification and access management segment, along with our power admin tool, but we've got many other things from intrusion detection to managed file transfer to encryption of course through to compliance reporting.

The big part for me is the synergy between not only the products and the tools that we propose to people but also the services that we can back this up with, ranging from evaluation to remediation and even managed security services to kind of own that configuration on your behalf. If you're interested in more information just head out to helpsystems.com where you can find trial download links, you will have demonstration videos, how-to articles. If you are interested in one of those free scans you can request that there as well. We're going to use the chat window. If you do have any questions, feel free to use them there, and Bob and I will take a quick look and see what we've got. As you think about perhaps if you do have a question or you want to pose that, I'm going to go ahead and open up a quick poll here.

Let me fire that up here. It's just a three-question poll. I'm interested in whether you're currently using multi-factor authentication or whether it's on your radar. If you are interested in the scan let us know there, even if you'd like more information before you make a decision. I'll give you some feedback here as to what folks are doing in the MFA space. All right, looks like so far 100% not currently using multi-factor authentication, but 78% of you do have it on your radar. That's a good thing. I'd be curious, and you can throw it in the chat window too, if you have a regulation that is mandating that or whether it's just out of your own due diligence. All right, I'll just give you about another 20 seconds to wrap that up. If you are answering those questions, thank you.

We appreciate that feedback. We'll take that and that'll help us going forward. Looks like we got some PCI mandates being thrown in there. All right, five seconds. All right, so the end result is 82% not currently doing MFA, 12% are. Then 61% have it on the radar, 27% do not. That gives us some feedback. Certainly there is a disconnect between the people that want to do MFA and those that are currently doing it. All right, well, I appreciate that feedback. Like I said, we'll look at the chat window here and we'll see. All right. Bob, I'll let you grab any questions you see. I do have one: "What's the difference between 2FA and MFA?" Two-factor authentication is actually a subset of multi-factor authentication. We've started to see some terminology shift whereby PCI has talked about 2FA and is now talking about the desire for MFA.

What is the difference? Well, two-factor is simply that, two factors. Bearing in mind, again, they have to be from two different categories. It can be something you know along with something you have. Multi-factor is two or more factors, so there's no limit to say I can only use two factors. Honestly, the more factors the better. What we've done is take the approach of multi-factor, and that's what most of the regulations now are speaking to because they would encourage you to use more factors because the more you use, the more secure it is and the more you're able to identify that individual. Bob, Jeff had a question here about the desktop application working in a Citrix environment. Have you done any testing with that yet in Citrix?

Bob Erdman: We have not specifically tested it Citrix at this point. From past experience we see no reason why this would not work on the Citrix desktop environment, and we would certainly be happy to engage in a free demo or a trial with you and get that set up and actually make sure that that works to your satisfaction. I did see one other question out here about whether or not you need to have Windows in the environment or can you do this directly on the IBM i. You do not need to have Windows. I'm showing the Windows desktop page because I'm actually running Windows for my WebEx presentation, but you can do this directly from the i. You do not have to have the Windows agent. One other question that came up: Have we tested this with Symantec VIP access? We have third party integrations on our near-term roadmap once we have released the first version of the product here. We will also be releasing agents for Linux and Windows that you can holistically use this across the environment, but for this first initial release this is purely IBM i only.

Robin Tatam: All right, fantastic. Well, we'll hang out for another minute. I don't think we've missed anything, but certainly we'll scan back through because we have a whole bunch of chat about different things. We'll make sure ... Oh, there Larry posted a quick question about using AD.

Bob Erdman: It does not require AD credentials. It just allows you to pull them both together if you have both.

Robin Tatam: Anything with single sign-on there looks like ... Dari asked a question about single sign-on and EIM identity mapping and integration with MFA.

Bob Erdman: We have the single sign-on third party integrations on our near-term roadmap. It will not be in this initial release, but we are going to definitely be going that direction as well as integrating two specific applications, both from HelpSystems and from other third parties. They would work like an exit point.

Robin Tatam: Yep, so Dari, if you do have specific requirements, reach out to us. As we develop any of our product roadmaps we're always looking for customer feedback and we factor that into a lot of our development roadmap plans of course. That's no different here. If there are specific requirements we absolutely want to hear about those, so if you're willing to share that information with us we can absolutely factor that in as we continue to evolve and build additional features and functions into the solution. All right, well, Bob, that's I think all the questions that we have today. I want to wrap up here, give people a little bit of time this afternoon. I appreciate everybody's attendance. Look forward to seeing you on an upcoming webinar. If you do have any questions about multi-factor authentication or in anything security-oriented, feel free to reach out to HelpSystems via helpsystems.com. You can go to the chat window there and make contact with us and we will make sure we get the right person on the line with you. Again, thanks for joining us. We appreciated this opportunity and we'll be speaking with you again soon. Have a good afternoon.