Welcome! This is the ninth edition of CloudProfs, sent to subscribers on October 1. See the email in-browser here.

If you enjoyed this newsletter, why not sign up to receive it in your inbox every week? Or if you have any feedback, email the editor.

---

What’s Been Done in Cloud This Week

Cloudflare has launched an R2 Storage product offering, putting the web performance company squarely in competition with various cloud service providers. R2, as CEO Matthew Prince jokingly put it, was named as being ‘one less than S3.’ It includes full S3 API compatibility, and its stated product aim is to eliminate egress bandwidth, which can be a headache for developers utilizing object storage, as well as being hard to predict. Cloudflare also promises 11 (eleven) nines of annual durability. In other words, if you store 1 million objects on R2, you will lose one, on average, every 100,000 years. Prince wrote on Twitter this week: “Fun fact: AWS hasn’t reduced the price of S3 since December 2016”, noting the direction of competitive travel.

Further reading: Stratechery: Cloudflare’s Disruption | Matt Quirion: Cloud Legos, Not Cloud Jack-of-all-Trades-in-the-Box

Tencent Cloud has launched two new certification programs for Practitioner and Solutions Architect Associate focus. Practitioner is aimed at a beginner level, teaching a foundational knowledge in cloud computing. Successful graduates will be able to explain the different features, advantages, use cases, and billing methods of core Tencent Cloud products. Solutions Architect Associate is aimed at a more intermediate level focusing on cloud architecture design. Graduates will be able to design cloud solutions which incorporate the principles of high availability, high security, high scalability and cost optimization. Both courses start October 1.

Eight of the world’s largest tech companies, including Amazon, Google and Microsoft, have signed up to an agreement called Trusted Cloud Principles. The agreement is based on achieving a balance between ensuring customers’ privacy and security while still being able to conduct business across borders. The principles include allowing governments to support cross-border data flows, with cloud providers having a right to protect customers’ interests. The full list of members is: Amazon, Atlassian, Cisco, Google, IBM, Microsoft, Salesforce/Slack, and SAP. Read more here.

A new free cloud security test tool has been launched which aims to ‘rapidly detect unprotected cloud storage in 16 public cloud service providers.’ ImmuniWeb, a provider of AI technologies for application security, has released the cloud security test as part of its set of Community Edition free online tools. The test takes approximately 15 minutes and requires users to simply add their company’s main website URL.

---

What’s Been Said in Cloud This Week

Don’t have time to listen to podcasts? Worried what great insight you’re missing? CloudProfs has you covered.

Elliott Abraham, security and compliance specialist at Google Cloud, on the decisions enterprises have to make on their architecture (3:09 in this podcast).

“Lift and shift versus cloud native is a topic that really, really comes up a lot when we meet especially with enterprise customers, because most of the time they’re trying to figure out ‘we want to move to the cloud’, but there is still this inertia of wanting things to stay the same, with lift and shift. With cloud migration writ large, you have to figure out what the best strategy is to move to the cloud – are you going to re-host, re-platform, or am I going to have to do some form of refactoring?

“About lift and shift versus cloud native, it really all depends on the application, and what the customer is going to do. The security implications really depend on how data-centric the applications are. Most people tend to think in a very, very legacy mindset. If there’s a bad habit that is on-prem or off-cloud, they tend to want to bring those same types of bad habits into the cloud world.

“A flat network on-prem tends to become flat in the cloud. For example, a LAMP stack, which is a novel idea and great for developers to get their feet wet and learn how to do stuff, is a terrible idea when you try to move that same type of application to the cloud. With something like LAMP, you have Linux, you have Apache, you have MySQL, you have PHP, you have your application server, database server, all centralized in one platform.”

Rob Hirschfeld, CEO of RackN, on the future of infrastructure technologies for enterprises (14:51 in this podcast).

“If you look in front of you and aren’t terrified of the impending complexity, overwhelming your ability to keep up with what’s going on, then you’re not watching how these systems are evolving. We’re now moving into one cloud and then solving all the problems, even the clouds themselves have huge surfaces with a lot of moving parts on it. And so to me, the real challenge that companies need to be thinking about the next five years is not how do I limit complexity, but how do I manage the complexity.

“When I look at where things are going, it’s very important that we start thinking about how some things can be standardized – this idea of building clouds to code, so that we have more standard operating practices and procedures that are known safe.

“And even though it’s really hard, helping wrangle teams to be using standard components, or standard processes. This has been a struggle throughout my career, over 20 years of IT teams coming in and then developer teams rebelling against it. We have to have tools and products that help everybody roll together. Just pounding the table and saying ‘automate, automate, automate’ is right now creating more work for more people.”

Will Button, from DevOps for Developers, on the question: do DevOps engineers need to know how to code? (6:06 in this podcast)

“I think in the long run, the answer is yes. I don’t think it’s a barrier to starting a career in DevOps. But it’s something that you’re going to want to pick up as you progress throughout your career. For me, a large part of what I do in DevOps, or DevOps-related tasks, is supporting the development team, helping them write better, faster, more efficient, more scalable code.

“Where programming skills have helped me the most is whenever I’m working with those teams, and they need to do something to make their application more resilient. They’re trying to build out the metrics to know when it’s time to auto scale based on application-specific metrics, or create a logging solution where they can create logs and send them off to a logging facility somewhere. A lot of times that’s just written as part of their application, whether it’s a Node.JS API server, or Python server, or Go, or whatever.

“That’s probably my biggest reason for learning to code – probably not at a level that someone who writes that language day in, day out is going to be at, but being able to look at the code, understand it, and rationalize it to help them achieve whatever goal they’re trying to achieve.”

---

The Unpredictable Security Challenges After Enterprises Adopt Cloud-Native

By Rajeev Kalia There is an increase in a cloud-native approach around the world in the era of COVID-19. Almost every other organization is either moving or planning to move to cloud-native apps to take the advantage of building robust, scalable, and cost-effective applications. Cloud-native applications can be deployed across hybrid cloud architectures, with a combination of public cloud, private cloud and on-premise being another useful advantage. Cloud-native app development includes microservices, DevOps, agile methodology, containers or serverless, and continuous delivery. Due to complex tenants, organizations are facing unpredicted security and networking challenges.

Cloud-native application security challenges In addition to traditional security issues cloud-native introduces more security challenges from the infrastructure and application viewpoint. Following are a few important to consider: Security consistency: Organizations are facing challenges in maintaining the same type of security in on-prime data centers and public cloud environments where cloud-native applications are deployed. In some cases, existing security tools do not support cloud environments Lack of security culture: In most of the organization application development and DevOps teams do not consider security as development responsibly and do not want to involve cybersecurity colleagues from the beginning Multiple cybersecurity controls:  Organizations keep on increasing complexity by using multiple security controls in transformation/migration from traditional to cloud native application. It makes the system complex and results in severely reduced effectiveness of any system or software Lack of visibility:  A lack of visibility is one of the most important cloud security challenges. Some organizations consider continuous monitoring useful, and it affects its ability to have solid incident response plans In addition, the Open Web Application Security Project’s (OWASP) Cloud-Native Application Security Top 10 document provides security professionals with an overview of the most critical security risks. A few examples are insecure cloud, container or orchestration configuration, injections, cross-site scripting (XSS) and improper authentication and authorization. An approach to overcome challenges    Following are a few steps that can help overcome the security challenges of cloud native applications: Shift security left: Shift left refers to moving security sooner in the development process. As the solution moves through the stages of conception, design, develop, build, and test, security was often a final step, prior to production deployment. To prevent business losses and interruptions it is important to allocate security responsibilities to designers and developers of the systems and software.  With the help of principles like “security by design” and DevSecOps concepts, we can help automate the integration of security at beginning and every phase of the software development lifecycle, fixing issues before moving to production

Defense in depth:  This security architecture offers layered security. It is based on the design to protect the physical, technical, and administrative aspects of a network. With defense in depth, security layers would include threat detection, antivirus programming, firewalls, anti-spyware programs, multi-factor authentication (MFA), and biometric authentication Cloud-native architectures deals with all kinds of attacks. Physical security of the workplace and intense security training of the workforce is also a part of Defense in Depth Identify security gaps: It is important to identify overlapped security controls and tools and   consolidate on fewer numbers of effective tools. This will increase efficacy and improve security Continuous monitoring: This automated process helps to observe and detect compliance issues and security threats during throughout the software development lifecycle. It helps organizations to monitor and detect uncovered vulnerabilities in real-time. It keeps the system ready to respond to new threats Continuous improvements: As a cloud-native architect, it is important to understand new vulnerabilities and refine architecture to make it more simplified and refined. Continuous adoptions and improvement is the key to success Security-first culture:  Spread a culture of “security as collective responsibility” across enterprise.  Developers are not security experts, but they should be educated in security practices and Security teams should also understand how the applications are developed. Ensure development, DevOps, operation teams involve security professionals at every step. Conclusion There can be several unpredicted security challenges after adopting cloud-native. The cloud-native computing challenges can be overcome by implementing strategies like “shift security left”, “defense in depth” and “security-first approach”. This will help in making a smooth and secure transition to a cloud-native model.

---

Research Analysis: Unit 42 Cloud Threat Report, 2H, 2021

The Unit 42 Cloud Threat Report for the second half of 2021, analysing key cloud infrastructure threats, was published by Palo Alto Networks this week. The report analysed data from a variety of public sources and had two alarming findings: first, 63% of third-party code templates used in building cloud infrastructure contained insecure configurations, and second, 96% of third-party container applications deployed in cloud infrastructure contained known vulnerabilities.

In addition to the report, Unit 42 was commissioned by a ‘large SaaS provider’ (and a customer of Palo Alto Networks) to run a red team exercise against their software development environment. The result? In three days, one Unit 42 researcher discovered critical software development flaws that left the customer vulnerable to an attack similar to the SolarWinds and Kaseya VSA incidents.

The customer had what ‘most would consider a mature cloud security posture’, the researchers noted. Yet there were several critical misconfigurations and vulnerabilities in their development environment.

The report also examined Terraform modules as a key example of the strengths and benefits of infrastructure as code (IaC) and open source. Unit 42 researchers used Checkov, from Bridgecrew, to analyse more than 4,000 Terraform templates in popular open source repositories. 63% of the templates overall contained one or more insecure configuration, with almost half (49%) containing at least one critical or highly insecure configuration.

It is worth noting in the research that IaC misconfigurations analysed were created by the user, not CSPs or IaC providers. “In the context of the shared responsibility model, IaC template configuration belongs entirely to the cloud user,” the report notes. “The challenge for organizations is ensuring that secure IaC configurations are consistently enforced across multiple cloud accounts, providers, and software development pipelines.”

There were also various misconfigurations noted within the three largest public clouds. The research noted the top five most common alerts addressing insecure configurations for each CSP:

AWS:
1) Ensure all data stored in the Launch configuration EBS is securely encrypted
2) Ensure all data stored in the S3 bucket has versioning enabled
3) Ensure all data stored in the S3 bucket is securely encrypted at rest
4) Ensure no security groups allow ingress form 0.0.0.0:0 to port 22
5) Ensure VPC flow logging is enabled in all VPCs

Azure:
1) Ensure default network access rule for Storage Accounts is set to deny
2) Ensure storage for critical data is encrypted with Customer Managed Key
3) Ensure that the expiration date is set on all secrets
4) Ensure Storage Account is using the latest version of TLS encryption
5) Ensure that ‘Secure transfer required’ is set to ‘Enabled’

GCP:
1) Ensure that VPC Flow Logs is enabled for every subnet in a VPC Network
2) Ensure ‘Block Project-wise SSH keys’ is enabled for VM instances
3) Ensure VM disks for critical VMs are encrypted with Customer Supplied Encryption Keys
4) Ensure that instances are not configured to use the default service account
5) Ensure all Cloud SQL database instances require all incoming connections to use SSL

You can read a top-level overview of the report here.