Identity Management Series – HR as a Source of Record Part 3: Transfers – Security Catalyst
1

Identity Management Series – HR as a Source of Record Part 3: Transfers

In the last article, we discussed the HR considerations for enabling auto-provisioning/auto-assignment of tasks for new hires. Now we’ll address transfers.

Employees are, by definition, only hired and terminated once, but they can undergo many transfers during their employment at a company. Transfers are the biggest part of the employee lifecycle because a transfer can happen at any time for any reason.

In many cases, transfers can’t be predicted. Sure, there are union jobs where step increases happen like clockwork, but in non-union jobs, promotions, demotions, and outright job changes can happen pretty much any time.

As I mentioned in this month’s introduction, there are two key challenges with transfers:

  • The HR system can’t notify identity management if the old access will still be needed in the new role (maybe just temporarily)
  • What’s considered a transfer from an access perspective may not register as a transfer from an HR perspective (I gave the example of Accounts Payable and Accounts Receivable both being positions in the same Accounting department).

These challenges are compounded by the fact that properly managing transferred users’ access is a key control for a variety of audit regulations, including SOX and PCI.

So let’s take a look at how HR data can be manipulated to feed identity management the right information to handle transfers.

Timing of transfer vs. timing of access change

Ultimately, to fully automate the transition from old job access to new job access, the user recertification workflows have to be in place in identity manager (we’ll talk about this in August), and roles and rules have to be properly defined in role manager (we’ll talk about this next month).

The groundwork laid now will make it easier is to spend time learning how transfer information is entered into the HR system. How does the system find out about transferred users, and when is the information typically entered into the system (consistently before or after the actual transfer date, and if after, how long after)?

HR *should* care about the accuracy and timeliness of transfer data since this could impact pay. If they’re sloppy about this, hopefully they’re working to fix it. Maybe the questions of the identity management team will provide extra incentive to get their cleanup done.

Another proactive step that can be taken, although it is not related to the HR system, is to find out what is acceptable in terms of access retention. For example, if there are segregation of duties concerns with a transfer, are there allowances for job transfer, or are there absolute rules that one type of access may never be granted while another type of access is in place? If a clean break is expected most or all of the time, this actually simplifies the workflows tremendously.

HR transfer vs. access transfer

This is the hard part, and what makes it so hard is that it requires the identity management team to become knowledgeable about the inner-workings of the HR database structure and data flows.  But for that to happen, the identity management team needs to get the HR administrators up to speed on how identity management needs to use their data. You will be talking in access terms, they will be talking in HR terms. You’ll be using the same words, but they have different meanings. So when you think you’ve come to an understanding, you may well find out that you didn’t. The best way to avoid such misunderstandings is by conducting a series of good old-fashioned whiteboard sessions – in person (if possible), with sleeves rolled up and some snacks to keep the energy flowing.

The goal of this exercise is to identify how to accurately flag transfers to minimize both false positives and false negatives.

For example, if a user’s job code changes, that’s a clear indication of a transfer. But, clerks in Accounts Payable and Accounts Receivable might have the same job code because from a payroll perspective it’s the same job level in the same department. So if the only criterion is job code change, critical access transfers could be missed.

But what if you add manager to that? Then, a user with an unchanged job code might be flagged as transferred because their manager has changed. But is that because the previous manager quit and the employee got a new manager, or is that because the employee moved from Accounts Payable to Accounts Receivable?

There are two HR elements that always indicate an access transfer, but each can lead to false negatives on their own because access transfers can happen within these elements:

  • Job code change
  • Department change

There are three additional HR elements that *could* indicate an access transfer, but each can lead to false positives – sometimes these elements change administratively without affecting the employee’s access needs:

  • Manager change
  • Cost center change
  • Location/facility change

The trick is working with the HR team to figure out what combination of the above attributes will yield the most accurate results on a consistent basis. Leverage their expertise to understand what could happen in the system, and work through the scenarios. If as an organization you’ve already mapped out segregation of duties rules, be sure to walk through those specific job functions and determine how transfers between them can be identified in terms of the HR data.

In complex organizations, there will be a subset of HR transfers that cannot be accurately addressed from an access perspective in an automated fashion. At a minimum, if the underlying transfer-to or transfer-from job functions can be identified in some way (as a combination of attributes), workflows could be designed to trigger a task to HR to manually indicate whether a transfer really occurred or not.

The good news in all of this is that not *all* job functions need to be analyzed here – only the ones with relevant access. By relevant I mean either complex access for large systems with high turnover (this is where automation brings ROI), or access that the auditors care about (so it has to be right).

Make no mistake – it’s a lot of work to get transfers set up, and we haven’t even gotten to the part about configuring identity manager. We’re still in the data mapping stage. But, this work has a big payoff – being able to automate transfers saves end users and their managers time (from not having to manually submit transfer requests, getting access cut off too soon, or getting the wrong new access), it saves the access services team time when the auditors come knocking (in terms of providing evidence), and it will definitely make for cleaner audit results (which could save money in terms of fines and penalties).

In the next article, we’ll end the lifecycle by looking at terminations.

Sharing is caring...
Ioana Bazavan Justus