FileMaker Security Blog

FileMaker DevCon To Convene

Against Backdrop

Of Cyber-Attacks Across The Globe

July 18^th 2017

In just a few days, four generations of FileMaker developers and users from all over the world will gather for the 22^nd Annual FileMaker DevCon, held this year in Phoenix, Arizona. We will do so against an unprecedented backdrop of critical security issues facing businesses and organizations all over the world.  Organizations of all sizes and from every business sector are vulnerable.  Small to medium-sized businesses are particularly so, especially in the areas of financial services, health care services, and retail services.

Jeff John Roberts and Adam Lashinsky, the latter well-known as a chronicler of FileMaker, Inc.’s parent company, reported recently:

…business is under assault like never before from hackers, and the cost and severity of the problem is escalating almost daily.

(Cybersecurity: How Business Is Protecting Itself

http://fortune.com/2017/06/22/cybersecurity-business-fights-back/)

Bob Pisani, well-known business reporter for CNBC, also recently reported on a major cyber-attack:

…snack food and beverage giant Mondelez International became the latest victim of a cyber attack. The company said it was hit with an attack on June 27 that compromised its ability to ship and send invoices during the last four days of its second quarter.

What made this call unusual is that the company quantified exactly how much the attack hurt them: Its preliminary estimate of the impact indicates a 3 percent slice off its revenue growth rate for the quarter.

(Cybersecurity stocks rally as global hackings start to impact corporate bottom lines

http://www.cnbc.com/2017/07/07/cybersecurity-stocks-rally-on-mondelez-hacking.html)

Additionally, in May of 2018 developers and their client organizations on both sides of the Atlantic will become subject to the comprehensive General Data Protection Regulation (GDPR) promulgated by the European Union (EU). Organizations that store data about EU citizens are bound by the GDPR strictures, irrespective of where the organization itself resides.  It will remain to be seen how the EU is able to enforce those requirements outside its own boundaries.

These issues, of course, also apply to platforms other than FileMaker. But as the developers, administrators, custodians, and users of business systems based on the FileMaker Platform, our principal concerns must be the identification and management of these issues.

These are not principally technical or programming issues.  They are—first and foremost—business issues:  business criminal and civil liability, business continuity, and business reputation among them.

·      Organizations of every type face criminal and civil liability sanctions if a data breach occurs.

·      Some attacks and breaches can literally speaking put an organization out of business, rendering it unable to continue functioning and to provide its designated services.

·      Even if an organization is able to recoup and to continue, its reputation will be damaged and its brand diminished.

As FileMaker developers we all have a responsibility to our clients to design our business solutions and to deploy and operate them with these security constraints in mind.  As in-house developers and administrators, we likewise have the responsibility to our customers, our shareholders, our members, and our fellow employees to operate our database systems in a responsible and careful fashion.

What are some of the more significant and damaging exploits that some Threat Agent could employ against FileMaker Platform business management solutions?  And who are those Threat Agents?

Threat Agents include a variety of actors, some malevolent, some hapless, some innocent:

·      Malicious Outsiders seeking financial gain or seeking to disrupt the organization’s business processes.

·      Malicious Insiders, current or former employees, or parts of an organization’s supply chain.

·      Inept Insiders who accidentally or unknowingly cause security-related incidents that damage, delete, or otherwise alter critical organizational data.

·      Threads in the Supply Chain where carelessness or poor security practices facilitate damage to our own organizational data and functioning.

·      Finally, although this by no means is a complete list, inattentive or unknowing developers, administrators, or custodians of FileMaker Platform business management solutions who do not follow Best Practices for Security and management of those systems.

What type of exploits can Threat Agents employ that damage these solutions and thereby damage the organization as well?

·      Deleting of data, intentional or accidental.

·      Altering of data, either obvious or (more problematically) subtle in nature.

·      Extracting of data for competitive business purposes or for use for embarrassing or damaging the organization.

·      Adding of spurious data.

·      Manipulating of tracking processes for key business activities such as invoice or accounts payable processes.

What can FileMaker Platform developers and administrators do to protect against these exploits, to lessen vulnerabilities, and to reduce risks of their occurring?  Security Check Lists are almost always bad ideas, because they overlook the dynamic and on-going nature of vulnerabilities, threats, and risks.  Nevertheless, here are a few items to consider:

·      Use FileMaker Server and invoke Encryption in Transit for data flowing across networks.

·      Employ Encryption at Rest on the database files.  One of the most frequently used attack vectors is getting a copy of the files and performing attacks on them.

·      Use File Access Protection on all files in the business management solution to prevent unauthorized access to fields, tables, scripts, value lists, and similar schema elements.

·      Use finely-grained Privilege Sets.  Respect the Rule of Least Privileges that states “Users should have all the privileges necessary successfully to fulfill their roles, but no more and no higher privileges.”  Escalation of privileges is a major vulnerability.

·      Employ strong credentials to access the FileMaker business management solution.  Use the tools that FileMaker, Inc. provides.  Do not try to invent your own system for doing this. Those artificial or ersatz security systems are rife with vulnerabilities.  This is particularly true of those that first grant access to the file, even at a diminished level of Privileges, and then require the user to take some actions or go through some process before using the system.

·      Remember that the User Interface is not part of the Security Schema.  Just because you cannot see or change something via the UI does not mean that an Attacker cannot see it, alter it, or delete it.

I will hope to see many of you at the Developer Conference.  And I would be happy to discuss any of these items with you in greater detail.

Steven H. Blackwell

Here is an Infographic showing the Security Schema of the FileMaker Platform at it now stands at Version 16.

There have been a number of reports of developers having difficulty logging into FileMaker® Pro 16 files with OAuth2 based Accounts once they have set up the services on FileMaker® Server 16.

Briefly to review, developers can now specify Amazon, Google, or Azure Active Directory Accounts to validate Identity Assertions and gain admission to the file.  However, users must understand that when using these OAuth2  Accounts that they do not enter the credentials in the normal place in the dialog.  That locale is reserved for FileMaker Accounts and legacy External Server Authentication Accounts only.

Instead, users should click the respective button for the Identity Service they are using as shown in the illustration. Once this is done, the authentication process can continue.

Steven H. Blackwell

Platinum Member Emeritus, FileMaker Business Alliance

One of the best new security features in the FileMaker 16 Platform is that, by default, several external Application Program Interfaces (APIs) are off and disabled.  AppleEvents, ActiveX, and FMPURL Perform Script are all still there.  But developers must specifically select and enable them.

This feature prevents unauthorized manipulation and interaction with FileMaker Pro files, both stand-alone and hosted by FileMaker Server.  Such manipulation can be used to alter data, destroy data, create data, run scripts, and in some instances, manipulate the User Interface. Such attacks can have significant impact on FileMaker Platform business solutions as described in FileMaker Security BLOG post found at http://fmforums.com/blogs/entry/1652-security-vulnerabilities-of-filemaker-platform-api’s-an-update/

If developers do use AppleEvents, ActiveX, or FMPURL Perform Script in solutions, and they wish to use FileMaker® Pro 16, then they must now specifically enable the desired Privilege Bit for these APIs.  This can be done on a Privilege Set specific basis.  If developers do not enable these privileges, then the solutions will not perform as designed.  This is true irrespective of whatever settings might have been in earlier versions.

To enable the specific privilege, go to Manage Security and select the Extended Privileges section.  Then check the desired option, as shown here:

Following this practice will allow the specific API to interact with the file as desired.

Steven H. Blackwell

Platinum Member Emeritus, FileMaker Business Alliance

FileMaker 16 Platform Brings Significant New Security Features

The release of Version 16 of the FileMaker Platform brings with it a host of new security features reaching across the entire FileMaker Platform, from FileMaker® Server 16 to FileMaker® Pro 16 to WebDirect™ and beyond.

There are new controls on the use of three external Application Programming Interfaces (API’s): AppleEvents, ActiveX, and FMPURL.  These controls significantly strengthen security in this area and prevent use of the API’s to manipulate and compromise the database files.

There is a new option to encrypt individual fields in a table of the database. Developers must learn what this feature is and what it does and does not do.  For example, it does not replace Encryption At Rest (EAR) for files.

Version 16 also expands Federated Identity Management with the addition of three new Identity Services that can authenticate user identity assertions.  Google Accounts, Amazon Accounts, and Azure Active Directory Accounts and Groups, can now validate such assertions.  Again, developers must learn how this feature works and what it does and does not do.

Read more in this new White Paper jointly authored by Wim Decorte and Steven H. Blackwell.

Introduction To The Numerous Significant New Security Features In FileMaker Platform Version 16

that you can download from this link:

http://fmforums.com/files/file/90-new-security-features-version-16/

You can also read more about the new OAuth2 Identity Assertion Validation options in a second White Paper also jointly authored by Wim Decorte and Steven H. Blackwell.

Federated Identity Management OAuth Identity Providers in FileMaker 16

that you can download from this link:

http://fmforums.com/files/file/91-oauth-identity-providers/

Wim Decorte will also be presenting a program at the 2017 DevCon on this topic.

Steven H. Blackwell

Platinum Member Emeritus, FileMaker Business Alliance

Security Vulnerabilities of FileMaker Platform API’s:  An Update

 January 9th 2017

In an April 2016 entry on this BLOG titled The FileMaker Platform API’s Are Your Friends, Right? [http://fmforums.com/blogs/entry/1535-the-filemaker-platform-api’s-are-your-friends-right/] I discussed a number of FileMaker Platform security issues centered on the uncontrolled use of a number of external Application Program Interfaces (API’s). There are at least nine of these API, possibly more, if ExecuteSQL is included. The central thesis of that article was that these API’s provide unexpected attack vectors to compromise FileMaker Platform files.  As noted at the time:

Many FileMaker developers are not aware, however, that these API’s have the capability to access customer or client solutions in unexpected ways and to extract or insert data, to manipulate business processes developers embedded into these solutions, and to compromise the integrity of these solutions. 

Unfortunately, in the intervening nine-month time span, we continue to see cases where several of these API have been used for malicious purposes to compromise FileMaker Platform files’ business process integrity, to manipulate data, and to extract data.  And many in the developer community remain unaware of this problem. In this BLOG entry, I will describe two of these API’s in greater specificity and detail, including describing a variety of attacks they can facilitate.  This article will not discuss the ActiveX API that is available on Windows OS; however, developers should give similar attention to that approach. Developers need to be aware of these items in order to protect their files and those of their clients.

The two API at the center of this focus are Apple Events and the FMPURL process.  In the earlier article, I noted several elements about these that bear repeating here:

[These API] cause particular concern because of their breadth and relative ease of use….

The Apple Events Suite has an extensive set of commands that can read and write data, read metadata, manipulate the UI, and trigger scripts. In addition, they can work outside the normal constraints found on layouts in a file. [http://thefmkb.com/5671]

The FMPURL…can open a file and run a script in it.  If the file is already open, then the script will still run. [http://thefmkb.com/5560]

A few general comments about both of these API’s:

·      They are not platform-specific in the sense that just because a client organization is an all Windows OS environment that it is immune from an Apple Event attack.  It’s the OS of the attacker that controls whether the API can be used.

·      There are some ways within Privilege Sets to constrain behavior of these API commands when they are applied on a file. The Export privilege bit can control the ability of Apple Events to extract data from a file. The Layout Access privilege bits can also constrain the ability to see contents of a layout. Likewise, Script Access privilege bits can control the availability of a script to either of these API.

·      These API often perform actions in unexpected fashions that fall outside the normal, traditional, and familiar FileMaker Pro User Interface behavior. This is part of what catches developers by surprise.

—Apple Events—

When a file is open, whether standalone or hosted by FileMaker Server, an attacker can send Apple Event commands to it causing it to perform a variety of actions, including:

·      Run any script to which the user has access, irrespective of whether that script is in the list of Scripts or whether it is attached to some UI element, such as a button.

·      Navigate to any Layout irrespective of whether that Layout’s name is in the list of Layouts or not. If the user’s Privilege Set has access to see that Layout, then its contents are visible whether the developer ever intended for the user to view the Layout or not.

·      Return various metadata about the file, including such items as Script Names, Value List Items, Layout Names, Field Names, etc. If a user’s Privilege Set does not allow access to the item, its name does not appear in the list returned.

·      Put data into any field in the database or extract data from any field, irrespective of whether that field is on the active Layout or is on any Layout for that matter.

Here are several examples of these scripts, all working on a file named Our_Secret_Information.fmp12.

tell application "FileMaker Pro Advanced"

       activate

       go to first layout

end tell

tell application "FileMaker Pro Advanced"

       activate

       do script FileMaker script "Relog_as_Admin"

end tell

tell application "FileMaker Pro Advanced"

       activate

       set somevar to name of every layout

end tell

tell application "FileMaker Pro Advanced"

       activate

       set somevar to name of every field

end tell

tell application "FileMaker Pro Advanced"

       activate

       set somevar to get data field "CreditCardNumber"

end tell

—FMPURL—

The FMPURL command’s principal attack vector is that it can be used to run any Script in a file to which a user’s privileges has access. Similar to Apple Events, this occurs irrespective of whether that script is in the list of Scripts or whether it is attached to some UI element, such as a button.

If the file is closed, the command first opens the file with supplied credentials, then runs any OnFirstWindowOpen script, and then runs the designated script from the FMPURL command.  As a result of this behavior, a Halt Script step at the end of the opening script has the effect of blocking the running of the FMPURL designated script. Some developers have utilized this technique to block FMPURL calls to scripts in a file.

However, if the file is already opened or if there is no opening script, then the designated script does run.

Here is an example of calling a script, again in our file Our_Secret_Information.fmp12 being hosted at a server at IP address 0.0.0.0.

fmp://0.0.0.0/Our_Secret_Information.fmp12?script= Relog_as_Admin

—What Is the Significance Of This and

How Do We Address This?—

One of the many reasons we caution developers against embedding security elements such as Identity and Access Management controls into the data layer of FileMaker Pro databases is precisely because such elements are vulnerable to these API attacks. Think for a minute about that Relog_as_Admin script that presumably relogs into the file with a [Full Access] Account.  If an Attacker can trigger that script and cause it to run, irrespective of what the developer might have intended, then the Attacker has full access to the file. This has actually happened.

Or, suppose that a developer has made a “Developer_Only” layout in the file, removed it from the list of layouts, and left sensitive information on it. If the Attacker can navigate to that layout, and if it is not protected by settings in the Privilege Set, then the Attacker can learn the contents of the information on it.  This has actually happened in numerous instances, including unbelievably, the appearance of [Full Access] level credentials left exposed on the layout!

Likewise, suppose that a developer has made a so-called “Privileges Table” with various fields that purport to control whether a user can do such things as create records. Using the Apple Event Set Data command, an Attacker could likely change the values in these fields if they do not enjoy additional protection.  More likely even, the Attacker could simply issue a Make New Record command and create the record.  That is a process frequently used to thwart developer-imposed limitations on the number of records in a demonstration version of a vertical market solution.

So, what can be done to manage this situation and to prevent these type attacks?  In FileMaker® Pro 15, FileMaker, Inc. added a new Extended Privilege option in the Privilege Set called fmscriptdisabled.  Developers must explicitly invoke this option; it is not a default option.  What it does is to prevent Apple Events (Macintosh OS) and ActiveX commands (Windows OS) from activating scripts, just as the name implies.  It has no impact on FMPURL or on other Apple Event commands that do not involve triggering of scripts.

Some of the other items in a Privilege Set, notably Export and data layer modification elements, can control Get Data and Set Data Apple Events.  If Export is disabled, then Get Data will not return data from the selected field. In tables where the editing privileges are restricted, likewise, Set Data will not add data to a field.  Creation and deletion privileges behave in similar fashion. Remember, we are talking here only about Apple Events.  Other processes may behave differently. Controlling API behavior is important; however, it is not the only security feature that developers must invoke to assure Confidentiality, Availability, and Integrity of their database systems.

So, clearly what we need here is a way to block these API from interacting with FileMaker Pro files. FileMaker, Inc. is aware of these issues and has been working on new ways to address them. In the Product Road Map Webinar presented on November 30^th 2016, FileMaker, Inc. noted that the next version of the FileMaker Platform will contain a number of additional security enhancements. I am authorized to say that one of those enhancements will be a new process for more closely and granularly controlling several of these API’s.

At such time as there is any new version of the FileMaker Platform, I will have additional comments and analyses of the issues related to these API’s.

I am very excited about the advent today of FileMaker Cloud. It is an excellent addition to the overall FileMaker Platform. Even in Version 1.0 we can see major benefits and uses for FileMaker Cloud. Over time and in succeeding versions, I believe these will get even better.

It is scalable, both up and down. It can meet rapidly changing needs for infrastructure to support FileMaker-based business management systems.

It is secure. Your files are encrypted. And data in transit are also encrypted. This is important to preserve the Confidentiality, Integrity, Availability, and Resilience of your FileMaker business management systems.

It is part of the FileMaker Platform. Users can connect to its hosted files with FileMaker Pro, FileMaker GO, and WebDirect™ clients.

It requires minimal administrative attention once established. And while no system can ever be a fire-and-forget structure, FileMaker Cloud offers ease of management. Amazon Web Services handles the heavy lifting.

FileMaker Cloud introduces the industry-standard oAuth2 process to the FileMaker Platform. That process allows new options for Identity and Access Management. In Version 1.0 that is confined to credentials for managing the newly revamped FileMaker Server Admin Console. This will work with an administrator’s regular Amazon Account.

Such federated identity management support might possibly in the future allow developers to utilize other authentication platforms to validate user credentials. Then those other platforms could pass that validation to FileMaker Server and admit the user to specific files. And with correct file privileges to boot!

I want to congratulate FileMaker, Inc. and its Engineering, SQA, and Product Management Teams on this initial foray into the Cloud. I look forward to future enhancements to FileMaker Cloud.

Steven H. Blackwell

Protecting FileMaker Platform Business Solutions

FileMaker Platform developers and FileMaker Server Administrators, as well as business data owners, need to take a variety of steps to protect the Confidentiality, Integrity, Availability, and Resilience (CIAR) of their FileMaker Platform Business Solutions. Threat Agents of many varieties seek to exploit vulnerabilities that might exist in those solutions to compromise them, to steal data, to alter data, or to destroy data.

This FileMaker Security BLOG article will describe four key steps that developers and administrators can take to protect their files. Before listing those however, I want to describe an important caveat about such an approach to FileMaker platform security.

Security is never a case of “One and Done.” It is not a check list of things to do to files, and then they are and will remain secure. Business circumstances change.  We discover new vulnerabilities. Threat Agents perfect new attacks, some possibly exploiting so-called Zero Day vulnerabilities. Security is an on-going process in a constant state of flux. Maintaining security for business solutions requires constant monitoring and evaluation. All that said, however, here are four important considerations.  All employ tools that the FileMaker platform already gives us to help protect our files.

First. Use Granular Access Privileges. The FileMaker security schema allows for very specific privileges as well as for very broad ones.  For best protection and control, set the privileges and permissions for each Privilege Set very carefully.  For each business role, give the users in that role all the privileges they need for them to accomplish their business requirements.  But do not give them any added privileges.  This is called the Rule of Least Privileges, and it is fundamental to having correct security for your files.

This process may take a bit of work, and it requires you to know and to understand what users are supposed to be doing—and not doing—in the file. To do this you also need to know what permissions are on and which are off by default in each Privilege Set. When a developer creates a new Privilege Set in a file, most privileges bits are off or at their most restrictive settings by default. This is a correct and is a consistent behavior with the Rule of Lest privileges. One of the things a developer wants to achieve in working with the security schema is to prevent an otherwise authorized user from escalating his or her privileges and gaining a level of access above the prescribed one.

To that end, developers should most likely avoid in almost all situations the use of the two default subordinate level Privilege Sets: [Data Entry Only] and [Read-Only Access]. Both these contain privileges in excess of what their names suggest.  If you plan to use them, carefully review the actual privileges they grant to see if those are consistent with your security model.

Second. Invoke Encryption at Rest (EAR) on your files. This is a particularly important step; likewise, EAR offers particularly good protection, provided you use a strong encryption password.  FileMaker Pro will tell you the strength of the password: Weak, Moderate, or Strong. If someone gains access to a copy of your files by any of several attack vectors, EAR prevents their forcing the file open or employing any of the so-called “password crackers” on them.  Unauthorized possession of copies of files, including backup copies, is a particularly strong attack vector.  It is also an attack vector that Threat Agents frequently employ.

Third. Use File Access Protection to block manipulation of your files by other FileMaker Pro files you do not control. File Access Protection prevents unauthorized persons from pointing their files at yours and extracting, viewing, or manipulating information. 

An important part of effective file protection is understanding how external Application Program Interfaces (API’s) can access your FileMaker Pro business solutions and then how to control that access. This includes layout access, file metadata, and the business logic found in scripts. [You can read more about this topic here:  http://fmforums.com/blogs/entry/1535-the-filemaker-platform-api’s-are-your-friends-right/]

Some of these elements respond to fine-grain permission controls in the Privilege Set.  Others do not; hence, developers should utilize File Access Protection. Additionally it can assist in preventing users who are otherwise authorized a particular level of permissions from escalating those permissions and privileges in the file.  Escalation of privileges is a key vulnerability we must try to prevent in all instances. 

Fourth. Utilize Encryption in Transit to protect you data while they are in motion between FileMaker Server and a variety of FileMaker Platform clients such as WebDirect™, FileMaker GO, and FileMaker Pro. This is particularly important when users are accessing FileMaker Platform Business Solutions by public Wi-Fi networks such as those found in coffee shops, hotels, conference centers, malls, airports, and similar venues. For that matter it is also important when the only access is across a Local Area Network (LAN) behind a closed firewall.  Just one single rogue wireless access point on that LAN can compromise it.  Additionally anyone with access to the LAN could also intercept data in transit. Encryption in Transit also helps verify the identity of the FileMaker Server and helps prevent man-in-the-middle attacks where a Threat Agent could impersonate your FileMaker Server.

I have described four FileMaker Platform security tools that developers and administrators can use to protect FileMaker Platform business solutions:

Granular Access Privileges

Encryption at Rest

File Access Protection

Encryption in Transit

I have attached a schematic that can serve as a reminder about these features. Remember when using these, that security is dynamic and on-going.  It is never a “One and Done” scenario. The FileMaker Platform provides these tools. A number of people have done a very considerable amount of work over the years to add these to the FileMaker Platform. I strongly recommend their use.

Phishing Attacks on FileMaker Platform Files

Recently I made reference in several venues to an article that described a sophisticated and interesting exploit to steal iOS credentials from a stolen Apple iPhone.  You can read the full article here:

https://hackernoon.com/this-is-what-apple-should-tell-you-when-you-lose-your-iphone-8f07cf73cf82

The core element of the article was that when the owner discovered the theft that he activated “…all the ‘send me email when the phone returns online’ checkboxes….”  Some eleven days later, the owner received an email and a SMS that the phone had been found. All the owner needed to do was to log-in to iCloud to see the location where the phone was.

The only problem was that the message was a spoof of iCloud.  It was a classic phishing attack designed to capture the owner’s credentials.

This episode brought back to mind an example of a similar style ruse that an attacker could possibly perpetrate against a FileMaker Pro file. I showed a brief example of this during my presentation at the 2015 DevCon.

In such an attack a Threat Agent might trick a user into believing that he or she had entered credentials incorrectly, most likely due to a mistyping.  Such so-called “fat-finger” errors occur all the time. FileMaker Pro presents the user with a dialog box advising of the error, and it asks the user to please try again.

The user then clicks the OK button and enters the credentials again. This time, the credentials work, and the user proceeds to go about his or her business in the file.

But there was no credentials failure the first time around.  The user had entered the correct credentials. One of these dialogs is real; the other is not, and it is the beginning of a phishing attack. The purpose is to trick the user into entering the credentials a second time, so that they may be captured in clear text and later used for nefarious purposes.

That subsequent credentials entry box as shown below is a bit harder to spoof than is the error message.  But when an Attacker can do that, this exploit likely will trick many users and possibly even some developers. Remember, it does not have to be perfect.  It only has to be good enough to trick the user.

This is but another reason developers and FileMaker Server Administrators must carefully review their systems to be sure that no vectors are open that could facilitate such an attack. Here are some such vectors:

• Guest Account enabled and attached to the [Full Access] Privilege Set
• A [Full Access] Account with no password
• A [Full Access] Account with the password stored using the File Options “Log In Using” feature.

By default, FileMaker® Server 15 will not open such files for hosting. Administrators can authorize the hosting of such files by unchecking an option in the Server Admin Console.  I strongly recommend that they not do so. Additionally, earlier versions of FileMaker Server will host such files automatically.  Carefully audit those server for the presence of such files.

Steven H. Blackwell

Edit Records Privileges

I have heard reports recently about some confusion regarding the behavior of the Edit Records privileges.  These privileges are set in the Privilege Set Custom Privileges area; they are part of the Record Level Access (RLA) privileges for a specific table.

Record editing privileges can be set to Yes, No, or Limited. Developers select these options from the drop-down menu under the Edit area in Custom privileges in the Privilege Set. What happens to a user’s privileges and when it happens depend on which setting a developer chooses.

Obviously the Yes setting means that the user can edit records. This is a common setting.  Developers might reasonably assume that a No setting means a user cannot edit records in the designated table. That is a correct assumption insofar as it goes; the issue is that it does not take effect until the session where the user created the record is ended.  This means that a user can create new records, and even after the user commits those records by any of several means, he or she can continue to edit them.  This persists until the session ends, usually the result of exiting FileMaker Pro.

In order for the restrictions on editing to take effect immediately upon committal of the record, developers must select the Limited option. That option is usually employed for invoking the privilege under differing conditions.  A common example would be that a user could delete only his or her own records. Another example would be to block deleting records that the user created before a certain date compared to the current date.

In this instance however, developers can simply select the Limited option and in the calculation dialog that option presents, enter a value of 0.  Thereby, once a user creates a record and commits it, the user can no longer edit the record. Committals can occur in numerous ways.  So, in this instance, it might be a good idea for the user to deselect the Layout option automatically to save records.

The following screen shots illustrate these items.

I hope that this explanation clears up any confusion and uncertainty about the behavior of the Edit Records privilege in FileMaker Pro. 

Steven H. Blackwell
Platinum Member Emeritus, FileMaker Business Alliance

The release of Version 15 of the FileMaker Platform brings with it a number of new security features, both in FileMaker® Server 15 and in FileMaker® Pro 15.  FileMaker® Pro 15 Advanced also has one notable security enhancement.

I have attached to this BLOG post a new White Paper that details and explains a number of these new features as well as offers some recommendations for their effective use. First however, we should take note that in the past several releases that FileMaker, Inc. has become more conscious about security issues and about equipping all the products with more features to enhance the Confidentiality, Integrity, Availability, and Resilience (CIAR) of FileMaker Platform solutions and their deployments. This is a highly welcomed development.

http://fmforums.com/files/file/79-new-security-features-version-15/

Steven H. Blackwell

The FileMaker Platform API’s Are Your Friends, Right?

The FileMaker Platform supports integration with a variety of Application Programming Interfaces (API’s), and it has done so for a very long time. These API’s allow FileMaker Platform developers to integrate their solutions with other technologies and applications. This is an incredibly useful capability; indeed, from both technological and business-process standpoints, it is essential.

Many FileMaker developers are not aware, however, that these API’s have the capability to access customer or client solutions in unexpected ways and to extract or insert data, to manipulate business processes developers embedded into these solutions, and to compromise the integrity of these solutions.  Correctly configured and appropriately granular Privilege Sets can control many of these behaviors. But developers must first understand what those behaviors are and then how to control them.

This FileMaker Security BLOG entry will identify a number of these API’s, will describe their use as attack vectors, and will point out some specific issues with several of the API’s. My hope and intent is to equip FileMaker Platform developers with the knowledge necessary to recognize these issues and to address them.

The FileMaker Platform utilizes a number of API’s:

• Apple Events
• Active X
• WebDirect™
• XML
• PHP
• Execute SQL
• xdbc (ODBC and JDBC)
• Plug-Ins
• FMPURL
• FileMaker Pro External File References and Data Sources

Many developers may be surprised by my including the FileMaker Pro application itself in the list of API’s. Yet, through use of its powerful capabilities to access data in other files and to trigger business-level processes such as scripts, the application is, in fact, an API to itself. This has significant impact from the security standpoint when the capability is misused and when one FileMaker Pro file functions as an attack vector on another FileMaker Pro file.

There are five significant actions an external API can undertake to perform on a FileMaker Pro file.  Not every API can perform all these tasks; however, each can perform at least one of them. What are those actions?

• Read and extract data
• Write data
• Read and extract metadata
• Manipulate the User Interface
• Trigger FileMaker Scripts

What are some of the types of attacks these API’s can facilitate?  And, more importantly, how can developers ameliorate the adverse impact of such attacks and perhaps prevent them in the first instance?

One category of attack centers on manipulation of the User Interface to send the attacker to a layout in the file the developer never intended to have exposed.  This is one of the inherent dangers that so-called “Developer” layouts present.  Unless a layout enjoys access protection in the Privilege Set attached to the active Account, the Attacker can navigate to it and observe anything shown on it.

Another category of attack deals with reading and extracting data from a table.  Some API’s can perform this task and even write out the data to another application such as Excel or Microsoft Word. In other instances, an attack can cause an export of data from a file.

Still another category of attack involves the triggering of scripts in a manner developers did not anticipate or intend. Generally speaking, if a script is either modifiable or (more commonly) executable to the active Account’s Privilege Set, then the Attacker can invoke the script. Developers must carefully consider the conditions under which a script runs. Scripts that re-log into the solution with elevated privileges without a credentials challenge are especially attractive targets for attackers. The script does not have to appear in the Scripts menu or be attached to an object on a layout to be vulnerable to such an attack. Its mere existence in the file in an unprotected state is sufficient to render it vulnerable.

Some API’s can extract metadata from a file.  Some metadata, such as a list of items in a value list, might also reveal data at the table level. Additionally, the metadata item might be a list of the Layout names in a file.  An attacker could use this information to attempt navigation to a particular layout such as the “Developer” layout previously mentioned. Similarly, metadata might reveal a list of Script names; this could facilitate an attack on a selected script.

There are three API’s that cause particular concern because of their breadth and relative ease of use.  These three are Apple Events, the FMPURL process, and FileMaker Pro files themselves.

The Apple Events Suite has an extensive set of commands that can read and write data, read metadata, manipulate the UI, and trigger scripts. In addition, they can work outside the normal constraints found on layouts in a file. http://thefmkb.com/5671

The FMPURL process (that is described at https://www.filemaker.com/help/14/fmp/en/html/sharing_data.17.6.html can open a file and run a script in it.  If the file is already open, then the script will still run.

A FileMaker Pro file can also read and write data in another FileMaker Pro file.  That is a commonly used process.  But such files can also run scripts, manipulate the UI, extract data, and extract metadata from other files.  If the target files are not protected, they are vulnerable to these type actions. This is a more subtle process than might first be observed.  A number of Privilege Set bits apply only to the file in which they are defined; they may work differently when called externally from another FileMaker Pro file.

So, how can a FileMaker Platform developer address these issues and protect a FileMaker Platform solution?  There are several key steps developers should take:

Invoke File Access Protection.  This prevents unauthorized references by external rogue files an attacker might create. FileMaker, Inc. introduced this feature to the Platform in version 11. At that time I authored a White Paper fully describing this feature. The White Paper can be found at the following location: http://www.fmpug.com/resources/security_schema_changes_filemaker_11

Tightly define Privilege Sets so as to block access to elements that need protecting. Items marked as «No Access» do not respond to External API calls as a general rule.

Take steps to prevent automatic access to files without credentials. In most instances developers should prevent auto-opening of files, especially at higher levels of privilege.  Once opened, such files can become vulnerable to attacks using the API’s. They can also be used to attack other FileMaker Pro files. I discussed some aspects of this two years ago in a post on this BLOG 

Do not enable any API’s not needed in a file. This includes such items as XML, PHP, and xdbc.  Strictly speaking, WebDirect™ perhaps is not actually an API; however, developers should not enable it either if it is not needed.

In this BLOG post, I have enumerated a number of FileMaker Platform External API’s and described how a Threat Agent (Attacker) might use them as a vector to compromise FileMaker Platform solutions.  I have also enumerated some specific attacks.  And I have provided several recommendations for protecting the files and lessening the likelihood of a successful attack.

Steven H. Blackwell

Hacking Your Own FileMaker Platform Solutions

Should FileMaker Platform developers mount hacking attacks on their own solutions? At first glance, this may seem an odd question. But I believe that the answer is “Yes, we should.”

Consider this. As developers we see our solutions from a totally different perspective than Threat Agents see them. Without practicing our own hacking skills, we can become blind to the vulnerabilities a Threat Agent can exploit to compromise the Confidentiality, Integrity, Availability, and Resilience (CIAR) of our deployed solutions.

I have previously observed that we need to “Think as the Attacker thinks, not as the Developer thinks.” It will be the strength of the Defender, much more so than the strength of the Attacker, that determines the outcome of a breach of any of our systems.

What are some of the vulnerabilities a Threat Agent (i.e. an Attacker) might exploit to compromise our systems?  What have we done to close those vulnerabilities and to mitigate the level of severity of impact of CIAR compromises when a breach occurs? There are a number of attack vectors to consider:

1. If the File Access Protection option is off, then an attacker with even lower-level privileges in the targeted file may be able to print, export, view, edit, and otherwise manipulate data in the hosted solution totally outside many of the constraints that the developer has utilized.  The attacker may also be able to run scripts in the file, even if they are not attached to User Interface elements or present in the Scripts menu.  The attacker may also me able to navigate to layouts in an unexpected and unauthorized fashion. And the Attacker can extract a significant amount of metadata from the file. 
   
   Are the files open to access by other, rogue FileMaker Pro files? The File Access Protection feature found in the Manage Security area of the file is designed to inhibit this behavior. But the developer must explicitly invoke that option.  When it is in force, an Attacker must know a [Full Access] level password in order to define External Data Source references to our file.
    
2. What about the External API’s that work in the FileMaker Platform? Have you, as the developer, considered how these might provide unauthorized and unexpected access to your files?  Some of these can be disabled via the Privilege Set bits. Examples of these include XML, PHP, ODBC, and JDBC. A Threat Agent could manipulate these and others to gain access to data and to view or to change them. An Attacker could also possibly use these to trigger scripts in an unexpected fashion.
   
   Other API’s are harder to control, and an attacker can use them to gain access to data, to gain access to metadata, to trigger scripts, and to manipulate the User Interface and traverse among various layouts. These, to varying degrees, include Apple Events, ActiveX, FMPURL, and ExecuteSQL. Developers can control much of this behavior through the use of very finely-grained Privilege Sets. And here is where the self-hacking aspect can play a particularly important role.  Try attacking your own files so you can spot the vulnerabilities a Threat Agent could employ using these API’s. I will have more to say about API’s in a future FileMaker Security BLOG post.
    
3. If a Threat Agent can gain access to a physical copy of your file, then the Agent can mount additional attacks against it. Have you tested for this?  Use of Encryption At Rest (EAR) and removal of the [Full Access] Privilege Set and Accounts with the Developer Tool can help mitigate these type attacks. EAR is particularly effective, since even lower-level access can furnish multiple opportunities for compromise of CIAR.
    
4. How easy is it for a Threat Agent to discover your FileMaker Server? In many instances, organizations need to make their servers available for access via the public Internet. The presumption should be that an Attacker can discover all such servers.  Sometimes this is as easy and as direct as entering the organization’s domain name into the hosts directory of Open Remote.  For example, www.somebody.com will frequently resolve to the public IP address of the server.  If administrators have not enabled File Access Filtering, then FileMaker Pro will display a list of available files.  If, in turn, a Threat Agent can access any of these, mischief can ensue. 
   
   Alternatively, through a process known as “Google-Dorking” attackers may discover enough information about a server to be able to attempt access.  So, the question is whether you, as the developer or administrator, have investigated how easy it might be to locate your server in any of these ways. It may be necessary to require authentication to access the Local Area Network by use of some process such as a VPN or two-factor authentication to protect these servers from outside access.
    
5. Finally, be sure that you and the FileMaker Server Administrator have implemented a vigorous and robust back-up regimen for your FileMaker Platform deployment.  Test that you can fully restore your system from these backups; otherwise, they are not worth too much at all. Given the rise and increasing frequency of ransom-ware attacks, this is particularly important.

Speaking recently about the MedStar Hospital ransom-ware attack  (http://wtop.com/local/2016/03/medstar-paralyzed-as-hackers-take-aim-at-another-us-hospital/) one of the Editors of the SANS Bulletin (a well-known information security news letter) noted:

Quote

 

This case again highlights the need for good disaster recovery plans. Organizations should be planning today for how they will deal  with ransom-ware and other destructive attacks - these are no longer black swan events.

 

These type activities have also prompted warnings by the US and Canadian governments about ransom-ware and the need to maintain continuity of business operations in light of the threats such attacks pose.  (http://www.computerweekly.com/news/450280335/US-and-Canada-issue-joint-alert-on-ransomware)

So, Yes, do hack your own FileMaker Platform deployments.

Steven H. Blackwell

Aligning FileMaker Security Requirements To Business Interests

March 29^th 2016

There has been a considerable amount of discussion recently in various FileMaker Platform venues about database security.  Much of the discussion has focused on the use of one technique or another, and most of those techniques actually detract from the security of FileMaker systems rather than enhance security.

Absent from these discussions, however, has been any description of first instance reasons for having security features in place in the FileMaker Platform. This BLOG entry will discuss the relationship between business interests and security requirements. Developers and administrators must assure that they have properly aligned security requirements with business interests. Generally speaking, we are seeking to assure the Confidentiality, Integrity, Availability, and Resilience (CIAR) of digital assets and supporting physical assets in the organization.

First and foremost, businesses and organizations of most every type have an interest in business continuity.  That is, they have an interest in remaining in business, and in being able to continue to function to perform their missions, all in the face of some natural or man-made interruption.  That includes cyber-attacks of varying types; but, such attacks are not the only potential interruption that can cause an organization to cease operations, either temporarily or permanently.

Physical damage to IT technology hardware whether by cyber-attack, flood, fire, tornado, building collapse, or similar disaster is one likely cause of business interruption and continuity failure. So is a new phenomenon:  the ransom-ware attack.  These attacks encrypt the entire data infrastructure of an organization with the attackers demanding a ransom to decrypt the data and release the underlying information back to the organization.

Business continuity can also fail as the result of the loss of customer or client confidence in the organization resulting from a data breach or data exfiltration. Additionally, if attackers were to damage or to delete significant portions of the organization’s data, the organization may not be able to continue in operation.

All these business continuity imperatives argue strongly for robust steps to preserve CIAR and to allow the organization to continue to function post-attack or post-disaster.

Regulatory compliance requirements related to data privacy and avoidance of the associated penalties for non-compliance are another key business interest for most organizations.  At international, national, and state levels, there are a variety of statutory and regulatory requirements for safeguarding data against breaches, for notifying affected individuals of breaches, and for post-breach monitoring and management. An organization’s compliance failure can subject it to civil and criminal penalties, including substantial fines. Clearly, any organization, irrespective of structure or mission, wants to avoid these potential penalties.

Organization brand reputation is another key business requirement needing safeguarding. The negative publicity that follows in the wake of a breach as well as the impact and burden of remediation for those whose data are compromised can seriously, if not permanently, tarnish the reputation that an organization has often worked years to achieve. Lost of customer or client confidence, loss of members’ confidence for professional and trade associations, and degradation of analyst and media opinion can all rapidly sink any organization.

Many FileMaker Platform customers and clients are small to medium-size businesses.  They frequently have fewer resources to combat the after-effects of CIAR loss. They are the ones most likely to suffer failure of business continuity and to be driven out of business by severe attacks. Larger businesses can also experience negative effects as well; however, they may have more resources to be able to continue to function.

These are some of the business interest reasons for safeguarding FileMaker Platform systems.  They are the underlying primary reasons for designing and implementing robust CIAR security in FileMaker systems.  These are not the only reasons of course.  There can be others, notably protection of developer intellectual property. But the concepts of business continuity, regulatory compliance, and avoidance of civil liability are core reasons that drive security requirements.

Steven H. Blackwell

Emerging Trends in Information Security Affect FileMaker Platform

By Steven H. Blackwell

March 17^th 2016

The recently concluded annual RSA Security Conference showcased a number of important emerging trends in Information Security that likely will affect FileMaker Platform developers and Administrators of FileMaker Platform systems. In this BLOG entry, I will describe some of these and offer some observations about how they might apply to the FileMaker Platform.

Multi-Factor Authentication (MFA) will increasingly become a standard requirement for Identity and Access Management (I&AM) in organizations of all sizes. This is especially true for connectivity by mobile devices. And it especially true for data hosted in the Cloud. As we saw recently, efforts to create a “two-factor authentication” system inside of the FileMaker Pro client product did not work out well at all. (http://fmforums.com/blogs/blog/112-eye-on-filemaker/) A true MFA system will require coordinated integration with FileMaker Server, wherever that server resides.

The data are still the key asset.  Outer perimeter defenses, while important, are secondary to protecting the data from the inside out. The data are the asset we most seek to protect, wherever the data reside.  For the most part, they reside inside of the database itself. That’s why finely-grained Privilege Sets, strong I&AM, Encryption At Rest, and Encryption In Transit are all so important for FileMaker Platform deployments.

Insiders are the new malware.  And now, everyone is an Insider.  Whether by inadvertence, by curiosity, by carelessness, or by malicious intent, those persons inside organizations and inside organizational supply chains remain a principal threat vector for compromise of digital assets. Any number of major recent data breaches over the past year or so started in the organizational supply chain apparently.

Context-sensitive and content-sensitive conditional authentication of identity assertions will become more and more common.  What does this mean? A trusted insider accessing data from inside a corporate LAN may trigger one level of authentication requirement.  That same user when attempting access from outside the LAN may trigger multiple steps (factors) of authentication requirements.  Moreover, access to more sensitive data may require additional authentication factors. And when the context changes mid-session, additional authentication challenges may need to appear.  This again will require close integration with FileMaker Server.

The need for cyber-insurance will increase dramatically. To mitigate the liability associated with data breaches, more and more organizations of all sizes are going to need to acquire cyber-insurance. Premiums will continue to rise. Organizations of all types and sizes face liabilities such as damage to brand reputation, civil judgments in suits brought by persons whose data are compromised, business interruptions, and–dare I even say it—cyber-extortion. The underwriting process for this will require a more stringent adherence to a range of Best Practices by those seeking the insurance. Small and medium-sized businesses, a staple of the FileMaker community, are perhaps least well equipped to survive a major breach absent this insurance.

Regulatory attention to security breaches will increase at both the Federal and State levels. Additionally there will be concomitant increases in scrutiny about whether organizations have employed “reasonable” security practices.  What constitutes such practices is sometimes unclear; however, in any given instance, the list may be extensive. The California Attorney General’s Office recently noted that there were at least twenty specific items that any organization should presume to employ in order to meet the standard of “reasonable” security practices. (These are the Center for Internet Security’s Critical Security Controls.
https://www.cisecurity.org/critical-controls.cfm)

The Attorney General’s report notes that in 2015 approximately 60% of Californians were victims of a data breach of one sort or the other. And the data involved are often the most sensitive type information, including financial data and health-care records. California is often a leading-edge indicator for regulatory actions, and it is entirely to be expected that other states will follow suit here. (https://oag.ca.gov/breachreport2016)

So, where does this leave the FileMaker platform and the FileMaker Developer Community?

First, developers and administrators need to be sure they have properly aligned the security requirements of their systems to business requirements.  This includes such items as brand reputation, customer/client data privacy, civil liability protection, regulatory compliance (State and Federal and international as applicable), and business continuity.  I will be having much more to say about this is coming weeks.

Second, developers need to follow Best Practices for security in FileMaker Platform files. This includes granular Privilege Sets, Encryption at Rest, and File Access Protection.

Third, FileMaker Server Administrators also need to follow Best Practices for deployment, including appropriate OS for servers, a rigorous backup regimen including the tested ability to restore from backups, and Encryption in Transit.

Fourth, business unit managers at FileMaker Platform customers need training in Security Best Practices from the user standpoint.  Likewise, they should assure that their employees have a similar awareness.

Fifth and finally, but certainly not least, we need to encourage FileMaker, Inc. to continue to improve the security schema of the Platform, most particularly the introduction of Multi-Factor Authentication (MFA) and the introduction of additional controls over the behavior of various external API’s.  This includes Apple Events, Active X, Execute SQL, PHP, XML, FMPURL, and PlugIns.

Some Vulnerabilities Associated With Ersatz Log-On Systems

October 29^th 2015

My recent post [http://fmforums.com/blogs/entry/1410-new-paradigms-in-filemaker-platform-security/] on this BLOG about New Paradigms in FileMaker Platform Security has apparently occasioned a good deal of discussion in various FileMaker-related venues. Much of this reportedly has focused on the ersatz systems that I recommended be avoided. Many persons seem to have asserted that they use such systems for a variety of reasons.  And further, they proclaimed their belief that these systems were secure and immune to tampering.

Others have taken a different view, similar to my own, cautioning against the use of such systems.  Among the reasons they cited for that cautionary warning are unreliability of these systems and their susceptibility to tampering.

In this BLOG post, I am going to focus on some commonly-found characteristics of these ersatz systems and explore how an attacker might compromise them.

—Ersatz Systems—

Generally speaking these systems are directed towards one or both of two distinct processes: first, authentication; second, assignment of privileges in the database. The processes they employ usually start with an automated log-in to the system, usually at a self-described “low level of privileges.” What this actually means in terms of actual privileges remains to be seen on a case-by-case basis and varies among different systems.

Through the use of some process of identification of the user, a re-login occurs with an Account Name and Password unknown to the user and with a level of privileges attached to the unknown Account. That is to say, multiple users employ the same Account and Password to access the file; however, the individual user does not know either of the credentials’ items.

Furthermore, in some versions of these ersatz systems, privileges are also set by values in flag fields rather than through privilege bit elements in the Privilege Set.

—Compromising Ersatz Systems—

An attacker frequently can easily achieve a compromise of these ersatz systems, resulting in access at elevated levels of privilege. Unauthorized escalation of privileges is a common result of an attack. It is a circumstance we try to avoid wherever possible.

When a system automatically admits a user to the file without a challenge, two-thirds of the battle is already lost. The automatic initial log-on with the re-login by the unknown Account does just that.  The attacker is now in the file. As a result the attacker can now exploit any vulnerability not controlled by the developer.  And the developer likely cannot control every vulnerability. The attacker can now escalate his privileges, something (as mentioned) we try to prevent happening.

Even self-described low-level privileges associated with the automated log-on have certain capabilities. Otherwise, the ersatz system would not work. What are some of these capabilities and how might they be exploited?

First, the process that identifies the user and performs the re-login is in one of two different possible states.  It is either Paused or Not Paused depending on the scripted action that controls it.  If it is Paused, then the attacker can stop the Pause by any of several methods, most notably by external Application Program Interfaces (API’s). This means the attacker can cancel the paused state and return to a normal or unpaused state. The Allow User Abort [Off] functionality has no impact on this at all.  Pause can be stopped even if Allow User Abort is set to OFF.  Conversely, if the initial state of the process is Not Paused, the attacker can proceed to the next step.

Second, the attacker is now in the file and the file is in a normal state. The attacker can now activate the re-login process and gain privileges. Unless the re-login scripts are exceptionally well protected, the attacker can activate them by any of several different methods or a combination of methods:

         •External API’s

         •External references if the target file is not protected

•User Interface manipulation of the target file in some instances, depending on how the file is constructed.

What this means is that the re-logon process can be run without any reference whatsoever to the user’s name or other identifying information.  The attacker will now enjoy the privileges associated with the newly acquired Privilege Set. If the re-login process includes access to an Account with [Full Access] privileges, such as has been observed in a number of instances of these ersatz systems, then various serious consequences will ensue:

•Compromise of intellectual property

•Exfiltration of data

•Sabotage of data in the file surreptitiously or overtly

•Surreptitious extraction of [Full Access] Account name and password from the file. The amount of damage flowing from this can be exceptionally extensive, especially for widely-distributed commercial vertical market products.

•Surreptitious monitoring of file over time

—Flag Fields—

There is another set of circumstances that can happen associated with the flag fields that attempt to confer privileges.  If these are not exceptionally well-protected, the attacker can change their values, and thereby a low-level privilege coverts to a high-level privilege. Protection does not mean removing from the Layouts Menu the layouts where the flag fields might appear. Additionally, protection also does not mean keeping flag fields off of any layout whatsoever.

An attacker can manipulate the values in these flag fields by a variety of methods:

•External API’s

•External references if the target file is not protected

•UI manipulation of target file in some instances

We distinguish all of this from privileges the developer allows in the Privilege Sets in the file.  An attacker cannot manipulate such privileges in the same fashion as he could with the flag fields.

—Summary—

Avoid the use of ersatz log-on and privilege-granting systems. An attacker can interrupt and otherwise thwart the processes controlling the ersatz system. The attacker can manipulate data-based “privilege” flags and change their values. The attacker gains access and escalates privileges through these flawed processes. Ersatz systems detract from the real security a file needs.  Ersatz systems also impart a false sense of security about the files.  Use the tools FileMaker, Inc. gives you to protect the file.  Do not try to invent your own in almost any and every instance.

Steven H. Blackwell

ErsatzSystems.pdf

New Paradigms In FileMaker Platform Security

October 19th 2015

Traditionally, the framework for Information Security management has focused on activities designed to preserve the Confidentiality, Integrity, and Availability (CIA) of digital assets, and, on occasion, of physical IT infrastructure assets. That focus must now shift; in fact, it is already shifting.

By way of a brief review, CIA focuses on three elements:

         Confidentiality focuses on preventing unauthorized access to data and viewing of those data;

         Integrity focuses on assuring that data cannot be manipulated or altered by unauthorized processes; and,

         Availability focuses on assuring that data are present and ready for use, and not purposefully or inadvertently destroyed or otherwise made inaccessible.

When a breach occurs, it creates an adverse impact on the People, Assets, Operations, and Reputation of the organization that suffered the breach. There are four levels of adverse impact: Limited, Serious, Severe, and Catastrophic.

This traditional approach to Information Security concentrated a lot of attention on the physical infrastructure of networks, servers, files, firewalls, and similar items. The underlying theory here is that protecting the digital asset mandates blocking attackers from entering the network infrastructure. That is still a legitimate and valid concern and requirement.  But it is no longer sufficient just to block access.  We must now shift and expand our focus to other elements.

FileMaker developers and FileMaker Server Administrators have two core security missions now.  The first is to guard the data themselves at the data level; the second is to provide for Resilience of systems after they are attacked and likely are breached. So, in addition to the traditional–and still useful—CIA, we now have CIAR.

Ponemon Institute, the renown security analytics company, offers an excellent definition of Resilience as an organization’s:

“…capacity…to maintain…[its] core purpose and integrity in the face of cyberattacks.”

Such an approach presumes that cyberattacks directed towards FileMaker hosted systems will occur, and that such attacks likely will succeed. In the face of these attacks, organizations deploying the FileMaker Platform must be able to continue to operate at something highly resembling normal levels. They must also, as a condition precedent to that requirement, be able to have restored their system and quickly to have detected and recognized an attack when it first occurs.  An organization’s success in all these ventures will vary depending on the type and the severity of the breach and to an even greater extent on the level of its preparedness.

—Causes of Breaches in FileMaker Platform Systems—

There are four major causes of breaches in FileMaker Platform systems:

1.                              Vulnerabilities in the software.  FileMaker, Inc. works on these and reports fixes from time to time. See http://thefmkb.com/13585

2.                              Misconfiguration of the software, especially FileMaker Server, but the other products as well.

3.                              Failure by developers to use the security tools provided in the products, especially Encryption at Rest (EAR), File Access Protection, finely-grained Privilege Sets, Encryption in Transit, and strong passwords.

4.                              Invention by developers of their own artificial (ersatz) “security” systems.  These contrivances detract from actual security and weaken it.  This includes such practices as “scripted security” processes, artificial authentication systems, storage of passwords in data elements, use of On-Open scripts to enforce privilege management, equating User Interface elements with actual security, and similar practices.

—How To Promote Preservation of CIAR—

How then do we promote Confidentiality, Integrity, Availability, and Resilience of FileMaker Platform systems? Here are seven core elements we can use to promote CIAR.

1.                              Realize that when a cyberattack occurs, it is the Strength of the Defender, not the Strength of the Attacker, that likely will determine the outcome. These attacks will occur; breaches will ensue as a result. How an organization survives a breach, particularly a serious or greater level breach, will determine how, and whether, it is able to continue in operation.

2.                              Focus on the data; they are the critical element. We must try to protect the data at the data level so as to deny the Attacker the fruits of the attack. This includes the hosted files and all backup copies.

3.                              Employ Encryption at Rest (EAR) with a strong Encryption Password. The “strength-ometer” in FileMaker Pro Advanced provides a clue as to the strength of the Encryption Password. If an Attacker exfiltrates digital assets from the network or the server, strong encryption goes a long way to preserving the Confidentiality of these data.

4.                              Properly use the tools that FileMaker, Inc. has introduced into the Platform, as previously noted.  In addition to EAR, this includes File Access Protection and finely-grained Privilege Sets. The former inhibits and blocks unauthorized access from external files into the protected file.  The latter, the finely-grained Privilege Sets, control behavior of everything from the User Interface, to scripts, to value lists, to file meta-data.  Additionally it can inhibit, although not totally restrict, unauthorized access to a file from external API’s such as Apple Events, Active X, FMPURL, XML, and PHP.

5.                              Avoid ersatz contrivances.  I have, over the past 15 or so years, seen literally hundreds and hundreds of these systems. All have introduced vulnerabilities not otherwise present. All provide rich attack vectors to compromise all or part of FileMaker Pro files. And they also impart a false sense of security and confidence that the files have adequate protection.

6.                              Thoroughly understand at a deep, hands-on level how the entire Family of Products actually works when it comes to security behaviors. Understand the vulnerabilities present in the Platform. Understand what additional vulnerabilities you introduce by failing to use the tools provided.  Understand the vulnerabilities you also introduce by using artificial contrivances. Finally, follow Best Practices.  These are there for a reason.  Furthermore, they usually have become Best Practices because of some incident that led to the compromise of CIAR.

7.                              And finally, develop a Security Incident Response Plan. When the attack is underway, when the damage is already done, it is too late, and a particularly inopportune time, to try to craft a response. Think through these items in advance; try to develop specific scenarios for response.  These will not be perfect nor totally predictable.  As Admiral William F. Halsey remarked, “No battle plan survives its first encounter with the enemy fleet.”

There are consequences flowing from failures to preserve CIAR of FileMaker Platform systems. There are regulatory strictures and penalties particularly in the health care, financial services, and education markets. There can be criminal and civil liabilities for data breaches resulting in losses and exposures. Certainly there is damage to organizational reputation and damage to customer or client relationships.  And finally, there can be business stoppages caused by breaches and loses.

Confidentiality, Integrity, Availability, and Resilience of FileMaker Platform assets are important. Developers and Administrators can meet these requirements through judicious use of the tools FileMaker, Inc. provides, through a thorough and hands-on understanding of how the products work, and, through avoidance of artificial, ersatz “security” contrivances.

In the coming weeks and months and on into 2016, I will be exploring and reporting on these items related to CIAR.

Steven H. Blackwell

FileMaker 14 Platform Brings New Security Features

The newly released FileMaker 14 Platform contains a number of security enhancements, at least one of which has significant potential to strengthen Platform security and to close a significant vulnerability.

For many years users of FileMaker Pro on the Macintosh OS platform have been able to save database credentials in the Macintosh KeyChain.  And with the advent of Windows 7, FileMaker Pro users have also been able to save credentials in the Windows Credentials Manager. We should note that is separate and distinct from Single Sign-On capabilities managed by External Server Authentication and Active Directory on the Windows OS.

All of this is convenient.  However, it also presents a vulnerability, inasmuch as it allows anyone with access to a machine to access the hosted databases without having to know the proper credentials. It can also present unexpected results, because such stored credentials take precedence over any a user might enter manually.  If database passwords are changed, then the stored credentials are no longer correct.  This causes error messages to appear, often to the confusion of the users and server administrators alike.

In FileMaker® Pro 14, developers can block the ability to store credentials and to use ones previously stored. This is done at the file level in the File Options pane as shown below.  By default the option to store credentials is blocked for newly created files in FileMaker Pro 14.  For files initially built in earlier versions and then converted to version 14, the option is enabled by default.  Developers must disable the ability to store credentials for files converted from earlier versions. This is a subtle distinction, but an important one.  Developers should note this difference in behavior.

Another new feature is the introduction in several places in FileMaker Pro 14, and in FileMaker® Server 14 as well, of password strength meters.  These meters are similar to the one already found in FileMaker® Pro 13 Advanced for the encryption password. The meter will tell the developer whether the selected password is Weak, Moderate, or Strong.  Strong passwords are the most secure.

What constitutes a strong password? Generally in the FileMaker developer community there is a belief that longer passwords are more secure than shorter ones.  This is not a correct belief.  Length is an important attribute of password strength.  However, it is not the only consideration.  Complexity is another attribute, as is entropy. Complexity refers to the alphanumeric mix of characters in a password or passphrase.  Entropy refers to the degree of uncertainty of a random variable that the password or passphrase exhibits.

Consider these examples:   

Maryhadalittlelambitsfleecewaswhiteassnow is a 41 character passphrase. $$todonuts4meanddonutsto$foryou is a 32 character passphrase.  However, the first one registers as Weak. The second one registers as Strong.

Another new security feature relates to the use of SSL for progressive downloading of container field contents in hosted files. In earlier versions, even if SSL for encryption of data in transit were invoked, contents of container fields were not encrypted in progressive downloads.  FileMaker Server 14 now allows for the use of SSL for such downloads.  This requires a custom SSL certificate; developers and server administrators configure this option in the Server Admin Console as shown below.

Another new security feature involves a change in the User Interface options for configuring security settings in files.  In addition to the previously existing system, that remains fully in place in the new version, there is also a new, abbreviated version targeted at new users and at others not familiar with the legacy structure.  The new system allows creation of Accounts and Passwords and linking to Privileges. The name of the new User Interface is Basic Security. The previously existing, legacy system has been renamed to Detailed Security.

Finally, there has been a significant change in the FileMaker Server Sample File from the one available in earlier versions.  Prior to FileMaker® Server 14, the Server Sample File had been a completely open file that opened by default to the [Full Access] Privilege Set. This behavior introduced a significant security vulnerability onto installations of FileMaker Server.  I discussed that vulnerability in the BLOG post found here: http://fmforums.com/blogs/entry/777-protect-your-filemaker-server-and-files-from-a-vulnerability/

I am pleased that in FileMaker Server 14, this vulnerability insofar as it relates to the Sample File has been closed. When the Sample File opens now, it is with a restricted set of privileges.

The recent cyber attack on Sony Pictures serves as a new, additional, and very loud wake-up call for businesses all over the world about the need to protect digital assets. Organizations who use the FileMaker Platform to manage their businesses and whose databases contain proprietary and sensitive information, business process control methods, or financial data especially need to be diligent about data protection. If you are a small business, an education institution, a not-for-profit organization—all typical FileMaker Platform customers—you are just as much at risk as are large multi-national organizations, perhaps even more so than they are.

As I have noted before, FileMaker Platform deployed files are susceptible to one or more of six distinct types of attacks that target one or more of seven distinct types of vulnerabilities. Fortunately FileMaker Pro and FileMaker Server both give developers the tools to close or to narrow dramatically these vulnerabilities. These attacks can destroy data or alter them in a subtle fashion, often a much more difficult situation to recognize initially or even at all. They can also extract data from the files.

Here are a number of specific actions FileMaker developers can take to protect their clients’ files as well as their own.

1. Review with you clients the likely threats to their digital assets and how serious the negative impact of a breach would be to their operations, people, and reputation. If you don’t know how to do this, I can help you.
   
2. Use strong passwords on all files. Such passwords are typically twelve or more alphanumeric or high ASCII characters. Whether internal to the database file or externally located on the server or on the domain controller, such passwords are much less prone to brute-force attacks or to guessing.
   
3. For the Account name for a set of credentials, avoid the use of the default name Admin.
   
4. Remove the FileMaker Server Sample file. Alternatively, give it a new Account name and strong password and remove the auto log-in option.
   
5. Avoid having files set to log-in automatically, even to supposed lower level privileges. Unless you have done an exceptionally thorough job of restricting privileges for such an auto log-in Account, your files are vulnerable to manipulation and compromise. Moreover, use of so-called “Account Management” modules can exacerbate such vulnerabilities.
   
6. Invoke File Access Protection on your files. This is one of the most important protections you can provide to the files.
   
7. Encrypt the file using the new Encryption at Rest feature of FileMaker® Pro 13.
   
8. Encrypt data traveling to and from FileMaker Server by selecting the encryption option in the Admin Console.
   
9. Be aware that User Interface elements such as Custom Menus, “hidden” layouts, and other such items are not part of the Security Schema. Just because a field is on a layout to which the Privilege Set attached to the active Account lacks access, does not mean the contents of that field cannot be changed, deleted, or viewed. Just because a field never appears on any layout does not mean its contents can be read or changed.
   
10. There are numerous ways to invoke scripts even if they do not appear in the Scripts menu or are not attached to buttons on a layout. Be sure you understand the implications to the business processes and business logic of your database if a Threat Agent (attacker) invokes a script in unexpected ways.
    
11. Carefully construct granular-level Privilege Sets to help protect both the data and the structure in your database system. Protect the values used in Record Level Access tests from manipulation or change by an attacker.
    
12. Be sure you understand how the so-called “Other Privileges” items in the Privilege Set definitions actually work. This is particularly true for the Print and Export privilege bits. You might believe that blocking one of these privileges in a file is sufficient to protect the data. That is not necessarily the case.
    
    
    Steven H. Blackwell
    Platinum Member Emeritus
    FileMaker Business Alliance
    

Over the past dozen years, I have discussed in a number of venues the necessity for robust security practices and the techniques needed to implement them on the FileMaker Platform. Such discussions have as their underlying framework a fairly traditional Information Security paradigm.

There are Threat Agents who seek to initiate Exploits or Threats that negatively Impact the Confidentiality, Integrity, and Availability of FileMaker Platform systems or other Digital Assets. These attacks also can damage the Resilience of the Digital Asset. These Threat Agents exploit a Vulnerability in the design or the deployment of the FileMaker systems. FileMaker Platform developers and FileMaker Server Administrators must assess the Risk that a Threat Agent will use a Vulnerability to trigger an Exploit that attacks the FileMaker Platform system.

I have learned that developers, after some examination of this concept, do understand it. And I have also learned is this: In many instances, developers do not see how these circumstances impact them. They do not connect the Information Security Paradigm model with their on-the-ground implementation of solutions built on the FileMaker Platform. That is what I intend to address in this paper.

I am going to describe some exploits and threats that target commonly-found vulnerabilities. And I will explain how to close those vulnerabilities. There are six significant and common exploits that can be run against FileMaker Platform systems. Each takes advantage of one or more of seven vulnerabilities to compromise Confidentiality, Integrity, or Availability or to damage Resilience of the system and its data. Each can be easy to trigger, and each can do significant damage.

Read more here:

http://www.fmpug.com/resources/exploit-based-approach-to-filemaker-security

I have recently learned that there may be any number of FileMaker Server installations world-wide that are hosting files that open automatically without credentials challenge to the [Full Access] Privilege Set. The default-installed FileMaker Server Sample File is one of these; however, there are others.

This is not such a good practice. Such files offer an attractive attack vector that a Threat Agent can use to inflict damage on the FileMaker Server machine or on its hosted files. If a Threat Agent can locate the server and access it, an attack can occur using these files.

Most attacks occur when a Threat Agent utilizes some vulnerability to mount an exploit that has some negative impact on the Confidentiality, Integrity, or Availability (CIA) of a digital asset such as a FileMaker Pro database. To that we must now add that the exploit can adversely impact the Resilience of the database system as well. We measure that negative impact of an attack along a continuum ranging from Limited to Serious to Severe to Catastrophic. In managing security in FileMaker database systems, we work to block Threat Agents, to close vulnerabilities, and to mitigate the negative impact of an attack.

I would therefore strongly recommend the following actions:

1. If you do not need the FileMaker Server Sample File, then remove it from your server. If you do need it, give it credentials or have it open to a restricted privilege level.
   
2. If you have other files that open without challenge to [Full Access] privileges, then change that process to require credentials or, at the least, to open to a restricted level of privileges.
   
3. Periodically review the FileMaker Server Access Log to see if it contains evidence of unusual or unexpected access to the server. Of course, for that to work, you must enable this log in the FileMaker Server Admin Console.
   

It is my view that in the FileMaker community we have a responsibility to one another to help each other maintain safe systems, to avoid and to prevent attacks, and to block Threat Agents. I will continue to advise the community of security-related items from time to time.

Steven H. Blackwell

On February 11^th FileMaker, Inc. presented two webinars on FileMaker Platform Security. I am highly gratified that FileMaker, Inc. did this. These webinars, conducted by Consulting Systems Engineer Rosemary Tietge, clearly laid out the case for following Best Practices for securing files and their data across all elements of the FileMaker Platform.

I want to expand on a number of recommendations about enhancing FileMaker file security from those webinars. By way of reminder from information in a previous FileMaker Security Blog post (http://fmforums.com/forum/blog/13/entry-600-assessing-threats-vulnerabilities-and-risks-to-filemaker-pro-databases/) our focus in security is to close vulnerabilities that a Threat Agent might employ to compromise the Confidentiality, Integrity, or Availability of the database. The webinars focused largely on closing some of those vulnerabilities.

First, developers secure their files against attacks by using the security features found across the platform, not by manipulating the User Interface or by adding their own contrivances.

Second, when creating a new file, developers should add a password to the [Full Access] Account FileMaker Pro automatically provides when creating a new file. Concurrently with this step, developers should remove the automatic log-in to the file using the default Account with the blank password. Failure to do so renders the file vulnerable to attack once it is hosted by FileMaker Server.

Third, there is this corollary to the point about the automatic log-in and default credentials. When developers or administrators deploy FileMaker Server, in many instances the sample file that comes with FileMaker Server is left on the server. Developers or administrators should remove this file with its automatic log-in unless there is some compelling need for it to remain. If it does remain, the Privilege Set of any automatic log-in should be a subordinate and restricted one. This file, if left unattended and unaltered, provides a direct attack vector to the FileMaker Server system. The webinars did not expressly address this item; however, it is a logical follow-on to the default credentials issue.

Fourth, developers should design a customized Privilege Set for each group of persons who will access the file and who will need to work in the file. Specific, individualized Accounts then link to this Privilege Set, and those Privilege Sets define the actions a user can and cannot take. Because FileMaker Pro follows the Rule of Least Privileges, as a general condition, the privilege bits for a given Privilege Set are turned off or set to their most restrictive level. Developers then must explicitly grant privileges for each Privilege Set. This helps assure a high level of security for the file.

Fifth, FileMaker® Pro 11 introduced a new security item: File Access Protection. Developers should control external file access to their solutions by employing the controls found in File Access Protection. This system establishes a mutual trust relationship among various files to prevent other, outside of the trust relationship, files from accessing data, schema, and other elements in a targeted file. Failure to employ this feature leaves a major vulnerability in a FileMaker Pro file.

Sixth, in conjunction with a file’s being hosted by FileMaker Server, developers and administrators should employ the Encryption In Transit feature of FileMaker Server to assure that data transferred between FileMaker Server and various clients, such as FileMaker GO and FileMaker Pro, are not susceptible to reading if intercepted.

Seventh, and new in FileMaker® Pro 13, developers should employ the Encryption At Rest feature to protect both the file and the data in it. FileMaker® Server 13 has the explicit capability to host such encrypted files and to provide seamless access to them from a variety of clients.

As a corollary to this item, the Encryption At Rest feature is no better nor any stronger than the Encryption Password a developer must create when encrypting the file. FileMaker® Pro 13 Advanced, required for this feature, will provide an analysis of Encryption Password strength, reporting Weak, Moderate, or Strong as a result. I emphatically urge the use of only Strong Encryption Passwords. Such level of strength is a result, not merely of length, but also of complexity and randomness. Thus, in some cases, a shorter Encryption Password may be stronger than a longer one. FileMaker Pro 13 Advanced will report the Encryption Password strength to you.

Finally, too often, in too many instances, developers believe they can enhance or refine the security schema and add various supposed “security features” to their files. This occurs both for vertical market solutions and for custom developed ones as well. In over two decades of working with elements of the FileMaker Platform, I can say that I have never encountered any of these enhancements that actually strengthened file security. In almost every instance, these “security features” detracted from file security, often by providing additional attack vectors into the file or into its data.

In coming weeks, I will be having a good deal more to say about these items and other issues related to FileMaker Platform security.

--

Steven H. Blackwell

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:





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.

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.

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.

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.

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.

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

From time to time people ask me why the Privilege Set bits in FileMaker Pro are all turned OFF by default. Would it not be easier and better for security purposes, the questions go, if all these were turned ON instead?

The answer is No; here is why. First, some history. Prior to the introduction of FileMaker® Pro 7 in March 2004, all of the privileges–as they then existed–were turned on by default. Developers then had to wade through a veritable sea of settings and options to limit access to their files. In the older versions of the products, a table and a file were more or less equivalent. A file could contain only one table. The modern versions of the products changed that. Files could contain multiple tables, and business rule mandates could require different privileges for each table.

As part of the products’ modernization, FileMaker, Inc. adopted a Role-Based Security model for all its privileges. The Privilege Set is where developers assign the rules a Role must follow. The Accounts then serve to identify the user and to authenticate and validate the user’s assertion of his or her identity. With two or three exceptions, some of which FileMaker, Inc. has subsequently modified to fit the original framework for the modern version, all Privileges were set to be OFF by default. Developers must explicitly authorize a specific Privilege for each Role.

A core principle of Information Security is the Rule of Least Privileges. That concept states that a user should have all the privileges necessary to fulfill his or her respective Role, but no additional privileges beyond those needed. A key effort FileMaker developers must make is to prevent escalation of privileges, a situation that results when a user assigned to a specific role can gain privileges to which he or she is not entitled. If a user can accomplish this, it can have unexpected and usually detrimental effect on the Confidentiality, Integrity, or Availability (CIA) of the data in the file. The preservation of CIA is the core reason underlying why we implement information security.

In older versions of FileMaker Pro, for example, when Record Level Access for viewing of data was put into effect, FileMaker Pro nevertheless downloaded all the records, whether a user was entitled to see them or not. The client-side application was left the task of sorting out which records to display. By employing a simple packet-sniffing tool, all the data could be viewed, irrespective of the user’s privileges. In the modern versions, however, such row level access (as it is formally known) occurs at the Server. Only the authorized records are returned to the client side.

Everything was turned ON is older versions of FileMaker. And turning them all OFF didn’t necessarily have the result a developer might expect. When it comes to being an “old-timer” in FileMaker, I am primus inter pares. Others of you who have been around for ten or more years may also remember that older process for Privileges. For the rest of you, accustomed only to the modern era security schema UI, here is what it used to look like in older versions.

The pop-up lists had two options: All or Limited. Now, contrast that with a newly created Privilege Set in FileMaker® Pro 12:

As you see, for the most part, every Privilege Bit is disabled, or it is set to its most restrictive option. The re-authentication for FileMaker GO is an exception, and that needs correcting in my view so that its default value is 0.

Requiring the developer explicitly to grant privileges for each Role in the database system is consistent with Information Security Best Practices. It provides for a high lever of granularity of control in granting privileges. It supports and enforces Role- Based Security. These are the reasons why the system works as it does. It was to further these goals and objectives that the system was changed almost ten years ago. The FileMaker Security Schema has evolved in the intervening time, including the addition of File Access Protection several years ago. It continues to evolve, and in the future we will hopefully see that process continue.

Steven H. Blackwell

Platinum Member Emeritus

FileMaker Business Alliance

FileMaker Security Survey Reveals Interest and Some Confusion

During early and mid-July, I posted on FM Forums a multi-question survey asking people about their use of various FileMaker product security features. I also asked for any comments or for any recommendations they might have for enhancing product security features.

The results are interesting. They reveal a high level of use of many security features; they also indicate some areas of confusion about how security features in FileMaker products work.

Who were the people who responded to the survey? Where were they located?

Respondents said they worked in a variety of different environments:



Respondents were primarily North American and European with a smaller number from other areas:



Security Features Respondents Utilize

One of the most important FileMaker security features is File Access Protection, introduced in FileMaker® Pro 11. This feature is vitally important for securing files and for preventing unauthorized external compromise of a database’s business logic and manipulation of the User Interface.

Respondents indicated considerable use and support for this feature:




Privilege Sets are the method by which FileMaker Pro enforces and supports Role Based Privileges in files. The level of granularity for Privilege Set construction is very fine and precise.

How did respondents to the survey utilize Privilege Sets?






External Server Authentication is another key tool for effective security management of FileMaker Pro solutions, especially for multi-file systems hosted by FileMaker Server. Easing of Account management and leveraging of existing IT security assets make External Server Authentication a very important tool.



The type External Server Authentication respondents say they used provides some interesting results:





Finally, respondents revealed widespread use of some key Record Level Access features for controlling creation, viewing, editing, and deleting of records.

Analysis and Interpretation.

While I am wary of over-generalizations from the information provided by survey respondents, I nevertheless can offer some observations.

1.     FileMaker developers are concerned about security items. They know that systems they develop, either for clients or for their employers, can and will be subject to attacks seeking the data in the files. They also know that the business processes the databases manage can be disrupted if users are not constrained from potentially damaging actions, such as inadvertent or careless record deletion. To that end, they employ a number of the standard security features both for Identity and Access Management and for Role Based Privileges.

2.     Utilization of security features tends to cluster towards and in the Great Middle, with only 39% of respondents saying they always use customized Privilege Sets. We also see a marked differentiation between Macintosh OS and Windows OS in the use of External Server Authentication with the respective Domain Controller.

What this suggests to me is that while a significant portion of respondents have an understanding of the basic security features of the products, that only a highly diminished segment utilizes the more nuanced and advanced security features. This is unfortunate, because these features are very valuable––not to mention very flexible––in aiding creation of robust security for FileMaker Pro files. Since nearly two-thirds of respondents work full time developing FileMaker databases, this is a loss to the developer community.

3.     The relatively high level of adoption and use of the File Access Protection feature is gratifying. Particularly for the developers of commercial products based on FileMaker Pro, but for all of us as well, File Access Protection is one of the very most important features we can employ to protect our and our clients’ files. The cluster around the 37% to 38% of developers who say they do not use File Access Protection is a cause for concern. Without this feature, their files are vulnerable to manipulation and compromise.

4.     In the Comments section of the survey—about which we may have more to say at a later time—a couple of items were noteworthy. First, a number of people requested the ability to have dynamic Field Level Access similar to Record Level Access. I fully endorse that request. Second, a number of people requested that a variety of features and capabilities in the security arena be added to the products. They spoke as if the items they requested could not presently be accomplished, when, in fact, they can be. This indicates that some specialized information about these capabilities needs developing. I will undertake to do that in the coming weeks.

Finally, a word of thanks to all who participated in the FileMaker Security Survey. And a very special thanks to Stephen Dolenski of FM Forums for hosting the survey.