Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
12/2/2014
11:20 AM
Kevin T. Reardon
Kevin T. Reardon
Partner Perspectives
50%
50%

The Case for Compelling Executive Dashboards

How to make security relevant upstairs in the C-suites.

Communicating complex security issues quickly and clearly to a non-technical audience is a frequent challenge in our jobs. Dashboards illustrating a positive or negative change in the metrics we track are a common approach, showing trends for threats, attacks, and vulnerabilities. To dress them up, we use gauges, global maps, pie charts, trend lines, heat maps, and other visual cues instead of words and tables. However, in my experience working with customers, these visualizations are often not clearly understood by the intended audience. The executive team leaves a briefing more confused than when they walked in, and the security team often leaves the meeting with no tangible feedback, no sense of ownership, and no ability to take action.

While the data is correct, the message is not applicable to the executive audience. They cannot relate tactical topics such as threats with unusual names, issues with software patching tools, or device vulnerability levels to corporate objectives like growing revenue, managing risk, or specific strategic projects. So I work with our customers to develop dashboards that relate directly to corporate strategy.

For example, I often develop dashboards with customers that focus on managing business risk in four areas: revenue impact, operations impact, regulatory compliance, and end-user education. In one case, revenue was the top priority. So we factored revenue into the other risk areas. In operations, we produced a summary for each major project showing successes, problems, and potential risks to revenue. During the presentations, we could then drill down into details for each project as questions arose.

Similarly, for compliance we looked at what regulations were being met, what controls were in place, the areas of concern, and how these factors and overall compliance could affect revenue and risk. This was especially important for cross-border and cross-regulation issues, where employees could have been in violation just because they worked on data from different projects or different countries.

Finally, how were we doing with end-user awareness and education? Specifically, where was the company at risk from social engineering, and what was the progress and feedback from activities such as social engineering seminars? This approach generated far more discussion and ultimate buy-in from the executives than would have a collection of technical metrics.

In another example, a customer was presenting dashboards with 40 metrics highlighting the problems and issues their underfunded department was having, but they could not get support from the executives. We helped move them to a dashboard that matched 10 core strategic priorities. Possibly the most successful part of this presentation was clearly identifying three of the 10 priorities that could not be supported due to lack of data and funding, and the risk that this presented to the organization in areas of potential outages, security breaches, data theft, or bad press.

As we develop these dashboards, we keep a few points in mind:

  1. It is important to get the story across quickly, so we use big pictures and color to illustrate the key points and draw attention to a key issue or outcome.
  2. Dashboards are not always presented live, so they must be comprehensible and have enough context to communicate well when they are forwarded from one executive to another.
  3. Summaries are great, and sometimes the only part that is presented, but having the details to drill down when questions arise is critical.

Most people talk in the vocabulary of their own jobs, and we in the technology industry are certainly prone to developing a language that can be incomprehensible to outsiders. When presenting to execs, it is necessary to speak in their vocabulary, to align our reports with their priorities. In the end, the words of messaging expert and campaign manager Dr. Frank Luntz come to mind: “It’s not what you say, it’s what they hear.”

Kevin T. Reardon is a Vice President in the Office of the CTO and is responsible for Intel Security's worldwide Value strategy and program. With more than 18 years' experience in the IT security field, Kevin acts as a key advisor to top Intel Security commercial and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
12/4/2014 | 10:19:51 AM
Re: Executive Dashboards...> "ride-alongs"
Great example of bringing "experiential learning" to the C-suite. Be sure to let us know how you make out with your developers. I'm curious to know whether they will be more or less responsive than your C-level bosses. Good luck!
ODA155
50%
50%
ODA155,
User Rank: Ninja
12/4/2014 | 10:07:21 AM
Re: Executive Dashboards...> "ride-alongs"
Marilyn Cohodas,... sure. I have done this before at another company I worked for and currently trying to get it started with other senior IT and business managers... my boss is working on trying to get a C-Level or two to engage. But it all started back in early days of SOX and mandatory compliance, the company I worked for, we were having discussions around password configurations, because there was never any "real" policy there was plenty of push-back when trying to decide what that policy would be. One morning I was with an auditor and an admin "discussing" how many AD accounts to audit with L0phtCrack 4 (LC4) because we would need to expire those passwords and thus forcing users to change them, L0phtCrack exposes the password and weak passwords get exposed faster than stronger passwords. The CEO just happened by my office and heard us and wanted to see what we were doing. Well we chose 100 accounts, after I clicked the Run command there were almost 100 exposed passwords and what remained were exposed in less than 30 seconds. He was blown away, he even asked me to target all of the C-Level user accounts, the results were the same. We (security) got the password policy that we wanted.

After the SQL Slammer and other Malware events around that time, he got directly involved with discussions around the need\requirements for patch management solutions and better AV tools. When I say "he got involved", he didn't take over discussions but he listened, he did his homework and he asked questions. I think the biggest problem he had to overcome was getting used to the view at ground level as opposed to the "high-level" or 10,000 foot view.

I don't think every security topic lends itself to this type information sharing, you have to choose something that directly affects them, get them coming back and then show them how very expensive tools work. I've used CoreImpact and Metasploit to show developers how bad code gets exploited. Now I'm trying to available time for once a month sessions to review production code with these guys, once you get the momentum you have to keep it going.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
12/4/2014 | 7:55:49 AM
Re: Executive Dashboards...> "ride-alongs"
 I suggested a "ride-along", the next time that a Vulnerability assessment or PENTEST is scheduled, invite those c-level people to observe and ask questions, that's powerful stuff. 

Interesting suggestion @ODA155. Is that something you've done with your top execs or heard about at another company? Please share!
ODA155
50%
50%
ODA155,
User Rank: Ninja
12/3/2014 | 1:51:35 PM
Executive Dashboards...
"Communicating complex security issues quickly and clearly to a non-technical audience is a frequent challenge in our jobs."

No, it's impossible and therein lies the problem. Because CEO's and other c-level individuals are so busy (eyes rolling), they want everything to be quick and fast, hence the "Executive Summary". I do understand and do not expect them to understand all of the specifics of Heartbleed, POODLE or why MS14-068 is more important for a Domain Controller than it is for his laptop, but I do expect her\him to expect more than a summarized "Good - Fair - Bad - High - Medium -Low - Red - Yellow - Green" description of serious problems that will\may eventually affect the business, sorry but everything cannot be explained in the time that it takes to ride an elevator.

I believe that C-Level individuals responsible for security or expressing that information to those who are higher up should schedule time with security people so that they can get a (working) understanding of why Drupal announced in October that a Core - SQL Injection vulnerability was so dangerous and that web admins should update NOW and why they (Drupal) came back in November and warned that if your site wasn't patched within a specific period of time... (HOURS) of that initial warning, your site was most likely compromised. How do explain that along with 30 - 40 other issues on a dashboard or an executive summary? You can't, I have a hard enough time trying to get the folks who should understand these problems to understand why these are problems.

Believe me, I do understand the need for brevity but I think dashboards and summaries should be more for that manager who understands what he's reading and knows how to research it and ask questions. Here's a suggestion that I tried before, I suggested a "ride-along", the next time that a Vulnerability assessment or PENTEST is scheduled, invite those c-level people to observe and ask questions, that's powerful stuff.

I guess what I'm really saying is that these folks should be as engaged in the stuff that they don't fully understand as the details of running the rest of the business, we're not trying to make them security experts... just better informed.
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...