Jump to content
  • entries
    44
  • comments
    59
  • views
    88,309

FMI Security Webinar

Steven H. Blackwell

1,679 views

FMI Security Webinar

On February 11th 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

  • Like 1


3 Comments


Recommended Comments

Thanks for the post, Steven.

 

Do you know if enabling Encryption At Rest will have any performance impacts?

  • Like 1

Share this comment


Link to comment

Mkos,

 

from what I was told by Rosemary the impact is no siginifiant impact, and would be similar in performance as using SSL

Share this comment


Link to comment

 

 

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 actuallystrengthened 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.

 

I agree that any additional measures a developer takes are unlikely to increase the security of a file. I don't think any serious developer adds security features with this expectation. They are usually added because the FileMaker security model is not suited to all client requirements. Take the Role-Based-Access-Control model (RBAC), for example, which has grown in popularity in the last few years. It isn't possible to implement RBAC using the default FileMaker Pro security features because users can only be assigned a single privilege set, which torpedoes the inheritance concept that RBAC relies on.

 

So, the only option if you want to implement RBAC is to create your own RBAC tables for users, auth items and child auth items and use them to manage access. And you use them in tandem with FileMaker accounts that are as restrictive as possible while still giving users the access levels they need.

 

Does this make your solution insecure? Only if you mess up the implementation. But, as Steven points out, your solution is also insecure if you mess up the implementation of a regular FileMaker security set up.

 

I do think getting the basics of FileMaker security right is essential and I appreciate the points in this blog. I also think that with most FileMaker solutions you are best served sticking to the built-in FileMaker security features, even if they do make development more time-consuming. But in some cases you do need to go outside the built-in security in order to provide users with functionality and compete with other products.

 

At heart, FileMaker is a DBMS like any other and in other DBMS (Oracle, MSSQL, MySQL) managing security through customized tables on top of built-in security is common and perfectly acceptable.

  • Like 1

Share this comment


Link to comment
×

Important Information

By using this site, you agree to our Terms of Use.