The security of an environment is often won or lost at the architecture level.
A poorly designed environment may require Herculean efforts to secure it - if that's even possible! Conversely, an environment that is designed with security as a driving requirement can be efficiently monitored, controlled, and administered - the three ingredients to a secure environment. It is all too common for a company to design its enterprise infrastructure, a web site, or a critical application, and to begin thinking about how to secure it only in the final stages of deployment.
One of the critical errors designers make is to concentrate exclusively on making the environment function as efficiently as possible without considering the effect the organization of networks, services, applications and information have on the security of the environment. The key point to recognize is that security is accomplished through a combination of compartmentalization, well defined perimeter defenses, clearly specified identities, bounded roles and corresponding access controls, and intrusion detection at multiple levels. Security is the responsibility of all the elements of your environment, from the perimeter, through the network services you run, and ultimately in the applications you deploy. An architecture that is designed with these security elements considered at all levels is the easiest to secure and the easiest to maintain securely.
Understanding how to think about a problem is the first step in developing a successful solution. Here are a few more points to think about as you design your environment.
Information Separation
One of the first questions you should ask when designing your enterprise or any part of it is, "Is the information being processed sensitive?" If so, you should consider how it relates to other information you work with. Is it being processed in the same environment as other sensitive data? Does it coexist with the information of your business partners, customers and employees? Questions like these help you understand the risk of a compromise. Once you understand whose data you have, you can consider separating different types of data into different zones. This principle, data separation, can have a substantial effect on your ability to protect data as well as detect and isolate intrusions.
The simple idea is that you should consider organizing your network into zones. Examples of zones might be separate demilitarized zones (DMZs) if you have applications of different sensitivity or purpose, a partner DMZ for connections with partners, and a remote access area to contain and monitor remote connections into your corporate network. The design and use of these zones will enable you to use your security tools more effectively. Your perimeter will be focused on allowing and disallowing particular types of traffic; intrusion detection devices can closely monitor the behavior of network traffic, systems, and applications. Furthermore, authentication and authorization solutions can be matched to the needs of the particular environment.
When developing your concept of zones, there is one time-tested truth about deploying any type of service. It is easier to manage and secure a host for a single service than for multiple services. A system running a web server can be hardened and managed more easily and better than a system that is running a web server, a mail server and some other service(s). The reason is that the more services you have on a particular host, the more likely it is that you will have to set the security parameters to be the least common denominator of all of them. Use separate systems for each important component: be sure to define specific security policies and procedures for each different type of device, service or application.
Your Perimeter(s)
Every network has at least one perimeter; most have more than they should. A perimeter is some point where your degree of control changes. In other words, your security requirements change. The obvious perimeter is the one that separates your internal network from the Internet. Other subtler, yet potentially more important, perimeter points include:
- your development network;
- other regional (e.g., another building, city, state, country) company connections;
- partner connections;
- vendor connections (e.g., for remote management);
- outsourced services (e.g., DNS, mail, data storage, backup).
Every one of these implies a (potentially) new set of security requirements and therefore, each one should be treated separately yet use the same standard services (which we will discuss below). For any given perimeter you are going to have to consider a variety of different mechanisms such as routers, firewalls, proxy servers, virtual private networks (VPNs), load-balancing, or intrusion detection systems. The key to designing perimeters is to think in terms of appropriate access - who should be able to do what, and under what circumstances. Don't fall into the trap of the 'firewall' mentality, i.e. the good guys are on the inside and the bad guys are on the outside. Even worse is thinking you can decide whom to trust based solely on something like an IP address.
If you're going to have a security breach that doesn't start from an insider, it's likely to be because of a configuration or deployment problem at a perimeter. Remember that the environment is only as secure as its weakest component. For example, a poorly configured IIS server at your perimeter can put all the other systems and services at risk.
Standard Security Services
To satisfy the needs of a robust and long-lasting architecture, there are certain standard security services that are always needed: authentication, authorization, auditing (which includes logging facilities), and intrusion detection. Here are several mistakes people make when determining how they will use these services.
- Assume that you will need all of these important services, even if at first you think you only need some of them. Many designers think about authentication and occasionally consider 'failure' auditing, but often ignore authorization, logging, 'success' auditing, and intrusion detection hooks. Design your environment to include all of these concepts even if early versions don't use them.
- Authentication and authorization are different things; don't rely just on authentication. Too many applications are built to either authorize no actions or all of them. So in essence, your authentication implies full authorization. Those that do better than that, usually only check for authorizations once, at the start of the session, and assume everything is the same after that.
- Standard services should have a generic interface such that the specific mechanism used can change over time without changing the applications that use them. Don't integrate directly to an underlying product. Instead, use an API that hides the product specifics. Let the API be the only place those specifics are used. That way, if the underlying product changes, only the interface needs to be updated, not all of your applications.
- Every time a new application or user interaction happens, the exchange should be authenticated so that you know who is performing the action. Even better, every principal (user, application) should have its own unique identity so you know exactly who did what (as opposed to having shared accounts: e.g., all administrators log into the admin account). Also, the strength of the authentication mechanism used should be proportional to the risk. The higher the risk, the stronger the authentication method you should use.
Assessing Your Security: Subtract the Layers
In creating your architecture, consider the entire data path. All the while, ask yourself, "If my security measures failed right now, what would be at risk? How would I even notice that I had a problem? What additional compensating controls or security mechanisms would I need to protect myself?" In today's business environment, the boundary between inside and outside is constantly shifting (for example, VPNs, extranets), so think about the layering not in terms of inside versus outside, but in terms of the type of access that is required (again, appropriate access).
The Importance of Discipline and Dealing with Reality
Most organizations don't really start building an architecture with a clean slate. It is important to come to agreement on what things can't change, what things can change a little, and what things can change a lot. Accept these business and technological realities and use it to your advantage. If not, you are likely to spend too much time on aspects of the environment that are immovable and not enough time on aspects that are quite flexible.
Be sure to think about the level of control you have over each component. Some elements and components you own and manage (i.e., they are in your buildings and are managed by your employees). Other resources may be under the control of third parties like ISPs or business partners. You need to deal with these situations differently and ensure you have the appropriate level of controls for each. Most importantly, be sure that the level of trust you place on each resource is consistent with your level of control over it.
Brad Johnson is vice president, Dick Mackey, principal, and Jonathan Gossels, president, of SystemExperts Corporation (www.systemexperts.com), a provider of network security consulting services.
