Virtually everyone I've ever spoken to will agree that security is always
better "baked in" to the design from the beginning as opposed to
"buttered on" at the end. Why is it, then, that we always seem to
have so much trouble getting there? It seems as though we have implemented our
systems development processes in a way that prevents us from reaching this
state.
While there are great frameworks out there like the Systems Development Life Cycle (SDLC), the systems are only as secure as the requirements that they are developed to. This, I believe, is where we most often go astray. Security must be a requirement, just as throughput or port density are requirements. The challenge, then, is to get security practitioners to develop requirements that will drive the design and assist in the tradeoff decisions between security, functionality, and cost that will inevitably occur. These tradeoff decisions must be backed up by solid risk analysis and not just compliant/not compliant auditing (compliance versus security will be a topic for another time).
These two actions are most often glossed over, in my humble opinion, because they are very hard to perform, taking a great deal of time and resources to execute. Resources always being constrained, it is often difficult to convince management to commit them to security since it is generally considered to be overhead, eating into the profit margin.
However, I’m convinced that preventing bugs and security holes is far more effective and efficient than trying to find them after the fact. The problem is that cost avoidance doesn’t sell well to management. The real secret then is to make security a differentiation, adding to potential profit as opposed to merely eating into it. In order to be effective at this, security must be baked in from the requirements generation stage.
While there are great frameworks out there like the Systems Development Life Cycle (SDLC), the systems are only as secure as the requirements that they are developed to. This, I believe, is where we most often go astray. Security must be a requirement, just as throughput or port density are requirements. The challenge, then, is to get security practitioners to develop requirements that will drive the design and assist in the tradeoff decisions between security, functionality, and cost that will inevitably occur. These tradeoff decisions must be backed up by solid risk analysis and not just compliant/not compliant auditing (compliance versus security will be a topic for another time).
These two actions are most often glossed over, in my humble opinion, because they are very hard to perform, taking a great deal of time and resources to execute. Resources always being constrained, it is often difficult to convince management to commit them to security since it is generally considered to be overhead, eating into the profit margin.
However, I’m convinced that preventing bugs and security holes is far more effective and efficient than trying to find them after the fact. The problem is that cost avoidance doesn’t sell well to management. The real secret then is to make security a differentiation, adding to potential profit as opposed to merely eating into it. In order to be effective at this, security must be baked in from the requirements generation stage.
Agree, the challenge is creating this mind set during the planning stages and convincing the leadership that this will be the best course of action. Information like this allows us to train and educate.
ReplyDelete