Here's the latest in our series of guest blog posts on the Chapter blog.
This one comes from Leron Zinatullin (@le_rond) and describes the pros and cons of different governance approaches in relation to securing cloud implementations.
Don't forget, feel free to contact us if you feel that you have a burning issue that you'd like to get off your chest via a guest blog post. We can help.
Governance Models - Cloud
Your company has decided to adopt Cloud. Or maybe it was among the ones that relied on virtualised environments before it was even a thing? In either case, cloud security has to be managed. How do you go about that?
Before checking out vendor marketing materials in search of the perfect technology solution, let’s step back and think of it from a governance perspective. In an enterprise like yours, there are a number of business functions and departments with various level of autonomy. Do you trust them to manage business process-specific risk or choose to relieve them from this burden by setting security control objectives and standards centrally? Or maybe something in-between?
Centralised model
Managing 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 organised in a central pool).
If one of the departments is struggling financially or is less profitable, the centralised 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 decentralised model.
Decentralised model
This 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 decentralisation, resource allocation is no longer managed centrally and, combined with increased buy-in, allows for greater ownership of the security programme.
This model naturally has limitations. These have been highlighted when identifying the benefits of the centralised 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 model
The middle ground can be achieved through establishing a governance body setting 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, decentralised 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 consistent metrics and remove potential bias. This approach is similar to the Three Lines of Defence employed in many organisations 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 defence respectively.
What next?
We’ve looked at three different governance models and discussed their pros and cons in relation to Cloud. Depending on the organisation 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 organisational 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, analyse 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.
Summary
Centralised model | Decentralised model | Hybrid model |
A single function responsible for all aspects of a Cloud security: people, process, technology, governance, operations, etc. | Strategic direction is set centrally, while all other capabilities are left up to existing teams to define. | Strategy, policy, governance and vendors are managed by the Cloud security team; other capabilities remain outside the Cloud security initiative. |
Advantages | Advantages | Advantages |
· Central insight and visibility across entire cloud security initiative
· High degree of consistency in process execution
· More streamlined with a single body for accountability
· Quick results due to reduced dependencies on other teams
| · High level of independence amongst departments for decision-making and implementation · Easier to obtain stakeholder buy-in · Less impact on existing organisation structures and teams · Increased adoption due to incremental change · High degree of alignment to existing functions | · High-priority Cloud security capabilities addressed first · Maintains centralised management for core Cloud security requirements · Allows decentralised decision-making and flexibility for some capabilities |
Disadvantages | Disadvantages | Disadvantages |
· Requires dedicated and additional financial support from leadership · Makes customisation more time consuming · Getting buy-in from all departments is problematic · Might be perceived as not relevant and slow in adoption | · Less control to enforce Cloud security requirements · Potential duplicate solutions, higher cost, and less effective control operations · Delayed results due to conflicting priorities · Potential for slower, less coordinated development of required capabilities · Lack of insight across non-integrated cloud infrastructure and services | · Gives up some control of Cloud security capability implementation and operations to existing functions · Some organisation change is still required (impacting existing functions) |
About the author
Leron Zinatullin is an experienced risk consultant, specialising in cyber-security strategy, management and delivery. He has led large-scale, global, high-value security transformation projects with a view to improving cost performance and supporting business strategy. He has extensive knowledge and practical experience in solving information security, privacy and architectural issues across multiple industry sectors. Leron is the author of The Psychology of Information Security.
Twitter: @le_rond
www.zinatullin.com
Comments
Post a Comment