Transcript
We will be recording the webinar today, so if you do have any questions or comments or have to step away for a few minutes and come back, feel free to do so. You'll be able to access the recording later on. If you do have any questions throughout the webinar, please feel free to use the questions panel in GoToWebinar. This is going to allow you to post any questions for us. If we don't have time to answer those, we will be sure to follow up with those after the fact and make sure that you get the answer to your questions. Again, we are recording this, so if you need access to the recording later on, you have that available. Now that our housekeeping is out of the way, let's talk about our webinar today. This is our State of IBMI Security Study. We've been doing this for quite some time. Today I wanted to introduce myself. I'm Sandy Moore, Senior Solutions Engineer here at Fortrex. I've been working on IBMI for over 20 years now and have focused primarily in security and many different roles and really enjoyed working with customers. With me today is my colleague, Amy Williams. Amy, if you'd like to introduce yourself. Hello, everybody. Welcome to the webinar. One of the senior security services consultants with Fortrex. I will hit my nine years this year and have really been focused on security probably for the last 10. Been working on the IBMI either as an administrator or otherwise since 1999. Fantastic. Hopefully, we'll have some good information for you. We've been around here for a bit and definitely enjoy having conversations around security as Amy can attest to. All right. It's hard to make a stop. I know. Yes. No kidding. All right. The Fortrex is a sponsor of today's study and really we're the premier security provider for security products on IBMI across not only IBMI but numerous other platform brands as well. If you're not familiar with our other offerings, I invite you to visit our website. There's some pretty amazing tools we have out there. From the IBMI side though, we provide comprehensive security services to help assess and mitigate any concerns based on your operating system features. We also are a member of PCI Security Standards Council and, of course, publisher of the annual State of IBMI Security Study since 2004, so 21 years into this and we're still doing it. This is the basis of the information for our presentation today and hopefully, you'll be able to garner some good information out of it. First, I want to set the stage for what our conversation is about. What is the security study and why are we doing this? We feel this is really important. Primary objectives of our study is to really help the community understand what the security exposures are for those IBMI servers. Often assumed to be secure platform, this is really something where we need to get that attention out there that there are concerns and they do need to be addressed. Really being able to help customers prioritize their mitigation activities and figuring out really where they should focus their attention and also support those IT efforts to justify security projects. Really helping to combat that popular misinformation that it is that secure platform, so giving you some leverage. The data itself is collected from our security scan for IBMI. This tool has been around for as long as the study's been available and it's implemented through a fast-running, non-invasive Windows application. It allows you to scan from the inside out, looking at those native configurations instead of trying to use an outside-in open port scan, which really isn't going to give you the true picture of security concerns on the system. We're going to validate security configuration across seven key configuration categories, so really ensuring that we're looking at it from a holistic view and top-down to make sure that we understand what are the weak points in the security posture. It's really not intended to be a granular review that's going to help with auditors or meeting any regulatory compliance requirements, but really that starting point of what's happening. There is some benefit to you with the security scan. It's going to give you that tangible report to keep for later reference and to share within your organization so that you can, in fact, start getting that support. Our consultants, including Amy and myself, are going to be able to provide interpretation of the results and explain those findings to you. Of course, the security scan is free to use. The software itself is provided free of charge. The review time, that hour with us to go through and help interpret really what you're seeing is also free. Of course, you have no obligation at that point. You can even opt out of sharing your anonymous data from that security scan, so you don't have to participate in our study. It's just some really good information, but new this year and something that folks may not even realize we do is the second set of data that we've included in this year's study. Amy, would you be willing to share with us a little bit of information about what this additional data collection is from? Yeah. For security services and for some paid engagements and working with customers, trying to get them to the best security posture as possible in their IBMI, we'll do a deep dive risk assessment. It not only covers everything that the security scan will cover at a very high level, the risk assessment will take you down into the deep, dark depths of all of the detailed data. We cover all the same points. We're looking at it from a more macular level so that we know exactly what profiles have those default passwords, what directories in your IFS might be secure. We found it very important because customers are coming back to us and they're not only doing multiple security scans, but they're also working with us year over year on their risk assessments to give a true holistic view of the community out there and what people are doing to start including this data also. Awesome. It sounds like there's a lot of good information here. Absolutely, yeah. We can provide not only the detailed information, but also the steps you can take to improve that. Awesome. All right. Cybersecurity. This is definitely an area of concern. I don't know, Amy, if you want to give us some insight here. What was interesting is that everybody's talking about security and they're looking at security, but we're actually seeing that in the trends of our marketplace survey. On the marketplace survey, it is not only in the top five, but it's actually the number one concern in IBM shops, which is really important because for so long, like you mentioned earlier, the IBMI was considered a secure platform and that you didn't really have to do much to it except for turn it on. The truth is, is it is probably the most securable platform that there is and IBM provides you a lot of those tools built right in, but you do have to take those steps because they ship that machine to you to run and to run unimpeded. So taking those steps, looking at that, we're seeing that it is actually surpassed the high availability and the disaster recovery, which used to be up there at the top. Absolutely. And it looks like eight years in a row, it was actually a number one concern. Makes me wonder though, Amy, if the IBMI people are doing the marketplace survey or if it's the other teams. It does make you wonder because often we have those conversations where there may not be getting as much support as they could from some of the other departments, agencies, people that you're working with on focusing on that security and those changes. Yeah, absolutely. All right. Well, obviously cybersecurity is on everyone's minds. First of all, they're sitting here listening to this webinar, but also in their responding in these surveys. I kind of want to get an idea from you folks in the audience, really what you're actually focused on because there's obviously some concern around cybersecurity. So I kind of wanted to see what security projects you're working on. So there's a number of different things that could be happening. There's malware and ransomware protection. That seems to be a hot topic. There's also the securing access to sensitive data. Are you trying to meet compliance mandates? Are you looking at data encryption or maybe you've got some other stuff going on? It's a combination of all those things and you've got a lot on your plate. I think other might be an appropriate answer for that as well. So just kind of get an idea here of really what your interests are and what your focus is this year. Really appreciate that. All right. So security projects can be a massive undertaking. So this is definitely something that you'll want to take under consideration and how you're going to approach that. All right. I'm going to go ahead and close this poll here in just a second, give you the last opportunity to answer that. All right. I'm going to go ahead and close that. So it looks like we had good response here. Looks like malware and ransomware protection is one of the higher options selected and looks like we've got a lot of meeting compliance mandates. So it looks like somebody has gotten some requirements on their table at this point. All right. So it looks like cybersecurity is really an important feature here. So we have to think about why the security study is still necessary. So we've been talking about this for over 20 years. Why are we still doing it? Really we have to ask the question of what has been the main inhibitor to better IBMI security. You know, this is definitely a conversation that we have over and over again. And I think Amy, maybe you want to provide some feedback into why you might think that we're still doing it. Yeah. So a lot of it is the overwhelming factor, right? When you get the security scan results, or you get a risk assessment results, or you even have an outside third party come in and give you an assessment if you're required to do audits, it can get really overwhelming, which can tend to freeze us into inaction. And inaction is the most dangerous place to be because then we're not taking any steps. So we see some inhibitors of prioritization, some inhibitors of no funding. But the truth is, is there's generally steps we can take. So whether it's understanding what the changes are going to cause to either stop functioning or function better, right? Those are those misperceptions that are sitting out there. Management priorities, it'll come to the top of the list right after an audit. And then if the focus isn't maintained, it can quickly dwindle and fall off and other priorities are going to come up. The education for IBMers is not necessarily as lackluster as it was. So when I started doing this stuff, nobody talked about security, right? You had the system running, you were getting your applications going. Security was all those, the windows and those network guys. Now security is more and more becoming the responsibility of the IBMI administrators. And there's a lot more information, a lot more education out there, not only from Fortra and with our webinars, but also from IBM and some of those user groups out there. I mentioned the network guys often. We will have a conversation with customers and it still happens today. Nope, IBM's behind a firewall, I don't need to worry about that. But when we look at some of the other security studies, when we see the results in the Verizon report, we are seeing that insiders are becoming the high risk access points that we need to pay more and more attention to. It's not the outside. So being behind the firewall doesn't necessarily give you that sense of comfort and reliability you used to have. So with the green screen menus, it was awesome, right? You had TwinX cables and you couldn't get to the system unless you had physical access. Well, that's not the case anymore. And so much of our applications have been moved into web and been modernized. So we don't have that reliability, we don't have that safety of just the menus protecting us and protecting our users from doing things that we didn't necessarily tell them, intend them to do. And the other thing, and we asked for this feedback, so if you wanna put it in the questions, that would be phenomenal, is what do you think is the inhibitor that's stopping you from being able to secure your IBMI as well as you think you can? The thing we wanna get to is we wanna start changing the trends even more than we've seen to make security the number one priority for the IBMI. Yeah, I can't agree more, Amy. The reliance on the... All of those topics are, I think, are a big piece of why there's so little movement and the inaction has paralyzed folks. So firewall comes up all the time in conversations with customers. The green screen menus, that reliance on that has always been up there at the top. So, all right, well, let's see if we can maybe look at the data and see if we can change the direction and if we can help start making a difference in this and really moving folks forward into the secure state on the system. And that's really our goal here to assist customers. I think the education topic is extremely important and being able to help customers get that level of security on the system and learning how to do it and how they're going to be able to accomplish those tasks. You can actually look at the data itself through the State of IBMI Security Study. It is available on our website now. It's being released today. So you will be able to access that information so you can see the details of it. We've actually highlighted a few things that are... We felt were really important things that have either seen significant change or things that are just profoundly disturbing and concerning from a security perspective. And so, hopefully, you'll find that these pieces of information that we're providing today are going to, in fact, give you guys some good solid foundation for getting a start on security. Yeah, so I really want to start with the system security value. So I mentioned that IBM provides us a lot of tools built right into the OS that can help us protect our systems. And the Q security system value is one of those. There used to be, I will say, levels 10, 20, 30, 40, or 50. At V7 or V5, IBM's even realized that levels 10 and 20 are just not applicable in this timeframe. So if you move to 7.5 and you do that save-restore, you're going to be forced into a minimum of level 30. So our recommendation, and it always has been, is to get to level 40 or 50, because this is where the integrity checking comes in to the OS level. There are some ways around the security checks at level 30 still. At level 20, it was very gracious and granted every user profile that was created on the system all object authority and safe sys by default. So you had to take steps to be able to change that. Now you can run a level 20 system, and this is the brilliant part, is you can run that level 20 system as if it were at level 30, because when you do that IPL, it's an all or nothing IPL, and it will change your user profiles, and you've got to now live at that new security level. So you can prepare for these things. You don't have to just cross your fingers and hope when you do that IPL. So we strongly encourage you to do this. I had a customer call us, and they were doing their DR testing, and they couldn't get anything to work, and they were just having authority failures all over the place. It turns out that their system that they're moving from was at level 20, and then when they did that move to the new hardware, that all object authority was stripped from all of their user profiles. So there are consequences, and moving forward and getting modernized, staying current on your OS, this is a factor you're going to have to start taking into consideration. Yeah, sounds like something that some folks are going to have to start getting on here shortly if they're going to be moving up their new operating system. So better to do it ahead of time than have your system fighting you for sure. Yeah. Awesome. All right, so second metric, really we thought that looking at the access of the users to the system, so the passwords and how they're going to be signing on a system was another key piece of information that we needed to look at. And it's interesting because the default password is what we're looking at here, and this is really where a password matches the user profile's name. So default password is terrifying in my world, and I think Amy would agree with that one. It's not a good plan. User ID and password is the same. There's this big concern with the fact that not only is it not an easy-to-guess password, but it's literally the same as the user profile. So the systems themselves don't come with default profiles. The only one that's actually shipped with the system with a default password is Qsec offer, which you change as soon as you stand up your system. When we looked at the data itself, we saw the number of user profiles on average, there was 129 average per system had that default password, 89 of those were enabled. Now while the average number of profiles has actually gone down over the last few years, what we have seen is an increase in the number of those profiles with default passwords that are enabled. So unfortunately, even though we seem to be moving in the right direction on the average, the fact that there's more of them that are enabled, ready to be used to sign on to the system through any available entry point to the system is very concerning. Amy, I think password level falls into this category as well, and I don't know if you want to give us a little bit of insight here on the password level metric we've got from the study. Yeah, so with password levels, again, at 7.5, IBM is really taking a strong stance in improving the security posture of the system. They've introduced a new level four encrypted password hash that's at SHA-512 now. So moving to level four gives you better encryption of the hash of the password. It does not change the complexity rules or anything like that if you've already moved from two to three. So what does happen is if you look, the numbers show that we're almost even with how many systems are at level zero or one versus two or three or four. So zero and one, you're not case sensitive. You're limited to 10 characters. Could we make it easier for people to do a password spray attack on an IBMI and guess the right passwords? Not really. So moving to level two is really a key factor, and then getting to three, what that does is it takes care of some of the lesser encrypted passwords that used to be required for Windows systems, but most of those Windows systems have been sunset in probably the last five to seven years. So with those password levels, those are all or nothing changes, and it still always catches me by surprise how many customers are still at those lower levels and limiting themselves to 10. We always would hear, well, our users can't handle complex passwords. 15 years ago when I started doing this, maybe 20 years ago, not everybody had a banking application. Not everybody had to have passwords for their internet access or for their phones. People know about passwords now. So I don't think we can continue to rely on the fact that we hope our users just aren't smart enough to do things. We need to start meeting these minimum requirements. Agreed. And it looks like when we look at the numbers from last year, we have had some improvement in this area where last year was only 30% of customers met that level two, three, or four. However, I want to make a comment that we actually had nobody who was at level four on the password level last year. So interesting piece of information there that I just wanted to throw out. We are seeing some movement, which is good. We're happy to see that, in fact, there's more level two than we've ever seen before. That absolutely true. Yeah. So it's being paid attention to, which is good. So let's talk about some of default passwords. I kind of already talked about where some of those risks might be. But when the server itself has the core data for the company, and your passwords are so weak that it is literally the same as your username, you're not doing your best to protect those assets. So really, it needs to be addressed, and it should be at the top of the radar. There needs to be policies in place that actually address how we're going to approach this. As Amy said, we're all used to passwords in our day-to-day lives, and even if the users may not be as savvy, this is still about protecting the core server for the business, and making sure that these policies do meet those minimum standards. Expiring a password, you want to be careful with that, because it doesn't actually prevent the profile from being used. It can still be used to run batch jobs. So while that seems to be a go-to, I see pretty often, it doesn't actually solve the problem. So we really need to make sure that those profiles are cleaned up, and that those default passwords are removed for the profiles altogether, not simply expiring the password, or even disabling the profile doesn't do enough. And keep in mind that passwords don't actually prove who the user is. So anybody can have their password compromised. If you've got users who are less savvy, they might be writing those passwords down on a Post-it note. We've seen it before. I hear horror stories about it all the time, where users have got their Post-it note either under the keyboard or flat out on the monitor. And multi-factor authentication can help to combat that, in giving you that, ensuring that it's not the compromised password that's the only thing that allows somebody to connect to the system who's not that user. Of course, the plan of action here would be to actually start cleaning this up. So a good place to start is by running the Analyze Default Password report. And that will give you a good idea of which profiles have those dangerous default passwords. And then expire the user's passwords and tell them to change those passwords immediately. Make sure you're reviewing your onboarding procedures. When you add a new user, don't allow for that profile name to be used as that password until the user changes it. Make sure that you have some sort of process in place, whether it's an internal default password that is not matching those user profile names, or simply adding a random password the user has to reset immediately when they sign on the first time. If you're above V7 R2 or later, of course, customers, you should all be there anyways. 7.2 and 7.3 are now out of support, so should be above that. But there is that limit profile name and all create change system values and password rules that can actually help to prevent those new default passwords from being assigned. And of course, if you are still at that password level 0 or 1 using the password rules, limit profile name and all create change are going to be effective and they will help with that. There's definitely some additional information that you can implement to start getting this going in the right direction. All right, next metric, admin privileges. Amy, I think you've got some insight into this one. This is always one of my favorites to chat about, because we have the average number of users on systems that have these special authorities. This is obviously a one-for-one, but the average across all the systems we evaluated, there were 241 users that would have all object. And with all object, you can very quickly and very easily add all the rest of the special authorities to your user profile. You truly are an admin with only all object as your special authority. In looking at the last year's data, what we really saw is an increase for the IO SysConfig from 61 last year, and job control, which again, always is in those higher numbers, but it was only at 442 last year, and this year we've got up over 849. These special authorities can grant access to things that we don't think of. For job control, it actually has a way to grant you authority to spooled files. It's not just about being able to end any subsystem on the system when you have job control beyond being able to end jobs, but it can also allow you access to spooled files in out queues that are set for opera control. It's something that people don't often think about and don't realize when they have that private information, that PII being printed out in the spooled files, that they are inadvertently possibly granting access to that data to users with job control. And then IO SysConfig, the reason we're focusing on that even more now is because of its ability to present shares, and we know that shares, and we'll talk about this later, is a huge risk to our infrastructure and the safety of our systems. If we get into some of the more specific numbers on the all object, because it is that truly administrative right, you can see in this chart, and this is a year-over-year comparison from 2017 to now on the percentage of users having all objects. We've moved from 18%, we kind of dropped down, 2021 and 2022 were huge spikes, but now we're starting to see 2023, nice improvement, and 2024, it went up a little bit. So always hoping that we'll continue to see this all object get reduced further and further, because we don't want to just make the problem go away by just granting them all object, and then it makes it easy because it just works. So some of the considerations that we can take when we're talking about special authorities is all eight of them are considered administrative authorities, and you're seeing auditors take these much more seriously now. When you're granting those authorities, you need to look not only at the user profile, but also at the group profiles they're a member of, because they can be inherited. When you get to the nitty-gritty, when you actually identify how your users are using the system, whether it be through menus or being through a web UI, however that application that you're running that you're relying on for your business is operating, you generally will find out that the majority of your users don't need any special authorities to make those applications run. So when you look at that by generating a built-in report off of the SecTools menu on IBMI, you can find out exactly who has what authorities and where they're inheriting those from if it's not on their user profile. The authority collection was introduced. This can absolutely show you how the objects are being accessed, and this really speaks to all object authority when we're just like, hey, just give them all object and it's going to work, because we don't know how much authority they need. Do they need read authority? Do they need execute authority? You can get to that minutiae level through the authority collection of exactly what authorities need to specific objects. Once you identify that, you really want to create that plan going forward. Sandy mentioned it earlier when you're talking about your onboarding process. You want to have it built in your onboarding process where you're giving to that zero trust, least privilege, only granting users the authority they need for the job that they're doing the majority of the time. Now, if you have those special cases, we've got operators that are doing special saves. We've got night-end processes that are being done by users of the application, and those sometimes need those elevated authorities. Well, you can temporarily elevate those authorities with either swapping profiles and using tools for that. You can also include a multi-factor authentication to have them prove they are who they are before they're allowed to do that special process or take that menu option that they need that additional authority for. There's a lot of ways that you can reduce that all-time exposure of the special authorities and really limit that risk landscape. I know it's something that's been coming up quite a bit with cyber insurance policies, and they are really cracking down on the administrative users from what I've heard from customers. Multi-factor authentication is one of those ways that they are requiring you to put in that additional control. It's a really good point, Amy. I think it's important as well. All right. Second metric, next metric is the exit program. When we look at the security study data, we look at a couple of different pieces of information with this. We're looking for full exit program coverage as well as systems that have at least one or more exit program in place. Really, first, we have to address what exit programs are, and when we look at those, these are really programmer-defined functions that can do something that the original application doesn't. Really, because these systems are so connected and the access to these systems has gone so far beyond a simple green screen connection, we've got to be able to add additional security. In order to augment that object-level security or to prevent those privileged users from accessing those systems through those TCPIP connections, those exit programs are going to provide that additional layer of control. They should be able to provide you with auditing of who's using these TCPIP connections and allow you to also add access control. If a user uses one TCPIP connection, such as FTP, should they be able to do all of the things that they can do technically at the system level, or should we pull back some of that control and only allow them to do certain functions? This does usually tend to be the first control that's deployed by companies that are just starting out in securing their systems, because it does give you that layer of control above and beyond what that object level and that default system level authorities are. We have seen an increase while the full exit program coverage increase was nominal from last year from, I think it was 3% actually had full exit program coverage on the systems that we evaluated and had the data for. But this year, we saw a little bit of a nudge into the 7%. When we look at systems that maybe only had partial exit program coverage, we actually saw a move from 35% up to 60%. We are seeing more adoption of exit programs, but I'd really like to see that number come up further. I would really like to see that there is more acknowledgement of the concerns around having access to the system without any visibility and actually putting those controls in place. Some of the considerations here with the exit programs is that they really should allow for you to have visibility to those entry points to the system. Amy and I talk about often and describe the IBMI as a building and the front door is your green screen and all of these other entry points to the systems are those side doors. They don't have cameras above the doors by default, so you can't see who's coming and going. You don't have a security camera. Then you also have the fact that those entry points don't really have much for locks on them. That's where it gets you in the door and then there's no real visibility beyond that as to what someone's actually doing once they enter. The exit programs are really going to give you the doors that are actually going to stop people from flowing in and out and be able to lock down what somebody's going to be able to do when they get there. When we look at exit programs in general, they can do anything you want, but we really like to have them be security centric. It does add that additional layer of security where you can determine if the action the user's taking is appropriate or not, and then go ahead and allow them to continue or stop them in their tracks. Unfortunately, this is really that one area is the most attacked interface. If you think of the threat actors, they are not going to attack the system through the green screen menu. They probably don't even know what a green screen is. They are going to attack through these TCP IP connections, which we can't shut down because we're using them for critical applications and functions in the business, but they're also the least guarded. This is really where you have the most vulnerable area of the system and there's very little attention paid to it. What you're going to be able to do is actually determine first if you have exit programs in place. This is something that comes up often is, well, I have an exit program, but I don't know what it does. Anybody can write an exit program to do whatever you would like. What I would do is run the work reginv command, locate the different servers, and determine if there are exit programs on there. You can print it out, look for the exit programs through the printout as well, and then really determine what are they doing. If you don't know who wrote that exit program or where it came from, I would start questioning, do a little bit of digging, figure out if you can identify it. Very often have conversations with customers that say, yeah, well, I think this was that guy who retired 10 years ago and we're not really sure, we're not using the data that's being collected. It's not doing you a lot of good if you don't know what the program's doing, if it's restricting access or if you're not monitoring what's happening. I would definitely look for a commercial solution, re-evaluate an exit-based program solution like our Exit Point Manager to be able to have that full visibility and deploy the solution so that you can actually have that visibility to who's connecting to the system outside of your green screen, what they're doing, and then be able to stop inappropriate activity. Going back to Amy's suggestion of that zero trust, this is an area where you should be getting to a deny by default. If you have not identified a user as having the ability to use FTP, for example, probably shouldn't be letting them. This is where you're going to be able to deny that by default and ensure that you don't have somebody taking advantage of those backdoors to the system. Now, we'll talk about auditing and having that visibility to what's happening from those external points to the system. Another metric we've got here is the event auditing. Yeah, and this is right in that visibility piece. If you don't have visibility into your system and what's happening on it, how can you protect it? It is still higher than I ever expect it to be. When I run into customers that don't have the audit journal configured and turned on, always surprises me, but it's still happening. Ensuring that you've got auditing so you've got some visibility turned on is really the first step because that is your security log on the IBMI. Some of the considerations that you want to take before you turn it on is your disk space. Many of us used to start in just gigabytes, and now we're all talking about multiples of terabytes, tens if not hundreds of terabytes on our systems, but you still want to take that into consideration. Turn it on on a Monday. Watch it. See what that activity looks like so you can scope out how much space you need. I like to recommend that customers keep at least 5% of their DASD reserved for this logging for that auditing so you can start using it. Then you need to start looking at it. IBM's provided a lot of queries for you to look at it now. Getting there is a lot easier. Some of the things you need to consider is that with the forensics tool, if you load it after something happens and you don't have the logs available to you, you have nothing to go back and look at. This is really where having the data up front and not eating it is definitely a bonus. I hope you never eat it. It still happens. We have customers call us after the fact, and there's nothing we can do when they don't have the logs. To do that event auditing, there are a lot of choices. IBM lets you get into the minutia of the system. We've got six or seven that we recommend. Security failures. You want to know what's getting created and deleted on your system. You want all the security events. Who's changing profiles, creating profiles, changing their authorities? You want to know those things. Moving forward, being able to report on those, either with our tools or, like I said, from those SQL queries that IBM's now providing with exposure to what's going on in the audit journal. What you don't know, you don't know. Definitely there are some things you need to know about. Virus protection. This has always been a controversial topic. Viruses on IBMI has always been considered not required. But in all truth is IBM actually has been supporting native virus scanning on the system since V5R3. They've actually provided two system values, two exit points, as well as attributes on the stream files to track the scan status. Virus protection is definitely a very desirable option to add to your system. Actually, I would go so far as to say non-negotiable. If you look at what the threats are to any environment, malware is right up there at the top. Ransomware attacks are the biggest concern. It's not if you're going to get hit by ransomware, it's when, how bad is it going to be, and how are you going to recover? Virus protection is crucial. It does need to be added because the IFS is vulnerable. It will allow malware to sit stored on the system for all eternity and can be spread out to end workstations, end user workstations, but it can also be impacted by malware. Ransomware attacks, having files encrypted, deleted, and basically unusable on your system. Cool thing with this year, and I just about fell over when I saw this piece of data, is that of the systems we evaluated, 41% of the systems actually had virus protection in place. This is a huge jump from previous years. I think that there is some adoption in this area that we haven't seen in the past. I don't know if these threats finally got bad enough. People got hit hard enough that they started actually addressing this concern. Year over year, we've seen the virus scan increase, but as you can see here, 2024, with 41% of the systems having that virus scan on open. There's a couple of different ways you can do this. This is really about using native tools and adding that functionality using the controls that IBM provides. The initial virus concern is from file transfers, anywhere where you have the ability to move files from a Windows workstation to the IFS and into the system. Those are the most often taken advantage of. Discoverable shares are wide open. Any user with a user ID and password that has access to the system is going to be able to take advantage of those discoverable shares. This is one where having exit programs to monitor who actually has access is really helpful. You know who is, and you can actually determine which users should be able to use the file server exit point. The native objects are immune from infection, but not from impact. Depending on what has been shared, if you've shared the root directory, qsys.lib is part of that. It is, in fact, able to be impacted. If something is unable to be encrypted by ransomware in an attack, it will very often be deleted. If that user has authority to delete, it is going to be deleted. It can have a massive impact on a system. We do hear a lot that high availability is what we use for backups. This is how we protect from downtime. Unfortunately, high availability replicates the viruses and any actions that were taken by malware in malware or ransomware attacks. Those files that are impacted are going to be replicated. You're going to have two systems that are unavailable and encrypted or damaged and need to be repaired. It is, unfortunately, not going to be a good solution for combating that particular concern. Viruses don't actually have to be written for IBMI. However, I have had some rather controversial conversations with folks that you could technically write malicious software for the IBMI that could be considered malware. Not as likely, but because it doesn't have to be written for IBMI, any of the threats that are out in the wild are potential impact to the IBMI. The virus protection features that IBM built into the system don't actually have a scan engine that comes with it. Even though the controls are in place, you actually have to add a scan engine to do that native virus scanning. Some folks are like, hey, you know what? This just sounds a little fishy to me. We have some real-world production examples of impacts that we've seen on customer systems. It's starting, I can't even, it's been, I think eight years ago was one of the very first major impact I saw with the half a million files encrypted by ransomware. Unfortunately, we continue to see this happening over and over again. It is, unfortunately, a real threat to the system. We really need to start providing that virus protection so that you know, in fact, that the system is not going to be hosting it, it's not going to be impacted by it, and that you are able to do the scanning securely and safely. When we talk about things that you can do to start getting to that point, goal and rule here is to never share the root folder of the IFS. That is going to be a game changer. You've got to make sure that you don't have a root folder share. Evaluate all of the shares that are defined. You can use Navigator. You can use the GoNets menu if you're a green screen, but make sure that you're reviewing them frequently so that you know when these have come up. People can add them if they have that iosys config, they're going to be able to add new shares. Making sure that you're staying on top of it. Make sure those drive shares are read-only whenever possible. When they're not, then ensure that you've got those exit programs in place to secure what a user's going to be able to do. Take advantage of the QPWF server authorization list. This is going to protect that qsys.lib from users if you do have a root share still out there. Of course, all object is going to trump that. You can delete the operating system, unfortunately, with that. Deploy the native antivirus. Make sure that you've got that native virus scanning on the system and even go so far as to use a tool that has anti-ransomware functionality so that you can also analyze the behavior of the users. Exit programs are going to be able to control that access. You've got that multi-layered control where you're able to not only determine if the user can access the system, how they can do it, but what are they doing, and ensure that there is plenty of protection in place there. There's a lot of things that we're not able to cover today on the security study. There's 98 different data points. Really encourage you to grab that security study and look at the other pieces of information that we found. It is interesting. I geek out on the numbers, but this is a process. This is not a one and done. You're not going to have a silver bullet that's going to fix it all. It is going to be a process. It takes the time, but eventually, you will be able to get to that point of a more secure system. Some of the things that we take into consideration are the CIS benchmarks. This was new a few years back, but I can't consider it new anymore. They continue to update those CIS benchmarks. They are specifically a set of them for IBMI and IBMI operating systems. They have published V7R4 and V7R5 just recently. I strongly recommend that you get access to those and download them. They're a great place to start for evaluating your own system. Absolutely. All right. Some key takeaways here. First, I would actually look at the threat of a security incident and understand that it is not going away. You have to acknowledge that that piece, the security incidents, it is monetized. It is not going to stop. We really need to understand and acknowledge that. The IBM Power and IBMI are a fantastic combination for a foundation, but security is not automatic. Ensure that you have taken those steps to activate and take advantage of security settings on the system. Even small changes can make a world of difference. It's not about a full system overhaul. You don't have to do it all at once. A small tweak can make a big difference. Think about all the different metrics that we talked about today. One of those changes can have a huge impact in securing the system, ensuring that something doesn't happen. It's hard to measure. If you don't know, if you prevented something from happening, how do you know that you prevented it? How do you know that you, in fact, did make a difference on the system? Having the information and ability to evaluate it, I think, is really important. Bonus here. Start auditing. Start inventorying your security settings on the system. Understand what's happening. This is going to give you additional information, additional insight, and I think it's going to give you a lot of power back on your plate to be able to make decisions about what's happening on your system. At Fortra, we do have a lot of helpful resources that you can take advantage of to be able to beef up the security on your IBMI systems. First step, of course, is assessing the risk of that security incident. Using our security scan is going to give you that insight. Talked a little bit about it at the beginning, basis of this security study that we're talking about today, but really allowing you to see that 30,000-foot view of your current security settings on the system. I encourage you to do that. I don't know if you have looked at it before. If you wanted to do a refresh and actually run another security scan, you could absolutely do so. I'm going to go ahead and plug out the poll here and see if you were, in fact, interested in doing another security study, or if you haven't participated yet, go ahead and let us know here, and we will make sure that we reach out to you and get that done with you. You can take advantage of that hour of free review and actually be able to get some traction on your starting. All right. I'm going to go ahead and close that. If you didn't have the opportunity to respond to that poll, you can throw a question into the questions panel and just let us know as well that you are interested or just need more information first. All right. Beyond the security scan, our expert services, we've got managed security services, single sign-on, remediation, risk assessment, penetration testing, and architecture. That full data security lifecycle, all with our security experts and being able to provide you with the actionable items to make a difference and get that system to a more secure state. Of course, best-of-breed security solutions. Not only taking those steps and making those modifications on the system, but adding those additional layers of security through the vulnerability assessment, intrusion prevention, compliance and audit reporting, encryption, virus protection, identification and access management, secure managed file transfer, security policy, as well as security and integrity monitoring. That full suite of security solutions that can help to address the individual needs. Circling back to the CIS benchmarks, Amy, I think we've actually got some tools that can address the majority of those controls. We do. We've bumped our tools up against what CIS is looking for in being able to secure these things. Not only from a policy standpoint and ensuring that the system values are set to best practice, but also other management aspects that CIS recommends on a server basis. Going beyond IBMI, but the CIS benchmarks across the platforms. Yeah. Fantastic. If we look at Fortrex as a whole, we cover even more of those. This is really our happy spot. If you do have any questions, feel free to drop those into the Q&A panel here. I know we are out of time for today, but I really appreciate you taking the time, listening to our information and hopefully you garnered some helpful information and it actually triggered some thoughts and questions on your side to entice you to look at security on your system and understanding that it is, of course, a journey. It is going to take effort, but it is well worth the effort. Please visit our website, Fortrex.com. You can send us an email as well if you had questions. We will be following up on any questions that were posted in the Q&A panel here. Really appreciate your time and we'll be talking with you soon.
