Published: 02 Jun 2003
Conversation: Four CISOs explore practical strategies for enterprise-wide risk management, from classification to assessment to monitoring to response.
INFORMATION SECURITY MAGAZINE (ISM): Risk assessment is a fundamental responsibility for infosecurity managers. There are lots of formal models for this--annualized loss expectancy (ALE), cost/benefit analysis, Six Sigma, etc. How comprehensive should a risk assessment be, and should the CISO always follow a formal model?
ROBERT GARIGUE, BANK OF MONTREAL: The CISO probably has the best perspective on technical risks. But their perspective gets a bit murky when it comes to the total picture of operational risk, where the company has to deal with things like legal issues and regulatory procedure. So it's important for CISOs to enter into dialogue with the other "risk communities" in the organization.
The problem is that we don't have a common language. We use either business terms to describe technical risk, or we use technical terms to translate a business risk. You have to recognize critical dependencies and make sure everyone's using the same language.
You have to be very cautious when working with senior executives to ensure they really understand the technical nuances of systems, and the security risks and challenges they present.
Ron Baklarz, CISO, American Red Cross
RON BAKLARZ, AMERICAN RED CROSS: I've walked into situations where there was little or no formal information security before I showed up. You don't necessarily have time to do a formal risk analysis in that case.
BOB WYNN, STATE OF GEORGIA: Methodologies like ALE are not very well suited to IT, which moves too quickly. ALE works better in slow-moving environments.
ISM: On a related topic, is qualitative or quantitative risk analysis a better approach for IT security?
BAKLARZ: Qualitative is much better because people intuitively understand the concepts of high, medium and low risk.
WYNN: I agree. I'm uncomfortable with the present quality of quantitative assessments. I always question how people arrive at either the value component or the probability component.
LESTER JOHN, FLEET SECURITIES: We try to quantify risk when it's feasible. Fleet is already doing quantitative risk analysis for other areas of the business, such as business loss insurance. It's a matter of getting those numbers and saying, "OK, this component is worth this amount, and if it's down, the department will lose this much money per hour per day." For example, as we automate a department, we start to put numbers around processes and systems. Now, if systems in that department go offline, we're not going to be able to fill customer requests. So, we have quantified loss numbers for system downtime, and how much it will cost per hour.
GARIGUE: I don't see qualitative vs. quantitative as a duality. It's more like a curve or a continuum that goes from immature processes that rely on qualitative assessments to mature processes that are more quantitative in nature. For financial institutions, for example, there are significant numbers you can relate to a whole series of activities. But it's very difficult to quantify things like loss of life, privacy, corporate reputation, etc.
ISM: Each of you is responsible for securing a large, distributed infrastructure. There's probably at least some portion of your network that you don't even know about, never mind perform a risk assessment of it. Are you comfortable with that?
WYNN: I have to be comfortable with it, because not all agencies or offices in Georgia are protected by the security group. Some have the option to remain autonomous. For instance, if the commissioner of an agency is an elected official, he can--and often does--run his own shop. I have no assessment authority over those groups.
BAKLARZ: Sure, there are areas within the organization that haven't been critically assessed for risk, but I don't think that's atypical. Our risk analysis approach is very structured. From a network perspective, we typically work on the perimeter first, and then start working our way in. I start at the management level, and put enterprise types of controls and procedures in place. This is followed by the network and host system layers. Lastly, I work my way down to the application and data security levels.
JOHN: We look closely at many areas, but there are some areas we don't pay a lot of attention to. It's all based on a cost model. Security is very difficult to get money for because most businesses view it as an insurance policy. You buy insurance for the things that matter most to you. We adjust the cost of security based on the revenue that a unit or department is responsible for.
ISM: But that might be a problem from the "weakest link" perspective. What happens if that unsecured unit is compromised, and then used as a jumping-off point to the rest of the infrastructure?
JOHN: This goes back to the hard shell/soft shell methodology. The border is everyone's issue, so we protect it. The border is a global cost. But within the border, there are certain areas that are a lot harder to secure than others. That's where individual business unit hardening comes in. So even if a "soft" area gets compromised, it will be contained with its own area.
GARIGUE: I understand making decisions with regard to your value and your protection. You're allocating your costs to your higher assets. The problem is that from an outside perspective, reputational risk will affect all parts of the business.
Y ou take risk because you see opportunities. It's not a technical debate anymore. You have to talk about it in the language of the organization.
Robert Garigue, CISO,
Bank of Montreal Financial Group
JOHN: There are things that you need to protect globally: Reputation, risk, border, privacy, information. What I'm talking about is specific to a department.
ISM: So once you've done your assessment, the next step is to plan your response and countermeasures. To what extent are your decisions guided by regulations and law?
WYNN: In state government, the primary drivers are compliance with federal mandates, such as HIPAA and Gramm-Leach-Bliley (GLB). These are very real mandates upon the agencies to maintain certification and achieve compliance or face criminal prosecution. While the individual regs address things in a stovepipe manner, in aggregate they raise security and privacy awareness throughout the state government. My role is to support the agencies so that we can all achieve compliance within one unified architecture.
ISM: Some security pros like regulations, because they mandate a minimum level of security. Others think they're too obtrusive or impractical to day-to-day business operations.
GARIGUE: They're a good thing. Regulations and their requirements enforce a standard of care around security issues.
JOHN: I agree. Outside of just ensuring the public good, GLB is changing the way companies handle information. In the world we live in--computers in every house, and every kid at age 14 knows how to program--the way information was handled in the brokerage industry prior to GLB was less than secure, and would have opened the industry up to a lot more fraud.
BAKLARZ: From a security perspective, regulations help us get our projects and priorities in place. But the downside is that they sometimes leave too much open to interpretation. For instance, look at the new California privacy law (see "State of Confusion"). Essentially, it requires companies that do business in California to inform state residents if a database containing their personal information is compromised--except if the data is encrypted. But that brings up the question, "What is encryption in the context of this law?"
ISM: Let's talk about the next stage in the risk lifecycle: business continuity planning. Is BCP a CISO's job?
BAKLARZ: In my case, it's currently handled by our operations group. I'm part of the team, assisting in the continuity plans and in recovery. The overall plan has gotten dusted off and tested recently when the terrorist threat level was raised to orange.
ISM: Did the Iraqi war cause any of you to do anything different with BCP?
WYNN: Yes. We are having exercises on physical, cyber and biological alerts, both tabletops and field exercises. The last one we had, we did a tabletop exercise on what would happen if the data center was contaminated with a biological attack. It was a short exercise involving the Georgia National Guard, Georgia State Patrol, the city of Atlanta police and the state office of information security. So, yes, we're definitely doing things out of the ordinary.
GARIGUE: War and the threat of terrorism contribute to heightened awareness of the criticality of business continuity planning. On the cyber side, we're very in tune to all the notices that go out, but I don't think that any of our processes have been significantly modified.
ISM: Another critical stage of risk analysis is threat monitoring and vulnerability assessment. How often do you perform VA scans or pen tests?
JOHN: We do them quarterly, and they're outsourced to a third party. We also do them anytime we're bring in a new application or before we start working with a new vendor.
ISM: How involved are you in the actual process?
JOHN: Very involved, but more with looking at the results and then tracking down exactly where the vulnerability is, what it's about, what caused it and why it's there.
BAKLARZ: I'm extremely involved. On an almost daily basis, I scan my own internal networks and systems using tools such as Nessus, Whisker and Nmap. We back those up with commercial vulnerability assessment tools, and several times a year we contract with outside firms for assessments.
GARIGUE: We've got a whole series of tools, and we do the whole infrastructure quarterly. We do the high-risk areas on the DMZs weekly or monthly.
ISM: How do you prioritize vulnerabilities when you find them?
WYNN: You have to work with the owners of the application or the owners of the data. By cooperating with them you come to understand the value of the data you're trying to protect, and you have to use that information to prioritize your response.
GARIGUE: I see more and more vulnerability analysis moving from the notion of "gap analysis" to the notion of currency management and configuration control. The assessment just tells you where the holes are. The important part is transforming that information into an enterprise management process. Once you discover a vulnerability, that's when the real work begins: How do you bring that desktop or server up to current configuration? Why was an older or unpatched version of the software on that box? Where can I go to get the patch? And so on.
ISM: So how do you learn about newly discovered vulnerabilities?
JOHN: I'm subscribed to most of the vulnerability announcement services. Corporate-wide, we have outsourced this to a third party. They distill these announcements for our platforms and tell us what vulnerabilities affect us.
WYNN: We use ISS's X-Force, NIPC reports and InfraGard on a daily basis. We also get a report daily from the Georgia National Guard.
Security is very difficult to get money for because most businesses view it as an insurance policy. You buy insurance for the things that matter most to you. We adjust the cost of security based on the revenue that a unit or department is responsible for.
Lester John, AVP of Security, Fleet Securities
ISM: Do any of you use a "threat dashboard," a security information management (SIM) system where all this information comes into a centralized place?
BAKLARZ: I am the dashboard.
JOHN: That's pretty much what our outsourced provider is supposed to do. We feed in a lot of our version information, hardware information, software information, etc., and it's supposed to come back with: "OK, these systems exist here in your environment, and because of this, they should be at threat level 'X,' based on this vulnerability."
GARIGUE: We use our own tool that creates a database for system administrators to go and check. There are different levels, different pushes and pulls. If we push out stuff that is very high risk that affects everyone, we alert specific system administrators or specific network managers. We also try to create synergies between the security teams, the information protection center, the application groups and the stakeholders in enterprise network management. We'll let the businesses know that there are exposures and what our plan is to address them.
ISM: How do you feel about your current intrusion detection systems?
GARIGUE: If you don't configure them correctly, you're going to have everyone getting those alerts and pages.
WYNN: We certainly get false positives, and there's no promise that we'll catch everything. But, in general, I'm pleased with the mix of signature- and behavioral-based IDSes we have. We're running ISS's RealSecure, Lancope's StealthWatch, Snort and Enterasys' Dragon.
BAKLARZ: We just got our IDS up and running. We get our share of false positives, but it's eye-opening to see how often our systems are under attack or being probed and scanned. In the first five minutes of IDS operation, we discovered a contractor laptop that was spewing SQL Slammer traffic.
ISM: If you could pass along one wish-list item to IDS vendors, what would it be?
GARIGUE: IDS is still very monolithic in approach. One of the challenges is the fact that we see IDS as a boundary perimeter. I want to extend the boundary. I don't want it just to be on the DMZ anymore. I want it to be on the laptops, on the sales floors--to the point where I extend the security perimeter all the way to the clients at home.
JOHN: We've had huge issues with IDS because of the amount of data we move around. IDS on the external perimeter is great, but if it's not backed up by another event happening on the inside, it's very difficult to say that this is something you actually want to be alerted about.
ISM: One of the last activities in the risk management lifecycle is incident response or incident management. Do you have a formal CIRT in place?
BAKLARZ: Yes, we have a core group of first responders that initially responds to the incident and assesses the damage or exposure. Then we have an extended team that supports the core team by gathering information, notifying affected users, performing recovery activities, etc.
ISM: What role should the CISO have in a CIRT?
BAKLARZ: When I first arrived at the Red Cross, the CIRT function wasn't formalized. I acted as a participant in an incident involving a computer virus simply because I didn't have knowledge of the systems and infrastructure. Now that we have formalized our CIRT and I've been here for a while, I take the lead.
GARIGUE: I don't necessarily take the lead on some of the technical incidents, except when it comes to, for example, Slammer. We're part of a larger emergency response organization that has to do with all the networks and systems.
JOHN: If it's a security incident, security might take the lead in disseminating what the information is and what needs to be done. It should be just a day-to-day process of handling a problem somewhere on the network or somewhere on the system.
ISM: There are two ways to respond to an incident: "pursue and prosecute" or "patch and proceed." It seems that very few companies take the "pursue and prosecute" route for fear of negative publicity.
WYNN: Our Cyber Crime Task Force is made up of the assistant attorney general, the Georgia Bureau of Investigation (GBI), the FBI, the Secret Service and me. If there's an attack, I bring in the task force, and we decide if the assistant attorney general needs to determine whether this is a criminal act. Then we'll proceed accordingly.
ISM: What about the two financial institutions on this roundtable? It seems like you would be much more inclined in patch and proceed rather than prosecuting and making a big deal out of it.
GARIGUE: Well, I wouldn't want anyone to have the impression that we're not going to pursue people who have a criminal intent. I work with my counterparts in other banks and we work with the Royal Canadian Mounted Police, the High-Tech Crime Task Force and OCIPEP [Canada's Office of Critical Infrastructure Protection and Emergency Preparedness]. The same kind of sharing of information goes on to see if an issue needs to be brought to the attention of law enforcement. The difficulty is the data sets that are required in a court of law to be able to make the case hold.
JOHN: If there's an intrusion to our network, we immediately go to our executive and legal groups, and they make the call.
CEOs, CFOs, CIOs--particularly CFOs--are becoming very closely aligned to IT and security development. They're aware that to a large degree IT will drive state government, and they know that with this understanding comes power, influence and the ability to shape things according to their own venue.
Bob Wynn, CISO, State of Georgia
ISM: What do senior executives in your company care about when it comes to IT risk? What should CISOs be communicating to them?
GARIGUE: Senior executives care a lot. They care a lot more than they used to, and they're going to care even more in the years to come. They're very much aware of the regulatory and the client expectancies, and the citizens' expectancies around taking care of the information in their charge.
JOHN: Senior management is more aware of risk, but it's incumbent upon us to put it in a language they understand. That's still the biggest divide: explaining technology risk vs. business risk, and how each affects the enterprise. My industry is concerned about the bottom line, and that's the language I use. But they're becoming more aware.
BAKLARZ: Our senior IT leadership and executive management teams are acutely aware of the importance of security. My caution, however, is that some executives in non-technology roles also consider themselves CIOs. After reading a few articles in the trade journals or listening to vendor presentations, they think they have all the answers. You have to be very cautious in working with this group to ensure they really understand the technical nuances and complexities of systems, and the security risks and challenges they present.
GARIGUE: CISOs are starting to have a chair at the table. We must be able to enter into dialogue with executive management and communicate both the opportunities and the risks. You take risks because you see opportunities, and balancing the appropriate level of risk is what CISOs bring to the table. It's not a technical debate anymore. You have to talk about it in the language of the organization.
WYNN: A few years ago, senior executives wanted the benefit of IT security--but they wanted it in the background. Now CEOs, CFOs, CIOs--particularly CFOs--are becoming very closely aligned to IT and security development. They're aware that to a large degree IT will drive state government, and they know that with this understanding comes power, influence and the ability to shape things according to their own venue.
Moderator Andrew Briney, CISSP, is editor-in-chief of Information Security.