Upcoming Virtual CICS Meetings

SESSION TRANSCRIPT

[00:00:00.05] – Amanda Hendley (Host)

So I’m glad you could join us today for our virtual user group session. Today we’re talking CICS, and we’ve got a great program for you, on security. So let’s go ahead and get started. Assume everyone can see my screen, and if I otherwise, we’re just going to move forward. If you are having trouble with your audio or can’t see my screen, sometimes the best solution is to leave and come right back. I have disabled the waiting room, so you should be able to jump. And as a reminder, please keep yourself muted today, I might be breaking up a little bit. I’m getting a notice on my end. Someone just shout if I am breaking up too much and I’ll cut my camera. But if we haven’t met, my name is Amanda Hendley. I’m your host today for our virtual user group. And today we’ve got a great program. And before we get started, I’ve got a couple of things to cover. So, we’re going to have a quick agenda today. We’re going to dive into our presentation shortly. There’ll be some time, plenty of time, for Q and A afterwards. And during the session, and then before we leave, we’ll talk about news and articles and our next session, I want to thank our partners, Broadcom Mainframe Software, IntelliMagic and DataKinetics, for sponsoring this virtual user group.

[00:01:32.04] – Amanda Hendley (Host)

They make this possible. And if you are with a company that might be interested in partnership, you can reach out to me, amanda[at]planetmainframe.com, and I’m happy to tell you a little bit more about the opportunity.

[00:01:48.05] – Amanda Hendley (Host)

There is going to be a quick exit survey today when you close out of your Zoom. It’s two questions and it will just tell us how we did and help us plan for the future. Please do that on your exit. And I did want to do a quick plug, maybe Mark will talk more about it. But plug for GSE UK’s in-person conference, that’ll be this November four through seven. And it’s a great program, great event. I really enjoyed it and I believe registration is open now. And the agenda I expect we’ll see in a couple months. Mark, I know the deadline was just a week or two ago, and as promised, we’re ready to get started, so that was pretty quick.

[00:02:40.07] – Amanda Hendley (Host)

I’m excited to introduce Mark Wilson as our presenter today. I’m going to stop my share so that Mark can do his awesome. Mark is our presenters today. He’s a global thought leader and international speaker in Main, you’ve probably been at a conference where he’s been a speaker or keynote. He is Vertali’s director and has more than 40 years experience in numerous industries across diverse mainframe environments. He is the region manager for GSE UK and has been awarded the IBM champion status for the last four years. So, Mark, take it away.

[00:03:25.24] – Mark Wilson (Presenter)

Thank you very much, Amanda. I will try and put my camera on, see if that works. There we go. Try and put the glasses on so I can actually see what’s going on. Thank you all for turning up for this. I do recognize a few names on the attendance sheet, so welcome to everybody. We’re going to spend some time now just talking about CICS security at a very high level, what we call the basics. And I’ll explain why as we go, as we go through this. As Amanda mentioned, I’m the technical director at Vertali and also have a hand in all things GSE in the UK, from conference manager to region manager. So little agenda. Only four subjects, about 192 slides to get through. No money, joking. Not that many quick objectives, bit of CICS security and then a summary. If you want to ask a question throughout the presentation, unmute yourself and obviously pause if you want to or drop a message in the chat. Amanda will keep an eye on that for us. So, technical director of Vertali. I’ve been doing mainframes for a while now. I’ve just gone through my 44th year, so I started in May 1980.

[00:04:59.06] – Mark Wilson (Presenter)

So I’ve been at this quite a while. As it says, they’re just over 44 years in the little bit of spare time I do have. Those of you who know me will now have a passion for riding motorcycles. I did this little trip a short while ago now. 318 curves in eleven Mile, known as the tale of the dragon. Excellent. If you’ve never done it, great fun. Spend a lot of time restoring motorbikes and spending time with my grandson in the middle. And you’ll notice that the picture there, top left, a typical summer’s day in the UK. You can see the kids have all got the coats on and the boots and the hats because it was pretty cool for us. So just a bit of fun there. Yeah. New bike. The wife asked, are you going to sell the old one? Of course, the answer was definitely no, but there we go. So, intros out the way, objectives. The objective is today is to give you just that intro to CICS security. If you actually want to do this, start to finish, it’s actually a one, sometimes two day class in its own right.

[00:06:19.03] – Mark Wilson (Presenter)

There’s a lot of stuff that’s happened in the security space in the CICS in the CICS space over the last few years. Because of all the different ways that we now connect to our CICS based applications, we’ll delve a little into it, but the idea is to give you some information that you can go off and start looking at this yourself and doing further learning and further understanding of your CICS systems. Basics stands for customer information control system. It’s been around a long time. Transaction processing system. IBM has others such as IMS and Websphere, and there are other vendors who have other transaction processing subsystems. What you typically see is a CICS application at the front end with some kind of data or database at the back end. That may be Db2, it may be IMS, it may be a VSAM dataset, it could be anything that sits behind it. It might not even be a database that sits on the mainframe these days. Specialist infrastructure. And basically it’s a multi-threaded application environment. So, you can have multiple transactions and multiple programs all running at the same time. You can have these clustered together in what they call a plex multi region operation, or you can have inter system communication with them.

[00:07:54.07] – Mark Wilson (Presenter)

It really depends on the requirements of the applications. As I mentioned, provides interfaces to databases such as Db2 idms, IMS, and many other data backends. First commercial release was July 8, 1969. Now, this is a much easier question to ask when you’re in a room, because you can say, okay, hands up if you know what happened 13 days later. Well, 13 days later, they 21 July man set foot on the moon. And for all the cynics in the house I’ll put in there, possibly landed on the moon. So the good stuff, let’s get into how this stuff works. There are a number of things you need to consider from a security perspective when you look at the CICS’s infrastructure. And one of the key things you need to look at is a data set called the CSD CICS system definition. It’s a VSAM data set where lots of information is stored about how CICS is configured. And for those of you who know CICS, it has that relationship between the transaction and the program. So if you type in transaction a, b, c, d, it knows to execute program a 123456. That’s very, very useful information.

[00:09:21.04] – Mark Wilson (Presenter)

From an audit perspective, what I’d be looking for is who’s got access to it? How’s it backed up? If you had a problem, how would it be recovered? Anything that can access that data set or data sets, because you may have multiple CSDS depending on your CICS’s configuration, understanding how they’re secured and who’s got access to them is very important to understand. And we’ll talk about later some of the transactions that CICS provides to manipulate the data that’s actually in the CSD. Okay, we’ve got two transactions, CEDA and CEDB for updating. You’ve got CEDC for viewing. There’s also a batch program. So one of the things that we impress on people is making sure you protect the program, DFHCSDUP, and also those transactions, especially CEDA and CEDB, sometimes pronounced “Ceda” or “Ceda-B” or “Ceda-C”. Okay, Ceda is what most people use, the sit. Okay, the cities are table or a set of parameters. And you know, how do you describe that? So I put some pictures of dogs sitting down on the, on the slide just to hopefully put a smile on your face. But the sit stands for the systems initialization table and it defines the configuration for that particular CICS region.

[00:11:00.12] – Mark Wilson (Presenter)

Now some of the language with CICS can get a bit confusing because some people might say CICS region, some people might say CICS subsystem, some people might say CICS started task. But basically you have a task running on. The system can either be a batch job or a started task, and it’s either a CICS subsystem or a CICS region. So an instance of CICS, 99% of people I’ve ever come across run CICS as a started task and you’re have multiple CICS regions running. Some very rarely run CICS as a batch job. It’s not very common, but it can be done. The interesting thing about the sit is it governs the security interface and what I mean by that. The elements of security that are enabled, ACF2 and Top Secret have a similar set of parameters, but they are not all defined in the sit. They’re defined in different parts of ACF2 and top secret. If you’re RACF, I can explain all that to you. ACF2 and top secret. You’d need to go and have a look at the manuals for that. Understand how it works. We just don’t have time to cover it all here.

[00:12:16.21] – Mark Wilson (Presenter)

Okay, so the way the SIT works, it has a number of inbuilt defaults. It can have a module that’s created from the DFHSIT macros and you create a load module. Or you can pass the CICS subsystem, the CICS task some parameters via a SYSIN DD statement, or you can pass parameters on the PARM equals exec program equals part of the JCL. For the tasks. You can issue some console commands by issuing modify CICS commands, but you can’t change any of the security definitions dynamically. So if you want to enable something, you’ve got to stop the subsystem and restart it having major change. If you want to turn something off, you’ve got to stop the CICS subsystem, make a change, and then restart it. When CICS is looking for all these parameters, it work its way down this list. The last one it finds a is the one it will use. So concatenation like we would expect it to work. If you have a look at a standard, a simple ish SIT, this is what they would look like. It’s a whole bunch of parameters. Some of the more interesting ones are Apple ID equals as we’ve got here, VRTCICS.

[00:13:54.17] – Mark Wilson (Presenter)

So this is the VTAM application that the users would log on to. We specify what the CICS’s default user is and we specify a whole bunch of security information. SEC=YES,  SECPRFX=NO, XCMD=YES, XTRAN=YES. And various other pieces of the SIT. We’re going to explain some of these as we go through. It’s typically the job of the CICS systems programmer to maintain these. I have sometimes advocated that the SIP parameter should be put in a separate library away from those that are controlled by the CICS systems programmer, because these should possibly be maintained via change control or even by the security personnel. Bit controversial, you know, security control in the hands of the security folks. Um, but if you have the ability to change these parameters, you have the ability to change the security controls within that CICS subsystem the next time it is started. And I’ll explain that. So, you know, we talk about, you know, security these days and you know, I found this little cartoon. You know, believe me, it’s so much easier to do this online. It probably is for a, for a fair few organizations.

[00:15:24.21] – Mark Wilson (Presenter)

But back in the day, CICS had a whole bunch of internal tables. One of them was called the SNT, the sign on names table that controlled who could access CICS. IBM have long since deprecated all of that support. So everything’s done within your ESM now. RACF what we’re talking about today, but also ACF2 and top secret, and they all do pretty similar things. I’m a great believer in strong usernames and strong passwords, and I thought that cartoon was quite entertaining as well. So what does the external security manager, the ESM, do for us? Okay, and when we say ESM, we’re talking generically about RACF, ACF2, or top secret or something else. If you wanted to write your own, not recommended. But if you look at what the security product does for us, typically the bits that we’re interested in is who can log on to CICS, who can access a particular CICS transaction, and what sort of things do you want to protect that, that CICS transaction that calls a program would ultimately use, and that might be a particular file or a temporary storage queue, and who can also issue some of the command, the transactions we’ve got with some of the sub parameters, what we call command security.

[00:16:54.03] – Mark Wilson (Presenter)

So in our context here, RACF can do all of this for us. Okay, CICS security is quite a complex piece. When configured, it will call the external security manager. But what I want to underline there is the word when, because you can turn off security in a particular CICS subsystem, and I’ll show you that. Okay, as I mentioned, CICS used to have a mechanism for internal security. Not anymore. If you don’t use your esmond, if you don’t use RACF, you have no security at all. Okay, the book that you really need to go to is the, we used to call it the CICS RACF security guide. It’s now just called Security for CICS. When I went to grab the latest version of this manual the other day, it did say that this book has been stabilized. And it looks like some of the content from what was the CICS? RACF security guard is going to be moved into other books, which was a bit surprising to me because having all the security information for RACF and CICS in one manual was very, very helpful most of the time. So how does it work?

[00:18:28.12] – Mark Wilson (Presenter)

CICS will ask RACF a question. Okay. It uses a piece of code called rack root, and it might say rack route request equals verify. And verify is typically a. Here’s a user, here’s a password. Do they match? Off we go to the RACF database, through the router, through any exits we’ve got, and RACF passes back two CICS, a return code. The simple return codes are zero, eight, and four. Return code zero. The question that you asked me. Yeah. The answer is yes, return. Sorry, return code zero. Return code eight. Wrong. Either it’s the wrong user id or the wrong password, or the wrong passphrase or whatever you’ve supplied. The answer is no, return code eight. Return code four. Yeah. On a verify, very rarely seen, but could be CICS can also say, has Mark got access to this transaction? And again, it gets back one thing, a return code. The answer is yes. The answer is no, or I can’t tell you. I don’t know. I can’t make a decision. But the interesting thing here is, and the thing that we all have to remember is CICS is asking RACF a question. You can control what questions get asked, okay, you.

[00:19:55.05] – Mark Wilson (Presenter)

By turning off security. And I said, I’ll show you that. But you could also have a CICS exit in place that says, okay, the answer from RACF was no. But for this person, on this data and on this time, I’m going to change that to a yes. So it is, it can be quite confusing, but we’ll get there when we get through it. Okay, but what we typically use CICS for. Sorry, rack f four is sign on and sign off and access authorization. But here’s the thing I’m trying to say. Access is CICS, not RACF. Okay? Access denied is CICS, not RACF. All RACF does is give CICS the answer to the question. The CICS code has to turn around and say, oh, I had a return code eight. Therefore, Mark doesn’t have access to this transaction. Therefore, I am not going to allow him to use it. Okay. If you just focus all of your time looking at your ESM, looking at RACF to see what controls you’ve got, you may be missing a big security hole if you are not looking at your CICS configuration. So you need to look at it very holistically.

[00:21:08.22] – Mark Wilson (Presenter)

How is CICS configured? And what do you have defined in RACF or your ESM? You need to look at all of that. The city is where most of the good stuff takes place. Okay. This is where we see most of the controls. Okay. And it’s really important to understand the parameters that we’re interested in. There’s lots of them. We don’t have enough time to go through every single one of them today. There’s lots of great reference material out there. You’ve got the CIS benchmarks for CICS in a, in a mainframe environment. You’ve got the CICS security guide that we, we saw earlier. But the one thing that’s really important is when you are looking at CICS security, you need to strictly control who has access to the sit and who can update it, because with one change of a parameter, they can turn all security off. Okay. We do see some environments control access to the sit because it’s just a set of. It’s a. It’s essentially a parameter file being controlled by your change management software. Whether you’ve got ISPW, endeavor, Changeman, or anything else that’s out there or that you’ve written yourself. Okay, here’s a little stripped down sit.

[00:22:32.10] – Mark Wilson (Presenter)

And this is one that we use on our system. So we’ve got an Apple ID of VRT CICS. FCT=NO. We’ve got some good morning text GM text that says this is the Vertali CICS system. And then we’ve got another few things turned on and a few things turned off. Okay, the most important one here, okay, is, I hope you’ve all spotted it by now, is yeah, SEC=YES. If your sit palm says SEC=NO, no security checking is performed within that CICS environment. Anybody can use any transaction, anybody can use any program, and anybody can access any of the files that that CICS region has access to if they can write the code to do it. So the first question is, have we got security turned on or enabled for that system? All of your CICS subsystems, whether they’re production, development, or test, should specify SEC=yes. You should not have a CICS subsystem that says SEC=NO. Even if it’s just a test or development one. It’s just a bad thing to do and a bad habit to get into it. So should always say SEC=YES.

[00:23:52.21] – Mark Wilson (Presenter)

Once you do that, you can then control what parts of security within CICS you actually want to protect with RACF. In our instance here, most of the parameters that we’re interested in start with X something:  XTRAN, XTST, XPCT, X COMMAND. Okay? And they all really have, the majority of them have three things you can do. You can say XTRAN equals yes, I want to do transaction security using the IBM supplied RACF class definitions. More on that later. You can say XTRAN equals no. So there is no transaction security. Or you can say XTRAN equals and part of a racket class name. And I’ll come back to the part of it in a moment. Part of a RACF class name that you have defined yourself using today, the RACF CDT class. Some of them just say XCOM=YES. And that’s all you can do. Yes and no. There are several of these, probably about 14 or 15 you’d really be interested in to see what you can actually protect in a RACF environment. Most of the RACF classes, and this is very different for ICF two and top secret. Most of the RACF classes come in a pair.

[00:25:20.21] – Mark Wilson (Presenter)

And what we talk about here is a member class and a grouping class. And CICS uses these in a very inventive way. I personally think it’s a little confusing at times, but in an inventive way. But we’ll cover that a little bit more later. Okay, so if you were to look at a. Okay, so let me just back up a second there. If we’re talking about transaction security, I mentioned here that extra equals a part of a class name. What you do here is you use the second character through 8th character of the RACF class nine for transaction security because CICS mandates that the member class starts with the letter T for Tommy and the grouping class starts with a G. So what you end up with is if you’ve got your own production transaction class, you will call the class T for Tommy, the £, in this instance, prd trn, and its opposite is G prd trn. They come in a pair. And I’ll explain that a little later. But when you come here and you say x trans equals, you would say x trans equals prd trn. You don’t specify the t, you don’t specify the g because that’s mandated by CICS.

[00:26:57.19] – Mark Wilson (Presenter)

Okay, so you need a pair of these classes, as I mentioned. Sorry, did somebody say something? No. Okay, so as I mentioned, most of the sip parameters come with, you know, three options. No, disabled. Yes, enable this functionality, but use the IBM default RACF classes. Or as I’ve just explained, you can specify a class name. Not all of them are like that, just the majority of them you see here. I’ve listed a few of the IBM supplied classes. So you can see you’ve got TCICSTRN and GCICSTRN. You’ve got PCICSPSB and QCICSPSB. The P and the Q are mandatory. The A and the B on the started transactions is mandatory. The D and the E on the transient data queues, mandatory. They all work exactly the same. We cannot change the first character of the class name. That’s fixed. You’ve got seven characters to name your own classes if you want to get into that. And that’s important to remember when we get a little bit further on. Okay, so there’s a couple of different ways you can do this. You could have three CICS. Subsystems, regions, CICSPRD one, two and three.

[00:28:33.19] – Mark Wilson (Presenter)

You could have extra equals yes, defined in all of those SISTS. So what that means is they’re all going to use TCICSTRN for member classes and GCICSTRN for grouping classes. They could all be sharing exactly the same sick data set as well. But if, if you don’t specify, and we’ll come on to this in a moment, prefixing, you will have a transaction definition in there. And it may say you could use CEMT. If you give a user access to CEMT in this configuration, you would give him access to that transaction in prod one, two and three. So you have no way of segregating access between the three different CICS regions. That might be perfectly fine. That might be exactly what you want. Okay, you have exactly the same configuration. If you create your own names, you could have prod one, two and three, all with XTRAN equals £PRDTN set. So they’d be using T£PRD and G£PRD transaction. Yeah. So again, for that second one, if we define a transaction in there, we might define CEDA in that T£PRODTRN class and give certain users access to it.

[00:30:09.02] – Mark Wilson (Presenter)

They’ll have access to that transaction in prod one, two and three. Again, not a lot of segregation. Yes, this is how I often feel with this. The more you think about it, the more confusing it gets. But it does get simpler when you write it down. But you might want to share classes, but have dissimilar security configurations in each of them. So there’s a second parameter that you can specify called sec prefix. And sec prefix is set to either yes or no. So if you have extra equals yes and you have sec prefix equals yes, set. What you have the ability to do is prefix the profile in tCICStrn, so you can say ProdCICS cEMT and give somebody access to it. ProdCICS being the user id under which the CICS subsystem or CICS region is running. So you could have then DevCICS cEmt and have a separate cEMT, a different access list for those two CMTS prod and Dev. But you could also put an asterisk cemt in there and say, okay, I’m going to protect prod with this, I’m going to protect Dev with this. But the other systems that are sharing the same transaction classes can have this type of access.

[00:31:47.22] – Mark Wilson (Presenter)

So again, you’ve got some flexibility. I’m a great believer in keeping things really, really simple, and I’ll explain that and go straight into the next slide. Yeah, I personally wouldn’t use prefixing, and I think it can get very confusing because with prefixing you’ve got 13 character transaction profiles, eight character user id, the period, and then a four character transaction name. I prefer no prefixing. And individual RACF classes. But it is, yeah, really down to you. As I say here, I would use separate RACF classes and not use prefixing. Especially now we’ve got the CDT class, which means we can dynamically create our own RACF classes. But if you’ve got hundreds and hundreds and hundreds of CICS regions, you may not be able to do that because we would run out of RACF class names. More importantly, we’d run out of what we call posit numbers. And we’ll come on to that again in a minute. Yeah, it’s much easier now. Now we have the CDT class, but ultimately, you’ve got to decide what’s best for your organization. Choose wisely, because unpicking it and trying to redo it two or three years down the line without causing access issues can be, can be a bit challenging.

[00:33:15.13] – Mark Wilson (Presenter)

Okay, so transaction security back onto this. So XTRAN=YES, we use TCICSTRAN and GCICSTRAN as the two class names, or we specify our own. As we’ve mentioned, if you want to see what’s in a given class, you can use the RACF search command. If you’ve got Z secure from IBM or Vanguard, or written your own tools, or have a tool from somebody else. Yeah, search class, TCICSTRN. No mask will show you all the profiles. That should show the. Oh, sorry. Yeah, this only shows you the actual profile. So you would see CEMT, CEDA, CEDB, CEDC, the same for GCICSTRAN. If you want to look at who’s got access to them, you actually have to go in and list every single transaction. Now, you can do this with a racket search command. You can do it like this. So you can say search class TCICSTRN, no mask, that is, show me everything, no list, because I don’t want you to show me what the actual profiles are. But then use the CLISTt function to say RLTCICSTRN. And in between these two parens here, the search command will pop in every single profile that it finds in this TCICSTRN class.

[00:34:39.19] – Mark Wilson (Presenter)

And because we’ve specified CLIST, RACF will create a dataset called EXEC, typically your USERID eXEC.RACF.CLIST, and you can execute that, which will then list every single profile. Much easier to do if you’ve got a vendor product, but not all of us have access to those. Search command, very powerful for doing that in these. Okay. IBM ship a lot of CICS. Transactions that come with CICS, that enables CICS to work. They categorize them they categorize them into category one, two, or three. Okay. Cat one, internal use only. This is. These are the transactions CICS, uses internally to do its stuff never associated with the terminal. Okay. That slide is actually wrong now because it’s changed. It doesn’t. That goes like that. How about that? Dynamic changes because some of this stuff got changed in 6.1. So for the category one transactions, CICS no longer checks security to them. Now, I have seen some folks document the actual transactions in RACF.  They’ve defined them and put an Astra read on the access list so that you know, you know they’re there, you can’t do anything with them, you can’t do anything to protect them, but at least they’re documented.

[00:36:12.19] – Mark Wilson (Presenter)

Okay. Just have a little chat window going here. I’m just reading all the notes. So, yeah, I will absolutely share these slides with people, and I think the session’s been recorded as well. So you’d be able to go back and look at them. But I’ll gladly share the. Share the slides with people. So that’s category one transactions. Category two, these are the ones that you are really interested in. Okay? The category two ones are the CICS administration transactions. They are extremely powerful. Okay. You need to protect these, I would always say with unique, discreet, non generic RACF profiles, you must most certainly have a UAC of none of them. You should have very, very restricted access lists. Yeah. Some of the CICS systems programmers. And today, the way we’re starting to see people work, their standard CICS user id doesn’t have access to them. If they need to use these, they have to go through a bright glass process, pull an elevated access request, either pull or a different user, or get their access elevated to run these transactions. These are super, super powerful, and in the wrong hands, could cause all kinds of carnage to your CICS subsystem.

[00:37:43.12] – Mark Wilson (Presenter)

So, category two, when you look at the CICS security guide and the CICS documentation, it tells you what they are. You want to make certain you’ve got them all protected. Category three, everybody needs access to these. Again, exempt from security checks. These are things like the sign on transaction and some of the good morning stuff that CICS does for us. Again, some people define them to RACF just for documentation purposes. I personally don’t bother for CAT three. I sometimes do for one, but absolutely, your focus is on the cat two ones. Yeah, that’s what needs to be there. So I’ve mentioned member and grouping classes. RACF is a CICS, and RACF are big users. Or potentially big users of member and grouping classes. The easy way to explain it is from what you would define in RACF, but basically the same two different ways to protect stuff in CICS. Yeah, even protect the same resources. RACF and CICS do some quite interesting stuff with a member class and grouping class when it determines there is a clash. Okay, and I’ll explain that. It can be a bit challenging to find out who’s actually got access to something.

[00:39:12.14] – Mark Wilson (Presenter)

There are extra parameters you need to issue on certain list commands. Okay, so let’s just say you wanted to protect three CICS transactions and you wanted to give a RACF group called Warehouse users access to those transactions. You could come along and do an RDF and TXTRN INVC for one transaction, ORDP for the next, and STOH for the next. So you define those three individual profiles. You then grant the group warehouse users access to each of those. That, to me, really, really simple, really clean. Okay. Some people choose not to do that. Some people choose to use grouping transactions. So you defining the GCICSTRN a profile of your, your name, you, whatever you want to call it here, we call it where underscore trans. And basically you define the profile, and then you use the RALTER ADMIN command to add the three transactions, INVC, ORDP, and STOH, the same three that were here. And then you permit warehouse users to this where trans grouping class. Essentially what you are saying is if I give an id access to this transaction here or this profile WARE_TRANS, it’s got access to these three transactions by association.

[00:40:54.12] – Mark Wilson (Presenter)

So you can see there, I’ve got three RACF commands as opposed to six. But the fun comes when somebody accidentally or on purpose might define something in here. I might have defined imvc in here, and also put imvc in this where trans one. When CICS starts and asks RACF to load into storage, the process of rack listing the class TCICSTRN RACF detects it’s got its grouping pair. Its, it’s opposite in the grouping class. GCICSTRN, TCICSTRN. It says, right, we need to load them all up into storage, but it detects a clash because I’ve got INVC here and I’ve got INVC there. So when they’re loaded, it merges them. But it only merges if that resource name, in this instance, transactions, appears in more than one place. And this is where it becomes interesting. For the UACC of the merged profile, it uses the most restrictive. So if you’ve got TCICSTRN UAC READ and GCICSTRN wear TRANS UAC none of the merge profile will have a UAC of none. That may block some people getting access who used to get it from TCICSTRN or your intention was they’d get it from TCICSTRN UAC of read.

[00:42:38.24] – Mark Wilson (Presenter)

But this is and I don’t understand why I didn’t write the interface access list. If a user or a group appears in multiple profiles, the user or group is given the highest level of access. So if I’ve got a user on an access list with none on WARE_TRANS and a user on the access list of imvc in Tk tRN with read, the user’s going to get read. So you might think you’re blocking them by using the grouping TRAN. Not going to be the case. RACF merges them together. This is always difficult to understand, so there are things you can do to help. So we want to find all the profiles, member and group in the protector transaction called STOH stores in this example. So we list it. You do RLIST TCICSTRN STOH AUTH okay, it shows me all the information, didn’t see anything. Is it protected by a grouping profile? Okay, if you use this RESGROUP parameter. So again, look, notice you still list TCICSTRN STOH, but you add the RESGROUP, okay, and the RESGROUP tells RACF that. I want you to tell me if Stoh is in a grouping class profile and you have to remember to add this RESGROUP parameter on.

[00:44:12.09] – Mark Wilson (Presenter)

Sometimes this gets missed. People sometimes don’t understand how a certain user is getting access or being denied access. I can’t understand. Use the RESGROUP parameter, it will tell you you’ve got to look at the member class and the grouping class. It gives you all the information you need there and then. Okay, signing on. And I look at 99% of what most people do just from the get go. It’s transaction security and sign on security. All the other stuff is dependent on what else is going on in that CICS region. But we use a sign on transaction, you use the IBM supplied one, or you may customize yours to add some extra fields to do some extra stuff. CICS supports MFA. I’m just putting it out there. Multi factor authentication is a really good thing. CICS has only been supporting it for ten years and still people don’t use it. But we don’t use MFA to log on to TSO for our privileged users in some cases. But that’s just another thing. But you know, you really want to be logging on okay, and you type in your user id and password as if you were logging on to TSO, if you were logging onto any other mainframe.

[00:45:31.11] – Mark Wilson (Presenter)

Okay, there’s other stuff you can, you can do. You can use terminal IDs and console names if you were doing specific stuff in and around automation, okay. And you can protect who can log on to a particular CICS application. So if you remember in the sic you’ve got that AppleID= setting that whatever you set it to. So if you said AppleID=PROD CICS, you can go to the CICS RACF, sorry, you can go to the RACF APPL Apple class and define in there fraud CICS UAC of none and build an access list. That’s a way of protecting what users can even log on to the CICS system before we get into transaction security. So it’s a good way of, okay, they can get to the application and then they’ve signed on and now you can control what CICS transactions they’ve got access to. So yeah, multi layers of security. There’s one seat setting, which is kind of security related and always an interesting conversation. And it’s this one here. Sign on scope. Most people run sign on scope equals none. And what that means is you can actually have four screens or 432 70 sessions all logged onto the same CICS region.

[00:47:01.14] – Mark Wilson (Presenter)

Some businesses need that because they need to be able to have almost real time looking at different things as they’re going along. Sometimes you set SNSCOPE=CICS. You can only sign on to that CICS region once, a little bit like TSO, but you could also say you can only sign on to one CICS for the entire MVS LPAR or in a SYSPLEX. Again, it really depends on what your security requirements are. I personally like SNSCOPE=CICS. I think that works really well. But your business may not be able to support that. Again, when you’re looking worthwhile, seeing what you’ve got and asking the question, this is a good one. Default user default user is used by CICS to do security checks when it needs to test something before we have signed on. Okay. If you don’t specify a default user in your sit, CICS defaults to CICS user. The default user id you specify or CICS user should have access to nothing. You need a RACF  user defined for it. It needs to be protected. You don’t give it access to anything. Okay, nothing at all because it shouldn’t be able to be used.

[00:48:30.13] – Mark Wilson (Presenter)

I’ve actually done CICS pen testing and being able to do all kinds of stuff with the CICS’s default user because it had been granted access to all kinds of stuff. Okay, there’s a couple of, couple of things. You will have to have it, too. I’ve forgotten about this. Sorry. It will need access to the app lib because it needs to do that before it can present the sign on screen for you. And also the CAT ONE transaction, which has changed now, so we don’t need to worry about that. For those of you familiar with RACF, CICS, RAC lists, its classes. You don’t go to RACF and say, set our ops RAFLIST[TCICSTRN], you don’t do that. CICS does it for you. So what happens is when CICS initializes, it sees is the data space with my transaction security and all the other stuff I’m supposed to be doing loaded into a data space. Yes or no? If no, it builds the data space. So now CICS is using the entries in the data space. If you change that RACF database, you have to do a rack list refresh to take the profiles you’ve amended from the database up into storage.

[00:49:46.00] – Mark Wilson (Presenter)

So, yeah, you can often, if you forget to do the refresh, you could be looking at RACF saying, well, you know, Mark, I’ve given you access. Well, I’m getting a security violation. And then the, the penny or the dollar or whatever it is drops and you go, oh, do the refresh. In storage, profiles and database are now in sync because rat list refresh copies them from the database and overlays what doesn’t overlay replaces what’s in, in the data space in storage. Okay. Ah, there’s the rack listing and refreshing. The one good point here is that, that second build there, this, this is a non disruptive action because what happens is when you say RACLIST, refresh RACF and CICS, well, it’s CICS doing the call, but RACF, doing the work, builds a new data space, populates it, and when it’s ready, disables this one and points CICS at the new data space. So, you know, you, you, you need to be aware that that’s what happens. And you need to be aware that if you make changes to, to these profiles, in these classes, you have to do the refresh. Now here’s an interesting one, and I’m only going to briefly mention it, and that’s the thing called the posit value.

[00:51:13.08] – Mark Wilson (Presenter)

And a POSIT value is as a number assigned to a RACF class. So if you’ve got a TCICSTRAN and a GCICSTRAN, they will share the same POSIT value. That’s how you would design it. Okay? So they might share the same, they might have 120 as their POSIT value. If you use or create another class and give them the same POSIT value. If you refresh one of those classes, everything that shares that same POSIT value will also all get refreshed at the same time. What you do to one, you do to all. Okay. I have seen instances where people have been doing some work, building some new profiles in a racket class that shared a posit value with another class. Over here, the administrator has reset done a refresh. The profiles they’ve been working on have been loaded into storage, causing production CICS regions to fall over. Because certain CICS transactions, if they are not protected correctly, will force the CICS Sub system to fail. So you need to be aware of that. It’s not the easiest thing to find out. You actually have to go hunting around the RACF database and looking at the class descriptor table, but you need to be conscious of what goes on there.

[00:52:33.23] – Mark Wilson (Presenter)

There’s a whole bunch of other stuff that you need to think about. And the one that catches us out the most today is there are still a lot of internal application security used today. So you might protect the transaction, you might protect the sign onto the CICS region, but what appears on the screen and what options they can get. Maybe a table held in a VSAM dataset that’s maintained by Fred down in the user access team. Nothing at all to do with RACF. You need to be mindful of that. And one of the things we should be thinking about doing is migrating that to RACF, two top secret security. You’ll have all kinds of surrogate class profiles you’re going to need, you need to start thinking about starting transactions and command security, resource security. There’s a whole bunch of other stuff that you should be thinking about. Okay, the, the point of this presentation is to give you some things to, to look at and some pointers to where to go and get information. And the IBM website, I prefer. The PDF’s just a bit old fashioned like that. Don’t tell my daughters, but sometimes I print the manuals because I prefer to write over them.

[00:53:59.05] – Mark Wilson (Presenter)

But you know, there’s a lot to do. You’ll have a lot of research, understanding what you’ve got, why you use it, where it’s stored, how it’s used, all that kind of stuff is really important. Understanding how the CICS systems programmers control the sit and who can actually update them and are they protected properly? What about the CSD? I like to write bits of code to go and issue RACF commands and pull stuff in and write all my little checks and balances. If you’ve got one of the products, whether you’ve got a Vanguard or a Z Secure or something else like that, they’ve got great tools for writing reports. But you do need to think about checking this on a regular basis because one small chink in your CICS configuration security could lead to somebody having. Performing some very bad things on your system. Could be a denial of service, might be getting access to transactions that they, they’re not allowed to get access to and all kinds of things. So just need to be very, very careful and regularly audit these things. Personally, I’d be looking to, you know, run some kind of control checks at least once a week, if not once a month.

[00:55:18.24] – Mark Wilson (Presenter)

Yeah. Is everything how we think it should be? Even if it’s just the basic controls? Make sure you’re. You’re checking them. My contact details are here. As I said, we’re happily share the presentation at the end. I’m based in the UK, so just be mindful of times. If you’re in a really, really tight spot and you need to call, call. If nothing, feel free to drop me an email. I’ll be more than happy to answer questions. And Amanda, with that, I’m going to stop sharing and ask if there are any questions.

[00:56:03.09] – Amanda Hendley (Host)

If anyone has any questions, you can come off mute and we’re happy to. Or rather not come off mute. You can into chat.

[00:56:14.24] – Mark Wilson (Presenter)

Yeah, Amanda, there was, there was one about. Yeah, you know, it’s very complex. Do we think RBM will make it easier? No, I don’t think they will. There’s more and more facilities going into kics now to allow us to interact with different things on host. Off host. And we need to put more security into CICS rather than simplifying it. I’m a great believer in keeping it simple. I think you can keep it simple and do it really, really well. It’s when we make it complicated with member classes and grouping classes and all of this stuff, it can be. We can make it complicated ourselves, but documenting it, checking it and understanding it helps. So the questions are piling in now, Amanda, so let’s slide. You done?

[00:57:20.09] – Amanda Hendley (Host)

Do you want me to field them to you since they are coming in?

[00:57:23.08] – Mark Wilson (Presenter)

I’m just reading them, I think because we need to have in respect to security when it comes to definition between the system versus the city. So I mean it doesn’t really matter whether you’re, you’re passing the, the sit palms in Sisin or on the exec. It’s more important to protect for. Yeah. Where they are located. So if they’re in a proc library. Yeah, who should. Yeah. Who can update the PROCLIB? Because if the procliv’s got your CICS started task in it and your sip definitions. Yeah. Then who’s got access to the PROCLIB? If they’re in sit specific libraries, who’s got access to that? Okay Marcus, thank you. Right, posit values. Okay, POSIT values are attributed at the RACF class level. So you need to look in the IBM RACF documentation for the IBM supplied classes and also the rules we’ve got for which posits we can use. And if you’re defining your own in the RACF CDT class, you go and list the profiles in the CDT class and it will show you what the posit values are. There’s a IBM, on IBM’s GIT repository there’s a little utility called LISTCDT which can show you that stuff as well.

[00:58:55.08] – Mark Wilson (Presenter)

So that’s useful to have. That’s one of the tools I regularly download if it’s updated and keep it in my, keep it in my little hacker, sorry, hackers. My auditors toolkit and hackers toolkit as well. So that’s what posit is. It’s, it’s a number attributed to a racket class. But the rule is what you do to one class with a posit number you do to all RACF classes that share the same POSIT value. And if you don’t get it right, you can have some interesting results. Rogero not so much a CICS vulnerability in the fact that CICS was vulnerable, but what we have seen is applications being vulnerable. With hidden fields on screens that are presented or codes that aren’t published. You might see a screen that says enter one for this, two for this, three for this, four for this. Yeah, but if you enter 99, you get into an admin screen. We’ve seen those kind of application vulnerabilities and seen quite a few of those. So is there any benefit in assigning the same posit number to several different RACF classes? Yes. So if you’ve got multiple RACF classes for a CICS subsystem, and when you refresh one you want to refresh them all, then you might think about giving them the same posit value, but it’s usually only one or two, three or four classes wide.

[01:00:26.15] – Mark Wilson (Presenter)

It’s not. Well here’s 50 classes that all share the same posit number because it’s very unlikely you’re going to want to do the same thing to all of them at the same time. Now I’ve mentioned refreshing, but if you deactivate a class as well, and I’ve actually seen this done on a production system, somebody defined a new RACF class, a production RACF class that they were doing some testing to and gave it the same posit value as all the other production CICS transaction classes. They activated it. All the other classes were active. That was fine, no problem. They did some testing. They deactivated their test class. It then deactivated all the production transaction classes. Every single production CICS region fell over. We had a severity one system outage from one racket command. So yeah, there are some benefits, but there are some big gotchas for sharing posit numbers. And I’m going to stop there because I realized I was getting very excited and talking a lot.

[01:01:38.10] – Amanda Hendley (Host)

Any other questions?

[01:01:41.15] – Mark Wilson (Presenter)

I think we’ve got them all.

[01:01:45.05] – Attendee

Yeah, this is Mary. Can you hear me?

[01:01:47.11] – Mark Wilson (Presenter)

Yes.

[01:01:48.15] – Attendee

Yeah, just a quick question. I know what your answer is going to be but I’m trying to take the shortcut. Can you provide the CAT one, CAT two and CAT three transactions? Can we list that somewhere? We have to go to a manual.

[01:02:02.17] – Mark Wilson (Presenter)

The best thing is to go to a manual because they actually change CICS release by CICS release. So you want to be, you want to be looking at the manuals for the version of CICS that you are running? I think the latest is 6.2.

[01:02:17.01] – Attendee

Yeah, we’re at six one. We’re looking for.

[01:02:19.24] – Mark Wilson (Presenter)

Yeah. So the best thing to do is absolutely, I mean the IBM manuals are quite well laid out these days. A lot of it’s on web and you can get most of it in, in the PDF’s but you know, going up. It’s best to look in the manuals because that’s the most current and up to date version.

[01:02:38.12] – Attendee

I thought you were going to say that. Thank you.

[01:02:51.10] – Mark Wilson (Presenter)

I think we might be done. Amanda.

[01:02:55.21] – Amanda Hendley (Host)

Yes, I’m just screen. Thank you, Mark. And I know a couple people were asking. We do have the presentation. The video and presentation and transcript will be available in the next couple of weeks virtualusergroups.com. so you can check it out there for news. I posted some recent updates as recent as last month for some CICS news from IBM. We were talking about the IBM as a resource with the announcements. There are some updates on IBM Planet mainframe announced today that we’ve acquired the Cheryl Watson tuning letter. So that is news. And we’re starting a transition process. And we’re also partnering with Watson Walker and looking for writers for the tuning letter. So Frank Kyne is looking for someone to help support that initiative. So if you’ve got any interest there, great technical writers, or if you want to learn more about the tuning letter, you can reach out to me on our job board. I saw there is a position looking for some CICS talent based out of Charlotte, North Carolina, which was where IDUG was located a couple weeks ago. And they’re hiring for a mainframe operations manager. And as always at Planet Mainframe, we are looking for contributors for content.

[01:04:33.02] – Amanda Hendley (Host)

So you can follow that QR code or just go to planetmainframe.com and reach out. We’d love to have you. If you are not subscribed to newsletters for groups, you should head to virtualusergroups.com and sign up for those. And that way you get announcements for the next sessions as well as the recap documents as well. Just throwing up our social media. You’re probably already following us on LinkedIn or X. And one again, thank our partners, broadcom, intellimagic, and data kinetics for their support. And our next meeting. We will see you. I can’t believe that we feels like we’re in the middle of summer, and September 10 feels like it’s going to be in the middle of fall, at least in the northern hemisphere. But that is our next session tent with Azriel. Gross. So with that, we’re done for today. So thanks, Mark. That was great. And we’ll see everyone in a couple months.

[01:05:42.11] – Mark Wilson (Presenter)

Thank you, Amanda.

[01:05:43.18] – Amanda Hendley (Host)

Right. Bye.