There is a sudden uptick in webinars and discussion panels where C-level executives talk about their experience rolling out security strategies within their organizations. I decided to weigh in with some of the most common approaches I have seen organizations adopt:
- Act when Something Happens
Some organizations clearly assume the reactive approach to security. Even if they agree that this is not the ideal approach, their argument centers around the fact that security is not a priority, rather an overhead that does not in any meaningful way bolster the bottom line. So security spending is strictly limited to being need based. Obvious counter arguments exist; however one can only assume that an environment with minimal adherence to compliance standards, tight budgets and a distinct lack of security awareness is the root cause for this point of view. Organizations that adopt this model are very low on the security maturity model ladder.
- Best Practice Roadmap
In this case an organization looks to analysts or vendors to provide a “best practice” roadmap for its industry. Armed with this roadmap, the organization’s current implementation is measured against recommendations, and gaps identified. These gaps then proceed to be filled based on budgets, priorities determined by pundits, and the ability to justify security wants cogently. This type of organization will possibly do better than the first type; however the security strategy is driven by generic industry trends and focuses rather than by the organization’s own needs. The general outcome here again tends to be unpredictable-hit or miss.
- Align with the Business
The key issue in the previous model is that the gap analysis is performed in a silo with a myopic security centric view. Business goals and objectives are not taken into consideration when determining priorities. Misaligned priorities often result in duplication rather than optimization. A far better option is one where there is synergy between business and security initiatives. The security roadmap is aligned with the business roadmap ensuring that priorities stay in synch and any solution rolled out by the business is integrated with appropriate security controls and governance from the ground up. Such an approach allows the organization to keep up with business trends while at the same time protecting its brand image and complying with security standards, optimally and cost effectively.
To illustrate the differences in the models let’s consider a common organizational requirement today and see how it plays out:
The Digital Strategies (DS) business team of XYZ Corp (may belong to any industry vertical) identifies the need to offer its consumers easy access to its products and resources. In order to achieve this objective the team decides to offer consumers an organizational portal from where they can access authorized content using a range of supported devices.
If XYZ Corp has an “Act when something happens” outlook the DS team would develop the solution in isolation, with scant regard to security principles. Everything would appear under control until a security incident occurred. At this time retrofitting security controls would be unavoidably expensive, technically challenging and worst of all performed under extreme management pressure (resulting possibly from unwanted publicity and loss of brand credibility). The outcome would not be ideal. Finally the reorganization of all associated teams, (which almost always follows such a crisis), would only exacerbate the situation and add a dimension of organizational politics to the mix!
If XYZ Corp is a “Best Practice Roadmap” organization, much the same as above, the DS team would do its own design and development, decoupled with any initiatives being pursued by the Security team. Its unlikely Security is working on what they need when they need it. Cross initiative recognition may only occur if one solution inadvertently breaks as a result of the other, the outcome being just as unpleasant and unproductive as in the “act when something happens” case.
Coming to the third model; here both the DS team and the Security team work collaboratively from the start. The Security team understands the objectives of the DS initiatives and the resulting design includes features such as secure authentication, single sign on, authorization and data access to support the solution. From the DS side there is awareness of the catalog of available security services that could be leveraged rather than duplicated. If gaps exist in security services required, the Security team can justify its needs and typically have a much smoother path to getting requisite resources and budgets allocated to the initiative. I hardly need to explain why it is easier to get funding for mobile or single sign on security solutions when they are associated with a concrete business initiative that calls for them, than if they were independently lobbied for!
If you consider security to be a journey, carrying a roadmap and a strategy to handle common challenges or obstacles goes a long way in being prepared and reducing risks from a security perspective. Aligning the security roadmap with your organization’s business initiatives and objectives makes the journey productive and worthwhile as well for the organization as a whole. Isn’t that the whole point?