The Decision-Making Process

The next few pages will guide us through a process that will greatly simplify and enhance our security decisions. Having studied the techniques and theories discussed so far in this book, we will now put them to practical use through the following steps:

Identify the components of a security issue
Identify the risks and threats
Walk through our list of rules, briefly taking each into consideration
Make the proper decision

Identify the Components

When a decision needs to be made, we must first discover and isolate the various components involved. Doing so will help to ensure that multiple aspects of security are considered. Almost every situation we face consists of several important components bound in some form of relationship. A decision about a router affects all its related WAN connections; a decision about a room affects all the equipment in the room; and a decision about a server affects the software, processes, and users of that server. To see all these components and understand their relationships, it is helpful to write them down in a list such as that shown in Table 6.1:

Table 6.1. Security Decision Example
Objects	Example: A WAN Connection
Direct objects	The WAN link itself Data traversing the WAN link Entities connected on both sides of the WAN link
Related objects	The routers The room that houses the routers and where the WAN link terminates The carrier that controls the line

Identify the Risks and Threats

I will discuss risks and threats in much more detail later in this book. For now, I will give simple examples for considering these topics.

Each component considered will have some level of risk and some related threats. Just about everything can have a risk or threat associated with it, but the goal is to identify those that have some significance to the organization. We need to consider each component individually and think of it in relation to the risks and threats involved. We will consider both the risks introduced by a component, as well as the risks the environment poses to that component, as illustrated in Table 6.2.

Filter Through the Rules

Once we have identified the different components and their risks and threats, we need to consider what each rule says about the matter. Would the decision violate one of the fundamental rules? Can we come up with a solution that is effective and follows all the rules? Below I have listed each rule and a series of sample questions to consider for each security situation.

Table 6.2. Component Risks and Threats
Component	Sample Risks and Threats TO A WAN Link	Sample Risks and Threats FROM a WAN Link
WAN	How valuable is this connection to our organization? Do our users rely on its services? Is the data sensitive or valuable?	If the WAN link and its data were compromised, what could happen to the organization? If the WAN link became unavailable, what could happen to the organization?
Room	If the room was compromised, what could happen to the WAN link? If the environment conditions were poor (bad power, heat, etc.), what could happen to our WAN link?	N/A
Router	If the router was compromised, what could happen to the WAN link? If the router failed, what could happen to the WAN link?	If the WAN link was compromised, what could happen to the routers? The routers hold other connections; what might happen to them?
Connected networks	If either entity was compromised, what could happen to the WAN link? If either entity had a networking failure, what could happen to the WAN link?	If the WAN link was compromised, what could happen to the connecting networks? If the WAN link failed, what could happen to the connecting networks?

The Rule of Least Privilege

We should be sure that our decision is made in such a way as to limit all parties and devices to the exact amount of access as is required and nothing more.

Do all subjects involved have the least amount of access to the object as is required?
Are all subjects capable of handling the object securely?
Are we actively enforcing the Rule of Least Privilege and security against unauthorized access?

With the Rule of Least Privilege, it is important to consider access in both directions. Going with the WAN link example, we may consider each question in reverse: Are we allowing only those that require access to access the WAN link? Are we allowing access from entities on the WAN link only to areas that are required?

The Rule of Change

We should ensure that any changes being made are clear, well thought out, and have been coordinated with all affected parties. There should be a formal change process in most security considerations. Some important questions to think about are:

Are we following a formal process, or at minimum, coordinating with all the parties that could potentially be affected by the change?
Have all the changing components stood the test of time? Are we in danger of being a guinea pig?
Are we introducing any completely new objects into the environment? Could a similar solution include technologies, brands, and products already running within the organization?

The Rule of Trust

Most situations, will involve some form of trust. Different subjects warrant different levels of trust that may affect our security decisions. Here are some good considerations to keep in mind:

Are we treating every subject with some measure of security and caution?
Are we trusting any entity more than it has proven to be trustworthy?
Are rules being enforced on every subject involved?
Is there any subject that is granted special privilege that may reduce our ability to maintain good security?

The Rule of the Weakest Link

In comparison with other security measures, we must always be looking for the weakest link in any new endeavor. Any addition or modification to an environment has the potential of introducing a new vulnerability, risk, or threat. New decisions should reflect the Rule of the Weakest Link and be as secure or more secure than other similar decisions.

Has the security of any addition or modification been tested and ranked against existing security?
Are we introducing any vulnerabilities in an area where such vulnerabilities never existed before?
Are the security measures we are applying in any way weaker than security measures we have applied before?

The Rule of Separation

Following the Rule of Separation, we should look at the issue and determine whether or not we are combining objects or subjects that are better off remaining separate. If our decision has to do with enabling a service, installing a new application, or granting privileges, we should make sure we reflect back on the Rule of Separation to check for inherent weaknesses.

Are we isolating sensitive or vulnerable components through the practice of zoning?
Are we combining elements that should be separate, such as services and applications that have different risks and levels of security? If we add together all risks and vulnerabilities from all elements, are we comfortable with going forward?
Have we divided power in such a way that no one individual or device is fully responsible for security?

The Rule of the Three-Fold Process

Every decision should be thought of in terms of the Rule of the Three-Fold Process. Before implementation has begun, consideration should be given to the tasks that will take place after the project is completed.

Have we included proper consideration, effort, and funding for all three processes?
- Implementation
- Monitoring
- Maintenance

The Rule of Preventative Action

When relevant, security decisions should focus not only on the specific problem at hand, but also on the source of the security issue. When solving a problem, look beyond the specific instance and contemplate solutions that will help to solve similar situations as well.

Are we thinking proactively and making decisions that will affect the source of the problem, and not just fixing a symptom of a larger issue?

The Rule of Immediate and Proper Response

Security decisions that are made in reaction to issues, or that relate to the planning of a reaction, should follow the Rule of Immediate and Proper Response.

Is this decision being considered in accordance with the organization's written policies? If policies or processes are not written, should they be drafted for the future?
Has the response been well thought out, or could this be a knee-jerk reaction that may cause more damage than good?
Are actions going to be taken in an adequate time frame as to not lose evidence or allow further damage to be done?

Considering Zones

As we look at a security issue, we must make sure that we create solutions that fall in line with the zoning principles. Most security decisions involve access to some resource by some application, system, or party. Using the Rule of Least Privilege, we must identify exactly what access is required, and using zones, we must isolate the access to protect the resource and other resources. Thinking in zones is, however, a very dynamic process. Having read about zoning in Chapter 5, Developing a Higher Security Mind, and understanding each exposure concept, we should be well-equipped to apply it in many different situations. Here we will walk through a few of the most common concepts:

If an object is being accessed from an external party, is it isolated in a protected DMZ?
If communications are taking place between trusted and untrusted parties, can we place some form of protected relay in between?
If an object needs access to sensitive data, can the data be stored, processed on a separate device, and pushed, or do we need to allow for direct access?
If we compare the solution to the different zoning solutions, are we following the most secure zoning scenario that is reasonably possible?

Layering Security

Any decision made should be thought of in terms of layers. What if a device fails? What if an attack is successful? What will we do then? It is always good to assume that an individual security measure will fail and make sure that other security measures are in place. It is also wise to assume that blending different forms of security will provide a much tighter defense than a single security layer.

Is all security relying on a single mechanism?
If security was to fail in any area, are there other means of protection that will continue to limit the potential damage?

Considering the Overall Level of Security

Finally, when considering any decision, we must be aware of the security of the surrounding environment, as well as the ultimate security goal of the organization. In accordance with the Rule of the Weakest Link, it will do us little good to make any one item secure when everything around that item is left completely vulnerable. We should avoid focusing so narrowly on the security decision at hand that we lose sight of how it fits with the rest of our security. We should not build a fortress of one system, when the remaining systems are left open, unless this system is of much higher risk or we are planning to build all other systems up to this level as well.

The Policy Test

A good test of a decision is to think of its outcome in terms of a policy. Would we be comfortable documenting this decision and requiring that the same decision be followed over and over again? Every good security decision should be directly in line with the overall security goals of the organization. We should feel comfortable adding it to our policies and procedures, even if we choose not to. It is important that all security decisions are consistent with previous and future decisions, and we should avoid making too many variations or introducing a weak link. If we are not comfortable making this decision into a permanent policy, we should question the quality of the decision itself.