Architecture and Implementation Best Practices

Visibility and Monitoring

No control will withstand an adversary forever, so the ability to know that failures have occurred is necessary to be resilient -- that is, to prevent an adversary from advancing further, you must take action, which requires knowledge. Reviewing logs builds a better understanding of normal and abnormal events, which leads to better alerting. And, higher-quality alerts spot threats faster. Good visibility also removes operational risk from Least Privilege and Default Deny implementations. It is easier to gain support for disabling software features and blocking network traffic with proof that neither impacts business functions.

Expect attackers to manipulate logs and network traffic data. It is best to securely transmit events to central storage systems as quickly as possible after generation. Central log analysis and storage systems are mission-critical. Treat any systems processing or storing events as highly sensitive. All the best practices described should be applied to those systems as well.

While planning visibility and monitoring strategies, consider where compromise might occur and how that will impact visibility. Architecting multiple monitoring points that should tell similar stories creates the ability to detect compromise even if some of your monitoring data gets affected by a threat. Numerous monitoring points also offer higher fidelity logs and better analytic results.

Least Privilege

The principle of Least Privilege restricts users’ access to the smallest set of capabilities required for normal operation. Ideally, apply Least Privilege to all users across all applications and services. Whenever possible, limit access based on identity, job role, location, time, and any other criteria that make sense for the organization. Do not forget user identities that aren’t associated with human beings. Service accounts used to run applications should also carry the minimum necessary permissions. Implementing Least Privilege makes it more difficult for adversaries to gain privilege and access credentials.

Implementing Least Privilege often generates anxiety among teams. Expect fear that restrictive policies generate some lost productivity for users. Not all these fears will be unfounded. Use log analysis to guide policy creation and measure risks associated with Least Privilege implementation. Good visibility and monitoring strategies lead to successful deployments. Least Privilege will sometimes introduce momentary delays to some users’ work, but this loss is often trivial compared to delays caused by a compromise or breach.

Default Deny

Default Deny is a type of Least Privilege associated with access control policies. Found in networking equipment, security gateways, and application control systems, access control policies will have a default rule applied when no other logic is matched. For resilient defense, security policies should deny activity by default.

As with Least Privilege, analyzing events observed through visibility and monitoring strategies makes implementing Default Deny easier. Do not rely only on the network filtering options offered by applications and systems. Layering security gateways with built-in filtering options forces attackers to compromise multiple systems to gain full access. Security gateways may also offer access to higher-layer enforcement. When applications are compromised, so are any controls they enforce. Application layer policies at a security gateway can maintain enforcement when applications are compromised, further hindering attackers. Default Deny slows attackers’ lateral movement, buying time for defenders to catch and remove threats. Default Deny also offers additional visibility options and the opportunity to create high-value alerts.

Segmentation

There are many ways to design a network. It is tempting to create open networks where all hosts can communicate freely with any other. The broad accessibility of open, permissive networks is convenient, but this convenience extends to attackers making these networks easy to maneuver. Dividing networks into logical or physical subnets creates more points of visibility and hampers attackers. To achieve goals in segmented networks, attackers must spend time compromising additional defenses after gaining initial access. Segmentation increases the time required to turn a compromise into a breach giving defenders more opportunities to stop attacks before they are completely successful.

Configuration

Software manufacturers tend not to ship products applied with the best possible security configuration. There is no malicious intent in this reality. Making flexible, feature-rich applications for a wide range of users makes it impossible to craft one perfect configuration for all possible use cases. It is important to review and harden configurations based on the specific workloads performed. Governments, third parties, and vendors produce hardened configuration options for several solutions. All offer potential starting points to harden a configuration but are not a substitute for understanding configuration options and features of the applications themselves. Hardening configurations is ultimately a balancing act between usability and resilience. Having a greater understanding of how an application works leads to better configurations. When all else fails, develop configurations that improve implementations of default-deny, Least Privilege, segmentation, and visibility.

Perfect: The enemy of good, and defenders

There is no perfect application of these best practices. Attackers will constantly develop new threats and improve their capabilities. Money, politics, and time will work to complicate defensive operations. Creating resilient systems capable of withstanding compromise and preventing a breach takes continual effort. Every incremental improvement is an opportunity to thwart some failure, even if it doesn't thwart all failures.

At times best practices will appear difficult or impossible to achieve. In these moments, ask, do we need this? “This” can be substituted for almost anything.

• Do we need to let all users access firewall administration?

• Do we need to let our servers open connections to any client workstations?

• Do we need to turn on every feature on our UTM device?

Where the answer is no, respond accordingly. For the examples above:

• Restrict access to non-administrative users.

• Block servers from connecting to workstations.

• Disable any feature on the UTM device that is not necessary.

Doing so implements Least Privilege, Default Deny and hardens the configuration. These may not be perfect applications of the practices, but every action to improve resilience, however small, makes the attacker’s work harder.