6 Steps to Effective Data Security

6 Steps to Effective Data Security

In this blog post, we’ll identify where today’s data security programs often fail and look at six steps to effective data security. These cover everything from product definition, minimal viable discovery, and services, to telemetrics, metrics as well as threat detection and response capabilities. If you’ve ever asked the question: ‘How can my company reduce insider threats?’ then read on.

You have probably heard something like this before: to implement any kind of meaningful data security, you must first:

  1. Discover your data
  2. Find out where it lives
  3. Catalog who uses it and who owns it
  4. Map its flows and lifecycle
  5. Determine which regulatory / compliance rules apply to it

These platitudes have existed for so long that they are accepted as truth. Be honest – how long would it take your organization to complete each step? Can you plausibly estimate this? Even if you did complete your data discovery effort, why would anyone in your organization care?

In this blog, we explore the shortfalls of discovery-first data security approaches and describe key principles to help organizations shift to value-centric data security.

The Limitations of Discovery-First Data Security

Imagine a manufacturing company that spent its first 6-12 months finding inventory and storing it. No concrete product plans or capital investment in manufacturing – that would simply work itself out once inventory has been bought, stored, and meticulously catalogued.

Sound like an appealing business plan?

This is the approach taken by discovery-first data security. Begin with a long (and comprehensive!) data discovery cycle. Once data is discovered and cataloged, then perform a risk analysis, and only then begin to implement controls to address data vulnerabilities.

In theory, discovery enables a targeted control approach that protects the most sensitive data and results in less business disruption. In practice, data discovery is complex, expensive, and slow. Common challenges include:

  1. Inaccurate milestone dates: there is no good way to estimate how much data exists to be discovered and how responsive the business will be. Further, this indicates a definite “end date” to data discovery; in reality, as the business creates new data, more discovery is needed.
  2. Long duration: many organizations start building an inventory with a top-down interview process. They reach out to senior leaders from across the company, intending to discover what data their organization handles and who “owns” the data. They soon discover that most leaders ignore them. Leaders who engage are irritated by the ambiguity of the interview or unequipped to answer these questions, leading to unending delegation cycles.
  3. High costs: discovery tools can run hundreds of thousands of dollars, with costs increasing for additional scope (structured vs. unstructured, cloud vs. on-premise). Resources must be dedicated to the discovery team and business units. Finally, organizations need to allot resources to maintain their discovered body of knowledge as new data is created and business units change.

What’s the Alternative? Six Principles of Value-Centric Data Security

Prioritizing the discovery element of data security results in the misuse of time and resources. Instead, organizations should focus on the end goal – practical controls addressing data vulnerabilities and threats. Read on to learn the essential principles to start your journey to value-centric data security.

  1. To produce value, first, define the product

Agile and its cousins, lean/just-in-time manufacturing, were born out of the inefficiency of long planning processes and excessive inventory gathering. Both begin by identifying a goal or product, identifying how the product is delivered, and then optimizing the value chain to produce the product quickly and well.

In software development, the product is code that fixes a problem or provides a service. In manufacturing, the product is the widget produced on the factory floor. This realization subordinates specific elements of the value chain (planning, inventory gathering, testing) to the end goal of delivering a usable product.

Data security products are not:

  • A list of sensitive data and where it lives
  • A list of data owners
  • Data classification definitions
  • Data flow diagrams

These are all fine things, but by themselves do next to nothing to protect data. They only become valuable when mobilized through data security controls and user training. Therefore, data security controls and user training, which either directly protect data or help users do the same, are the product.

2. Practice Minimally Viable Discovery

Discovery data, while not bad, should not be the focus of a data security program since it does not create direct value.

Instead, start by addressing obvious security risks with broad controls suitable for all data. Examples include:

  • Alerting on or blocking data moving to personal cloud storage or email accounts
  • Removable media control
  • Automatic remediation of folders accessible to everyone in the organization
  • Quarantining or purging severely aged data (e.g., 2+ years since last viewed)

Organizations should start conservatively with conditions that are unlikely to disrupt legitimate business activity. Even a cautious approach will address glaring vulnerabilities and generate success stories to fuel further growth.

3. Build Services First and the Controls Will Follow

Successful data security controls are supported by layers of governance and infrastructure to ensure they align with business objectives. These layers comprise a service and include:

  • User experience considerations
  • Communications and knowledge articles
  • Exception processes
  • Metrics
  • Telemetry (e.g., ingress or egress APIs)

For example, a control to alert on uploads to personal webmail accounts should:

  • Provide a pop-up educating the user and linking them to secure collaboration guidance
  • Link to exception processes for legitimate use cases
  • Include metrics to signal user behavior improvements to leadership

Each service can create multiple, unique controls and serve as a landing place for data that is discovered.

4. Use Discovery to Enable Telemetry

Well-designed data security services (data access governance, insider risk management, etc.) can consume inputs from data discovery or classification efforts. While discovery on its own is of little value, the service can operationalize discovery-driven insights. These insights could stem from discussions or data owners or tagging done with labeling technology like Microsoft Information Protection.

For instance, an existing control within a DLP service may alert on uploads to personal webmail. After discovering a trade secret and confirming with a data owner, the existing control could be copied and enhanced with a REGEX identifying the trade secret and trigger a complete block, instead of a simple alert.

5. Use Metrics Intentionally

Security organizations often struggle to demonstrate value from their controls. Can be used to not only improve controls but to demonstrate the value the products are creating. This is especially important for cyber board communications.

Each data security service should entertain the following metrics types:

Improve – internally facing metrics to ensure the service is producing intended results. Examples include:

  • Exception request growth (shows how precisely controls were configured)
  • Time to close (for detective controls)

Impress – upward metrics designed to show the success of your program and obtain more buy-in

  • Volume-based (amount of aged data purged, number of overly permissive ACLs remediated, number of unsanctioned cloud service uploads blocked)
  • Success stories (egregious incidents contained or organizational processes improved due to insights from the service)

Invoke – upward metrics showing service weakness to garner additional funding or support

  • % of environment visible (could be used to support buying additional software)
  • Escalation response time (may highlight unresponsiveness from leadership, requiring re-assignment of responsibilities or additional support from program sponsors)


6. Enhance Insider Risk Management capabilities

Data detection and response capabilities (best manifested in Insider Risk Management) are quickly becoming the predominant data security service. There are a few reasons for this phenomenon:

a. Follow the leader: for close to a decade, the security industry has shifted from a prevent-centric to detect/respond paradigm. This is evidenced by the growth of threat hunting and the literal inclusion of “detection and response” into new product and service names (EDR, MDR, etc.). While discovery and prevention have their place, they struggle to keep up with large, complex, and hybrid operating environments.

b. Boundaryspanning improvements: security services that demonstrate the broadest value statements get the most support. More than any other security service, Insider Risk Management (IRM) is holistic and seeks to understand why employees violate policy instead of just addressing incidents. Insights gleaned from asking “why” can improve not only security controls, but user training, employee retention, and satisfaction, and the alignment of technology offerings with business needs (shadow IT).

c. Scalability: the core of IRM is people and process, meaning that technology is rarely a barrier to entry. No CASB, DLP, UEBA, or SIEM? No problem. Start by assigning responsibilities and building repeatable investigation and escalation processes. Stretch current technology to provide as much incident visibility as possible. As the IRM service matures and gains political capital, invest in technology to increase visibility and integrate it into existing processes.

Want to learn more about maturing your insider risk management program? Download our latest ModernCISO Guide, A Four-Step Framework for Managing Insider Risk, for a deeper dive into the topic. Or contact a member of Kudelski Security’s team of data security experts today info@kudelskisecurity.com.

MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps

MITRE ATT&CK & D3FEND: Step-by-Step Guide to Closing Security Visibility Gaps

In this article, summarized from a recent managed detection and response webinar, we’ll explain what MITRE D3FEND is, how it complements the MITRE ATT&CK framework, and how you can use it to identify and close gaps in security visibility.

It’s no secret that cybercrime is on the rise with attacks happening more frequently and for higher and higher profits. Tuning our threat detection and response capabilities is more important than ever. But, as with most things in cybersecurity, that’s easier said than done.

One of the primary roadblocks to better threat detection is understanding your security visibility priorities and any gaps you may have within that visibility. Trying to get visibility into every single thing happening in your environment, however, is expensive, and for most organizations, impossible.

Fortunately, there are some really valuable frameworks out there like MITRE ATT&CK and MITRE D3FEND that can help streamline threat detection capabilities. These are free tools that anyone can use in order to prioritize detection and close security visibility gaps.

Read the blog: “Four Roadblocks to Faster Threat Detection & Response”


MITRE D3FEND is a new project from MITRE, the creators of the well-known ATT&CK framework, that establishes relationships between attack techniques, countermeasures and digital artifacts. From the MITRE website:

D3FEND is a knowledge base, but more specifically a knowledge graph, of cybersecurity countermeasure techniques. In the simplest sense, it is a catalog of defensive cybersecurity techniques and their relationships to offensive/adversary techniques.

The D3FEND matrix

The D3FEND matrix categorizes countermeasure techniques into five stages of defense:

  1. Harden – application hardening, platform hardening, credential hardening, message hardening
  2. Detect – network traffic analysis, process analysis, file analysis, platform monitoring, identifier analysis, message analysis, user behavior analysis
  3. Isolate – network isolation, execution isolation
  4. Deceive – decoy environment, decoy object
  5. Evict – credential eviction, process eviction

Each countermeasure is mapped to related MITRE ATT&CK techniques as well as any artifacts generated by the associated ATT&CK techniques. For example, the MITRE ATT&CK initial access technique of “Spearphishing Attachment” (T1566.001) would produce a MITRE D3FEND artifact of “Inbound Internet Mail Traffic” (D3FEND Artifact):

Figure 1. D3FEND inferred relationships for a spearphishing attack


D3FEND is a fairly new project that MITRE says is still in an experimental phase. We still find it incredibly valuable, especially when used in conjunction with the ATT&CK framework to prioritize security visibility requirements – and in the future, potentially even guide organizations in improving their resiliency by reducing attack surface.

MITRE ATT&CK – A knowledge base of attacker tactics and techniques

If you’re familiar with the ATT&CK framework, which I’m assuming at this point most of us are, you know that it’s an offensive model that looks at relationships between known threat actors, the techniques they used to perpetrate their attacks. Additionally, MITRE has categorized techniques into “tactics” which map roughly to stages in the cyber-attack killchain. MITRE also provides some (somewhat limited) guidance around mitigations and data sources to leverage for detection and mitigation, but those really just scratch the surface and have been fairly focused on endpoint telemetry.

MITRE D3FEND – A knowledge base of cybersecurity countermeasure techniques

D3FEND is the defensive counterpart to MITRE ATT&CK, providing countermeasures that can be implemented to harden defenses and detect, isolate, deceive, and evict attackers from the environment.

The connective tissue between the two frameworks are the digital artifacts that particular attack techniques generate. The techniques attackers use will produce some kind of digital evidence such as logs, network traffic, newly created user accounts, changes to email rules or application configurations, etc. Knowing which artifacts to look for allows us to implement the appropriate security visibility to detect threat actors abusing those techniques. Additionally, understanding where an attack technique falls – within an attack killchain – allows us to prioritize countermeasures and disrupt attackers as early as possible.

Watch our recent webinar to learn how to strengthen your threat detection and response capabilities

A Step-by-Step Guide on How to Use MITRE frameworks to prioritize and close security visibility gaps

Step 1 – Define your cybersecurity threat model.

First things first, you’re going to need a threat model. Without this, you’ll end up spinning your wheels trying to stop every potential threat to your organization. Threat modeling allows you to narrow in on the actual threat actors that may be targeting your organization based on factors like industry sector and geographic presence. Knowing those adversaries, you can better understand their objectives and which MITRE ATT&CK techniques and tactics they might use against you to compromise your environment and achieve their objectives.

At minimum, your threat model should accomplish the following five things:

  • Provide you an understanding of threat actors targeting potentially targeting your organization
  • Provide you an understanding of threat actor objectives (corporate espionage, financial gain, data theft, causing physical harm, etc) and a rough understanding of how threat actors attack (which techniques & tactics they use)
  • Mapping ATT&CK techniques to your technology stack – and understanding which are applicable to your environment (do you use containers? If not, techniques related to Docker containers are not applicable)
  • Understanding your attack surface
  • Some details regarding remediation and risk reduction steps

Step 2 – Prioritize high overlap cyber-attack techniques based on the killchain stage, using MITRE ATT&CK

With your threat model defined, you should have a good understanding of the types of threat actors targeting your organization, and you can start to identify where there is a high overlap of MITRE ATT&CK techniques these different threat actors using at each stage of the killchain.

Let’s say your threat model identifies APT28, more commonly known as Fancy Bear, as a threat actor that may be targeting your organization. You can reference the MITRE ATT&CK database to find the common techniques leveraged by APT28 to perform reconnaissance, gain initial access, establish persistence, etc.

Unless you’re very lucky, there’s not just one threat actor targeting your environment. So the next step is to cross-reference the techniques used by Fancy Bear with the techniques used by other threat actors to see if there are any techniques with really high overlap.

At Kudelski Security, we’ve developed a tool that helps speed up and visualize this cross-referencing step. In the example below, we can see that 42 of the threat actors we think are targeting our organization are leveraging Spearphishing Attachments to gain initial access. If we can prevent or detect a technique that’s very early on in the attack chain, then we have a much better chance of reducing the overall impact to the organization. For that reason, maybe Spearphishing Attachments should be our highest priority from a security visibility and detection perspective.


Figure 2.  A screenshot from Kudelski Security’s threat modeling tool that shows high overlap attacker techniques based on the MITRE ATT&CK database

Once we’ve gotten really good at detecting Spearphishing Attachments, we may want to move on to detecting users clicking on Spearphishing Links, then maybe Drive-by Compromise and so on. If you can understand where attackers are succeeding and the techniques that they’re using, you can prioritize what your visibility should be.

Learn more about Kudelski Security’s managed threat detection and response capabilities

Step 3 – Understand data requirements for technique detection and create a data checklist

Once you’ve got your list of offensive techniques prioritized, you need to understand the data that’s required to potentially detect each technique.

This is usually where we see the most failures when it comes to threat detection. Either you’re collecting too much data, or you think you’re collecting everything you need to when in reality, really valuable logs (which may not be enabled by default) aren’t even turned on or being collected. This is often the case in standard Windows Active Directory Environments. We talk a lot more about this in our blog “Four Roadblocks to Faster Threat Detection & Response.”

Going back to our Spearphishing Attachment example, the MITRE database will tell us what data we need to collect in order to detect Spearphishing Attachments. According to MITRE, we should be collecting data related to:

  • File creation
  • Application log content
  • Network traffic content
  • Network traffic flow

This becomes our data checklist. If we’re already collecting this data or at least have the ability to collect it, then we know we have what we need to detect this specific technique. Your objective here is to better understand the data you’re sending to your security visibility tooling, identify any gaps you might have and then start closing those gaps.

You will have to balance how easy the data is to collect with how valuable the data is in detecting an attack. Of course, you’ll want to tackle any low hanging fruit. Enabling object access and change logs in Active Directory is pretty simple. Making a change across HTTP web server in your environment when you don’t have centralized configuration management capabilities is not.

Ultimately, you’ll have to decide if the juice is worth the squeeze. If a complicated change could give you better visibility into your overlapping techniques, it may be worth considering.

Step 4 – Prioritize your attack mitigations, using MITRE D3FEND

As the saying goes, the best offense is a good defense. With steps 1-3 complete, it’s time to think about how you can prevent these types of attacks, applying mitigations or countermeasures designed to stop specific techniques from evening working in the first place.

Let’s look again at the MITRE D3FEND countermeasure database for the Spearphishing Attachment technique. You can see that there are 18 potential countermeasures that could either harden, detect, deceive or isolate the attack.

Figure 3. The 18 MITRE D3FEND countermeasures for spearphishing

That’s a lot to take on at once, so we recommend prioritizing mitigations with these four things in mind:

  1. Mitigate techniques early in the killchain – the earlier in an attack campaign you mitigate, the less impact to your overall environment
  2. Prioritize based on value and ease of deployment – don’t tackle the hardest thing first, even if it’s the most valuable
  3. Leverage available audit modes and early adopters – Some mitigations may impact the way your users are used to working. Your job is to reduce risk while also ensuring your business can still function. Leverage “audit” modes of preventative tooling to understand the potential impact of a mitigation and identify things you need to whitelist.
  4. Consider user experience – build a process internally to handle exceptions to your mitigations

Get in Touch

We find both the MITRE ATT&CK and MITRE D3FEND frameworks really valuable and have incorporated them into our managed threat detection and response capabilities. Our team uses data from both in the internal tool we’ve built to help our team execute threat modeling and identify data requirements as outlined in this post. Though the tool is not a requirement for what we’re recommending, it can help streamline efforts.

If you’re interested in learning more about the tool or our managed threat detection and response capabilities in general, get in touch with our team here.