Agile Ajax » The Truth About Designing For Security

The Truth About Designing For Security

Ivan Moscoso, Tuesday, November 18, 2008 @ 12:49 pm

Security is an area of concern where value and cost are often difficult to estimate. While big mistakes made early on in many areas of an application may prove difficult to correct, this is especially true for security, since its specifications often model a direct reflection of an organizational structure.

And all too often, dysfunctional organizations create dysfunctional security requirements.

It is common knowledge then that a failure to account for security from the start can prove much more costly in the end. However, over-engineering security needs can require so much effort that your team may not have enough time left over to actually build the very features you are trying to secure.

I find the following two points very useful to keep in mind when participating in discussions concerning security regardless of the application, but especially when working under the assumption that a new application needs the same kind of security model as the old application:

All security models are idiosyncratic
Never underestimate the cost of being flexible

These two items work as polar opposites of each other: a flexible system can accommodate many types of organizations, but not without the added cost of training, installation, documentation or maintenance. On the other hand, a static model is cheap to build, but rarely captures the nuances of an organization's structure, particularly as business needs evolve over time.

Years ago I worked on a small part of the security infrastructure for a public-facing site. The security model included a fairly complex, "lattice-based" authorization scheme: User roles were arranged in hierarchies. Access to resources could only be determined by understanding both the hierarchy and the security level at each step in the hierarchy. Resources were configured with different "security levels" along the way. Half of the information needed to answer the question of access control was stored in a database, and the other half in code. Because of this, user management was left in the hands of development, and only after that proved to be a clear bottleneck were we given the opportunity to build a front-end management interface for non-developers to manage user access rights.

The system was flexible, but a coordinated mess. Several developers spent a significant effort to keep things going, and it still took a few hours with a whiteboard to explain problems or inconsistencies in the model. A simpler, role-based authorization would have sufficed. In retrospect, the idea of role hierarchies was never justified, and could have been done away completely if just a little bit of the front-end interface had been designed in tandem with the original security specification.

I wish this were an isolated case, but we hear these types of stories time and again. The lesson I take from it is that, in trying to be flexible, an organization can overshoot its needs. In this case, the security model covered the nuances of the organization, but at an ever-widening cost measured in development time, maintenance, training, documentation, review, etc.

('spiritual lattice' by jared)

Topics: architecture, Design, Security