Threats and Vulnerabilities - Practical Approach To Secure Openstack Cloud

New features are getting introduced every six months with an intention to make openstack cloud a secure cloud. Some recent hiccup in security vulnerabilities with glibc and OpenSSL reminds that even a single loop-hole can bring down the whole system and impose immense risk to any organization. The attack surface of cloud is definitely getting bigger and bigger due to various cross-integration and support for several components through consolidation (both server and applications) and minimizing "defense-in-depth" due to highly practiced virtualization notion ~ almost everywhere.

Due to those reasons, there are best practices and tools around to minimize the vulnerability gaps and make it difficult for attackers to impose threat. Let's start discussing top threats that we should consider while tightening security for openstack cloud. Later we will discuss on how you can secure it in practical.

To recommend security tools and techniques, we need to identify potential security threats and define possible attack vectors. We will consider STRIDE model in thisarticle and provide recommendation around the same -

No software is full prove safe and it is pretty important to define following classes of security threats:

1. Spoofing: It is defined as "pretending to be something or someone other than original identity"

2. Tampering: It is defined as "altering something on the disk, memory or in network"

3. Repudiation: It is defined as "claiming someone is not responsible and he didn't do anything"

4. Information disclosure: It is defined as "Giving access to someone who is not authorized to see it"

5. Denial of service: It is defined as "Allowing to use all the resource and not letting usual service to use any of those"

6. Escalation of privileges: It is defined as "giving privilege to do something he is not responsible to do"

So far, we have discussed areas inside the organization and now let's see for external threats as well. The major threats are given below:

External Threats - Attackers can use vulnerability in the user VM to take control of it and then move laterally to other vms in the cloud until the attacker puts hand on the "Gem".

Threats from a cloud provider: Cloud misconfigurations can be exploited by "escalation of privilege" and impose risk on disclosure of information. An attacker can launch a new VM in the cloud and attach the previous EBS volumes and steal the information. Good data erasing technique as well as proper care should be taken while restricting EBS volumes for a secure connection and reconnection whenever needed.

Threats from another tenant: Attacker can run an escalation of privilege escape from their restricted boundaries and get into another’s den and steal/disrupts operations.

Now, let's see the practicality of mitigating risks.

Spoofing mitigation:

1. Use public keys infrastructure (PKI) for authentication

2. Use SSL/TLS for HTTP(s) sessions with trusted certificates

3. Immediately change vendors default passwords

4. Administer Openstack keystone and integrate it with LDAP/AD for secure authentication, password policies and account security policies

Tampering Mitigation:

1. Use digital signatures for data integrity. Mitaka and later version will have support for Openstack Glance signing

2. Use of MAC (Mandatory access control) and RBAC to protect Openstack services

Repudiation Mitigation:

1. Enable event logging and security audit

2. Centralized log management through SIEM systems

3. Keep monitoring tenant’s network for anomalies/risk/threats. An idea way is to use network based IDS/IPS and try sand boxing systems for 0 day vulnerability

Information disclosure mitigation:

1. Storage encryption (cinder and libvirt support volume encryption)

2. Use of openstack permission, domains, tenants and group to implement MAC/RBAC for user workloads

Denial of service (DoS) mitigations:

1. Try to use quote per domain/project/user etc and implement through Openstack best practices. High availability will allow to isolate the issue and let other application to work normally at the time of attack.

2. Like AWS/Azure, Openstack can also have availability zone and try to use that feature to isolate affected environment.

3. Reverse proxies for REST API endpoints can be used to isolate Openstack services from direct access. Reverse proxies are pretty important to divert DoS/DDoS attack and each proxy can be easily maintained because those are light weight linux servers with minimal administrative requirement on daily basis.

Escalation of privilege mitigation:

1. Always use SElinux/apparmour edition to implement MAC/RBAC for hypervisor and Openstack services

2. When you place Openstack services into the DMZ, only allow access to API endpoints....

Cloud tenant threat mitigation:

1. Use separate cloud for tenants, if necessary

2. Administer storage encryption per VM or per tenant

3. Openstack Nova has a trusted filter for filter scheduler to schedule workloads. It is known as trusted computing pools so that the workload that are required to be put in trusted execution cluster will only be created on trusted execution platform.

Cloud provider threat mitigation:

1. Can be done through monitoring mechanism for measuring east-west traffic for anomalies.

Encrypting cloud, the recommended methods are provided below:

1. NIST recommendations for cipher suites and key management techniques

2. Salt for passwords – unique for each password, randomly generated

3. Elliptic curve cryptography (ECC) instead of RSA/DSA. ECC requires smaller keys to provide equivalent security, so ECC based algorithms are usually faster.

4. Use the Diffie-Hellman key exchange method for securely exchanging cryptographic keys over a public channel.

Part 2 will come soon.........