Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

Balancing Security & Flexibility

It is simple to expect our software to be highly secure and highly flexible all the time, but as a product matures the trade-offs become apparent. Unlike security, other aspects of the application follow a different value curve. While the organization evolves. Security may be stuck reflecting an organization that no longer exists. The reason why this is so is easy: we often build it without the right kind of flexibility in mind.

Imagine a large, hierarchical organization and an application that helps manage it. We might want to reflect the entire organizational structure in our security model (regions have divisions, divisions have departments, departments have units, etc). Conventional wisdom says that future functionality will span any given sub-unit of the organizational hierarchy. Hence, you implement a rigorous security infrastructure, even though your business features are only take advantage of it bit by bit. This up-front cost is often justified by the notion: “either my system is secure, or it is not.”

I have seen examples of this kind of thinking, and it can end up costing more money than you think. While these initial design is intended to speed up development down the line, they are often predicated on the notion that the organizational structure will either remain static, or be infinitely flexible. What you get is overhead from day one of being in production.

Addressing all of security up front trades a real, fixed cost for the possibility of increased efficiency at an unknown, future date. Only in hindsight do many organizations realize how risky this type of proposition can be, since it makes a few dangerous assumptions:

• “Will I have the same development team writing those features later on?”
• “Will I have the budget for those features that take advantage of the security infrastructure?”
• “Will my vendor relationships change by then?”
• etc.

So What’s the Answer?

The needs of security can (and will) change over time. We strive for flexibility in other aspects of application architecture, but often demand stringency in tackling security. The right balance between these two concerns can only be found over time, and not up front. Remind yourself of this early on and challenge any presumptions up front. Don’t build in more security measures than you have to, and expect these measures to evolve. The right development team will understand this as well.

Next, design security around the most important aspects of your organization, not the entire organization all at once. Decisions you make up front need to reflect idiosyncrasies of the organization, keeping things as simple as possible to lock down the immediate features you have the budget to implement.

One of the benefits of iterative development is that your security model can (and should) evolve along with your features. Start simple, let the ideas prove themselves out, and you have a much better chance of finding the right balance between keeping your application secure and maximizing its flexibility.

Share/Bookmark