Rule of Separation

graphics/rules5_icon.gif

The Rule of Separation states that to secure something, it must be separated from the dangers and threats of the world around it. In accordance with the Rule of Least Privilege, we should only bestow access to our treasure room on those who really require such access. Consider, however, if we also had a library in the middle of our treasure room, and had to allow students to come in to study. We don't want the students to have access to the gold, but we can't deny them access to the books!

Often, our treasure rooms are not so cut and dried as to say, "The gold is inside and the thieves are outside," just as the protective barriers we build do not always exist at the perimeter of our networks. Many times, it is important to separate different internal objects to avoid introducing unnecessary exposure.

Concept

It is commonly known that the more "tasks" a device must perform, the more issues it is likely to have. It is ill-advised for any company to have 10 applications running on one system due to the likely chance that these applications have not been designed or tested to share the hosting server with other applications. It is also commonly known that the more subjects that have access to an object, the higher the chance that the object will have an exposure. By not practicing the Rule of Separation, an organization multiplies its exposures and, at the same time, reduces the overall level of security for each object.

Multiplying Exposures

The strengths and weaknesses of any particular object can usually be related to the tasks that object performs. The more something does, the more complicated it has to be, and thus, the more potential security weaknesses it will have. Every service running on a device has some degree of programming errors, incompatibilities, and vulnerabilities. Running multiple services on a single device not only combines existing vulnerabilities, but can also introduce new ones. Thus, if an email service has three vulnerabilities and a Web service has two, running them both together may even surpass five vulnerabilities. When services are combined, each service adopts the weaknesses of the other services running with it. Some services are less stable than others, and some have more vulnerabilities than others. When we combine services, we compound these negative attributes.

Reducing the Level of Security

Each service also has its own unique sensitivity considerations. One service may not be important to our organization, while another service may be vital. Similarly, some services deal with meaningless data, while others store and process sensitive transactions. By combining services together on a single server, we are essentially combining the different levels of sensitivity along with the different levels of security. An FTP service may not be vital to an organization, and thus the application may not include a great deal of security. The email server, however, may be vital to the organization and its applications may be highly secured. By combining these two applications on a single system, they are essentially placing the weak security controls of the FTP services into an otherwise secure, critical email server.

Example of Reduced Security Through Shared Services

As seen in Table 4.2, System X runs three applications: email, Web, and FTP. Each service has its own level of security and its own vulnerabilities. Each also hosts a different set of data with different levels of sensitivity. Thinking back to our Rule of the Weakest Link, imagine what we have done to the security of this system. We have combined the worst of the vulnerabilities with the most sensitive of data! If any one of these applications is compromised, all data from all applications could easily be exposed.

Table 4.2. Reducation of Security via Shared Services

Service

Sensitivity of Data

Security of Application

Number of Vulnerabilities

Email server

Extremely sensitive information

Highly-secured email host

2 security vulnerabilities/year

Web server

Somewhat sensitive data

Medium security, Web-hosting software

2 security vulnerabilities/year

FTP

Nonessential information

Minimum security applied to application

3 security vulnerabilities/year

All services

Extremely sensitive information

Minimum security

7 security vulnerabilities/year

Practicing Separation

The application of this rule does not require us to place every single service on its own bulletproof device, locked in an airtight chamber. If we follow these guidelines, we should be able to make practical and secure decisions without great expense:

  • Isolate important services and data The more critical a service is or the more sensitive its data, the more important it is that it be isolated.

  • Isolate services that are more prone to attack Services that commonly have "known vulnerabilities" and "new security patches" should be separated from more secure and stable systems.

  • Isolate all security services Security devices should never have multiple services on them unless absolutely required. The best practice is to make the firewall only a firewall and put extra services like authentication, mail relay, and virus checking on other systems. If this is not possible, at least limit the firewall's services to those developed by the same manufacturer (that is, don't install a Checkpoint firewall with a third-party domain name server (DNS) relay on it).

  • Only group services based on common security factors When services are grouped together, it is best if they are of similar risk levels and a similar level of security should be applied to each service.

  • Understand exactly what is being grouped together If a service is to be run on the same system as another service, it is well worth it to take the time to research the applications and how well they interact with each other.

Six Sample Considerations to Determine if a Service Should Be Isolated

Table 4.3 is an example scoring system to show the thought process one might go through when deciding to share services. Take a specific object and review each consideration on the left. Select the best answer on the right and add the points together. Then, compare the score to the recommendation at the bottom of the chart.



Inside the Security Mind(c) Making the Tough Decisions
Inside the Security Mind: Making the Tough Decisions
ISBN: 0131118293
EAN: 2147483647
Year: 2006
Pages: 119
Authors: Kevin Day

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net