You may remember Alexander Adamov from his May 2015 article, “Detecting targeted cyber attacks in the cloud”. Now he’s brought us a look at security at the Tokyo summit.
Vulnerability Management and Security Testing
The vulnerability mailing list is to be tightened to provide more control on information exposure, but the Vulnerability Management process flow will be more formalized so that the mailing list isn’t the sole means of delivering information to downstream stakeholders. You can get more information on the etherpad.
A new Python API security testing tool called Syntribos was discussed in a dedicated design session. It can be used as a penetration testing tool or implemented as a gate job in the future. Syntribos is designed to automatically detect common potential security breaches such as SQL injection, LDAP injection, a buffer overflow, and so on. In addition, Syntribos can be used to help identify new security defects by fuzzing HTTP requests. You can get more information on the etherpad, or check out the Syntribos tool itself.
Identity Federation in focus
Using the Barbican service for Identity Federation was discussed, however there’s a problem with trusting a cloud provider when storing an encryption key for images and running decrypted images. The key stored by a Barbican private service and a decrypted image should be erased after use but what if a cloud provider leaves decrypted data, or unintentionally exposes a key?
Steve Martinelli from IBM, Joe Savak and Douglas Mendizábal from Rackspace, Marek Dennis from CERN, and Klaas Wierenga from Cisco gave a presentation about different aspects of federated applications. During the panel discussion it was stated that Federation continues growing in popularity, and is now even used in an academic area. Dennis explained how Federation helps CERN researchers to focus on discovering the fundamental structure of the Universe, not managing accounts that provide scientists with access to petabytes of data gathered by the Large Hadron Collider’s sensors.
Development of the Firewall as a Service plugin is ongoing and we looked at the FWaaS roadmap. Important takeaways included:
- We should consider setting FWaaS up for zones, service chains, containers, and VM ports, as opposed to the current situation, where it only works for Routers. For example, a zone-based firewall will be able to filter any given network traffic without the need to set multiple ACLs, bringing the service to a higher abstraction level. In this way, you need only to care about setting an appropriate security zone for a node.
- The Liberty FWaaS API is deprecated and will be redesigned in Mitaka with the goal of enabling:
- port based functionality
- augmentation of SecurityGroups
- an IPTables based reference implementation
- Service Groups
- In the N-cycle, we’ll work on scalability, HA, and zone-based firewalls.
- In the O-cycle, we’ll work on a common back end for Security Groups and Firewall.
- Mirantis can contribute to FWaaS documentation.
Securing traffic in OpenStack private clouds (Intel + Midokura)
Intel, with the help of Midokura, presented its own security solution for scanning network traffic, built on the Intel Security Controller Platform. (They also promised to open source it at some point in the future.) The implementation is new, and looks fairly immature for now, however, I consider this approach rather promising. Sooner or later cloud providers will start thinking about deploying an all-in-one security solution that can orchestrate a deployed cloud in an automatic way via APIs. This will make it possible to configure, adjust, and scale it in close to real time, providing protection for emerging threats. Moreover, being integrated with Intel TXT on a hardware level, it may have a solid background to be a reliable security solution.
Some takeaways from this session include:
- 80% of cloud traffic is East/West — that is, inside the cloud
- The Intel Security Controller (ISC) Platform may include McAfee Virtual Network Security Platform, Firewall, and third-party security applications communicating via open APIs for Orchestration
- ISC uses the VLAN tag to bind Security Policies and the in/out packet is redirected to the Service VM to be scanned
Basically, the Intel Security Controller Platform will scan ingoing/outgoing network traffic and orchestrate deployed security solutions via API; they also introduced a concept of Virtual Domains from PLUMgrid that includes a policy enforcement zone through which network traffic comes from external networks to VMs. Such domains bring a flexibility, for example, to cut a compromised domain from the Internet and a private network, and let the forensics team do their work.
Secure Your OpenStack Infrastructure (Awnix + PLUMgrid)
Rick Kundiger (CEO Awnix and former US DoD engineer) stated that Firewalls, VLAN, and ACLs are not enough to make a cloud secure. The suggested a solution: create a Security Tenant with Firewall, Security Groups, IDS, IPS, UTM, and so on on board, leveraging SDN. This way, once any tenant is compromised, the Gateway IP can be changed to connect to the internal Forensics network with a security tenant there full of forensics tools. (This is a nice idea PLUMgrid came up with.) The also discussed Detection (for example, by IDS) and Remediation automation.
The suggested that Security Groups are preferable to Firewall rules because of the high granularity they provide. Even if an attacker gets into one server, they won’t be able to propagate within the same project.
Also discussed was IOVisor, a Linux upstream project by PLUMgrid that provides Network Isolation across Compute Domains that works the same way for VMs and Containers. This way it unifies management of networking security, and not only networking. Because it is a part of the linux kernel, IOVisor can also trace a process and a user that sends suspicious packets.
Protecting Hybrid Cloud (FlawCheck)
I also attended a talk by FlawCheck, an interesting startup that has its own malware/vulnerability static signature engine to check Docker containers. They’re on the rise now, of course, and according to the report, the majority of predefined containers are vulnerable. In fact, the top concern users had about running apps in Docker containers was “Vulnerability and malware”, with 42% of respondents citing it. And no wonder: with no security check inspection by Docker, it turns out that 30% containers have vulnerabilities.
An overall look at security at the OpenStack Tokyo Summit
In Tokyo we saw more topics that ever before intending to answer the question, “How do you protect your cloud against cyber attacks?” In addition to these views coming from Intel and Midokura, Awnix and PLUMGrid, and FlawCheck, the Vulnerability Management Team, being a part of the OpenStack Security Project, is doing a great job in revealing and fixing vulnerabilities in the upstream code and delivering those fixes to downstream stakeholders. Tools such as Bandit and a new security testing tool called Syntribos appeared this release, and can be of use here.
However, fixing security bugs is not enough to protect clouds against hackers. Intel and PLUMgrid understand this and propose architectural solutions aimed to increase cloud security.
On the container side, we saw just how serious the situation is, but we also saw the introduction of the open source Linux kernel module IOVisor to try and solve it.
To sum up, we see a trend of interface unification and centralized security orchestration, which may bring more flexibility and simplicity for security policy enforcement and digital forensics.