Back to Blog
What You Need to Know About CoreGuard Micropolicies

CoreGuard® is a sentry processor that acts like a bodyguard by checking every instruction sent to an embedded system’s host processor for malicious code—stopping attacks before any damage can be done.

But how does CoreGuard know when instructions are malicious, and when to prevent the host processor from running those instructions? That’s where micropolicies come into play.

In order to determine whether or not the host processor should execute the instructions it’s sent, CoreGuard checks that the instruction complies with a set of predefined security, safety, and privacy rules, that we call micropolicies. These micropolicies are key to CoreGuard’s ability to stop entire classes of attack and prevent host processors from acting in ways they shouldn’t.

To help you better understand this powerful technology, let’s take a closer look at CoreGuard’s micropolicies, how they work, what they can do, and how micropolicy violations are handled.

What are micropolicies?

Micropolicies make up a key part of the firmware CoreGuard runs and can be best described as the brains behind the technology.

Micropolicies are predefined security, safety, and privacy rules that enable CoreGuard’s hardware to determine which instructions it should let pass, and which to block. Micropolicies are small and efficient, providing an unprecedented degree of control over the way embedded systems respond to cyberattacks.

CoreGuard uses micropolicies as a source of truth, crosschecking them against information about the instructions in order to understand whether or not the instructions should be executed. This information is called metadata.

Metadata is information about other data. CoreGuard maintains metadata about every piece of data and about every instruction handled by the host processor. It accomplishes this in two ways.

First, CoreGuard collects metadata from the application that is thrown away during compilation. This information is then combined with metadata that CoreGuard collects during run-time. Rather than waste this valuable information as a typical processor would, CoreGuard uses it to determine whether an instruction should be executed or blocked. (More on this later.)

When metadata is combined with micropolicies, we see exactly how CoreGuard leverages its firmware to inform its hardware on how to protect the host processor. Here’s a quick breakdown in just four steps:

  1. An application sends an instruction to the host processor
  2. CoreGuard takes both the metadata collected during compilation and the metadata collected during run-time and simultaneously checks both against a predefined set of micropolicies that have been installed on the SoC
  3. If the instruction doesn’t violate any of the micropolicies, CoreGuard allows the host processor to execute it as it would normally
  4. However, if the instruction violates any of the predefined micropolicies, CoreGuard will issue a nonmaskable interrupt and provide the system with the information it needs about the violation to appropriately respond

How are micropolicies written?

CoreGuard micropolicies are written in a proprietary language, called “Dover Policy Language.” Because DPL is designed only for the purpose of defining policies, it is extremely lightweight and efficient—most micropolicies are written with just a dozen or fewer rules.

A great example of DPLs efficiency can be seen below in the Read/Write/Execute (RWX) micropolicy. While you can get a more detailed look at the RWX Micropolicy below, at the highest level this micropolicy ensures that nothing is read from, written to, or executed in memory that shouldn’t be. And it only takes a few rules to accomplish.

 

 

If we want to get a better understanding of just how powerful DPL is, we can zoom in on a specific rule within this micropolicy.

 

 

Above, we see the readFailure rule. Here, the micropolicy is telling CoreGuard to check if the instruction it’s been sent is allowed to read from a particular address in memory.

The rule establishes that when an instruction tries to read from an address in memory that is not tagged as “readable,” it will result in CoreGuard issuing a policy violation and the instruction will be blocked.

CoreGuard accomplishes this in two ways: by 1) sending a nonmaskable interrupt to the host processor and 2) generating an SNMP packet which is sent to the embedded system’s violation handler to help it determine a response.

Violation handlers can be programmed in tandem with micropolicies to properly leverage the information CoreGuard sends them. For example, when CoreGuard interrupts an instruction, the violation handler can set the device into a known state, turn off all peripherals, and powerdown. Alternatively, a violation handler might allow an attack to carry out, and begin collecting as much information as possible on the attacker’s activity. Most importantly, CoreGuard provides the type of information developers need to program their violation handlers in ways that make the most sense for their devices, and the environments in which they operate.

How does CoreGuard use micropolicies to protect embedded systems?

CoreGuard’s ability to combine a predetermined set of micropolicies with the metadata it collects during compilation and runtime, is what gives CoreGuard the knowledge it needs to make informed decisions about the safety of each instruction given to the host processor to execute.

As mentioned earlier, micropolicies fall into three main categories: security, safety, and privacy.

It’s important to understand how these categories vary from one another in order to better comprehend how CoreGuard leverages micropolicies to protect embedded systems:

  • Security Micropolicies are focused on providing computing security. Security micropolicies protect embedded systems from the outside world and block network-based attacks that can subvert a system’s processor by exploiting software vulnerabilities in the application or operating system.

    A prime example of a security micropolicy is the Read/Write/Execute (RWX) micropolicy, which comes as a part of CoreGuard’s base set. The RWX micropolicy uses CoreGuard to provide the functionality of a hardware Memory Protection Unit, but at a much more granular level. Unlike an MPU that can only assign permission and memory attributes to a predefined set of memory regions, the RWX Micropolicy can label each word in memory with metadata that indicates whether it is readable, writable, and/or executable.

    The RWX Micropolicy is designed to block attacks that try to manipulate data in a way they shouldn’t. For example, a code injection attack can exploit a software vulnerability (such as a buffer overflow) to introduce arbitrary code that will change the system’s course of execution. The injected code may try to write to an area of memory that is read-only, or execute code when it should be reading data. 
  • Safety Micropolicies ensure devices operate safely in our cyber-physical world and ensures the enforcement of safety rules unique to the device and the application it runs. Because each device will be different, having a unique set of capabilities, and operating in an environment specific to its function, safety micropolicies need to be tailored to each use case.

    A great example of a safety micropolicy in action involves traffic lights, and is discussed in detail in our Safety White Paper.

    Safety In Our Embedded Systems Download White Paper

    In this example, CoreGuard’s Traffic Light Micropolicy is aimed at ensuring valid states in a finite state machine. While you can get a more in-depth look at how the Traffic Light micropolicy works in our white paper, the high-level view is that the micropolicy is set up to guarantee that the lights facing North and South at an intersection are only green or yellow when the lights facing East and West are red, and vice versa.

    If this micropolicy is defied for any reason, CoreGuard will issue a violation in the form of a nonmaskable interrupt to the host processor and CoreGuard will send detailed information about the violation to the system’s violation handler, giving it the information it needs to determine an appropriate and safe response. For example, if a nonmaskable interrupt is sent to the host processor, then a safe response could be to reboot the traffic lights into a known state—perhaps flashing red and yellow lights—and remain in that state until further diagnostics can be done. 
  • Privacy Micropolicies are all about securing communications and preventing the exfiltration of private data. One example of how CoreGuard accomplishes this is through our Taint Tracking Micropolicy which tags private data as “tainted” and ensures tainted data never leaves the device unless it is encrypted.

    This is an effective means of keeping private data safe as the micropolicy dictates that any untainted data that mixes with tainted data will result in tainted data. For example, if someone were to mix untainted data like their date of birth with tainted data like their social security number, than the resulting combination of the DoB and SSN will be considered tainted and not allowed to leave the device.

    Further, the Taint Tracking micropolicy ensures that the only way to remove taint is through encryption. Only encrypted data can leave the device, thus preventing the exfiltration of private data.

CoreGuard is a versatile technology that can be leveraged across a wide range of industries, and its micropolicies are a big reason this is possible. With that in mind, the combination of micropolicies that CoreGuard is deployed with will depend on each individual use case.

Specifics aside, all micropolicies essentially work the same way. Micropolicies define an embedded system's valid rules of operation. CoreGuard then crosschecks metadata about every instruction against those micropolicy rules to determine whether an instruction is allowed to run.

How are micropolicies and metadata protected from bad actors?

Key to CoreGuard’s ability to secure embedded systems is its ability to remain insulated from an attack itself.

While CoreGuard works in lockstep with the host processor to ensure every instruction it runs is one it is supposed to, CoreGuard micropolicies and metadata remain completely isolated and secure. CoreGuard's hardware maintains a strict separation between micropolicies and metadata, and the system's OS and application software. Only CoreGuard hardware can access and run CoreGuard micropolicies.

What Designers and Manufacturers Need to Know About Using CoreGuard Micropolicies

While CoreGuard comes with a base set of micropolicies that require no alteration to your application, Dover also works with customers to create custom security, safety, and privacy micropolicies to meet their systems’ unique needs.

Out of the box, CoreGuard stops 90 percent of network-based attacks thanks to its base set of micropolicies. While you can read about CoreGuards base set of micropolicies on Our Solution page, we’ve re-published them here for your convenience:

RWX MICROPOLICY

The RWX Micropolicy uses CoreGuard to provide the functionality of a hardware Memory Protection Unit, but at a much more granular level. Unlike an MPU that can only assign permission and memory attributes to a predefined set of memory regions, the RWX Micropolicy can label each word in memory with metadata that indicates whether it is readable, writable, and/or executabl

The RWX Micropolicy is designed to block attacks that try to manipulate data in a way they shouldn’t. For example, a code injection attack can exploit a software vulnerability (such as a buffer overflow) to introduce arbitrary code that will change the system’s course of execution. The injected code may try to write to an area of memory that is read-only, or execute code when it should be reading data.

HEAP MICROPOLICY

The Heap Micropolicy prevents buffer overflows and protects heap memory. A buffer overflow is the most common type of memory violation. It occurs when an instruction writes more data to a buffer than the buffer is designed to hold; data fills the intended buffer, and then overflows into the adjacent buffer. Attackers will intentionally overflow a buffer’s boundary to replace data in the adjacent buffer with malicious code.

The Heap Micropolicy prevents buffer overflows by assigning a color to the buffer in which data resides, as well as a pointer to the buffer. For example, blue for the username buffer and its pointer, and yellow for the password buffer and its pointer. The Heap Micropolicy dictates that an instruction cannot write data to a buffer with a color that doesn’t match the color of the pointer to the buffer.

STACK MICROPOLICY

The Stack Micropolicy enforces memory safety by protecting the control structure of the stack frame. A stack is a fixed-length region of memory that stores temporary variables created by each function running in a program. A stack frame is a portion within the stack dedicated to a specific function; it includes a function’s return address, which tells the program what to do next.

The Stack Micropolicy is designed to block a type of buffer overflow attack known as a “stack smashing attack.” During a stack smashing attack, the attacker writes more data to a stack buffer than it is designed to hold. This overflow data can include carefully constructed data that overwrites the function’s return address with a specific address that points to other code in memory that the program was not intended to execute. Modifying the return address enables the attacker to employ a simple hacking technique called Return-Oriented Programming. With ROP, the attacker can hijack a program to execute system-level commands that delete files, change passwords, shut down servers, and do other serious damage.

A function in C contains three sections of code: Prologue, Body, and Epilogue. With the Stack Micropolicy, CoreGuard uses metadata to tag a function’s code and its data on the stack. It then blocks any instructions that attempt to violate the structure defined by the Stack metadata.

CONTROL FLOW INTEGRITY MICROPOLICY

The CFI Micropolicy stops attackers from redirecting the execution flow of a program. A code reuse attack is a security exploit that enables an attacker to execute arbitrary code on a compromised system. Rather than injecting their own code, attackers reuse fragments of code that already exist in memory. In other words, attackers cherry-pick chunks of existing code and repurpose them to do their bidding.

The CFI Micropolicy enforces that all control transfers adhere to a fixed control flow. Metadata for the CFI Micropolicy distinguishes the memory locations that contain instructions, as well as the sources and targets of jumps. All CFI metadata is generated when the application is compiled and is not altered during runtime. If an instruction attempts to jump to a location in memory that is not tagged as a legal location to which the program can jump, CoreGuard will block the instruction from executing.

MITRE’s Common Weakness Enumeration (CWE) list divides 705 known vulnerabilities into seven classes, and CoreGuard micropolicies are designed to stop these classes of attacks, allowing CoreGuard to block malicious behaviors from both known and unknown sources. In fact, building our base micropolicies to protect against MITRE’s CWE seven classes of attacks even gives CoreGuard the ability to defend against zero-day attacks.

Further, these base micropolicies require no alteration to your application. Depending on the specific application of a given device, the base set of micropolicies might be all you need to protect your system. However, designers and manufacturers can work with Dover Microsystems to build unique micropolicies or modify existing ones to better fit their specific use cases. Further, Dover works with clients directly to help them update their violation handlers to effectively leverage the data it’s receiving from CoreGuard to respond to attacks more appropriately.

If designers and manufacturers want a more detailed look at CoreGuard’s micropolicies and the impact they can have on securing their products, the best place to start is with a conversation.

REQUEST A DEMO

 

 

Share This Post

More from Dover

PublishedJanuary 15, 2019

The Internet of Things garnered plenty of headlines in 2018, but not necessarily for the best reasons. While the rapidly growing industry successfully avoided the type of black eye that the Dyn DDoS attack left back in 2016, IoT devices are still...

Cybersecurity Safety Security Privacy