Security Alert! Prevent FTP and ODBC Data Breaches on IBM i

Hello everyone, welcome to our discussion today about preventing data breaches on IBM i through channels such as FTP and ODBC. My name is Robin Tatam. I am the Director of Security Technologies here at Fortra, and as always, it's my pleasure to be able to present to you today. If you don't know me, my background is IBM i. I've been on the platform for many years now, and I work as one of the subject matter experts for COMMON. I'm also an IBM champion, and my responsibilities at Fortra include publishing the State of IBM i Security Study and speaking to our customers around the challenges and work and remediation for security on the IBM i platform.

It’s important to note that the key reason IBM i has a vulnerability potential around interfaces such as FTP and ODBC and other systems don't is because we have an integrated database. When you buy IBM i as an operating system, you get that DB2 database built right in, so you already own it. And that's a great thing, but we have to also understand that the security challenge that comes with that is that the integrated database means that if I provide you with a user ID and a password to the system, you automatically get access to the database, as well. That's not true elsewhere. If you're on HP or Oracle or Microsoft, you typically need separate access to the different databases, so that's why this particular problem is pretty unique to our platform.

As I mentioned, one of my responsibilities at Fortra, each year is to publish the State of IBM i Security Study, and this is a labor of love that I have been doing now for about 10 years, and it gives really unique insight into what people are doing and not doing with regards to security on the IBM i platform.

And for 2019, several of the takeaways include the fact that we have an excessive number of profiles that are carrying what we referred to as root privileges.

Now, in IBM i terms that is the All Object Special Authority that can be granted to a user profile and typically we want to maintain this at an absolute minimum level. So, to say that there is an average of 168 of these profile attributes on each system, certainly does indicate that we have a lot of profiles that have access not only to the database but every object on the system. For those users that don't have all-object, then public and private authorities become relevant. One of the things that we study in the guide is the fact that most libraries on an IBM i system are not set to the ideal setting of *EXCLUDE. In fact, less than 10% fall into that category. The other 90 or so percent are open to anybody simply because that user has valid credentials to the machine.

IBM i tends to run multiple applications, so the fact that I'm connecting to the server doesn't necessarily clarify which application I'm there to use. So when we leave this public permission setting as open, it means that even though I'm there for application A, I may well be able to see and even change the data associated with application B. Part of the problem stems back to the history of the platform, and as much as I encourage people to refer to the boxes of power system server and the operating system is IBM i to ensure that we're talking to our management teams about how up-to-date this technology is, I have to acknowledge that many of the applications we're using pre-date the IBM i server, meaning that they were written on the AS/400 or the i-Series, and they've been migrated through the ages.

The benefit of these types of applications is that it masked some of the complexity around IBM i Security. All we had to do was put a menu in front of the user, limit them to certain options from that menu, and then we were able to corral their functionality.

We could also handle this, to a certain extent, through application security, meaning that I can get into my ERP application as an example, but what I do within that application is managed by the application itself. There's no actual object-level security, there's no restrictions potentially to the database itself, it's all handled through application code.

The challenge is that with the advent of TCP services on the platform, interfaces like FTP and ODBC amongst others, we are allowing or enabling the user to connect directly to the server in many instances to the database itself, without actually then passing or channeling the user through that application menu, or the application itself for that matter. This, therefore, renders that application layer and menu layer; I'm not going to say worthless but certainly with limited benefit in this day and age.

Now, when we pull up tools like Microsoft Excel, we find that the connection to the IBM i database is actually fairly intuitive. This is an older version of Excel that made it really easy. We simply took the option to transfer data from i-series, we could transfer data to i-series as well, and within a few clicks, we were able to access data that perhaps is in a format that we would not anticipate the user to be using. Meaning that perhaps my user is a green screen user exclusively, and all of a sudden, this data is now in a spreadsheet or a Word document, and they're able to export it to a thumb drive or send it to an external account fire email. Tools like Excel and others also potentially allow users to not only pull database information, but return it back to the server and unfortunately, this type of data transfer is typically not logged by the server. Despite the fact that we have pretty comprehensive database and system monitoring, the act of transferring data from one location to another is not really something that is given a lot of visibility into the log. And if you are controlled by regulation, and an auditor gets wind to the fact that somebody can download data from the server without generating any type of audit trail, then of course but not surprisingly, they're going take issue with that.

FTP is another example of a tool that is easily accessed. Windows has FTP built right into it. We simply bring up a DOS prompt, and we can run FTP directives. It's very quick, it's very effective, but unfortunately it carries with it a high risk of not only data corruption, but data theft, as well.

In the example here, we've taken an old Word document and uploaded it to a production library over the customer master file.

FTP doesn't stop us and say, "Are you really sure you want to put a word document over the top of there?”. Instead, what it does is a binary transfer and, in this case, it's going to simply overlay, completely corrupting the customer master file as it goes. What we see is that the IBM i database has really two primary issues associated with it. Number one, users typically have a lot of access to the application data arguably, excessive access to the data. And, the operating system ships with a number of powerful TCP services that tend to be activated by default.

It's not just about database access. We also have the potential of users who wish to run commands. Many of us are familiar with the limit capabilities attribute on a user’s profile, which indicates a couple of things to the administrator. Number one is whether the user can access certain options on IBM menus. It also controls whether we can run commands on the system.

I think you're probably familiar, there is on a green screen menu, a command line the long line at the bottom of the screen. The visibility of that is really not something that a user can control, programmers can on program defined menus, but the system menus, just simply have that line. So, this is not a visibility control, but instead it’s actually an attribute that indicates which of the commands on the system, of which there's about 2,000 of them nowadays, can be issued on that command line.

Now, the limit capabilities attribute is very beneficial in telling the system that this particular user should or should not be able to run the vast majority of commands. However, even if you've implemented that control, we have to understand that some of the TCP interfaces don't necessarily respect that setting. You're still potentially able to run commands through alternate interfaces even if a user is limited in their capabilities. We also have to acknowledge that there's going to be certain kinds of uses that do require legitimate access to the command line. In this case, it may be a programmer, a system admin that really can manage and program on the system without that capability. If you do indeed have this type of user, and let's face it, most of us do, then we want to ensure that we have auditing correctly configured for those privileged accounts, and that we include the *CMD directive that logs all of the command line directives that the user issues. The bottom line in this risk equation is that when we have users and open services running on the system, we have a high risk of data corruption or data loss. Fortunately, when IBM added in the TCP functionality that opened arguably Pandoras box to the database, they also gave us a supplementary security level attribute. Now, we refer to this typically as an exit point; it's really just a hook into the system that allows invocation of a user-defined program. There's nothing security-oriented specifically about it, it's more of an application development function than anything else, but what it allows us to do is deploy an exit program that can oversee these types of PC network connections in and out of the system.

The actual exit program is what does the work, and that's registered to the exit point. And this exit program can do anything that the programmer programs it to do, but there's really two main functions that I as a security officer would like to see that perform. One, is that I need it create a trail of the transaction, meaning that this is going to be responsible for logging an audit trail of the request made by the user. We also are going to want that exit program to do some access control. It's going to determine whether the user and their request is reasonable based on the type of responsibility the user has within the organization.

One of the responsibilities of the exit program is to pass back to the exit point a pass-fail indicator, so this is a very powerful capability that allows the exit program to indicate to the server that the users request should not be honored.

Even if I am a privileged account, that means that I can reject a user from being able to transfer data or to be able to run SQL statements from a PC. Very, very powerful, almost like a transactional fire wall.

When we look in the State of IBM i Security to see how many people have deployed these types of exit programs, unfortunately we have a little work to do. Now, the rudimentary exit program coverage speaks to the idea that out of the almost or approximately 30 different exit points in the operating system for this function, at least one has an exit program associated with it. And still even with the bar set as low as that, we have 29% of shops that are doing so but a whopping 71% that are not. If we bring the bar up to full exit point coverage, then we see that only 8% of servers are currently performing that task, and this is usually indicative of somebody utilizing a commercial exit program solution. Because when people write their own programs, they don't tend to do all 30 of them, they just do one or two.

Now, the encouragement that we have to take from this is that people are starting to recognize that inbound outbound traffic flows are probably their primary attack vector and something that they need to address as a risk control.

One of the big benefits of exit programs is it allows us to compensate for the lack of or poorly configured object-level security, and this is something that we see often simply because many organizations remain in the mindset that the menus and those command line restrictions are going to correctly control the user function. But with exit programs, we’re able to block unwanted access even if the user has object privileges. It's going to allow us to approve the access and importantly, log all of the access attempts, whether they were successful or not. If you're thinking to yourself, “Well, I'm one of the few that does have good and comprehensive object-level security. Do I really need exit programs?” In my opinion the answer is yes. Often times we find that that data isn't quite as secure the owner thinks.

Sure, we may have public set to exclude on our application library, but then we discovered that the user belongs to say a group profile that owns the library, and, therefore, the user gains access through the inheritance of that group's permissions. We also have to recognize that the authority to those application objects is going to carry through to all interfaces. Meaning that if I open the door through the green screen for the user to access the database, I've also opened up the door through FTP and ODBC. In other words, the operating system is unable to differentiate between those different interfaces. It's all or nothing.

We also recognize that even with excellent object-level security configuration, there is insufficient auditing of those requests, and so the exit program can facilitate logging those requests into the IBM security audit journal.

And of course, as I mentioned earlier, it's not just about database access. The idea that a user potentially can run commands through a PC interface without having the limit capabilities options set to “no” is of great concern, and so even if we're not using an exit program for database control, we certainly want to use it for the limitation of users executing commands without expectation. Within an IBM i environment, we tend to discuss this perfect storm of vulnerability, meaning that security awareness amongst IBM i professionals in general, tends to be low.

We're very skilled at managing the system, doing role-swaps, saving and restoring data, but when it comes to understanding exactly how authorization lists work, and public and private permissions, we tend to see that people are not as focused and as trained in those area. Unfortunately, where the audit community would tend to catch that and hold our feet to the fire, we also have discovered that IBM i awareness amongst these professionals tends to be arguably even lower, so nobody is really checking up on us. We've been able to get away with corner cutting and ignoring the problem for many years.

I'm sure you will agree that a lot of valuable data tends to be stored on these types of servers. They are phenomenal at storing large amounts of data, serving up enterprise-level applications, and so we have to ensure that that database is protected. Unfortunately, we know from the State of Security that much of it is not secured, and we definitely have seen already, that the users have far too many privileges to that database.

So, what I'd like to do is talk to you just a little bit about an exit program solution within our portfolio. We're going to show you some data access, we're going to track some user activities, show some dashboarding, and explain that we have a choice of interfaces with this particular application.

So, first of all, what I'd like to show you is a profile on my system of a user that I have by the name of Paul C. You'll see about half way down that this user has a class of *SECOFR and in my sessions at various locations I try to preach to people that user class is not necessarily indicative of the privileges of the user, but it's certainly our first line item to check on. More importantly, what we're interested in is Paul C’s special authorities, and in this case Paul C is indeed a security officer, he's carrying all eight of the administrative privileges. And the reason I'm picking on Paul here is that I want to show you some of what we're able to do, even though the user has a traditionally unstoppable database privilege in the all-object special authority (*ALLOBJ). So, the first thing I'm going to have Paul do here is update a file on the system, not very cryptically named here, which contains payroll information. It's in a library called payroll, and the master file itself is also called payroll.

Here we see an employee Carrie Okie who has a salary of a little shy of 74,000 per year, and it becomes a very easy task to perhaps give Carrie a nice healthy pay-raise, and of course this will be logged, if you're familiar with DFU, you'll know that it does create a spool file indicating that this record was changed, but let's face it, all it requires is somebody to delete that spool file and any log of that traditionally is probably going to be lost.

So, as a user, we have the ability to directly influence data, but within the emulator we also have some functionality here that allows us to transfer data off of the server to some other type of application.

So, here's a data transfer window, we're going to zero in on a system by the name of Earl that is named after Powertech founder John Earl and a great guy. Unfortunately, we lost him a few years ago to brain cancer, but out of respect for him, we have a system by that name and in that system, we have a library named payroll and a file named payroll, as we just saw. We take an option of selecting the display, but when we try to transfer that data, what we end up with is an error message indicating that the SQL request that the data transfer issued was actually rejected, despite the fact that Paul C is running with all-object special authority. This is an example of the exit program setting that return code to a “fail”, telling the service that this is not a responsibility that Paul has and to deny that request.

Now, if we change the file perhaps, to a different file, let's look at “pay new” here, which is perhaps an extract of the payroll master file, and we take the option to start that transfer. What we end up with is visibility to the data, so the benefit here is we're not simply blocking Paul from all database access, what we're doing is being more selective about what we allow him to access and what we reject.

I mentioned FTP earlier as well, why don't we take a look here. Making the FTP connection into Earl is very straightforward. We simply have to specify the instruction of FTP space Earl, and we get a connection to the database. Or excuse me to, the server itself.

Now, this assumes that the FTP server is listening, but I will tell you the vast majority of servers do have this up and running.

Of course, IBM i is going to ask for connection information, so we specify Paul's credentials.

Let's assume that Paul is not overly familiar with FTP. Which is an excuse that I hear quite often that, “Well, my users wouldn't know how to do that.”

All Paul had to do was type “help”, and he gets a list of directives that are available to him as a user in FTP. One of those directives is remote help, which is a little bit more server-centric, and if we run remote help, what we get is a whole slew of information that talks about how data should be or how the command should be delimited and the types of directives that can be issued based on the different file systems that exist under IBM i. So, there's a lot of information here based on different name formats that can be given for the Integrated File System (IFS) or the native database. So, if you think your users can't stumble upon this, you might want to reconsider. Also, because these tend to be the primary attack vectors from outside attacks, we have to also acknowledge that users who make their way into the perimeter network, and it does happen in virtually every breach that we read about, that once they get to this system, it's not as cryptic as many people like to think it is. Now, in this case, we've got a couple of requests, we grabbed the pay new file, and you’ll see that the member was retrieved, and 535 bytes were received in less than a second, so that file was downloaded extremely quickly, but when Paul tried to grab the original payroll master file, what we now see is, despite his all-object special authority (*ALLOBJ), that request was also rejected. So, we have the ability to be flexible here.

One more interface that I want to touch on is Navigator. A popular tool for many administrators, but it also tends to be installed on an end user desktops. It's buried there in the program group. We don't necessarily direct the user to it, but it's sitting there. Now, when we make a connection to the server we're again asked for user credentials, but when we drill down using those credentials, we're going to see a subset of the tree infrastructure for the database, and then within that we have what's called a schema, which is in essence the equivalent of just a library on the system and here we've drilled into the payroll library. And at the payroll, we have an option for the tables, which equates simply to the term of database file. When we click on that, and we pull up the list of files inside the library, you'll see that there are in fact three files here. One is the payroll master file that we've been using, and the other one is the extract file that I created called PAYNEW. When I attempt to open the file again, I have been given an indication that this function is rejected by the exit program.

The exit programs made a determination based on information that's been given about the user and what they're asking to do, and it is indicated that this is not associated with their responsibilities and, therefore, it should be denied.

I mentioned access already. Here's a newer version of access, where the connection is buried just a little bit further than it used to be, but, of course, grabbing data from alternate data sources is a common act.

When we go under the Microsoft Query tab, we do get an option of different databases, one of which is the system of Earl.

Now, by setting up that system ahead of time, it makes it very easy for users to access data, which can be a good thing, but it's also a consideration, if the user doesn't really have this as an ongoing requirement.

If we make a connection to Earl, we are going to be requested for user credential information. So, we're not bypassing security on the box, but, when we drill into the different application files, we are again accessing through an Excel spreadsheet, where the user may not actually have a requirement for them to be able to do that as part of their job function.

When we click on the pay new file, which we have the ability to access, we do see the columns or the fields in the file that we have access to. However, if we click the payroll file, we're not seeing any columns there, despite the fact that it would actually have basically the same columns as the other file. In essence, what's happening here is that any request to determine the field structure within that file, or the actual download of the file itself, if we don't drill by column, we're going to again be rejected by the exit program. So, I think here, you're getting the sense that the exit program is acting kind of like the traffic cop.

It's determining based on rules that it's been given, whether this user is within their rights to be downloading data and by within their rights, I don't necessarily mean their object level permissions. What I mean is that the business logic says this user is in a position of responsibility that allows them to download or upload data.

So, the big question is the exit programs and how did we accomplish that decision-making process? Now, within our entire IBM i Security portfolio, we have many modules, and they fall within these different categories, but the intrusion prevention and detection section is really where we're going to focus our attention today because what we're trying to do is ensure that any connections to the system are legitimate, and that we're monitoring and controlling the use of these interfaces. When we look at the tools behind the scenes of all of those segments, we see that there is a specific tool that we want to talk about that is designed to really well handle the perimeter access control requirements that most regulations and all best practices state we should have. And this is a tool we call Exit Point Manager for IBM i. Now if you're familiar with the name Network Security as a product, this is in essence the same thing. We did go through a rebranding in 2018 to make the tool more intuitive from a naming perspective, so we changed some of the product names, but in essence, it is Network Security that we're talking about here. And this is a rules-based exit program engine, meaning that we can define soft rules within the environment that decipher whether that user should be able to perform requested tasks or not. We also have audit capabilities here, so independently of whether you allow the user to perform the task or not, we're able to log that record of request and build that breadcrumb trail of what the user is doing to the system.

And if you're in an organization that has multiple partitions or maybe multiple physical servers, we can also handle the deployment of these rules from a central partition, pushing them out to all of the end points.

Now, FTP and ODBC is kind of what I'm focusing on here because they're arguably two of the most visible interfaces into the system, but there are many more ODBC, JDBC, remote command, DDM REXEC, network spool print, all of these interfaces are part of the IBM i operating system and carry with them IBM supplied exit points. It's just the matter of applying the exit program to them.

Now, let's take a look at one of the interfaces we have available to you through Exit Point Manager, again when you see Network Security, it's just a re-branding of the product. Here when we take option 80, we see that we have access to a reports menu because what I'm going to do first of all is just run a report over some of the actions that we've already been performing against the system. We've got a number of ways to run reports, as well as to print off the rules that are configured, so that we can document those in a run book or for auditor review. In our case, we're going to take a user report because I want to zero in on our old friend, Paul here. We're going to provide some filtering information we’re going to zero in on Paul's activity, we're going to look at a certain date and time, and we're going to tell the system that we want to generate a spool file on the system. Now, we can also go out to a comma separate file in the Integrated File System, which makes it very easy to slice and dice that data in a tool like Excel. We can also dump to a DB2 database file, so that you can run query or write a high-level language program over it, but we're going to keep things simple and just generate a spool file.

What we see in that spool file is the indicator that we are looking at filtered information in this case, just Paul's data. Down towards the bottom we do see information about the activities that Paul is presenting to us.

In this case, we're seeing a remote command. It's coming through the central server, and in this case on the far left, we can see that the action taken was to permit that request.

Now, it's important to understand that if the exit program does indeed allow the request, the operating system will then continue to attempt to process it. It doesn't guarantee that the operating system itself will allow it, so if you do indeed have restrictions or object-level security in place, we are simply preempting that, we're not overriding it. Now, we do have some functionality that allows us to alter the identity of the user who the request is coming from. So, for example, maybe I have an all-object profile like Paul C that I want to be able to allow to read data from the system, but not upload it back. In which case what I can do is change Paul C’s identity to that request to perhaps one of a profile called read-only, that only has *USE permission to the database. Then if Paul were to try to send data back up to the server, it would be sent to the database as if user read-only had sent it, and because that user only has use permission, the update request would fail. The Exit Point Manager permission would be to okay it, the operating system ultimately would say that is a denied opportunity.

We also ran some SQL requests through that Excel connection. You'll see two of them here, one is allowed, and the first one is rejected. The request to download data from the payroll master file was denied, but we're showing here that it was a SQL server request, it was a prepare and describe based function, there is a time stamp, and there is job information. So, we have what we need in order to now know exactly who Paul is and what type of connection he's making.

Alright, now there's other information and other points here that would indicate Paul's IP address and other types of useful data. The second request was permitted, and that was Paul now accessing the extract file pay new.

Now, if like me, you are a fan of the green screen, then perhaps that's as far as you go. But, our recommendation is that you take a closer look at something we lovingly call Insite. Insite is a user experience that we have designed here at Fortra to provide a browser-based mobile friendly user interface. This is not limited just to an individual product. In fact, the initiative goes across the entire Fortra product portfolio. Powertech, Robot have tools that are embedded within Insite. It's not just about replacing the user interface, however, Insite also contains central deployment capabilities, as well as license key management tools. This means that your entire Fortra family of products can now be administered, installed, and upgraded through a single interface.

The best part from your perspective is this is part of the Fortra product family. So, without any additional cost, you can choose to use the Insite interface, and if you have Fortra products already and you've not seen any visibility to Insite, this is something that I would recommend that we spend a little time and show you because I think you will find it’s a highly effective way of administering your system and Fortra tools. We are going to zero in today on the Exit Point Manager interface within Insite.

When we go to the Home instruction, here what we're going to get is a nice dashboard that gives us some volume counts with regards to the transactions that are flowing into the system named Earl. What we see in green are the transaction counts of those transactions that were permitted, and if we see anything in red, then we have some transactions that were rejected.

Now in a normal day-to-day environment, we probably would question the permitted transactions, unless we simply want to know if there's an unusual volume of activity. For me, what I tend to focus my attention on are the rejected transactions. So here, we can see that the DDM server has two that were allowed, and the SQL Server transaction count shows that there were 10 transactions within this window of time that were rejected. Up in the top right, you'll see that we're actually looking at transactions over the window of today. There are other times that we can specify there of course, you've got flexibility in either a custom range, today, yesterday, last week, last month, etc. We also have access to the report information as well, so regardless of whether I run the report through the green screen or directly through the interface here, we're able to generate the same type of data. It's giving us information about the action that was taken, the user that performed it, the server that was processing the request, along with some time stamp information. On the far-right column, you'll see the actual data, whether it's the SQL statement, the file that was accessed or the directory that was changed. You'll also see any commands that were issued as part of the command functionality in these servers. When transactions come through Exit Point Manager, we have the option of capturing them to use them as a template for future transactions. What I mean by that is if a user is going to run a recurring SQL statement, we have the ability to turn on this capture function, have the user run their request and indicate to the server how to respond if they see that request again in the future. It makes deployment of these rules very quick and effective.

The power of Exit Point Manager though, comes in its rules engine. And so, when we click on the rules section, what we get is indicators of how we want to behave when a user makes a request of the server. Here, we filtered it down to a particular profile with the typer head of PTNS Demo, so you'll see four rules that are typed up here that pertain to this particular user. And by specifying these rules, we're telling the server that if we see a transaction that matches the rule criteria, this is what we want to have happen. And on the right hand side of this panel here, you'll see indicators of whether the transaction should be recorded, or audited, whether a message should be sent to a message cue, and whether we want to capture it for setting up a new transaction rule in the future. That capture transaction that I mentioned on the prior screen. We can set rules inside Exit Point Manager pertaining to a particular user, to a group that they belong to, whether it be an IBM i based group profile or an Exit Point Manger defined group. We also have the ability to set rules based on an IP address, so we can set rules specific to a different server or a user that is connecting through perhaps a proxy. We can combine those things, so that we can act differently when a user is connected to a VPN versus when they're connected directly.

In this case, we have a panel that talks about object rules, so we can go from being pretty generic giving general rules that says Paul can't use FTP at all, all the way down to he can use upload but not download, or he can do a download of an individual file or object but not others. So, these rules can be as generic or as granular as you want, the flexibility allows you to decide individually whether your rules are going to be complex or simple.

There's benefit there in that by keeping things simple, of course, there is less administrative overhead for the security officer, but when we need to, we can get extremely granular and control exactly what that user is doing.

Alright, so that is Insite and its integration with Exit Point Manager, and what I'd like to do now is just give you a very simple call to action pertaining to PC type connections. And that call to action is to run a security scan that will give you insight into the configuration of your IBM i partitions.

This is a free tool that you're able to use. It entails about 60 seconds of time to scan the configuration across seven different categories, and we will also give to you the time of a security expert who will go through these findings with you and explain exactly what they mean and answer any questions that you may have.

Now, this is always a recommendation for people whether they have done security work on their server or not because it allows us to confirm the correct deployment or give us a foundation of where you're starting out from. But one of the aspects of that review is network access, so if you are not sure, for example, whether you have exit programs deployed to your system, this is arguably the easiest way to find out. This section here will identify all of the different exit points that support the exit program concept and determine whether an exit program is currently registered.

Unfortunately, in my sample system here we have a high-risk item because none of the services are currently monitored or controlled by this powerful exit program concept.

If you're not familiar with Fortra, and the focus we have on the power system security side of our business, I'd like you just simply to take away that we do have a significant number of security products. The brand that we use for this is the Powertech brand, which you may have heard of, but it is a Fortra brand. We also have a complementary suite of services, so it's not just about buying a tool, pretending that the world is rosy. When we all know that things aren't quite that simple. What we try to extend is the idea that the operating system does have functionality in it that should be configured correctly in order to build a solid foundation on which to build everything else.

I'm not saying tools like Exit Point Manager aren't often used as a compensating control because they do a fantastic job in that regard, but always as a security professional I always recommend that the correct configuration be deployed at the server level as well, and we can help in that regard.

We're also a member of the PCI Security Standards Council, so we're engaged with them to understand what type of regulations are going to require oversight of connections to IBM i. We're also authorized to issue continuing education credits for security education on the i-platform, meaning that we are the ones often who are training auditors about auditing i.  And as I've mentioned, one of my responsibilities here that I'm very proud of and enjoy every spring is the publication of the State of IBM i Security Study, so if that's not something you've accessed before head out to our website you can go into the Resources tab, and find that document. It is a free download, and it is available any time you would like to access it.

Alright, so I've got time here just for a couple of questions. I know there were a whole slew of them that came in as I was going through, and what I'm going to do is I'm just going to cherry pick a couple of them here, and then we'll make sure that we get back to anybody who asks a question that I'm not able to answer.

First one here, Dave, you're asking, how many different exit points are there on the system? I want to say there is about 30 approximately. IBM added three around the 7.1 time frame to handle socket connections, and that's something that we have in Exit Point Manager, so that may have tipped the scale over the 30 mark. But yeah, it's right around there.

A couple of you have asked about the security scan function, so let me just kind of give you a rundown of how that works. It's actually a Windows based tool. It's downloaded from our website, you fire it up and give it some information about the server that you wish to scan. Now, this is not a port scan. It is actually connecting to the server, and it's pulling configuration information back to the PC to give you insight into those configurations and also then to evaluate whether that item is correctly configured. So, things like the Q security system value, and the maximum sign on attempts, the password policy, the presence or lack thereof exit programs. That's a relevant piece for this discussion, of course. We're going to look and see how many privileged accounts, how many of them have command line permission, whether there is an antivirus engine actively running in IBM i, so lots of different areas of valuable information.

There's no access that is necessary outside of your network, so this is all self-contained. Although there is an ability to share the data with us in an anonymous and scrubbed form that we then use to publish the State of IBM i Security Study. So, we always appreciate when people are willing to share that data, but I can assure you there's no application data ever accessed, and that information comes in encrypted and anonymously. Our intent is to make you more secure, not to open you up to additional vulnerabilities.

Okay, and then a third question, I'll just take this as my last one. Somebody's writing network security, which like I said is now called Exit Point Manager, but the same concept, how is that going to block traffic?

Alright, so out of the box when you install Exit Point Manager, it takes a default configuration of audit only. Meaning that because we're sitting in front of the operating system and intercepting these requests, we don't want to be presumptuous and start blocking traffic right out of the gate. Reality is you're not going to know the types of legitimate transactions that are happening on your system because in your defense there's no way to report on it. That's part of the issue in the first place. By employing Exit Point Manger, what we're able to do is start recording the inbound outbound traffic flow, and from that intelligence, we're able to then make determinations as to what is legitimate traffic and perhaps what is not.

If you have a third-party ERP program for example, that runs directly over an ODBC or JDBC connection, you're going to see that type of traffic. If you use high availability, there's a good chance, you're going see some of that traffic as well, and we of course don't want to restrict any of that. We don't want to break any legitimate applications, so it's important to do that initial analysis and the reporting and messaging function makes that very easy to do. Once you've done this analysis, what we're able to do then is start gently locking things down, but that's down the road. It's usually a process that we explain how to do without breaking things, and there are some tricks and techniques that we use in order to minimize the risk of any business interruption. So pretty streamlined process, but the default configuration is simply to start building that insight without turning anything off, without breaking or changing any application, so very streamlined.

Alright, well, we're going stop there. I appreciate the questions that have come in and like I said if we did not answer your question, we will reach out to you after the event and answer that for you. If you are interested in looking closer at Exit Point Manager or any of our tools for that matter, please head out to Fortra.com.

Or give us a call and we would be happy to walk you through a demo or set you up with a proof of concept. No charge for that. And we're always here to help. If you have any security questions pertaining to IBM i, I always love getting those so feel free to email me, hit me up on Twitter or LinkedIn. I'm always happy to help. That's my job here at Fortra, and I take great pride in sharing as much information as I can.

I thank you for your attendance today, and I look forward to seeing you again on an upcoming webinar, but