Getting Started with IBM i Security: Integrated File System (IFS)

You can maximize the window here, so that you can see the full screen as we go through. I actually will keep it minimized but you can certainly maximize it for your own needs there. At the end, we'll have hopefully a short period for Q and A, so if you have a question you can shoot it through the chat panel. I'll do my best to get to it at the end. If not, then I will reply to you afterwards. Let's get started.

My name is Sandi Moore. I'm a security consultant with HelpSystems, I've been working with our customers for over 15 years now in many different capacities including training, support, testing, and now in a security role helping customers identify security needs on their system and where things need a little bit of extra help. Hopefully, I'll be able to share some good information with you today.

A little bit about HelpSystems Security Investments. First, we do have Premier Security Products that are globally recognized with our Powertech brands and are represented by Robin Tatam, an industry veteran. A lot of information there. I'm sure you're familiar with him, heard some of his webinars, as well.

We also provide comprehensive IBM i Security Services. We are a member of PCI Security Standards Council, authorized by NASBA to issue CPE credits for security education, as well as a publisher of the Annual State of IBM i Security report.

Today’s topic is the IFS, and we start out with a few basics about the IFS and why you might need to care about the security of it. If you Google or look on Wikipedia, there's a lot of different terms that this can mean, but of course for our purposes today, we're talking about the Integrated File System on your IBM midrange and mainframe systems. According to Wikipedia, it’s the POSIX compatible file system provided by the operating system, as opposed to the traditional non-POSIX file system it also supplies, so basically your integrated file system. And, it’s a term to describe the various file systems that are available under IBM i. The IFS was added back in V3R1 to make the server more versatile by allowing multiple filesystems and operating systems to act upon the data that's stored there. To start here, similar to what you would see on a PC, however on the IFS, each of the different file structures may have different rules and limitations. For example, the library structure has specific object naming rules and a limit of only going one directory deep. All of these structures are contained with a single directory that is referred to as the root.

A common misconception is that the IFS, refers to everything other than the traditional libraries and document library system that previously existed in the operating system. The document structure was originally used by IBM's Office Vision products, which enabled green screen office-type functions like mail, document editing, as well calendaring. It also enabled the first storage of PC type documents could be accessed by a PC by a facility called shared folders.

Actually, the reality is that the IFS encompasses all of the file systems found in IBM i. This includes the traditional libraries and objects that we are used to, as well as the document library system. Part of the reason that many people see the IFS as an extra piece to the traditional structures is because the entire system save process was changed at V3R1. Hopefully the IFS was included in that organization state strategy. Adding the state gave the impression of something separate in additional, however.

If you look behind the help text behind a Go Save Option 21, you'll actually see that the IFS is saved with an omission for the two existing file systems, \QSYS.LIB and \QDLS. You could technically perform an entire system save by just saving the IFS, but the restore processes that are built in the IBM wouldn't actually allow you to be able to recover from it. I've actually had customers tell me that they don't use the IFS, they don't worry about it, they're not using it, they don’t talk about carrying it, and unfortunately, this is not possible. As we saw on the previous slide, even your operating system is a branch of the IFS, so you're absolutely using it. Data from green screen applications is often acceptable by the IFS, and the permissive levels of object-level security found in virtually every edition of our State of IBM i Security Study, means that we have to take this exposure seriously.

There are many applications that utilize it, including IBM i access (ACS), Apache HTPP Server WebSphere. Many client server applications, such as JD Edwards use it as Well. Powertech’s Compliance Monitor Solution makes extensive use of the IFS, as do many of the other HelpSystems tools.

 You might be hoping that it’s already secure. However, this is the unfortunate misconception that the IBM i operating system is already secure.

While we do agree that it's securable, there's a significant difference between those two words. And ironically, IBM i operating system is one of the most securable in the world, but it's just any wide open configuration. Unfortunately, the majority of organizations don't take the necessary steps to change this. Under most operating systems, if you're not granted access to something, then you have no access. IBM i however, is unique and contains a concept called *PUBLIC, which encompasses any user that does not have an explicit authority. For those native objects such as your libraries, files and programs, this public authority is shipped at *CHANGE which is sufficient enough for a user to read, change and even delete data. For the IFS, the public authority to the critical root folder is   read, write, execute (*RWX), plus all of the other possible object authorities, which is the native equivalent of *ALL Authority and should be changed immediately.

We'll talk about the recommended settings shortly.

When organizations often place a lot of trust in their people being able to access the servers, authorized users usually have privileges far beyond any business requirement and users are often given that access that profile and a password within just a few days of starting their employment. A lot of times, I hear about security by obscurity, where organizations are hoping that their users, or people pretending to be their users, are policing themselves, even though technically that user could access the customer master data file, they hope that they really wouldn't do that.

Unfortunately, the State of IBM i Security Study shows that most organizations still base their security on lack of user knowledge or malicious intent. An average system has about 147 users with *ALLOBJ special authority, and the average is 76 enabled profiles have default passwords.

While it doesn't matter if Bill has worked in the company for 20 years, you can't base a corporate security strategy on him having perfect ethics.

And even if Bill had those great ethics, he's still human and can make mistakes.

Of course, there's always a chance that Bill doesn't have perfect ethics and is more than willing to hand over customer data to a competitor for a down payment on a new car. After all, wasn't the organization asking for it because they gave Bill all that access to the system? Perhaps Bill is simply trying to prevent a foreclosure on his family house. In a study from a few years back during recession, they found that a number of employees actually were willing to compromise their ethics at the workplace in order to maintain their way of life.

And in order to keep your family in your home, you might consider doing things that are a little bit outside of what you would typically find as an ethical business model.

Unfortunately, when you're in the middle of a recession, projects and staffing, the monitor and detect compromises on your system get reduced. So, people are required to do more with less, and while not every security event is malicious, sometimes there's just simply mistakes that can end up costing your organization just the same.

We talked about the IFS a little bit and what it is and why it's important.

Now, let's talk about what the IFS is a mixture of.

It's got IBM i, Unix and PC structure to it, and each part of that impacts how you actually are able to secure it. Background first, every object has two categories of authorities in your IFS. Object Authorities, which control how the object itself is accessed, and Data Authorities, which control what a user can do to the data inside that object.

Of course, not every object in the IFS has data per say, but all of the objects do still have the same two categories. Data authorities are what most of us know and think of, these give the user the ability to read, update or delete data. The execute authority is slightly different but does allow a program to be invoked or a library to be searched. Object authorities control the ability to delete an object or to rename or copy it. I do want to point out that that object operational authority, which allows the object to be used, without that OPR or operational authority you can't do anything with it. Although you can manually specify any mixture of these authorities, IBM i does contain templates of the authorities to handle common requirements. Examples of this are *USE and *CHANGE. In IBM i, there's a pretty unique authority of *EXCLUDE, which is the authority to do nothing with the object. And this is actually necessary, due to that public setting that I mentioned earlier. This list actually shows summary of the data and object authorities, and how the IBM templates define them. I am not going to actually go through each and every one of these. This list is more for reference and because you will be able to get that link to the recording later on, as well as request a PDF of the presentation, you'll have that for reference. So, certainly go back to that and use this information as needed later on.

Alright, let's talk about IBM i authorities.

The IFS Security Model is a unique combination of those IBM i authorities, the PC file properties, and the Unix file permissions. Because we have those extra pieces to contend with, a Unix component is critical in as much that the IFS Security Model is based on that Unix Security scheme.

First thing you'll notice here is that if you look at the authority for an IFS object is that the object operational authority is now considered a data authority. That's because Unix doesn't understand the concept of object authorities and object operational is required for that IBM i to allow a user to use the object. In the world of Unix, we don't talk about the normal user change. Instead we have read (*R), write (*W), and execute (*X) and many combinations of that. Permissions often closely align with our traditional authority model. For example, the authority of *USE would be the equivalent of *R and *X. Operational authority is given automatically. *CHANGE authority would be granted by giving *R, *W, and *X. Again, operational authority is given automatically. Interestingly enough, there's no Unix equivalent of IBM i’s *ALL authority template. If you wanted to actually assign objects in Unix authority, for example, you would have to assign it manually.

IFS objects are also similar to the PC files in that there may also be properties that will impact what a user can do. For example, an object can be marked as read-only, so that it can't be changed or deleted. Even by a user that has *ALLOBJ authority.

Of course, remember those *ALLOBJ users can change the properties and then access the object anyways, so you have to watch out for those *ALLOBJ users and keep them to a minimum.

Other attributes include whether the file is hidden or is considered a system file, and whether it has been changed since the last time it was tagged.

There's several ways you can alter the properties, including a native change attribute command. If you're using navigator, you can access all of the authorities, permissions, and properties through that. This year, if you have NetServer started, you can access the object and do a right click to access the properties, just as you would with a local PC file. Another property comes via the support of a check-out feature. This allows the user to indicate that they're working with an object so that no one else can perform conflicting functions on it.

If you are running on IBM i v6.1 or newer, which I hope you are, then you can even check out an entire directory, as well as the sub-directories. Regardless, the IFS objects are still IBM i objects, and there are certain rules and conditions that still have to be met. As I mentioned earlier, with the exception of operational authority, object authorities are not granted when using only the *R, *W, or *X data authority setting. If you want a user to be able to delete an IFS object, then the object authority of *OBJEXIST must be granted to that user.

Now we have covered a little bit more about the IFS and can see why some people avoid it. It’s confusing, and there's a lot of pieces to it, but I really want to share with you guys some ideas on what can be done to actually start securing it. I mentioned the root directory earlier, and this is the base directory that contains the directories for all of the file systems. We have to be very cautious though to not over secure the IFS. It's easy to do based on the different security model being used and also those nesting of those directories in your path. I strongly recommend that you make detailed notes about any changes that you're making so that they can be undone if you discover a problem afterwards.

Restrict the Right to Write, as a reminder, the IFS root folder ships from the factory with the IBM equivalent of *PUBLIC *ALL authority. This allows users to delete existing objects and to create new objects, including new directories in that root folder. Our recommendation is to revoke the ability for those end users to write new objects to the root. Using *W *R they can read the contents, but this might not also be necessary if there's no objects for them to read, and they don't need to see the folder paths.

I often revoke all of the object authorities, as well as there really should be no need for users to delete objects if they can't create them in the first place.

Now remember we're talking about the public here. There might be specific users that need these kinds of privileges, but it shouldn't be granted for every user. And, just as with your native object access, *ALLOBJ special authority overrides any of these restrictions. A note of caution though, do not change the *PUBLIC authority to the root folder to be *EXCLUDE. Access is necessary for users to be able to access subfolders, things like IBM i Access, as well as some of your system processes.

One of the decisions that you will have to make is whether users should be able to see the contents of a directory or simply be able to drill down to the sub-directories inside of it.

*X (execute) authority is sufficient to traverse a directory structure. *R (read) authority is necessary to see the contents of the directory as you go. Of course, any access requires object operational authority, and for the IFS that's granted under the covers with any combination of the *RWX data authorities. Rather than having users accessing miscellaneous directories or creating random new directories, I suggest that you provide a user with a working directory that's going to be a much easier way to manage this process. You can create a directory under home for each of your users, restrict authority just for that specific user. You can do this by granting *X (execute) authority to the parent home directory. This allows the user to navigate to sub-directories without being able to see the contents of that parent directory. Next we can exclude the public from all of those personal directories.

And then finally, grant each user the permission to *RWX for their own folder.

So how do you grant all of these authority settings? There's some commands that are similar to the native IBM i commands. Talking about WRKAUT and CHGAUT, that are actually simply dropping the OBJ from the native cousins like most of the other IFS commands. If you use Navigator, then of course these settings can be accessed directly from there, as well.

Restricting access to Qsys.lib. As I mentioned, one of the file structures available through directory is Qsys.lib. This is a structure that provides usability to your native libraries and objects, and is rarely accessed legitimately by the IFS view. IBM provides an authorization list to secure user access to this Qsys.lib structure. The authorization list is called QPWFSERVER, and it ships open because of that *PUBLIC *USE setting.

We recommend to all clients that this should be changed immediately, to *PUBLIC *EXCLUDE. Then if you have users that need access, and very rarely do we hear that request, but you can grant it to that user by giving a private access to that authority list.

As with most authorities it is not effective against *ALLOBJ users, but it is a good supplemental layer for everyone else. Even if the user has authority to the payroll library, they wouldn't be able to access it this way, without also having authority to that authorization list.

Managing your file shares.

File shares are how many users access directories. When we perform an audit, we typically request the list of the shares in that environment and that have been defined so that we can question the legitimacy of each one and see if the root directory is actually shared.

My recommendations include limiting shares that are not really required.

You'd actually be surprised at how many clients have 10, 20, or even 50 shares defined, and they have no idea why, they can't explain what they're for.

If possible, make a share “read only”. This is effective against every user, although those powerful users would be able to go in and change that configuration on you. At least it will slow them down and hopefully give them pause. If you expect the user to be able to navigate through the directory structure, remember they only need *X authority to access folders in the past.

Lastly, please resist the urge to share the root folder, as it's rarely needed for your end-users.

Auditing your IFS object access. If you have sensitive data in IFS, then you should strongly consider activating auditing of that object or objects. It's simple to turn on if you're already auditing those native events.

First, you need to ensure that the QAUDCTL system value includes that *OBJAUD value. This is the recommended setting even for your native object access, as it acts as the on-off switch to permit that object level auditing. Then use that CHGAUD command to activate the desired auditing levels. With your native object auditing, collecting the data is pretty easy, but reporting on it is usually a little bit trickier.

One option is to supplement the operating system with an exit program solution, and we'll talk about that more in a minute.

Any newly-created files in your IFS can inherit the auditing setting from the parent directory. The off value is *NONE. There's two basic settings *CHANGE and *ALL, which says audit for either changes or audit for reason changes respectively.

There's also a couple of other values *SYSVAL says to inherent the value from the CRTOBJAUD system value, and the user profile option defers the decision to the user's object auditing setting on their profile. This actually allows for files to be audited only when they're accessed by certain users.

Secure your native IFS commands. Users without command line privileges, are not able to run native IFS commands.

However, I don't want you to overlook the fact that some users can run commands through non-5250 interfaces that don't actually respect the restriction granted. Put in place by that LMTCPB(*YES) setting. For those users that can execute commands, most of the IFS commands are permissible and should be secured where appropriate. This can be done by object authorities on the commands or better yet, through a selective command solution. Something like our Powertech command security, where you can select which users can use, which commands, which parameters they're about to run.

These are the examples of the commands that allow a user to move data back and forth, between native objects and IFS files. Also have listed here, a few management commands that non-IFS users typically should not have access to.

The bottom line is you want to make sure that users are not leveraging the IFS, to gain access to information in ways that allow them to duplicate data for offline access. Or, that they have access to application structures that they really don't need to be in.

 A big consideration with the IFS is that it doesn't support authority adoption.

This can represent a challenge to applications that are built on that foundation of adoption, so you need to find another tool when accessing those IFS files. One way is to use profile switching, which uses IBM supplied APIs to switch a job’s user to a new user on the fly. We actually use that technique in our authority broker software, and that can actually be embedded pretty easily into your own CL programs to manage and track this activity. You can use the analogy for this as Clark Kent going into a phone booth and coming out as Superman. We still know that it's Clark under that suit, but we can audit the activities while he's navigating in this powerful alter ego. When he's got a Superman suit on, we know what he's doing, we know where he's at, we know what he's done.

This picture here is pretty much that your security's at the mercy of multiple control.  And this shows how users see your security controls. They're going use them if they absolutely have to, but if there's an easier route, they're going to take it. In this case, security policy is not providing much value as there's a lot of easy circumvention and security. It's possible that your controls are similar on your IBM i, so you need to configure certain aspects of the security model, but users often have just too much power and perhaps the public authority to the files is entirely too permissive. Just as we see on the native side.

We often talk with our customers about exit programs, and these are simply programs that get invoked during the process, in order to perform some function before the original request is performed. These programs might check a user for some specific required attribute or validate that the application is configured to perform this task. With the security exit programs, we want the program to ensure that the user should have access to the requested function and that we audit that request. Something that the operating system often doesn't do, unless there's a subsequent authority violation. Now, there is an IFS exit point that allows an exit program to interrogate and validate the request as authorized, even before those object authorities are checked. So there’s that extra layer of control, so that you know what's going on before the user gets to your system. There are a number of functions that can be audited, as well as prevented with that exit program, including the navigation of those directory paths, the creation and deletion of IFS files, as well as when a file is opened. This can either supplement or augment IFS’s own security model and it's effective on all users even those all object users, as the exit program gets invoked prior to any native authority checks.

When using a commercial exit program like Powertech’s Network Security to audit that activity, the reporting and exporting functions are greatly enhanced from what's possible with native IBM i. In fact, if you've ever tried to read or target the security audit general manually, you know what I'm talking about. It is hard to read, it’s a lot of information, kind of a needle in a hay stack.

This slide actually shows an example of a user that may have wandered into payroll directory, an activity that could potentially be a problem. IFS is one point of access that network security can address, others include FTP, ODBC as well as remote command.

 No discussion about IFS security is complete without actually bringing up antivirus. We can't overlook disruption by viruses.

Yes, I know virus on IBM i? Surely not. Well, this is an area of great misunderstanding, due to the fact that IBM i operating system has always been heralded as being virus proof. Technically it's virus resistance, there's no such thing as virus proof anything. It's important to understand how these viruses can impact your server including those running IBM i. Natively, it’s a very secure environment due to the object design that prevents objects from simply being renamed from files to programs or vice versa, or being tampered with after they've been created from the source template. However, IFS is a different story. This PC like structure can house infected files and cause major disruption in your network. Viruses can spread to and from your IBM i. Obvious one, there is Mapped Drive. The ability to have that immediate connection between your PC files and your IFS files through the Mapped Drive. IFS is another obvious one, the ability to push and pull files on and off the server to either the IFS or your native file structure.

Additionally, viruses can spread from a lot of other sources. IBM i from business partners, third-party vendors basically anyone who sends you a file or a CD or download from the internet.

How do you know if that third-party vendor has unknowingly sent and infected  HTML file on the disc you just installed? Even seemingly harmless IBM i safe files can contain infected files. Because the safe files are encrypted ebcdic, they're not actually going appear as infected on the PC before you load it up to the system and wouldn't be detectable to that PC-based scanning and could be easily populated to your system.

Needless to say if you have an HA set up, then an infected file on one system, equals an infected file on that backup system, as well. Obviously, if you save an infected file to a tape, then use that tape to restore, that virus is restored to the system again.

Client access has actually been another source of virus outbreaks. We had a customer contact us awhile back about a problem they were having with viruses on their network that kept re-infecting the PCs despite their clean-up efforts. The update function that runs when client access starts is a way to easily infect every PC in the network, simply by starting up that terminal emulation session that green screen session. To make a long story short, this particular customer’s PCs were all running client access, and the setup.exe files for client access, which is located in your IFS was actually infected. So, every time that PC ran the automatic update, which was every morning when they opened client access, they would run that setup.exe file and then it would start the virus infection on the PC again. So, weeks later, figuring out that finally that was the function that was triggering the virus infection. And it was a shock.

Not what you would normally expect.

We have actually had some un-enlightened auditors suggests that antivirus is not a requirement for i based servers, but we beg to differ there and so does IBM. They actually built the supporting infrastructure to support native antivirus solutions, such as our Powertech Antivirus (formerly known as Stand Guard Anti-Virus). This is invoked via either on-demand or a scheduled local scan or through exit points that check an object before it's opened or closed.

IBM had recognized that the IFS could actually very easily be infected, and they charged third-party vendors with building a scanning engine. On a regulatory note, if you're dealing with PCI compliance mandate, then requirement 5 actually demands all servers be protected by a well-maintained antivirus solution.

However, don't want you to scan from the network.

I have actually had a customer suggest that they could simply map drive to the IFS and scan it from another server that's running an antivirus solution. This is bad for several reasons.

First, it requires you to configure a right capable share, possibly to the root folder.

Something we discussed as not a good idea. That share needs to be accessed by a powerful profile, so they can access all objects. This was a bad idea too. From the perspective of bandwidth and speed, all the projects have to be moved to the memory of the scanning server. This can consume critical bandwidth, performing a slow scan of a server that's paths have been connected to the network during the virus outbreak.

So if you already have a problem going on with viruses ramping on your network, you're going to add to that with that mapped drive and the fact that you're moving that data in clear text. So, it is now also exposed.

The operating system has no idea if that PC software has discovered an infected file either. There's no tie, in fact, to the structure that IBM provided for virus scanning. So, you might think that scanning is a good thing, but scanning from another server can actually make that bad situation even worse.

This photo shows here this woman thinks she's doing a good thing. She's gassing up her car, and I don’t know if you can see it there, but in her left hand she's got a lit cigarette. As we don't recommend refueling your car while you're smoking a cigarette, we also don't recommend overlooking antivirus for that IFS.

Key actions for you today. First, you need to determine what applications are using the IFS. Exit Programs can help you find that. Might be line of business application, or infrastructure applications like webservers or client access. Highly recommend you do some reading on how the IFS handles security. There are some great books out there on this topic, and the information center is a good source of information as well.

Suggest that you establish security for key directories like root or home. Also, lockdown IFS access with the need of Qsys.lib structure to prevent the accidental deletion of a library by an overly powerful user who thought they were deleting a folder from their PC. And yes, it has actually happened.

You also want to become a little bit more judicious about the shares you create. Make sure that you're policing them, to make sure users aren't creating new ones, and any user with navigator installed can potentially perform that function. If you're not already using an exit program to monitor those IFS activities, I suggest evaluating Network Security to monitor and report on the user access. You'll also get the added benefit of access control, and auditing some of the other powerful TCP services such as FTP and ODCB. Acknowledge the risk of virus infection and implement a commercial antivirus solution like Powertech Antivirus for IBM i.

Lastly, while it does sound obvious many of us don't do a good enough job of documenting any pending changes and testing them before rolling them out to a production server, make sure you're testing that. If you don't believe all the things that I've talked about that users can do on your system, go ahead and try it. See what you can do as an average user, you'd be amazed at what can pop up on your system. You can also take advantage of our free security scan, which is one of the things you can do, go out, and look at each of the IBM of servers and tell you whether or not you have exit programs attached. We can actually see if there are individual exit points, the tool does a ranking and indicates how important particular exit programs are, but that ranking going to those exit programs that control the flow of application data on an office system or facilitates command execution. We can actually use this effective tool for free to look at your own system. You can go to HelpSystems.com and find that information out there. You can send a chat message through to me, as well, and we can get that arranged. It's a great tool, shows a ton of valuable security information in six different categories.

Oh, and it's free.

This is kind of what we see going on with IBM i, especially as organizations are increasingly doing business over those network interfaces. Unfortunately, security awareness among IBM i professionals is pretty low, relative to the security awareness among Linux, Windows, and even networking professionals.

I think it's a lot of because a lot of us have heard over the years from IBM that the IBM i is incredibly secure and assume that IBM has already done all the leg work for us, and that there really wasn’t anything left for us to do. On the flip side of that, the auditors that are out there have learned exactly how to audit Windows and Linux systems but haven't really figured out how to effectively audit our system, so their expertise on our platform is fairly low, as well. That's good news, bad news though, and it's historically been easy to pass most audits because they really don't know what the vulnerabilities are, but they all still ask questions and demand action on things that make no sense based on IBM i strengths.

To give you an example there, we've had auditors say, "Hey you need to encrypt your entire IBM i system”.

That's not something that can happen. We can do that with those other file systems, but with IBM i encryption is at the field level.

We also know that some valuable data in any organization is stored on that IBM i, and it’s often the core business application that runs these businesses, and based on our Annual State of IBM i Security Study, we find that most of the data is not actually properly secured.

Add all that up, and you come up with the perfect storm of vulnerability. You have IBM i machines out there that are accessible from the Internet. Oftentimes, the system administrators don't know and won’t admit that that data on the system is not very well secured.

Understand this is not just a challenge for internet-connected systems. You're just as likely to see this issue on any server, regardless of whether you offer it to the outside world.

In fact, most studies indicate that between 60-70% of data that is lost, stolen, or damaged was actually initiated by a user from inside the firewall. If you think about it, that makes perfect sense, as the best defense you have for your data is a user profile and password, and your internal users often get that on their first day at the company.

You can learn a little bit more about IBM i security. There's our free download, we actually have the 2017 State of IBM i security study available, as well as previous years if you want to compare. Just know that the numbers do get better over the years, things have improved, but there's always room for improvement. And security is a moving target and once you set things up, you have to keep checking up on it.

If somebody deletes a program, changes your user *QSECAUTHOR user profile, changes a system value, and you don't have that IBM security audit journal configured and auditing turned on, you’re not going to be able to see what happened.

Good news is, if that QAUDJRN, that audit journal, is free, it's part of the operating system, and you own that functionality. So, you can take advantage of that and start auditing what's happening on your own system.

We are going to wrap this up a little bit early, so you guys can get off to lunch if you're on the East Coast, you might have actually sat through this through lunch hour with me today, and I appreciate that, as well.

So, if do you have any questions we can go ahead and look at those, and if I don't get your question, I will follow up with you after the presentation.

Couple of questions there on the session and whether or not it was recorded. Yes, this is being recorded, so we will share that recording with you. It will be available for On-Demand by the end of the day today probably, maybe tomorrow. If you want a copy of the PDF files here, go ahead and shoot me a chat message as well so that you can request that, and I'll get that out to you as well.

Do we offer a security search check service? Yes, we do that is our security scan. You can run that against your system, high level look at the security configurations on your system, give you some ideas on places to start. We can walk through that with you and explain any of the findings from that security scan. Let me know if you would like to do that. You can request them on our website, as well.

Somebody else is asking me about viruses on the IFS and if I've ever actually seen one. I know it’s a little crazy, but there have been quite a few instances of people with their IFS and having infected files out there. One of the biggest infections I have personally seen was due to exactly the configurations I just talked about and having them set wrong.

We had a company with an *ALLOBJ user with a map drive to the root directory, and this particular gentleman actually opened an email on Friday afternoon with ransomware in it, and that ransomware started kicking off on his PC and started following all of the network directories that he had. One of those, of course, included the root directory on their IFS, and this gentleman left on that Friday afternoon for the weekend, and the ransomware had the entire weekend to run. And by the time they discovered it on Sunday, they had half a million files encrypted in their IFS. It actually brought their system completely down. It encrypted their Webster directories, everything in the Webster directories, their web server was down, their TCP/ IP configuration files were encrypted as well, so they couldn't get on to the system from anywhere but the console. So, they thankfully had a good back up of their IFS and were able to restore the files, it took them about a month to completely recover from it. But as you can imagine, extremely painful. And they didn't pay a ransom. Another company I worked with that actually did have to pay a ransom because they didn't have good back up. So, it is absolutely possible for it to happen, it has happened. So, I hope that you take that seriously, especially if you're using a mapped drive and allowing those users, that's really where your weakest area is with those mapped drives.

Question about being able to monitor IFS usage prior to restricting the authority? Actually yes, with the Powertech Network Security, you can actually just start auditing the activity, so you can actually see what directory users are accessing and what they're doing to those directories. So, you could certainly watch that, audit it for a while, see what is being done. You'll also see if it's any system processes that are using the IFS, as well. You'll see all of that activity, so you can easily work backwards from the activity that's happening, identify it, set rules up that say “Yes, this is appropriate” and then lock everything else down.

Of course, if you were to be in that audit mode and monitoring that, then absolutely lock that down immediately without waiting to see if something bad happens. If you see users in there that shouldn't be, feel free to make sure you restrict it.

A lot of people are asking for a copy the presentation. I will certainly make sure I get that out to everybody. I really appreciate you spending the time with me today, hopefully you got some good information out of it.

I'll be following up with everybody who shot me a message and make sure that you get the information that you requested.

I hope you all have a wonderful day. Please be sure to join us in our next session is on June 6, to discuss event auditing, and while the title of this slide does show that it's the final episode, we actually switched things up a little bit, and it will be the third in our series of six Getting Started IBM i Security studies.

Thank you all for coming, you have a wonderful day, hope to see you again soon!