Apps

Applications (we will call them apps from now on) are the entry point for the user to consume data and to transmit, process, or store information onto the system. Apps are evolving rapidly, and the adoption of SaaS-based apps is on the rise. However, there are inherited problems with this amalgamation of apps. Here are two key examples:

• Security: How secure are these apps that are being developed in-house and the ones that you are paying for as a service?
• Company-owned versus personal apps: Users will have their own set of apps on their own devices (BYOD scenario). How do these apps jeopardize the company's security posture, and can they lead to a potential data breach?

If you have a team of developers that are building apps in-house, measures should be taken to ensure that they are using a secure framework throughout the software development lifecycle, such as the Microsoft Security Development Lifecycle (SDL) [10]. If you are going to use a SaaS app, such as Office 365, you need to make sure you read the vendor's security and compliance policy [11]. The intent here is to see if the vendor and the SaaS app are able to meet your company's security and compliance requirements.

Another security challenge facing apps is how the company's data is handled among different apps, the ones used and approved by the company and the ones used by the end user (personal apps).

This problem becomes even more critical with SaaS, where users are consuming many apps that may not be secure. The traditional network security approach to support apps is not designed to protect data in SaaS apps, and worse, they don't give IT the visibility they need to know how employees are using them. This scenario is also called Shadow IT, and according to a survey conducted by Cloud Security Alliance (CSA) [12], only 8 percent of companies know the scope of Shadow IT within their organizations. You can't protect something you don't know you have, and this is a dangerous place to be.

According to Kaspersky Global IT Risk Report 2016 [13], 54 percent of businesses perceive that the main IT security threats are related to inappropriate sharing of data via mobile devices. It is necessary for IT to gain control of the apps and enforce security policies across devices (company-owned and BYOD). One of the key scenarios that you want to mitigate is the one described in the following diagram:

Figure 3: BYOD scenario with corporate app approval isolation

In this scenario, we have the user's personal tablet that has approved applications as well as personal apps. Without a platform that can integrate device management with application management, this company is exposed to a potential data leakage scenario.

In this case, if the user downloads the Excel spreadsheet onto his/her device, then uploads it to a personal Dropbox cloud storage and the spreadsheet contains the company's confidential information, the user has now created a data leak without the company's knowledge or the ability to secure it.

Data

We finished the previous section talking about data. It's always important to ensure that data is protected, regardless of its current state (in transit or at rest). There will be different threats according to the data's state. The following are some examples of potential threats and countermeasures:

State	Description	Threats	Countermeasures	Security triad affected
Data at rest on the user's device.	The data is currently located on the user's device.	The unauthorized or malicious process could read or modify the data.	Data encryption at rest. It could be file-level encryption or disk encryption.	Confidentiality and integrity.
Data in transit.	The data is currently being transferred from one host to another.	A man-in-the- middle attack could read, modify, or hijack the data.	SSL/TLS could be used to encrypt the data in transit.	Confidentiality and integrity.
Data at rest on-premise (server) or in the cloud.	The data is located at rest either on the server's hard drive located on-premise or in the cloud (storage pool).	Unauthorized or malicious processes could read or modify the data.	Data encryption at rest. It could be file-level encryption or disk encryption.	Confidentiality and integrity.

These are only some examples of potential threats and suggested countermeasures. A deeper analysis must be performed to fully understand the data path according to the customer's needs. Each customer will have their own particularities regarding data path, compliance, rules, and regulations. It is critical to understand these requirements even before the project is started.