Welcome to the fifth blog in the series on Cloud computing. This edition will look at the security implications raised by the Application level of infrastructure security in the Cloud. Following a brief overview of generic security issues at this level each cloud deployment model (SaaS, PaaS and IaaS) will be discussed and their specific security issues highlighted.
This article is not suggesting that the security issues mentioned should be seen as the only security concerns with Application level security.
Neither is it intended as a technical description of cloud security countermeasures.
Infrastructure Security in the Cloud: Application Level
The application level of the Cloud computing infrastructure model has a spectrum that ranges from standalone single-user applications to sophisticated multiuser e-commerce applications used by millions of users across the globe.
The speed that Cross-Site Scripting (XSS) and other attacks have developed is a testimony to the fact that criminals looking for financial gain can exploit vulnerabilities from web programming errors as new and ever more sophisticated ways to penetrate organisations are being utilised.
Hackers armed with knowledge and tools are continually scanning web applications (accessible from the Internet) for application vulnerabilities.
All web applications built and deployed in a public cloud platform will be subjected to a high threat level, attacked, and potentially exploited by hackers to support fraudulent and illegal activities.
Web applications deployed in a public cloud environment (the SPI model) must be designed along the Internet threat model, and security must be embedded into the Software Development Life Cycle (SDLC).
Application level DoS and DDoS attacks can potentially disrupt cloud services for an extended time.
These attacks typically originate from compromised computer systems attached to the Internet (routinely, hackers hijack and control computers infected by way of viruses/worms/malware and, in some cases, powerful unprotected servers). Application-level DoS attacks could manifest themselves as high-volume web page reloads.
These malicious requests blend with the legitimate traffic, making it extremely difficult to selectively filter the malicious traffic without impacting the service as a whole.
SaaS Application Security
The Cloud Service Provider (CSP) manages the entire suite of applications delivered to users (customers). Hence, SaaS providers are primarily responsible for the security of the applications and components they are offering to their customers.
Customers are usually responsible for day-to-day operational security functions such as user access management. This may be supported by the CSP via a portal within the application suite.
An organisation considering using a SaaS solution, especially one hosted on a public cloud, should request the following information from the CSP:
- The design, architecture and development of the application
- Black-box application testing
- White-box application testing
Some larger organisations will have the security of the SaaS application independently scrutinised via an external security analyst. This may involve penetration testing, with the CSP’s consent, to gain independent assurance that the security measures provided by the CSP are adequate and at least match the risk appetite of the customer.
It is important for customers of SaaS to pay extra attention to the authorisation and access control features offered by the CSP.
Concerning the above points, customers of this Cloud solution should try to understand cloud-specific access control mechanisms and deploy strong authentication and privilege management. This should be based on user roles and functions, although not exclusively related to Cloud computing the principle of implementing the least amount of privilege required for an employee to perform the tasks necessary for their job function should be born in mind.
Segregation of duties also helps protect against insider threats.
Two other levels of mitigation customers should consider they are the strict management of access to privileged areas such as the SaaS administration tool and the implementation of a strong password policy.
PaaS Application Security
Whether the customer is deploying a private or a public cloud PaaS provides an integrated environment for the design, development, testing, deployment and support of custom built applications. These applications must be developed in a language that the platform supports.
There are two dimensions to security in PaaS:
- The security of the platform itself (The runtime engine)
- The security of customer applications deployed on a PaaS platform
Security of the PaaS platform
The PaaS platform provider (i.e. Google, Microsoft) is responsible for the security of the platform software stack, the runtime engine and customer applications, generally. Potential customers should be aware that this is not always the case, and assurances should be sought.
PaaS can utilise third-party applications, components or even web services. The third-party may well be responsible for provisioning their security measures.
Customers of the PaaS platform should understand the dependency of their application on all services and assess the risk about third-party service providers.
Enterprise level customers should demand and receive information from the CSP to perform initial security risk assessments in a fair and transparent manner.
This transparency should be continuous to allow ongoing security monitoring and management.
The CSP remains responsible for monitoring new bugs and vulnerabilities that could be used to exploit the PaaS platform and breakout of the architecture, network and host security.
The monitoring of a shared network and the relevant system infrastructure hosting customer applications remains the responsibility of the PaaS provider.
Therefore, it is of paramount importance that customers understand how the CSPs are managing their platform, including updates of the runtime engine and change, release and patch management.
Security of Customer Deployed Application in PaaS
Developers are required to be familiar with specific APIs to deploy and manage software modules that enforce security controls. Software developers are required to become familiar with platform-specific security features that are available such as, security objects, web services for the configuration of authentication and authorisation controls within the application.
One of the challenges developers currently face is the lack of a standard for PaaS API design. Furthermore, there is no concerted effort by CSPs to develop consent and consistency for API across clouds. This leads to the following issues for cloud customers:
- Porting of applications across PaaS clouds becomes an expensive and time-consuming
- CSP has the potential to retain customers due to the above more so than when a traditional software licence is in place.
The lack of an API standard creates problems for security management and application portability across the cloud. Developers should expect CSPs to offer a universal set of security features for user authentication, SSO with Federation and privilege management via authorisation as well as Secure Sockets Layer (SSL) or Transport Layer Security (TLS) SSL and TLS. This should all be available in every API.
At present security features are limited to basic security configurations such as SSL, necessary privilege management, user authentication using the CSPs identification store.
IaaS Application Security
CSPs treat applications on customers virtual instances as a black-box and completely agnostic to the operations management of the customer’s applications.
The entire stack of customer applications, runtime application platform (Java, .NET, PHP, Ruby on Rails, etc.) run on the customer’s virtual servers. These virtual servers are deployed and managed by the CSP’s customers.
On an IaaS deployment, the customer retains full responsibility for the security of their applications deployed in the Cloud. The CSP will not provide any assistance with security beyond basic guidelines and features relating to firewall policy.
Customers in an IaaS public cloud deployment must ensure applications are designed for an Internet threat model, embedded with standard security counter-measures against common web vulnerabilities.
It is further recommended that the customer periodically tests for new vulnerabilities that should be integrated into the software development life-cycle (SDLC).
Developers writing applications for IaaS clouds must implement their features to deal with authentication and authorisation.
Once again, the customer is solely responsible for keeping applications and the runtime platform patched to protect the system from malware and hackers who scan the internet for vulnerabilities to gain unauthorised access to data in the cloud.
Therefore, customers using IaaS should deploy the ‘least-privilege’ runtime model. The least-privilege model is based on providing users with the minimum access to systems and features they need to do the task they are employed to perform.
The first question raised about application-level security is ‘how does one address such a broad spectrum of security risk? On the one hand, the risks an individual is exposed to require attention, and at the other extreme the risks a global organisation will also be presented to need addressing.
The types of attack vary from XSS to DDoS, the speed and ferocity of the attacks will vary depending on the SPI (SaaS, PaaS or IaaS) as does the responsibility for ensuring security layers are in place.
Where the CSP has responsibility for security, in a SaaS deployment, for example, customers should take all reasonable steps to ensure that the security in place is suitable and robust enough for the integrity of their data.
Regardless of the SPI deployed both the customer and the CSP have a vested interest in ensuring current security measures are adequate based on current threat intelligence.
Cross Site Scripting (XSS)
When malicious code is added (injected) into trusted websites as a browser side script by an attacker to send data (frequently also malicious) to a different end user, it is called Cross-Site Scripting (XSS).
Black-box application testing
Black-box application testing allows testing of applications merely by focusing on the inputs to and outputs from the application being tested. There is no need for the tester(s) to know or understand the internal code or how the app works.
White-box application testing
White-box application testing is the opposite of Black-box application testing as the tester has in-depth knowledge and understanding of the component being tested usually at code or machine level.
The purpose of release management frequently referred to as the ‘release management process, ‘is to ensure new builds (versions) of an application are controlled, tested and deployed to a preplanned schedule. The aim is to provide the integrity of existing services during the deployment of updates or patches.
The runtime engine
The runtime engine provides the typical routines and functions necessary for an application to work (execute). A standard runtime engine will convert the application code, which is usually written using an intermediate language (Java; Python etc.) into a low-level language (machine language or assembly language)
SSO with Federation
Single sign-on (SSO) allows a single authentication credential such as a user ID and password, to access multiple or different systems within an organisation.
When a federated identity system is introduced in conjunction with SSO a user can access multiple systems in different organisations. A widely cited example is apps that allow the user to log in with either their Google or Facebook account details.
SSL and TLS
Cryptographic protocols such as SSL and TLS provide authentication (and encrypt data) between applications, machines and servers over a network. TLS is more modern the SSL and is becoming recognised as the cryptographic standard within the IT sector.