Principles of EASI

Now, let’s look at some basic principles to follow when integrating security into component-based e-commerce applications. You’ll learn these rules as you apply EASI techniques to many large customers’ problems.

Authentication

The two principles of authentication are trust no one (not to be confused with the FOX television series the “X-Files”) and balance cost against threat.

Trust No One

In distributed systems, authentication isn’t just about people. A client request bounces through many applications in a multitier architecture, so there are many points of vulnerability. Each component that is a part of a request chain should be authenticated on its own. If not, an attacker may be able to insert a new component in this chain and cause serious damage. The more complex the application architecture, the more serious the threat.

Balance Cost Against Threat

On the other hand, the best authentication isn’t for everyone. The most secure authentication, such as public key certificates on smart cards, is probably too expensive to deploy and manage for many applications. If authentication techniques are too strong, people may just give up and not use the system. It’s better to have authentication that people will use rather than building a secure boat anchor. Single sign-on is an example of this principle; no one likes to log in more than once.

Authorization

The two principles of authorization are application driven and push security down.

Application Driven

Authorization policies aren’t really to protect URLs or files—they protect business data that resides in those files. A lot of time and money is wasted blindly setting up security products that do little to protect important application data. To secure a system, don’t lose sight of the fact that the most important thing to understand is the purpose of the business application. After you understand what the business application is for, and what bad security things could go wrong, then you can figure out the best way to protect the data.

Push Security Down

After you know which application data is really important to protect, look to enforce authorization at the lowest practical level in the architecture. Least desirable is within the application, although some policies cannot be enforced anywhere else. By pushing authorization down to the lower layers of the architecture, you’re more likely to have robust common security mechanisms that can be shared across many applications.

Accountability: Audit Early, Not Often

Auditing is expensive in distributed systems, so for performance reasons it’s better to do it as little as possible. Unlike authorization, it’s preferable to push the source of an audit event to the upper layers of the architecture near the application. Low-level auditing (at the operating system level) is extremely difficult to analyze, because it takes several low-level events to match to a single business transaction. Low-level auditing is fine for discovering an attack on your operating system, but correlating low-level audit data across multiple audit logs to detect an application attack can be close to impossible. As a result, the most effective auditing is done as soon as an application recognizes that a potentially dangerous event occurred.

Security Administration

The principles of security administration are collections for scale, centralized management, and distributed enforcement.

Collections for Scale

E-commerce applications are all about managing huge numbers: millions of users and resources, thousands of servers. The best way to deal with large numbers is to collect things into groups, and make those groups hierarchical. By defining collections, administrators can set policies on lots of things at the same time and delegate security responsibilities across many administrators.

Note

Collections are not just about people; services and data should also be grouped to handle scale.

Centralized Management and Distributed Enforcement

Administering distributed applications is difficult because components are widely scattered, and manually setting up policies for each component across a large network isn’t practical. The easiest way to administer security is when the security policy is in one place. However, a centralized policy may not be very efficient to enforce if the security infrastructure must check a central policy every time a remote component executes. The best approaches give the best of both worlds by offering security administration that is logically centralized, but use distribution techniques to get the policy out near the components where it’s needed. Beware of synchronization issues; many products use caching that speeds up access but could mean that policies are sometimes out of date.

Security Association

The principles of security administration are think end-to-end, not point-to-point and design for failure.

Think End-to-End and Not Point-to-Point

As mentioned previously, e-commerce applications are implemented by chains of requests, which are much more complex than the antique client/server model. Transport security mechanisms, such as SSL or Secure Internet Protocol (IPSEC), are inadequate in multitier environments, because they cannot secure a chain of requests; they only secure two end points. It’s for this reason that these protocols don’t deal with delegation. Protocols such as Security Assertions Markup Language (SAML) and CSI that are built upon transport security are the best way to secure applications end-to-end.

Design for Failure

Finally, a simplistic component model assumes that all applications trust each other to protect data. That may be okay for small systems, but it’s a dangerous assumption when the applications are more distributed. If one component is compromised in this scenario, then the entire set of distributed components is vulnerable. A better approach is to view collections of components as mutually suspicious islands—if one collection of components is compromised, then others will still be safe.