"Quite frankly, the only data that is allowed to leave the state infrastructure is public data," says Delaware Chief Security Officer Elayne Starkey says in the second of a two-part interview with GovInfoSecurity.com (transcript below). "All the others can only leave if it is properly protected or properly encrypted. This is just something that we've been focusing on at least the six to eight months, just analyzing how big or how small the problem is and trying to take steps to mitigate the risk."
And the most common sensitive data being leaked: Social Security numbers. Often, Starkey says, citizens include their Social Security numbers when corresponding by e-mail with government employees, and when those messages are answered, the original file that includes the SSN is attached, potentially exposing the SSN if the reply isn't encrypted. Delaware has implemented filters that block unencrypted messages containing the numeric pattern of three digits, two digits, four digits.
"We allow the technology to take care of closing the vulnerability by sending an alert back to the sender to let them know that they attempted to send confidential information and the send has been blocked," Starkey says. "The recipient did not receive the e-mail."
In the interview, Starkey also discusses a new program to let state employees access government servers with their own BlackBerries, iPhones and Droids provided they follow stringent security rules that could result in the loss of all of the data - government generated and personal - from their smart phones if those devices are deemed a threat to state information systems. "That's not something I want to do very often, but we need to reserve the ability to do it if needed," Starkey says.
In part one of the interview, Starkey addresses managing a team of IT security professionals not protected by civil service and the use of metrics to evaluate their performance.
Starkey, interviewed by GovInfoSecurity.com's Eric Chabrow, holds two computer science degrees, a BS from James Madison University and an MS from the Rochester Institute of Technology.
Stopping Data Leakage
ERIC CHABROW: A major problem that faces not only Delaware but other states is data leakage. How do you define data leakage and tell us a bit about Delaware's data leakage problems?
ELAYNE STARKEY: One of the things that we've been focused on recently, Eric, is our ways to close any possible data leakage issue, and the way I define data leakage is anytime any type of confidential or otherwise protected information leaves the state network either unattended. It is unattended that it leaves the network, or it leaves the network in a way that is unprotected or unencrypted. We have four classifications that follow the federal classifications ranging from public to top secret. Quite frankly, the only data that is allowed to leave the state infrastructure is public data. All the others can only leave if it is properly protected or properly encrypted. This is just something that we've been focusing on at least the six to eight months, just analyzing how big or how small the problem is and trying to take steps to mitigate the risk.
CHABROW: Give some examples of some of the problems with data leakage?
STARKEY: The most recent examples have been around Social Security numbers. We have done some analysis of our e-mail that are leaving the state network containing a Social Security number or SSN like pattern, and we're not so much worried about the e-mails that are going from state user to state user because our network is a structure that protects that automatically through encryption, but we're worried about those that leave the state network in a clear text e-mail. And they may be Social Security numbers of our citizens. In fact it's very common for citizens that are inquiring about state services to send an e-mail to a division or an agency inquiring maybe for a status of something, and they will send along their Social Security number, full Social Security number, in an unencrypted e-mail. The state agency may respond to that and reply and continue the thread, where in the thread that Social Security number may bounce back and forth in and out of the network four or five times unprotected. That is the kind of work we've looked at, which is a very noninvasive approach to the problem, first just trying to analyze how big the problem was. We decided that it was something that needed attention and just in the last fifteen days we've been able to close that potential leakage area.
CHABROW: Are people using Social Security numbers in situations where the number really isn't necessary?
STARKEY: I believe so. Quite frankly, encrypting an e-mail in my opinion is maybe the third choice, but what I would rather see is when the correspondence continues back to the citizen they take a look at it and say, "Do I really need to send that full Social Security number?" In many times, the answer is no. If there is some need for an identifier, maybe it's just the last four, and it would not be against our policy to send just the last four in an unencrypted e-mail. The absolute best way to mitigate the risk is to take a look at your business need and ask yourself, do I really need to send this whole Social Security number or this file of full Social Security numbers out by the state network?
Why Use Social Security Numbers?
CHABROW: Does Delaware use Social Security numbers for purposes other than Social Security, which is federal government responsibility?
STARKEY: A number of our systems require it. It may not be the, what I would call the key field or the primary field as it once was. It used to be the key field for example in our motor vehicle system. It has been many years now that have changed as the value of a Social Security number became more important. It used to be a wonderful unique identifier, but now it introduces so many privacy concerns. Certainly, it is collected and stored in many state systems
CHABROW: Except for payroll purposes, why would the state or any organization need to use a Social Security number?
STARKEY: Some of it, Eric, is just kind of left over from it's a convenient easy way to uniquely identify an individual, whether it is someone applying for child support benefits, some type of family transaction or healthcare or anything along those lines. We're seeing over time, I think, that is going to change, and it's not because it is such a hot button field. It will slowly be phased out as the data element in a lot of databases. But in the meantime, it is still there. If you take a look, if you know anyone that is on Medicare, you know take a look at their Medicare card and there it is printed you know right on the card. We advise a lot of senior citizens when we're doing security presentations to try to commit that Social Security number to memory. You know to carry it around in your wallet is a huge risk.
CHABROW: What are the initiatives under way to combat that leakage?
STARKEY: The first thing that we've done is we've implemented, we've reconfigured our e-mail tool so that we scan all outbound e-mails looking for Social Security number or a SSN like pattern. If found, we will block that. If it is a straight nine-digit number that could potentially be a Social Security number, we send an advisory back to the sender letting them know that there is a possibility that was a Social Security number. But if it is a true, fortified, three-digit hyphen, two-digit hyphen, four digit, we block it. We allow the technology to take care of closing the vulnerability sending an alert back to the sender to let them know that they attempted to send confidential information and the send has been blocked. The recipient did not receive the e-mail.
CHABROW: Has that caused any kind of business problems?
STARKEY: So far so good. We're only about two weeks into it, and we did a lot of education to our customers up front and we identified several applications that were sending nine digit numbers that were not Social Security numbers. We took some special steps to prevent the disruptions through applications, but knock on wood so far so good.
Accessing State Network with Personnel Devices
CHABROW: You also have programs allowing the use of personal mobile devices by state employees that you just initiated. What is the problem that created this new policy?
STARKEY: For the last six years or so, we in Delaware have standardized on the BlackBerry mobile device to meet our business level device needs. It has served us very well. We are quite satisfied with everything about the BlackBerry and the underlying architecture including the very robust security controls that we enjoy on the desk server. Things like strong passwords and encryption, inactivity time-out, remote wiping, all of those things.
What we are seeing though just in the last 12 months or so is a shift of requirements from our customers. Rather than carrying around a work device and a personal device, we're seeing the trend toward combining both their work data and their home data on to a single device. We have not up until just yesterday; we had not disabled that capability. What we did effective yesterday is we put in a blocking mechanism so that only pre-approved smart phones, those devices where people have gone through a process to request approval to connect to the state network and have acknowledged that I agree to the standards the state security policies around, using strong passwords, using in-activity time-out monitors, if necessary, I agree to have my device remote wiped if there is some type of vulnerability. I also agree to use encryptions, make sure all the traffic and the device itself are encrypted, all of those things. I see this as a huge step in enclosing down a risk. If you think about it, everyone is carrying around these smart phones. If that smart phones is indeed connected and linked to the state network, if it's not password protected and if it gets lost or stolen and gets in the hands of someone, they literally have unfettered access to state data, which is the kind of stuff that causes me to loose sleep at night. It is this type of new policy that we're rolling out this week that will close that data leakage problem.
CHABROW: What has been the reception from employees to this?
STARKEY: Very mixed, everything from people that you know understand the security risk and understand why this is so important, and maybe make the decision to say hey, you know I just kind of did this as more out of convenience. It's not a real requirement of mine. Take me off your list; I don't really want to do this. We've also fielded a lot of questions about how does that remote wiping, how is that going to work. If my device is at risk, where does the date data start and stop or the governance of that state data start and stop, and where does my own personal data governance come into play? How does the acceptable use policy apply to all of this? It's been an interesting roll out for sure. We've had a lot of feedback. I know that some of my piers in other states have taken the approach of just simply locking everybody out, and we considered that in Delaware. We considered it very seriously, but we decided we wanted to have a more customer friendly approach and find a way to balance to the security requirement with the needs of our customers. I think we've come up with a way to do that.
CHABROW: When you talk about remote wipe, what are the conditions that the data would be wiped out?
STARKEY: The first good example of that is if it does and it gets in the wrong hands and there are seven failed attempts to log into the system, it automatically wipes. That mirrors our BlackBerry policy already. So if someone is a fat-finger typist, they are at risk. It's a protection for just if it gets in the wrong hands that device would be protected and secured after the first time. The other ones are more what we are hoping to be far less frequent then that, but if there is some type of risk, some type of exposure, something that can be tied back to a device, we just reserve the right to kind of take that device off of the network, and if necessary remotely wipe it. We're hoping not to use that very often, but we need to reserve the ability to do that if needed.
CHABROW: The wipe policy, to some seems Draconian especially if you have your own personal information in there, but is that the best alternative? Would just locking out not being sufficient?
STARKEY: We would certainly consider that; it would depend on the situation. If we needed to just simply lock that device down and we had the ability to troubleshoot it in a different way, we would certainly want to do that. We realize that remotely wiping, we can't separate the personal data and the work data, and we have to wipe the entire device. That is not something I want to do very often. But like I said, we need to reserve the ability to do it if needed.
CHABROW: What were some of the privacy concerns that employees raised about their own information on their devices? Did you do anything to assure them that their personal information will be private, or is there nothing you really can assure on that?
STARKEY: Yeah, we have assured them exactly that, and the way that we've done that is to be very clear where the acceptable, the state acceptable use policies starts and stops. Data acceptable use policy is there to govern state data, state transactions only. Whether it is a phone call or an e-mail or a data file or whatever, we do not intend or do not want to, and it is impractical to think that we would be out there monitoring personal phone calls or personal e-mails or anything like that. That is not our intent at all. The user has made the decision that they want to combine their work and their home on to a single device and we respect the fact that work is work and their personal things are not under the state acceptable use policy.
CHABROW: And that use policy does define that certain private personal information remains personal?
CHABROW: When are you going to be reviewing this? How many months out will you say this is working or not?
STARKEY: The first example I use is a little bit easier to measure kind of in an out weeks and out months because we've already identified one hundred and one e-mails that potentially would have left the state network. Prior to us implementing the blocking tool would have, and since Nov. 1 has been blocked by the new filter. We're going to be watching that number closely because what I expect it do is probably grow a little bit more as people become educated and understand how to use the encryption tool and all that, and then I'm looking for a downward trend to that number so that there are no longer even attempting to send the Social Security number out. So remembering to mask it or remove it before they click send. The smart phone one is a little bit harder to measure. I just know quite frankly every e-mail that came through that said I don't really need to do this. It's not real important to me; take me off your list. With every removal of that, in my mind, we removed a significant risk. Those of us in the security business know we can always find a way to remove the risk which is to shut people out and lock things down, and this approach we wanted to take was a kinder, gentler approach to at least give our employees the option to do this while still maintaining the proper security controls.
CHABROW: Why is that the proper way to approach it?
STARKEY: It's not the only way for sure but from the research we did, I worked very closely with the National Association of State CIOs and the Multi-State Information Sharing Analysis Center. I talked to a lot of other states to see what they are doing, and in my opinion this was the best practice model that emerged. In fact, earlier this year NASCIO took some of the results of our survey and published a white paper called Security at the Edge Protecting Mobile Computing Devices. It has a lot of the, not only what Delaware is doing, but other states what we're doing to try to close this data leakage issue.