Using IAM tools to improve compliance

Using IAM tools to improve compliance

Date: May 15, 2009

Provisioning and password management tools can ease complexity, reduce help desk calls and save money. But they also have an added benefit: They can help ease enterprise compliance woes. This webcast offers strategic advice on:

 

  • State of the art and current offerings in the password management and provisioning space
  • How provisioning tools can help with regulatory audits
  • Gap analysis: Plugging "holes" in your regulatory strategies
  • Mapping IAM technologies and business processes: How technology can help

About the speaker:
Tom Bowers is managing director of consulting firm Security Constructs.


Read the full text transcript from this video below. Please note the full transcript is for reference only and may include limited inaccuracies. To suggest a transcript correction, contact editor@searchsecurity.com.    

Using IAM tools to improve compliance

Eric Parizo: Hello and welcome to using IAM Tools to Improve Compliance with
guest speaker Tom Bowers. My name is Eric Parizo and I'm your host today.
Provisioning and password management tools can ease complexity, reduce help
desk calls, and save money but they also have an added benefit, they can
ease your company's compliance calendars as well. In today's presentation,
Tom will discuss the current landscape of the provisioning and password
management market. Specifically, he'll touch on current and state of the
art product offerings, how provisioning tools can help with regulatory
audits, staff analysis and plugging holes in your regulatory strategies,
and how technology can help with mapping AIM technology and business
processes. Our speaker today, Tom Bowers, holds the CISST, CNT, and
Certified Ethical Hacker Certification. He is the managing director of
Independent Thinktank and security industry analyst group Security
Construct LLC. Tom's areas of expertise include aligning business needs
with security architecture, risk assessment, and product management, on a
global scale. Tom is a technical editor for Information Security magazine
and a regular speaker at events like Information Security Decisions. Thank
you for joining us today Tom.

Tom Bowers: My pleasure to be with you again.

Eric Parizo: And now we're ready for your presentation. So here's Tom Bowers.
Tom, take it away.

Tom Bowers: Great. Thanks Eric. Today we're going to talk about using identity and
access management tools to improve compliance. It's probably the major
driver currently in the market. Companies are struggling to see a return on
investments purely from an ROI standpoint but compliance has really driven
this market and there's a major growth here in this market, so we're going
to begin to take a strong look at this. In today's presentation we're going
to take a look at some of the current offerings. What some of the new
visions coming out of this marketplace are. We're going to look at how to
maximize identity access management, deployment success and this is really
a crucial part of the presentation: we're going to look at what assistance
these product suites offer for audits and auditing and the holes in your
regulatory compliance architecture and how identity access management can
help out. Then we're going to take a look at probably the greatest piece
of failure, and/or the greatest successes in most of these projects, and
that is the business process. Then we'll wrap things up and take a few
questions.

Identity and access management solves two main problems. First is user
account management. That's pretty obvious. Identity and access
management. So, user account assignment and management and enforcement of
privileges. These are critical. It also focuses on the usage and the
regulatory and compliance space. And as I said, we're going to look at a
number of areas within this. Some of the new state of the art feature that
are, in my estimation, very exciting are things such as virtual directory
support. Many corporations have grabbed a hold of the LVAP architecture
and/or active directory architecture. Many corporations have several large
directories operating. Identity and access management:, the newest
versions allow us to create a virtual directory. So it can pull user IDs
and passwords and user attributes from multiple sources into a virtual
directory and then use that virtual directory as the main directory for the
identity and access management product and project itself.

The next major feature that I see a real improve in is web access
management. Think about you organization and all the web portals you have,
all the web enabled applications you have, all the enterprise applications
that you have that are web-based. Web access management is a relatively
new add-on here to the identity and access management function, that allows
you to control those applications as well as the standard network log-on
type of applications and certainly there have been some dramatic
improvements in auditing. As the auditors continue to refine what they're
looking for, and corporations begin to understand what the compliance
regulations are asking for, these identity and access management tools are
also beginning to get more refined. Therefore the auditing reports, the
types of things that can be seen and drawn out of this are becoming much
more sophisticated and easier to use at the same time.

So, what do I see here in the future? Probably the biggest failure point
of a technology right now is the identity and access management
implementation change. These are major projects, folks. You need to know
going into this that for a large organization of let's say 30,000 people on
a global scale with multiple offices, identity and access management may
take you three years to implement to a full degree. This is not a short
term project. Certainly you may start with one or two groups and then
build out the architecture from there. The challenge is right now that
it's not easy. What we're seeing now from the vendors, however, is a real
focus on this. They're beginning to get much smarter about making the
implementation, the deployment of their products much easier, and changing
them. So that once you've implemented let's say for an SAP or an Oracle
implementation, and you need to change that architecture a year down the
line, the change in identity access management process will also become
much easier.

The other true business scenario that I see real improvement coming, not
here yet however, is the whole idea of business process change management.
Most people tend to forget that one of the greatest successes, and I've
already mentioned it briefly, one of the greatest success and/or failures
will be business process and how identity and access management can either
help, or hinder it. You must always remember that security is a business
risk function, and we're here to enable the business. If this product
and/or project is going to succeed in your enterprise, you have to be
always aware of business process change management. What's happening is
that the vendors are getting smarter about this, they're professional
services are getting smarter, their technologies and interfaces are getting
smarter; and they're beginning to make it easier for you to have a real
success in helping your business become better at what they do.

So, what are some of the basic features here? As I was developing this
presentation I realized that we hadn't really talked about identity and
access management, so here's probably the four major areas of identity and
access management and what it is that it's trying to do for us. Identity
management, certainly, is the first function here, we're looking for a
single user identifier. I've seen a number of instances where projects
have stumbled, simply because they had multiple user IDs for the same
person. So one of the things, it's almost a prerequisite as you're coming
into this, you're going to have to settle on a standard user ID, and
central policy control point. This is another key area of improvement for
your architecture.

It leads right into provisioning. How easy is it to provision and how easy
is it to de-provision? Probably the greatest failure of the companies that
I have worked for personally, has been de-provisioning. There have been
users that have left the enterprise, they've been gone for years, but the
user ID is still there. And in some cases I'm aware of, those users have
come back in as consultants later on, and all they had to do was re-enable
the user Id because it was never disposed of properly. So how easy is it
to create the user ID? How easy is it to de-provision that user ID? And
what type of documentation controls are there? Think about Sarbanes-Oxley,
Gramm-Leach-Bliley, HIPAA requirements, FERPA requirements for education,
they're all very similar and a big cornerstone of these things like FFIEC
is all about documenting your controls and keeping a control on that
documentation.

The next obvious example here is authentication. We're looking for every
user has a separate user ID, no generic accounts and I, like all of you,
have struggled like that because there are some cases, let's use training
as a great example: you have a training room where you don't want people to
log-in with their own user ID, simply because if they do it will push down
all their applications to the training computer and the training computer
will have to be re-imaged. So the only way to get around that is to create
training IDs that are somewhat generic. So how do you deal with that
situation? The next obvious thing is single-sign-on. All of us in large
enterprises have multiple applications that we're trying to get into
multiple platforms. Whether it be AS400, S390, Novel networks, Windows
networks, Linux networks: there's a number of places we need to log-in to
get to information to be able to do our business. Single user sign-on is a
critical success factor, and this is a very large public relations piece
for your project team out to the business. Being able to achieve this
single sign-on, or at least being able to reduce sign-on. The other
advantage here is reduced help desk costs. You can see great savings here
with this single or reduced sign-on component of identity and access
management.

Lastly, most identity and access managements have a strong certificate
management, which provides strong authentication. Here we're going to talk
about some of the most important features that you need to be aware of for
your product, and therefore your project. First of all, when you review
identity and access management products you need to look to ensure that it
has a diverse run-time environment. What do I mean by that? I mean, does
it support J2E? Does it support LVAP and active directory? Is it
flexible, in other words? A cohesive product offering. This is a
wonderful one. A number of really good vendors out there have these
component pieces, these modules, you can think of them as building blocks
and this in and of itself it not bad; it gives you a great amount of
flexibility. But do these modules talk cohesively to one another? Is it
one large integrated product or are there several smaller ones? And if
there are several smaller ones, do they work seamlessly together? Well,
what we're beginning to see in this space is the larger companies buying up
these smaller promising vendors. And as such, their product offering are
not as cohesive as they need to be.

Work flow. Please notice that work flow here is number three on the list.
It's very, very high. What we're talking about here is automating business
processes, or support for nested work flows. So, for instance, you may,
your identity and access management may be supporting your finance
application; underneath finance you've got cost controls; underneath that
you've got vendors. And those all have work flows underneath them as well.
Will this identity and access management support those nested work flows?

Multiple connectors. This is crucial. You'll find a number of vendors
have what I'll call canned connectors to multiple platforms. And, as such,
they can talk to a few standard Windows, Linux, UNIX platforms, etc. The
question becomes, do the connectors have a graphical interface or is it
command line driven interface? Is there a programmer required? Quite
frankly the era of having the end users, us, the architects, having to do
this type of command line or graphical programming is long gone. There's no
reason with today's modern GUI interfaces to force the customers to do
this. And you're seeing some of the better vendors in this space have
graphical interfaces that are wizard driven and all the programming is done
in the background.

Certainly account management is going to be a very important feature. It's
one of the base features. Roles and groups also falls under that. And
multiple user interfaces. Typically these products will have interfaces
for users that may be outsourced, maybe you're outsourcing some of your
functions. They may not need the same interface that your internal users
need to have. What about your remote internal users? Do they need to have
the same rich feature set that your inside-of-the-firewall-users need to
have? So, are these products able to handle multiple interfaces, for
multiple clients within your organization? And lastly, however, is your
administration. Can you delegate administration, and thus have a different
user interface for different levels of administration. Self-service
capabilities. Even though it sounds like a no-brainer, it's one of those
things that for a project like this, it will really sell your project to
the end user community.

Virtual directory support, we've already talked about that briefly. This
is really just building, but there are enough products out there that you
need to be able to look at this. Aggregating user information from multiple
sources, have one logical view, and ideally the identity and access
management function houses the authoritative directory for user
information. Reporting is going to be key. What type of attestation does
it do for the logs? What types of auditing is it capable of doing? Can
you do a corporate policy audit? Can you do a regulatory audit? What
types of compliance audits can you do? And lastly, what type of change
request approval process are available to you?

So, how do we maximize deployment success? Well first I'm going to talk
about the failure points. The failure points typically are the business
process changes. You need to get your business unit heads involved in this
process at the very, very beginning. They're the ones you want to tie in
to, let's say SAP or Oracle or JD Edwards or some other large web portal
that you may have internally. Those business owners, the people whose
businesses rely upon that software package, and that you're tying into
those business processes; those are the ones that you're trying to improve
or automate. So, you have to, at the very front, create an expectation of
what the identity and access management product is going to be able to do
for you. And then ensure that you meet your actual expectations. This will
keep your business unit head, and thus, who do they report to? They report
to senior management, who report to the CEO. It's going to keep senior
management happy, because you've improved the business by doing things
securely.

Failure to communicate project goals. I've seen far too many projects as a
project manager, where the project team knew what was going on but nobody
outside knew what was going on. So, rumors started being created about
what the project was going to do, and of course once the project is
complete and it doesn't meet that rumored expectations, it's considered a
failure. So you need to communicate to management, specifically senior
management, and business units and to the end users in this case, and you
need to give them constant reminders. And by this I mean not only weekly
updates but emails to your internal end users to say, 'This is where the
project is at. This is what we've completed so far. These are the success
we've had. These are the challenges we're facing. This is when we expect
these things to be done.' So, you're giving constant communication out
there to always set that level of expectations. Just ensure that you meet
that level of expectations. Your business requirements, your architecture
deployment, if the business is not enabled through this process, this
process will fail. So don't try to implement one small piece without
having the bigger plan. I've seen a number of companies who have been
success in deploying to one small group, only to find out that they really
didn't plan out the whole enterprise and thus the whole project ultimate
failed. Simply because that one small group, they're business process was
so unique, that it couldn't scale out to the rest of the enterprise. And
if not done in this order, disaster will await. So always start with your
business process; start with your business unit heads. Then bring in the
technologies. Figure out what the expectations are going to be, and then
meet those expectations.

So what we're going to talk about here are the success builders. First of
all, I've already mentioned this briefly, but define your identity in the
enterprise. For instance, the syntax. So, is it going to be 'TBauers' or
'BauersT'? And ensure that every user has one user ID format, and one user
ID within the enterprise. Things such as your location, your division,
your management, your security level. All of those should be attributes
that should be defined before this project even starts. You need to define
attributes themselves. The required credentials. The roles. The user
rights or entitlements, and the policies or what's commonly known as
'segregation of duties'. All of these attributes must be defined. Please
notice: both of these are really done before this project even starts. Map
your attributes for the various systems. How are you going to map let's
say, the location attribute to your AS400 versus the active directory
implementations, versus the Linux or UNIX implementation or Documentum?
Does it even apply? Can it be used across all of those? So you need to
map those before you even start here.

Then define your audit requirements. Both corporate audit requirements
and regulatory. Corporate requirements are not just policy driven. Think
about data loss. Many of us have suffered from these privacy breech
notifications or Sarbanes-Oxley breach or GLBA problems. Think about it in
legal terms. So that if I've done audits and information still gets out of
the enterprise, intellectual property is what I'm talking about here,
intellectual property gets out, get's into the public domain, and you want
to press a legal case in the court systems. Those corporate audits, to
prove that not only did you have a policy, but that you audited the policy,
will come in very, very important in the court of law. So, ensure that you
have your corporate audit guidelines done, as well as your regulatory and
compliance guidelines.

And lastly, and one of the most often overlooked in many projects that I've
seen, is document your decisions and your decision process. Think about
the people that are coming three years after this is deployed. You've
moved on. You've been promoted. You've done a phenomenal job with this.
They've made a VP, but you're VP of a completely separate department now.
And the people that are in charge of running it don't have any idea why you
setup the user ID construct the way you did. So not only document that
decision, but how you got to that decision. What were the limiting
factors? What were the constraints? What were the success factors for
making that decision? So document both your decisions and your decision
process. So, how does the identity and access management product suite
help you with your audits? Well certainly we have the regulations, and I
list them here; everybody is familiar with them. Sarbanes-Oxley section
404; FFIEC for the financial industry; FERPA for, this is really the same
as FFIEC for financial except it's for education.

So, Sarbanes-Oxley section 404 recommends things such as the COSO or COBIT
audit controls, FFIEC, it is very specific control recommendations, FERPA
is very similar to FFIEC except education versus financial. And we start
at, we create an identity control cycle here. This identity control cycle
is where the audit assistance really starts to come in. We start at number
one, which is at the very top here, defining your control objectives. What
it is you're trying to control. Access to a particular hard drive or data
on a particular hard drive,access to a particular portion of an Oracle
database. Next you have to document the required control activities. How
is it that you are going to control access to that particular section of
the Oracle database? Then you're going to determine metrics. What metrics
are you going to use to measure to ensure that you're meeting those
controls? Then you're going to implement those controls. Put the controls
in place. And lastly, you'll audit the controls. And so those controls,
now, you've created an audit here, and you go all the way back up there to
ensure that, well, was my definition even correct? Well, you begin to see
automatically, just based on this identity control cycle, you begin to see
how identity and access management can really play a large role here.
Because identity and access management, what does it do? User Ids,
control, segregation of duties, auditing and reporting. So, it provides
the real technological framework to be able to create this control cycle
here. So, I can define the control object, control access to an Oracle
database; I can document those required controls, as we've already talked
about documentation. I can determine the metrics so I can measure using
identity and access management tool, I can actually measure log-ons, log-on
attempts, incorrect log-on attempts, attempts to hack into the system, I
can see all those thing. I implement the controls here using intensity and
access management and then I use the internal tools in the identity and
access management product suite to audit the controls and give me very
detailed reports. I can then turn those reports around and give them to
the regulators, to prove that I've met regulatory guidelines.

So, identity and access management, obviously, covers at least items 2-5.
Although in many ways as part of the project, you're going to define number
one. So, you're going to come up with a user identification, you're going
to create user attestation and assurance, you're going to ensure,
basically, that the user is who they say they are. And you're going to be
assured that it is they who are logging on to the system. Then you're
going to create a user authorization process by assigning rights, roles,
and responsibilities. Basically, segregation of duties, to that particular
user.

Then lastly, you will generate historical data for auditing compliance
reporting. This is really, as I mentioned at the very beginning, probably
the most critical reason for growth in this particular segment of the
information security marketplace. Is that this historical data is now
available in a very easy way to give to the auditors, to prove that you're
complying with regulatory requirements. So, where are the holes, both in
your organization, how can the technology help? The first thing you need
to look for is what the risks are in your current system. Basically, you
need to do an audit of your current system, whether it's an internal audit
or a third-party audit. You need to find out where the risks are, and this
is not just technological, this is business process as well. So think of
things such as bar code systems from a warehouse. Is it using RFID tags?
How far away can those RFID tag be read? What I'm trying to do is get you
to think outside the box here. This is not just technology, this is
business process as well. So you need to identify business risks, as well
technological risks.

Let's say SAP has its own security infrastructure. Well, what holes are
there in the SAP system? Well, what holes are in the business process
embedded in the SAP system? Do you know right know who has access to what
systems? Can you definitively, right know, go put your hands on every user
that has access to particular systems? My guess is that you'd be hard
pressed to figure it out; and maybe one of the reasons that you're looking
to do identity and access management. Do you know who has access to what
information? Now we're getting a lot dicier. I know in my previous
employers that this was the number one area that we had difficulty with.
When you have a standard networking environment, whether it be a Linux,
whether it be Novel, or Windows, you've got these servers that most people
can get in to. Well, who has what information that's there, number one,
and who has access to the information, and how is that information flowing?
This becomes very, very important for regulatory compliance. Because
regulatory compliance, things like the FFIEC, FERPA, etc., they are very
precise about controlling who has access to data. FFIEC talks about who
has access to particular systems, but it also has specific guidance about
who has access to specific information. So you need to figure out who has
access to what information, how that information is flowing, and thus how
will identity and access management control that situation, or how do you
expect that it will control the situation. What are you current
authoritative user repositories? Do you have all LVAP? If so, how many
versions of LVAP do you have? Do you have active directory? Do you have
more than one tree? Do you have a Novel e-directory? So, how many
directories do you have there that are holding users?

Well, how many enterprise applications is SAP, for instance, part of the
LVAP infrastructure, or is it maintaining its own user ID base? What about
Oracle systems? Does it have its own Oracle ID base? I could go on and
name a number of different enterprise systems, but you begin to get the
idea. Where are those users located, and which ones do you consider
authoritative, and which ones you're going to have to change? So let's
assume that you have an LVAP that you've settled on, it's in your
enterprise, you may also have active directory. So you've got both, but
you're using LVAP as the main directory. But, there are some research
organizations in your company that have large enterprise based applications
that have their own user ID base, and their own passwords and their own
security, and they're not using any of the LVAP or active directory
functions. So they've got their own. Well, are you going to force them
through the identity and access management project to change, to become
LVAP compliant so that identity and access management can take better
control? That's really what you should be doing, but you can begin to see
now that unless you have that business owner in charge of that particular
research application, unless you have that business owner on board, and
being one of your champions, it becomes one of those areas of heartache,
and also potential area of failure. Because now you'll have this large
identity and access management infrastructures and they aren't plugged into
it and they still have additional help desk costs and senior management
says "it didn't work; we didn't improve the process, it didn't improve
anywhere."

So what are the points of human error in your current processes? And here
I'm talking about the business processes themselves where humans are
involved, that could be assisted by identity access management project.
Things such as creating user IDs or de-provisioning user IDs. Most
organizations without this IAM infrastructure have a very manual de-
provisioning process. So there are many mistakes. And as I've already
shared, I'm personally aware of organizations that have user IDs that have
been there for ten years, and the user has been gone for six. It's a very
manual process. Are your current identity and access management processes
documented? If not, that's got to become part of your project, and
obviously part of your cost. And you may end up having to bring in
consultants just to do that cost effectively.

Are your external partners covered in your current identity and access
management system? Many, many organizations are going to outsourcing or in-
sourcing, but they are shifting non-core business processes to some other
third party. Well, are those third parties included in your current plans?
They need to be in order to control data flow. We're talking about
information here. That's really what this is all about, is controlling
access to that information, not necessarily systems, but information. So
they need to be a part of your current system, and they need to be a part
of your current project, and you probably need to have somebody on your
team representing those third parties.

So the business processes. What happens if we don't implement this
properly? Implement identity and access management properly? We allow
open access to privileges that the user may no longer require. Think about
it. You came in to the organization, you're a network engineer, you got
promoted, you're not an enterprise; you've gone from senior to enterprise
level network engineer. But you've still got user privileges for systems
that you were responsible for when you were first hired. That's a problem.
Open accounts. Somewhere along the line someone was doing development
work, they created an account to do testing with and that account was never
done away with, it was never deprovisioned. Administrative overhead in
cleaning up the systems. How much are you spending now in creating or
overseeing those problems now? For a return when the users no longer
require them. So how do I go beyond this? How do I improve this process?
Well there are some recommendations here for mapping the process. First of
all, gain human resources buy-in. They are the people, they are the people
portion of your corporation. So, gain them, gain their support from the
very, very inception. HR employed life cycle process is key to effective
employee identity and access management. Tie in those two, the HR employee
life cycle process and the identity and access management process should be
absolutely intertwined. Simple and transparent provisioning for all
employees and make the approval provisioning process for non-employees
equally as easy.

Here I'm talking about consultants, contractors, temporary personnel.
Provide simple mechanisms for employees that change roles in the
corporations. Is there a graphical user process to be able to make those
changes, as roles change? Is it an automated system? Look at mapping the
business roles to IT processes, resources, and assets. This can be
problematic sometimes, and I'll be the first one to admit it. That the way
IT sees the world, from a system standpoint, from an architecture
standpoint, doesn't necessarily always map cleanly to business processes.
But you need to make this as close as possible.

Is it possible to change the IT process or is it possible to change the
business process so that they do come in alignment? Introduce in this
project, introduce simple roles to start. In other words, employee versus
non-employee. That's a very simple role. And then assign common
privileges to those roles. So, start there as your foundation. Don't try
to start complex first. Create an easy interface first, and then turn
around and add your layers of complexity; add your roles and groups there.
But start at the simple and become more complex.

Lastly, consider what resources may require approval. Those that don't
require approvals are built into a roll catalog. Very simply, what we're
trying to do is automate the process as much as possible. For instance,
you have a manager that needs to have access to a particular web portal.
Do you really need to have a formal HR approval process to have that
manager have access to that particular web portal? If they don't then make
it an automated process and assign it to a roll catalog. And make it a
very simple process.

In conclusion, many of the aspects of this marketplace are mature, but
certainly more polish is going to be required. These suites are not where
they need to be yet, but they are getting there. Realize that this is a
complex project, very complex for both implementation and configuration.
You will most certainly need to have professional services from your vendor
involved in this. You'll probably likely have consultants and contractors
involved, to help do some of the more mundane documentation, role
management stuff, to be able to do that cost effectively. Consolidation in
this space is happening at a very rapid pace. Vendors, large vendors are
buying smaller vendors, smaller vendors are doing the most innovation.
Larger vendors tend to be buying those and integrating them into their
suites. This whole space, however, is driving improvement in features that
will improve regulatory compliance. It will make it much easier to prove
regulatory compliance. And lastly, identity and access management provides
everything you need to meet regulatory requirements, currently. Today, they
can meet all of your requirements for identity controls. It is the right
solution. It will make it easier for you, just realize that it will be a
birthing process, a growing process to get this project deployed correctly.
Thank you.

Eric Parizo: Alright, great presentation Tom. Thank you so much. I have a few
follow up questions for you. Nobody ever likes to talk about the negative
side of things. But, how do IAM deployments fail most often? What are the
factors and/or worst case scenarios?

Tom Bowers: As a global project manager, where I see most of these projects, at
least stumble if not outright fail, is not getting their business units
involved enough. Number one: from the very beginning, going to those
business unit champions, developing champions, if you will, business unit
people. And by this I mean, people who are in the business side of the
house. Whether you're selling silicone, whether you're selling boxes or
products, those business unit people need to be involved in the process
from the very inception, number one. And they need to be involved
throughout the project. Secondly, is setting expectations. Don't tell
them you're going to deliver the moon and then only deliver them Mount
Everest. Mount Everest is impressive, but when compared to the moon, it's
not there and the project may be seen as a failure. So, set reasonable
expectation and get your business units involved from the very inception.
Those are the two most common areas I see problems with these deployments.

Eric Parizo: Following up on that real quick, regarding the business units. In
your experience, are those champions hard to find or are they always there
to be found? Will they take the time and make the effort?

Tom Bowers: Business champions typically can be very easy to find simply by
looking at the enterprise applications that you're looking to bring in as
part of identity and access management. So, I've already mentioned a few
things like SAP. Well SAP, JD Edwards, those types of applications support
things like human resources, legal, finance and accounting, production,
manufacturing, research. So, look at those applications and then look at
who those applications are supporting, then go to those business units and
talk to the business unit head and let them know what's going on with the
identity and access management project; or what your vision is. So it's
relatively easy. What you're going to find out is if you go to them and
say 'Hey, we're looking to improve the business process. Help you do thing
more efficiently here.

We have some technology that we think you'll find very helpful. Would you
be willing to invest some of your group's time in order to help make this a
success?' What I've seen personally is that most of those business units
are going to be jumping all over themselves to be jumping on the bandwagon
if they can be part of a success project. So it's relatively easy to
develop champions. What's more difficult is to keep them as champions. By
communicating, keeping them involved, letting them know what the initial
expectations were, and the expectations that you've met. So, it can be
done and I think it's a people issue; it's a soft issue, it's not a
technology issue.

Eric Parizo: OK. That sounds like a good plan. What is the most important part
of regulation that IAM addresses?

Tom Bowers: Regulations in and of themselves talk about--they either mandate or
in the case of FFIEC, strongly suggest controls that need to be put into
place. For instance, FFIEC is very strong about two factor authentication
as a minimum. Although it doesn't come out and say you must, if you don't
have it and the regulators see it, you may not be seen as meeting
regulations. So even though it's not mandatory, it's strongly suggested.
So controls are definitely a part of that documentation. You're going to
find that regulations are requiring more and more documentation. This is
where identity and access management can shine, because there's a built-in
methodology for documenting a reporting what's been done. Auditing and
reporting are the back-end of identity and access management, and they are
how you prove to regulators that you're complying with the regulations;
it's by conducting audits, frequent, regular audits, and providing the
required reports. So, identity access management, while regulations
require controlled documentation, auditing, and reporting, identity access
management can actually supply all of those things. It can supply the
controls for you; it can supply the documentation or at least assist in
creating that documentation; and then it will help you in a built in
process do auditing and reporting.

Eric Parizo: All right. Here's our final question for today. And really, this
is just to go off of all of this, if you could offer just word of advice
for IAM/compliance related projects, what would it be? What's the most
important thing to keep in mind?

Tom Bowers: Business processes. It is the foundation. Everything must build off
of your business process planning. Set your expectations; get your people
involved--the business units heads involved. It will absolutely pay huge
dividends down the road during the project, if you find out that the
identity access management doesn't have a connector for this particular
platform so you go to the particular business unit head and because they're
a champion you can get funding from them instead of having to always go to
your own funding all the time. I would say that business processes are the
starting point, the foundation point, and the success criteria for a
successful deployment.

Eric Parizo: All right. Sounds good, very good. Thank you so much for your
insights. That brings us to the end. We'd like to thank Tom Bowers of
Security Construct for joining us today. For more information on
provisioning and password management, read our companions disk via the link
on your screen. And be sure to check out our firstsecurtiy.com identity
and access management security school at firstsecurity.com/iamschool.
Thanks to all of our listens for joining us. I'm Eric Parizo. Stay safe
out there.

More on Enterprise User Provisioning Tools

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
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
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: