by Phil Martin
If possible, sensitive and private data should never be stored in a public, community or hybrid cloud, and if they are, each data element must be encrypted. This encryption will require additional storage space and key management. Because the encrypted data is stored in the cloud where it is more vulnerable, both the algorithm and associated key must be easily changed when needed. This is called cryptographic agility.
Since our data lives on shared resources owned by the service provider, it is very likely that the resource will at some point be recycled and given to another tenant for use. Data remanence becomes a real issue at this point, because the only access we as a tenant will have to permanently erase this data is to use overwriting. SLAs can go a long way in forcing the service provider to take further steps to properly dispose of data to prevent disclosure.
Unauthorized Access
After confidentiality, the next important aspect of security to address when living in a public cloud is that of unauthorized access. The fact that we share resources with other tenants means that a breach in their system could very well spill over into ours. That is why data privacy and data separation become crucial. The service provider must be able to demonstrate that the Brewer & Nash conflict-of-interest (the Chinese Wall) model has been implemented. In other words, the service provider should be able to demonstrate that data from one tenant is not accessible by other tenants.
Access control lists and system hardening can help to mitigate unauthorized access risks. Keep in mind that if SSO is not implemented correctly, it can result in broken authentication and unauthorized access.
Man-in-the-Middle and Traffic Hijacking
Because it is easier for an attacker to insert himself in between a private intranet and a publicly-accessible cloud provider, man-in-the-middle attacks become a greater threat. Obviously TLS and IPSec should be employed to prevent sniffing, but the proper level of password management must also be implemented.
Insecure and Proprietary API’s
To protect against scanning and enumeration attacks, services must implement a robust authentication and authorization scheme. Some organizations expose unsecured services to support monitoring and auditing reporting capabilities, which represents serious information leakage and must be secured. As various services differ in the minimum authorization needed, it is possible that dependency chaining could result. This occurs when less-trusted APIs call APIs with higher privilege levels, resulting in users with lower access executing code that would normally require elevated levels of access if invoked directly.
While not directly related to security, it is important not to choose a service provider that requires the use of a custom, non-standard API, as this could lead you to be locked in to the vendor due the cost of uncoupling your own solution from theirs.
Service Interruptions
Core to information security is availability, which can be negatively affected by the move to a public cloud. Now, cloud providers such as Amazon’s AWS are famous for their huge redundancy capabilities, but we need to keep in mind that thousands of other companies will be sharing the same resources. That means that if someone decides to launch a DDoS attack against one tenant, all tenants could end up suffering. This also represents a single point of failure which must be considered. Since most cloud platforms are based on a pay-per-use model, downtime will not always result in compensation for the tenants affected, and an organization is still liable for providing services to its own customers. SLAs must be examined closely to determine what levels of service are being provided.
Malicious Personnel (Insiders)
Anytime a person feels they can carry out actions without being known or held accountable, they will almost always choose to see what they can get away with. Just witness the rising incident of road rage – people feel insulated from other drivers around them and perceive a sense of anonymity. As a result, drivers often carry out actions they would never consider if they knew they would be held accountable. Moving functionality to the cloud has the same effect, where employees feel they have a level of anonymity afforded because the application is not being hosted by their own company. It is therefore even more important for a cloud-based application to have sufficient audit trails enabled.
Additionally, people who work for the service provider now have potentially unlimited access to our data. Since cloud service providers often use third-parties themselves, a company should perform deep checks on the reputation of service providers as well as the employees who will have privileged access. Of course, this approach really is not feasible for the most part, and instead the evidence of assurance from a third party should be requested from the provider. The Statement on Standards for Attestation Engagements No. 16, or AES 16, is commonly used for this purpose. The Cloud Controls Matrix, or CCM, is a great tool that cloud service providers should use to guide their control implementation. It also happens to be a great tool for organizations to use as criteria when evaluating potential service providers.
Cloud Abuse
Because cloud computing resources are by definition infinitely scalable, that capability can be used for evil as well as its intended use, an activity that is called cloud abuse. For example, a
malicious actor could launch a DDoS attack from multiple virtual machines, use the site to propagate malware, and even share pirated software. By leveraging the distributed nature of many hosts, an attacker could even use the computing power to brute force crack an encrypted package. Before moving to the cloud, an organization should establish use cases for their architecture so that misuse cases can be identified such as cloud abuse.
Cloud bursting is a term used when an organization must leave the relative safety of a private cloud to leverage the capabilities of a public cloud due to spikes in demands and workload. In short, cloud bursting leads to hybrid clouds where a capability spans both the private and public cloud. This provides an inherent security challenge in which public IP and MAC addresses are linked to the private network, resulting in the ability to spoof both types of addresses. The communication path between the private and public clouds must be secured and protected. Hardening and sandboxing of the infrastructure is required to lessen the ability for platform and hypervisor exploits to be carried out.
Insufficient Due Diligence / Unknown Risk Profile
When faced with the immediate ability to save on costs, it is tempting for an organization to immediately jump on the cloud bandwagon. However, this can be a costly mistake. A proper level of due diligence must be carried out to understand contractual terms, most importantly those dealing with liability and how the contract terms will be enforced. Never sign a contract with a service provider that is a black box. If the provider is not willing to be transparent with their internal working processes, don’t walk away – run! On the flip side, the organization must also understand how the provider will ensure that tenants do not violate their own requirements.
Rich Internet Applications
Going back to the early 2000’s, the term ‘Web 2.0’ came to mean rich Internet-based web applications. Over time that concept became reality, but the web community continually vacillates between ‘make the user experience richer’ and ‘keep it simple, dude’. A rich Internet application, or RIA, is a browser-based app that conveys the same level of interaction and usability that a full-fledged desktop application can provide. Originally, this was built on top of technologies such as AJAX, Adobe Flash/Flex/AIR, Microsoft Silverlight and JavaFX. However, the industry has moved away from proprietary technologies and settled around HTML 5, which has been purposefully designed to deliver a RIA without requiring extensions or external modules. By using a combination of CSS, JavaScript and HTML5, an astonishing array of rich features are suddenly available. A series of modern frameworks have been developed to take advantage of this powerful combination while providing cross-browser support, such as Bootstrap, Materialize, AngularJS, React, Material UI, plus many more.
From a security perspective, RIA intro
duces two common issues that need to be addressed – same origin policy and sandboxing.
Same origin policy, or SOP, deals with a single page requesting resources from more than one ‘origin’, or web server. The origin of a page consists of the protocol, host name and port number. For example, ‘https://www.mydomain.com’ is a different origin than ‘https://www.mydomain.com:1002’, because port 80 is the default. However, the following two URLs use the same origin:
‘https://www.mydomain.com:80’
‘https://www.mydomain.com’
Almost all modern browsers implement SOP natively, meaning that they do not allow a single web page to pull in resources from more than one origin. However, it is possible to override this security feature by enabling cross-origin resource sharing, or CORS, on the server. While many sites purposefully allow this, it is something that should only be enabled if explicitly needed, and only for the origins in question.
The second security issue is sandboxing, a feature in which the browser contains an RIA inside of an area from which it cannot escape. For example, a web application is prevented from accessing files on the client computer except for cookies. The sandbox enforces these security restrictions but can be overridden at times through the browser settings. Occasionally, an exploit will be discovered allowing a web app to escape the sandbox. As a result, a good application should never trust what the browser says – always perform validation on the server. It’s OK to perform the same validation in the browser, but never trust it alone.
Mobile Applications
As mobile devices become increasingly prevalent, so do the attacks. We tend to feel more comfortable in taking chances with a smart phone since we believe it has less of a chance of becoming infected. After all, Apple and Google are watching out for malicious apps on my behalf, so what is the problem? Even behemoths such as the app store owners can’t keep up with the bad guys, and there will always be malware that slips through. Before we can protect ourselves from such apps, we need to understand the design, development and deployment of insecure mobile applications.
Architecture
We have already touched on rich Internet applications, or RIAs – web apps that live in a browser and offer functionality similar to desktop programs. Mobile apps are all considered to be ‘rich’ as well but run directly on top of an OS instead of in a browser. Mobile apps have three components – the user interface, middleware the app communicates with, and some type of backend, usually containing a database of some kind. Thin mobile apps depend on a remote middleware living on a server, with all business logic and data layer access contained on backend support. Thick mobile apps have all three tiers living on the mobile device itself. At times a thick mobile app will also communicate to a remote server but does not need to maintain that connection to be fully operational.
To dive in slightly deeper, mobile app architectures usually have the following components:
Client hardware, such as a cellular chip, GPS, sensors, a touch screen, camera, etc.
Client software such as the OS, virtual runtimes, and the mobile app
Interfaces to the various capabilities such as NFC, RDIF, 802.11x, and Bluetooth
Endpoints living on a remote server, such as the app store or web services
Carrier networks such as voice, data, and SMS
Data storage such as local, cloud, flash, and removable
Data transmission over the carrier network
Types of Mobile Apps
There are four different types of mobile apps commonly used these days – native, browser-based, rich and hybrid.
A native mobile app is installed on the device itself by deploying the code base. They generally require little backend support from a remote server.
A browser-based app is simply a web application that runs in a browser already installed on the device. A responsive web design is crucial to the usability of such apps, in which the web page dynamically rearranges itself to fit the size of the device screen.
A rich Internet mobile app is deployed to a device just like a native app, but without the ability to communicate to a remote server, this app has limited to no capabilities. The backend support is normally accessed using SOAP or REST – usually REST these days.
A hybrid app is also deployed to a device, but primarily consists of an embedded browser that loads a locally-stored web app. The browser sandbox is usually relaxed a little in these applications such that they can often reach features on the device a normal web app will not have access to.
Mobile Operating Systems
The Mobile OS performs the same function on a mobile device as the OS does on a desktop. All applications run on top of the OS, and the OS provides the abstraction layer between mobile apps and hardware. Some mobile OSs are open source, such as Android, but most are proprietary.
Let’s discuss some popularity stats for a second that are applicable as of October 2018. While Windows without a doubt rules the desktop – 90% of all desktops run some variant of Windows, the mobile device market is quite different. Here, Android rules with a 75% market share, with iOS following a distant second at 20%. Now, when we say ‘mobile device’, it is best described as devices that are easiest to use when held in the hand. Touch-screen laptops that fold into a screen-only device are usually not included. It is interesting to note that 50% of all devices world-wide are smart phones, 40% are desktop and only 10% represent tablets. The OS market share changes depending on smart phones vs. tablets. iOS rules tablets with a 65% market share, while Android runs the majority of smart phones at around the same number – 65%.
Why spend so much time discussing market share? Well, besides being just interesting, mobile OSs behave differently and you should know the majority of operating systems you will be dealing with specific to the makeup of your own organization. For example, if you have a BYOD policy and most employees use a tablet, then iOS will represent the majority of vulnerabilities. If smart phones are used instead, then Android will be where you should focus your attention. Desktops and laptops will obviously be Windows.
As an example, iOS has a feature known as backgrounding in which the OS takes a snapshot image of a running app. This is used to show the app when switching or viewing a visual list of all running apps. However, if the snapshot just happens to include some sensitive data that was showing on the screen at the time it was taken, it could be taken as a breach of PHI regulations.
Security in Mobile Applications
The primary threats faced by a mobile app will be directly related to the type of architecture the mobile app is built on. For example, a rich Internet application will face the same threats as any other web-based app, while a native app which seldom, if ever, communicates to a remote server will not have to worry about network traffic sniffing.
Mobile app threats will mostly come from malicious humans or programs, intent on stealing something or causing harm. Malicious programs range from malware that is installed on a device to scripts loaded from a web server that run in a browser. Malicious programs could also impact communications protocols such as SMS. Of course, there will always be non-malicious threats from humans, although these are not nearly as prevalent as on desktops. Examples might include uninformed users who inadvertently install malware as well as owners who lose their device.
In general, threats to a mobile app will be one of the following:
Information disclosure
Mobile DoS or DDoS attack
Broken authentication
Bypassing authorization
Improper session management
Client-side injection
Jailbreaking and Sideloading
Mobile malware
We’re going to discuss each, along with possible countermeasures.
Information Disclosure
Information can be disclosed or stolen through one of six primary vectors.
First, we have the obvious scenario of lost or stolen devices. Given mobile devices are…well…mobile, th
eft becomes that much easier, especially since this usually happens in public places where it is easy to forget a device and leave. Until we can figure out how to permanently tether a mobile device to a person, the only countermeasure is the ability to remotely wipe the data from the device.
Next, the insecure data storage in local or cloud database represents a significant threat. When a device is stolen, so is the data on the device. Mobile databases are not as mature as their server-based counterparts, and therefore security is not really that great. That is why a remote wipe is so important. However, data stored in the cloud also falls under this threat, as data remanence can be a problem when resources are re-provisioned for other organizations. Additionally, cloud-based databases can be relatively unsecure due to a lack of data separation. When carrying out data classification, be sure to take into account data stored on mobile devices.
Insufficient protection of data transmission can lead to an attacker sniffing passing packets. Always encrypt data in-transit between networks and even between devices if they form an ad-hoc network.
Broken cryptography is most often encountered when custom algorithms are used, or keys are hardcoded into mobile apps. Always use encryption capabilities built into the mobile OS. When encryption APIs are tied into security based on a simple PIN, it may be wise to use a third-party API instead. But never roll your own. When dealing with key management, use secure containers instead of hardcoding the key. In case you have forgotten, a secure container is an area on a mobile device that is encrypted and only accessible by a mobile app.