InfoSec Triads: Cost/time/functionality
Following InfoSanity’s recent (and unexplainable) focus on triads in previous posts is the relationship between cost, time and functionality. For the purpose of this discussion assume a scenario for introducing a new product/service or adding new capabilities to an existing service.
In an ideal world all projects would have enough resources and realistic timescales to develop all required functionality to the highest level of quality. However in the real world this is rarely achievable when working with external constraints. Therefore in any project compromises are inevitable.
The theory stands that with a given set of resources, only a finite amount of functionality can be developed. Therefore it stands to reason that additional functionality can be added to a project by increasing the length of the project or adding additional resources (although the Mythical Man Month and Dilbert may refute this simplistic theory).
Within ever tightening economic conditions and competition, in order to reduce costs and/or development and implementation time functionality is stripped from the service. As security is often seen by wider business as a nicety rather than a necessity, security features are commonly the first to be dropped, or the security of features still implemented is reduced.
Despite what infosec professionals (myself included) may like to think, reducing security to meet business or market drivers isn’t necessarily a bad thing. Providing that the benefit gained is proportionate to the additional risks introduced, and those risks are acceptable to the business and/or client. However, in the increasing world of regulatory compliance this can provide a false economy to a business as it is almost universally more costly in implement additional security on-top of an existing solution than it is to bake the required security into the design and development phases.
And if anyone tells you that a less secure solution is temporary and will be rectified at a later date… Don’t believe them 🙂
— Andrew Waite