All corporate reporting roads lead to the corner office. C-level executives are flooded with reams of data and business intelligence: sales figures, operations status checks, inventory counts, financials and stock reports, facility records and so on. To an executive, security reports just add to the stack of paper.
Framing the "security message" in this environment requires a delicate balance between too much and too little detail. It's an oversimplification to say that execs only want to know, "Are we secure?" But at the same time, you don't want to overwhelm them with details that only dilute a report's impact.
Honing an action-oriented security report is half science, half art. The science is rooted in the tools that measure security events: number of breaches and viruses, what was blocked, what got through, the damage caused, and the staff hours and resources used to support security. This is the raw, empirical data culled from syslogs, management consoles and good old-fashioned observation.
The art is the interpretation of the data into meaningful business intelligence that informs, educates and influences executives. Effective reporting means aligning the security data with known business frameworks, bridging the language and cultural divide between geekdom and the C-suite.
The challenge facing you -- the security manager -- is following security report writing best practices that will provide not only the information execs want to receive, but also the intelligence that you want them to see.
Alignment to the Risk Lifecycle
Before formulating a report, you must first know where your organization or projects are in the risk lifecycle.
Risk and exposure change as security programs and specific IT projects mature. Risk significantly increases as projects and organizations move through the strategic (planning), tactical (deployment) and operational (ongoing use) phases.
The reasons are simple. Your risk in the planning stage is minimal, since systems aren't exposed to hostile environments. However, there's still some risk, because the strategic stage is when you can forecast future risks and infuse security into processes and systems as they're developed. Likewise, risk becomes paramount in the operational phases, where systems are exposed to constant internal and external threats, abuses and misuses.
Understanding the risk lifecycle of your business is the key to finding a presentation framework and lingua franca for security reports. You may not realize it, but you and your business executives have similar understandings of what happens in strategic, tactical and operational phases.
Strategic. This stage is when the development of policies and procedures that guide the inclusion and support for security throughout a project's life happen. Risk is minimal, but the steepness of the risk curve will be dictated in the long run by the actions and decisions made here.
Tactical. This is when you ensure that security is built in to applications, processes and procedures. Risk is still a potential, not an actual problem, since project managers are making decisions about platforms, applications and environments. Each decision influences the risk profile.
Operational. This stage is divided into two categories: infosecurity services and active security posture.
Infosecurity services are the day-to-day tasks that maintain an organization's security posture and minimize or reduce risk. They include revising firewall rulesets, maintaining IDS signatures, controlling access to systems, managing tokens for secure remote access and managing cryptographic keys.
Active security posture is the response to external threats such as viruses, worms and intrusions. It also includes recovering from security incidents: removing a rootkit placed on a compromised server, rebuilding a file server after a worm infection, closing a port to prevent exploitation of a newly found vulnerability, etc.
The risks are high in the operational stage, but vary depending on internal controls -- such as depth of security scheme and presence of security solutions -- and external conditions -- such as malware outbreaks, availability of exploit code and the unavailability of patches. It's during the operational stage that security managers must measure the effectiveness of their previous efforts and project what's needed to improve and maintain their security posture.
Corporate executives are time-starved animals. They want information in easily digestible chunks, so they can home in on what needs attention. Once they identify the problem areas, they'll seek additional information to understand and evaluate a problem.
For instance, if you want to report on the organization's compliance with security regulations, such as the Sarbanes-Oxley Act, or with security standards, such as ISO 17799, you would present a report from a strategic perspective. Similarly, an after-action report on a virus infection would be presented from an operational perspective.
Additionally, a comprehensive security report that bridges the three stages can be used to show how ongoing security initiatives and shortcomings are affecting later phases of a project or ongoing operations.
To that end, you need to present two types of corresponding reports -- assessments and activities.
An assessment report answers the main question, "Are we secure?" Executives should be able to glance at the assessment report and get the information they need and the information you want them to see. The goal is to highlight only the issues that need executive attention -- with just the right amount of detail.
Managers of all stripes have a tendency to try to include everything they can think of in their reports to demonstrate their effectiveness, showcase their efforts and highlight their needs. Resist this temptation -- keep it short and simple. Use pithy descriptions to identify topics, and clear and concise explanations to describe their status. Don't try to include every possible permutation, but limit your explanation to two or three bullet points.
A good way to guide your executive through the report is through color-coding. The most common method is the classic traffic light: red for problems (unsatisfactory, action required) yellow for concerns (needs improvement and monitoring) and green for satisfactory (no executive intervention needed).
The activity report details what's contained in the assessment report. When an executive spots an item marked red, he can turn to the activity report to see in detail what you're doing to improve or correct an issue, and what resources you need to get the job done.
For instance, if the top four security issues that account for half of all identified items are coding errors, there's probably a need for improved quality assurance and better training for software developers and project managers. Likewise, reporting the number of intrusion attempts and the cost of recovering from system compromises could justify the cost of better security measures.
Activity reports are also where you brag about your own achievements, and where you provide metrics and explanations about the areas that need improvement. Here, you can talk about the number of viruses stopped, vulnerabilities patched, and the detected and prevented intrusions. It's also where you can highlight many of the routine tasks your security department performs: password resets, access control maintenance, tokens issued, etc. This shows the value of the security program and provides tangible evidence of the return on investment, especially if the data is tied to previous cost assessments for threats and security incidents.
Activity reports don't require the same concision and organization as the assessment reports. They are vehicles for providing copious details, and you should include as much information as you feel necessary to inform, educate and influence your executives.
Beyond routine status checks are periodic trending reports. By extrapolating data from the assessment and activity reports across multiple projects and departments, you can identify certain trends that can show cascading security issues, and forecast future security problems.
For instance, spikes in virus infections in certain departments could indicate a failure to update AV signatures. Or, an abnormally high number of password-reset requests could indicate an overly stringent password policy. Translating raw statistics into trends can unearth security problems, where risks are potentially increasing and where better controls are needed.
By tracking the changes in periodic reports, you and your supervisors can see the progress made toward remediating problems and improving overall security posture.
Beyond conveying information to your higher-ups, you can use statistics and trends to make adjustments in your own policies and procedures. Consider, for example, AV updates. If you're seeing an unusually high number of AV infections, you know you must increase the frequency of your signature updates. If you're receiving complaints about dropped connections or broken applications, you may need to tweak your firewall rule sets.
Trend reports can help managers set priorities and optimize resource allocation by focusing on areas of the network that have the highest vulnerabilities and represent the highest business risks.
Every organization will have different business cultures, operations and expectations. These variables will greatly influence how executives will want to receive security information and reports.
Frameworks such as this are merely guides for organizing and presenting security data. It's important to understand your business's culture, goals and priorities, and align your security thinking and reporting to them. A good place to start is asking your supervisor how he would like the information presented.
Regardless of these differences, understanding risks and data, and being able to organize security reports into easily understandable intelligence, goes a long way in informing, educating and influencing decision-making executives.
About the authors:
Robert Garigue is VP and CISO and Marc Stefaniu is a senior manager of information security analytics and reporting at the Bank of Montreal Financial Group. The information and views presented in this article do not represent the environment or policies of the BMO Financial Group. A version of this article appeared in Information Systems Security (Vol. 12, No. 4), published by Auerbach Publications, and is reused with permission.