What’s New in IBM i Security in V7R4 (and Other Great Things)

Okay, so the first one is a system value that has been around forever, but it was enhanced in V6R1. Yes, back in V6R, so this is the system value that allows you to say how many times a user can sign on.

So, the original intent was to prevent users from sharing profiles and passwords. The original setting for this was zero, which was unlimited or one device.

So back in 6.1, they enhanced it to allow you to specify that users can sign on to two devices up to 9 devices. You can also specify this in the user profile. This enhancement has made this system value much more usable. One was the setting of one where users could only sign on to one session at a time was usually too restrictive for people, but unlimited was also not acceptable. So, now you can say end users get two sessions, you can also always override that in the user profile to allow, say, programmers to have four sessions or whatever.

So, I like to tell people about that.

The other one also came into V6R1 is the ability to save private authorities with an individual object. So, sometimes that's helpful if you are taking a database file from production and restoring it on to test. Now, I know auditors do not like production data to be available to developers, but in practice, I know it happens.

And the problem is when you take that database file from production, and you're just saving that one file, the private authority is the way that you have it secured on production doesn't necessarily come with the file if you have used private authorities.

So now when you do a save object (SAVOBJ), you can take an option to save the private authorities with that particular option. So, you could say save private authorities, yes. And then when you go to restore it, you can also specify to restore the private authorities. Now, this is kind of a duh moment, but you have to have saved the private authorities before you can restore them. So just that note. Another thing that came in in V6R1 is a new parameter or a new option on copy to stream file and copy to import file.

So, when people are dealing with the IFS, one of the biggest concerns that they have or frustrations I guess is a better word, is how stream files end up being secured and owned when you're copying them into the IFS or creating them into the IFS. So, in V6R1, there were parameters added to the authority setting that allow you to say that the authorities should come from the directory that the file is being created into. It can also come from the database file that you're copying from.

So, these extra options have given people a lot more flexibility when dealing with stream files.

The unfortunate thing is that IBM does a very good job of not breaking things or not changing things release to release. And as a result, they didn't change the default behavior, which is a bit unfortunate in this case because most people expect those stream files to inherit the authorities from the director it's going into. So, you have to know to change this command. I just wanted to let you know that that option is available. Then the other hint is the ability to use the Change Object Owner command to change the owner of all the objects in a particular library.

So if you look at the Change Object Owner command, *ALL is not an option. In other words, there is no ability in the Change Object Owner command to change all of the objects in a particular library, but you can do that with CHGOWN. CHGOWN takes a path name. So you simply have to say what the file name is that your file system is that you're working with. In this case, we're working with QSYS.LIB. Then you have to name the library that you want to work with, so in this case, it's Application Lib (APPLIB.LIB). Then you always have to say with the object types, so it’s .LIB. And then in this case it will change all of the files in this particular library. If you left the *.FILE off and just ended with the library, you could take the option to say directory subtree and say “ALL” and then it would change all of the objects in that particular library. So just a handy way to change the owner of multiple objects in a particular library.

Okay, so that's kind of a catch up from previous releases of things I hear questions on that you might not be aware of that the function was already there.

Okay, so let's start with the V7R1 and come forward.

 Application administration, so there are ways that you can allow people to do particular functions and prevent people from doing particular functions. One of those features is through Application administration. If you want green screen, it's Work With Function Usage (WRKFCNUSG).

So, what was added in V7R1 was the ability to control ODBC and JDBC access. Now, this is an on-off switch. The other thing that they added was the ability to control DDM and DRDA access. FTP has been in this particular facility for quite some time.

So again, this is an on-off switch by user or by group or by default. Now this is not at all granular nor is there robust logging, so if you need granularity or situational control, this is not for you. What I actually use this for most often is to prove that people are doing an FTP or people are using ODBC. Because in the audit journal, there is an audit journal entry for those.

It is a G-R-audit journal entry, and it shows that the user is using ODBC. Problem is that’s where it stops. So if you want to know what was downloaded or what was uploaded, that's not going to work. So again, a lot of people have to convince their bosses that activity is occurring. So, this is a way to prove to your bosses that the activity is actually occurring and will help justify that purchase of the Powertech Exit Point Manager software, used to be Powertech Network Security, but now it's called Exit Point Manager. So again, some people it's sufficient to just shut off the access. A lot of people have situational control, like they want to have a service account be able to do FTP but not do certain things with ODBC.

When you have situational control, this is not going to work, that or if you want to review the activity of what they're doing, that's not going to work either. You need the more robust exit points, but this will get you visibility into the actual activity. The other thing that has become quite popular and quite honestly, we're seeing quite the uptick in this is something called Field Procedures or FIELDPROC. So, this came in V7R1, but it has really only started to catch momentum in the last two years, but really within the last year. So, this is a facility that IBM has put at the field level of a database file that allows you to, I'll call it “snap in” an encryption algorithm and encrypt the contents of a column in a database file. So, why is this catching on? I think it's catching on because of all of the laws and regulations, as well as all of the fines that people are getting for loss and stolen data, especially anybody that's dealing with GDPR. I think also people are tired of getting their data lost when they have been breached. So, if it is encrypted, assuming the key isn't stored with that database file, whoever is reading this can't read that data.

What it is, is basically a re-architecture of a database file and when a field procedure is defined for a particular field in a database file, IBM does some magic under the covers and allows that field to be encrypted. Now, why is it so important? This is so important, because prior to V7R1, to encrypt a field basically meant that you were going to have to re-write your application. When you encrypt a field, it is almost always longer than the original field size.

So, say you had a social security number that is nine characters long. When you encrypted it, it was always going to be longer than nine characters.

Well, when you change the size of a field, what does that mean?

Any program that touches it has to be re-compiled. For some people that meant re-compiling hundreds of programs, and it was just prohibitive. That or you had to create another structure, and point to a file that had the encrypted value, there was a lot of programming that went around the actual encryption of it and decryption of it. That is all out the window with field procedure. So basically, the file field stays the same size and the same type. So, no programming is required. What you do have to do however is encrypt it. IBM has not provided the encryption.

So I do not recommend that you try the encryption yourself.

Yes, there are APIs that can be done. The problem is not the encryption itself, the problem is the key manager. That's the encryption keys that actually dictate the strength of the encryption algorithm, and those must be protected, and they must be fed into the algorithm correctly. I do not recommend that you write your own. That's an option, but the better thing is to purchase a solution, and we have a solution for that, it's called Encryption for IBM i. We have installed this and implemented this, again, literally around the world, and we are seeing a great, great interest in this product.

So, if you are in the position of needing to encrypt data, this is for you. And I have spent so much time on this just because we are getting a lot of questions on this product and on field procedures.

Another thing that started to come in V7R1 are SQL views and this library called QSYS2. So QSYS2 is not operating system code, it is where all of these views are contained.

So if you're not familiar with them, I've put the link here to get more information but there are a lot of ways that you can see data that you would normally have done like a display to an out-file, that are now just simply in SQL views. One of those, and the easiest way to get to those views is through Access Client Solutions (ACS) and the Run SQL scripts feature. When you run or open up ACS, Access Client Solutions you specify the run SQL scripts feature, and then when you open up SQL scripts what you want to do is go to edit and then drop that down and then you can say, "Insert from examples”. With every new version of ACS, they are giving us new examples. So I like to do this, especially when I am using something that I haven't used before, a view that I haven't used before. You come in and say, "Insert from example”, and the SQL is going to be inserted into your run SQL script window. I don't usually use it as is, but at least it gives me a place to start. I prefer to edit not create, so IBM has helped us, and again that started in V7R1, but they are improving that and giving us more examples with each new version of Access Client Solutions.

This is one of my favorite views that they have or services that they have provided in SYSTOOLS. This one is group PTF currency. So what you do is select this service, and this particular one goes out and phones home to IBM, looks at what the current group PTF numbers are and compares it to your current settings. So you can see right away whether you are at the most current group’s PTF level or not. Very easy way to find out whether you're current or not.

Okay, so V7R2. V7R2 password rules system value came in V6R1, but in V7R2 they added a very important setting or option to be able to specify in password rules (QPWDRULES) called All Create and Change (*ALLCRTCHG).

So, if you think about when you create a user profile or change your user profile, and you think about the password field, normally you can set that password to anything that you want it to be, and it does not have to match your password composition rules, but when you specify All Create and Change (*ALLCRTCHG) in this password rules system value, this now says that all of your rules must apply even when you're creating a user profile or changing a user profile.

So, this is very powerful, especially when you coupled that with this Limit Profile Name (*LMTPRFNAME) value because that says that the profile name cannot be any part of the password. This basically says that you can't have default passwords anymore, because a default password is the profile name.

So, we are encouraging our clients to move over from using those individual system values that have been around forever, and now start using the password rules system value, move all of your rules into this system value because there's a lot more options available to you with this system value versus the individual ones. But once you start using this system value all, of your rules must come into the system value, the system will no longer look at those individual ones, so this is an all or nothing type of thing.

Another thing that was added in V7R2 were some before values for specific audit journal entries. So, if you think of or if you're familiar with the system value audit journal entry, the system value audit journal entry has always had the previous value for the system value prior to its being changed. So, none of the other system values or none of the other audit journal types had a before value until now. So, all of these types of audit journal entries now have a before value, so if you need to change it back, you can look in the audit journal entry see what the previous value was. There were also some changes to commands in V7R2, the work with objects by owner (WRKOBJOWN), work with objects by primary group (WRKOBJPGP), work with object by private authorities (WRKOBJPVT) now allow you to work with those objects by object type. Before it was just you worked with it by user profile, and you got everything. Now, you can subset that, be a little bit more efficient, and work with that by object type.

Also, in V7R2 was a feature called row and column access control or RCAC. This is an SQL feature that was put into place that allows you to filter out by row which rows users see, and another feature allows you to look at columns and mask the value at the column level.

I'm going to say right now, and I'm going to repeat this as I talk in more detail, but masking is not encryption.

So, at the database level, the mask or that column is still in clear text. This is a view only mask. So, let's look at this in more detail. So, at the role level sorry, let me back up a little bit of housekeeping here on the row and column access control, you must first, have authority to the database file before the SQL statements and permissions ever kick in. If you are excluded from the file, doesn't matter if you have permission through row and column access control, it’s never going to take effect. But the cool thing about it is that if you do have authority and these permissions are in place, those permissions will be in place regardless of how you access the file, just like object-level security. So, think of the row permissions as an extension to the object-level security that we've known about for years, and it will apply no matter how that data is being accessed.

Alright, so this is a sample SQL where it is creating the permissions on a particular database file, so this is an employee database file, and basically the filter is based on the department number, so we have department one, two. And in this case, you can say that anybody that is in a particular group sees everything. There are a couple new things that were added in SQL in V7R2, and one of them is the fact that you can now filter by group. If one of my groups is the manager one group, then I will see everything where the field name is department 001 basically. So, that was added. The other thing that was added is the ability to be able to filter based on adopted authority. You can get these permissions the adopted authority, just like you can get the object level authorities based on adopted authority.

So, the interesting thing with the row permissions is that the absence of authority means you can't get access. So in this previous example, if we have a new department, we have department 1 and department 2, if I added a new department 100 and forgot to add an SQL permission for department 100, when somebody tried to do a select statement against this database file in Department 100, they're not going to get anything back. So, you have to think about that one. So, there's a bit of maintenance that you have to think about. Also think about how your developers access production data if they're on the system, they need to have permission to access that information. So if you're using something like the Powertech Authority Broker product, what you would want to do in that case is make sure that whatever profile you're elevating to or swapping to has the permission to be able to see all of the rows or else they're not going to be able to debug properly.

The other thing is that there's no indication that the data is subsetted. So again, especially from a debug perspective, you really want to think through the row and column permissions in that case. When you are copying files to a different system, QA or Dev, we may need to grant additional row privileges. So, if you think about it, the profiles that are accessing data on production are typically different on Dev and QA, so you're probably going to have to modify those permissions when you move that database file to either a Dev or QA box. So, the other thing is that if you're using logical files and want to replace those logical files with SQL view statements, then you're going to want to make sure that you test that to make sure that the view is the same, whether it's a logical view or the SQL permission.

One thing to realize is that you cannot modify or manage the row and column access controls on green screen. The only indication that you have on green screen is when you're doing a display object authority, the row on column access control field will show up, and it will say that it's active. The other way to understand whether objects have permissions and places to look at the SYSCONTROLS view in the QSYS2 library. If you're a green screen lover, this may be a slight challenge for you.

The other thing that you can do is mask. And again, I'm going to repeat this is not encryption. The better thing to do is the field proc. And in field proc I didn't explain it, but you can either bring back the full value for those people that should allow you to see a full value, you can bring back the masked value, or you can bring back a not authorized, which they don't get any values back.

Back to the role and column mask.

This is a masked value, so you have total control of over which part of the value is masked and what the value is for the masked part.

In this case, you can see that what they'll see is XXX for the part that is masked.

Okay, so that's what that is.

Now, the one time when I would use the role and column masking feature, well two times, is if you are absolutely positively never going to encrypt, you're just like “Nope, I'm never going to do that,”  okay, masking is better than nothing.

So, perhaps you take your production data and you move it to development, and you don't want development to see real production data, then use the mask in that case. Okay, the other time we've worked with a client that was moving towards encryption, but they had used a value that needed to be encrypted for a key field, and you can't encrypt a key field. So, what they were doing in that case was masking the data until they could rework that database file such that that value that needed to be encrypted could be redefined and not be a key field. So, it was an interim solution, and it was a good compensating control for the time until they could get it encrypted.

If you want more information on this, it's in the Security Reference Manual or there's a Redpiece it's not as long as a Redbook, but it does a really good job of explaining this feature and when you might want to use it, how to implement it, and so forth. So, I would highly recommend if you're considering this to get this Redpiece.

Okay on to V7R3. V7R3 added more auditing enhancements. The create and change user profile, the CP entry was enhanced, and it was enhanced to include everything about the user profile attributes except the text field and the authority setting on it. Until now, the CP entry logged only the security relevant attributes when the profile was created or changed. So, the group profiles, the special authorities, the limited capability, and that sort of thing.

What it didn't do was things like job description, and the CCSID, and the language ID, and the sort sequence, and all of the non-security relevant fields that are in a user profile. But now everything is logged, so that you know exactly how that profile was created.

The other auditing enhancement that came in V7R3 was to the aud level system value. This is where we specify the action auditing and some of the network action auditing values were modified and a couple more were added. And this allows you to better monitor when you have unencrypted or encrypted sessions. If you're trying to go from unencrypted to encrypted sessions, these are handy because it will tell you what the protocol is that is being used, so something like SSLV3 or TLS 1.0. Especially handy if you're trying to get to TLS 1.2 for example. Good enhancements to today's network audit values. V7R3 brought also enhancements to DCM (Digital Certificate Manager). This is where you assign digital certificates to servers to allow them to have an encrypted session. This is where you would assign a digital certificate to, for example, the Telnet session, so that your Telnet sessions, your 5250-sessions, no longer flow in the clear. The enhancement was to add the ability to have more than one digital certificate assigned to the server. And this is important because a lot of people have created certificates in the past, those certificates tend to have very weak encryption algorithms associated with them or enabled by them. As we are moving forward, to the stronger encryption algorithms and the stronger protocols you have new digital certificates rolled out for those. So, what you can do is assign that stronger certificate, and as your clients are upgraded and they can actually work with the stronger protocols and ciphers, those can use the stronger encryption, while the older clients are still in place.

So once you have totally replaced your older clients, so for example, once you have totally gotten rid of client access and have totally moved over to ACS you can most likely remove those older certificates and weaker certificates, but it allows for easier migration from the older clients and older technology to the newer technology.

So, the best thing in my opinion about V7R3 is the authority collection feature that came in.

So, it came in V7R3, and it's been enhanced in V7R4, so I will get you those enhancements in a minute, but let me first explain what authority collection is. So in V7R3, you have the ability to by user specify or to start to collect information by user on the objects that that user touches and what authority they currently have to that object and what authority is required by the operating system to be able to touch that object or update that object, along with where their authority is currently coming from. So, let's look at this and look at some examples.

The way that we have started to use this is more and more of you are starting to move on to V7R3, so this team has the ability to use authority collection at our clients, and it has just made things so much easier. It takes the guess work out of the security. So, for example, when we're re-working an application to become more secure or have tighter access control settings, we can know what the authorities are that a profile needs. Especially like service accounts, so that we can start locking that down and know that the application isn’t going to stop working.

So especially in the IFS a lot of people, it's a guess work in the IFS because people are just not familiar with it, so it takes the guess work out of what authority is required in the IFS for things like FTP or ODBC.

And for service accounts, a lot of times service accounts or application IDs or there's a number of terms that people use, but these are typically profiles that are making a connection from something like a Windows server or maybe a desktop. And they are making these regular connections. A lot of times we see those just by default, given all object because they don't know, people don't know what they're touching don't know what authority is going to be required, so we can very easily know what they are touching and what authority is required with the authority collection. So, here's an example, say I get this information from the audit journal, and I've got an authority failure to a data area.

Okay, and this is just the easiest example I could provide. I have authority failure to a data area, so what authority is required? So what I did was to run the Start Authority Collection (STRAUTCOL) command, that's how I enable this feature. You enable it again by user profile, so I've specified the user profile, but the profile that had the problem with CJWTest, I know that the data area is in the library called CJW, so I said I want to start the collection for objects in CJW Library.

I'm starting it for all objects in there, but I'm limiting it down to data areas. So, I can be very broad and say I want to start the authority collection on everything that CJW touches, or I can be very narrow and actually name the object. In this case I came pretty close. I narrowed it down to the data areas in a particular library. So I do that, I have CJWTest try to access the database, the data area, again, and so then I can come up and query the collection.

The collection is one of those views in the QSYS2 library. So, I've queried the view, and you can see that the authorization name is always the user profile name. In this case, I'm looking at the demo, that's the object, that's the data area, and the required authority is *USE. So, simple enough I just grant the CJWTest *USE authority to the database or to the data area, and boom, I'm done. Now, this was an over-simplification, but I just wanted you to see that this is how easy it is to use this feature.

Okay, so say we have one of those service accounts where I'm trying to get rid of all objects. So, in this case, I am going to start the authority collection, and I know that the service account is touching something in the IFS, but I'm not exactly sure what. So, in this case I'm not specifying anything about the libraries I want to collect on.

In this case, I'm specifying that I want to collect on the file system objects for directories and stream files.

Now, they did not provide us a way to specify a specific path. So, in this case, all we have is the ability to specify for objects in the IFS. So, I'm starting this authority collection, and you can query this collection again out of QSYS2, and you can see that for the root directory I need *OBJOPR and *EXECUTE. For the payroll directory, that's what I'm really writing to, I need basically RWX to the payroll directory and for the stream file I basically need ownership. So, this is the required authority. So again, the guess work is done.

V7R4. So, the enhancements in V7R4 to the authority collection is now that you can collect on a specific object.

So V7R3 allowed us to collect by user, let's say you have something like your employee master database file or your accounts payable or something that is highly sensitive for a specific file or set of files. So, you can start the collection by that, and it will collect every one that touches that specific file.

So, the configuration of this feature is slightly different then in V7R3. The configuration by user is the same, but when you configure by object you have to use the Change Authority Collection (CHGAUTCOL) command, and you're specifying the object. So, in this case they only provided us with a path name. So, if you want to do a database file you have to know how to specify that via a path name.

So, you specified QSYS.LIB, that's the file system we're working with, and then I want to capture everything in the SKYVIEWPMP library in this case. So, my authority collection value is object information. This is basically your on-off switch. At the point in time that I got all of the information that I needed, I would come back in here and specify *NONE, but to turn it on, you specify object information. You have some options when you're specifying by library. If I wanted to include all my dependent objects, I can do that. You can say directory subtree, which in this case is all of the objects in the library, not a directory but a library, I’m saying *ALL, and so this way I can turn it on for everything in that particular library.

Okay, so then, this is kind of a one-time setting I have configured it for this particular library, and objects in the library by doing the change authority collection (CHGAUTCOL), but when I want to actually enable the collection for objects, I have to do a one-time object authority collection using the start authority collection (STRAUTCOL) command. So now I can start collecting authority information on objects.

That's basically the authority collection feature. I'll show you a link to the authority collection webinar that I did on theV7R3 information. Later this year, look for another session where I'll update that webinar including V7R4 features.

Okay, so moving on to the other enhancements in V7R4, there were some new SST or service tool commands. Before you had to actually log into service tools to be able to do these features, but now there are actually commands that allow you to do these features. By that I mean, you can change security attributes. Some of the things you can do with the security attributes is the ability to lock system values from being changed. So that's kind of an on-off setting.

You can also change the password composition rule requirements for SST passwords using the SST security attributes command. The other thing you can do is actually create service tool IDs, change service IDs and delete them via commands now. So, you might say, “Well, have they reduced the authorities required to run these commands and features?” because that was one of the things about logging into SST it provided some protection. Never fear. So I just took one of the menu options, and it produces this command prompt, and you can see that the ability to run this command requires you to have a service tool ID, so you will have to specify the service tool ID, along with the passwords, and that service tool ID has to have the authority required to actually perform this operation. So, just lowly, old me, if I didn't have a service tool ID, I can't run this command.

If I had a service tool ID, it would have to have the appropriate authorities within service tools to allow me to create another service tool ID. So no, they did not lower any of the security requirements for this. They're just providing a different way into the features.

Another big enhancement in V7R4 are the encryption enhancements, and the biggest thing is that TLSv1.3 has been enabled. TLSv1.3 was approved by the standards body a good year ago, so in 2018 it was enabled, so it's great that that was added to V7R4. Along with that, are some changes to the way the protocols are defaulted on IBM i, so the QSSLPCL, that's the system value that defaults your protocols, now defaults to only including TLS version 1.2 and 1.3. In V7R2, it defaults to including to TLS 1.0, 1.1, 1.2. So, those are now removed from the default, which is a good because you do not want to be using those protocols. They are old, they are weak, they are vulnerable, and there have been vulnerabilities proven that have allowed hackers to gain access to organizations.

So, you do not want to be using that, but the problem is, you might be using that now.

And so when you go to V7R4, things might break, so you're going to want to do some investigation.

I have more of that in just one slide, but the other main thing is that SSLv2 can no longer be specified. So, that is really old stuff, and what's been discovered is that that has not been included as a default setting for quite some time, but just having the code, the ability to specify it actually produced vulnerabilities on the system. So, IBM actually took that code out, and you can no longer specify SSLv2, so that is a huge positive for the integrity of the system.

Alright, so the cipher list because the protocols change the default cipher list has also changed, so now you can see that it only includes strong protocols, and it removed weaker protocols.

One of the things that you're going to want to do in your analysis prior to moving to V7R4 is to check your current encryption levels because if you are using, so if this protocol had said, “This is a strong protocol, so I don't have to worry. My work station will work”, but you will want to launch your ACS session and look at the security information. It will list a security protocol if it says something less than TLSv1.2, it is likely that your encryption will break, and you need to start moving now to the stronger encryption, so that it doesn't break when it goes to V7R4.  You can add those weaker protocols back in, but I want to encourage you to take the time right now and get that up to a level where it is what the industry is requiring, and the industry is requiring no less than TLSv1.2. So, take that time and do that now.

So, here are some links to IBM documentation that helps you understand what protocols are currently in use on your system, as well as to run a trace to find out what the ciphers are.

In past webinars, we have described these various protocols and how to get away from them and how to securely deploy access client solutions.

For more information on new enhancements and other things, I have some links to here. IBM in V7R3 added a chapter to the Security Reference manual to talk about authority collection, so it was obviously enhanced in V7R4 to add the object collection, as well.

And with that, I will turn it over to John, and see if there's any questions.

I'm going to go through a couple of slides here just letting you know about what our professional security services are that we have to offer, and also talk a little bit about some of the products that we have, as well.

I'm going to start in the upper right-hand corner, risk assessment. That's kind of the foundation; that's where you kind of learn what risks are present on your system.

And we do a very deep in-depth dive into your system with the risk assessment and go over with you following an analysis of all the data that we gather, what risks we find, and we put it in a high, medium, and low priority order, so that you can kind of get a good picture in a place to start with enhancing your security.

We also do penetration testing. That’s something that's becoming quite popular. A lot of laws and regulations are now starting to require penetration testing. Think of that as ethical hacking, where we're exploiting what we find when we do and see some of the data that we gather on your system. We find and gather data about user profiles and attempt to exploit your system, documenting as we go and as we go along so that you can see exactly how we were able to get access to data. So that you can have good visibility into just what exactly it is people can do with the profiles that they are currently provisioned with.

So that's an important thing, it's kind of the next step beyond a risk assessment, where we're actually actively attempting to exploit what we find.

And we also do architecture engagements.

I said weeks, could last anywhere from who knows one week to several weeks. And what we're doing there is designing security on your IBM i, and that is an engagement that is quite popular with people. A lot of people do risk assessment, and they run off and do their own remediation work which is great.

The whole goal we have is to get people to improve security.

A lot of people need that plan, “How are we going to put together the security plan? And then, I need more help beyond one risk-assessment. I understand risk, but I want to know where I need to go from there.” And that's what the architecture week is because about. It's more detailed, more in-depth and get you a plan put in place that architects a good security scheme for you. A lot of people will take that and go off and do their remediation with that.

And then finally, we do offer remediation services. There are number of people who just don't have the time, they don't have the bandwidth, they don't have the skill set. After seeing a risk assessment and maybe doing an Architecture week, they just asked us to do remediation, so we do that as well. Then follow on services that we have after we’ve remediated and help you is we have managed security services. You can either start or end there. A lot of people start there with Managed Security Services, some people end there. And what I mean by that is, after they remediated their systems, they put in place our managed security service, which is us paying attention to your security for you on a month-by-month basis, so you don't have to. We set up some software tools, which part of the deal. You don't have to purchase them, they're just part of Managed Security Services, they send information back to us, we evaluate the information and send you a summary report once a month. So that you know somebody's paying attention to your security configuration, so you don’t have to. You can kind of check that box and realize that somebody's watching over it for you. And if you do have issues pop up, we call those to your attention, and then you can address those at that time.

We also do single sign-on manage service. It’s quite popular in the industry and is gaining a lot of traction. It’s the idea of just eliminating passwords and connecting your Windows active directory to your IBM i, and so we provide that service, as well. We do that as a managed services subscription, as well, where we help you get up and running a single sign-on, and then we monitor it over the course of a year, we check in with you periodically, we once a year try to do an evaluation of where you're at with a single-sign-on and if there's anything new things you can take advantage of in your environment and expand your use of single-sign-on.

So that is our security professional services and now we also offer a number of software solutions. During the course of the presentation very early, I don't know if you remember, We talked about Exit Point Manager. That is one of the tools that we offer here at HelpSystems. What you see in front of you is our Powertech Security Suite, for lack of a better term, these are all the different products that fall under the Powertech brand, and you can see that we do compliance reporting, privileged access management, self-service password reset for the IBM i, database monitoring, user provisioning, multi-factor authentication, native encryption, We mentioned that during the presentation, as well. Don't think you want to write your own encryption, think you are way ahead if consider a third-party solution for that.

So, we offer a native encryption, perimeter access control, again, that was that Exit Point Manager that we talked about, command monitoring, so securing specific commands and understanding who is using them and for what, automated risk audit, we have risk assessor for IBM i, which is part of that managed security services that we talk about in addition to paying attention to your services on a month-by-month basis, we also do a risk assessment as part of manage security services. We use risk assessor as a tool to gather data. We also have a SIEM agent for IBM i, so if you're passing information to things like Splunk or QRadar or other sort of log aggregators we have a tool, our SIEM agent that will allow you to do that. We have native virus protection on the IBM i. Policy Minder for IBM i is InfoSec Policy Control, that's where you can set your policy in the context of software and then just check your configuration to see that it's set the way you intend it to be set from a policy perspective. And then finally, and we mentioned this as well, I believe during the course of the presentation, we have secure managed file transfer. One of the things we do offer for free is something called a security scan. It's just a snapshot of where you stand and gives an idea or a first look into security. It's not the depth of a risk assessment, but it just gives you a quick look and it's free and you can just check it out and say, "Okay do I really need to go to the next level and do a risk assessment or are there potentially some software solutions that I could deploy that would be low hanging fruit?”, so to speak. With that I am going to move to questions and see what we have here.

First question: can we create an SST user on the spot without going into STR SST?

Can we create a service tool user without going into SST? Yes, as long as you have an SST user and a password with enough authority, you can do that. So if you know the QSECOFR SST password, you can use the command to create a new service tool ID.

And this was from the same asker, I think it was follow-on to that question, because it starts with “And change as well?”.

Yep.

Regarding column masking, if I implement masking on a field that is used to compare it to a field in another table, will the masking interfere with finding a match (not a key field but used to further verify a proper record match)?

I don't know, honestly the answer to that question. I would suggest they read that Redpiece that I've put the link in for because I think it would be explained in there. I'm not sure. I am not sure programmatically, if it would be mapped or if it depends on the user running that program.

I honestly I'm not sure. I think read the Redpiece is my advice on that one.

Okay, there we are finished with all of the questions.

Thanks everyone for attending today. We appreciate your time. I know we went over a lot of information, covering more than just V7R4.

But from our experience, what you've seen there is a lot of stuff that we see tripping up people in security, so it got more than just V7R4, but very important stuff.

Thank you very much, thanks everyone for attending. Have a great day.