We have seen a mass migration of data and applications form local datacenters to the public cloud. Now while the cloud is not perfect it has a lot going for it. The positives include an elastic, resilient and fault tolerant architecture. The cons are that its highly configurable and requires the proper controls, monitoring and service architecture to make it secure.
So there are several questions that security leadership must confront and ignoring the cloud is no longer feasible. Here are some questions to reflect on before engaging with infrastructure, application and DevOps teams.
- Do we have an overall strategy and approach to secure Cloud (SaaS, PaaS and IaaS)?
- Do we leverage multifactor authentication for all Cloud services. If so, are governance gates in place to prevent shadow cloud?
- How do we inventory and track cloud assets? Who are the owners, are we tagging resources?
- Are all of the cloud logs being monitored and what anomalies are we alerting on?
- Are our cloud or multi-cloud configurations monitored for compliance and for over exposed access or permissions?
- How are vulnerabilities discovered and managed in our cloud computing environment? Do we leverage golden images for virtual machines? Do we patch or replace vulnerable assets?
- Who manages the cloud account and subscriptions and what is the default security policies and overall security governance for new cloud accounts?
- Do we have an encryption standard for the cloud? Where are keys stored, HSM? What aren’t we encrypting and why?
- How are privileged accounts managed? Where are the sensitive passwords stored, how often are they rotated. How are runtime secrets secured? PIM vs PAM
- How is our cloud networking secured, zero trust, remote access, firewalls, Internet Egress, URL filtering and remote browser isolation?
- How are IAM resource policies provisioned and how many resources contain star (*) permissions?
- Do we have centralized WAF / DDOS / CDN / DNS services in place for cloud services?
- How do we secure API’s and do we have an API gateway with proper security controls and governance?
- How are we controlling access to SaaS solutions and are we monitoring for sensitive data loss or exfiltration? Think CASB.
- How is data in transit secured and how are certificates, PKI managed for cloud endpoints?
- Does our threat intelligence cover the cloud? Are SecOps actively engaged to investigate cloud based incidents and events?
- Does our GitHub type accounts contain any sensitive information? How do we know?
- How are code vulnerabilities identified, risk prioritized and remediated? Do we leverage static, dynamic, open source code scanning or a bug bounty program?
- What is the strategy for cloud security services such as, big data analytics, Kubernetes, Docker, Serverless, microservices and IOT to name a few.
- Does our CI/CD pipeline have security gates. How can security shift left and prevent inferior code and configurations before deployment?
Part of the misconception surrounding cloud security has been the preoccupation of the underlying hardware, hypervisor and shared public hosting. This centered around hosting compliance reports and certifications generated by cloud vendors (AWS, Azure, Google) essentially saying they run a tight compliant ship. They in fact don’t mix their clients peanut butter and chocolate. These are critically important but should not be confused with securing the highly configurable cloud services and understanding the shared responsibility model. We should be able to stipulate that AWS, Azure and Google can run a datacenter better than most and better than most governments. The vulnerable pieces of the puzzle are, how data and services are configured and how anomalies are monitored. Errors or omissions of the smallest variety can expose sensitive data and lead to a breach.
Where should we start. There is only one place to start and it’s with the security organizational design. Cyber cloud security must be more decentralized and work closely with developers, platform engineers and architects. This has been traditionally the role of a cloud security architect and this is appropriate for smaller or early adopters of public cloud. Larger and more mature cloud consumers need security in the trenches. This has brought about a relatively newer function called “DevSecOps”. Ideally, (cloud, security and enterprise) architects set the overall strategy, controls framework and evangelize the security design and requirements. This new functional group of (DevSecOps) security engineers help DevOps work through the security design and best practices. The goal is to create the proper feedback loops so the security gates can be adjusted to emerging challenges to their adoption. This shifting to the left, allows security to Continually Improve and Continuously Deliver at birth rather than security as a painful expensive afterthought. This investment has to start at the organizational level, bring security to the trenches and security will continually improve.