Centralized ModelManaging security centrally allows you to uniformly project your security strategy and guiding policy across all departments. This is especially useful when aiming to achieve alignment across business functions. It helps when your customers, products or services are similar across the company, but even if not, centralised governance and clear accountability may reduce duplication of work through streamlining the processes and cost-effective use of people and technology (if organized in a central pool). If one of the departments is struggling financially or is less profitable, the centralized approach ensures that overall risk is still managed appropriately and security is not neglected. This point is especially important when considering a security incident (e.g. due to misconfigured access permissions) that may affect the whole company. Responding to incidents, in general, may be simplified not only from the reporting perspective but also by making sure due process is followed with appropriate oversight. There are, of course, some drawbacks. In the effort to come up with a uniform policy, you may end up in a situation where it loses its appeal. It’s now perceived as too high-level and out of touch with real business unit needs. The buy-in from the business stakeholders, therefore, might be challenging to achieve. Let’s explore the alternative; the decentralized model.
Decentralized ModelThis approach is best applied when your company’s departments have different customers, varied needs and business models. This situation naturally calls for more granular security requirements preferably set at the business unit level. In this scenario, every department is empowered to develop their own set of policies and controls. These policies should be aligned with the specific business need relevant to that team. This allows for local adjustments and increased levels of autonomy. For example, upstream and downstream operations of an oil company have vastly different needs due to the nature of activities they are involved in. Drilling and extracting raw materials from the ground is not the same as operating a petrol station, which can feel more like a retail business rather than one dominated by industrial control systems. Another example might be a company that grew through a series of mergers and acquisitions where acquired companies retained a level of individuality and operate as an enterprise under the umbrella of a parent corporation. With this degree of decentralization, resource allocation is no longer managed centrally and, combined with increased buy-in, allows for greater ownership of the security program. This model naturally has limitations. These have been highlighted when identifying the benefits of the centralized approach: potential duplication of effort, inconsistent policy framework, challenges while responding to the enterprise-wide incident, etc. But is there a way to combine the best of both worlds? Let’s explore what a hybrid model might look like.
Hybrid Cloud ModelThe middle ground can be achieved through establishing a governance body that sets goals and objectives for the company overall and allowing departments to choose the ways to achieve these targets. What are the examples of such centrally defined security outcomes? Maintaining compliance with relevant laws and regulations is an obvious one, but this point is more subtle. The aim here is to make sure security is supporting the business objectives and strategy. Every department in the hybrid model, in turn, decides how their security efforts contribute to the overall risk reduction and better security posture. This means setting a baseline of security controls and communicating it to all business units and then gradually rolling out training, updating policies and setting risk, assurance and audit processes to match. While developing this baseline, however, input from various departments should be considered, as it is essential to ensure adoption. When an overall control framework is developed, departments are asked to come up with a specific set of controls that meet their business requirements and take distinctive business unit characteristics into account. This should be followed up by gap assessment, understanding potential inconsistencies with the baseline framework. In the context of the cloud, decentralized and hybrid models might allow different business units to choose different cloud providers based on individual needs and cost-benefit analysis. They can go further and focus on different solution types such as SaaS over IaaS. As mentioned above, business units are free to decide on implementation methods of security controls providing they align with the overall policy. Compliance monitoring responsibilities, however, are best shared. Business units can manage the implemented controls but link in with the central function for reporting to agree on consistent metrics and remove potential bias. This approach is similar to the Three Lines of Defense employed in many organizations to effectively manage risk. This model suggests that departments themselves own and manage risk in the first instance, with security and audit and assurance functions forming second and third lines of defense, respectively.
What Next?We’ve looked at three different governance models and discussed their pros and cons in relation to cloud. Depending on the organization, the choice can be fairly obvious. It might be emerging naturally from the way the company is running its operations. All you need to do is fit in the organizational culture and adopt the approach to cloud governance accordingly. The point of this article, however, is to encourage you to consider security in the business context. Don’t just select a governance model based on what “sounds good” or what you’ve done in the past. Instead, analyze the company, talk to people, see what works and be ready to adjust the course of action. If the governance structure chosen is wrong or, worse still, undefined, this can stifle the business instead of enabling it. And believe me, that’s the last thing you want to do. Be prepared to listen: the decision to choose one of the above models doesn’t have to be final. It can be adjusted as part of the continuous improvement and feedback cycle. It always, however, has to be aligned with business needs.