Same As It Ever Was

You may have heard that the RSA Conference is going on this week. Who knows how good anyone's security is, but one thing you can be sure of -- there will be hype and pyrotechnics aplenty. Still, for all the buzz (and it gets dialed up each year), the process of delivering security does not change that much from one year to the next. Who are you and what can you do? That is the question on the table. Most real-world systems cannot reliably answer that question, and no amount of trade show booths and parties can mask this deficiency.

Answering the who are you and what are you allowed to do question has plagued the security industry at least since the dawn of the Web. In the field, we are not that much closer to being ably to consistently answer these questions; however, some trends look promising.

The NIST/NSA Survey of Access Control models (PDF) identified two of the primary drivers behind work on identity systems -- a move toward finer grained access control and increasing access control decisions that are policy-based (configured as opposed to hard-coded). There are a number of interesting things at work behind the drivers -- some technical in nature, some related to software manageability, and some required to close out security gaps.

As access control models evolve, we can expect the trends on finer grained access control and policy-based access control to continue. But how can an enterprise realize these goals in a real-world architecture? A good example of where to start is found in XACML. Systems that implement XACML can deploy a fine-grained attribute-based access control (ABAC) system and manage the policy rules that govern the system.

At a structural level, XACML separates the Policy Enforcement Point (PEP), which effectively operates as a gateway or entry point to the app, from the Policy Decision Point (PDP), which resolves the attributes the rules use to define access control decisions. Making access control decisions based on fine-grained attributes is not new. Almost all applications already do this. So why is it a big deal now?

Authorization governs who has access to what. As much focus as authentication gets, for better and worse authorization is really the heart and soul of access control. (Read the OWASP Top Ten -- you will find many authorization fails.) Pulling authorization logic out of code and into configurable policy rules means that they can be reviewed and audited. Further, it's often the case that developers are not the people who know what policy and rules should govern access in the first place. Removing some access rules from code enables other people to assist in this effort.

Configuring rules rather than hard-coding them has been a recurring theme in software development for decades; it's time for security to get on the bus, and authorization rules are a good place to start. This is not a new, shiny tool or pizza box. It's not glamorous or dramatic. The rule structure for authorization is simple. Its role in security architecture is fundamental, yet often ignored by security teams. Gaps in authorization are, however, not ignored by attackers -- they are actively sought after and often easily found. Improving authorization is not a glamor detail, but it's essential to building stronger systems.

Gunnar Peterson is a Managing Principal at Arctec Group