Manage Learn to apply best practices and optimize your operations.

Best practices: Identity management - Part 2

In part 2 of Best practices: Identity management, experts Kelly Manthey and Peter Gyurko discuss optimization through case studies involving a Fortune 500 bank.

Topics include:

  • Getting there: Optimized (0:44)
  • Seperation of Duties case study: Fortune 500 bank (3:18)
  • Seperation of Duties case study diagram (4:10)
  • Closing thoughts (7:08)

Related videos:
Best practices: IdM - Part 1
What is identity management
Identity management maturity model

About the experts:
Kelly Manthey is the Vice President of Consulting Services at Solstice Consulting, a Chicago-based technology management consulting firm that helps companies be more successful through business process optimization and custom software development.

Peter Gyurko is a Senior Consultant with Solstice Consulting. His areas of expertise include custom application development, agile adoption with scrum, and Identity and Access Management.

Read the full transcript from this video below:  

Best practices: Identity management - Part 2

Kelly Manthey: So, as Peter was talking about, established, he mentioned that you
were going to be there for a while, and you will. Jumping from phase to
phase is not something that happens every year. In phase one will be
developing, and phase two, next year, will be fully evolved. Really, what
these definitions are is, what it means to your organization. [What] it goes all
the way back to is, "What's your organization's appetite for risk?" Maybe
being in, what's considered, developing, having some ad-hoc processes in
place, having some technology in place, maybe that's good enough. Maybe
that is something that your organization is willing to accept.

There is no right answer here. There is no silver bullet, there's no, "This
is the standard you should be at, and that's it." It's what is right for
your organization, depending on your organization's size, the business that
you're in, the regulatory requirements that govern what you do. This is all
about using your audit team as part of your evolution, of your identity
management strategy. Letting them have a seat at the table as well, to help
you guys come up with together, How are we going to develop our internal
policies, or our internal requirements for how we are going to address
these external requirements, or external guidelines that we're being held

If you're in banking or pharmaceutical, I know I keep pulling from that,
it's where I had most of my experience, but the regulations that come down,
they're not clear. It doesn't say, "Do this," it's up to you to interpret it.
Being an information security officer, or somebody in the IS department,
it's really not something you want to do on your own, and make that
decision yourself. You want the experience of your audit team, you want the
experience of, some of, your line-of-business management, to help share
that decision-making process. That gets back to, make sure you have the
right people on board. That you have educated them up front, that they are
aware of what your strategy is. Having all the right people on board, and
forming your core team made up of your audit team… and I know I keep saying
that, but they are. You all work for the same company from an internal
audit perspective. You want them to have a seat at the table so that you
can understand their perspective.

You want to develop your own internal policies, and figure out the ways you
may want to automate enforcement for those policies. There's some great
tools out there. The identity management space has become very mature.
There's some great vendor products out there that we've come across, we've
seen, and helped our clients implement. That can help you pull for
deviations from standard and help take over some of that manual work. You
have to know what standard is. You have to have defined what standard is
for your company. There is no, "If it worked here, it's going to work here
and we're not going to get an audit point on it." It doesn't work like
that. You need communication and all the right people on board within your
organization to become optimized.

I'm going to talk a little bit about a case study of another one of our
clients. This is a separation of duties case study. Something that I think
a lot of you guys may be dealing with as well. Implementing some of the
most critical controls for SAS 70 and SOX compliance. The key issue here
was trying to restrict direct developer access with their own developer ID,
to critical production source code, and data. Getting more control around
that, being able to prove to external auditors that, "We've got a process
in place, we've got control around who has access to production and what
they're touching when they get there, and how we can look at what was done
when somebody was there." It was a little bit of a wild west, not totally,
but a little bit. They needed to put in controls, and how they did it was
people, process, and technology.

The first area was restricting the developer access. The role of the
existing identity management technology and process was key here. Because
the identity management solution that was already in place was leveraged to
help put controls in place to restrict access. How was this done? The
identity management tool was used to create these shared production IDs. So
getting away from allowing individual IDs, being able to access production,
but moving towards shared production IDs for a specific environment, and
access production in very controlled ways.

Identity management process was leveraged in two ways. One was to create
the ID in the first place. There was an approval workflow put together
for, "What are the requirements for getting these IDs, and who needs to
approve them?" Once they were created, there was a secondary process for
granting access to those IDs, including an approval process. Who was
allowed to have access to a shared production ID for a UNIX environment, or
for an Oracle environment, for these specific applications? There were,
let's say, 10 IDs set up for a specific environment, they all had the same
prefix, but they were named slightly differently so, database logging,
which is kind of the next piece, was tracking what all these IDs were
doing. Through the enterprise password vault, you knew who had what ID
checked out at which time. There was accountability in several areas. One
in the, who can get access. No. 2, who's using it, at what time? The
password vault was tracking who had checked out each ID, and in the
environment itself, what the ID was doing, was being logged. The third
prong of this was correlating what was done after the fact. So, again, you
didn't have to wait to get the approval, but you did have to get approval
eventually. There was an oversight committee that was put in place. To
basically look at: what changes were performed, was the proper paper trail,
after the fact, filled out to say, "Yes, this is what I did, this is why I
needed to check the ID out, I got the appropriate management approval." It
happened after the fact, but it was a way the events could be memorialized.
It was a way that the events could be tracked for compliance. Was the right
process followed?

A detective measure, for sure. At the end their memorializing it, because
once people are granted access to check things out, and to make changes in
production, the damage has already been done, if something was done. The
preventative measures up front of creating the ID, approvals around who
has access to the ID, usage of the vault, tracing who's checking in and out things
via the vault, were all the preventative measures.

I hope that we met our goal of giving you some nuggets of information that you could take back to your company. First, brainstorming to spur some discussions on, "Where are
we right now?" In terms of baselining where your maturity is and, "What
makes sense for where we want to be?" Again, there is no, "This is where
you should be." It depends on multiple factors within your company. Our
advice is, start small, have a plan, test some things out, pilot something,
see what might work, and then refine from there to continue moving up the
maturity continuum. Always remember: people, process, technology. Make
progress on all three of those fronts, and don't sacrifice one for the other.

View All Videos

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.