Modern digital technology underpins the shift that enables businesses to implement new processes, scale quickly and serve customers in a whole new way.
Historically, organisations would invest in their own IT infrastructure to support their business objectives and the IT department’s role would be focused on keeping the ‘lights on’.
To minimise the chance of failure of the equipment, engineers traditionally introduced an element of redundancy in the architecture. That redundancy could manifest itself on many levels. For example, it could be a redundant datacentre, which is kept as a ‘hot’ or ‘warm’ site with a complete set of hardware and software ready to take the workload in case of the failure of a primary datacentre. Components of the datacentre, like power and cooling, can also be redundant to increase the resiliency.
On a lesser scale, within a single datacentre, networking infrastructure elements can be redundant. It is not uncommon to procure two firewalls instead of just one to configure them to balance the load or just to have a second one as a backup. Power and utilities companies still stock up on critical industrial control equipment to be able to quickly react to a failed component.
The majority of effort, however, went into protecting the data storage. Magnetic disks were assembled in RAIDs to reduce the chances of data loss in case of failure and backups were relegated to magnetic tapes to preserve less time-sensitive data and stored in separate physical locations.
Depending on specific business objectives or compliance requirements, organisations had to heavily invest in these architectures. One-off investments were, however, only one side of the story. On-going maintenance, regular tests and periodic upgrades were also required to keep these components operational. Labour, electricity, insurance and other costs were adding to the final bill. Moreover, if a company was operating in a regulated space, for example if they processed payments and cardholder data then external audits, certification and attestation were also required.
With the advent of cloud computing, companies were able to abstract away a lot of this complexity and let someone else handle the building and operation of datacentres and dealing with compliance issues relating to physical security.
The need for the business resilience, however, did not go away.
Cloud providers can offer options that far exceed (at comparable costs) the traditional infrastructure; but only if configured appropriately.
One example of this is the use of ‘zones’ of availability, where your resources can be deployed across physically separate datacentres. In this scenario, your service can be balanced across these availability zones and can remain running even if one of the ‘zones’ goes down. If you build your own infrastructure for this, you would have to build one datacentre in each zone and . You better have a solid business case for this.
It is important to keep this in mind when deciding to move to the cloud from the traditional infrastructure. Simply lifting and shifting your applications to the cloud may, in fact. These applications are unlikely to have been developed to work in the cloud and take advantage of these additional resiliency options. Therefore, I advise against such migration in favour of re-architecting.
Cloud Service Provider SLAs should also be considered. Compensation might be offered for failure to meet these, but it’s your job to check how this compares to the traditional “5 nines” of a availability in a traditional datacentre.
You should also be aware of the many differences between cloud service models.
When procuring a SaaS, for example, your ability to manage resilience is significantly reduced. In this case you are relying completely on your provider to keep the service up and running, potentially raising the provider outage concern. . Even with the data, however, your options are limited without a second application on-hand to process that data which may also require data transformation. Study the historical performance and pick your SaaS provider carefully.
IaaS gives you more options to design an architecture for your application, but with this great freedom comes great responsibility. The provider is responsible for fewer layers of the overall stack when it comes to IaaS, so you must design and maintain a lot of it yourself. When doing so, assume failure rather than thinking of it as a (remote) possibility. Availability Zones are helpful, but not always sufficient. What scenarios require consideration of the use of a separate geographical region? The European Banking Authority recommendations on Exit and Continuity can be an interesting example to look at from a testing and deliverability perspective.
Be mindful of characteristics of SaaS that also affect PaaS from a redundancy perspective. For example, if you’re using a proprietary PaaS then you can’t just lift and shift your data and code.
Above all, when designing for resiliency, take a risk-based approach. Not all your assets have the same criticality. , know your RPO and RTO. Remember that SaaS can be built on top of AWS or Azure, exposing you to supply chain risks.
Even when assuming the worst, you may not have to keep every single service running should the worst actually happen. For one thing, it’s too expensive – just ask your business stakeholders. The very worst time to be defining your approach to resilience is in the middle of an incident, closely followed by shortly after an incident. As with other elements of security in the cloud, resilience should “shift left” and be addressed as early in the delivery cycle as possible. As the Scout movement is fond of saying – “be prepared”.
I just passed the Certified Cloud Security Practitioner (CCSP) exam. It wasn’t easy, but nothing you can’t prepare for.
Apart from the official (ISC)2 guides, here are some of the resources I used in my studies:
- Cloud Security Alliance Security Guidance v4.0
- Cloud Security Alliance Enterprise Architecture
- Security Guidance for Critical Areas of Mobile Computing
- CSA Cloud Controls Matrix
- The ‘Treacherous Twelve’ Cloud Computing Top Threats in 2016
- ENISA Cloud Security Publications
- NIST SP 800-146 Cloud Computing Synopsis and Recommendations
- NIST Special Publication 500-299 Cloud Computing Security Reference Architecture (Draft)
- OWASP Top 10
If you would prefer to add video lectures to your study plan, there’s a free course on Cybrary. For a quick summary, check out these study notes and mindmaps. Also, multiple sets of free flashcards are available on Quizlet.
It is a good idea to do some practice questions: there are books and mobile apps out there to help you with this. Practical experience in cloud security is also essential.
The exam tests your knowledge of the following CCSP domains:
- Architectural Concepts and Design Requirements
- Cloud Data Security
- Cloud Platform and Infrastructure Security
- Cloud Application Security
- Legal and Compliance
The structure and format might change as (ISC)2 continuously revise their exams, so please check the official website to make sure you are up-to-date with the latest developments.
On the day, read the questions carefully. It’s not a time pressured exam (I was done in two hours), so it’s worth re-reading the questions and answers again to make sure you are answering exactly what is being asked. Eliminate the wrong options first and then decide on the best out of the remaining ones.
Finally, my suggestion would be to approach the questions from the perspective of a consultant. What would you recommend in each situation? Don’t go too technical – keep the business needs in mind at all times.
Don’t stress too much about the final result. I’m sure you’ll pass, but even if not on your first attempt, you’ll learn either way! Remember, the knowledge you accumulate in the process of preparing for the test itself has the most value, not the credential.
I’ve recently passed my AWS Certified Solutions Architect – Associate exam. In this blog I would like to share some preparation tips that would help you ace it.
Not only practice makes perfect, some hands-on experience is also a prerequisite for the exam. So there is really no way around that! But what if you didn’t have a chance to use your skills on a real-world project yet? No problem! AWS gives you a opportunity to learn how their cloud components work through AWS Free Tier. For one year, you can use Amazon EC2 , Amazon S3, Amazon RDS, AWS IoT and many more free of charge,
You want more guidance? Qwiklabs developed a set of labs that specifically designed to help you prepare for this exam. For a small price, you can complete exercises without even requiring an AWS account or signing up for Free Tier.
I recommend studying AWS Whitepapers to broaden your technical understanding. If you are short on time, focus on these:
- Overview of Amazon Web Services
- Architecting for the Cloud: AWS Best Practices
- How AWS Pricing Works
- Compare AWS Support Plans
AWS developed a freecself-paced Cloud Practitioner Essential course, to help you develop an overall understanding of the AWS Cloud. You will learn basic cloud concepts and AWS services, security, architecture, pricing, and support.
There is also a YouTube channel with free introductory videos and other noteworthy material.
Exam sample questions can help you check your knowledge and highlight areas requiring more study.
Remember, the best preparation for the exam is practical experience: AWS recommend 1+ years of hands-on experience with their technologies.
When you’re ready, go ahead and schedule an exam here.
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?
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.
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.
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.
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.
|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.|
Organisations around the world are increasingly relying on third-party vendors to provide them with competitive advantage. Many companies in a race to optimise processes and reduce costs begin to outsource core functions. This leads to increased risk profile and new challenges of supplier oversight.
Dealing with third-parties has grown bigger than being just a procurement issue. Suppliers companies increasingly rely on, pose not only legal but also reputational risks that cannot be fully transferred. Security and privacy related incidents related to third-party providers are presenting new management challenges. Moreover, regulators are increasingly demanding the management of the third-party risk.
Suppliers, however, have their own challenges. Constant squeeze on costs from their clients reduces the profit margins making it increasingly difficult for vendors to prioritise security requirements implementation.
How do we make sure the suppliers we work with are trustworthy? How do we minimise the risk exposure from a potential incident? What level of assurance is required for a supplier?
These are the questions I’m going to answer in this blog.
Understanding business drivers and goals is essential for developing a third-party risk management approach. By analysing company’s corporate strategy I was able to derive multiple business attributes relevant to the shareholders. One of them stands out: Trusted. I’m going to disregard other attributes and focus on this one for the purposes of this case study. Not only it is important for the company to be trusted by its customers, but trustworthiness is also something I’m going to explore in this blog from the third-party relationship standpoint.
After a workshop with the CIO and IT managers in various business units, I’ve defined the following IT attributes supporting the main business attribute (Trusted): Transparent, Assured and Managed.
How does the security function support the wider IT objectives and corresponding attributes? After a number of workshops and analysing the security strategy document I’ve managed to create a number of security attributes. Below is a simplified example correlating to the business and IT attributes in scope:
Dealing with customers and managing relationships with them is one of the core activities of the company. As discussed above, being trusted by the customers is one of the main values of the organisation. IT department through the implementation of their technology strategy supported the business stakeholders in Sales and Marketing to outsource customer relationship management platform to a third party provider. A cloud-based solution has been chosen to fulfill this requirement.
A combination of attribute profiling, trust modelling and risk analysis is used to assess the degree of assurance required and compare third-party providers. Below is a recommended approach based on the attributes defined.
Security attributes mapping
Based on the internal security policy the following questionnaire has been developed to assess the supplier. Responses from the supplier have been omitted to preserve confidentiality. Below is a short excerpt from one of the sections of the questionnaire related to cloud services.
|Are terms of services and liabilities clearly defined in service agreements?||Governed|
|Are escrow arrangements in supplier contract agreement and cloud service agreements registered with procurement and documented in cloud service register.||Identified|
|Are physical security and environmental controls present in the data centre that contains company data?||Integrated|
|Are procedures for user authentication, authorization and access termination documented?||Access-Controlled|
|Has the Business Continuity Plan been reviewed and approved by the executive management?||Governed|
|How often is the Business Continuity Plans and Disaster Recovery Plans tested?||Available|
|Is there a specific Recovery Time Objective(s) (RTO) and Recovery Point Objective(s) (RPO)? If yes, specify the RTO and RPO for the company services.||Available|
|Are default settings customized to implement strong encryption for authentication and transmission?||Access-Controlled|
Attribute compliance is assessed based on the questionnaire answers, as every question is mapped to a specific attribute. Where a specific combination of an attribute corresponds to multiple questions, all answers are rated separately then an average rating for that attribute weight is calculated. Exceptions apply where certain specific questions are identified to have priority (higher level of impact on attribute compliance) over the other questions mapped to the same attribute. Expert judgement is applied to analyse such situations.
Attributes are evaluated with three main levels:
- High level of compliance with policy (Green),
- Medium level of compliance with policy (Amber),
- Low level of compliance with policy (Red)