IBM i DevOps TechTalk
Roles & Responsibilities #14

Ray Bernardi – Welcome to IBM i DevOps TechTalk, where we discuss key topics and questions with ARCAD experts. I’m Ray Bernardi and I’ll be your host today. We’ll be talking about roles and responsibilities within DevOps. You’ll also hear a little bit about how ARCAD Software controls roles and responsibilities within the software. As I said, I’m Ray Bernardi. I’m a senior solutions architect here at ARCAD Software.
I’m joined today by Alan Ashley. He’s also a senior solutions architect here. And Jennifer Novak, she is from our R&D department. And she is a software development engineer. Let’s jump right in. Jen, as an organization starts to adopt DevOps and DevOps processes, what are the security considerations that they need to be thinking about as they go forward?

Genyphyr Novak – Basically what’s happened over time is that initially DevOps was invented so that development and operations would have an easier time delivering software quickly and improving internal delivery, internal turnaround for new enhancements. But, as we see with a lot of incidents in the papers, the SolarWinds hack, things like that, where you’re actually used to be that everybody cared about their production server and securing their production server.
And the developers were left to do whatever they wanted. A lot of them had security officer authority and could do anything. But then, we started to see problems where you’d have somebody maybe, get made redundant or was let go and they were there for a couple of days and they managed to slip in something into the software or do you do something naughty.
And so security has just become a bigger concern. And then we also have a lot of regulations that have come through in the last 5 or 10 years where data privacy and these sort of things are becoming really huge. And so developers, should not be able to look at certain things like test data and they shouldn’t be able to access from their development server into production.
I think people cared about that before, but now it’s become pretty huge. And auditors will come and make sure that you’ve got separation of duties and things like that. So generally, they’re trying to give their users only what they need to perform their jobs.

R.B. – To basically move away from the wild, wild West into a little bit more of a organized…

G.N. – I mean, and I think you’ll find with the smaller shops, it’s still a little bit Wild West because if you have 1 or 2 developers, they pretty much do need every type of authority because you maybe don’t even have a system administrator. Maybe that guy’s the same person, but that’s usually a really small shop. And then anything bigger you’re going to start to have separation of duties really being needed and really putting an end to end at places like banks and insurance companies.
Then you get the mega security, with a whole team, a separate team that’s auditing internally and externally, auditing all the processes that happen from the production server, but also on the development side.

R.B. – Alan, I see you have a question.

A.A. – So Jen, you started talking about some of the separation of duties. And before we go that way, I do want to say thank you for mentioning access to test data, because I love that restricting that access, because it is important to realize that there the test side of things needs to be secured as well. Particularly coming from an anonymized world.

G.N. – Yes, definitely.

A.A. – So today we’re talking about some of the security that goes on with us. And as you start to make things a little bit more separated, you’ve got this nice metrics of who does what, when and how, who is really going to be impacted when it comes time to implement this granular security to the developers and ops and everyone else in the workflow pipeline.

G.N. – The person the most impacted is the guy who’s going to or the gal who will sit there and have to define the security, what they’re going to do on the server in a way, because they often they maybe never had to think about it in this way before. They know what they want their programmers to do.
They know that there’s a couple of guys that are the ones who always move stuff into production. These are power users, but they never had to put it on paper. And now they have to because we’ve to go through and say, okay, this person is going to be assigned a role.
So the impact is a lot of it in planning. And then, ideally you want no impact on your end users. There’ll be some because maybe somebody would be more restricted to what they used to be able to do, but they shouldn’t be restricted from performing their job. So in an ideal world, you’re not doing any impact on the people who are using the product.
It’s more on the upfront planning and the administration side as you implement your security solution.

A.A. – We’ve talked a little bit about how the people are going to be impacted. Well, I know that a lot of the driving factors behind security are government laws and policies and internal enterprise policies that are set up basically designed by auditors to go through and make sure that you’re following the rules and that comes into what is the right amount of security that comes into this.
How much does an enterprise look at government influence or internal policies to define the security? What’s really the right give and take and the right choice going forward?

G.N. – It’s dependent a lot about the size of your company and what kind of business you’re doing. I would say because some companies are going to come under a lot more regulations than others. In general, there’s a concept called the principle of least privilege. And that means you just give people what they need to do their jobs and no more.
It’s kind of the opposite of the way the smallest shops would be working, which would be, hey, you’re slack off or do whatever you need to do. And that’s potentially fine for a really small business, but it doesn’t work at all in a world where there’s a lot of hacking and sort of spying going on and things like that you want to only give your users start out with the idea of what is the task for this person? And in whatever software they’re using, whether it be ARCAD or their own ERP system or whatever, what does that person need to do to accomplish their job? And you try to give them, a role that bounds them to just those parameters.

A.A. – So within this toolset, is there anything that’s really going to help the administrator, the one that has to develop this and roll it out to his developer and his teams? Is there anything that ARCAD offers within this tool?

G.N. – Yes, there’s several things. For one, we have the concept of grouping all over so you can create user groups, and the user groups get assigned roles. And the roles go down to something called context. And that means your application. So if you have one role for programmer that’s authorized to a bunch of commands, many of those commands can be authorized for only a particular application.
So you can say this programmer is of this user group. For example, of programmers for my ACME, ABC-Application are authorized to do all these things. And I have a separate set of maybe only a couple people who are authorized to my secured ACME application. And these are the guys who can, because I’ve already had customers with their own internal security auditing software, and they only want 1 or 2 people to be able to develop that.
So even though they have different applications, we only need one role and we just authorize two different user groups. One gets authorized to do that role in and application ACME, and the other one gets authorized for the ACME and for another application, the secured ACME application, for example. So there’s that. And we also offer a set of reports, we offer history tracking.
So every time you make a change to your security, this is tracked in an internal log, and you can print out reports on that. And we have for developing it, you don’t always have to have the user in front of you to try something, a bunch of commands that allow you to check authority to a particular process.
So you just say check the authority of this user to this command, and it gives you an answer. And it doesn’t just give you a yes or no answer. It’s possible to get a very detailed answer. So for your customer, you would have maybe like five roles and you don’t know where is this authority coming from, you can have it print out to the screen, every single place where it’s looked to see where the authority comes from. And then it will show you. It’s getting authority from this role and this role. I’d authorized him to that, but he still has authority because I forgot to authorize him to this. So that sort of tool that we developed really is helpful.

R.B. – So, Jen, correct me if I’m wrong here. ARCAD had always done roles and responsibilities. We’re just getting much more granular now. Is that what’s going on here?

G.N. – ARCAD has always had roles, so that part is good. And it’s part of why people have always chosen our software in the past. But in the past, our roles were more fixed. They had a few options for how you could tweak them, but basically we had like a programmer role, a librarian who was sort of in charge of deciding what versions of your application would be released when and where it would go.
You’d have a database administrator role that would allow someone to make a change to the database or not, even at the programmer level. That was an optional role. Some people didn’t need it and other customers used it a lot. Application manager who is the person who says when it goes into test cycle and that sort of thing project leaders.
And we also had tester and analyst roles in the product. So in version 24 of ARCAD, we’ve had a lot of customers wanting to restrict in the past very specific things. And you couldn’t do that with the fixed roles.
So we’ve redesigned the security, but at the same time, because we have a huge customer base, we wanted to make sure that anyone upgrading would not be impacted by this new security paradigm. So we turned it almost every ARCAD command into what we call features, which is a securable thing. So every user, who needs to run that command, needs to have a role that will authorize them to that.
And, the roles have inheritance and things like that. So but we deliver out of the box roles that are matching the old roles that we always had in the product. So as you upgrade, ARCAD goes through all the users that exist and looks at what they were marked as in the software and assigns them the corresponding new roles, and then, after that, you have a choice of staying like that, which is perfectly fine.
Or you can customize those roles. And if you’re a new customer, the base installation will install using the old roles as the default. So, normally we have a screen that’s work with users screen, and you assign a user a key that gives them a programmer authority in the product as a software key, it’s a seat.
And as long as you have that key, you’re also assigned a default role of a standard programmer that we’ve designed to match our old standard programmer. But if you don’t like that role, you can choose to copy it with inheritance so you can inherit the previous role. I could explain that later if you want to. There’s a more technical side of it, but, anyway, you can say, oh, instead of the ARCAD provided role, I would like all my programmers that I give a license key for programmer to be my local standard programmer role that I’ve designed. And, you can tweak it. So our old administrator role is a super powerful role and it can do everything in the software.
And now you have customers who are saying, okay, now I’m going to separate that, and I’m going to make a role that can administrate security in ARCAD and another role that can do changes to how the applications, parameters would work. So you’re doing separate. You can do separation of duties now even with the administrator role that you previously could not do.

R.B. – I assume you can even do restrictions on programmer levels. Things like you can’t edit a macro or something like that, but you can run them.

G.N. – Yes. So in the past, it was kind of an all or nothing with macros. And now you can have people who can edit macros very specifically and you can see it. The other really good thing about what we’ve done is that it is self-documenting system. So you have screens that list every single command that’s in a role.
So you know exactly what people can do. And in the past when you gave somebody a programmer role, it wasn’t super clear from just looking at that X in a box. What did that actually mean when the software ran. And now you can see it because everyone has a command listed, and then you can go look at the help text on the command.

R.B. – So you try and write down the single command level, you can see what everybody can do is in the back.

G.N. – Yes. And the commands as we call them now, features are grouped. So there’s a parent feature. So for example, and they’re grouped in workflows in a logical way for DevOps. So we have a workflow that allows you to do things with the repository changes to it or your software repository, another one that only allows you to view it.
And so, you can very easily see just with that parent feature level, and then you can expand it to see all the individual commands underneath it. What does that mean when I give somebody this authority? What are they allowed to do and not allowed to do? So that’s really good. And a lot of the customers that have so far started implementing their own customizations have chosen to quite often remove the ability to edit macros, remove the ability to launch remote commands on another system.
And they’ve separated the way that, the software updates are put on to other systems so that the individual user no longer has that kind of authority, and they give it to like a robot user or sort of a batch user that ends up doing those software updates, on to other systems. And so it makes all of that much easier.
And it’s also much easier for the administrator to show an auditor what it is that you’ve done on your system.

R.B. – That’s going to make auditors happy, that’s for sure.

G.N. – Yes. We’re pretty excited about this. It’s really a game changer I think for ARCAD.

R.B. – It sounds like it. Jen thanks for joining us today. I really appreciate it. Let me summarize just a little bit here. Sounds like what we’ve done is we’ve really expanded the ability to define roles and responsibilities within the ARCAD system. Of course, the roles you already have are maintained. They’ll carry forward, but now you can customize right down to a individual level and right down to a feature or a command level for that individual.
So that’s really going to allow you to get the flexibility that you need whether your organization be a small one or a large one. And don’t forget we’re adding reporting to this and so on to make the auditors happy. And that is always a plus. So thanks for joining us today and hopefully you’ll join us for other techtalks.