Are Your Automated Workloads a Security Nightmare Waiting to Happen?

Welcome everyone, and thank you for joining us for today’s webinar, Are your automated workloads a security nightmare waiting to happen? My name is Cody Gondyke, I’m from Fortra, and we make JAMS job scheduler, the enterprise job scheduling solution that centralizes, automates, and secures your critical batch processes.

Today, we’re going to bring up some of the most common security issues that could be lurking in your environment. We’ll talk about how common practices can cause problems for your business, and how you can address those security issues with an enterprise job scheduling solution like JAMS. If you have any questions, please go ahead and post those in the chat window that’s accessible through the panel on the right hand side of your screen. We will be monitoring those questions as we go and if we don’t get to your question right away, don’t worry. We will take some extra time at the end of our webinar to answer as many of those questions as we can. We do have a lot of folks in the call today, so we’re going to mute everyone except for our presenter. Let’s get started.

Workload automation security is our focus today, but it’s always good to know that here at Fortra we offer a suite of products, including the ones you see here. I like to say that with our product suite we really can solve any IT or security problem you might have. We are a global company with dedicated JAMS team offices in the United States, the United Kingdom in Australia that offer 24-7 JAMS support. Our support team has deployed JAMS to hundreds of customers worldwide, and you can see a small sample of our customers here.

It’s a general rule that you will interact with a JAMS customer today. Whether that’s watching a show on a Vizio TV, building, a bird feeder with Milwaukee power tools, maybe checking the forecast with Accuweather, or going for a run in Nike sneakers. And we also have an incredibly strong partner network, as you can see here. And at the JAMS team everything we do is for your success, from incorporating your needs directly into our development cycle to offering professional services and support services that jumpstart your automation, and you’ll be happy to hear that you can contact us after this webinar is over for a JAMS security review.

And now I’ll turn the presentation over to one of our rock star JAMS support engineers, Rob Newman.

Thank you, Cody. All right. Let’s talk about some common practices that organizations readily admit they do, but should not. How many of you have given elevated permissions or even shared the admin password just so your users could get something done? Users should not have access to username and password information other than their own for batch scheduling. Service accounts should be secure and available only to the users that need their use without exposing true usernames, passwords, or keys.

Do you give your users remote access to systems they shouldn’t be logging into? Providing users with endpoint information that allows them to log on to remote systems for ad hoc scheduling or modification is not a safe practice. You don’t want someone to accidentally shut down instead of just logging off a production server. Additionally, your operator shouldn’t need to know an IP address, just that their job is running on the ACME system server.

Is it possible for your report manager to run a job that updates the finance department statistics? Although certain users should and need heightened privileges within their department, it is crucial that their scope is limited to their department alone. Developers shouldn’t be able to kick off the production payroll process. Has your source code ever been inadvertently modified? Individuals should not have permission to modify or inspect source code that may contain sensitive information that is crucial to business continuity. Locking down source code access could be the difference between payroll running on time or running with an incorrect department number that delays your coworkers’ paychecks.

How often have your new users had to sit and wait for access to your scheduling system? How long after someone leaves can they still submit jobs? Administrators should be able to quickly adjust organization-wide access to scheduling utilities, and you should not have to find out two weeks later that a user is still able to log into a server and kick off a job several hundred times.

And, can you easily track down edits to your business processes that are no longer executing as expected? So, regardless of the size of an organization, there should be no guesswork as to who performed the actions that influenced the company from a scheduling standpoint. An audit trail will allow admins to quickly pinpoint unusual behaviors and any impacted systems by maintaining accountability records.

So your administrators should frame their workload environment to address each of these critical points. Defining credentials and service accounts, defining the remote systems the service accounts will access, dividing the workload into sensible, secure and organized compartments, locking down critical jobs, quickly onboarding, updating and off boarding users with integrated utilities, and following up and reviewing changes to your environment and critical processes as necessary.

Stop providing users with username and password information. We are all guilty of having that one text file that securely manages all the passwords for your service accounts. Users, jobs, when they log into systems with administrator credentials, they can impersonate administrator activity and modify things they shouldn’t have access to in the first place. JAMS encrypts in stores, credential information including password and private keys for quick and secure use. Admins can generate a unique encryption key for additional protection and users are granted appropriate access to specific credential objects for required use cases. So you can have your operators submit a database restore job without having admin access to the database.

You should not have users remoting onto end systems to kick off ad hoc items or to verify job activity. This exposes the entire system, as users are commonly logging in with elevated permissions and system hopping is never safe practice. You should allow your users to manage activity from behind both a firewall and with access control restrictions. They have alias names for machines and should be able to view and submit jobs without remoting onto those systems.

So JAMS allows central workload management of an infinite number of remote systems without users establishing remote sessions to those target systems. Any communication between scheduler and remote agents takes place over encrypted channels. Users can only target business processes and job scheduling on designated agents based on their access. So let’s not allow your developers to execute processes on your production servers.

JAMS administrators organize environment access using a customizable folder structure. While many organizations choose to organize based on department. You can configure your environment however your business runs. Individual folder properties regularly end user access through active directory user and group entries. Users can only interact with folders and objects within those folders based on their configured access, and JAMS has cascading security so the roles and access you set on a folder will automatically apply to all of the folders and jobs within.

A job is composed of moving parts. These parts are all sensitive in nature. They have credentials, machine IP configuration, and source code, which may expose your confidential information, application data or system access information. You should allow your users to manage or submit workload items without exposing the underlying critical information. This does not mean locking them out entirely, or the other extreme, giving them super user rights. When operators need to interactively run an ad hoc job, they should be able to easily follow pre-configured prompts containing dropdown lists and data validation, instead of exposing the source code. This safely bridges the gap between developers and submitters to harmonize overall productivity.

So, JAMS regulates exposure of your source code, host machine, and credential information, and job properties regulate job level control for end users based on their role, so your developers can edit a job source without giving them permission to submit that job.

Now there’s no need to reinvent the wheel. JAMS integrates with native services that you already use to manage the different permissions and access points to your network resources. You shouldn’t need to configure your security roles in yet another utility. Providing someone with access to your automation environment is as seamless as adding that user to the correct active directory group. JAMS inherits the rest. Most importantly, if someone were to leave the company, you definitely do not want to be searching around for what permissions they might still have. Worse, if you need to remove someone from the company, you want that done quickly. Once they’re removed from AD, they’re immediately revoked from any access to JAMS and your entire automation environment.

JAMS integrates with active directory users and groups or any LDAP provider. Users that are added to an active directory group during onboarding or role change immediately inherit permissions in JAMS based on their group. This ensures users have all the required permissions in JAMS based on their role. You can even use the JAMS jobs to automate the process of adding new users to their required groups.

JAMS keeps a complete revision history for all jobs, sequences, and other objects. Here we can see all jobs modified by Robert Newman with multi in the name, and we can see the exact date and time the changes were made. Administrators can quickly retrieve this information and filter by object type, AD user that performed the action, and/or the dates and times the action occurred. You also have the ability to quickly revert back to any previous iteration, providing a fully built inversion control system for your jobs. We can even automate reports for exporting or emailing audit information and user access.

So to recap, JAMS stores all of your credentials in an encrypted password vault, ensuring you never need to share your admin passwords again. JAMS manages all of your remote systems from a central location, eliminating the need for your users to manually connect to any machine, and of course eliminates the need to distribute machine connection information. Now in JAMS, you can organize and control access to your environment through the folder structure, which means you’ll never have accounting kicking off your HR jobs. JAMS has granular security controls for all of your jobs and business processes. This ensures that your operators never edit source code. And JAMS integrates with your preexisting security groups and roles, which means you’ll never have the surprise of a terminated employee running production jobs. And lastly, JAMS collects and reports on changes made to any JAMS objects. This ensures you will know who did what, when and where, and if bad changes were made, you can revert those changes.

Now that we’ve reviewed all of the JAMS security options, you’re ensured that you have all the tools you need to secure your environment and processes. I will now turn it back over to Cody. Cody?

Fantastic. Thank you, Rob. This has been really informative so far. I just want to remind everyone that we have the chat window over on the right hand side of your screen. I see some questions in already, but if you have anything that comes to mind, go ahead and post that and we will try to get to as many of those as we can.

And I apologize in advance for paraphrasing any of these. The first question that I have here, is there a limit on the number of security groups we can create in JAMS?

No, there’s not. And actually the security groups are from within your active directory environment, so you can set up any number of groups representing the role based access that you would like to provide within JAMS.

Perfect. The next question I have here, what did that monitor security check box mean?

So that monitor button was to allow your operators and administrators or whomever needs to have a holistic overview of everything currently happening within JAMS. They can see jobs that are executing or waiting on dependencies, or waiting to be released, and if they need additional control over those jobs, you can add additional role based security that will actually allow them to cancel the jobs, put the jobs on hold, or even reschedule the jobs.

Nice. The next question that I have here. Can we have different security roles for different JAMS servers?

Yes you can. So we can easily separate your dev, QA, and your environments based on role based security within each segregated separate environment. So you can have your developers having full control in your dev environment, minus maybe security changes in QA. They can have submit and testing rights, and in production they may only have inquire rights to see that the jobs have been promoted successfully and are running.

Great. I’ll handle the next question that I see right here. How can I make a JAMS job that changes users in active directory? So we can’t go over everything to do with that right now, but if you leave your contact information for us, we can have Rob or another engineer reach out to you and start talking to you through that process.

All right. The next question that I have here, we have a process that uses a student’s ID number. Does JAMS have something to keep data confidential?

Yes, we do. JAMS actually does not host any customer data. However, when you’re passing variables and parameters that may contain sensitive data, we will encrypt that data to ensure it is not visible to those that should not be able to see it. Additionally, all communications between JAMS scheduler and its agents are sent to through an encrypted channel, and all passwords are stored encrypted within the database as well.

Great. You guys have been giving us some great questions. The next one that I see here is one that I’ll take too, Rob. Can we have a security review? So the answer to that is absolutely yes. Just leave your information for us and we will start to schedule something for you to go over how your security is currently configured.

And that is that is it for, kind of the questions that are inside the scope here. So if you have a question that we didn’t answer, we will reach out to you and respond to that question right after this webinar is over.

So thank you again Rob. This has been really informative. And thank you all for joining us today. If you’re looking for more information on job scheduling security, and how you can prevent security nightmares, I encourage you to get in touch with us for one of those security reviews. And if you’re new to jams, remember you can start your trial at any time by downloading the latest version right from our main site at www.JAMSscheduler.com. And that’s going to give you everything that you need to get up and running, which includes ways to contact our rock-star support team members like Rob, and the links to training materials and security guides.

So thank you all again for joining us today and have a great day. Thank you, Rob.

Thank you.