 So, what is information security architecture? An architecture must provide all the links in the chain and ensure that security is provided through a fully integrated systems approach. The security architecture must ensure that services are properly managed, delivered and supported. The security architecture must be created for your needs. The architecture you end up creating must consider business needs as well as regulatory requirements. It must be holistic and complete. I'm going to talk a little bit about security architecture principle. They form the basis for our security architecture design. The same principles apply to cloud infrastructure as to infrastructure in your own data center. To make our design complete, we make sure that we provide security all the way throughout the lifecycle of the software. We make sure that within any system, the level of security is equal throughout. Later in this course, we will talk about the principle called layer defenses. As in medieval times, when you have a castle with multiple walls, we layer our defenses that will protect our asses in the cloud. Privilege separation is a technique in which a program is divided into parts. The different parts are limited to the specific privileges they require in order to perform a specific task. This is used to mitigate the potential damage of a computer security vulnerability. The least privileged security design principle states that each user should be able to access the system with least privilege. Only those privileges should be assigned to the users, which are essential to perform the desired task. A system that has critical data, processes, or resources must be isolated such that it restricts public access. The system can be isolated in two ways, both physical or logical. The physical isolation is one where the system with critical information is isolated from the system with public access information. In a logical isolation, the security services layers are established between the public system and the critical systems. Zero trust is based on the realization that traditional security models operate on the assumption that everything inside an organization's network should be trusted. Under this broken trust model, it's assumed that the user's identity is not compromised and that all users act responsibly and can be trusted. Zero trust can be achieved by leveraging network segmentations for preventing lateral movement, providing application threat prevention, and applying granule user access control. Security by design is increasingly becoming the mainstream development approach to ensure security and privacy of software systems. In this approach, security is built into the system from the ground up and starts with a robust architecture design. In this section, you'll learn that cloud security architecture is needed to avoid costly design and misconfiguration mistakes. Through this course, you will learn about security architecture for the cloud and steps required to create your own. In this section, you also learned about information security architecture and architecture principles. These principles also applies to cloud architectures. This section will cover some basics about cloud computing and how security architecture is different in the cloud. I will talk about the essential characteristics of the cloud and how it differs from a non-premises environment. I will also discuss different delivery and deployment models in the cloud and how responsibility for security is shared between the cloud provider and you as a consumer. I will also explain how we can find information about how the cloud provider has secured the cloud services that you use. Cloud computing is being adopted worldwide for all types of organizations. It gives a number of benefits to the cloud customers but will also change the way IT is administered and operated. For information security, cloud computing provides new opportunities but will also pose some challenges. Cloud technology enables companies to scale their computing solution as they grow. The days of forecasting how many servers to buy is long in the past. Instead, companies can simply alter their usage with the cloud provider like Amazon web services or Microsoft Azure. The cloud provider allocates more space and charges more money. Not only does the cloud allow companies to create more valuable apps for customers, it enables better customer support. Customers want answers and the ability to purchase products all the times of the day. The cloud makes this possible. Cloud computing requires in-depth knowledge about technologies and platforms. You should prepare to learn about the technology platform of at least one of the major cloud providers. You will also benefit from knowing about the automation of operations and how to utilize different cloud services and cloud security offerings. So what are the main characteristics of cloud computing? On demand self-service, a consumer can provision computing capabilities such as server time and network storage as needed automatically without requiring human interaction with each service provider. Broad network access capabilities are available over the network and access through standard mechanism that promote the use of thin or thick client platforms such as mobile phones, tablets, laptops and workstations. Resource pooling. The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. Rapid elasticity capability can be elastically provisioned and released in some cases automatically to scale rapidly outward and inward on demand. Mashout service. Cloud system automatically control and optimize resource use by leveraging a metering capability appropriate to the type of service. For example, storage, processing, bandwidth and CPU usage. Resource usage can be monitored, controlled and reported, providing transparency for both the provider and the consumer. An important concept for cloud services is the cloud service delivery models. These models are infrastructure as a service, platform as a service and software as a service. Infrastructure as a service involves the hosting of physical or virtual machines in a data center environment. Service providers supply resources on demand as required by the client. This means that an organization only pays for the resources that they utilize. Platform as a service is where cloud providers deliver a computing platform. Generally, this involves hosting of an operating system or web server. Software as a service is a model in which users are giving access to application, software and databases. The cloud provider manages the infrastructure and platforms that operate the applications. Software is installed and updated in the cloud and can be accessed at any time by users. This eliminates the need for businesses to install and manage software themselves. We have four different cloud deployment models. Public cloud is a deployment model that supports all users who want to make use of a computing resource such as hardware or software on a subscription basis. Private cloud is typically infrastructure used by a single organization. Such infrastructure may be managed by the organization itself to support various user groups or it could be managed by a service provider that takes care of either on-site or off-site. In a hybrid cloud an organization makes use of interconnected private and public cloud infrastructure. Many organizations make use of this model when they need to scale up their IT infrastructure rapidly such as when leveraging public clouds to supplement the capacity available within the private cloud. The community cloud model supports multiple organizations sharing computing resources. Examples include a university cooperating in certain areas of research. Access to a community cloud environment is typically restricted to the members of the community. So how is security architecture different in the cloud? Cloud services can be delivered in many flavors in any combination of the service delivery models such as software as a service, platform as a service and infrastructure as a service and the deployment models public, private, hybrid and community. You as a cloud customer are responsible for knowing how your cloud services work with respect to security. The cloud provider should give the documentation you need for your work with architecture. Cloud security concerns and solutions are dependent on the context. In other words, how your business choose to use the cloud services. So then the solution architecture you end up with should match these concerns and build security safeguards into the cloud application architecture. The cloud shared responsibility model is maybe the most important model for you to understand as a security architect. Failure to understand what responsibility you have for security as a cloud consumer can lead to loss of sensitive data and outages. This slide shows the division of responsibility between the cloud consumer and the cloud provider for different service models. For the IIS tier, the security burden on the cloud service provider includes virtualization security and infrastructure security. Areas such as data security, application security, middleware security and host security all fall to the IIS customer. That means you. Simply put, users are responsible for the guest operating system and everything inside of it. For platform as a service, the cloud service providers responsibility are broader, including security configuration, management, operation monitoring and emergency response of infrastructure. The service provider also has responsibility of security of virtual networks, the platform layer security, such as security of operating systems and databases. You as a platform as a service customer is responsible for data security and application security. In the software as a service tier, the cloud service provider's responsibility for security of the application and all underlying components. The software as a service customer is responsible for data security and endpoint device protection. As you can see, some of the areas are marked as shared responsibility. This means between you as a customer and the cloud service provider. Depending on the type of service, the administration is split between the customer and the provider. For identity and access management, you usually have full control as the customers over identities and access rights. However, the administration interfaces are delivered to you as a service by the cloud provider. Data security, governance, risk and compliance are always the responsibility of the cloud customer. You should raise your own competency in these areas before you start using cloud services. As you can see from this matrix, there are many areas of responsibility for the cloud customer. Don't underestimate the time and resources you'll need to invest for each cloud deployment, including any necessary training to bring your team up to speed. So how do you know that the cloud provider fulfills its responsibility for securing the cloud? The short answer is audit reports. But apart from the audit reports, each cloud service provider makes available for the customers. There are also independent organizations, such as Cloud Security Alliance, who can help you. The Consensus Assessments Initiative questionnaire, the so-called CAIC, offers an industry-accepted way to document what security controls exist in IIS, PAS and software as a service. CAIC provides security control transparency. It provides a set of yes or no questions a cloud consumer and a cloud auditor may wish to ask a cloud provider to ascertain their compliance to the cloud controls matrix. I will talk about the cloud controls matrix later in this course when I summarize the different frameworks and methodologies. In this section, we'll learn that cloud computing changes IT operations and that you and your team need to develop new competencies. You have learned that cloud services are flexible and can benefit your organization, but you need to acquire knowledge about the service and deployment models in the cloud. Now you also know that responsibility for security is shared in the cloud and that you need to carefully study what is your responsibility. The responsibilities of the cloud consumer changes with the different service models. You also learned that audit reports and the CAIC from the Cloud Security Alliance can help you understand how the cloud provider handles security. Now that we know how security architecture is different in the cloud, we can start looking into important steps for building the cloud security architecture. In this section, I will talk about the steps that will be necessary for you to go through when designing and building a cloud security architecture. This approach can be used both for an organization, wide scope and for projects. I will explain the use of methodologies, frameworks and standards and how to use this in your own process. I will introduce risk management and describe the most prevalent risks in cloud deployments. Implementation strategy is important also for cloud and I will talk about what choices and priorities that can be made when developing a strategy. Finally, I will talk about compliance in the cloud and how to document your cloud architecture. There are multiple methodologies and frameworks to choose from, even though they are not created for use with cloud architectures that can be adapted and used to design and build solid cloud architectures. The methodology should follow a top-down approach starting with gathering of business and regulatory requirements. Risk management is an essential part of a security architecture and identified risks and their mitigation strategies should form the basis for your cloud security approach. A sound strategy is vital. Maybe organization already has established a cloud strategy. The strategy should cover how applications are migrated to the cloud or built as native cloud applications. This will also have an effect on how to secure those applications and the infrastructure they are deployed to. This document the design and implementation of security architecture in the cloud. Ensure that you can trace the rationale of deploying a security control back to its business or regulatory requirement and vice versa. Implement the controls using infrastructure as code. This will help you streamline and automate deployments and reduce the risk of manual configuration errors. So why do we need a methodology? When you develop security architecture for your organization or project, you need to communicate your design. A methodology will help you to be structured in your architecture approach and to provide a holistic architecture covering many perspectives important to different groups of stakeholders. A methodology can integrate different frameworks and security standards depending on the needs of your organization or project. It will always be an advantage to map your design decisions to regulatory requirements so that your documentation can be used to prove compliance. Traceability is another important aspect. It's an advantage to be able to trace the existence of a security control back to a specific business requirement. Last but not least, a methodology will help you break things down and manage complexity better. This will also help you manage risk. Risk management is also an important part of many popular methodologies. I'm going to talk a little bit about framework standards and methodology that we can use in our architecture work. SAPSA is a popular methodology for developing business-driven risk and opportunity-focused security architectures at the enterprise level. It can be adapted for use in projects but also for use with cloud architecture. SAPSA ensures that the needs of your enterprise are met completely and that security services are designed, delivered and supported as an integral part of your business and IT management infrastructure. Although copyright protected, SAPSA is an open-use methodology, not a commercial product. SAPSA does not replace ITIL, ISO 27001 or NIST frameworks but rather enables their deployment and effective integration into the corporate culture. NIST has a comprehensive security framework consisting of three components, core implementation chairs and profiles. The NIST framework core provides a set of desired cybersecurity activities and outcomes using common language that's easy to understand. The core guides organization in managing and reducing the cybersecurity risks in a way that complements an organization's existing security and risk management processes. The NIST framework implementation chairs assist organizations by providing context on how an organization views cybersecurity risk management. Chairs are often used as a communication tool to discuss risk appetite, mission priority and budget. NIST framework profiles are an organization's unique alignment of their organizational requirements and objectives, risk appetite and resources against the desired outcomes of the framework core. Profiles are primarily used to identify and prioritize opportunities for improving cybersecurity in an organization. ISO 27001 is a widely known service security standard providing requirements for an information securities management system. There are more than a dozen standards in the ISO 27000 family. Using them enables organizations of any kind to manage the security of assets such as financial information, intellectual property, employer details or health information. Many cloud service providers offer security controls mapped to the ISO 27001 standard. The CSA cloud controls matrix, the CCM, is a cybersecurity control framework for cloud computing composed of 197 control objectives that are structured in 17 domains. The CCM can be used as a tool for systematic assessment of a cloud implementation. It provides guidance on which security controls should be implemented by which actor within the cloud supply chain. The Kaik as I talked about earlier in the course is a questionnaire answered by the cloud provider. It matches the structure of the CCM. The controls in the CCM are mapped against industry accepted security standards, regulations and control frameworks including ISO 27001 and NIST. Risks can be combined and used together in a structured way. It's important that you tailor the methodology to your own organization. Use and incorporate the frameworks you consider most appropriate for your business needs. Risk management is a very wide topic that deserves its own course. In this course I will talk about managing risks that are important to cloud architectures. Risk management is an important part of developing a security architecture. You need to be aware of the risks that you face as a cloud customer and how to mitigate them. You should conduct a risk analysis during your security architecture development project. Guidance on how to perform a risk analysis is not part of this course but good documentation can both be found in the SAPSA methodology and the NIST CSF. Choose the methodology in the framework that suits you the best. The first and most important part of the analysis is to identify the risks. I have given references to information on cloud risk in this slide. Both CSA and NISA offer good descriptions of cloud risks. This is a very good starting point. You should, depending on your architectural requirements, come up with more detailed risks covering the specifics of your services or solutions. Once the risks are identified they must be scored and prioritized. The security services and controls in your architecture should be implemented to mitigate the risks that you have identified. If your business has a low risk appetite then ensure that you use a defense in depth model where security controls are incorporated at each layer. We will talk more about defense in depth later in this course. Many organizations develop a cloud strategy. A strategy will help the organization get the most benefits from the cloud initiatives. The strategy takes all the aspects of cloud mentioned early in this course into account. The choice of service and deployment model will impact the way cloud services are implemented and secured. The strategy covers data classification, change management and operational aspects. An important consideration in the cloud that should be included in the strategy is the use of services. One way to go is to choose SAS and PASS over IIS as a service model. Then you buy operational services from the cloud provider and, according to the shared responsibility model, more responsibility for security is shifted to the cloud provider. Similarly, you can buy security controls from the cloud provider as a service. This is often called security as a service. Change management is important for cloud consumers. The services you buy from the cloud provider will be updated throughout the usage period. Update notifications will be sent to you as a customer and you need a way to handle the changes in case they affect the way you and your organizations use the cloud services. Additionally, you have to handle your own changes, both to configuration and to code deployed to the cloud. You should handle changes in the cloud the same way you handle changes in your own data center. ITIL could give you a good set of service management practices. Cloud operation is all about centralization, standardization and automation. This also applies to security operations. Monitoring of security events can be centralized. Handling of the events can be automated and deploying new environments can be standardized and also automated. You can do more in the cloud with fewer personal resources. Your cloud implementation strategy should not be a document ending up in your project archive, but rather be a living document that you constantly seek to improve. The major cloud providers offer a lot of documentation on their compliance status. Independent auditors perform assessments of the cloud vendors infrastructure operations and procedures. Their audit reports are available to cloud customers as documents downloadable from the cloud vendors portal. The cloud service provider should demonstrate compliance with industry standards and frameworks such as ISO 27001 and CSA Cloud Controls Matrix. If you plan to host regulated data, you must ensure that your cloud provider meet compliance requirements such as PSI, DSS, GDPR and HIPAA. When you as a cloud customer deploy your solutions and services on top of the already compliant cloud infrastructure and services, it will be your own responsibility to stay compliant with the same standards and regulations. That means, for example, that your solution must be compliant with GDPR if your user base is located within the EU. You should gain knowledge about regulations, frameworks and standards such as GDPR, ISO 27001, PSI, DSS and HIPAA depending on your business requirements. Follow the links in the resources folder in this section to learn more about regulations, frameworks and standards. So why do we need architecture documentation? We need to document our architecture work to use this for communications with different stakeholders. If you have chosen a methodology in framework, these will help you to structure your documentation. In my work, I often use drawings to visualize the architecture. This is very effective with most stakeholders from C-level executives to developers and infrastructure specialists. But remember that you need a different level of abstractions for use with different groups of stakeholders. As I talked about early in this course, traceability is important for most stakeholders. You want to be able to prove why a security control is needed and trace it back to a regulatory or business requirement. Management or legal team members often asks how a certain requirement is covered. Then you need traceability from the top down to specific security control. My advice is to use visualizations and explanatory text. Keep documentation short and concise, and map to standards and regulations. Always keep it updated. In this section, you'll learn about the steps you need for creating security architecture for the cloud. You know how to gain knowledge about methodology, frameworks and standards. You know why risk management and strategy is important for cloud services and how you can approach compliance. You'll learn about architecture documentation and why you, as a cloud security architect, must be a good communicator. The steps and topics we have covered in this section provides a good basis for designing and documenting the security architecture. When we move on to the implementation phase, we need to choose a cloud service provider. We must also examine how to implement our architecture using the provider service offerings. These are the topics for the next section. In this section, I will talk about important considerations for implementing the cloud architecture. I will not go into cloud service provider specific solutions or infrastructure, but talk about security controls that all major providers will offer you. This section will give you insight into implementing the cloud security architecture, covering governance and policies, identity and access management, data security, network security, application security and security operations. Layer defenses will also be discussed. To wrap up, I will give you cloud provider specific references for further reading. After self-study, you can go ahead implementing the architecture yourself using your chosen provider. The three largest service providers are Microsoft Azure, Amazon Web Services and Google Cloud. These very large providers combined have more than 50% of the cloud services market. Choosing a provider is a business decision, but can also have an impact on the security architecture. Your security architecture will help you get an overview of what type of security controls you need to protect your services. That makes choosing a provider simpler from a security perspective. Many organizations pursue multi-cloud strategies. This can help you avoid vendor lock-in and potential help reducing costs. A consideration that you must make as a cloud consumer is how the multi-cloud approach will change your security architecture. It will be more complex to manage security across cloud service providers and you need provider specific security controls for each provider you choose to use. Architecture implementation is about architecting appropriate security controls that protect confidentiality, integrity and availability of information. This can help mitigate threats to cloud security. Security controls can be delivered as a service by the cloud provider, by the enterprise or by a third-party provider. Security architectural patterns are typically expressed from the point of the security controls, both for the technology and the organizational processes. These security controls and the service locations either enterprise, cloud provider or third party should be highlighted in your security architecture documentation. Architecture implementation must cover both organizational and technical measures. The overall security posture for your cloud services will depend on the governance policies and processes you establish, as well as the technical security controls you select. I will talk about important topics for implementations in this section. Governance and policies is about people and processes. Identity and access management is about the life cycle of identities. Data application and network security is important for protecting your valuable information assets. Layer defenses is a principle that brings it all together and forms the baseline of your security posture. Security operations is vital for monitoring your environments. And finally, the reference architectures from the cloud providers will give you valuable details on how to implement your environments using their cloud offerings. You should align your cloud governance with your business strategy. Keep your business objectives in mind as you develop your governance policy and find some common ground between a strong governance policy and the flexibility to innovate. Separation of responsibilities is important for keeping your data secure. Rules and roles should also be clearly defined so you know who has access to what and why. Policies will help you stay compliant. Make sure your governance policy incorporates any external rules an outside organization or regulator might enforce on you. Plan how to handle an audit should the need arise. Automation is a key success factor in cloud operations. It enables you to scale your business in the cloud. Incorporating automated systems into the cloud governance framework can ensure violations of your policies are more easily caught. To protect the data in the cloud, governance policies must be in place. Customize your governance policies so your most valuable or sensitive data follows stricter governance rules than your public data. Using policies in the cloud can effectively block users from doing misconfigurations. This will help reduce your overall risk significantly. Identity and access management protects data by ensuring that only the right people have access to the right information at the right time and for the right reasons. The task of determining job responsibilities and access needs for users and then grouping those common users together into roles may sound like a tedious task, but spending the time to do this correctly will save you frustration and extra work down the road. Automation will help you minimize the manual work needed. You should apply a join or move or lever process for handling identity lifecycle. Privilege access management is used for protecting accounts with administrative access rights. The cloud provider should provide functionality for protecting identities with privileged roles. Functionality for temporarily elevating user rights is often offered to cloud consumers. Role-based access control is the default mechanism for cloud consumers to assign access rights in the cloud. Employees are assigned built-in cloud roles or given membership in security groups designed by you as a cloud consumer. Access keys are often used for giving applications or users access to data. These keys must be kept confidential and have a short life to minimize the risk of unauthorized use. Data security is as important in the cloud as in your own data center. You need contextual access control so you can ensure secure access to the data based on who the users are, what devices they are using and what geographic locations they're in. You also need application auditing so you can identify who has access which data and create alerts based on anomalous use. This is critical as most SaaS applications don't provide an audit trail of read operations to understand what exactly happened when an incident occurred. Be sure to turn on data loss prevention to make sure that personal identifiable information and personal health information is not moving to or through the cloud in the clear in violation of PCI DSS or HIPAA regulations. You also need the ability to easily but consistently enforce policies in the cloud for various use cases. You can effectively prevent your users from doing dangerous mistakes by creating policies to protect sensitive data. Always use data encryption for transport and storage. These are default settings in many cloud infrastructure implementations. Many cybersecurity attacks happen at the application layer. As a cloud customer, it will be important to protect applications from adversaries. The cloud access security broker can help you manage and protect data stored in the cloud. A cloud access security broker can offer many services such as monitoring user activity and warning administrators about potentially hazardous actions. It can also enforce security policy compliance and automatically prevent malware. Use a web application firewall to detect and block malicious HTTP requests to your web applications. By inspecting HTTP traffic, it can prevent attacks exploiting a web application's known vulnerabilities. These vulnerabilities can be SQL injection, cross-site scripting, file inclusion and improper system configuration. However, a web application firewall will not replace the need for solid web application testing. Use OWASP guidelines and tools for improving the security of your web applications. The acronym OWASP stands for Open Web Application Security Project. A link is provided in the resources folder in this section. Use security capabilities offered in the cloud platform to protect the APIs. Managing the APIs using a common gateway will help administering and securing your APIs. All the networking is taken care of by the cloud provider using IIS and PASS solutions often leave the network security to the cloud customer. It will be wise to choose a network topology for your cloud implementation depending on your business needs. The topologies should provide your users access from on-premises or from home. They will, as an example, need access to development, test and production environments. Environments should be segregated and access between environments must be restricted to strictly necessary communication. Network segmentation is a proving security strategy that lets you set strict rules for which services are permitted between accessible zones. This is also possible to do in the cloud. Designating sensitive data and resources within zones ensures only designated hosts and users belonging to other approved zones can reach them. This is helpful for constraining attacks by making lateral movement across the network difficult. Hackers and malware can't port-skine to identify your critical assets if they're blocked, let alone access them to X-Roll trade data. All network traffic must be monitored, this for detecting potential misuse or attacks. All major cloud providers offer tools for network monitoring, creating alerts. Intrusion detection and prevention will help you discover and block unwanted network traffic. Intrusion detection system, IDS, is a security solution that detects security-related events in your environment but does not block them. Intrusion prevention system, IPS, is a type of security solution that identifies a threat and blocks it so the attack cannot occur. IDS and IPS systems can be provided as a security offering from the cloud provider or from a third-party vendor. Layered security refers to security systems that use multiple components to protect operations on multiple levels or layers. The central idea behind layered security or defense is that in order to protect systems from a broad range of attacks, using multiple strategies will be more effective. The outermost layer in the figure is physical security. The cloud provider manages physical security at all locations. Only authorized personnel have access to different areas of data centers. Identity and access management is a centralist service offered by most cloud providers. All resources are governed and controlled through the centralized service. You can control access to your resources using role-based access control. For privileged roles, many cloud providers offer capabilities like privileged access management for extra protections of identity with elevated rights. For protecting the perimeter, many cloud providers offer distributed denial of service protection. It comes with traffic monitoring in real-time mitigations of common network-level attacks. DDoS protections provides capability to protect against volumetric attacks, protocol attacks, and application attacks. At the network layer, cloud providers often offer rich capabilities for creating rules. You can filter network traffic to and from resources in a virtual network through network security groups, which contain security rules allowing or denying traffic. You can also lock down in-bound traffic to your virtual machines using security controls from the cloud provider for secure access to your environment. Securing compute resources like virtual machines is often offered as a service by the cloud provider. Cloud providers often offer protection against threats using signal processing and can detect security threats like RDP brute-force attacks and a squirrel injection. Disc encryption can be used to protect complete virtual machine images from authorized access. Major cloud providers offer endpoint protection for virtual machines. This can also be bought from a third-party vendor. Applications hosted in the cloud are often web applications. A web application firewall provides centralized protection of your web application from common exploits and vulnerabilities. No busp that I mentioned earlier in this course can be used to actively ensure applications are built with security in mind. Code scanners are also available and can be bought as a service for many cloud providers. The innermost layer in our layer defenses model is the data layer. Data encryption should be used for storage of both structured and unstructured data. You can further control access to the data using authentication mechanisms. Be sure to back up your data and keep the backups at an offline location. You as a cloud consumer must build defenses on top of the cloud provider security offerings. This will give you the best possible layer defenses approach. What controls to be used and how many depends on the services model. Remember the first section when I talked about the cloud shell responsibility model. You need to know your responsibility for security as a cloud consumer. Each separate environment will need multiple defenses both internally and externally. Cloud security operations is all about doing more with less resources. Many organizations struggle with shortage of personnel with the right skills. Centralization, standardization and automation can help you achieve more with less resources. Centralization is the idea that you need to look at tools and cloud services that ideally integrate into a single dashboard. It's very easy in cloud deployments to end up with numerous management tools, dashboards and interfaces to handle operations across environments. This is not exclusive to security tools. Operations and development teams are often faced with the same problems. Using and integrating with the cloud providers tools can help you making operations more seamless and less fragmented. Automation is the core idea behind DevOps and DevSecOps by extension. I will explain DevSecOps a bit later in this presentation. Manual efforts in the cloud are doomed to fail in many cases as environments change very rapidly. Security teams should explore ways to automate their security controls and feedback loops whenever possible. When using cloud services, you as a cloud customer must also monitor cloud usage. Your primary source of feedback is logs. Enable logging everywhere you can within the cloud environment account as a whole in virtual machines, for network platforms, for all identity and access management activity, for all interconnected services and their activity. We show to secure access to logs as well. DevSecOps is short for development, security and operations. Its mantra is to make everyone accountable for security with the objective of implementing security at the same scale and speed as development and operations. From testing for potential security exploits to building business-driven security services, DevSecOps tools ensures security is built into applications rather than being introduced as an afterthought. By ensuring that security is present during every stage of the software delivery lifecycle, we reduce the cost of compliance and software is delivered and released faster. When implementing a cloud security architecture, a good starting point is the existing resources from the cloud providers. These will give you good start for your implementation project. The AWS well-architected framework helps cloud security architect build secure, high-performing, resilient and efficient infrastructure for their applications and workloads. The framework includes hands-on labs and the AWS well-architected tool. The tool provides a mechanism for regularly evaluating your workloads, identifying high-risk issues and recording your improvements. The Microsoft Cloud Adoption Framework provides tools and guidance for implementing not only cloud technologies but also help you with organizational changes. Because it is based on best practices and successful customer and partner experiences, the framework is updated on a regular basis. The Microsoft Cybersecurity Reference Architecture is created for a hybrid infrastructure and describes Microsoft's cybersecurity capabilities and how they integrate with your existing architecture. The document can be used as a starting template for implementing your security architecture. It can also be used to compare your existing architecture against Microsoft Reference Architecture. There are many good architecture resources available, both from independent organizations and from the cloud providers. I'll give you a couple of pointers here for further study. The Cloud Security Alliance, the CSA, is the world's leading organization dedicated to defining and raising awareness of best practices to help your organization ensuring a secure cloud computing environment. As I've talked about in this course, the CSA has tools like the Cloud Controls Matrix and the top threads to cloud security. It's definitely a place to go for learning more about cloud security architecture. Azure has a zone architecture center where you can find numerous architecture examples to use in your own environment. Similarly, AWS offers examples, patterns, and best practices in their architecture center. Google offers a solution architecture reference where you can find reference architecture for infrastructure modernization, data management, app development, and smart analytics. Cloud security architecture implementation can be very different across cloud provider platforms. However, as you learn in this section, many areas of implementations are the same. You have learned about topics for implementations of governance, identity, and access management, data security, app security, and network security. Layer defenses is an important concept and you should pay close attention to how well your security architectures covers the different layers. Plan how to monitor your infrastructure and applications already in the design stage so that your security operations team can get a head start. Use the resources I recommended in this section for implementation best practices not architecture design. Review the security offerings from the chosen cloud provider and integrate the controls that fits your needs with existing tools. I hope you enjoyed the course as much as I enjoyed teaching it. Cloud security has many aspects and affects many different stakeholders in your company. In this course, you have learned that cloud security architecture is different from security architecture for an on-premise implementation. Now you also know that you should use a structured approach and apply business and regulatory requirements as a basis for your architecture approach. Your goal is to provide value for your business. It's imperative that you document your architecture and that you can communicate your results and proposals to different stakeholders. Use a graphical representation rather than just words. Be sure to follow a layered approach to security in the cloud and to investigate the implementation best practices and reference architecture from your chosen cloud provider. Finally, I have a tip for you. Use an agile approach to architecture. Remember that an agile approach lets you do small steps. It gives you the ability to try different ways of implementing the architecture. You may have to go back to your architecture design and do some changes when you learn how your implementation actually works. Using agile methodology and implementation project can also be an initiative for learning. Now we should the best of luck with your security architecture project.