The great unknown
Most of the challenges we
face with security, and IAM
in particular, are based on
the diversity of the systems
that must be controlled, the
complexity of the disparate
solutions put in place to
secure access to those diverse
systems, and the constantly
shifting landscape of users and
the ways those users choose to
access those systems.
Every time a new system is
introduced or a new access
opportunity presents itself, we face
a crossroads. On the one hand,
we can do our very best to secure
the new system or the new access
method on its own, hopefully
(emphasis on “hope”) with the
ability to draw on existing security
practices or technologies; or we
can take a step back and redesign
security across the board so that
3
everything, including the new player,
is addressed as a unified whole. The
second option is ideal yet entirely
impractical, while the first option is
the reality of the situation and the
root of the problem.
We don’t know what tomorrow
will bring. We can’t redesign our
security systems every time
something new comes up. We can’t
throw out existing investments and
proven systems and practices simply
because the new investment doesn’t
“play nice” with them. So we’re left
doing the best we can with the hand
we’ve been dealt, but often that
isn’t enough. Risk doesn’t go away
simply because we’re trying hard.
Compliance doesn’t rest because
we have the best intentions. And
users don’t forgive security-caused
inefficiency simply because systems
don’t play nicely with each other.
In other words, the future is the
great unknown and no one can
afford to wait for the future to arrive
before making critical IAM decisions.
How we got here
When thinking about futureready IAM, I like to look at and
learn from the past.
Let’s look at the tale of two platforms:
Windows and Unix/Linux. Back when
Unix was king and Linux was gaining
ground, and when Windows NT was
all the rage, the only way to secure
those systems was by treating each
server as an independent island.
That meant from an IAM standpoint
each user had a unique account, an
independent authentication method
and unique authorization. So, clearly,
administration was a nightmare.
To overcome the problem, the
*NIX world pursued complex
synchronization scenarios and nonsecure tools that made things slightly
better, but only as long as everything
remained constant. Unfortunately, this
complex synchronization by the *NIX
world, doesn"t support a future-ready
IAM solution. In fact, it was wholly
unequipped to address pending trends.
Windows, on the other hand, took an
entirely different approach. Rather
than attempt to make the disjointed
approach to IAM work, Microsoft
took a step back and evaluated the
right thing to do with an eye on the
flexibility and scalability necessary to
4
address whatever the future would
hold and consequently an opportunity
to help influence the future. The
result was Active Directory, a
single source of authentication and
authorization for all things in the
Windows universe. And the rest, as
they say, is history.
The challenge of the day
must be addressed quickly
and with the tools available
at the moment.
Interestingly, the *NIX world soon
embraced the concept of the unified
directory for all servers and the
thriving Active Directory bridge
industry was born. Rather than create
its own unified directory, *NIX chose
instead to take advantage of what
Microsoft had already done – future
ready IAM at its best.
The culprit in most IAM approaches
that are rigid and not future-ready
is the necessity that the challenge of
the day must be addressed quickly
and with the tools available at the
moment. Keep in mind, the vast
Please complete the form to gain access to this content
