FME Flow Hosted Security FAQs

Introduction

The FME Flow Hosted Security Whitepaper provides an overview of how we secure our FME Flow Hosted (formerly FME Cloud) infrastructure and can be found on the FME Security Center. The questions that follow are popular questions that have come up in addition to what is defined in the whitepaper. 

Internal Management Processes

The whitepaper lists the cloud compliance that AWS provides, but does Safe have any security compliance, and if so, to what standards?

Safe Software is ISO 27001:2013 certified for the management of information security for the protection of company and customer information.

Are your staff vetted, if so to what standard and how does this apply to just the small team performing updates?

We don't run police checks on our staff, but we do check references and have a thorough recruiting process. We only have a small team who can actually access the FME Flow Hosted code. This team must follow our internal security guidelines, which include things like using 2-step authentication to access any of the services we use, encrypting hard disks on the machine that have copies of the code, etc. No one person is trusted with access to the infrastructure. If there is a key piece of infrastructure, then it is monitored, and everyone is alerted when someone accesses it.

Will customer data ever be viewed by your staff in Canada (if so it’s deemed to be data export by some clients residing in other countries), or do they just operate on the infrastructure/software?

No, it will not, not without the customer's permission. We have no access to the FME Flow (formerly FME Server) instances through the WebUI and Rest API, our only potential access is via SSH, which is monitored and you will receive an email if we open that port. When working on a support issue, we do our best to respect your privacy as much as possible, we only access the minimum files and settings needed to resolve your issue.

What logs are made /emails are sent when staff access instances– can you provide some examples?

The instance can only be accessed by our staff via SSH, and we will never do it without asking. We don't have the passwords for your FME Flow login. As soon as you download the passwords for the instance, we delete them from our infrastructure. We also monitor the system logs on the instance, if anyone tries to access the instance via SSH (including ourselves), the account owner will receive an email warning them that someone has accessed their instance via SSH.

Hi xxxxx,

As part of our security checks, we wanted to inform you that a user has logged onto your instance ***** via SSH. If the FME Flow Hosted support team did not ask for your permission, or if you would like more details, please contact our support team.

PHONE: +1 604-501-9985 x.278

EMAIL: support@fmecloud.com

Note any unauthorized access to instances is also closely monitored by ourselves.

Sincerely,

The FME Flow Hosted team

You will also see an entry on the activity log for that instance on the dashboard.
 

Do you have a copy of the typical SLA you provide and the Terms and conditions of the service?

We don't offer explicit SLAs as standard for FME Flow Hosted as you can see from the terms and conditions outlined here. The reasonable commercial efforts to make the Online Services available that we talk about in the T&Cs—although not defined on our website—look like this. During office hours (9am-5pm PST Monday-Friday excluding holidays), we will investigate issues within 2 hours. Outside of that window, we will do our best to investigate issues as they happen, but can’t guarantee a response time. However, we are open to creating tailored SLAs for individual clients based on your requirements.

There is also an element of joint responsibility with regard to the instance. The main reason we see instances running into issues is when it runs out of disk space or is overloaded. The FME Flow Hosted Monitoring enables you to monitor when the disk goes over a certain value or the load/CPU exceeds a limit and sends an alert. This means you can tackle issues before they turn serious.

Instance Security

What entry points are open to the instance by default?
What entry points are open to the instance by default?
By default, we open ports 22, 80, 443 and 25. Here is an outline of what each port is used for:

• Port 22: Used for SSH access. You cannot delete this port as Safe Software uses it to configure and access the instance. The port is locked to our IP and heavily monitored.
• Port 80: Used for HTTP. Required to access the FME Flow WebUI or Rest API.
• Port 443: Used for HTTPS and WebSockets via WSS. Required to access the FME Flow WebUI or Rest API.
• Port 25: FME Flow SMTP server runs on this port. If you are not using the SMTP Email publisher, you can delete this.
  
  

With ports 80 and 443 open, since the instance has a public IP address, anyone could access the FME Flow web application or REST API. Authentication is, however, required for anyone to be able to do anything. If you wish to prevent people from even connecting, then you can lock the source down to a specific IP. This means that ports 80 and 443 will only be reachable from the IP addresses you define. Details on how to do that are outlined here.
 

SSL encryption – the white paper states this is 128 bit RC4, is this still correct?

The connection is encrypted and authenticated using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism. We have removed RC4 ciphers.

Is it possible to lockdown outgoing ports /IPs on server instances?

Currently, it is not possible, it is something we could add, please post in the ideas exchange. Incoming ports can be locked down.

Can you confirm that individual instances don’t have shared components (other than the AWS cloud infrastructure)

Correct, they are dedicated instances and there are no shared components. The only data from Safe Software going onto the instance are via messaging queues to do things like trigger Ubuntu patches.

Are the data volumes mounted against the instance encrypted – if so to what level/protocol?

All EBS volumes that we mount against the instance are encrypted using the industry-standard AES-256 algorithm, it's the default encryption provided by AWS. Read more here.

Are the backup images encrypted – if so to what level?

Yes, they are also encrypted using AES-256. We are essentially taking a copy of the EBS volume, since that is encrypted the backups and snapshots are too.

How are images, and/or backups destroyed?

When you terminate an instance on FME Flow Hosted, the instance and EBS volumes are immediately destroyed. The associated backups and snapshots are destroyed 30 days after you trigger the terminate command. We wait 30 days so we can recover an instance for a period if required. After 30 days we destroy the backups and snapshots using the standard AWS commands.

Security Threats

How do Safe deal with security threats and what’s the SLA to resolve?

We don't offer explicit SLAs as standard for FME Flow Hosted as you can see from the terms and conditions outlined here. We usually work to create tailored SLAs for individual clients based on their requirements. That said, we do have the capability to react immediately, it just isn’t always worth us doing so for every customer if they are running development and staging environments for example. If there is an intrusion or a vulnerability, we will know about it right away because of all the monitoring setups. We have key alerts that go straight to all of our phones via a service called PagerDuty.

Can you provide examples of how you have dealt with critical security threats in the past.

There have been several high-profile security bugs uncovered globally that have impacted FME Flow Hosted: Shellshock, Poodle, and Heartbleed. We were not affected by all of them, but for all of these issues, the process was the same. We first audit our entire infrastructure to see what is affected and based on that assess what the security risk is. We often discuss things with our third-party security professional at this point, too. In the case of Shellshock, which we were vulnerable to, we created a patch and before rolling the patch out sent the following email to affected customers:

Hi xxxxxx,

The engineering team at FME Flow Hosted has been working to assess the impact for our customers in the wake of September 25th’s disclosure of CVE-2014-6271 and CVE-2014-7169, known colloquially as Shellshock. The issue lies in Bash's handling of environment variables and in theory an attacker could exploit it to execute shell commands i.e. run programs on the server. We join nearly every service provider on the internet responding to this critical vulnerability and conducted a comprehensive security review.

You are running an instance that has security updates deactivated (or you launched it before we provided the automated patching). We could not find any vulnerabilities in FME Flow, but because of the severity of this bug (10/10 for severity) and as a preventive measure we will apply the security patch to your instance. We will therefore be logging onto your instance via SSH in the next few hours to apply the patch. We will not need to restart the instance, but you will get an email saying someone has logged onto your instance.

As best practice, we have disabled the ability to launch instances with security updates deactivated. This is until we are 100% sure that the server that we are providing you when you first launch is secure.

If you have any questions or concerns, don't hesitate to contact us.

Many Thanks,

FME Flow Hosted Team

We are aware that communication is critical when issues such as this arise and we aim to be as transparent as possible. 

How do you monitor and manage the emergence of new security threats?

We work with a third-party Certified Information Systems Security Professional (CISSP), to complete the application and network security audits. This includes manual network vulnerability scanning and penetration testing against the FME Server instances and the FME Cloud web application where you manage all of your instances.

How do you do to communicate issues?

For general issues, we will post updates in our Security Center as well as send out emails to those who have signed up to receive security emails. You can sign up at the bottom of the Security Center. 

Software Development Cycle

How does your product development cycles for FME Flow and FME Flow Hosted and cloud take account of checking for security issues being introduced?

On FME Flow and FME Flow Hosted, we use industry-standard frameworks and tools to ensure that if there is an issue then it is easy to patch.

FME Flow works on an annual release cycle. For all third-party components that FME Flow uses such as PostgreSQL, JVM and Tomcat; we ensure the most recent security patches are applied. We also systematically monitor vulnerabilities in libraries that we ship with the FME Engine and we use the .x releases to incorporate these fixes on a regular basis.
FME Flow Hosted works on a continuous deployment cycle. Firstly we have very strict rules about who can deploy and when you are allowed to deploy. We first have humans check for issues in the code reviews. When we push the code to our staging environment where two things happen, a service called Code Climate runs which checks the actual code for common errors that people make that can lead to security exploits. We then deploy the code to production.

How do you deal with changes to FME Flow Hosted?

 What happens if you need to introduce a breaking change to your rest services for example.

Our entire FME Flow Hosted infrastructure is heavily versioned, from the APIs through to the machine images that we use to provision FME Flow. That means for all but the most very serious of bugs we would just push the change to the new version. If we did have to push a breaking change—security issues might be the only reason we needed to do this—we would communicate this to customers in advance, via email and any other channels deemed appropriate. We would give a time window defining when we were going to roll out the change and then work with customers to ensure they knew how they had to update their workflows.

Data Protection

What happens if this data centre was to go down, would we lose our services or would you/AWS move to a different data centre automatically?

Currently, if the data center (so-called availability zone [AZ]) was to go down, then the instance would be unreachable for that period. Each region is comprised of multiple AZs. We could add support for fault-tolerant deployments across multiple AZs in one region, but it is not something we have requested so far, as the cost and complexity have increased dramatically. We would never move data between regions.
Although instances may be unreachable for periods of time, if the data center goes down we still won’t have lost your data. If the hardware on the instance fails, or the EBS volume becomes corrupt, we can roll back to a previous backup and restore the instance.