Chris Shenton <[EMAIL PROTECTED]> recalled his epiphany about
strong user authentication at a previous employer:
>We then realized our greatest vulnerability was weak passwords and
>users sharing their passwords with friends, family, etc. So we got
>SecurID tokens and integrated that into RADIUS.
>
>I'd do the hardware token thing again but I'd look around at competing
>token products; their docs and support suck, and I gather they require
>tons of ports open if you want to leverage their ACE server (say) from
>inside the firewall.
Ouch! Man-pages, tech support, and the product itself -- you did have
a bad time. Sorry. I don't think, however, that this is a common or
representative experience.
I've been around SDTI since before the SecurID came to market; and a
consultant to the company for years. While there are always problems -- and
the possibility of some guy having a bad day -- my impression (backed by
some good poll data) is that SDTI's customers are largely satisfied with
ACE/SecurID technology, support, and documentation.
Network admins who run ACE/SecurID, in truly impressive numbers,
recommend the ACE/Server to others as solid, serviceable, and trustworthy.
Everyone is entited to a contrary opinion, of course. I only take
issue to suggest that anyone else who tumbles to the fact that reusable
passwords (and unencrypted public network links) are major vulnerabilities
should carefully kick the tires on all the competitive options, including
ACE/SecurID.
(To judge from Mr. Shenton's diagram -- which put the ACE/Server on
his internal LAN, but a RADIUS server elsewhere -- I assume his experience
with SDTI was a while back. More recent ACE/Servers bundle both RADIUS and
TACACS+ support.)
I know that FW readers, not without cause, are cynical when it
comes to magazine reviews... but the issue of Network Computing that came
out today (9/6) has a competitive review in which the ACE/Server (v3.x)
trounces its leading competitors. See: "Token of Our Esteem," at:
<http://www.networkcomputing.com/1018/1018f13.html>
[That was ACE 3.x that got the rave review. With the latest (v4.0)
release, the speed of authentication on the ACE/Server was quadrupled.
Routine admin tasks are slated for a vastly more impressive speedup.]
The most persuasive evaluation of ACE/SecurID I've ever seen was in
the SANS' Power Tool Survey last year. SANS surveyed 350 network managers
and veteran SANS professionals to ask what they will depend upon to secure
their new corporate NT networks. See:
<http://www.sans.org/newlook/publications/powertools.htm>
The SANS survey is worth a scan; it offers far more depth than is
common in similar studies. SDTI made out like a bandit, but I was
particularly gratified to see that -- as compared to all network security
products -- ACE/SecurID won the highest percentage of endorsements from
professionals who had personal hands-on experience with the product.
Fully 92 percent of the ACE/Server veterans polled said they
actively recommended it to others as a critical component for network
security.
Neither installation nor admin of the rDBS-based ACE/Server is
trivial (and a rDBS is probably not a small site choice). Like any big
software package which has been evolving for a decade, the ACE/Server also
has its legacy issues and idiosyncrasies -- but no mission critical product
gets that sort of endorsement from network administrators unless it is
predictably stable, professionally supported, and steadily evolving to meet
customer needs.
Mr. Shenton also offered a vague technical crit:
> [...] I gather they require tons of ports open if you want to leverage
> their ACE server (say) from inside the firewall.
This is confusing. An ACE/Server (like a RADIUS server) leaves a
single UDP port open. Even for cross-firewall ACE support -- where the
ACE/Agent is out in the DMZ -- I don't think there is a problem managing
incoming SecurID traffic on the firewall.
An ACE/Agent does assign a new UDP port, from a range specified by
the Admin, for each authentication call.
(On the other end, the ACE/Server uses that designation of a UPD
port on the ACE/Agent -- for each simultaneous SecurID authentication call
-- to maintain state and to manage the relatively rare interactive SecurID
housekeeping tasks: the assignment of a new PIN; or a demand for a second
SecurID token-code, when the ACE/Server decides it wants to authenticate to
a higher degree of assurance.
In the config for ACE/Agents -- the documentation of which won an
STM award last year (bet I get a free lunch from the doc damsel for
mentioning that;-) -- the ACE Administrator can specify and limit range of
ports that will be used on the ACE/Agent host.
(The range of ports that might be selected depends upon the
horsepower of the host; the size of the SecurID user community; as well as a
number of Admin-defined choices in the ACE/Agent configuration.)
The range of UDP ports required by an ACE/Agent is unlikely to be an
issue if the ACE/Agent is on the firewall, of course. Then, all traffic is
on the internal net. (Most commercial FWs ship with an ACE/Agent built into
them.) If an ACE/Agent is on a machine outside the firewall, there have been
sites which had an issue with the range of Agent ports the ACE/Server has to
be able to address in outgoing traffic, from inside the firewall.
I understood that those concerns were usually addressed by the ACE
Admin reconfiguring the Agent and narrowing the range of ports the ACE/Agent
requires. Historically, some firewalls have had difficulty restricting the
outgoing interaction between the ACE/Server and ACE/Agents on machines
outside the firewall by IP address, which may also have been part of the
problem. I think this is less of a problem today, but I don't know the
status of this control across the range of commercial firewalls.
I beg your indulgence for this defense of a vendor's reputation, but
it is a long holiday weekend -- and with Mr. Shenton's across the board
slam, I thought that 92 percent customer endorsement in the SANS survey
deserved some mention.
Most of us don't get that sort of rating from our kids.
Suerte,
_Vin
PS:
IMNSHO, the focus of competition between the token authentication
vendors in the enterprise market has moved beyond the tokens and even beyond
the relative capabilities of the authentication servers.
With PKI looming, network authentication options are in great flux,
and what has SDTI's market share still expanding in the big companies is its
vision of the future. SDTI's mega-customers demanded a clear and
incremental upward transition path, for whenever they choose to move beyond AAA.
SDTI and its crypto subsidiary, RSA, have reengineered SDTI's
popular BoKs SSO product into Keon: an application-focused suite of AAA,
PKI, and CA products, now in beta or shipping. Keon and ACE are overlapping
but still somewhat parallel product lines; but the v.5 ACE/Server will be a
Keon server.
* Vin McLellan + The Privacy Guild + <[EMAIL PROTECTED]> *
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
