• Introduction
• Principles
• Conclusion

Introduction

In the first part, we have summed up all the essential elements to consider when working with Cloud and securing cloud-native applications/platforms. In this post, we would like to give you some concrete principles and tips for creating more secure applications.

Principles

Multi-Layered Defense

Keywords: general

First of all, a more generic but important principle: It would be best to look at security as a whole – integrating various security layers on multiple levels in any system. It should include cyber-security plans for:

1. Devices
2. Applications
3. Networks
4. Infrastructure
5. People

Think of this principle as all the layers of clothing you wear to protect yourself from cold and bad weather. If one of the layers is compromised, there is always another to keep you warm and dry.

Identity and Access Management (IAM) Misconfiguration

Keywords: network, permissions

You need to control access and permissions meticulously and over time. Things to consider:

• Implementing role-based access control (RBAC)
• Principle of least privilege
• Routines for updating and removing permissions when they are no longer needed.
• Explore possibilities for using time-based conditions for IAM policies.

API Security

Keywords: endpoints, permissions

• APIs act as the gateways to your application and data. Securing access to and securing them from known vulnerabilities is paramount to prevent unauthorized access and data breaches.
• Utilize authentication, authorization, and API gateways to control access and protect sensitive information. Don’t forget to monitor the software or libraries that make APIs available (e.g., runtimes, middleware)

Data Encryption

Keywords: data

• Safeguarding data at rest, in transit, and during processing is critical for your applications.
• Utilize encryption, tokenization, and data masking techniques to ensure data protection. Removing unnecessary sensitive information can simplify some of these tasks.
• If a platform or a Cloud provider provides the encryption, consider if you would like to use the standard keys for encryption or “bring your own” and manage them yourself or through a third party.
• Beware: Don’t write your own crypto! Ever.

Zero Trust

Keywords: network, permissions

• The Zero Trust security model assumes that no one is inherently trustworthy, even those within your network.
• This is opposed to more traditional approaches where perimeter security was prioritized over security inside the network.
• Adopting this approach, every request, user, and device is thoroughly verified before gaining access.
• Again: Implement the principle of least privilege, where users are only granted the minimum level of access required to perform their tasks.

Software Supply Chain Security

Keywords: software, environment

• Create Software Bill of Materials (SBOM) for your software
• Governance: Know where all the building blocks (artifacts) of your software are coming from.
• Automate security checks within your CI/CD pipeline to catch vulnerabilities early and often.
• Use static code analysis with tools like SonarQube to scan your code for potential security flaws and integrate those checks into your CI/CD pipeline to ensure continuous security monitoring.
• Use tools to monitor not only the code you develop yourself but also all the third-party libraries you utilize in your code.
• With DevSecOps, automated security security is becoming integral to the development process. Adopt it if you haven’t done so already.

Secure Containerization

Keywords: software, environment

• Containerization and orchestration technologies, like Docker and Kubernetes, offer exceptional flexibility but also introduce security concerns.
• Securing containers and managing their lifecycle is vital to ensure a safe cloud environment.
• For example, use container scanning tools to identify vulnerabilities within container images before deploying them.
• Additionally, enforce strict security policies and segregate workloads using Kubernetes namespaces.

Continuous Monitoring and Incident Response

Keywords: software, environment

• The cloud landscape is constantly changing, and threats evolve rapidly. This means that we need to monitor not only for known threats but also for anomalies.
• Continuous monitoring and proactive incident response are essential to detect anomalies and respond swiftly to security incidents.
• For example, use cloud-native monitoring tools your Cloud or platform provider provides.
• Have good logging, but remember that more is not always better – log relevant information.

Human Factors (including Social Engineering, Misconfigurations, and Human Errors)

Keywords: people, human factors

• 82% of incidents are caused by human factors (2022 Data Breach Investigations Report)
• Creating secure applications also implies providing security training for the system users.
• Social engineering and human factor has proven to be essential to creating secure applications.
• Consider running security awareness campaigns and employee training from user and developer perspectives.
• Automate routine and mundane tasks – humans often don’t enjoy carrying out tasks like this and are prone to errors; computers, on the other hand, excel at tasks like this!

Conclusion

You have probably heard that nothing is stronger than its weakest link. Therefore, it is important to look at various sides of the security. Especially in the Cloud, one size does not fit all when it comes to security. Cloud platforms, software, and threats constantly evolve and add to the complexity of creating secure applications.

Here, we have seen some of the principles to consider regarding the security of the platforms and application development for the Cloud and cloud-native applications in general.

Finally, note that this is not an exhaustive list but is instead meant to serve as a stepping stone to more secure application development.

• Introduction
• Key Elements of a Cloud Security Architecture
• Responsibilities
• Constantly Evolving Landscape
• Platform Security Architecture
• Application Security Architecture
• Conclusion

Introduction

Whether you are running on the Cloud or not it is all about the CIA triad model – Confidentiality, Integrity, and Availability.

When thinking about Cloud Security Architecture we need to be able to think about the whole stack. Of course, we don’t need to think about all the moving parts alone – it is a shared responsibility between the Cloud service provider and you, the user of the platform.

Key Elements of a Cloud Security Architecture

Let’s first start by defining the key elements of a Cloud Security Architecture, divided across the layers of the stack, based on the Cloud Security Alliance (CSA) stack model.

Now, we can also mention some of the main challenges related to security, divided into separate groups, and try to map them to the CIA triad model that we have mentioned earlier.

Network and Storage

• Data Encryption
• Network Security

Application layer

• Application Security
• Logging and Monitoring
• Identity and Access Management (IAM)

Observability, and traceability

• Incident Response and Recovery
• Vendor and Third-Party Risk Management

DevOps

• Automation and Orchestration
• Resilience and High Availability

General

• Compliance and Governance
• User Training and Awareness
• Cloud Provider Security Features

Responsibilities

Shared Responsibility + Intersection of Responsibilities

Addressing all these challenges is a shared responsibility between the Cloud service provider and the customer and the division will vary depending on the type of the solution and whether you are using IaaS, PaaS, or SaaS.

Typically, Cloud service providers will take care of the lower parts of the stack, like physical, infrastructure, and platform security, while customers will be responsible for creating secure applications, securing their data, creating proper Identity and Access Management (IAM), and configuration management.

An effective overlap and a clear understanding of the responsibilities ensure comprehensive security coverage across all layers.

Constantly Evolving Landscape

Evolving Landscape == Constant Change

One of the differentiating factors from regular application development is the constant change and evolution of the platform and tooling on one side, and the constantly evolving types of attacks and possibly larger attack surfaces on the other side.

These factors will lead to changes in the model and the responsibility division. The same might be influenced by the new services being introduced both from the side of the Cloud service provider and the customer (app developer).

Therefore, regular communication between the parties involved and staying updated on their security practices is essential to ensure secure Cloud applications.

Types of the Cloud Security Architecture

The Cloud Security Architecture is twofold – you will need to choose a platform for running your application and think about the security of the application you will be deploying on that platform.

Platform Security Architecture

Let’s start with defining the types of platforms and list some of the key elements to consider when choosing a platform type.

Public Cloud Security Architecture

• Designed for cloud services provided by third-party vendors (e.g., AWS, Azure, Google Cloud).
• Focuses on securing data and applications hosted on shared infrastructure.
• Utilizes the security features provided by the cloud service provider (CSP) while also implementing * additional security measures.
• Emphasizes network segmentation, encryption, IAM, and monitoring.

Private Cloud Security Architecture

• Created for cloud environments dedicated to a single organization.
• Offers more control over security settings and configurations.
• Often used by organizations with strict compliance requirements or sensitive data.
• Implements strong access controls, encryption, and strict network isolation.

Hybrid Cloud Security Architecture

• Combines public and private clouds to take advantage of the benefits of both deployment models
• Security architecture addresses integration challenges and ensures consistency across environments
• Emphasizes secure communication between on-premises and cloud components
• Requires seamless identity and access management across both environments

Multi-Cloud Security Architecture

• Involves using services from multiple cloud providers simultaneously
• Ensures compatibility and security across diverse cloud platforms
• Requires careful management of authentication, authorization, data protection, and compliance measures
• Aims to prevent vendor lock-in and distribute risk

Application Security Architecture

Here are some things you will need to think about when developing modern applications for the Cloud and the cloud-native world.

1. Secure Your Code

• Software Supply Chain Security: Securing and monitoring your artifacts and third-party libraries.
• Making sure the code you have written is secure: OWASP Top 10, static code analysis, coding best practices.

2. Your Container (and Serverless) Security Architecture

• Specifically addresses security for containerized applications (e.g., Containers, Kubernetes) and serverless computing (e.g., AWS Lambda, Azure Functions, Cloud Functions, or Cloud Run on Google Cloud)
• Focus on securing microservices, communication between them, their orchestrators, and function-as-a-service (FaaS) platforms
• Involves isolating containers, securing images, and managing runtime security

3. Add DevSecOps Architecture Practices

• Integrate security practices into the DevOps process: DevSecOps
• Ensure security is considered at every stage of application development and deployment
• Involves automated security testing, vulnerability scanning, and security policy enforcement

4. Cross-application and Cross-container communication: Zero Trust Security Architecture

• Assume no trust by default and require strict authentication and authorization for all users and devices
• Focus on identity verification, principle of least privilege, and continuous monitoring
• Suitable for cloud environments where traditional perimeter defenses are less effective

5. Physical security: Edge Cloud Security Architecture

• Address security concerns at the edge of the network, closer to where data is generated and consumed
• In case of having local edge hardware devices consider also physical security of those devices
• Involves considerations like local processing, secure communication, and protection against threats targeting edge devices

6. Compliance-Centric Security Architecture

• Tailored to meet specific regulatory compliance requirements (e.g., GDPR, HIPAA, PCI DSS)
• Focus on implementing controls and safeguards to adhere to relevant standards

Conclusion

We have seen the key elements of the cloud security architecture and the building blocks of the whole stack. Furthermore, we have looked at the various types and elements to consider when it comes to the security of the platforms and application development. This is a stepping stone to categorize and group some of the main things you will need to consider when working with the Cloud and cloud-native applications.

** Illustrations in this post: Rustam Mehmandarov.

• The Story
• Information Security
• Norwegian Personal Data Act (Personopplysningsloven)
• EU GDPR
• The Bottom Line

The Story

It all started when I had to deliver my Apple device for service due to some hardware issues to one of the biggest Apple Premium Resellers and service centers in Norway. After handing in the product, I got an SMS and an email containing a link to a website where I could track the progress of the service online. So far, so good.

While logging in I realized that I already had an account, but did not have the password, so I decided to reset that – that’s where it all started.

The first thing I did, was to push the big, blue “Forgot My Password” button. Unsure if I had to type in the email first, or if I would be forwarded to another page, where I would have to provide my account details to process with the password reset procedure, I just clicked the button.

However, instead of being redirected to a new page, or getting an error about the missing e-mail in the form, I was presented with this page. Are you noticing anything strange?

Well, yes, the site reset the password and sent it over to an email and as an SMS. Cool! The only problem was that at that point it could not have any idea who I was, since I have not provided any information about myself yet, and there were no cookies to identify myself to that site.

Another problem there was that the phone number is shown in clear text (hidden here) was not mine. So, I just reset the password and sent it over to some random user – possibly the first, or the last one in the users table. I tried a few times just to make sure that it was not my fault, and I was still resetting the password for the same person (sorry, total stranger!).

Having worked with systems development for quite some time, I shrug my shoulders, slightly shook my head, mumbled something about weird bugs and reset my password. This time by providing my e-mail address, proceeding to check the status of my device.

Then, it suddenly hit me. By only providing an email to a service, I could see a confirmation about my password is sent to my mobile phone number registered in the system – in clear text!

While the first bug (resetting the password for a random person) might be just annoying to a small group of users, the second one (dumping the phone numbers from the database in clear text) was much worse for a bigger group of people. Why might you ask?

Information Security

Well, given the fact that the company is being one of the biggest service centers for Apple products, it is very likely to assume that many people would have owned, and sent in for a service an Apple device at some point in the past; thereby getting registered in the service provider’s database.

So, now I was sitting in front of an unintentional yellow pages (a.k.a. phone directory) service that could provide me with phone numbers of nearly anyone I wanted by just manually typing their emails, or by creating a script that would try scrape the Internet, or just simply construct emails by putting together firstname.lastname and some @provider.com, and dumping all the phone numbers from their customer database.

Well, of course, bugs happen, so I don’t want to jump into conclusions about the lack of proper testing or similar in general.

However, when we provide data to a company, we expect them to handle it with integrity and care, and not leak personal data to the outside world. While phone number might be considered a low-risk data to be leaked for most of us, it might still be quite sensitive for some groups of people, like some high-profile politicians, celebrities, or anybody else how might have a wish, or even a need, to hide their contact information.

Norwegian Personal Data Act (Personopplysningsloven)

Also, according to The Norwegian Data Protection Authority (Datatilsynet), any information that can be used to identify a person is considered personal. Further, Personal Data Act chapter 2, section 13 (Norwegian: [Personopplysningsloven] from 2000) requires that “the processor shall by means of planned, systematic measures ensure satisfactory data security with regard to confidentiality, integrity, and accessibility in connection with the processing of personal data”.

Further, according to the Personal Data Act section 46, The Norwegian Data Protection Authority (Datatilsynet) may impose a fee for violations of the act, or the regulations, with an amount up to ten times the basic amount of the National Insurance, equivalent to 925,760 NOK (as of May 2017).

EU GDPR

If the fines mentioned above sound bad, just wait to see how expensive it will get with the introduction of EU General Data Protection Regulation (GDPR) next year.

With the introduction of GDPR in 2018, the maximum amount of fines will be raised significantly with an upper limit of 20 million NOK, or the company’s 4% of the total global annual turnover in the previous fiscal year, if this is higher (GDPR art. 83, item 5).

The Bottom Line

Storing any personal information is an important task and requires rigorous testing and planning on what data you collect, why and how it is protected. Deviating from that can be rather harmful to your company both in regard to reputation and the financial penalties.

That all being said, it is important to note that all of the problems I reported to the company in question were fixed within a few hours. However, I don’t know for how long that data was available online, and if anyone had taken advantage of the vulnerability of the system.

Least but not last, I would like to thank the company, and especially the company’s CIO for great communication and quick responses and fast bug fixes.