How to Achieve PCI Compliance with an Enterprise Job Scheduler

Pat: Welcome to today's webinar. Today we're going to talk about PCI Compliance and how an Enterprise Job Scheduler can help you meet those compliance requirements. My name is Pat Cameron and I am with Skybot Software. I've been with HelpSystems for about 15 years and work with a lot of customers on automating their systems and scheduling, and I'm joined today by Robin Tatam. Hey Robin, welcome.

Robin: Good morning, Pat. How are you?

Pat: I am good, ready to roll today.

Robin: My title is Director of Security Technologies. I work for the Powertech brand, and for those of you who may not be familiar with HelpSystems, that's the umbrella company, so yes technically we are all HelpSystems employees here, but we have different divisions of the company. So Pat, obviously you work with Skybot in the automation team and I'm on the security team under the Powertech brand, but we're all part of the same happy family.

Pat: Exactly, and we have a lot of synergies between all the different products that we sell. Today we're going to be talking about PCI and the security standards and requirements you may need to meet at your company. So we'll talk about what they are, who is PCI, what some of those specific requirements are, and then how a job scheduler can help you meet those requirements. I think when we talk about automation and we talk about the documentation that needs to be created in order to prove that you're doing what you say you're doing, that's where automation can come in and help you out. Before we get started, I've got a couple of questions I'm just going to pop up on the screen. I just want to get a feel for who's with us today, what platforms you're running, and if you're using any kind of Enterprise Scheduler now. We're going to be talking about Skybot Scheduler specifically, but HelpSystems does have a number of different automation and scheduling tools. So what platforms do you run and are you using a scheduler now? A lot of people are using maybe cron or the Windows Task Schedulers or some individual schedulers. Do you have some type of an enterprise? Are you able to automate the reporting that you need to do for your PCI compliance? Just think if you've got any type of automation in place to help you with that, because I think gathering all of that information can be quite a monumental task and . . .

Robin: That's the biggest aspect for most people, right? Is collecting that data and then trying to disseminate it. That's always a handful of work.

Pat: Right exactly, so if there's something we can do to help you out with that, we'd love to be able to do that. So we'll take a look at how automation can help you meet those standards. Close the poll, and I should put the results up here in just a second, sometimes it takes WebEx a minute to get it together. Let's see who we've got. Can you guys see the poll results?

Robin: Yep, I got it.

Pat: Alright, so we've got some Linuxes, and some IBM i people with us today, some Robot people. Thank you for joining us. We appreciate that. Then there are people who have some other schedulers as well. We've got a few people reporting as 100% automated, fabulous, you should be doing a webinar today. Thanks for your input, we appreciate knowing who's out there. I’ll drive the slides, but Robin, I'm going to pass the speaking over to you.

Robin: Yeah absolutely, because what I'd like to do is just introduce the concept of PCI initially. I think having a basic understanding of what and who PCI is, is a starting point for us here. So the payment card industry actually established a Security Standards Council. It's a consortium of different card processing brands. I think most of us will recognize the logos on the slide here comprised of Mastercard, Visa, Discover, American Express, and JCD International. These guys got together and built out, for want of a better word, a set of best practices that they want people to comply with in order to ensure protection of credit card data.

We've been through several iterations now. Version Three, if we move forward here, is actually the latest iteration of PCI, and most of us are focused on what we call the data security standards or PCI-DSS. There are some other standards, but the DSS is the one typically referenced. It’s comprised of 12 different requirements as a foundation for that regulatory mandate, and each of those 12 requirements obviously has a lot of sub-requirements within it, but it's broken down into that. So what we're doing here is looking to deal with these 12 requirements by building out a response to the QSA, the qualified assessors, who are going to come in and potentially evaluate your PCI Compliance. Smaller companies may be dealing with self-assessment, so if you don't have QSA coming in, it may be based on the number of credit card transactions that you perform. You're going to fall into a different grouping of organizations, but once you get up to a certain threshold, depending on the card brand, you're going to be required to have a QSA actually attest to the fact that you are PCI compliant.

Each of the brands has its own different set of criteria, but there's certainly a centralized map. The PCI standards as a whole typically work on about a three-year life cycle. In fact, we've got some relevance here in 2015; the Version Three standards actually became active starting at the beginning of this year as the Version Two standard fell off, and we've got until mid-year to get that into an enforced state. So if you want to click forward there for me Pat, we’ve got some dates. Oh maybe not, they've fallen off there, but there are some dates. June 2015 is when we really need to be active on Version Three, and that's going to be the critical date that we're interested in.

One of the changes within Version Three that was very beneficial to most organizations is that the PCI Council went back and actually provided a lot of guidance and clarity on some things that were a little bit of a gray area prior to Version Three, meaning that instead of us having to try to interpret this ourselves, they allow us to indicate whether things are considered high, medium, or low risk, and we can focus on the high risk so we're not dealing with a lot of small things with the same risk level as perhaps what would be considered higher risk. So, having that clarity is going to make our life easier when it comes to certifying as PCI compliant.

Pat: You know what, let me pop back to that previous screen Robin, I think we do have dates up on there.

Robin: Yeah, there we go. So June 15 is kind of our kick-off there, where our Version Three requirements in essence now become a requirement versus a recommendation. So that was kind of the date to keep in mind. So you've got five, six months to get a good handle on the Version Three mandate.

Pat: Alright awesome, and that time will fly I'm sure.

Robin: Oh absolutely. As I mentioned PCI-DSS is comprised of 12 different requirements and what I've done is list them all there just for your reference, but we've highlighted the four or so that really have some interaction with the concept of automation in scheduling and things like that. None of the PCI requirements are going to spell out exactly in black and white, "Hey, click this and do that." So that's where the QSA comes in, that's where some of the self-assessment processes come in to help give us some direction, but these are the ones that we're going to focus on today.

Pat: Well, let's take a look at number six.

Robin: Yeah, requirement six here: “develop and maintain secure systems and applications.” As I said earlier, this has a fairly far reach into the organization much beyond automation, but we don't want to overlook the idea that automating processes is a big part of making sure your system environment and applications are secure. This may comprise things like change control. When we have application modification we want to make sure the implications of that are managed. We may use a scheduler to actually implement code from a test environment into production. We want to keep those environments separate. That's a big thing for PCI. We want to develop in a development environment and then ultimately put that up into production. We want to control the access to the production environment so we don't have programmers accessing that information because at the end of the day we need to be able to ensure the integrity of the database, making sure our credit card information is only viewed by those who have business requirements and we have standardized processes in place. Now Pat, do you know the leading cause of data breaches in 2014?

Pat: I do not, my guess is an insider instead of an outsider.

Robin: The answer is actually humans. Every single breach that we dealt with last year was sourced by a person, and that's really at the end of the day, what it comes down to. Computers are not going to breach one another. It really comes down the fact that there's some type of gain to be had by accessing this information, whether it's competitive advantage, whether it's a financial advantage, or whether it's just mischief. There's some gain to be had by somebody behind the scenes looking to achieve this information. So one of the things we want to do as part of maintaining secure systems is to try to automate and remove human interaction as much as we possibly can. Not just from the integrity standpoint, but also from a consistency standpoint. Having an automation solution can actually help maintain a consistent set of jobs, making sure those jobs complete successfully, and that's something that typically humans are going to struggle with a little bit. We're a little bit more inconsistent than a computer system, and having that as an automated procedure is going to be very beneficial to us in a production environment.

Pat: That's exactly right and you know we've talked about that in areas other than just PCI compliance too. Every time you automate you take away the possibility of errors, because everything's going to run in the right order, at the right time, etc. When we’re talking about an enterprise scheduler like Skybot, these requirements, as far as change control and moving from development or test to production, help automate that process. Let the computers do those moves. You can leave your test system wide open to any of your developers or any staff that needs to get to it, but make sure that you've got specific people based on what their job responsibilities are—maybe a business unit—that only has access to your production system. You want to make sure in whatever job scheduler you have that you can be very granular in the access that people have. Those of you who might be using cron or the Windows Task Scheduler, those schedulers don't give you the flexibility for the security that's needed. Also when providing secure systems, you want to make sure that you've got a high availability option and the database is replicated so you can assure the operations will be smooth in case of a failure. That replication needs to be in real time so you don't lose any history, which is part of your reporting option when you do some kind of a fail-over. Again, you want to automate that process of moving from test to production and be able to manage your users, maybe from a central point. Here you can see in our Skybot set-up that we can interface with an LDAB or an active directory server, so you can set those users up once on your network and manage the access that they have from that single point.

Robin: That's huge from a compliance standpoint: maintaining consistency. I will certainly issue a word of caution for those folks that do maintain duplicate environments. Make sure your data is just as secure on a test system, maybe you cleanse it as you move it from one side to the other, because if I'm hacking the environment I don't really care if I'm getting production data or if I'm getting a duplicate of production data, it's all the same to me. It's still going to be valuable. So we want to consider automation, not only for production, but for other paths as well so that again, we can limit the human interaction needed on all those sets of servers.

Pat: Robin, that is so true. I was at a user group this fall, and one of the guys gave a presentation on masking test data and it's so true. How many times have you been asked in an operation area: "would you copy these files over the test?" And that's what they're using, is production data, and he gave some great examples of how you can mask that data to make sure you're not storing copies of your production data that's not secured. I'm going to try and get him to do a webinar with me I think in March or April.

Robin: Yeah, that's going to be a hot topic. It doesn't do you any good to secure your production if you've got a duplicate sitting out there and in using a scheduler like Skybot to actually instigate processes, that will go out and perform some type of cleanse of the data, whether it's masking or replacing sensitive data with some bogus data before it's actually made available to programmers or developers.

Pat: Exactly, and that kind of feeds into this requirement seven as far as access to that card holder data. Like you said, whether it's in production or in test, it's the same data.

Robin: Yep, it sure is. So restricting access to that data is really needing to be done on a need-to-know basis. As a consumer of the data, we need to be able to prove a business case for why we're being able to see that data, and potentially manipulate it on a limited basis. We want to make sure anything that is accessing the database is doing so legitimately. We want to have some bells and whistles that allow us to be notified any time anybody accesses that data without coming through the anticipated access methodology. But again, having some type of enterprise scheduler is going to allow you to remove some of the human interaction in this conversation, so that when there are jobs that need to run, that will process data, or host things perhaps, we don't need to rely on somebody kicking that off and having access to the file in order to be able to run that process. The automation tasks can provide those necessary privileges and be able to fulfill that task completely without any type of ulterior motive.   

Pat: Exactly, and we're talking about security and being able to secure that production environment or any environment. That comes into play for this requirement as well, and restricting access to that credit card data or any other critical files that are on your system. If you've got an enterprise scheduling tool that's sits on top of your data and your script and it can be managed by a group such as Production Control, and allow them to have just access to the scheduler, they don't have to have any kind of security officer or root access because all of that can be done at the administrator level and then production control can just set up the jobs, move the jobs, and automate the processing of those tasks. They don't need access to the files, they don't need access to anything critical. Again, this shows where we need that clear division of duties between development and operations. I remember back in the olden days when I first started in IT, the developers at the hospital where I started kind of ran everything and it took a while and a cultural change to be able to get that line between development and operations and also a lot of smaller shops, sometimes those lines are blurred. So in order to be able to restrict those you need to be very clear in who has what type of access to what data and what options.

Robin: Absolutely, and requirement ten is definitely one of the biggest components that we're going to be able to help with when we talk about enterprise scheduling, because we need to be able to track and monitor all access to network resources and card holder data. So building out audit trails is definitely a big focus for me on the Powertech side of the business, but when we talk about automation, we're allowing the reduction of the amount of manual and human interactions with that sensitive data. And PCI talks primarily about card holder data, but there was also reference to critical system files, so the concept of what is important to PCI is more than just credit card data, it actually goes to the integrity of the machine. Making sure that any servers that are handling or touching any credit card data are secured holistically, making sure that the system configuration can't be tampered with, that perhaps will compromise the operating system, because that's going to weaken any controls that you have over the actual card holder data itself. So building out those history trails, knowing how your jobs are running, what completed successfully, perhaps if there are any jobs that are running out of cycle, maybe they run too long or too short. Having an audit trail over that type of environment is going to be beneficial in helping you ensure that the system is running in an anticipated state.

Pat: And having an easy way to get to that information and provide that for your auditors.

Robin: Easy is the key right? We want to make this so that the tool is doing the heavy lifting, we don't have to analyze it and babysit an environment and spend the whole day running reports and interrogating.

Pat: Exactly, and when the auditors show up, you don't have to want to spend a couple of days tracking that information and pulling it together into a format that makes sense to them. You want to make sure that your schedule will include an auto-log, so that changes to production are easily tracked and reported on. Skybot tracks every change that's made to any job in the system, and again we can schedule reports that will automatically email those every day, week, or month to your auditing team. You want to be able to see any exceptions to the schedule, any outages, failed jobs, or jobs that run outside of their schedule or regular time. You want to make it easy to track those types of exceptions. As you can see here the red or the pink highlights any problems that you have, so you want to be able to see those exceptions. You know, HelpSystems in all of its product lines, has always talked about managing your systems by exception, and that's true if you're talking about PCI compliance as well. It's those exceptions that are important and you want to be able to pull those out easily. We do provide a number of canned reports that you can schedule daily, weekly, or monthly. Our database is secure and you can create some custom reports from that database as well. Included in our canned reports are the audited history report, the job history report, as well as a security report that lists all of the users and what options they have access to. So usually what I've found with customers is between those three different reports, we will be able to meet the requirement that you have for your reporting.

Robin: There's some great dashboards in there too and I think one of the things we mentioned earlier is that if you have jobs out there that are designed to do some of that data cleanse, maybe masking or altering data, knowing that the job has been terminated by someone is obviously a huge piece of ensuring the integrity of the jobs we have in place. If someone starts tampering that that, it’s potentially an attempt to cover tracks and we need to be apprised of that. Having a scheduler report those things to me is going to be critical.

Pat: Exactly, you don't want to have to go looking for them.

Robin: Yep, so requirement twelve here, the last one, is actually about maintaining a security policy. Unfortunately, too many organizations are configuring their systems and addressing what they believe are the security requirements of the enterprise without having a baseline document that says how they expect things to be configured, and the analogy I always give is every spring I clean out my garage and invariably my teenagers are accessing my tools and moving things around, and come fall, the garage looks absolutely nothing like it did when I started with the cleaning.

Pat: Your kids use your tools?\

Robin: Yeah, they do and the kicker is that they don't put them back. That's probably the problem I have with it more than anything. I only have myself to blame, because I should have a written policy that says, "Here's what the stuff is used for and here are the penalties if you don't comply with those policies." Because at the end of the day when it comes to security, we've got to maintain some level of baseline so we have something to measure ourselves against. It's great to go and clean up, secure a system, to become compliant, but if you don't have ongoing validations based on what your directives are, then how are you going to know if you're no longer doing what you said you were going to be doing? So this documentation is a critical piece of that, not just PCI compliance, but pretty much any form of regulation is building that baseline of what we expect to do process-wise, and that way we've got some way of indicating if there's a non-compliance state. I know you guys are doing a lot of that on the Skybot side because having the tool help you with documenting your job flow is a critical part of building out that documentation.

Pat: Exactly and if you don't have that documentation built into your scheduler, then finding that can be a huge time consumer if you need to do that manually. You certainly might be running across 5 or 10 or 15 or 100 different servers, and if you've got to go to each one and pull out that exception, that can take up all of your time. Your policies for data security and the retention of that history have to be clear and your jobs scheduler has got to be able to support that policy that you've got put in place.

Robin: Well, let's face it, if something's difficult to do, what's the human tendency? We're not going to do it. What we find is, with a lot of customers who are using a tool that doesn't provide easy-to-interpret audit history, they're not in a good state as far as knowing what's happening and what they need to react to and that's definitely an area of improvement that they see when they switch over to a great automation tool like Skybot.

Pat: When you go through that automation process, those things get pushed off, because they do take up huge amounts of time that is precious to everyone these days, so they get pushed off until crunch time and then . . .

Robin: Right before the auditors walk in the door, the auditor’s not there to say, "I want to know that you looked at your system yesterday." They're there to know that you've been looking at your system all along. It's all about constant monitoring. At the end of the day, why do we put in automation tools? We do it to make our life easier and if we're automating things, but then spending all of our time instead monitoring the automation and generating reports and things like that, we haven't really accomplished our end goal, which is to allow the computer to manage itself. Let the tool generate the reports. Ultimately of course, you're going to be responsible for looking at those things and saying, "Yes, this is a problem or no it's not." But you shouldn't have to do the heavy lifting to get to a point where you're making a business decision from the data. A good tool should provide that data to you and allow you to simply sit back and say, "Yep, everything looks good," or, "There's an issue here I need to delve into. What's going on?"

Pat: Exactly, and how nice to be proactive, to set those reports up and proactively email them or send them off to your auditors so you're providing that information before they even walk down the hall.

Robin: That would blow an auditor's mind, wouldn't it?

Pat: It would, wouldn't it? We keep going back to these three points of audit, exception reporting, and role security. So if you've got a tool that makes those three areas easy to manage and easy to report on, you'll be able to work on other products and projects that are innovative instead of those mundane day-to-day tasks that can take up so much of your time. In closing, I'll talk a little bit about our Skybot Scheduler for those of you that are not familiar with it. We like to look at it as the hub of your operations area that can reach out with our Skybot Scheduler and automate jobs on different platforms and applications. We will pull that all together into a single screen, to a single pane of glass that you can monitor, that you can report on, that you can audit from, and set it and forget it. Like Robin said, you don't want to be monitoring that, you want to be notified if there are any exceptions, which is what Skybot does so well along with the other Robot products as well.

Well, that's what we wanted to talk about today on PCI and how a job scheduler can kind of help you meet those requirements. If anyone has any questions, we're happy to take those; you can send us a chat message over on the right-hand side of the screen, and we'll be here for a couple of minutes to see if you do have any. Rob thanks so much, I just love your experience and your expertise in the area. I know you've been doing it for quite a while now and I look forward to learning from you.

Robin: Thank you, just a couple of years.

Pat: Just a couple of years.

Robin: Well, I appreciate you having me. Again, we are definitely here at HelpSystems to help you with a lot of different aspects from automation to security and compliance and we appreciate the business from those of you that are already working with HelpSystems. Pat did record the session today, so if you joined late and would like to catch up, then feel free. We'll send that out to you typically within about 24 hours along with the slide deck, so if you have any questions after the fact, feel free to reach out that way and we'll be happy to answer those questions for you.

Pat: Thanks for joining us today and we'll see you all next time.

Robin: Alright, take care everyone.

Pat: Have a good day.