GUIDE (Cybersecurity)

Five Compliance Pressures When Deploying OpenStack in Production in 2018It’s not just about ease of deployment or containerized applications. Your organization needs to keep passing business and technical audits. Over the past three years many of our largest customers have moved into production with various OpenStack flavors, including Red Hat OpenShift, SUSE OpenStack, and HPE OpenStack. Responding to pressures from their international business units for on-demand Platform as a Service (PAAS) these organizations have created first regional and then expanding to worldwide implementations.

In various regulated marketplaces these customers have continued to maintain business and technical compliance, passing their monthly or quarterly audits in this new infrastructure.

Polling their project teams, we would like to share some common compliance themes that must be overcome in the transition to production operation.

Page 1www.foxt.com

Five Compliance Pressures When Deploying OpenStack in Production in 2018

1. “The OpenStack security model is a work in progress and needs enhancement with other tools.”

Instance Roles: Compared to your production operations staff, auditors ask different types of questions, such as:

• “Who could log into all your Red Hat Linux systems and be granted root privilege in the last 60 days?”

• “Which database support staff ran privileged commands on our customer databases two weeks ago?”

Administration and operations staff hate audit time. They rearrange technical and audit log information in the format auditors prefer rather than how it is organized and presented for day to day production support and tracking. The OpenStack Zone:instance model at first glance does not tell you a lot about which business process component a running instance is hosting, never mind what operating system type it is running today.

A single running instance may have multiple host roles, with different production support teams needing to connect for various reasons. For example

• I am a SUSE Enterprise Linux 12 host

• I run a APV performance tracking agent

• I host a copy of the customer database (with an expected long uptime)

For efficiency and auditability another tool is needed to provide

to make reporting easier and provide the answers to auditors quickly without admin staff intervention.

Transient Support Staff: The current access model of static IP address ranges allowing your staff to access images in an otherwise highly dynamic infrastructure is a quite surprising anomaly.

This means when your international support teams provide follow-the-sun production support their locations (and network addresses) may change through different times of the day and/or working week. In exceptional circumstances tier three support staff may need to connect to your infrastructure from their homes, or their latest conference hotel room.

All the customers we contacted recommend using an access management agent inside the instance operating system, with a wider range of access control options than the defaults offered by OpenStack.

Multi-factor authentication: MFA has been mandated in worldwide financial services infrastructures for server/virtual machine production access for some years, and now applies to OpenStack images coming into live operation. With PCI-DSS requirements, this will also impact your infrastructure if your organization is processing card information.

With large scale deployments, especially across geographies, different teams may have different MFA devices to log in to the same instance. Various add-ons for OpenStack or inside-the-instance OS are available to support MFA technologies. Ensure yours can support more than one manufacturer/vendor concurrently.

2. “For our auditors, OpenStack security stops at the running instance boundary.”

Compliance and audit looks at material impacts and risks to your business. Now that means instances where data is stored, other instances where it is transformed, and instances where it is presented to a customer or supplier.

Zone:Role(s):Instance

Page 2www.foxt.com

Five Compliance Pressures When Deploying OpenStack in Production in 2018

Assuming most live applications migrated to OpenStack are legacy applications, (see point 5 below), audit will continue to ask questions about the use of SU and SUDO inside your instances.

It is interesting or the OpenStack project, when deploying at scale, recommendations and architectural decisions have been made in the latest editions to stop using Linux/UNIX SUDO by default for privileged command escalation for the OpenStack infrastructure itself. The reasons quoted being:

• SUDO is not granular enough

• SUDO is difficult to scale

• Keeping sudoers files in authoritative sync is not OpenStack’s core strength

And therefore, the OpenStack security model has nothing to say about maintaining SUDO (nor SU) inside application and database instances—something your auditors require you keep under control.

Luckily there are many vendors who have centralized policy management solutions for Linux and UNIX platforms for SU and SUDO. They have solved these scaling, granularity, and management issues decades ago, and most have stopped using sudoers’ files completely. Review analyst reports from Gartner, Forrester, and others for privileged access management (PAM) vendors to compare features.

3. “We use commercial tools if they bring business advantage.”

There is a certain culture to OpenStack deployments, where project teams use open source products at all cost whenever possible. When your business requires extra levers to be more agile, or to stay compliant with regulatory requirements, our customers tell us they have no problem adding commercial software into their OpenStack production deployments.

To be ultra-responsive to a customer’s experience: Using APV performance agents on all instances to report and tease out performance bottlenecks. More than half of our customers use these, another 25 percent are considering their implementation on OpenStack during 2018.

To be compliant: Adding access management, alert monitoring, and file monitoring—all almost the same mix of security tool scope they have used on stand-alone servers and VMware infrastructures over the past decades, but now on OpenStack running instances. From most perspectives OpenStack is a new Tier 2 hypervisor surrounded by toolsets. The basic security requirements and compliance/audit needs for a business for an OpenStack instance are the same as a virtual machine running on the last generation of technology stack.

4. “OpenStack is data centre-centric. Specifically, Keystone does not map well to thousands of branches running four nines applications.”

Originally specific to financial services but now an expanding issue for card processing in PCI infrastructures (all retailers, “eCitizen” government-based services, transportation companies, and healthcare worldwide), the requirement for four nines application availability in (for example) a brick-and-mortar branch operation does not tie well into the current OpenStack technology stack.

Page 3www.foxt.com

Five Compliance Pressures When Deploying OpenStack in Production in 2018

5. “Containerized applications do not have a vendor-neutral reference security model to implement. This will be important for the future; however, it will be a minority activity during 2018.”

The Cloud Security Alliance (CSA) announced the formation of an Application Container and Microservices Working Group in December 2017. The group is not expected to report for at least a year.

In the meantime, why are customers not yet concerned? Separate from general discussions about OpenStack deployment worldwide, and with a hard reality check, the Q4 2017 analysis by the 451 Group’s “State of the Enterprise” (warning: PAYWALL) gave us all some hard statistics:

• No more than 13.7 percent of enterprises have containerized applications in production

• Of these companies, no more of 10 percent of deployed applications are container based.

• That means no more than 1.4 percent of all applications deployed in production worldwide are containerized.

In review with our customers, they report that the session on Highly Distributed OpenStack at the recent OpenStack Summit in Sydney is a fair representation of the issues they continue to have, and at the moment OpenStack is not suitable for transactional applications that must keep operating if the network links to the bank’s data centres are down.

Worldwide, the failure rate of random network links (even with redundancy) from retailers and bank branches to corporate infrastructures can run at a dependable three to five percent. Now think about that for a moment:

• For a retailer with 25 shops, that could be less than one store offline

• For a transportation vendor with 500 machines selling tickets, 15 machines could be offline

• For an international bank with 6,000 branches, 180 could be offline at any time

As a result, banking and most retail branches have stand-alone infrastructure, typically implemented as a “cloud in a box,” where customers’ deposits, withdrawals, and time-critical transactions can be processed locally. This is a mandatory business requirement, and so our customers tell us they have no plans to use OpenStack to manage these local mini-clouds.

Realizing this from their own feedback from the community, the OpenStack Project has just begun to collect “branch” and “edge” requirements for a future major release. Analysts say a feasible solution could be three years out.

In the meantime, from a security compliance perspective, the switch in operations from connected to local control gets auditors’ notice. Changes in privileged escalation, how offline security policy is managed by a nominated local staff member, and showing evidence of how offline control is carefully controlled must be easily reportable once branches reconnect to the network. Most commercial access management solutions for Linux, UNIX, and Windows server platforms have offline mode capabilities.

Five Compliance Pressures When Deploying OpenStack in Production in 2018

About HelpSystemsOrganizations around the world rely on HelpSystems to make IT

lives easier and keep business running smoothly. Our software and services monitor and automate processes, encrypt and secure

data, and provide easy access to the information people need.www.helpsystems.com

HelpSystems, LLC. All trademarks and registered trademarks are the property of their respective owners. (RJB-PTX-PNS-SCR-GD-1018-R1)

That’s a sobering thought, and a reflection of current reality confirmed by Red Hat’s head of its OpenShift business unit in an interview early in 2018.

For OpenStack deployments, although reams of press and marketing announcements focus on OpenStack and containers, in real life your deployment teams are migrating “legacy” applications onto its new infrastructure. Platform as a service (PAAS) is by far the main business and technical driver in 2018, and hosted applications cannot all be transformed to interact with Keystone effectively.

That means security models and administration practices that surround these applications shall migrate into your OpenStack infrastructures. You will need to migrate the security tooling from your old infrastructure for audit and compliance purposes. Our customers confirm this, although all have significant other projects to build new applications using containers. Going forward, the percentage footprint into production will take time to get past 5 percent, 10 percent, 20 percent over the next three or four years.

HelpSystems and OpenStack deployments during 2018

Of the five compliance and audit concerns identified by our financial services customers, HelpSystems is gap-filling the first four using standard functionality that supports the audit and compliance requirements of critical business applications.

At this stage, containerization and microservices are important strategic directions for the future, directed by solution architects. OpenStack is one of the technical platforms where containerization can be easily overlaid.

The Powertech Identity & Access Manager (BoKS) access management and privileged escalation audit and control platform is available on all major Linux and UNIX operating system platforms, providing a central administration experience.

Identity & Access Manager is a highly scalable solution, and can be deployed on stand-alone server clusters, soft or hard partitioning of traditional UNIX platforms, or within VMware, OpenStack, or Amazon AWS clouds.

To learn more about Identity & Access Manager or request a demo, visit www.helpsystems.com/cta/request-live-demonstration-identity-access-manager.