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.

Careers & People

9/29/2014
12:25 PM
Jason Polancich
Jason Polancich
Commentary
Connect Directly
Twitter
RSS
E-Mail vvv
50%
50%

Can We Talk? Finding A Common Security Language

How engineers can get beyond the crippling vocabulary and semantic barrier of infosec and actually communicate about cyber risk with bosses and business colleagues.

Put yourself in the shoes of your CEO.

Good morning, Mr. or Ms. CEO! Quick question -- and I need you to think fast: What’s the top cyber risk to your enterprise this quarter, and how does it affect your business’s bottom line?

It might help to think back to your last status meeting with your security team. In the meeting are all your department heads, including your CFO, COO, CMO, CTO, and CSO.

Imagine that you’ve come to the half-hour set aside for the CSO and his lead infosec engineers, and, on the slides, you see one summarizing your IT security and cyber defense spending over the first half of the year. Things like antivirus, malware detection, and anti-phishing show up, as do $ symbols followed by healthy numbers beside things like IDS/IPS, firewalls, signature detection, log aggregation, netflow analysis, and packet inspection.

Then you see a slide summarizing your top cyber security issues over the first half of the year: words and phrases like Zeus, Citadel Trojan, Backoff POS, Man-in-the-Middle, Dorking, Beaconing, Packet Reflection.

So, what is the top cyber risk to your enterprise this quarter, and how does it really affect your business’s bottom line?

Imagine you still can’t answer? You wouldn’t be alone.

Today’s enterprises, and their CEOs and board members, are increasingly impacted by everyday cybercrime. However, despite swelling budgets and ever-expanding resource allocations, many enterprises are actually losing ground in the fight to protect vital business operations from cyberharm.

While there are many reasons for this, none is as puzzling as the inability of executives and other senior management to communicate with their own security professionals. One major reason for this dysfunction hides in plain sight: There is no mutually understood, shared, and high-level language between the two sides via which both can really connect, perform critical analysis, make efficient and faster decisions, develop strategies, and, ultimately, work with less friction.

In short, it’s as if there’s a conversation going on where one side is speaking French, one side Russian, and they’re working through an English translator who’s using pocket travel guides for both languages.

In other business domains, such as sales or financial performance, there are time-tested and well-understood standards for expressing concepts and data -- in words. For example, things like “Run Rate” or “Debt-to-Equity Ratio” allow those people pulling the levers and pushing the buttons in an organization’s financial operations to percolate up important reporting for business leaders to use when steering the enterprise ship.

This is all made possible by a shared language of terms and classifications.

For the area of business where cyber security and business overlap, there’s no common, intuitive, business intelligence or key performance indicator (KPI) language that security professionals and business leaders share to communicate effectively. No common or generally accepted business terms and metric specifications in place to routinely track, analyze, and express how cybercrime affects a business. And, for the leaders and security professionals alike, this gap affects both sides equally.

How do businesses get things tracking?
There is no silver bullet that will work for every organization. But there are simple, practical ways to help the two sides begin communicating better. To start, enterprises can establish a standard, high-level cyber ontology within their organizations. In other words, create a specification for how cyber concepts are described and tracked. This will enable engineers on the security side to express lower-level, cyber operations information in ways that management can leverage for planning, strategy, and, more fundamentally, good old-fashioned discourse.

Once established, data can be gathered together, mapped to this specification, and then analyzed and exchanged. It sounds simplistic, but too few organizations diligently collect cyber data in this manner, and thus they lose out on the opportunity to create a common language for expressing important concepts.

For example, most cyberthreats and hits that an organization suffers can be expressed in terms of: Who did what to whom (or against what), how it was done, and what happened as a result? For example:

  • Actor
  • Target
  • Effect
  • Practice

From here, as things occur, macro-level categories of items can be created underneath each of the high-level groupings such as:

  • Actor. State-Sponsored, Organized Crime, Hacktivist, etc.
  • Target. Web Servers, Point of Sale (POS) System, Cloud Storage, etc.
  • Effect. Website Downtime, Data Stolen/Leaked, Vandalism, etc.
  • Practice. Network Intrusion, Social Engineering, Malware, etc.

As entries are made, other data can also be added. Enrichment data and simple metadata, such as date and time, and specific micro-level information, such as "Malware: Citadel Trojan," can be entered and then analyzed. Everything from simple summary rollups to time series analysis, and more can then be performed against this data in ways that resemble traditional KPI-driven formats found in sales or financial performance.

What’s more, once data is collected in a standard format, it’s very easy to connect it to KPI-type data from the other key business domains to create insights into how your business, your suppliers, your customers, and more are being affected by cyber events. IT and security budgets become more amenable to fine-grained assessment and continuous quality checks and improvements.

In other words, security engineers and those who lead them can begin to talk the same, shared, data-driven language. It’s a simple, inexpensive approach with big, persistent results.

Jason Polancich is co-founder, app designer and digital marketing lead for Musubu.io. Polancich is also a linguist, software engineer, data scientist, and intelligence analyst. He originally founded HackSurfer/SurfWatch Labs (Pre-VC), a cyber analytics firm founded in 2013 ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
<<   <   Page 2 / 2
JasonPolancich
50%
50%
JasonPolancich,
User Rank: Author
9/29/2014 | 4:58:39 PM
Re: Other Side Of The Coin
Drew,the short answer is yes.there are plenty of approches that can achieve what you describe via the buildout of the model.

creating the core, shared data model as ive described above (and storing data in it, analyzing it) is just the beginning. it isnt even necesary to look outside for a formal framework. in fact, just adding key fields and relationships to related data sets can be even more effective in an in-house solution that, for example, groups types of malware with simple, high-level incident reponse and triage procedures to serve as first-pass recipe system for moving out quickly when new malware beomes active malware.

we have seen big successes where organizations begin to track types of as-yet-unseen malware in and aorund them be able to react more quicky with mitigation by also tracking (simply, of course) what has been done in the past for similar problems. we use a simple "Polarity" metric attached to all our Actor-Target-Effect-Practice tuples, if you will, that map positive, negative or neutral to things like "security research" or "security solution" (as seen here).

this allows for quick sorting and filtering data to isolate things that may be not be active yet or may be the solution side of a problem you didnt yet know you have. what's more, it makes it easy to matrix these items into exploit knowledge bases or in-house incident respone recipes too. it's also great for surfacing to management in a way that tells them what may be out there too and show quantitatively what portion of your strategy these kinds of things occupy. simple data models can be very powerful when extended the right way and when data is collected diligently. not always a need to look outside for a solution either.

 

 
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
9/29/2014 | 3:16:59 PM
Re: Other Side Of The Coin
I agree that this is a really interesting approach to a very entrenched tech problem that goes beyond infosec. My question, however, is whether Jason has used this in practice and how long did it take for people to really start understanding each other?
Drew Conry-Murray
50%
50%
Drew Conry-Murray,
User Rank: Ninja
9/29/2014 | 2:57:54 PM
Other Side Of The Coin
This is an interesting idea with concrete examples. You've focused on the impact of breaches, which is a good place to start. Is there a similar concept for measuring things that didn't happen (i.e. intrusions or attacks repelled) or to measure potential risk and steps to take to mitigate it?

For instance, if you know there's malware floating around that's attacking PoS systems, but you don't yet have data to measure its impact, is there a framework to talk about mitigation (i.e. Hey, maybe we should check our PoS software and see if we're vulnerable)?
<<   <   Page 2 / 2
Commentary
Cyberattacks Are Tailored to Employees ... Why Isn't Security Training?
Tim Sadler, CEO and co-founder of Tessian,  6/17/2021
Edge-DRsplash-10-edge-articles
7 Powerful Cybersecurity Skills the Energy Sector Needs Most
Pam Baker, Contributing Writer,  6/22/2021
News
Microsoft Disrupts Large-Scale BEC Campaign Across Web Services
Kelly Sheridan, Staff Editor, Dark Reading,  6/15/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
The State of Cybersecurity Incident Response
In this report learn how enterprises are building their incident response teams and processes, how they research potential compromises, how they respond to new breaches, and what tools and processes they use to remediate problems and improve their cyber defenses for the future.
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-34390
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel function where a lack of checks allows the exploitation of an integer overflow on the size parameter of the tz_map_shared_mem function.
CVE-2021-34391
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel&Atilde;&macr;&Acirc;&iquest;&Acirc;&frac12;s tz_handle_trusted_app_smc function where a lack of integer overflow checks on the req_off and param_ofs variables leads to memory corruption of critical kernel structures.
CVE-2021-34392
PUBLISHED: 2021-06-22
Trusty TLK contains a vulnerability in the NVIDIA TLK kernel where an integer overflow in the tz_map_shared_mem function can bypass boundary checks, which might lead to denial of service.
CVE-2021-34393
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in TSEC TA which deserializes the incoming messages even though the TSEC TA does not expose any command. This vulnerability might allow an attacker to exploit the deserializer to impact code execution, causing information disclosure.
CVE-2021-34394
PUBLISHED: 2021-06-22
Trusty contains a vulnerability in all TAs whose deserializer does not reject messages with multiple occurrences of the same parameter. The deserialization of untrusted data might allow an attacker to exploit the deserializer to impact code execution.