RSA Breach: A CISO RespondsHow One Organization Is Stepping Up Monitoring
In the aftermath of the recent attack against RSA's SecurID, UAB Medicine is stepping up its vigilance in reviewing authentication management logs to look for such activity as a high number of failed attempts to authenticate, notes Terrell Herzig, information security officer.
The Birmingham, Ala.-based academic medical center has about 2,000 users of SecurID tokens, which it's been using for more than 10 years. It's making the transition from hardware-based to software-based tokens for those remotely accessing clinical information systems.
"In the short-term, I would have to say we are increasing our monitoring quite a bit, and, of course, stepping up education with our users," Herzig says.
In an interview (transcript below) with Howard Anderson, executive editor of HealthcareInfoSecurity.com, Herzig:
- Points out that UAB will cut back on handing out new tokens in the short-term, focusing only on those that are "absolutely necessary for our clinical staff."
- Advises SecurID clients to educate end-users about such issues as never revealing their token serial numbers, PINs or passwords and avoiding falling for social engineering gimmicks, such as clicking on a URL in an e-mail and being redirected to a site that asks for credentials.
- Stresses that UAB segments its infrastructure so that the RSA Authentication Manager database runs on secure servers protected by multiple firewalls. Plus, UAB gives only a limited number of staff members access to authentication servers.
- Says he's looking forward to learning what remediation steps RSA will take to restore any security measures that have been compromised.
In addition to serving as information security officer at UAB Medicine, Herzig is HIPAA security officer. He heads a team of three security specialists at the delivery system, which includes a 1,000-bed hospital and numerous outpatient facilities throughout the state. He is editor the book, "Information Security in Healthcare: Managing Risk," published by the Healthcare Information and Management Systems Society.
Herzig also is the featured speaker in a webinar on developing a policy for protecting information on mobile devices.
HOWARD ANDERSON: RSA recently announced it was investigating what it characterized as an extremely sophisticated attack aimed at its SecurID two-factor authentication products. Tell us how UAB Medicine uses SecurID and how long you've been using the technology. You recently shifted from hardware to software tokens right?
TERRELL HERZIG: We're actually still in that process of moving from the SecurID hardware tokens to the software product. And we have been RSA customers for at least 10 years now, so we adopted two-factor authentication pretty early. We saw that was the direction the industry was going to take and that it was one of the sure methods of verifying that whoever is getting into our records is indeed a person who should be having access to the medical information.
ANDERSON: And you use it for primarily physicians remotely accessing clinical information?
HERZIG: That's correct. That's our general mechanism if you're a vendor or a party coming in to access our records remotely.
Authentication MonitoringANDERSON: So in light of the announcement about the breach, are you altering how you use SecurID?
HERZIG: In the short-term, I would have to say we are increasing our monitoring quite a bit, and, of course, stepping up education with our users. ... We order a lot of the tokens and do our own internal deployments. It's really unclear, in the documentation RSA sent out thus far, exactly how their products are impacted. ... From the information that I've read, it looks like the breach compromised either some internal sensitive information about how their algorithms or server technology worked, which could result downstream in either some extensive upgrades or maybe even an organization having to go through a redeployment of their SecurID products. Or it was a compromise of seed values or something related to the generation or the expectation of a certain code back from the SecurID products, which ultimately could result in recalls of some tokens. ... (Note: For an update, see: 'Tricked' RSA Worker Opened Backdoor to APT Attack.)
We won't be handing out tokens right now unless they are absolutely necessary, strictly for our clinical staff. On the other hand, we will also be educating our users more about not handing out their PIN codes or things like that, because that is one of the key things that RSA's documentation seems to hammer home and it makes perfect sense. The weakest link is your individual in the organization, and the token can't be compromised unless those individuals cough up certain information that is unique about themselves.
ANDERSON: So what do you perceive as the potential risk to your organization as a result of the attack against RSA products?
HERZIG: Well depending on how much information they've got and what kind of attack they can put together quickly, if they can get the end-user to disclose information about the token or their PIN codes, then they could very possibly have enough information to come in as the individual user and assume their identity.
There are a couple of things here in the health system we do to minimize the impact of that kind of event. We do not build our remote authentication services into our automatic directory authentication services. So what we actually do is require the user to have a separate ID and password for those services, and then we minimize what the individual can get to when they go through that authentication process for remote access. So from those two endpoints, if the system were compromised with the remote access portion, the ability of the user (to access information) is based on their role and what profiles they use internally. And, of course, then the person doing the attack would have to know the other credentials the user had ... independent from the token.
Extra Security Steps
ANDERSON: So can you explain what extra steps you are taking to monitor for potential problems stemming from your use of the SecurID technology?
HERZIG: Some of the information we've got from RSA tells what to look for in those log files, and I would encourage users to go out to the RSA website and consult their remediation guidance that they are suggesting.
There are a lot of good tips ... including look for a high number of failed attempts to authenticate. And then, of course, they note some of the other token code events in their best practices guideline for log management, which is out on the RSA website. I would recommend that customers go out and look at that, and step up their vigilance when it comes to reviewing those logs.
ANDERSON: Is there any other advice you would give customers?.
HERZIG: We just mentioned review the Authentication Manager logs, but one of the things that they continue to go back to is to make sure that the Authentication Manager database and server that it is running on are secure. ... We always segment our infrastructure in such a way that we have multiple firewall coverage ... for authentication servers and things like that. And we don't give a whole lot of people access to those authentication servers. You want to kind of keep those keys to the kingdom locked up. And that is something that I think organizations should look at ... in the light of this event. Also, with PIN policies, they want to make sure that they use strong PINs. In today's computer technology, it doesn't take a whole lot of computing power and effort to crack PIN codes. And if you are using weak PIN codes - four-digit or five-digit PIN codes - then, of course, that could lead to a rapid compromise. So RSA is actually recommending in their guidance at least eight digits in their PIN codes, and that is pretty smart.
I would recommend that and stand behind that for daily use, not just because of this event, but in extending the security of the technology, I would promote longer PIN codes. And, of course, RSA is saying protect that database in the Authentication Manager, and that if you have copies of it out there not to store them on the Authentication Manager server but make sure they are encrypted and stored in a safe location. ...
Of course, then they talk about going to your end-users and educating them on some of the things that they should and should not be doing. For example, reinforce to the end-users that they'll never be asked to divulge information like their token serial numbers, token codes, PINs or passwords, and encourage people not to freely give those up. And advise them not to bite for some of the social engineering gimmicks, like clicking on a URL in e-mail and being redirected to a site where you are prompted for those same credentials.
Waiting for Remediation
ANDERSON: So you haven't run into any problems so far?
HERZIG: No we haven't. We're watching the situation. In any event like this, and I can understand why RSA is kind of reluctant to talk about what was compromised, but we will be watching closely and expecting more correspondence on what is going on, and then, of course, the final remediation efforts on what they are going to do with their product and what changes need to be made to get any security that was compromised back into place.
ANDERSON: And how many users do you have approximately?
HERZIG: Well as far as our hardware and software tokens deployed right now, we have roughly a couple of thousand out there. So in terms of some organizations, not a whole lot, but in terms of healthcare users, we have a large number.