Default Deny, Allow by Exception

In the cybersecurity world, “default deny, allow by exception” is almost a golden rule. If you follow it through in your system architecture, boundaries, software stack, you are building towards a “least” functionality that means A) you know what is going on in your environment and B) you have approved it to be in your environment. This rule helps enforce change management and, if used well, will involve security review of the changes before they are “allowed.”

The realities of “default deny, allow by exception” implementation.

In practice, a default deny security posture isn’t common in the real world. Adherents claim that they do it, but cutting corners all too often gets in the way. It is also worth noting that migrating an existing system to an “allow by exception” one tends to be much more involved than building one “right” from the start.

What do we mean when we say, “default deny?” Simply put, nothing can run on your system unless it has first been approved. If one attempts to run an unexpected network service, it is blocked, because it hasn’t been “allowed by exception.” If one opens a new program on their computer— “access denied.” From a security perspective, threats like malware, viruses, ransomware, and data exfiltration software will be unable to run in your system because your cybersecurity team hasn’t approved them.

CMMC Level 2: mapping to compliance controls.

From a CMMC level 2 perspective, there are several controls that this security mindset either leans toward or directly calls out:

• L2-3.13.6 – NETWORK COMMUNICATION BY EXCEPTION – “Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).”
  • That’s pretty clear cut.
• L2-3.4.7 – NONESSENTIAL FUNCTIONALITY – “Restrict, disable, or prevent the use of nonessential programs, functions, ports, protocols, and services.”
  • That isn’t quite default deny, but it is pretty close. If it isn’t essential, disable it.
• L2-3.4.8 – APPLICATION EXECUTION POLICY – “Apply deny-by-exception policy to prevent the use of unauthorized software or deny-all, permit-by-exception policy to allow the execution of authorized software.”
  • That one gives you a choice – allowlist or denylist. Allowlist is a much more secure option, and in NIST 800-171 r3 the option to choose is removed – it is allowlist all the way.

So in practice, how does a mature IT team realistically implement these requirements? Planning, monitoring, reviewing, and getting stakeholder sign off is the basic workflow for this type of implementation. Ongoing maintenance would include review of the approved list (does this still need to be approved?) as well as change management and security review around new additions to your allowlist.

Case study: firewall policy implementation.

Take your firewall for example—your security team can make a monitor only rule on your application aware firewall and export that traffic list after a planned period (say, two weeks or a month). After that period, you will have a large CSV file of all these different applications that you may (or may not) know are running on your network at the moment. Your firewall has likely assigned a risk score to each application. You will be able to see which users are currently using which software and determine what the business case is and the need for the application. The security team can make recommendations based on best practices, business policy, or known risks.

Once you have your security review complete, it is time to go to the stakeholders and let them know what is currently running on their network, what the cyber team recommends to block right away, and potentially discuss things like time wasting applications, bandwidth wasters, data leak concerns, etc. If no one in your business uses a specific file sharing tool, why should it be allowed on your network? Is someone using it in a shadow IT way, or perhaps toward some more nefarious end? These conversations are important; you don’t want to break the business processes of a team simply because no one talked to them.    

Once you have your compiled list of what you want running on your network, it is time to implement the actual firewall policy. Doing so is simple enough: allow what you want to be allowed. Right below that—DENY. Of course, it is a bit more involved than that, but from a high-level overview it is that clear cut. First, learn what is running on your system, then create that list of what you want to continue running and lock it down.

Application allowlisting: from network to endpoint.

In terms of workstation-level allowlisting of software, the process is much the same as the firewall. Application allowlisting software likely isn’t currently in your software stack, but once you add it, it should have a learning mode, a way to export lists of what is currently running, etc. Following through, the process is roughly the same.

Once your system is operational (blocking all non-allowed programs), you’ll need to maintain it. Creating a help desk flow where end users can request access, provide a business use case justification, and ideally a change process involving management approval and cybersecurity approval is ideal. You want your system to last; if you have a “set it and forget it” mindset, it isn’t going to. Make sure you are reviewing your allowlist at least annually (or more often, depending on requirements and policy). Take a look at that firewall rule allowing the application that has had zero hits in 6 months—is the rule misconfigured, or is no one actually using the software anymore?

Implementing strong “default deny, allow by exception” IT security.

Hopefully this post helps demystify the mindset and process of implementing strong “default deny, allow by exception” IT security. Adopting this approach requires planning, buy-in, and ongoing management, but the benefits for your organization’s security posture are substantial, from minimizing risks to meeting modern compliance requirements. If your team needs guidance building or maintaining an allow-by-exception policy, or you’re looking for support integrating these controls into your environment, our experts are here to help. Contact us today to see how our team can support your cybersecurity journey.