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.
Continue reading »

• Digg
• Reddit
• del.icio.us

Comments (0)

agile ajax