Skip to the main content.
Downloads Thriftly Login
Downloads Thriftly Login
Group 762

Migrate and run DataFlex applications with Oracle, MS SQL Server, PostgreSQL, MySQL &  MariaDB.

flex2Crystal

Stuck in Crystal XI?  Upgrade and use the latest versions of Crystal Reports with DataFlex applications. 

BTR2SQL

Seamlessly convert from Btrieve transactional database to PostgreSQL, Oracle, and MS SQL Server.

thriftly-1

Quickly build multi-protocol web services with the same API. Supports JSON-RPC, REST, SOAP,  Thrift, and gRPC.

 Group 671-1

 

Why Mertech?

7 min read

Cloud deployment security risks, implications and prevention measures

Cloud deployment security risks, implications and prevention measures

When modernizing from being a traditional software vendor deploying desktop applications to cloud-native SaaS applications, it is crucial to evaluate cloud security's potential risks and consequences carefully.

A company's firewall protects on-premise Windows applications. If the application had a client/server architecture, the clients were also located behind a firewall. The main security concern in these setups was typically user management, such as validating user identities and determining their access rights. However, for a SaaS product running in the cloud,  you must consider new security risks that you didn't have to worry about before.

So, how can you ensure the integrity of your SaaS application in the cloud, and are the risks worth it? We firmly believe they are, so we have compiled this comprehensive guide on cloud deployment security risks and how to mitigate them for a secure and modernized cloud-native application.

Cloud security risks of modern-day deployment 

From the perspective of safeguarding applications, the advent of the open Internet as a universal channel of communication among cloud-based application components, on-premises components, and user devices (laptops, phones, tablets, etc.) necessitates implementing security measures like encryption for every message and API connection. Securing these elements is crucial to mitigate potential security risks, which can be classified into two main types:

Application Level or Internal 

When deploying a SaaS application to the cloud, there are multiple security risks and potential vulnerabilities that you should look out for at an application level. According to OWASP, these can vary depending on the architecture and technologies used, but here are some examples of the major ones to keep in mind.


1. Data Breaches

Data breaches can potentially cause significant harm, including the theft of sensitive information, financial repercussions, damage to reputation, and non-compliance with data protection laws. Several aspects can lead to data breaches:

  • Inadequate Data Encryption: Data stored in the cloud may be vulnerable if encryption is not properly implemented for data at rest and in transit.
  • Weak Access Controls: Insufficient access controls can lead to unauthorized users accessing sensitive data.
  • Compromised PII (Personally Identifiable Information): Threat actors are particularly drawn to it, as it holds immense value in the dark web marketplace. These individuals will go to great lengths to collect PII and then exploit it for identity theft and phishing attacks.
  • Improper Firewall Rules: Incorrectly configured security groups or firewall rules can allow unauthorized traffic into your network.


2. Code Vulnerabilities

Code vulnerabilities threaten SaaS applications regardless of whether they're deployed on the cloud or not. However, they can be especially dangerous as part of app modernization and migration projects from legacy to cloud.

The good news is that all modern languages creating and consuming web-facing RPCs (REST, SOAP, etc.) can be secured. The bad news is that they are not secured automatically.  Security-aware developers must write code-specific ways to make sure their code is secure. Some of the major risks include:

  • Injection Attacks: Poorly coded input validation can lead to SQL injection, NoSQL injection, or other injection attacks.
  • Cross-Site Scripting (XSS): Improper user input handling can enable attackers to inject malicious scripts into web pages.
  • Cross-Site Request Forgery (CSRF): Lack of proper anti-CSRF measures can lead to attackers tricking users into making unintended actions.

3. Insecure APIs

Web APIs are particularly important to secure because, unlike web applications that are designed to be used by people, web APIs are designed to be used by other programs. While web APIs are vulnerable to many of the same kinds of attacks as web applications, such as SQL injections, they are easier for hackers to attack because they can write programs to perform their attacks. 

In other words, while it is possible to create highly secure web APIs, it’s also completely possible to create highly insecure APIs.

4. Identity and Access Management (IAM) Issues

IAM practices are crucial for managing and regulating access to cloud resources, allowing organizations to control and secure their data and applications in the cloud. Some of the main pitfalls that this aspect can suffer from are:

  • Weak Authentication: Weak passwords or lack of multi-factor authentication (MFA) can make it easier for attackers to compromise user accounts.
  • Ineffective Authorization: Improperly configured role-based access control (RBAC) or permissions can lead to unauthorized resource access.

Infrastructure Level or External 

Infrastructure-level security threats refer to the vulnerabilities external to the application and related to the cloud environment. Some of the main OWASP threats fall under this category, as they can be handled by providing this layer in front of the application. 

1. Configuration and setup

Improperly configured settings and inadequate cloud security strategies often serve as the main entry point for threat actors to gain unauthorized access to sensitive data, including passwords, financial information, phone numbers, and more. These misconfigurations act as a gateway for attackers, putting cloud data at risk of breaches and compromising the system's overall security.

Below is a compilation of some of the commonly misconfigured cloud components that can potentially jeopardize the security of the cloud environment:

  • Open Ports: Leaving unnecessary inbound and outbound ports open can provide attackers with entry points into your cloud resources
  • Publicly Accessible Buckets, VMs, and hosts: Misconfigured cloud storage containers (e.g., Amazon S3, Azure Blob Storage), VMs, and hosts that are set to "public" instead of private (or just too permissive) can expose sensitive data to the internet.
  • Unprotected Databases: Using weak passwords or default database credentials can result in unauthorized access or data breaches. Not to mention that failing to isolate databases from public networks can expose them to external threats.
  • Improper Firewall Rules: Incorrectly configured security groups or firewall rules can allow unauthorized traffic into your network.

2. Operation visibility

When transitioning your workloads to a public cloud, the concept of operational visibility becomes crucial. It entails the ability to effectively monitor, track, and comprehend the various activities, events, and behaviors within your cloud computing environment. However, it's important to note that migrating to the cloud means relinquishing certain controls that were previously available on-premises. The following elements are just some of the aspects that can result in a security threat:

  • Insufficient Logging & Monitoring: Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to attack systems further, maintain persistence, pivot to more systems, and tamper, extract, or destroy data.
  • Broken Access Control: Restrictions on what authenticated users can do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

Examples and best practices for a secure cloud deployment

If you browse our application modernization case studies, you'll see that security is a cornerstone in our cloud deployment and modernization processes. But how can you do the same?

The answer lies in following best practices to make sure you are transitioning to cloud without creating any loose ends and vulnerabilities that attackers can exploit.

1. Authentication

Let’s take one familiar example - authentication.  Let’s say a user successfully logs into a cloud application. Then, the user’s application needs to make subsequent API calls to the cloud application. Does the user have to log in over and over to make multiple API calls?  Fortunately, they do not. The receiving API needs to know who is making the call to determine if the request should be carried out and data returned.   

To avoid repeated logins, internet standards people have developed identity tokens such as the JSON web token that perform this exact function. They communicate identity information across the internet securely and scalability, so APIs have the information they need to make authentication and authorization decisions.

However, things are much more complex when traditional Windows developers are used to managing. For one, JSON web tokens have finite lifespans. If they are not used quickly enough, or the lifespan is not extended, the user has to reauthenticate to get a new token. Multiple re-logins do not make for a smooth user experience (or a happy customer).

2. Penetration testing

Having your SaaS application running in an on-premise environment means that you typically approach penetration testing following traditional methodologies. However, cloud penetration testing requires different approaches. Spoiler alert: it’s not the same as the standard, but it’s definitely as critical (if not more). 

The scope of penetration testing procedure for cloud deployment security entails various stages, going from evaluation and exploitation all the way to remediation. This scope can be categorized under three main types: 

  • Black Box method refers to the procedure where the pen testers aren't given any prior knowledge of the cloud systems on which they perform the attack simulation. This method allows you to identify and eliminate potential security vulnerabilities from an external level (malicious attacks from outside your cloud infrastructure). 
  • Grey Box method refers to the procedure where the pen testers have partial access to the cloud systems they’re testing, whether it be limited administration privileges or other. This method allows you to identify and eliminate potential vulnerabilities from an internal level (malicious attacks or unintentional mistakes from users inside your cloud infrastructure). 
  • White Box method refers to the procedure where the pen testers have full access (a.k.a admin or root access) to the cloud systems they’re testing. This method allows you to identify and eliminate potential vulnerabilities from a higher hierarchy or management level (malicious attacks or unintentional mistakes from admins/managers inside your cloud infrastructure). 

We recommend performing this procedure regularly to ensure your infrastructure is safeguarded against cloud security risks (and your customers are happy).

3. HTTPS

Migrating a desktop SaaS application to the cloud leads to a common issue arising: your customers might be subjected to vulnerabilities related to non-secure HTTP protocols. These protocols pose a substantial threat because user data (like passwords, sensitive keys, monetary transactions data, etc.) flow in plain text and aren’t protected by HTTPS encryption. 

To prevent man-in-the-middle attacks, keyloggers, or packet sniffer tools from collecting and exploiting this data, make sure HTTPs are enforced throughout the entire infrastructure, your TLS certificates are valid, and no requests can go through non-secure protocols. 

4. Regular audits and training

Let’s face it: the common factor between a cybersecurity expert and a regular collaborator is the fact that they're both human and human error is real.  

One of the most important best practices you need to keep at the heart of your SaaS modernization project is ensuring the whole team is aware, educated, and trained to ensure the integrity of the application in a cloud-native environment.

From knowing how to create a strong password and recognizing a malicious email all the way to the most complex security measures implementation, everyone involved in cloud security operations should play an integral part in mitigating cloud security threats. 

These practices are just the kind of thought and effort that goes into making a web API secure.  Ankush Thaak over at Geekflare, has written an excellent blog post on securing API endpoints. He also recommends a series of tools to use to secure APIs, including web application security products that incorporate web application firewalls, distributed denial of service protection and protection against man-in-the-middle attacks, network scanners, and API test harnesses. Identity management products and runtime security monitoring tools. 

How do we mitigate the cloud deployment security risks?

Migrating your SaaS application to the cloud is risky, but it does offer you a real potential for growth and competitive advantage. We at Mertech always put security at the heart of our migration process, and we can summarize the main tips from our experience as follows:

  • Continuous Monitoring – ABC: Always Be Checking. Adopt ID monitoring and system monitoring to look for anomalies. 
  • Minimize Access – Limit access to critical resources with minimal rights 
  • CI/CD – Manual deployments are more likely to result in misconfigurations and mistakes that result in unintended access or leaked credentials. 
  • MFA - Whenever possible, use Multifactor Authentication to add an additional layer of assurance. 

Do you need help with securing your cloud migrating process? We're here to help! 

Schedule a Free Consultation

Why Migrate from Btrieve to PostgreSQL and other Relational Databases?

Why Migrate from Btrieve to PostgreSQL and other Relational Databases?

Introduction Many independent software vendors (ISV) and corporate users still rely on applications that use a category of database collective called...

Read More
Four Challenges in Converting COBOL Applications from ISAM Databases to Relational Databases

Four Challenges in Converting COBOL Applications from ISAM Databases to Relational Databases

COBOL applications are the foundation of numerous essential business functions, especially within the banking, insurance, and government sectors....

Read More
Application Modernization 101: Ultimate Guide to Digital Transformation

Application Modernization 101: Ultimate Guide to Digital Transformation

Imagine breaking free from the constraints of old, monolithic systems and embracing the agility and innovation of cloud-based solutions.

Read More