Authors Bram van Pelt Sander Mastwijk

Transcription

1 AMIS Edisonbaan 15 Postbus AA Nieuwegein T +31(0) E info@amis.nl I amis.nl BTW nummer NL B69 KvK nummer Statutair gevestigd te Enschede Whitepaper: How to reach an optimal Cloud Security Level Additional measures on top of ISO / ISO to ensure the optimal cloud security level. Authors Bram van Pelt Sander Mastwijk Date October 2015

2 2/14

3 1 Abstract With the rise of cloud applications, a new way of looking at security is required. Security is no longer concentrated only within the perimeter of your company. The scope of your security management also needs to include the cloud providers which offer services to you. From a security perspective, this means that you are relying on their security measures to implement your security policy regarding the information you store in the cloud. Potential customers of SAAS products must adopt a more rigorous due diligence process due to regulatory changes, increasing privacy concerns, and risks of fraud and exposure. It is increasingly important to determine how providers implement security and if their level of security matches expectations. And as the SAAS market keeps growing, diversity and complexity of cloud solutions increase. This requires an even more detailed security analysis which goes beyond traditional contractual protection. This requires open communication about security matters, which also benefits providers in aligning services with market demand. This is similar to buying a car. The vendor may have a good reputation, and the features may be well documented. But you are still going to have to trust the customer reviews and have a good look underneath the hood before you trust it with your life. Or at least you want to prevent the embarrassment of showing up late for important meetings. This whitepaper details governance and technical security aspects that you need to address when exploring the possibilities of SAAS applications, and provides input for your risk analysis and service level agreements between you and your cloud provider. Securing your information in the cloud is a joint effort of you and your cloud provider. 3/14

4 Contents 1 Abstract Security Governance Processes and technical security measures Public interfaces Traffic Encryption Encryption type Encryption management Endpoint access Endpoint protection Internal infrastructure Multitenancy Component connections Security monitoring and feedback Uptime and availability Configuration / tripwire files Added services scan Administrative account management Service account security Data Storage Data encryption Backup strategy Data segregation & accessibility Identity and access management Identity management Access management /14

5 2 Security Governance When using cloud applications, you are basically incorporating a black box into your IT landscape. It provides you with specific functionality at a certain price. From a security perspective, you need to know what information is processed and stored in this black box, and what the provided functionality and stored information means to you. What does it mean to you when the information is lost or unavailable? What if its confidentiality or integrity is no longer guaranteed? Risk is determined based on these values. Based on the risks associated with the information you want to store in the cloud application, you define security policies and measures. This is basically the same chain of thought when managing your own applications, except with cloud applications there is a point up to which you can control security measures yourself. This can put you in an awkward situation because your cloud provider manages the black box, but you are still responsible for the information in it. Fortunately, there are ways to deal with this situation. For instance, you can keep a close eye on the cloud provider by asking for daily or weekly reports detailing the security aspects of their operation. These reports will help you to exercise control over the security infrastructure. Besides the reactive nature, the main problem with this method of control is that the cloud provider has to inform you of its own operational security status. This is a direct conflict of interest as it is in the best interest of the provider to reflect a positive image to its customers. Providers may not be able or willing to provide the level of transparency you want because of the risks involved, or simply because of the additional strain on their operations. An auditor might argue that you can never fully trust your provider. At a glance, the more appropriate way of managing security is to require the cloud provider to be audited on a regular basis. In most cases the ISO / ISO or similar security guidelines are used, which tell you something about how the provider manages security in general. Important things, like how their facilities are protected against unwanted physical access and cyber-attacks. Although this is a great way of gaining some assurance about the provider s security controls, they do not take into account how the responsibility for certain security aspects is divided between you and the provider. It also does not directly audit any specific requirements you may have regarding the service in question and the information that is processed. The responsibility for certain security aspects and the level of security can differ between providers, services they offer and individual customers. This makes it difficult for you to make an analysis of risks associated with the usage of a certain cloud service. So in order to gain insight in the risks of using cloud services, you need to ask additional questions to get a clear overview of security measures in place. With that overview you can check if the service meets your requirements and if there are any aspects your provider doesn t take care of. It also provides the input for audits (e.g. ISAE3402) that are more focused on your needs. 5/14

6 3 Processes and technical security measures Once you define the level of security you require for a specific service, you have the basis to which you can compare the measures your cloud provider has implemented. You need to understand the security level of your cloud provider and this is important for you both, because trust drives business. You need to be able to discuss security matters, for example when you want to do your own pen tests. And to make sure the cloud service is an effective part of your landscape in a sustainable way, you need to align views with your provider. Their security level is on their road map, not on yours. So keep your future business plans in mind to avoid having to switch cloud providers. In the next chapters we will go into some technical details. We start with the public interfaces that expose the service and its functionality. It goes without saying that access to these interfaces should be properly protected. Next, we look at the way they structure their service and store your data and make sure enough measures are taken to disrupt an attackers kill chain. And last, we look at the way you can control access to your data. Your provider needs to let you take care of what is your responsibility: making sure authorizations and access to your data are correct. It needs to let you do that. Below is a table of security measures discussed in this document and their strength. These measures can be combined in different ways to add up to a certain level of security. This can help you determine if the combination offered by the cloud provider meets the level you require based on your risk analysis. Security measure strength overview Basic Medium Advanced Public interfaces Traffic encryption Local authentication Firewall Strong traffic encryption Formal encryption management Federated login Reversed proxy Strong traffic encryption Formal encryption management HSM Federated, attribute based login IPS / IDS Internal infrastructure Multitenant Performance monitoring Manual privileged account management Encrypted multitenant Encrypted internal traffic Configuration monitoring Privileged account management process Single tenant Encrypted internal traffic Internal firewalls IDS / IPS PAM solution Data storage Data encryption Offsite backup Data encryption Disk encryption Encrypted offsite backup PAM Data encryption Disk encryption Watermarking Encrypted offsite backup Technical data segregation Identity & Access management Manual identity management Local authentication IDM integration Single sign-on IDM integration Access management integration Context based access control MFA / OTP 6/14

7 4 Public interfaces To interact with a cloud application, you connect with the publicly available application endpoints. When designing or running a cloud application, the cloud provider must manage the security of these publicly available endpoints. In this section an endpoint is defined as a web service which is available to the internet either via an open connection or a connection secured via VPN. Examples of these connections can be REST interfaces, web sites or an open SSH port. The security recommendations in this section should be applied to each endpoint. 4.1 Traffic Encryption Connections to each service which is open to the internet have to be encrypted. The only exception to this rule are static pages of a public website. Any other data is likely to contain personal information, company secrets or other sensitive information and must be encrypted. When adding encryption to an endpoint the following items need to be addressed: Encryption type There are several different ways of adding encryption to an endpoint. The most common is by adding SSL to a TCP connection or placing the endpoint behind a VPN. In case of connection security by adding SSL or other encryption which relies on certificates, it is important to consider that the certificate defines the minimum level of security. It is therefore very important that the certificate is defined correctly. One way of checking if an endpoint is secured correctly is by running it past the qualis guard SSL check tool. This is available on For VPNs the most important aspect is to check the key length of the connection and the filtering of IP addresses that are allowed to connect Encryption management When using encryption to secure an endpoint, it is very important that the cloud provider manages the encryption and the certificates correctly. The most common processes for encryption management usually are key generation, key application, key distribution and key storage. Keys can be a collection of certificates, passwords to use certificates and VPN keys. Common ways of storage include storing the keys in an encrypted container or storing them on a hardware security module (HSM). 4.2 Endpoint access When designing an application endpoint, designers need to keep in mind who is allowed to access an endpoint and how authentication is handled. In order to identify which people are allowed to access an interface, the design should avoid specifying individual accounts: it should specify conditions. Conditions like: an administrative user is defined by a role in an external system, or an external employee is identified by the identity store the user account is stored in. Only when software needs one specific account, and the account cannot be described by a condition, the account can be named specifically. When it is clear who will be able to access an endpoint, the second thing to consider is how users must authenticate. This can either be done by using a password which is stored within the cloud itself or by allowing a third party to authenticate users. By allowing a third party to authenticate users, a cloud provider needs to watch for one thing: trust. The main question is: how much do I trust this authentication provider? For instance if I host a whitepaper in the cloud and I only want to distribute it to people I can contact after they download the whitepaper, Linked-in could be rated as sufficiently trustworthy. On the other hand, if the file is classified as secure, an Identity provider set up by the customer is more appropriate. One of the options is to set up federation with an on premise system like your Active Directory. This way you control the accounts that can be used in the cloud environment more closely, and leverage existing monitoring capabilities to track login activity. There are other concerns as well when using accounts as a security measure. These concerns are addressed later in this document when discussing identity management. 7/14

8 4.3 Endpoint protection Endpoints rely on certain components to run them. It is therefore important to be able to guarantee the security of these components. Common ways to secure components which are available to the internet are to place them behind an application layer firewall, intrusion detection and prevention systems or a behind a reverse proxy. The main objective of these devices is to filter out malicious connections to the endpoints. When thinking of malicious connections to an endpoint, one can think of ddos attacks or attacks which involve sending malicious data to an endpoint like SQL injection and heart bleed. Although some malicious connections can be handled by the endpoint itself, a designer should consider relieving the endpoint (and its development) by using some of the mentioned capabilities, which are designed for that purpose. 8/14

9 5 Internal infrastructure The internal infrastructure of a cloud application affects the overall security significantly. Even if the measures employed are not directly useful against stopping intruders, they pose a significant hurdle for malicious users in the exploitation phase of their attack. This in turn grants the cloud provider time to detect these malicious users and take action. 5.1 Multitenancy For efficiency reasons, cloud providers service customers from one environment (multitenancy). Multiple customers share at least parts of the cloud provider s systems. The first thing to check for is how data from customers is separated. This is called the tenant issue and is usually determined by (cost) efficiency of an application, but it does impact security. If customers have dedicated application instances, the impact of a data breach can be contained quite well. On the other hand, if data leaks from a cloud application, and the application instances are set up for multitenancy, other customers will be affected as well. Providers implement logical boundaries that separate customer data in the virtualization layer, in applications, in webservices and at storage level. How they do it is really up to them, but you do need insight in the risks of their chosen solution to determine if a (costly) single tenant is necessary. The only way you can add security to a multitenant environment yourself is by data encryption that uses a dedicated encryption key for your data. This is due to the fact that the only thing unique for a customer in a multitenant environment is its data. When different keys are used for different customers, a data leak will only reveal encrypted information which cannot be broken in case the keys of one customer are stolen. 5.2 Component connections In most cases, cloud applications are made up of multiple components. For instance the application might be made up of a database and a frontend web server. In order for these components to work together efficiently, they need to be able to communicate. What most cloud providers do however is leave this communication unencrypted. This allows malicious users to intercept and read plain text traffic. To solve this problem, traffic encryption should be used between front and backend servers. Also, if the interaction between components is not modelled correctly, front and backend servers might be able to use covert means of communication. This happens when internal development and operational processes are not properly aligned and it s not clear which ports are used so all are left open. To reduce this risk, a firewall should be placed between front and backend connections that allows all modelled traffic, whilst all non-modelled traffic should be used as a high priority security trigger. This causes strain on the providers operations and it s definitely something to talk about. 5.3 Security monitoring and feedback One of the most important components in a secure cloud environment is a solid security monitoring process. Security monitoring is usually a component which is not designed when setting up a cloud service. Usually, it is a component which is added at runtime by system administrators. In most cases you need to rely on system administrators to acknowledge the need for a monitoring system and their skill in setting it up correctly. When implemented properly, a monitoring system is divided in at least three components: Uptime and availability Uptime and availability monitoring systems are systems which check the status of components in the cloud service. They should at least check for the availability of endpoints and the response times of internal components Configuration / tripwire files The second monitoring task is the reporting of configuration changes. Your provider should have a process in place to detect these changes because anything that s not explained by incident or change handling processes indicates malicious activity. Tracking configuration changes can be achieved by storing hash values of 9/14

10 configuration files. The great advantage is that if any system or person changes these files, the system administrators will immediately be notified. A good example of one of these files is the UNIX password file or the static files of a webserver Added services scan The added services scan is a process which continually checks the cloud environment for new TCP/UDP services. A change to these services might indicate exfiltration of data by a malicious user. This scan usually gives a good insight in the securable endpoints of an internal cloud environment. 5.4 Administrative account management One of the most overlooked challenges in cloud management is being in control of administrative accounts and privileged access. In most cases system administrator accounts are managed manually as they would in a small company. To keep the usage of administrative accounts in check, the cloud provider needs to model the administration of its system and have processes for administrative access in place. An administrative model of the system should include a list of common administrative actions and the level of clearance a user needs to execute those actions. Also, the model should describe how users gain access to an administrative account and how to release an administrative account. Based on this information the correct administrative accounts can be created and managed. This management can be done by hand, but is preferably done automatically. A privileged access management (PAM) solution automatically manages privileged accounts and their passwords and provides audit information about their use. To complement this management, the monitoring system should include a tripwire for accounts that were not created by this process. 5.5 Service account security Service accounts are accounts that software services require to identify themselves. These accounts in general have more rights than normal user accounts and their use can t be traced to individuals. It is therefore imperative that procedures are defined to manage these accounts correctly. These procedures must include at least how to create a service account and how to reset the password of a service account. If both procedures are defined correctly, the password of a service account can be set up in the application once (encrypted of course) and does not need to be stored anywhere else. This in turn assures that no one can get access to the password and can therefore not abuse it. The password of a service account should preferably be as long as the key with which the database is encrypted. If this is not possible due to restrictions to the maximum length of a password, the password must be exactly that length. The more both processes can be automated, the better. It is also sensible to set a tripwire for every change in password for these accounts. 10/14

11 6 Data Storage Data is your most tangible property and must therefore be treated with great caution. If data leaks from a cloud provider, or if the suggestion is given that it has, it could be disastrous for the cloud provider. To ensure data is safely stored, a cloud provider should be rated on the topics below. 6.1 Data encryption Whenever customer data is stored with a cloud provider, the data has to be encrypted. This is due to two reasons. The first being that the data ownership lies with the customer, therefore the cloud provider should not have access to it. Second, in case of a data leak, the data will be encrypted and therefore not readable to external parties. This measure therefore protects both the cloud provider and the customer. There is another advantage of implementing data encryption. Data encryption can be used as a digital watermark to identify where the data originated. This can be very helpful in scenarios where data has been leaked, but it is not certain from where. A watermark can be created by a customer by controlling the encryption methods for a cloud provider. If the customer can determine which key is used by the cloud provider, leaked data can be identified by decrypting it. If all cloud providers for a customer use a different key, a decryption key can be used to determine where the information leak originated from. Lastly, the hard drive on which the data is stored should be encrypted as well. By encrypting the hard drives as well as the data which resides on it, the likelihood of an information leakage in case of a stolen hard drives becomes very little. Most operating systems support this kind of drive encryption natively. It can therefore be a quick win to enable this kind of encryption. 6.2 Backup strategy The most important thing that has to be considered when creating a secure backup strategy is the content of a backup. Backups come in a lot of shapes and varieties, for instance a backup could include the content of a running application server or a flat file dump of a database. The thing to keep in mind is what kind of information will be available in the backup. If customer data is included in the backup, backups must be encrypted and signed before leaving the system. If the backup contains configuration information the backup should be signed and the size of the backup should be signed before the data is allowed to leave the system: this ensures data integrity and reliability. To verify proper functioning you should periodically request a restore. After the encryption and signing of a backup, the backup should be stored off site on a secure location. The storage and transfer must conform to the security measures which have been named previously. For instance, the data transfer has to be secured using SSL to ensure data cannot be read by another person, and the location where the backup is stored should be encrypted. 6.3 Data segregation & accessibility If a cloud provider decides to set up a multitenant environment, usually the first question that pops to mind is how to keep data separated between customers. As stated before, data is the most tangible thing within a cloud application. Therefore, customers do not wish to see other customer s data, as this can be a good indication that its own data is showing up on unauthorized systems. So usually, this problem gets tackled well. But one important aspect is overlooked: the system administrator. Data is not separated from the cloud provider s system administrators. One of the consequences is that administrators can view, modify and delete customer data, that is why administrative accounts are a primary target for malicious users. So how is your data protected against misuse of these accounts? There are several ways of dealing with the segregation of data. The first is quite simple: you make the administrators sign a non-disclosure agreement and you require administrators to login with a personalized account. Although this cannot actually prevent access, in case of a system mishap a root cause analysis can quickly determine the active user on the system. The cloud provider has to be careful though when choosing this 11/14

12 approach. If administrators log into a system and as a habit elevate to the root account, the actions of an individual admin cannot be monitored properly anymore. A better way of dealing with data segregation is by installing a Privileged Account Management system. A PAM solution takes control of the administrative accounts and their passwords and provides staff with access in a controlled way. As an additional security measure the account can be locked until the administrator has approval from a manager to use the system. Also, this system can keep track of the actions a user undertakes whist using a privileged account. This in turn makes auditing the usage of privileged accounts simple. The last measure that can be taken to secure administrator accounts, is to restrict administrator accounts to only be able to manage databases, while denying them access to data stored in the database. The clear advantage is that administrative accounts can no longer be used to leak data. Ironically, this is also the downside of this system. System administrators will no longer be able to troubleshoot down to the data storage when the system displays incorrect information. This risk can be mitigated by unlocking a system account you control in a privileged account management system. 12/14

13 7 Identity and access management Security management is quite simply a gathering of processes in which you have a prominent role. The section below explains how you can get more control of who can use the cloud application. This involves having the tools needed to manage users, logins and check security audits. As mentioned in the chapter on identity and access in the public interfaces portion of this document, access rights and the way users connect are important to the security of an application. Since you are the only one who knows who can have access to what information, you need a secure way of managing these aspects of a cloud application. Let s break it down into identity management and access management. 7.1 Identity management Identity management in a cloud application usually consists of two parts: a user management portal and an API for user management. The user management portal is in most cases a website which allows customers to manually preform user management actions. Although this can be fine for small enterprises or applications which have a low volume of users or mutations, this is not an ideal situation. If the use of the application grows over time, user management tends to become more and more of a costly and fault sensitive process with the risk of user accounts not being removed in time or rights not changed quickly enough, leaving the door open for unwanted access. You will also have additional operational strain if you re required to do periodic reviews of access rights. A more effective way of managing users is by managing users from your own site. You normally already have a directory or an on premise identity manager (IDM). By allowing you to manage users in cloud applications with automated connections, a cloud provider facilitates a hybrid cloud security model. There are two ways of achieving this hybrid model. The first is by allowing identity management using an API. This allows you to push user updates to the cloud. This is usually the most desired situation if you have an on-site identity manager. In order to minimize operational risks related to custom integrations, a cloud provider should have support for standards used in the market. This is definitely something to check when considering a specific provider. A cloud provider can support SCIM or the older SPML. SCIM is a simple API based on REST web services. It is based on the CRUD approach to identity management. This is an effective way of user management in most cases. SPML is an older standard based on SOAP web services. It is a more free-format web service implementation for identity management. This allows the cloud provider to implement custom functionality for user management, but is more difficult to integrate with. If for some reason you are not using an API to push identity information, a second option is to set up a VPN connection between the cloud environment and an identity store you have set up on premise, for example an Active Directory. The cloud application then uses your local resource to authorize users. This option allows you to directly control accounts and access rights, but is more prone to operational issues. 7.2 Access management In basic form, authentication and session management is handled by the cloud application. Out of the box the functionalities it offers may be limited. Things like single sign-on, session logging and monitoring, context based rules and multifactor authentication are not always available. There are a number of these things you may want to accomplish, depending on the kind of information that can be accessed in the application, the associated risks, your information security policy, and operational needs. Here are some examples of functionality you can use for a higher level of control: Controlling the accounts that can be used to sign on Logging authentication events Single sign-on across applications Controlling active user sessions Specifying authentication methods Context based access decisions 13/14

14 As said earlier in this document, most providers support authentication through a third party by letting you specify a trusted external system to use for authentication using industry standards like SAML. This basically means that the cloud application redirects users to another system when they try to log in. The trusted system authenticates the user who then is sent back to the cloud application with the result. You can use this mechanism to designate a system that you trust or set up yourself as a source for authentication, and in doing so you provide yourself with an enforcement point for your access management requirements. If you re not extending your identity management processes to the cloud application, but you still want more control over accounts that can be used to sign on, you can set up a VPN connection to an on premise resource which the sign on mechanism of the application can use to authenticate users. This option allows you to directly control accounts and log authentication events, but is more prone to operational issues and does not give you any of the other benefits because you are still using the sign on mechanism of the application. A more agile option is to use a single sign-on solution that s set up on premise or another cloud location. Sometimes this is the only way to integrate a cloud application to a user store you control or your identity management solution. The main benefits are that you can use it to control access to multiple cloud services from a central location, and users only have to sign on once to use all connected applications. It also gives you a central point for integration with other processes like identity management and monitoring. Advanced access management solutions extend traditional single sign-on solutions by adding decision making capabilities based on rules and context. This enables you for instance to specify if a connection needs to be initiated from a specific location (for example from the IP range used in your offices), if a user needs a specific attribute (like a department number) to use an application or to require an additional login method outside business hours. It will also allow more methods of authentication (with support for Windows authentication, multifactor authentication (MFA), one time password (OTP) and social login). If you are already using an on premise access management solution it would be the logical choice to use that as an authentication point for the cloud application. This way you incorporate cloud applications in your existing access management processes. 14/14