Heat maps: not quite so hot anymore?
On the face of it, a colorful heat map looks like a great way of visualizing the risks that could affect an enterprise. They’re easy to produce from spreadsheet data and they provide a simple view of the potential impact and likelihood of a range of risks, that can be used to help raise awareness of risk generally and to communicate the risk assessment to senior management.
So what’s wrong with heat maps? Why are security professionals cooling in their attitude towards them?
Because, as I’ve said before, the two-dimensional view of risks based on severity and likelihood are no longer enough.
Old School Risk Heat Map
Enterprises need to go far beyond the focus on inherent and residual risks that’s typical of a heat map and incorporate more dimensions, including assets, threats, vulnerabilities and controls. They want to look at risk relationships and mitigation tracking, with an approach to risk analysis that enables a quantitative assessment of all risks to all parts of the enterprise.
Although risk management information systems (RMIS), enterprise risk management (ERM), business continuity planning and crisis response are all specialized areas in their own right, the lines between them are starting to blur as the realization dawns that these management areas are all fundamental to an enterprise’s ability to survive and thrive.
A spreadsheet-driven approach is simply no longer up to the increasingly complex risk analysis job—and can even become a risk in itself. As Chris Duncan puts it, it’s like being armed with only a rock in the middle of a gunfight: you soon realize you need a lot more firepower.
So what’s the answer?
Heat maps can’t give you a rounded view of risks. Good risk management involves taking external and internal perspectives and modeling risk in relational diagrams, decision trees, heat maps, or even quantitative models involving at-risk simulations. So heat maps are one view but they’re not THE view.
Think about the difference between the Google Maps ‘Map View’, ‘Satellite View’ and ‘Street View’. It’s Street View that will give you the most comprehensive view of the location you’re searching for, letting you pan around to see not only the building you’re looking for but also the environment you’ll be entering.
In much the same way, when it comes to risk management, you need to use multi-dimensional models that let you view risk data from different perspectives and enable creation of risk intelligence, so that you can make informed decisions enhanced by risk simulations from quantitative models.
Doing this right also involves combining high performance analytics (HPA) so that, instead of collating the different views on a monthly basis, you can collect, analyze and predict risk outcomes in near-real time. Combining all perspectives in this way means you get a much richer, multidimensional view of risk—and is exactly why using just a heat map is an archaic idea. A possible multidimensional view is represented in the above graph.
In the end it becomes possible to see the effect of each risk on different areas of the enterprise. Each enterprise domain—such as IT, legal, finance, operations—can view each risk and determine, for example, how the domains intersect; whether it’s a geopolitical risk; whether it’s an external or an internal risk; who is responsible; and what the impact on the enterprise will be in financial, reputational or other terms.
New RSA Archer Community and Exchange are live
So we’ve injected fresh energy into our online forums, the RSA Archer Community and Exchange, and moved them onto a new platform. You’ll find they offer more intuitive navigation that makes participation more straightforward, and powerful new features that make collaboration even easier.
Between them, the Community and Exchange provide an active user community and an online exchange of applications, content, services, and integrations. They sit under the umbrella of the new EMC GRC Ecosystem that addresses your broader GRC issues and offers more strategic-level discussions around GRC as a practice.
As a member of the RSA Archer Community, you can achieve value sooner by taking a more direct role in the direction of the RSA Archer product roadmap, and using a platform that’s continually being improved by its most innovative users. You’ll significantly reduce your learning curve by sharing ideas with your peers, as well as getting advice from GRC specialists about strategies and best practice around Archer product use and configuration.
The RSA Archer Community and Exchange are not just places you go, but things you do; participation in them becomes a way of life for GRC professionals.
Discover the RSA Archer Community now >>>
Discover the RSA Archer Exchange now >>>
Your business. Your solution. Your community.
RSA Archer Community
RSA Conference Talks Big Data
I just came back from the RSA Conference in San Francisco where I couldn’t turn a corner without someone talking about how Big Data was revolutionizing the security industry. In fact, there was one session that stood out during the conference for me. It was titled “Managing Advanced Security Problems Using Advanced Security Analytics” where Eddie Schwartz, VP and CISO of RSA moderated a panel comprised of four industry analysts including Scott Crawford, Research Director of Enterprise Management Associates; John Kindervag, Senior Analyst at Forrester Research; Neil MacDonald, VP & Gartner Fellow of Gartner and; Jon Oltsik, Senior Principal Analyst from Enterprise Strategy Group.
The panel discussion covered quite a bit of ground including defining what Big Data actually means, the acceptance within security organizations of using big data analytic techniques as well as the prediction of when security professionals will embrace big data analytics and finally how big data can be the answer to the advanced threat problem with it’s incredible scalability and high speed analytics.
Discussion point that I agree with:
1) Everyone from the moderator to the panel participants acknowledged that the current approach that companies are taking to manage the advanced threat problem fail due to lack of event context and constraints in traditional IT architecture. The panel also pointed out that there are many organizations that are not changing their ways from traditional perimeter based security, anti-virus, etc. due to “what we don’t know won’t hurt us” mentality which leaves the security teams with archaic technology that leaves them with no visibility into the threats that affect their business.
Discussion point that I did not agree with:
1) Heat maps are a must to provide visualization. This is something I cannot agree with as the notion of a heat map is even to a risk professional becoming obsolete as they only provide a two dimensional view into the risks that could affect the business. They are not multidimensional and only provide areas of risks vs. different views into key risk issues with details. I have seen organizations phase out heat maps and phase in multidimensional models that provide a way to view risk data from different dimensions so you get a risk portfolio vs. just pretty colors from a heat map. It also should result in creating risk intelligence so organizations can make informed decisions which can and should be enhanced by risk simulations from quantitative models. What was funny was in another meeting right after the session I was handed a “global threat” heat map of the world which showed different threat colors by country on the size of a business card…..which was of no use.
The conclusion to the session did send me away with a good feeling because what I heard was that by using Big Data it solves many things that GRC programs should do which is breakdown information silos, automate the capture of information, normalize/correlate data and organize the information to be able to respond to risks in an organized/prioritized fashion. Sound familiar? I just can’t wait to see the scale of information capture and speed of analytics better enable the “R” in GRC.
eGRC Summit – June 5-7 in Chicago!
I have participated in the the RSA Archer eGRC Summit in the past and have seen first hand the value of bringing over 600 GRC professionals together under one roof to discuss best practices, learn from each other and also have a great time. I have just submitted to speak at the conference and hope to see all of you do the same.
You can submit your presentation idea here.
Hope to see all of you there this year.
‘I don’t understand what you’re trying to tell me’: Why taxonomy is so important to eGRC
Taxonomy, the science or practice of classification, is all about specifying the relationships between entities and giving them agreed names.
I can’t count the number of times that clashing taxonomies have caused me difficulties: mis-interpreting what a friend is telling me, a boss not being on the same page, my direct reports looking at me like I’m from Mars. I remember a time when I was four years old, around the holidays, asking over and over again for ‘milk yolk’ while my mom tried desperately to figure out what I wanted. After 10 minutes of trying everything, she finally got it when I described what the drink looked and tasted like. I was after eggnog, of course.
As I explained in my last blog, when it comes to eGRC it’s critical to create common processes. A big part of this is providing consistent naming conventions so that everyone is talking the same language and there’s less chance of miscommunication. I gave the simple example of an ‘incident’ management process and an ‘issues’ management process that were identical except for what the stages in the process were called (largely just a difference in using ‘issue’ vs ‘incident’). But of course many taxonomy differences won’t be as obvious or straightforward as that example.
Naming conventions are important because they frame people’s understandings of what’s happening and what they need to do. They let people identify the context quickly and hand off information and activities without going through the palaver that my mom and I went through.
The issue of taxonomy often comes to the fore when you’re assigning labels to elements and workflow activities within software applications that are part of your eGRC strategy. People need to be comfortable with what things are called if they’re to use technology effectively; and it can take months to negotiate these naming conventions. Make sure you allow for this in your planning. Dealing with taxonomies effectively is a critical success factor for eGRC.
Good GRC taxonomy website:
Open Compliance & Ethics Group
Creating consistent processes for eGRC: a negotiation about change
When you’re trying to integrate and align governance, risk management and compliance, where do you start?
With processes.
This has been one of the hottest topics that the RSA Archer eGRC Community has been discussing during the recent eGRC Roadshows that I have been extremely honored to be a part of this fall. The conclusion that organizations have all agreed on is that you need to identify the key processes across your business that relate to enterprise GRC activities, find the commonalities and intersections, and make changes as necessary to create consistency across them.
This is both easier and harder than you might think:
- It’s easier than you might think because the majority of GRC processes across the business will mostly be very similar to one another. People will use different names for things and think that they’re doing something very different from others, but in terms of underlying principles and steps, they mostly won’t be.
- It’s harder than you might think because people won’t want to change what they’re doing. Even if it’s just a name change, eg changing an ‘incident’ to be called an ‘issue’, people will fight hard not to change what they’re used to. Processes and their naming conventions can be really personal; they frame how people think about what they do. If you ignore this and try to be dictatorial about process change, you’ll be in for a hard time. To illustrate my point I present to you two examples of pretty much the exact same process for both ‘incident’ and ‘issues’ management. As you will note, the only thing different is what you call each stage of the process.
Negotiate change
So when you’re setting out to break down GRC silos and create common processes, you need to allow plenty of time to negotiate process change. The role of a GRC advocate or leader is to orchestrate this negotiation, not impose change on people. If you want to be successful you need to help people to their own conclusions about why the change is necessary and not as bad as they think.
This applies even if you’re just changing the naming conventions (taxonomy) associated with processes (I’ll cover taxonomy in a bit more detail in my next blog). It applies even more so if you’re improving a bad or mediocre process, ie making actual process change. Process change is important if your processes don’t reflect best practice, otherwise the danger is that the improvements you make through eGRC will just make mediocre results happen more quickly.
So to reiterate, every eGRC project should:
1. Start with process.
2. Create consistent eGRC processes across the business.
3. Improve poor or mediocre processes.
4. Negotiation change in Taxonomy.
Disaster Preparedness in a Changing Climate
Risk Management Monitor, the blog of Risk Management magazine, has published a guest blog by me, which is a great honor. It’s about some key principles of disaster recovery planning from a GRC perspective. You can read it here . Enjoy!
Why GRC matters to IT security teams
Expectations of IT security have never been higher. I talked about this a bit in my last blog . But if you don’t believe me there’s a great paper by Enterprise Strategy Group (ESG) that nicely sums up why businesses are calling for much more sophisticated, business-oriented approaches to IT security. You can find it here (look under ‘white papers’ in the right-hand navigation area)
So if you’re in charge of IT security in your organization, what do you do to meet these expectations?
If you said ‘convince the business to invest in eGRC’ then you’re ahead of the innovation curve and are taking your program to the next level.
What happens without eGRC?
Organizations that haven’t invested in eGRC are typically mired in manual processes, trying to manage security using Word documents, spreadsheets and email. They can’t connect anything to anything and have to duplicate work all the time. One IT security manager told me that his team asks the operations team to answer questions specific to FFIEC regulations in January; and then in February asks the same questions of the same people for the purposes of SOX compliance.
This kind of thing is happening in a million different ways all the time. A recent article from Computerworld, titled “Feds want uber cybersecurity compliance standard”, illustrates this as well.
It quotes Jerry Archer, CISO at Sallie Mae, who is presenting his IT-GRC strategy at the RSA Archer eGRC Roadshow in Indianapolis tomorrow (October 13). Speaking at the SINET Innovation Summit in Boston, Jerry said his agency spent 40% of its budget on complying with regulations. “What is needed is automating compliance to reduce the bite it takes from the budget,” he said.
The kicker is the response that Jerry’s remark got from Josh Corman, director of security intelligence at Akamai. He congratulated Jerry on the 40% figure, saying: “For some it’s 100%.”
The article goes on to note that “the trouble with regulations is that they drive security architectures and prevent data loss that may have little real impact, while ignoring thefts that could be devastating.”
What happens with eGRC?
So how does GRC help? For one thing, it helps you automate compliance processes and efforts so security teams can focus attention, budget and strategy on the threats that truly matter to their business.
Organizations that have invested in eGRC (assuming they’ve adopted best practices and made careful strategy and technology choices) can:
- Automatically map policies, control standards, control procedures, authoritative sources and assessment questions to one another and see the relations between any and all
- Track the whole life-cycle of security incidents, reliably prioritize incidents in line with business impact and objectives, automatically assign actions to respond to incidents, and report on incidents in a way that provides meaningful business context to senior management
- Identify gaps in compliance and satisfy common compliance requirements with a ‘one-to-many’ approach
I’ve said it before and I’ll say it again: eGRC is about enterprise-wide collaboration, visibility and control. It’s time for IT security functions to lead the charge to achieve these things. Not only is it the only way to deliver value to the business, but it will make life so much easier for you!
Recommended Reading:
The pressure’s on for IT security
I was speaking to a board member of a large investment advisory firm recently about his expectations of the company’s IT security function. He said: “I just need to know that our data is protected, that IT risks are tied back to the business, that we can maintain the continuity of our business operations, and that we can effectively manage our regulatory risks.”
No pressure, then, right!?
The fact is, a lot of senior management teams and boards are getting wise to the fact that they need more closely linked security, risk management and compliance activities. This is why IT security is linked to GRC and their relationship is so important from both a top-down and bottom-up perspective.
Here are some more expectations I’m hearing from C-level executives and board members:
- We want to understand how security events, and our responses to them, tie to our risk profile and remediation efforts at the enterprise level.
- We want to know that our security/IT risk assessments are clearly connected to, and consistent with, our enterprise risk assessment processes.
- We want to understand how security risks are developing so that the future doesn’t take us completely by surprise. And to minimize the chance of a ‘black swan’ event.
- We want to be able to put meaningful metrics against security risks and controls; and define key risk indicators, key compliance indicators, key performance indicators for our security team.
In the end, GRC matters to IT security functions because to meet these expectations you need a level of visibility and control, top-down and bottom-up, that only a sustainable eGRC program can deliver. I’ll take a brief look at what eGRC can mean for IT security in a follow-up blog.
Business continuity as an element of GRC. An illustration
In my last blog, I promised to bring you a case study that illustrates the benefits of applying the best practices of eGRC to business continuity management. So here it is.
We’re looking at a financial institution that provides insurance, retirement and investment products, mainly to cooperatives, credit unions and their members worldwide. As a leader in its industry, this company takes risk management and data protection very seriously. Both its own high standards and the requirements of the regulations that it must adhere to make risk management a company priority.
Why doing the right things isn’t always enough
The company was doing the right things. It was carrying out vendor assessments to evaluate the risks presented by some 250 partners. It recorded policy exceptions, such as applications that wouldn’t support new standards for robust passwords. It was also conducting annual business continuity business impact analyses and had disaster recovery plans for all of its key applications.
Sounds pretty robust, right?
The catch is that all of these activities were standalone processes with outputs held by relevant business owners in emails, filing cabinets or limited fileshares. The company’s IT security and risk management team had little visibility of any of this documentation and had no easy way to identify emerging IT or business risks that might affect business continuity or disaster recovery plans. There was also limited collaboration between the IT disaster recovery team and the company’s business continuity team within its corporate risk function.
Senior business executives had even less insight. They just assumed that IT could get a data center up and running again in a few hours. They didn’t appreciate what might happen if a natural disaster struck. They didn’t really understand the risk or potential impact of a data breach, whether through a vulnerability of the company itself or a partner.
The company knew it could do better. It wanted to remove the various disconnects between business users, IT and senior management. “Our focus was to transition from standalone processes to a more complete company-wide view so that we could make better decisions based on the bigger picture without digging into details first,” says the company’s chief information security officer.
What happens when you integrate and share?
So now the company has implemented a central solution that supports both business continuity and other risk management activities.* It has an integrated tool through which to gather, process, store and report on risk- and infrastructure-related information, including business impact analysis surveys and disaster recovery plans.
Everything is in one place and consistent processes and workflows can be applied to all business areas. Vendor assessments, policy exceptions and other risk-related documentation can all be accessed, reported on, and used to inform business continuity teams and risk management activities. Data from business impact analysis surveys can be combined with metadata about systems gathered through a different process, enabling the company to tie together its system, server and database dependencies. Disaster recovery plans developed with application owners are consistent and, instead of being treated as independent items, can be orchestrated into an overriding plan with priority given to applications based on their criticality.
Senior executives have direct access to a reporting dashboard and can quickly see open risks, vulnerabilities and whether disaster plans have passed their tests. There’s no longer a gap between their perceptions and reality. This visibility has given the IT security and risk management team the ability to justify appropriate investment to fix problems.
And there’s more
The impetus for this company was always the desire to protect its customers and prove itself a trustworthy partner. But it’s also saving a lot of time: a couple of hundred hours from efficiencies in conducting impact analysis surveys; and a 75% reduction in the number of people needed to perform vendor assessments.
So I hope I’ve illustrated my point from the previous blog: a siloed approach to business continuity or risk management is not the way forward; an integrated approach is the only way to get your organization into a best-in-class status among the business elite.
* In case you’re wondering: the solution referred to, which holds all the company’s critical disaster recovery information, is itself backed up to an active offsite instance so that it remains accessible in the event of a disruption taking out the primary tool.
Resources:
