If you talk to any developer around about the toughest part of the SDLC, I will be surprised if you don't hear about the hurdles of passing the Security Checklist put up by the Security Architect. In the traditional enterprise world, we have been discussing several layers of security and have several test tools around to mitigate threats. So while the term “cloud-native” is now one of the main topics of discussion in the developer community, “cloud-native apps security” is also taking its own place.

Let's first discuss what changes Cloud Native has brought in terms of security implementation compared to traditional enterprise security.

Cloud-Native Security

Traditional Security

DevOps

This brings speed for applying new security patches for the operating systems or the applications.

Most organizations use manual patching, validate in test environments, and push to production. The whole cycle would require months for a patch.

Advanced Persistent Threats

Frequent changes/updates to the system and environment eliminate the chance for malware to sit undetected for a long time and then start damaging.

Due to infrequent changes, it becomes vulnerable and malware can survive for a long time while doing damage.

Patching with immutable containers

All the patches are applied as soon as they are ready, with a complete redeploy carried out using DevOps practices.

This traditionally applies patches one by one due to internal testing, dependencies on other systems, etc..

Proactive vs Reactive

This promotes a more proactive approach.

This still follows the reactive approach of finding a vulnerability and then fixing it.

So the biggest misconception in the developer community (especially those who are new to the cloud) is that once we move to the cloud, all those security compliance headaches are now the cloud provider's problem; but that is not the case. System security is a shared responsibility between application developers and cloud providers. Providers need to ensure they provide a platform that secures the infrastructure underneath and enables the developer to configure/customize the rules of application security as per their organization's needs.

The Security Features That a Cloud Platform Provides

Immutable Containers - Most cloud platforms provide immutable containers to run your applications. That means the application and the data are isolated, i.e. they cannot be changed from the outside.

RBAC (Role Based Access Control) - Cloud platforms provide access to their platforms based on user roles and they control authorization with some kind of UAA server.

Isolation Segments - most cloud platforms provide options for a segmented environment to isolate systems and resources. These are mostly required for PCI compliance or for financial apps which are data sensitive.

Frequent Patches - Cloud platforms enable automated deployment of new patches. This helps to fix vulnerability issues at the infrastructure level very fast. Also, this doesn't allow the malware to sit there and do damage.

Security Groups - Security groups are like virtual firewalls to secure inbound and outbound traffic to instances. This has become a core functionality for any cloud platform.

Logging and Monitoring - All platforms provide built-in logging and monitoring tools to see what’s happening in the environment and application. They also provide metrics and alerting features as well.

Rotating Credentials - Some platforms are now coming up with a new feature where credentials and keys can be rotated frequently without impacting the actual application changes or downtime.

There's a lot more detail we could go into, but the above features are the most common features you will come across. But the security of any system doesn't stop with these features only. As discussed earlier, it has to be taken care of at the application layer as well.

What Are the Responsibilities of Application Developers'?

Authentication - Authentication is sometimes confused with authorization. Authentication identifies that a user is who they claims to be and authorization defines whether a user is allowed to do something. The application has to be configured to check if an authenticated user is trying to access it. There are many options available to authenticate a user. Some of them are:

User Name and Password - These can be stored either in LDAP or DB and can be validated against user inputs.

Token-based credentials - This is much safer than User Name and Password.

Login with an existing account like Twitter, Google, Facebook, etc. using SSO.

Fingerprints, bio-metrics.

Two-factor authentication- where the first factor is a username/password and the second factor is either an OTP or secret pin.

Authorization - Authorization gives permission to the user to perform a specific action against a particular resource. The following are different ways to perform authorization:

Role-Based Access Control – This is the simplest access control protocol, where resources are allocated based on the user's role, e.g. Admin, Manager, Reviewer, etc.

Attribute-Based Access Control – It defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together. The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.)

OAuth 2.0 - The HTTP-based OAuth 2.0 framework allows an app to obtain access to a resource exposed by your API. The application does send the request to the OAuth 2.0 authorization server, checking each incoming call for an access token. It then validates the call with the authorization server. The response from the authorization server will indicate whether the access token is valid. Also, it will define the scope of access provided by that token.

The Security Assertion Markup Language (SAML) - A SAML Assertion can be issued by an Identity Provider in one security context and be inherently understandable by an Identity Provider in another context. SAML assertions typically convey information about the User including the organizational groups to which the user belongs, together with the expiry period of the assertion. The identity provider which has to validate the assertion must have a trust relationship with the issuing identity provider.

Session Management - Sessions are generally created by setting a session id inside a cookie. The session id is sent by a user’s browser in subsequent requests. The security of these identifiers depends on them being unpredictable, unique, and confidential. If an attacker can obtain a session identifier by guessing it or observing it, they can use it to hijack a user’s session.

Input Data Validation - Data entered by the user through a form or web service call (JSON, XML) must be validated to ensure that they meet the application requirements. Missing that can cause attackers to take control of your application, e.g. passing JavaScript with HTML can get an application's cookies information, passing a DB query can delete system data, etc.

Denial of Service - DoS attacks typically flood servers, systems or networks with traffic in order to overwhelm the victim's resources and make it difficult or impossible for legitimate users to use said resources.

Handle Cross-Site Scripting (XSS) – These attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. To prevent this, several techniques have to be combined, e.g. data validation, content security policy, etc.

Handle SQL Injection - ASQL injection is a code injection technique that might destroy your database. SQL injection usually occurs when you ask a user for input, like their username/user id, and instead of a name/id, the user gives you a SQL statement that you will unknowingly run on your database. SQL parameter binding is one of the known ways of mitigating this risk.

Encryption in Transit - Allow only inbound and outbound SSL connections for the application. Some clients even prefer to have MASSL setup to secure their applications.

Handle User Passwords – That is one of the common issues, and, indeed, password leaks can be a big issue. Application credentials need to have an expiry date and keep changing frequently. Now, even some cloud platforms help to rotate passwords without changing the application code.

Common Misconceptions About Application Security

We Use a Web Framework, So We Do Not Need to Worry About Security. It will take care every aspect of security.

This is not true.

Our application is accessible via VPN only so why worry about security?

What if an attacker uses social engineering and gains access to your VPN and hacks application?

We have backups for our websites so we don't need to worry about hacking.

Backing up your system can be helpful, but, during an attack, whatever damage happens can be significant.

We don’t collect sensitive data, so why bother?

There are many other kinds of damage hackers can do other than stealing sensitive data, e.g. Denial of Service, sending spams to all users, etc.

There is no ROI with security audits.

Security is like insurance for an application; so it doesn't have direct ROI but you'll never regret having it (especially if you're ever hacked).

The website Runs on SSL (HTTPS) so it's secured.

This protocol can only encrypt data that is in transit but it cannot secure your site from other vulnerabilities.