Breach to Nowhere

Will that data breach be the end of your career? Managing information security in higher ed requires more than just technical expertise, especially when the heat is cranked up.

• By Dian Schaffhauser
• 03/01/09

FOR MONTANA STATE CSO Adam Edelman, providing 'meaningful metrics' helps people understand the nature of the threats faced in a university environment.

IN OCTOBER 2004, Purdue University (IN)suffered a hack attack that compromised the Social Security numbers (SSNs) of 85,000 staff and students. Then, in March 2005, the personal information of 1,200 employees, students, graduates, and business affiliates was exposed. When May of that year rolled around and a hacker made off with another 11,360 records, an editorial cartoon appeared in the Lafayette Journal and Courier portraying a worker holding a hammer next to a flip-sign with numbers, proclaiming "Purdue University has worked 14 days without a computer system being hacked!!"

A signed copy of that cartoon now hangs on Scott Ksander's wall, daily reminding the university's chief information security officer: "Never again. That's inspiration, not just bad memories for me. We're better than that now," he asserts.

The fact is, when sensitive data are exposed--whether through hacking, the loss of computer hardware, outright theft, unwitting online posting, or some other reason--the people in charge of information security find themselves in the middle of the turmoil. Even if the breach goes against everything they've worked to manage on campus, others may believe that responsibility for the attacks ultimately resides with them.

But rather than viewing identity theft and other such incidents as potential career-busters, this security expert appears to view them as just the opposite--opportunities "to leap forward."

"Every day is an adventure," laughs the CISO. "I thrive on the adrenaline rush of the whole thing." Ksander also is the executive director for IT networks and security and a sometime-professor of computer forensics at Purdue. "You get dumped into a situation, and people around you are getting crazy. If you can take that and put some order to it and feel you contributed, that's a good job to have."

Adam Edelman, chief security officer for Montana State University, is a bit more circumspect. "Challenges will always be there. Opportunities are there, too." The Bozeman-based school where Edelman operates faced its share of challenges in late 2007, when four separate breaches were uncovered, possibly exposing data on about 1,700 individuals.

Through it all, he says, he tried to be proactive-- first, by engaging university technical staff who could assist the security department in analyzing and securing the vulnerabilities and, second, by communicating with the campus administration. "Call No. 1 is to the CIO, once we think something is happening. I know he'll also assist by speaking to other VPs, maybe give the heads-up to the president if he thinks it's necessary. Then I speak to the head of the affected department. I make sure the communications folks are aware: 'Hey, this is what's going on.'"

Edelman explains that for those conversations to be successful, a large amount of his effort during less stressful times is spent "developing relationships with and earning trust from our higher administration, folks out and about running systems, and folks who are department heads. So when I call, they don't say, 'Who is this?'"

Working the Process at Purdue

When a potential breach is discovered at Purdue, says Ksander, institutional policy specifies that the Computer Incident Response Team be immediately notified, whether via web page, e-mail, or phone. That team, comprised of a cross-section of individuals in the central computing organization, then begins its investigation, trying to nail down what happened, what facts the university has regarding the problem, and what the impact is on data. "If it's a breach, that requires that they notify me," says Ksander. "Then I get involved personally."

Under Indiana breach notification laws, for specific types of exposures, the institution has three business days to notify certain state agencies, including the Office of the Indiana Attorney General. The process then moves from reporting the incident to remediation, which includes figuring out how to close the security hole and notify the appropriate people, including those who might have had their information divulged. That part of the process can take quite some time, says Ksander. If the breach involves one of the campus's distributed systems, the IT people who administer those get involved. Once the remediation is over, the response team does an "after-action" report that looks at what was learned, what went wrong, and what went right.

"We're to the point now," he says, "where we've been doing it long enough that we have a pretty good rhythm to it. I won't say nothing new ever happens, but the times when we don't have a procedure are getting fewer and fewer."

Purdue also has a policy of being "very public" when a security breach occurs. "We have decided to be out there with everything we know," Ksander says. "I would much rather tell you what's going wrong even if it looks bad, than have you find out and add to that the implication that we were trying to hide [something]." As with Edelman at Montana State, that makes him the point person for communicating with the university's news service, department heads, and campus administrators.

Ksander never forgets that the 2004 breach at Purdue exposed a lot of SSNs-- including those belonging to the university president and to Ksander himself. "We were in the paper being publicly humiliated by our local press," he recalls. "But to be perfectly blunt: Not without cause."

So when Ksander finds himself having to explain a security breach to university executives, he goes into the conversation with the intent of helping the administrators understand, not trying to defend himself or his own career. "They're very smart and very talented people, but IT isn't their specialty," he says. So he keeps his focus on the action plan, letting them know that he is technically on top of what has happened, and that his team has "got this covered." His primary goal is to help them have confidence in his group to manage the problem quickly, and thus "to have confidence in me." A secondary goal: to get across "a few tidbits of understanding-- and not to say that this is never going to happen again. Sometime, somewhere, this is going to happen again."

Through it all, he says, "I don't see any reason for these to be career-defining moments."

Risk Management at Montana State

Edelman takes it a step further, explaining that he provides "meaningful metrics" that will help people understand the nature of the threats faced in a university environment. Such metrics might take the form of a dashboard that an executive with limited time can look at and say, "Oh, I understand that."

For example, he says, a dashboard might lay out that 500,000 port scans are coming to the network looking for holes every day and that those scans hit 350 servers. "Of those scans, 10,000 are focused attacks with humans on the other side, developing specific URL strings, looking for SQL injections."

The value of that approach, Edelman explains, is that "It helps the people who lead your institution to understand where the risk is, so they can make educated decisions. They may not be the right decisions, but they're educated ones." If that kind of insight is lacking, he says, then "Maybe there is a performance issue. If there's a significant breach that could have been avoided and you haven't done your part to help people choose to address it or not, then maybe you ought to be worried."

::WEBEXTRAS ::
Want to know more about Purdue incident response? Go here.