On Demand- Best Practice Security Measures for Deploying IBM Maximo Application Suite on Red Hat OpenShift

0:00
Good afternoon.

0:02
My name is Anamora.

0:03
I’m a part of the Cohesive marketing team and I will be assisting the team today with the webinar as moderator.

0:09
We will give it another 30 to 60 seconds to allow all the attendees to join us on this call.

0:35
Great, I think we can start.

0:36
Hi everyone and welcome to our webinar on best practice security measures for deploying IBM Maximo Application Suite on Red Hat Open Shift.

0:45
Before we start, I would just like to highlight some administrative tasks.

0:48
Note that this webinar will be recorded and distributed post webinar.

0:52
All the attendees are currently set to listen only mode, but feel free to post any questions or comments in the chat or question box located in the top right hand corner.

1:02
We will address all of these at the end of the webinar.

1:05
Should you have any technical questions or problems, please log it with the go to Webinar technical team in the form of a question mark or help section on the panel itself.

1:14
Before we dive in, let me briefly introduce Cohesive.

1:19
We are a leading service provider and systems integrator for IBM Maximo, helping organizations maximize their asset investments through improved efficiency, extended asset life and reduced risk.

1:30
Our expertise bands implementation, upgrades and digital transformation, ensuring sustained success for asset intensive industries.

1:39
In today’s session, we’ll explore best practice security measures for deploying maximum application suite on Red Hat Open Shift based on our practical experience and insights gained from working across various industries.

1:51
To guide us through this topic, we’re joined here today by three experts.

1:56
Jeff, Director of Hosting Services at Cohesive Jeff is an expert in cloud strategy and Maximo deployments with nearly 20 years of experience in IT and digital transformation.

2:07
If Staw’s Senior Manager, Cloud Hosting team at Cohesive.

2:12
He is a specialist in mass architecture and cloud optimization with deep expertise in IBM technologies and secure infrastructure design.

2:21
In Ezra, Cloud Engineer, Cloud Hosting and DevOps at Cohesive focused on developing mass on Red Hat Openshift with hands on experience and cloud security, DevOps and infrastructure automation.

2:33
So without further ado, let’s dive in and hands it over to our speaker today, Jeff.

2:39
All right.

2:40
Yeah, thanks.

2:41
Thanks, Anna, for the introduction.

2:43
I appreciate it or we appreciate it.

2:45
So we’re going to go through a number of different topics here today just to kind of do a little bit of an introduction.

2:53
You know, what I’m going to do is we’re going to go through a little bit of the general architecture landscape, just why we’re doing this.

3:01
You know, this topic, what’s happening in the maximal space from an architecture perspective, and the really, you know, kind of dive into why this is important, right, especially from a security perspective.

3:14
So then we’re going to dive into a number of different technical topics.

3:18
So we’re going to do an overview of the essential security configurations that are typically done and especially some of those ones that we recommend for IBM maximal application speed on red hot open shift.

3:31
Then we’re going to go through some of the recommended security, the network security settings settings, OK.

3:37
So this includes some of the access control policies that you may find and a variety of other things.

3:45
Then we’re going to go through some data protection and encryption items, OK?

3:49
So these are really important, especially, you know, when you start talking about data at rest and then data at transit.

3:58
And then lastly, we’re going to go through a little bit of observability and compliance tool kits to help you understand what is maybe available to organizations out there, what cohesive recommends and what that looks like.

4:12
OK.

4:14
And then lastly, I guess we’ll open it up for QA.

4:16
We’ll answer some questions, see if anybody has any questions.

4:23
All right, so just to kind of kick things off, I think, you know, everyone is fully aware, you know, it’s been, you know, IBM Mass has been out for a number of different years now.

4:33
What I want to do is just kind of set the landscape, set the tone, take a look at some of the key drivers or the key changes.

4:41
And then the drivers, which really is, you know, why we’re talking about security, why we start talking about open shift, you know, some of the major drivers or the factors with this architecture shift.

4:55
You know, one of the things many years ago, IBM, you know, has changed their, you know, the deployment methodology, right?

5:02
So what IBM has done is they’ve moved, you know, into a little bit more of a modernizing way of deploying Maximum, OK.

5:11
So they’ve created a unified platform strategy for deploying IBM maximal application speed.

5:18
And this all involves deploying on red hot open shift, right?

5:23
So there’s a lot of different technologies that have changed.

5:26
You know, it’s, it’s quite a bit different now, like classic Maximo, you know, Maximo 76.

5:32
What we used to do is you take a server, you know, whether it’s Windows or Linux, you deploy Web Sphere as an example.

5:38
You know, you didn’t install the Web Sphere application server and then what you would go ahead and you deploy things, right.

5:45
So this has significantly changed.

5:49
You know, obviously this has been doing, we’ve been in this kind of methodology change or this deployment change for quite some time.

5:57
So this, like I said, this involves the Red Hat Openshift platform.

6:01
It involves the use now of IBM Cloud Pack, cloud packs.

6:06
And really this is a change from a monolithic deployment to ultimately micro service, micro services using a containerization approach.

6:15
OK, this changes a lot of different things, right?

6:18
So on the right side of the screen, there’s a lot of different things that need to be addressed as part of an upgrade from 76 to IBM Mass, right?

6:27
So the biggest thing ultimately as part of this is the architecture and technologies, right?

6:32
So, you know, everything is deployed now within the Red Hat Openshift container platform, and there’s a significant amount of choices that you have, whether it’s a public cloud system, you know, whether you want to use single node Openshift, whether you want to use a regular distributed platform.

6:50
You know, what happens is you need to look at your requirements and that changes how we deploy things, right?

6:58
The deployments, right?

6:59
So the deployments are significantly different, right?

7:02
So there’s some automated tools that you can use now to be able to deploy all of the artifacts that are needed, whether it’s a hypervisor on your on premise platform or if it’s on a public cloud, there’s certain things that you can do to speed up and automate that process, right?

7:20
So you want to make sure that you’re, you do have a standardized consistent and repeatable deployment, right?

7:28
IBM release, the, the IBM release life cycle policy has changed as well, right?

7:35
So that’s changed to A313 life cycle.

7:39
There’s lots of information on this, obviously.

7:42
So every release, you know, every IBM is committed or I guess what they’ve, they’ve said is we’re going to be doing yearly releases.

7:49
Now there’s a lot more to this.

7:52
Obviously, if anybody has any questions about the life cycle release policy, we can certainly provide more information on that.

7:58
There’s a lot of information there.

8:00
Implementations, of course, with the new platform, you need to start looking at the maintenance of it, the upgrades.

8:08
What does that look like?

8:10
You know, there’s a lot of information there.

8:12
Of course, red, there’s different release policies or life cycles where you know, there’s there’s releases with IBM Mass, there’s releases with manage and then of course there’s new releases with red hot Openshift as well.

8:23
So you want to make sure that you’re deploying, you know, providing your maintenance and your updates in a, in a matter that’s right for your organization.

8:35
Obviously the the topic of today is security.

8:37
So that’s a huge thing, right?

8:38
Security and monitoring, that’s changed significantly, right?

8:43
So it’s a lot different.

8:44
You got to monitor right at Openshift.

8:46
Now you know what’s actually deployed in Openshift, the pods, everything that’s running.

8:51
So that’s changed considerably, right?

8:53
And then lastly is the people and processes, right?

8:56
How are we doing things, right?

8:58
So you know, even processes something as simple as you know, our restore, right?

9:04
So when you restore from mass down, you know, from from production, for example, down to your development or, or test environment, that’s changed, right?

9:13
So there’s different processes that are involved when you even restore down, right?

9:18
So that’s all that’s all changed, right?

9:20
So, so that’s the landscape kind of just setting things up.

9:24
Obviously we’re focusing on security in this presentation.

9:27
So I’m going to dive right into, you know, why does it matter, right?

9:31
So, you know, I, I think the big thing, you know, from a cohesive perspective, especially is, you know, security is not optional, right?

9:39
So it’s, it’s the foundation of everything we do, right?

9:42
So especially in today’s world with everything that’s happening, there’s a lot of, you know, there’s, there’s vulnerabilities, there’s a lot of people, you know, in organizations that try to obviously disrupt operations.

9:56
So that is, it’s certainly a foundational part of anyone’s deployment or I, we certainly recommend that it needs to be a foundation of your deployments, right.

10:06
So you know what we see, you know, there’s there’s a couple of reasons for this is because you know what we see is quite often maximum does have some level of sensitive data that’s deployed into it, right.

10:17
So you know, of course it operate, it handles operational data, it handles asset data depending on what systems Maximum is integrated to right, if we pull in data from an ERPHR systems etcetera.

10:34
So this is at very critical that, you know, security is certainly a very high priority, right?

10:43
Complex architecture is a big part of this, right?

10:45
So with any shift or change in architecture, you need to have a full understanding of what this platform looks like, right?

10:55
Especially when you know, there’s different ports that are open, there’s different ways to harden the system.

11:01
It’s, it’s really important to ensure that you know, of course, you’re, you have a really good and thorough understanding of what this new architecture looks like because it has changed.

11:13
It’s again, it’s no longer a Windows machine or a Linux machine that runs web sphere, right?

11:18
So this is just, it’s significantly different.

11:20
It’s more complex, of course, but there’s of course it’s, while it may be more complex, you know, obviously, you know, myself and the team is we’re a huge proponent of Red Hat Open Shift.

11:32
It does a lot for us right now with IBM Maximum Application Suite.

11:37
A lot of industries, certain industries have compliance and regulatory requirements, right.

11:42
So you know, there’s very strict adherence to standards.

11:48
You know, cohesive does have ISO 27,000 and one obviously that’s a very strict, you know, compliance audited every year.

11:58
There’s a lot of controls in there to ensure that’s, you know, our, our number one priority is security, right, integration risks, I did talk about this a little bit, but you know, mass does integrate to many enterprise systems.

12:11
You know, weak security can compromise the whole ecosystem, right?

12:16
So data does flow between the systems quite often, especially when you’ve got a full enterprise deployment.

12:23
So that’s certainly something that you want to make sure that data in transit is secure, you know, and and that there’s no issues with that, right.

12:34
And then lastly, operational continuity, right.

12:37
So obviously you don’t want to disrupt your operations.

12:39
Security incidents are are of greatest concern and you certainly, you know, you do everything you can to not have that happen, right.

12:52
And then, so I guess my last point is there’s not, it’s a shared responsibility, right?

12:57
So when you deploy IBM mass, there’s multiple layers here, right?

13:03
So there’s a layer, there’s an application layer.

13:06
And of course at the application layer, you know this is generally handled by IBM, right.

13:12
So we obviously work very closely with IBM with everything that we do at the application and vulnerability level.

13:19
This is typically handled by IBM, you know, at the platform and the infrastructure layer that’s usually either handled by the customer or you know, potentially cohesive depending on the level of service that, you know, the customers do have, right.

13:36
So it’s a shared responsibility between application, platform and infrastructure layers.

13:47
Thanks, Jeff.

13:48
So I’m going to start a little bit by talking about the architecture of Red Hat Openshift.

13:55
So Red Hat Openshift, as Jeff mentioned, is now the platform for Maxima Application Suite.

14:02
So ultimately a lot of the components that we need to secure are ultimately within Openshift or kind of around the Openshift platform, right?

14:13
This diagram shows a couple of these areas.

14:16
You can see there’s a couple of points of external communication to and from the cluster shown on this diagram.

14:23
You’ve got on the left hand side here a load balancer, and actual fact there’s a few load balancers that are typically deployed with Openshift.

14:33
The one that’s shown on this diagram here is specifically for interaction with the API server in Openshift.

14:39
So for sending API requests to the cluster on the right hand side is the router.

14:46
And that router typically has another load balancer directly in front of it as well.

14:51
And that router is for handling traffic from the Internet or from your device via the Internet to the pods.

14:58
And the pods are containers effectively, which are running your maximum application suite instance.

15:03
They’re the micro services.

15:06
There’s also the the image registry on the bottom.

15:09
It’s a container repository and the nodes are pushing and pulling images for pod deployments from this registry.

15:16
OK, so maximum application suite is deployed using IBM images supplied by IBM via a catalog that we subscribe to.

15:26
And these images are ultimately stored in that registry.

15:28
So those three points become very important to secure right communication to and from your cluster.

15:36
And within the cluster itself, there’s a couple of crucial components as well.

15:40
So API server is one of the most important ones here.

15:44
That’s kind of your your central management point to the cluster.

15:48
So it’s a REST based interface and all of the operations will flow through that REST interface to your nodes and your pods and you know the cube light and the proxy on the right hand side there.

15:59
Ultimately, they will all go through API based interactions and then you have the etcd, which is your database for the open shift cluster.

16:08
It’s a distributed key value database and it kind of holds all of the cluster configuration and state data.

16:16
So a couple of very crucial components there that we need to think about can have the next slide please, Jeff.

16:24
So drilling a little bit deeper into ingress traffic.

16:27
OK, so the diagram here shows the typical load balancer types you would find with your Openshift cluster.

16:35
If you’re deploying Openshift on Azure, AWS, GCP, many other hypervisors and you’re utilizing the IPI installation approach, which is an installer provisioned infrastructure approach, effectively letting a Red Hat installer deploy your Openshift cluster for you, then the installer is going to deploy these load balancers on the screen here to your hypervisor.

16:59
OK, and there’s three load balancers shown.

17:03
Two of these load balances are external, which is the ones on the left hand side.

17:06
You’ve got the load balancer for the apps domain and the API domain, and you also have an internal load balancer for the API int domain.

17:15
OK, the external load balancers can still be internally published if you want them to be.

17:21
They don’t necessarily have to be Internet facing, but they are handling external traffic to the cluster.

17:27
That is their purpose, to describe these load balancers in just a little bit more detail.

17:32
So the apps load balancer is kind of your your main one for interacting with all of the applications on the cluster.

17:39
If you’re sending traffic to maximum application suite to maximum manage, you know, to cloud pad for data, any other components you might have deployed on your Openshift cluster, it’s going to be going through this apps load balancer, OK?

17:52
And from there, it will route traffic directly to your worker notes or potentially your infrastructure notes.

17:58
OK, the nodes, the, these nodes will run your ingress controllers as well.

18:03
OK, And then the API, external API load balancer there, that’s your, your route to the control plane.

18:11
OK, So the API server and the control plane and this load balancer can be used by open shift administrators.

18:18
It can be used by automation tools, by CICD pipelines.

18:22
It’s effectively given you an API endpoint for performing all open shift functions.

18:29
And for for those familiar with Kubernetes, port 6443 is also the Kubernetes API port.

18:35
OK.

18:35
So it’s kind of been very much adopted from that, that cube model, the the internal load balancer is specifically for internal communications within the cluster.

18:47
OK, So the worker nodes communicating with the control plane, they’ll speak via that internal load balancer.

18:52
They’re on the right.

18:54
So yeah, as you can see, very, very crucial to secure, especially those two on the left, right, there’s external points to your cluster.

19:02
Can we have the next slide, please, Geoff?

19:07
So drilling into data and transit a little bit and kind of our recommendations, recommendations around this.

19:14
TLS 1.3 is very much a recommendation now, OK?

19:18
It’s been stable for 6 plus years now, quite a while.

19:22
It has now become the recommended minimum for modern systems, and TLS 1.2 is not deprecated yet, but it’s going to be heading that way soon, and it’s now considered primarily for backwards compatibility support.

19:35
So if possible, you should really be trying to use TLS 1.3 for your data and transit wherever you can.

19:43
With respect to certificates, we I would recommend elliptic curve certificates.

19:49
Now they’re, they’re kind of effectively a much, much smaller bit size, but the way that they’re structured, they’re just a lot more performance.

19:59
And just because their bit size is smaller doesn’t make them less secure.

20:04
So ECDSA with SHA 384 is now kind of the most one of the most recommended ciphers now for SSL certificates.

20:13
These EC elliptic curve certificates, they have faster crypto operations, they have lower CPU overhead on your load balances and API gateways.

20:23
They’re very, very lightweight and they’re also very small footprint, OK.

20:27
So they’re kind of very, very robust and very light.

20:31
And then last but not least, automatic certificate rotation is now a heavy recommendation as well.

20:37
So very regularly now we see the kind of maximum certificate lifespan slowly being reduced.

20:45
In 2020, the maximum lifespan got reduced to 398 days for a certificate, which is roughly 13 months.

20:53
And Google and Apple are now pushing for 90 days certificates.

20:57
So there’s a chance that we’ll see 90 days certificates over the next couple of years.

21:01
And this obviously makes certificate rotation very important.

21:06
It’s going to be very challenging.

21:08
Keep it on top of manual certificate rotations across all of your systems if they have a 90 day shelf life.

21:13
So having some sort of automation script or some sort of tool with an Openshift, Openshift provides a certain manager tool for certificate rotation becomes increasingly important And a recommendation.

21:26
Next slide please, Geoff.

21:30
So just a little bit about the the do’s and don’ts with respect to ports and protocols.

21:37
I’m kind of covering here the the main ports and protocols you might think about with maximum application suite.

21:43
OK, so you have your HTP, you know, and HTPS ports.

21:50
Obviously HTPS is recommended for the entire cluster.

21:54
There’s really no reason to be using port 80 within open Shift.

21:57
There’s no dependencies anywhere in open shift on port 80 anymore.

22:01
So if possible, you should be using HTTPS with, you know, TLS 1.3 security standard FTP and FTPS.

22:11
So again, FTPS is very much the recommendation.

22:15
FTPS is just a secure FTP with an SSL certificate on it.

22:21
So FTP and FTPS is one of the ways that IBM allow you to publish customizations to maximum manage.

22:30
These days there’s four protocols, FTPFTPSHTP and HTPS.

22:36
Really I would only recommend HTPS and FTPS for file transfer.

22:41
If you’re transferring sensitive data to your maximum application suite cluster, you want to make sure that data in transit is secured OK.

22:50
SMTP.

22:51
So again, port 25 is kind of your unencrypted mail ports, OK.

22:57
The recommendation here is to go for SMTP with start TLS and use port 587.

23:03
Again, encrypting that mail data in and out of your SMTP server.

23:09
MAZ does permit port 25, but actually you’ll find that modern cloud providers, you know, providers like AWS for example, they will question why you’re sending data on port 25 to the point where they will even block outbound traffic on port 25 unless you explicitly request that from them.

23:27
OK, so very much recommendation now to switch to secured SMTP type communications and then LDAP and LDAP S, you know, for your authentication and your user syncs from a registry.

23:42
Again, LDAP S should always be used if possible.

23:46
Again held up with an SSL certificate securing that traffic.

23:50
If you’re transferring PII from an Active Directory to your maximum application suite instance, you’ve got users, usernames, emails, potentially addresses and phone numbers that are travelling in transit to your application.

24:03
You want to make sure that traffic is secure, and I’ve mentioned SFTP there as well.

24:08
SFTP is again recommended over FTP for publishing any files to your cloud, your hypervisor or your maximum application suite environment.

24:21
Next slide please Geoff.

24:25
So just to drill a little bit further into the etcd database which I briefly touched on, this database is not encrypted by default.

24:34
OK, so etcd was developed in the early twenty 10’s and encryption at rest was less of a standard in those days with distributed database databases.

24:44
Sorry, it is now of course and modern systems will enforce encryption by default.

24:51
You’ll find this with a lot of cloud database services, you know anywhere you look they will be enforced by default with some sort of symmetric encryption.

25:00
Etcd does stay non encrypted by default and this is basically to support backwards compatibility for existing deployments and systems.

25:09
Like I said, it’s been around for a while now, going on to two decades and there are a lot of legacy applications that still depend on etcd.

25:17
So now etcd encryption is an option, but it’s very much a recommended option.

25:22
OK.

25:22
And it does support 2 encryption types, a ESGCM&AESCBC.

25:30
AESGCM is the more modern and secure encryption type.

25:35
OK, so CBC is vulnerable to some known web attacks, for example chosen plaintext attack and chosen ciphertext attack and AES.

25:46
CBC encryption also cannot be written in parallel, IE cannot encrypt and decrypt multiple blocks of data simultaneously.

25:54
OK, AESGCM can be written in parallel, so it does support parallel encryption and decryption, which makes it a lot more performant on the etcd database and it’s not vulnerable to those aforementioned attack types.

26:09
And actually the fact that it’s the fact that it’s increasing the performance of the etcd is very important because remember, etcd is kind of the one of the hearts effectively of your Openshift cluster.

26:21
And if you do get performance throttling on ETCD, but you will impact your cluster, OK?

26:26
So a performance encryption type becomes important not just for security, but also for performance of your open shift cluster.

26:33
OK, Next slide, please, Geoff.

26:40
And then moving on to beta rest.

26:43
So a couple of recommendations here.

26:46
So first one is to deploy your infrastructure to private networks.

26:50
Always OK if you can, then ensure that your Openshift nodes, your control plane, your workers, your infrastructure nodes, and your databases.

27:00
If those databases live outside of your Openshift cluster, ensure these components are deployed to private subnets that do not have a direct route to the Internet.

27:08
That automatically makes them so much more secure than, you know, deploying into public subnets where they can potentially be accessed from the Internet.

27:17
Instead, there’s a couple of things you can do.

27:19
You can configure some network components, for example load balancers or proxies that can route traffic from public subnets to these private subnets.

27:28
So you can send traffic via a middle Ware network component to those private subnets to get to them from the Internet.

27:36
Or you can use AVPN, OK, obviously to access those components.

27:40
So very much a recommendation not to deploy to public subnets for the open shift cluster databases.

27:49
Then in terms of encryption, AES 256 GCM is now the industry standard for encryption at rest.

27:57
You will find that all modern hypervisors will support AES 256 GCM.

28:03
And in terms of what we should be encrypting at rest, well, we should be encrypting all of the maximum data.

28:09
OK, be about the maximum managed database which contains your maximum managed data.

28:15
That will be your SQL Server, Oracle or IBM DB2 database and also your Mongo DB database which is the back end for maximum application suite itself.

28:25
That will contain all of your user data and your licensed data.

28:28
All of that needs to be encrypted at rest.

28:31
At a high standard.

28:33
We should be encrypting our block storage as well, so Open Shift block volumes, and we should also be encrypting any persistent volumes that we create within open Shift.

28:43
So persistent storage for our containers needs to be encrypted.

28:48
Additionally, any backups that we take should be encrypted at rest also.

28:53
Of course, they contain your maximum data ultimately and logs as well.

28:57
Some logs can contain PII and we should be carefully encrypted logs as well, OK?

29:04
If you’re using various types of cloud storage, so I’m mentioning S3 on the slide here, you’re likely already benefiting from data at rest encryption through those.

29:14
S3 has SSSS ES3 encryption, and this is basically transparent encryption provided by the hypervisor, AWS in this case.

29:24
So the data is encrypted and decrypted automatically when it’s written to the disk.

29:30
OK.

29:32
Again, there are other types of other types of storage as well, Azure BLOB storage, for example.

29:38
All of those also already benefit from data arrest encryption out-of-the-box.

29:43
OK.

29:46
So yes.

29:46
And these encryptions should be typically done symmetrically.

29:50
That is the most performant way of doing them.

29:52
And they should use, again, AES 256 GCM wherever possible.

29:57
OK, Next slide please, Geoff.

30:02
OK, moving on to backups and disaster recovery.

30:07
So recommendation here is to take regular backups of databases and block server volumes.

30:14
OK.

30:15
So where possible, we should be configuring automated backups or backup jobs for the Maximo managed data, for your Mongo DB data, and also for your open shift cluster.

30:28
OK, I’ll speak a little bit on the operator that forms that function.

30:34
But additionally to automated backups, we should also be taking manual backups as well.

30:38
Anytime we do a configuration change that affects the open shift cluster or the database in some way, we should be taking a manual backup so we can restore that backup if something does go wrong.

30:51
And of course, those backups need to be encrypted, right?

30:53
So if you do have an automated backup tool, you need to make sure that when it automates the backups and runs the job, whatever backup it spits out is ultimately encrypted at rest.

31:02
OK.

31:04
With respect to automated backups, again, something that’s now offered by many cloud providers is point in time recovery backups.

31:13
So effectively, these are specific to your databases and they use redo logs to be able to get you to a certain point in time, typically within a time frame for a couple of minutes, OK?

31:26
So even if your backup was taken, you know, nearly 24 hours ago, as long as you have the redo logs on the database, you can use that backup to roll back to within a couple of minutes in time, OK, With respect to Openshift itself, there is an operator for backups.

31:43
It’s called OADP, which stands for Openshift Advanced Data Protection.

31:48
It is based on Valero.

31:50
Valero is an open source tool and OADP is kind of the Red Hat variant of Valero.

31:56
OK OADP extends Valero by first of all utilizing the open Shift operator models.

32:03
It kind of provides you a managed application type deployments and it also creates custom resource definitions, which are effectively templates for what open Shift needs to deploy to, you know, to to to effectively achieve a certain function.

32:20
As well as that it adds additional plug insurance to Valero.

32:24
So it adds snapshot plug insurance for the container storage interface.

32:29
That effectively allows you to manage your hypervisor backups directly from your Openshift cluster, which is very neat.

32:36
And it does offer integration with a number of the big hypervisors.

32:39
So AWS, Azure, GCP, VMware, kind of all the all the big ones.

32:44
There’s a, there’s an integration for that out-of-the-box.

32:47
So it’s very nice.

32:49
And the recommendation is to set this up and effectively just have it periodically running backup jobs on your Openshift cluster.

32:56
OK, the last thing you want to do is, you know, misconfigure something and open shift, make it safe and then realise you have to go ahead and restore your whole cluster from block storage backups, right?

33:08
That’s kind of a nuclear option, whereas OADP provides you a kind of, you know, regular rollback point for any open shift configuration that you might be working with with regards to disaster recovery.

33:21
Another recommendation is to replicate backups to ADR region.

33:26
OK, so recent example, right, We saw that problem with AWS that affected many businesses recently affected a specific region, which was a N Virginia region for AWS.

33:39
You know, there is maybe a chance that you would not be able to get to your backups in such an event.

33:44
And in that case, if you’re replicating your backups to another region, you know a physically separate location, then it does increase your chances of recovering your system in the event of serious kind of catastrophic failure.

33:57
OK.

33:58
And last but not least, it’s important to do regular disaster recovery tests.

34:02
So if you have backups, it’s important to regularly check that your backup procedures are up to date and current and they’re working as you’d expect them to and to kind of go through that process, get through the motions and kind of be, you know, be mindful that if you did have a, you know, serious disaster, you can get the whole system back using the backups.

34:22
Quite an important principle for some of the, you know, some of the compliance certifications is kind of a evidence Dr.

34:30
test.

34:31
OK, Next slide please, Jeff.

34:37
So VPNs is another thing I want to touch on briefly.

34:41
VPNs are crucial for communication with the private services that you may be deploying as part of your mass deployment.

34:49
These are primarily going to be your databases, but also the storage tier.

34:54
So if you’re using kind of, you know, external storage for potentially an RWX read, write, many type storage, so a shared storage that all nodes can read and write from, then you might want to connect privately to that as well.

35:09
Or alternatively, if your Openshift cluster is deployed without any Internet facing endpoints.

35:14
So there is such a thing as an internal publish with Openshift as it’s called, whereby the load balancers do not go into public subnets, They get deployed into private subnets only, OK?

35:25
And that way your cluster is fully disconnected from the Internet and then VPN becomes one of the options that you can then access your cluster and access all the data.

35:32
OK, very much the same recommendation for VPNs.

35:36
If possible, use AES 256 GCM encryption.

35:40
Once again, that is now just the industry standard.

35:44
Use also, if possible, Diffie Hellman Group 21.

35:47
OK, that’s a top recommendation for 256 bits symmetric encryption.

35:53
If the VPN gateway device that you’re using does not support 256 bit symmetric encryption, then try and use group 19 or 20, which is 128 bit encryption still still very secure.

36:08
And if possible aim to achieve a highly available active active setup.

36:12
OK, so if one VPN tunnel fails, you’ve still got data flowing through the other.

36:18
Next slide please Jeff, on to data segregation.

36:24
So, but one thing I would recommend here potentially thinking about is the benefits of single tenancy.

36:30
OK, so single tenancy gives you benefits in resource isolation.

36:35
So you’re completely isolating your resources from any other deployments.

36:40
It also gives you independent identity boundaries or I am boundaries.

36:44
OK.

36:44
So effectively, you have your own identity store, your own users that are not clashing with anyone else.

36:49
It also makes it a lot easier to perform compliance and auditing on your infrastructure if it’s completely segregated and network separation, OK.

36:58
So if you’re deploying your infrastructure, deploy it into subnets, OK, and carefully divide those subnets either across availability zones or some sort of, you know, different geographically separated areas.

37:16
Or, you know, also think about separating out your use cases and putting databases in different subnets to your application service, for example.

37:24
And that way you can kind of very carefully control your routing, OK?

37:28
You can have a lot more granular control.

37:31
The other benefit of, you know, having some sort of single tenancy setup is a kind of blast radius containment, OK?

37:38
So if something did happen, catastrophe happened, you’re only kind of affecting 1 deployment or one account potentially.

37:44
You’re not affecting multiple areas.

37:48
OK, next slide please, chef.

37:53
OK, so another important point is maintenance.

37:56
So there’s a couple of do’s and don’ts with maintenance.

38:01
If you’re doing routine maintenance, IE monthly, then it’s pretty safe to patch the following components.

38:06
OK, you’re open shift cluster itself specifically to minor fix versions.

38:12
OK, Not even minor releases, fix releases.

38:15
These will be the ones that are patching your bugs and kind of security vulnerabilities.

38:19
They’re not changing any functionality.

38:21
So for example, if you’re going from Openshift 418.5 to 418.8, that’s a fix, OK.

38:28
And if you’re going from 4:15 to 4:16, that’s a minor release.

38:32
And those need to be considered a lot more carefully.

38:35
Openshift operators, as long as you’re kind of regression testing appropriately, then it’s typically safe to patch those.

38:43
These might include your container storage interfaces, for example, operating systems on any kind of admin servers you may have, or kind of, you know, helper servers.

38:54
Also important to patch and keep those up to date.

38:57
Any monitoring and security agents who may have running database engines on the cloud, typically safe to patch and middle Ware.

39:05
OK, So your CAF code, for example, you know from messaging to and from the cluster, you should exclude mass and manage operator patches from your routine maintenance.

39:17
These need to be done under controlled situations and controlled testing needs to be applied to these as well.

39:23
OK, next slide please, Jeff.

39:27
So just to touch a little bit more about when we should be doing maximum application sweep patches.

39:35
First of all, they’re released in a major minor fix type versioning.

39:41
OK, so the major is your MAZ 9 currently up from MAZ 8 recently.

39:47
Your binder is your MAZ 9.0 or 9.1 or 9.2 is now scheduled for general release in June 2026.

39:57
And your fix is your, you know, 9.1 point one or nine point 1.2 for example.

40:02
OK.

40:03
And these fixes are specifically addressing bugs and security vulnerabilities.

40:08
So yes, it is recommended to keep up to date with the fixes.

40:12
But it is also important to have the appropriate regression testing in place when you’re patching as and manage.

40:18
There are times when a fix comes out and you do apply it and something may change in the system, OK.

40:24
And you do need to be wary of that.

40:25
And you do need to be cognizant that you need to appropriately test your systems and obviously put them through the pipeline of your non production environments, your dev and your test and your pre prod first before it gets to production.

40:38
OK.

40:39
Fixes are released as and when available by IBM and IBM specifically recommend controlling when updates are introduced at the catalog level.

40:49
So effectively taking out the old catalog Openshift and plugging in the new one, which contains the new versions of MAZ of Manage and all of the other IBM operators.

41:02
Thank you.

41:09
Thank you very much, Staz.

41:10
That’s some good information there.

41:13
OK, so in this next section I’ll be touching on a few different topics, starting on how we recommend implementing network security and access controls.

41:23
So now we’re starting with a proxy.

41:26
This sits in front of mass and Openshift and acts as a protective edge layer, absorbing, absorbing, and filtering traffic before it reaches the Openshift cluster or application load balances.

41:38
TLS 1.3 should be enforced as as mentioned earlier and showing that any data in transit is encrypted and secure.

41:46
Using a proxy is important as it hides internal IPS and restricts direct access to the back end services allowing only the proxy to reach them.

41:56
This will also make sure that security layer cannot be bypassed.

42:01
Access logs should be kept and captured and retained to provide visibility on traffic sources, patterns, and any potential non anomalies that may arise.

42:10
Finally, Geo restrictions can be used to control regional access.

42:14
They’re primarily used to block traffic from suspicious regions or only allow traffic from selected regions and to block everything else.

42:22
So for example, you could just allow traffic from the UK if your client only is going to be in the UK and they want everything else blocked out.

42:30
This will help protect against some basic attacks before they can even begin.

42:35
Because some places in the world will, you know, you’ll see more attacks from from those places.

42:41
It’s good to do that.

42:44
Next slide please, Joe.

42:47
So linking closely to our proxy is an application firewall.

42:51
This adds an additional layer of protection at the application level.

42:55
The firewall should inspect HTTP and Https://requests at the proxy layer before they reach the open shift cluster.

43:04
A good firewall would protect against Commonwealth exploits such as SQL injections, malicious bots and brute force attacks or some large or bad requests that could cause issues or disrupt mass.

43:19
Modern firewalls will also provide a range of managed rule groups which are preconfigured and automatically updated to defend against the latest threats.

43:28
We do recommend implementing custom firewall rules though, to ensure that legitimate requests aren’t falsely blocked.

43:33
Since we have seen this in some of our deployments.

43:37
We’ve had examples where cookies were too large and that’s automatically been blocked.

43:44
And that’s something that we, you know, don’t want to see and this, but it’s fairly unique to each deployment.

43:50
So this needs to be careful, considered carefully when you’re deploying.

43:56
Next slide please, Jeff.

43:59
So here is an example of a firewall dashboard.

44:02
This shows a number of requests, requests and the amount that have been allowed through and also blocked.

44:08
You can see that it also shows the location, the source location of the request here.

44:14
And then for the blocked requests, it can also show some of the Attack Attack types.

44:21
In general, firewall dashboards can provide some real time visibility to traffic and performance in general.

44:28
They will track metrics such as request counts, cache hit limits, latency, geographic distribution, top as well as top requesters.

44:40
You should be able to see 400 and 500 error trends in these these places as well.

44:45
With this, you can actually, you know, start to tailor your mass deployment so it can be as optimised and secure as possible.

44:54
Next slide please Jeff.

44:58
So this here is a high level diagram that shows user journey as they access open, shift and mass from the Internet.

45:05
So the user will start on their browser or mobile device.

45:10
DNS is then resolved by ADNS server which will direct traffic to the proxy firewall security layer.

45:18
As you can see, the proxy firewall will then apply multiple layers of filtering, inspection and security controls which should should block any malicious or suspicious requests.

45:31
Traffic that is considered legitimate and safe is then rejected, directed to the load balancer, and from there it is rooted on to Openshift and MAZ.

45:41
A setup similar to this diagram ensures that all incoming traffic is validated and secured before it ever reaches any internal infrastructure for a publicly facing application.

45:55
Next slide please, Chair.

45:58
So now to discuss authentication access for MAZ, Openshift and any underlying infrastructure.

46:04
We recommend that MAZ should be integrated with SSO which provides centralised user management.

46:10
For example, we use a client’s SSO which creates a shared responsibility model, EG they manage user identities and we ensure secure integration and access enforcement on our side for project team members or administrators.

46:26
SSO can be integrated with Openshift for cluster authentication.

46:30
This allows any privileged users to log in using their corporate credentials or SSO, which is quite convenient.

46:37
Groups are then assigned to these users in Openshift to restrict access to only the required resources they need.

46:43
Quite often so we’ll we’ll have project members only been have read only access and then any hosting administrators will be able to actually do configuration changes and and things that require a high level of privilege.

47:00
Typically they should adhere to least privilege access which would result in users only getting the exact permissions that they require for their tasks and nothing more.

47:11
We highly recommend that the number of true system admins is kept to a minimum to prevent unauthorized access or accidental misconfigurations.

47:19
The last thing you would want is someone accidentally changing a a value and then the whole application dying.

47:27
Especially in a production system and then for the underlying infrastructure tight access control should be enforced as a number one priority as if someone has access to this then they have full control over the system.

47:42
This again should adhere to least privileged access on a need to use basis only.

47:47
An audit trail should be kept for all login and session activity.

47:51
This is important so you don’t just get you you understand what’s going on in your own system.

47:58
And finally, to actually connect to private infrastructure, we recommend using a client VPN connection.

48:04
We use AVPN integrated with SSO.

48:08
This is a feature we have recently developed and streamlined technical troubleshooting activity as well remaining our strict access controls.

48:16
All VPN traffic should be encrypted with TLS and connections should be logged and monitored as well.

48:22
Next slide please, Jeff.

48:26
So an important part of all systems is monitoring and security and MAZ is no exception.

48:31
We recommend any MAZ deployments are aligned with security standards like ISO 27,000 and ONE or Cyber Essentials Plus.

48:39
Adhering to security standards like these enforces confidentiality, integrity and high availability of the open shift and mass systems deployed if everything is followed correctly for Open shift cluster security.

48:54
Open Shift doesn’t support traditional antivirus software like you’d normally find on Windows or Linux servers like ESET Crowd Strike.

49:02
Instead though, you can deploy premium tool.

49:05
You can.

49:06
You can deploy a paid premium tool like Open Shift Advanced Cluster Security, or you can deploy an open source alternative such as Snack Rocks.

49:15
Both of these continuously scan container images and workloads looking for any vulnerabilities or policy violations.

49:23
This is very important to have just so you know what is going on in your system.

49:31
Full system monitoring is also crucial to any mass deployment.

49:34
We need to know what’s happening at any given time so we can better prevent and react to problems that may arise.

49:40
Mass comes without the box.

49:41
Metric scrapers.

49:43
Metric scrapers which can be plugged into a monitoring solution.

49:47
Once a mass system is integrated into a monitoring stack, alerts should be configured with set thresholds.

49:52
These should raise alerts that so admins and support are notified of any erroneous behaviour which can then be investigated.

50:01
Next slide please Jeff.

50:04
So this diagram here shows a basic alerting stack.

50:08
So when a trigger, when an alert is triggered on the underlying infrastructure or MAZ or Openshift, Grafana will send out a notification.

50:19
Here you can see it’s feeding into Slack and e-mail channels.

50:24
This should allow it’s that they.

50:27
This will then ping notifications to the hosting team or it will ping notifications to a support team or you know, for instance, say you could create a ticket if a certain threshold is is it’s breached.

50:42
But this, this is important as you don’t want to be playing catch up.

50:48
You want to be be pre emptive with things.

50:50
You know, you don’t want to sort of suddenly find that your database has run out of storage, right?

50:55
You, you want to have alerts being a ping alerts being pinged at say 20%.

51:00
So then you can go ahead and you can, you can do some preventative actions that next slide please, Jim.

51:10
So this is an example of a final dashboard.

51:14
This is this is used using data obtained from the MAZ metric scrapers.

51:21
As you can see here, we have full visibility of statistics such as current DB connections, open sessions, pod CPU, pod memory, concurrent users and quite a few more viewing these dashboards and we can get a larger overview of the system over a long period of time.

51:38
This can be very helpful when troubleshooting problems or applying preventative changes to avoid a potential issue in the future.

51:46
So for this, you know, you can see if one one of the pods had an elevated CPU level, like you could go into that pod and you could check the logs and you could get a clear picture of what’s going on.

52:01
Next slide please, chair.

52:04
So finally we have audit logs.

52:07
So acquiring and storing logs is very important from a security and application support perspective.

52:14
Mass system logs should be uploaded and retained in a safe environment to show that to ensure that they can be kept and analysed if needed.

52:23
If logs are not stored externally to the JVM pod then they are lost when the pod is restarted which is important to know.

52:30
If they are lost then this can hinder root cause analysis of the problem and lead to an unclear explanation of what actually happened to that pod, which will lead to a higher risk of reoccurrence in the future.

52:43
All logs should be retained and protected in accordance with security compliance requirements and this ensures that they can be analysed and they provide an audible history of system and use actions if they are ever needed.

52:57
Thank you for listening to this.

53:00
So next slide, please, Jeff.

53:05
So finally, if today’s webinar on best practice security measurements for deploying IBM Maximum Application Suite on Red Hat Openshift sparked ideas for your organization, don’t stop here.

53:18
This is your opportunity to take the next step.

53:22
Whether you’re just starting to explore the secure deployment strategies or you’re ready to optimize your maximum application suite environment, we’re here to help.

53:29
We’re offering a free evaluation to assess your current server, identify how cohesive can support your journey towards a secure, scalable and future ready operations.

53:40
So you can scan this QR here to access the offer and start conversation.

53:45
Now let’s build a secure foundation for your Maximo deployment together.

53:53
Yeah, and I think so that’s yeah.

53:54
So I guess that concludes our session.

53:56
What we’re going to do now is open it up for Q&A and, and because this is a security session, we promise you that that QR code is safe.

54:08
I just want to point that out.

54:09
So it’s not going to lead you to any nefarious URLs or anything like that.

54:15
So, but that said, yeah, we can open up for questions.

54:19
I we’ll see if there’s any and then the three of us can answer if there’s anything that anyone has some additional, you know, questions, concerns or comments or what else to comment more on to add on to that, I just want to thank you guys so much for that informative session.

54:37
And so now we have a little bit of time for some questions.

54:40
So if you have any questions and haven’t done so already, please go ahead and enter them in the chat or question box in the top right hand corner of your screen.

54:49
And it looks like our first question is what is the best time and frequency for updating IBM Maximo Application Suite?

55:00
Yeah, I can.

55:01
I, I think a little bit, I think all three of us, it’s a good question for sure.

55:04
I think Staz did talk touch a little bit on the maintenance of Maximo application suite.

55:10
Will probably all three of us will kind of jump in and talk about this one.

55:14
But I think each organization’s, you know, slightly different, right?

55:18
So and you know, we have to remember that there’s different components here, right?

55:23
So you got to separate and start thinking about the platform components, but then also the application components because there is different release cycles for that, right?

55:32
So if you kind of zone in on the Red Hat open shift side of things, do you have to remember Red Hat open shift updates on a very frequent basis, right?

55:41
So Red Hat is going to update open shift on a weekly basis, right?

55:45
So they’re very frequent updates where you know, mass manage, it depends on what applications you have in there.

55:53
They’re a little bit less frequent.

55:55
Of course, they’re important.

55:57
But on the application side of things, there’s a larger impact to your business, right?

56:02
Because especially if you update manage, right.

56:04
So if you’re applying a manage a new manage release, it may be a minor dot release, but you do want to go through the proper procedures in the in the protocols, going through your development environment first Test and then production, making sure that you’re validating the application side of things right now, going back to the red hot open shift side of things, like I said, open shift does a weekly release schedule.

56:30
Sometimes it’s more frequent.

56:32
Even if they need to put something out there, you need to develop.

56:35
Every organization probably needs to develop a particular cadence on each of these two differences.

56:42
You know these two different items, right?

56:43
Because they are different, right?

56:45
So, you know, I, we, we certainly recommend getting into a cadence where your open shift updates and some of the platform components are more frequent because there’s certainly less of an impact from an application perspective.

56:58
And you want to make sure that the any, you know, any fixes, any vulnerabilities on the platform level are addressed as soon as possible.

57:07
And then you develop a cadence on the application side which suit is suitable for your business because there’s a lot more demand on, you know, your business updating mass and manage because of the regression testing that’s required.

57:23
Yeah.

57:23
And and just to add a little to that, I would recommend just subscribing to the kind of IBM newsletter and IBM Security Bulletin.

57:32
There’s a couple of kind of RSS feeds that you can subscribe to to get regular updates, Same for Red Hat, Red Hat feed as well.

57:39
And then if you know, if you kind of get notification that there has been a serious vulnerability on the product or something like that, something that may directly affect the business or you know, you’re looking for a bug fix, right?

57:52
You’ve been using maximum Manage and you’ve ran into a bug and you’ve, you know, you’ve kind of heard from the release notes that it’s addressed in version X, right.

58:01
Then that’s also a kind of, that’s probably the right time to start thinking about going through that cycle of, you know, taking it through dev regression testing and kind of moving it slowly up the pipeline to eventually production.

58:17
OK, OK, awesome.

58:23
Thank you that it looks like that is all the time that we have for today.

58:28
So any other questions that were unanswered, we will make sure to get back to you via e-mail.

58:34
And so with that, we can conclude our webinar.

58:36
I want to thank our speakers for joining us today as well as you, our attendees for listening today.

58:41
We have additional information available on our website in the form of blog posts, articles, case studies, and even brochures.

58:48
If you want to really reach out and discuss your strategic path forward, please reach out.

58:52
You can also reach out via our website.

58:55
That is a wrap for today’s webinar.

58:56
A short survey will pop up afterwards and we would really appreciate it if you could take a minute to complete it.

59:01
Your feedback helps us improve and choose the topics that matter most to you.

59:05
Jeff Ezra Estas, thank you again and I wish everyone a great day.

59:09
Thank you everyone.

59:12
Thanks everyone.