Information Technology Reference
In-Depth Information
Misconceptions about Security
While it's easy to mock organisations that blindly worship at the altar of big
brand names, we also accept that there is some method in that madness. Big
brand names are a convenient shorthand for compliance with the various
security principles and standards that need to be followed in such an
obviously risk-sensitive area.
Having said that, let us be under no illusions here. Even if you start with a
certifiably secure product, as soon as you install it in your organisational
environment, connect it to a couple of other systems, change a few
configuration settings and customise some of its workflow, all that
certification is moot. What may appear to a lay person (i.e., not a security
specialist) as a trivial change could often introduce security holes into a
previously secure system. Therefore, you will need to have
your particular
implementation
audited and certified afresh. And this is not a one-time
activity either but a periodic requirement, because changes are constantly
applied to systems, and fresh security vulnerabilities could be introduced at
any time in the application's lifecycle. There is no exemption from this
procedure for organisations that implement an off-the-shelf product as
opposed to an in-house build. At best, some subsystems that are untouched
may be treated as black boxes. Keep in mind that a brand-name IAM product
with a bunch of security standards certifications does not obviate the need
for a security audit of your end-to-end system design
10
.
The good news is that we're not necessarily starting off with no guidance or
direction. There are many relevant security principles and standards that
need to be followed in IAM, and we will demonstrate as we go along that the
design we describe in this document is not a “cowboy” solution but an
approach that is scrupulous in its adherence to security best practice.
For example, the Access Management side of IAM, which most requires the
use of cryptographic techniques, is something we would not recommend
writing in-house (unless your organisation specialises in writing security
products). We recommend off-the-shelf, yet commoditised, products to
perform these functions. The Single Sign-On ticketing server we recommend
(CAS) provides various configuration points to enforce different aspects of
10
We're reasonably confident about the soundness of the approach we describe
here because we had our system independently audited by an external consultancy.
There were code and design reviews as well as penetration tests. Only after the
review concluded with no serious findings did the system go live. You will almost
certainly need to do the same with yours, regardless of whether you buy a vendor
stack or “roll your own”.
