After a brief gap, as I continue this series, let us look at application security and how it is different in cloud environment. Applications, which is an important component of elements of cloud which I love to call cloud-triad – data, applications and users.
But before that, let us list down our 10 steps to cloud security as defined by Cloud Standards Council:
Ensure effective governance, risk and compliance processes exist
Audit operational and business processes
Manage people, roles and identities
Ensure proper protection of data and information
Enforce privacy policies
Assess the security provisions for cloud applications
Ensure cloud networks and connections are secure
Evaluate security controls on physical infrastructure and facilities
Manage security terms in the cloud service agreement
Understand the security requirements of the exit process
Today, we will look at assessing the security provisions of cloud applications.
Let us begin by looking at two ways you can have applications in the cloud. Firstly, you can migrate your existing applications to the cloud and secondly, you can build applications on the cloud platform, typically, in a PaaS (Platform-as-a-Service) offering. We will also look at how you can build in security during migration or development of the software.
Application Migration to Cloud
For migration, you should always start with auditing your existing application list as it is not always possible to forklift every application and put in the cloud. After Audit, you can typically categorise applications into six categories, also known, as 6 R’s as follows:
Re-host - Easiest and represent apps that can be forklift and move to the cloud. Minimal efforts required.
Re-platform - Apps that can be moved to a better solution in the cloud. Typically, it means replacing your old software with a SaaS solution.
Re-factor - Significant changes are required in this type of apps before they can be tailored to cloud.
Re-use - Apps that can be decomposed and its parts or services can be used in proposed cloud solution.
Retain - Apps that cannot be moved to cloud and retained by the enterprise.
Retire - Apps that can be retired and new cloud-native application can be built.
Building Applications for Cloud
Generally, a software development lifecycle has 4 phases – Define, Design Develop and Test. But when we look at ‘Cloud Secure Software Development Lifecycle’ (SDLC) there are more phases which are as follows:
Define: In this phase, we identify the business needs of the application, for eg, CRM. Make sure you do not choose any specific tool or technology at this point of time.
Design:In this phase, decisions are made like what interface will look like, decision to develop API and also programming languages to be used.
Develop: This is the phase where actual code is written. Make sure that the coding is done according to defined and designed parameters. Some testing is done at this stage to make sure codes are working as per design.
Test: In this phase, activities like vulnerability assessment and penetration testing takes place. Number of static and dynamic testing techniques are also used that we will discuss later.
Secure Operations phase: Applications enter this phase after thorough testing is done and application and its environment is deemed to be secure
Disposal: As the name suggest, this is where application is disposed of because of End of Life (EOL) or if it is replaced by another application. This is a very important phase which is often overlooked. EOL applications pose greatest threats because they are not properly patched and may contain vulnerabilities.
Now, before we discuss different application security testing methods or techniques, I would like to discuss about a little less known ISO standard which is 27034-1. It provides a set of standards and guidelines for secure application development. A few of the key elements include Organizational normative framework (ONF), the application normative framework (ANF) and the application security management process (ASMP). Please refer to the standard for more details.
Open Web Application Security Project (OWASP) guidelines should also be considered when doing secure engineering of applications.
Now, let us look at various security tools/techniques applied at various stages of SDLC for secure development.
Threat Modelling: It is performed once the application design phase is completed and the goal is to determine any weakness and potential ingress, egress, and actors involved before the weakness is introduced to the production environment. You must be aware of STRIDE model by Microsoft.
Code Reviews: This is a very important process and what I have found in audits, it is often neglected. Clients will have the process but will not be doing it. At least, peer-to-peer code reviews is recommended.
Static Application Security Testing (SAST): It is generally a white-box test, where the application test performs an analysis of application source code, byte code, and binaries without executing the application code. The main purpose is to determine the coding errors and omissions that may indicate security vulnerabilities. It can detect XSS errors, SQL injection, buffer overflows, unhandled error conditions and potential backdoors.
Dynamic Application Security Testing (DAST): This is generally black-box test. It is used agains the applications in their running state. It is very effective when testing exposed HTTP and HTML interfaces of web application.
Vulnerability Assessment / Penetration Testing: And there is of course VA / PT and we know all about it.
Till now, we understand how to build in security when doing application development or migrating applications to cloud. Now lets us look at some of the best security practices during the secure operations phase or when the application is residing in cloud.
First and foremost, is to understand the shared responsibility model (I keep coming to this point in every article). As the service model will change, so will be the responsibility of application security. In IaaS, it will be completely customer responsibility for application whereas in PaaS it will be shared responsibility and in SaaS it will be cloud service provider’s responsibility. But in SaaS model, customer should enforce security of applications on CSP through SLAs and contracts.
Secondly, Dev-Ops culture should be incorporated in cloud environment where development and operations teams come together in engineering and maintaining Secure cloud infrastructure, platform and applications. A new approach, Dev-Sec-Ops is also getting adopted wherein security is also incorporated along with continuous development and delivery of the applications.
In conclusion, applications residing in cloud could pose a serious threat to organization. Therefore, as they say, security should be baked-in and not an afterthought.