Newest Version of FileMaker Platform Brings Significant Major Security Enhancement

Steven H. Blackwell · December 3, 2013

Newest Version of FileMaker Platform

Brings Significant Major Security Enhancement

FileMaker, Inc. today released the latest version of its Platform: FileMaker® Pro 13, FileMaker® Pro 13 Advanced, FileMaker® Server 13, and FileMaker® GO 13.  This release brings many significant new features to the platform including the innovative FileMaker WebDirect™ client access. But to me the most significant enhancement is Encryption of Data at Rest (EAR). Addition of this critical and key functionality completes the FileMaker Platform Security Suite:

Identity and Access Management

Role-Based Privileges

File Access Protection

Encryption of Data in Transit

Encryption of Data at Rest

More so than ever in the past, today many different Threat Agents relentlessly attack an organization’s confidential and proprietary data and are eager to steal those data. Whether by direct attack on hosted databases, by unauthorized access to backups or other copies of database files, or by other attack vectors, these incursions place data at risk. This poses significant problems for organizations, significant business reputation damage, and significant legal liabilities.  With the introduction of the new version of the FileMaker Platform, developers, administrators, and end user clients or customers now have much stronger tools to protect their files and the data those files contain. But in order fully to benefit from this new feature, developers need to understand how it works and what it supposed to do.  How does this work? Using FileMaker Pro 13 Advanced and its Developer Tools, developers or administrators may now introduce industry-standard AES-256 encryption onto FileMaker Pro files. Once FileMaker Server 13 hosts these files, then this encryption is transparent to the end user who will continue to access the files by Account Name and Password as previously.

Figure 1. Developer Tool option for file encryption.

This type of Encryption At Rest protects the physical file and its contents from a variety of attacks. As the name “At Rest” implies, this is basically when the file is closed or when an attack is directed at the physical file itself.  Developers and administrators must recognize some significant considerations when employing the new EAR feature. Here are a number of them:

1. The strength of the encryption is no better than the strength of the new Encryption Password used to encrypt the files. FileMaker Pro Advanced will report whether the Encryption Password is Weak, Moderate, or Strong. Use Strong passwords only.

 Figure 2. Password Quality Dialog. Use Strong Encryption Passwords.

What are the characteristics of a strong password? Certainly length of the password is one attribute. But length alone is insufficient. Shorter passwords in some cases can be stronger than longer ones. The principal determinant of strength is the entropy of the Encryption Password. Entropy is the measurement of uncertainty of a random variable. To achieve strong FileMaker encryption passwords, developers should utilize complex passwords or passphrases with a mixture of lower and upper case alphanumeric characters and high ASCII characters. The best minimum length is probably 14 characters.

2. Encryption with EAR is for the file itself, not for data as they flow across the network from FileMaker Server 13 to various FileMaker Pro clients, including the new WebDirect. Developers and Administrators should continue to use the SSL Encryption option provided in FileMaker Server 13 to protect data in transit. This setting is found in the Admin Console, under Database Server—Security—Require Secure connections as shown here.

Figure 3. Continue to enable Encryption of Data in Transit in the FileMaker Server Admin Console as before. This is in addition to EAR.

3. Refer again to Figure 1, Developer Tool option for file encryption, and please note the text box with the Shared ID label. FileMaker Pro 13 Advanced will automatically enter a value here when the encryption process starts. That value is a simple timestamp; developers may wish to change that value to something else. The purpose of this value is to link a set of files together so that the opening process for those files does not require repeated entry of the Encryption Password.  Here is an important additional piece of information about the Shared ID. Should developers wish at some later time to add a file to a previously encrypted set of files, they must use the same Shared ID and Encryption Password as they did with the original set of files. Otherwise, there will be multiple requests for the Encryption Password.  Thus, safeguarding the Shared ID is important so that developers and administrators can properly and more easily administer encrypted file sets.

4. EAR does not take the place either of passwords or of access privileges as defined in the Privilege Set attached to the active Account. Developers must still employ these features to protect files and the data in them. EAR is not field level encryption; it does not block access to any specific field once a user opens the file. Use the settings in the Privilege Set to control user access to elements of the file.

5. EAR does not take the place of File Access Protection (introduced in FileMaker® Pro 11). Developers should still employ File Access Protection to help guard against Escalation of Privileges by otherwise authorized users or by others who manage to connect to the file. File Access Protection is enabled in the Manage Security section of the file.

Figure 4. File Access Protection.

6. Developers and Administrators should take particular care to safeguard the Encryption Password for a file or group of files. If that information is lost, you will lose the ability to open the file. Loss of the Encryption Password effectively destroys the file. Additionally, the Encryption Password will be needed if developers ever wish to remove encryption from the file. There are several ways to manage retention of these Encryption Passwords, including storing them on an encrypted external device such as a thumb drive and then locking that device away in a secure place.

Figure 5. Removing Encryption from a file requires knowledge of the Encryption Password.

All of which raises this key point about safeguarding the Encryption Passwords. If a Threat Agent, either from inside the organization or from outside of it, were to learn the Encryption Password, that Threat Agent might be able to remove the encryption from the file. So safeguard these Encryption Passwords.  There is one way to prevent the removal of encryption from a file. It is irreversible and permanent, so developers should use it only after exercising serious thought about possible ramifications. This is true even though the Developer Tool makes a copy of the file when it encrypts it, leaving the original intact. If the encrypted copy is put into production, it might not be possible later to extract data from the production copy to be re-introduced into another copy of the original file.

 If, after encrypting the file, a developer uses the Tool also to remove the [Full Access] Accounts, then that file’s encryption is permanent. It cannot be removed, because a [Full Access] Account and password are no longer available. So exercise caution in this area.

In summary, FileMaker Pro 13 Advanced and FileMaker Server 13 bring new capability to protect files and their data with the introduction of industry standard Encryption At Rest. This new capability rounds out the Security Suite of the FileMaker Platform along with Identity and Access Management, Role-Based Security, File Access Protection, and Encryption of Data in Transit.  By employing EAR, developers and administrators of FileMaker systems can help to protect their hosted files, their backups, and any other copies of the files from a variety of attacks that will result in data loss.  

For developers who support business areas with regulatory compliance requirements related to data confidentiality, the new EAR will make securing the file much easier. It can also provide increased confidence in the solution's ability to meet those regulatory requirements. For files containing sensitive, confidential, or proprietary data, I strongly recommend employing EAR. However, almost all business solutions need to protect their data; every developer should, therefore, employ the use of Encryption at Rest.

   -- 

Steven H. Blackwell