Yan Noblot, IT security manager for this month's Winter Olympics in Torino, Italy, hopes this is the only time...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
you see his name in print. If his becomes a household name, a digital disaster has disrupted the 16-day event typically shrouded in security. Noblot, a France native who works for systems integrator Atos Origin, says lessons learned from previous Olympiads are essential to keeping threats to a minimum.
What were the highest priorities identified by your risk assessments? There are two main risks. The first, like every corporation, is protection from viruses and intrusions. A virus could be catastrophic; if you have a virus at the wrong time or place, you might have to postpone a competition.
The second type of risk is people with malicious intent trying to piggyback on the visibility of the games. The impact of someone breaking into a scoreboard, or hijacking a feed with their own messages, is bad for the Olympic movement.
At the end of the day, the Olympics is about visibility. For two weeks, everybody will be looking at Torino. We are in a critical mode for only two weeks; we're not like a normal organization.
You were in charge of security for the 2004 Athens summer games. What lessons learned are you applying to Torino? The amount of change that happens in this project is surprising. You would figure it would be a nice, natural project in implementing what you've done before. That's not the case.
In the last 16 months, we've had more than 700 change requests for our IT systems. From a security perspective, you need to put in controls that can adapt to a large number of changes. Security is now a part of the change-control board. No changes are accepted without the approval of security.
The second lesson learned resulted in the implementation of an identity management system. Two weeks before the Athens games, we had to create thousands of accounts. Admins should be monitoring CPU cycles and memory; you don't want them spending nights creating accounts for users.
Going back to Salt Lake City, the biggest lesson learned from a security perspective was around the number of security events--not alarms--that were generated. We monitored thousands of workstations, and hundreds of switches, servers and devices. It was quickly a situation of information overload. We implemented a SIM solution for Athens that did real-time security monitoring.
What was the scope of the security events you managed in Athens? During the 16 days in Athens, 4.7 million security events were generated. We put the SIM system in place and spent lot of time integrating it with the environment; it was a large effort writing the monitoring rules for each specific event. Of the 4.7 million events, 430 were high-level events and only 22 were critical where someone internal was trying to do something against policy. Systems are separated from the Internet by multiple DMZs.
Among the 22 critical events, several were people who unplugged our system and plugged in their own. Other events were people trying to use privileged accounts when they were not supposed to. Those are security policy breaches, and [if you caused one] you were in trouble, whatever your motivation.
Read the full version of this interview with Yan Noblot at searchsecurity.com/ismag.