Jump to content
  • entries
    41
  • comments
    56
  • views
    84,849

About this blog

Discusses issues of Confidentiality, Integrity, and Availability of FileMaker Pro databases.

Entries in this blog

Steven H. Blackwell

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:



Full time independent developer

47%

Full time in-house developer

18%

Work at or for a FileMaker development company

17%


Part time in-house developer

 11%


Power user

3%

Regular user

1%


FileMaker hosting company

1%

 

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



USA

71%

Western Europe

12%

Canada

6%

Australia/New Zealand

4%

Eastern and Central Europe

 2%

Latin America/Caribbean

 2%

 

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:




Category

Use File Access

Not Use

Full time independent developer

68%

32%

Full time in-house developer

63%

37%

Work at or for a FileMaker development company

62%

38%

Part time in-house developer

62%

38%

 

 

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?



Category

Never

Sometimes

Always


Generic Privilege Sets

19%

65%

10%


Basic Privilege Sets

11%

66%

17%


Customized Privilege Sets

3%

53%

39%


Custom Extended Privileges

6%

59%

30%

 




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.



Category

Yes

No

Use External Authentication of any type

58%

42%

External Authentication (Macintosh OS)

35%

65%

External Authentication (Windows OS)

52%

48%

 

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



Type

Yes

No

Open Directory Domain

23%

77%

Active Directory Domain

47%

53%

Local Server Groups (Macintosh)

26%

74%

Local Server Groups (Windows)

30%

70%

 



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

 

Category

 Yes

No

Use any type RLA

71%

 29%

View Records

63%

37%

Create Records

60%

40%

Delete Records

71%

29%

Edit Records

66%

34%

 

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.

Steven H. Blackwell

Assessing Threats, Vulnerabilities, and Risks to

FileMaker® Pro Databases

Hosted FileMaker Pro databases are susceptible to unauthorized access, manipulation, destruction, and other forms of compromise. Developers and server administrators need to understand how to assess threats and the risks of those risk’s occurring as various threat agents seek to exploit vulnerabilities.

This process starts with an understanding of the environment where the databases operate. We have a variety of digital assets that we must seek to protect. Nowadays, for the most part, the assets we are most concerned about are the hosted databases and the information in them.. We need to be able to protect the Confidentiality, Integrity, and Availability (CIA) of those digital assets.

When a breach of CIA occurs there will be an impact on the digital asset. Understanding and predicting the level of that impact is an important aspect of the assessment we must make. We can generally classify the level of impact into one of four categories:

1. Limited Adverse Impact

2. Serious Adverse Impact

3. Severe Adverse Impact

4. Catastrophic Adverse Impact

The targets of that impact are the people, the assets, the operations, and the reputation of the organization that owns the asset whose CIA is breached. The same event, e.g. a breach of Confidentiality of the asset, may have very different levels of impact on each different target. Likewise, on the same target, a breach of Integrity may have a far more adverse impact than a breach of Confidentiality would.

As a result, FileMaker developers and server administrators must assess each attribute of CIA and the likely impact of its breach on each target: people, operations, assets, and reputation.

The Threat is that a Threat Agent will exploit a known or a heretofore unknown Vulnerability in a specific hosted FileMaker file resulting in a breach of CIA with an adverse impact of varying levels on the various targets as described previously.

Risk is the likelihood of some Threat Agent’s actually exploiting the Vulnerability. And Risk can be difficult to quantify or even to identify, especially if the Threat Agent is of a type not previously identified or even known to exist.

In FileMaker Security, indeed in most types of information security, we have three principal tasks:

Close Vulnerabilities

Block Threat Agents

Mitigate the Adverse Impact of Breaches

In terms of setting priorities to achieve this, since tasks seem always to exceed resources, we should focus on the higher Risk items that have greater levels of Adverse Impact. Or so it would seem. But the equation is not quite that simple. Closing known Vulnerabilities is a major factor in blocking the Threat Agent. We may therefore get an overall more beneficial result in terms of our goal of protecting our digital asset by having a more nuanced mixture and balance among these categories.

In summary then, when we undertake to assess the Threats, Vulnerabilities, and Risks to our hosted FileMaker Pro databases we have a number of items to consider:

• What
assets
are we trying to protect?

• What would be the level of Impact on
people, assets, operations,
or
reputation
if a CIA breach occurred?

• What
Vulnerabilities
could a
Threat Agent
exploit to cause a
Breach
?

• What are the
Threats
?

• Who are the
Threat Agents
?

• What is the
Risk
of the
Threat Agent’s
triggering the
Threat
to exploit the
Vulnerability
?

When we can answer these questions, we can begin to address the question of what type and amount of security we need for our hosted FileMaker Pro databases and for FileMaker Server.

Please see the graphic for a further depiction of this concept. As always, your comments or questions are welcomed.

Steven H. Blackwell

blogentry-57159-0-57839300-1370382108_th

Steven H. Blackwell

“What's in a name? that which we call a rose,


By any other name would smell as sweet.”

—Juliet (Romeo and Juliet, Act II, Scene 2, William Shakespeare)—

“The beginning of wisdom is to call things by their proper name.”

—Confucius—

An entire series of recent studies[1] published by well-known and well renown international security analysis and information industry firms have all made, in slightly varying language, the following key points:

  1. Data housed in files in organizations are under relentless and persistent attack by a variety of threat agents including criminals, nation states, so-called “hacktivists”, and disgruntled current or former employees.
  2. Organizations of all different sizes are vulnerable; however, smaller businesses and organizations are particularly susceptible to data breaches because they have fewer resources with which to protect themselves and are often in the supply chain of larger organizations that may house particularly valuable data. This is not to say that smaller organization themselves do not also have the same type of particularly valuable data.
  3. Financial gain, industrial espionage focused on the theft of intellectual property, and embarrassment or disruption of organization activity are three principal motivations driving threat agents to undertake attacks that result in data breaches.
  4. The data are the target, not networks or web sites, or other digital infrastructure items. It’s the data.

The data housed in FileMaker databases and resident in organizations using FileMaker Pro and FileMaker Server fall squarely into this realm. So contrary to Juliet’s assertion, we need to adopt the Confucian approach and call this by its proper name.

FileMaker databases are susceptible to attack, and the data in them can be compromised and stolen or altered or manipulated by unauthorized persons. The sooner the community recognizes this, and the sooner developers and administrators recognize this, the sooner we can begin a serious and focused discussion about how to identify the likely attackers, identify what vulnerabilities in the software they might exploit, assess the likely risk of their doing so, and develop plans to mitigate the adverse impact of successful attacks.

What type data are vulnerable? The answer is: all types. Some categories are more valuable than others; these are likely high on the list of any attacker. Financial data, personally identifiable information, intellectual property, business process information, and organizational IT data are major targets.

What type organization is most at risk? Both small and large organizations in the for-profit, the not-for-profit, and the government and education sectors are targets. While certain types of attacks tend to focus on different sized organizations, all are vulnerable. And since smaller organizations frequently lack the resources or the processes to protect themselves, they can be especially hard hit.

FileMaker Pro database systems can be found in every type organization imaginable of every size and description in well over 100 countries on seven continents. Some of these databases are well-defended; others are defenseless. We in the developer community are lagging in our efforts to address the seriousness and pervasiveness of the threats to FileMaker databases found in all types of organizations, large and small, across a range of business segments.

One sentence in one of those reports[2] I referenced at the beginning of this post stands out as a stark reminder:

“Some interpret attack difficulty as synonymous with the skill of the attacker, and while there’s some truth to that, it almost certainly reveals much more about the skill and readiness of the defender.”

It’s time for the developer community to get busy about and to get serious about protecting information stored in the systems we create. What information do your clients have that needs protecting? And what happens if you don’t do that? We will explore those two questions, along with how to determine threats and risks, in coming entries on this BLOG.

[1] Verizon, 2013 Data Breach Investigations Report

Mandiant, 2013 M Trends Threat Report

Solutionary, 2013 Global Threat Intelligence Report (GTIR)

Sophos, Security Threat Report 2013

[2] Verizon Report p. 48

Steven H. Blackwell

Ten Frequently Encountered Practices

That Can Compromise Security of FileMaker Pro Files

April 9th 2013

In our last installment, I noted:

“In 2013, I will be focusing on promoting the goal of achieving that understanding [meaning understanding FileMaker Server] along with the parallel and related one of overcoming a similar lack of understanding and awareness about FileMaker security items.”

In this post I want to focus on ten frequently encountered practices with FileMaker Pro files that present potential vulnerabilities that could be used to compromise the Confidentiality, Integrity, or Availability of the files and their resident data. Most of these scenarios occur on files hosted by FileMaker Server; however some may pertain to standalone files as well. These scenarios occur in a variety of organizations and deployments; all present unneeded vulnerabilities.

  1. Full Access Accounts for server side scripts. Avoid the use of Accounts tied to the [Full Access] Privilege Set for running server side scripts. Use an Account tied to a subordinate level Privilege Set specifically designed for the purpose of running the script.

  2. Not disabling default Account. The default Account, whether auto-logon or not, should be disabled. This Account is Admin with a blank password. Or alternatively, add a strong password to that Account and be sure auto-logon is disabled.

  3. FMServer sample file where is as is. Developers should close and preferably remove this file from FileMaker Server if it is not being used. If it is used, disable the auto-logon and give the default Admin Account a strong password.

  4. External Server Authentication of Full Access Accounts. Avoid using External Server Authentication for Accounts tied to the [Full Access] Privilege Set. It puts the files at risk of compromise.

  5. Reliance on default subordinate Privilege Sets. The two default subordinate Privilege Sets (Data Entry Only and Read- Only Access) contain privileges considerably in excess of what their respective name implies. Create your own custom Privilege Sets instead with exactly the privileges, and only the privileges, that you need for the assigned role.

  6. Not logging out of the FileMaker Server machine. FileMaker Server is a service/daemon. It is designed to be run with no one logged into its machine. That, by far, is the safest way to run it. Running it with a user logged in or at the “Lock” position on either OS X Server or Windows Server compromises its security.

  7. Failing to Employ the File Access Protection Feature. The File Access Protection feature added in FileMaker® Pro 11, and continued in FileMaker® Pro 12, helps protect files from unauthorized and unexpected manipulation of scripts, value lists, table aliases, and other schema. It also prevents unauthorized accessing of information in an external file by manipulation of the Design Functions. Many developers simply do not invoke this feature to protect files, and this leaves them vulnerable.

  8. Enabling OS Level File Sharing. FileMaker Server does not require the use of Operating System (OS) level file sharing in order to function correctly. Such OS level shares represent an attack vector that can be exploited to compromise or to damage the files. These shares can also impede performance of FileMaker Server.

  9. Confusing Data Access Privileges And User Interface Privileges. Generally speaking, privileges assigned at the data level persist wherever the data are accessed. If a field is not editable for a given Privilege Set when that field is viewed in File A, it will likewise not be editable when viewed in File B. The same is not true however with other items such as printing or exporting. Blocking printing of data or exporting of data in File A does not block those same actions when data from File A are viewed in File B. That’s one reason why the File Access Protection feature described in item 7 is so important for protecting data.

  10. Using Enterprise Level Backup Systems on Live FileMaker Pro files. FileMaker Server has its own built-in backup processes. In FileMaker® Server 12, this includes both incremental backups that copy only changed blocks and a new hard-link backup system that prevents multiple copying of files that have not changed since their last backup. Use of enterprise level backup systems on hosted FileMaker Pro files can damage those files and adversely affect the integrity and availability of those backups. It can also damage and corrupt the original files in the process. Such enterprise systems should not be used on live, hosted files.

Developers and FileMaker Server administrators should avoid being members of the class of “Unskilled and Unaware of It” persons by learning and following Best Practices for FileMaker security.

Steven H. Blackwell

Unskilled and Unaware

Nearly fourteen years ago two Cornell University psychologists authored a definitive study titled Unskilled and Unaware of It. Their core thesis was that persons who were unskilled in any number of domains suffered a dual burden. They reach erroneous conclusions and make incorrect and unfortunate choices on the one hand. And second, their lack of knowledge and competence robs them of the ability to recognize their errors. They are incorrect; yet, they believe that they are correct, and they are unaware of their errors.

In the broader FileMaker community and among significant portions of the broadly-defined FileMaker developer community, this unfortunate set of circumstances manifests itself most vividly in the two areas of FileMaker Server and FileMaker Security.

There are many excellent and creative developers who are providing software development services to internal and external clients on seven continents. The solutions they create solve a vast array of business management problems, allow companies or organizations to grow and better to serve their clients and customers, and streamline organization operations.

A line, seemingly and paradoxically both vivid and yet hidden at the same time, separates these developers from those also having an effective knowledge of FileMaker Server and a clear understanding of how different an environment FileMaker Server is than what FileMaker Pro is. That effective knowledge also allows those developers to offer a stable and secure deployment platform on which their solutions can be run for maximum effectiveness.

There is a considerable body of material extant about FileMaker Server, and most of it is both good and useful. But there is not too much information available about how different it is than the development environment that characterizes FileMaker Pro Advanced or the client consumption environments of FileMaker Pro, FileMaker GO, or the various web publishing options, not to mention such elements as ODBC or JDBC connectivity.

The server environment is poised in my view to increase its significance and importance, not to mention its ubiquity. Thus, it is an absolute necessity that FileMaker professionals significantly increase their knowledge levels about the environments in which the Server products work as well as their knowledge about how the Server products do their work. The developer community, and the customer/client community, must acquire the understanding and the skills to overcome the burdens of being unskilled and unaware.

In 2013, I will be focusing on promoting the goal of achieving that understanding along with the parallel and related one of overcoming a similar lack of understanding and awareness about FileMaker security items.

To begin the discussion about FileMaker Server, I would point out a few key items:

1. The purpose of FileMaker Server is to provide safe, secure, reliable, and consistently available access to data and business processes housed in database files.

2. The purpose of the server hardware housing FileMaker Server is to facilitate and to enhance FileMaker Server’s ability to achieve its core objectives. The same is true for the operating system that runs the hardware.

3. A server environment is different than and distinct from a workstation’s development environment or a client usage environment. It has its own constraints, requirements, tools and sound operating principles.

As a first step towards gaining more understanding about FileMaker Server, I recommend a review of the FileMaker Server 12 video tutorials by our leading industry expert Wim Decorte found at:

VTC Server Videos

Steven H. Blackwell

The original study by the two Cornell scholars:

Justin Kruger and David Dunning;

Unskilled and Unaware of It: How Difficulties in Recognizing One's Own

Incompetence Lead to Inflated Self-Assessments (Journal of Personality and Social Psychology,

1999, Vol. 77, No. 6. 121-1134)

Steven H. Blackwell

 

 

FileMaker Server 12 BackUps Frequently Asked Questions

 

 

FileMaker® Server 12 has a number of new features for creating backups of databases it hosts.

 

As evidenced by questions raised at the 2012 DevCon and as evidenced by a number of items posted on various FileMaker lists, there is a good deal of confusion still about how the new backup system works.

 

Wim Decorte and I have authored a short set of Frequently Asked Questions along with their answers about this topic. You can download the attached PDF that contains this information.

 

Among the questions we address are these:

 

How have backups changed in FileMaker® Server 12?

 

I want to schedule an incremental or progressive backup. But I can’t find where that is done? How do I schedule this?

 

I need to restore from the last backup. But I get an error message when I try to open the backup file directly in FileMaker Pro or host it on FileMaker Server. Are my backups broken?

 

Where does FileMaker Server put the actual backup copies it creates?

 

We hope the answers to these and to other FAQ’s about FileMaker Server 12 backups will assist the developer community and IT Administrators with FileMaker responsibilities to understand how the new systems work and how to employ them effectively.

 

Steven H. Blackwell

 

Click on the attached PDF to download the document.

FMSBackUpsFAQ.pdf

September 12th 2012

Steven H. Blackwell

April 27th--Update.

We were recently advised that a last minute change in the encryption level of secure storage resulted in that encryption's being 128 bit, not 256 bit as the attached document on Containers states. This is still a strong level of encryption.

 

April 4th 2012

Today’s release of FileMaker® Server 12, together with its companion FileMaker Pro and FileMaker GO products, marks another important milestone on the FileMaker, Inc. Product Roadmap.

FileMaker Server is at the center of all robust and business critical FileMaker solution deployments. It provides safe and reliable hosting of multiple files for access by multiple simultaneous users employing a variety of clients including FileMaker Pro, FileMaker GO, modern web browsers, and ODBC/JDBC savvy applications.

There is one very important caveat about all this, however. For FileMaker Server reliably and effectively to accomplish its various tasks, it must be deployed correctly, configured correctly, and managed correctly.

There are a number of new features in FileMaker Server 12; likewise there are some very significant changes in the way long-standing features function. It is very important for all FileMaker devel­opers and all IT Administrators with FileMaker Server responsibilities to be aware of these in order correctly and safely to deploy the new version of FileMaker Server.

Wim Decorte and I are pleased to present a series of Technical Narratives that discuss a variety of these topics in some depth and detail.

FileMaker® Server 12 Overview

FileMaker® Server 12 Remote Containers

FileMaker® Server 12 New SSL Features

FileMaker® Server 12 Processes

FileMaker® Server 12 Cache

FileMaker® Server 12 Backups

PDF’s of these papers are attached to this BLOG post as an archive. Simply save the Archive by clicking on the file icon and extract the Narratives. Start with the one titled Overview.

 

Steven H. Blackwell

Platinum Member Emeritus, FileMaker Business Alliance

 

FileMakerServer12_Narratives.zip

Steven H. Blackwell

External Server Authentication and [Full Access] Privileges…

Life (or FileMaker) May Not Be What At First It Seems

-By-

Steven H. Blackwell

Someone recently advised me about a discussion on a FileMaker List that focused on the supposed ability of a user with an Account authenticated by External Server Authentication and attached to the [Full Access] Privilege Set to make changes in a hosted file’s security schema. (Technically this is a Group, not an Account, but we’ll call it an Account here for sake of simplicity.)

If someone has actually done this, we need to learn the circumstances under which it happened including the versions both of FileMaker Pro and of FileMaker Server as well as the OS of the machines running FileMaker Server and FileMaker Pro. Such a capability would represent a significant security vulnerability.

I set out to investigate this report and whether such an action could actually have occurred, and whether I could duplicate the reported behavior. Bottom line: the answer is No. But the scenarios I discovered were interesting and somewhat unexpected.

I want to thank long time FileMaker developer and technical expert Darren L. Terry of Pacific Data Management in San Jose, California, for his assistance in running this issue to ground. Darren, who was once described on a FileMaker List as being “…worth [his] weight in rum…” hit on the first major important clue required to answer this question.

The report I got was that a user with a [Full Access] Account that was externally authenticated by FileMaker Server had been able to log onto a hosted file and change items in the security settings. I doubted that claim.

Here is what should happen, and is actually supposed to happen, in these circumstances. If a user with an Account with [Full Access] privileges that was externally authenticated opens a hosted file, that user will have access to the Manage Security… functionality. The user of this Account can view the names of other Accounts and of External Groups. The user of this Account can also view the items in any of the Privilege Sets in the file.

When the user of the Account makes changes in any of the other Accounts or Groups or in any of the Privilege Sets, they may appear to be changed. However, these changes are not committed until the user exits the Manage Security… area.

Upon exiting, the user will be presented with a credentials challenge similar to this one:

blogentry-51827-0-19267200-1328980851_th

Now, if the user enters the [Full Access] Account credentials that were externally authenticated, an error message similar to this one should appear:

blogentry-51827-0-90775000-1328980856_th

In other words, an externally authenticated Account with [Full Access] privileges should not be able to change and commit Security settings. To do otherwise would be a violation of several core Principles of Security including Segregation of Duties/Separation of Duties, Rule of Least Privileges, etc.

Here is an important caveat and warning: For a variety of reasons, externally authenticated Accounts ought not be assigned to the [Full Access] Privilege Set. If a physical copy of a file were to be obtained, the External Groups could possibly be spoofed, granting unrestricted access to the file.

Nevertheless, if someone ignores that advice and does assign [Full Access] privileges to an external Account, attempts to make changes in the security schema should produce the results described above, namely the invalid password challenge.

Yet, the report was that a user had been able to change the security settings. I considered one way this might have appeared to have happened.

If a user had entered the Manage Security… area and made some changes but then cancelled them before attempting to exit the Security area and commit them, such a user might understandably believe he or she had been able to make the changes. So if the user did not want the apparent changes to take effect, the user would cancel out of the event. This was a possible explanation.

Darren Terry then provided an important clue: suppose there were duplicate Accounts, one internal and one external, with identical Account names and passwords. What would happen then? FileMaker Pro blocks creation of identically named Accounts in the same file; Account names must be unique. (Interestingly, passwords do not have to be unique; however developers should work on an assumption that they are required to be so.) But in this instance, since one Account was internal and the other external, there is no way to flag identical items.

So, in testing this scenario on a hosted file with identical [Full Access] Accounts, one internal and the other external, I was able to log onto the file with the external Account. I could identify that this was the external Account by placing it higher in the Authentication Order List than the identical internal Account. I made changes in the Privilege Sets and then sought to exit the file. I was presented with the Confirm Full Access Login credentials challenge (as shown above), entered the credentials, and exited the Security area successfully.

Thus it did appear that I had used the externally authenticated [Full Access] Account to change the security settings in the file. But this appearance is deceptive; that is not what actually happened.

When FileMaker Pro sought to evaluate the credentials I supplied, it first examined the externally authenticated one that was higher in the Authentication Order List. It rejected that Account, and moved to the next one in the list. That was the internal [Full Access] Account; that Account was accepted. I confirmed this behavior by disabling the internal Account. That produced the error shown at the start of this BLOG post. Re-enabling the internal Account produced a successful exit from the Manage Security… area of the file.

Positioning in the Authentication Order List is not a controlling factor for this scenario. Placing the internal Account higher in the list, logging in to the file, and then disabling that Account produced the same unsuccessful result. That happened despite the presence of the identical external Account.

So, in summary, here are the key points to remember:

  1. Don’t use External Server Authentication for a [Full Access] Account (technically a Group) in a file.

  2. If you choose to ignore this advice, you cannot commit changes to the Security schema with that externally authenticated [Full Access] Account. Such changes require an internally authenticated [Full Access] Account.

  3. Darren Terry is still worth his weight in rum.
Steven H. Blackwell

Gas, Liquid, or Solid: Drive On

--By—

Steven H. Blackwell

January 3rd 2012

Happy New Year to FileMaker developers and users around the world. We have a lot of work to do in the FileMaker World in 2012, and I am eager to get started.

A very key element and requirement for the reliable and safe deployment of FileMaker Pro files is, of course, FileMaker Server. And, of all the components of a FileMaker Server deployment, none is more important, I would assert, than the quality of the hard disk drive subsystem on the server machine. In 2011 we saw a lot of discussion about Solid State Drives (SSD’s) and their use with FileMaker Server. Almost all this discussion focused on the benefits of using these drives in lieu of the more traditional block I/O hard disk drives (HDD’s). Very little attention was paid to some important nuances that should inform any decision to use SSD’s. These drives are becoming more and more prevalent, and they can offer significant advantages. However, we need a fuller picture of them. I hope this BLOG post will engender some discussion in the community about SSD’s and their use in FileMaker Server machines.

An important concept of any engineering process is to focus on stress points and potential failures. Civil engineers building a bridge do this; electrical engineers designing and constructing transformers and power grids do the same. And as developers and IT Administrators dealing with FileMaker Server hardware, we must also consider stress and failure points.

In this BLOG posting, I want to highlight several considerations you should be aware of when contemplating the use of SSD’s.

SSD’s are not new devices. Their origins are in the 1950’s era. The first modern type SSD appeared 35 years ago this year. Comparing SSD’s with the traditional HHD’s can be difficult. In the late Spring of 2011 the Storage Networking Industry Association (SNIA) released two sets of specifications that can be used to measure SSD performance. Traditionally HDD benchmarks have tended to focus on aspects of those drives that are weak, particularly rotational latency and seek time. Since SSD’s don’t spin or seek, by comparison they seem superior to HDD’s.

But the equation isn’t that simple. SSD’s slow down after initial use once data have been written to them. The drive’s processor begins to move data around in the read-modify-erase-write cycle. The availability of free programmable blocks significantly impacts SSD write performance. Fewer blocks translate to diminished performance levels. Once the drive has data of any significant amounts, the NAND[1] flash memory at the drive’s core requires that old data be marked for deletion and then actually deleted in the “garbage collection” process.

A further refinement of this behavior has been described:[2]

SSDs have challenges with mixed reads and writes, and their performance may degrade over time. SSD testing must start from the (in use) full disk, as the new and empty (fresh out of the box) disk may have much better write performance than it would show after only weeks of use. [emphasis supplied]

SSD reliability and longevity are also influenced considerably by a process known as Write Amplification. This process has been described[3] as:

…an undesirable phenomenon associated with flash memory and solid-state drives (SSDs). Because flash memory must be erased before it can be rewritten, the process to perform these operations results in moving (or rewriting) user data and metadata more than once. This multiplying effect increases the number of writes required over the life of the SSD which shortens the time it can reliably operate.

All of which raises another interesting item. NAND flash memory cannot be overwritten. This can cause problems for software encryption programs. The encryption program cannot effectively deal with the data marked for deletion. Hardware based encryption programs do not have this problem.

SSD’s offer one instance of “…you get what you pay for…” at least in one respect. Entry grade and lower cost SSD’s have write speeds significantly lower than their read speeds. This is different than traditional HHD’s where read and write speeds are more nearly equal to one another; write is only marginally slower than read. Higher performing–and thus more expensive–SSD’s have a more balanced read and write speed comparison.

FileMaker Server, even in a modestly busy environment, does a lot of read and write between disk and cache as it sends data, receives data, encrypts data, and resolves calculations between client workstations and the server. Thus FileMaker Pro developers and IT Administrators will want to consider the read-write characteristics of SSD’s very carefully when selecting server hardware.

Developers and Administrators must also consider the Operating System running the server when selecting HHD or SSD type drives. Versions of Windows OS prior to Windows 7 are optimized for HHD’s, not SSD’s. Windows 7 is optimized for both SSD’s and HHD’s, and the OS operates differently if it detects the presence of a SSD, including disabling disk fragmentation. Windows Server 2008R2 supports SSD’s as well. Macintosh OS X 10.6.8 and 10.7 also support SSD’s. All of these very modern OS support the TRIM function as well, a feature needed to reduce garbage collection of data the OS has already determined to be no longer valid. This saves unnecessary wear and tear on the SSD.

These documents were a principal resource for preparing this BLOG entry, and I recommend a further reading:

http://en.wikipedia....lid-state_drive

http://www.macworld....ssdtesting.html

http://en.wikipedia....e_amplification

Benchmarking Enterprise SSD’s

http://www.stec-inc....rprise_SSDs.pdf

Notes:

[1] Not AND (NAND) electronic logic gate. http://wiki.answers....t_is_NAND_flash

[2] Benchmarking Enterprise SSD’s

http://www.stec-inc....rprise_SSDs.pdf

and see also http://en.wikipedia....lid-state_drive at Page 1.

[3] Write Amplification. http://en.wikipedia....e_amplification

Steven H. Blackwell

A Different Perspective On Recently Released

FileMaker, Inc. How To Paper

Regarding External Authentication Configuration

By

Wim Decorte

and

Steven H. Blackwell

I am pleased to have as co-author of this BLOG posting the renown and exceptionally highly regarded “developer’s developer” Wim Decorte.

FileMaker, Inc. recently published a FileMaker How To article entitled Replicating an External Authentication Environment for Development authored by developers at Skeleton Key in St. Louis, Missouri.

A copy of the Skeleton Key article can be found on their website here:

http://www.skeletonkey.com/blog/replicate_an_externally_authenticated_production_environment

This is an interesting paper, and it deserves a review by FileMaker developers, both independent and corporate. It reminds us that servers do have local Security Groups and Accounts. In fact, such Groups and Accounts are widely used for External Server Authentication purposes in a variety of small to medium sized enterprises as well as in workgroups of larger ones. The fact that FileMaker External Authentication can work with local accounts and groups in the OS on the FileMaker Server machine itself is often overlooked, so the article serves a good purpose in this respect.

Notwithstanding this, however, we have significant concerns and reservations about the underlying premise of this paper as well as some of the specific techniques it recommends and describes. We have elected to share these with the FileMaker developer community because of the official FileMaker, Inc. imprimatur on this paper and because of our genuine respect for the developer team at Skeleton Key. Developers will see and read this paper, authored by a well-known and respected company and issued by FileMaker, Inc., and perhaps not be aware of a number of additional considerations.

The paper states at the outset its principal purpose (emphasis supplied):

Imagine you are an outside developer for a large company. You are building a mission-critical FileMaker system – a large solution with several different privilege sets that require careful testing and tuning. Their IT team has mandated that FileMaker Server must authenticate users externally. You want to make sure the solution’s security setup will work well with multiple users and that once deployed it will properly interact with the customer’s Active or Open Directory environment. As their dedicated developer you have been given access to the company’s FileMaker Server and files, but as an outside consultant you do not have access to make changes to their network directory or services. How can you fully configure and test the security of your FileMaker system before the actual deployment in their production environment?

In our view this underlying assumption of the paper is invalid. There is no need to construct a system of External Accounts to “…fully configure and test…” the system’s security. The effect of restrictions held in privilege sets can be tested with regular internal FileMaker accounts.

The only reason to set up a system of External Authentication would be test the mechanics of the authentication process, not the restrictions of a user’s role.

The paper’s underlying assumption and the subsequent recommendations confuse and conflate Identity and Access Management (who are you?) with Role Based Privileges (what are you allowed to do?). Through its Privilege Set definitions, FileMaker Pro enforces a set of conditions for each Account attached to that specific Privilege Set. Accounts attached to a Privilege Set all enjoy, for the most part,[1] a common set of privileges in tables and files. By default, all privileges are denied; developers must specifically enable each. This is in keeping with the Rule of Least Privileges that mandates a user have all the privileges needed for his or her role, but no more privileges than the ones needed.

Role Based Privileges form one part of the FileMaker security schema. The other part is Identity and Access Management (I&AM). I&AM is used to authenticate users seeking access to the database system. It answers two related questions: “Who are you?” and “Are you whom you claim to be?” Once these two questions are successfully answered, the user is granted access to the database system with the Role Based Privileges defined in the Privilege Set to which the Account is attached.

FileMaker can perform I&AM functions either with internal FileMaker accounts or with External Server Accounts. In either regard, the result is the same: if the user is properly authenticated and deemed to be an authorized user, that user gets the privileges associated with the Account accessing the file. Thus, there is no need to construct a “development” environment using External Server Accounts to, in the paper’s phrasing, “…test the security of your FileMaker system before the actual deployment in their production environment….” An internal FileMaker account works just as well for this purpose. Two different Accounts, one internal and the other External, attached to the same Privilege Set will enjoy exactly the same set of privileges when the user is connected to the file. FileMaker, Inc. has taken specific steps over the past several versions to assure this.

—Beyond Fundamentals—

Beyond this fundamental item, there are also a number of other elements in the paper that concern us. The page number references are to pages in the paper.

Better access control (page 1). While indeed this is an advantage of External Server Authentication, this is a Domain level policy, and it will not be achieved through use of Local Security Group objects. Unless there are a great number of files in the FileMaker solution there is no real benefit in setting up this local External Authentication scheme, an internal FileMaker account will work for this purpose and is easier to set up.

What’s Needed? A local machine that is not bound to either an OD or an AD domain…(page 2). OSX and Windows work differently in this respect. Even if a Macintosh machine is bound to an Open Directory or Active Directory domain, FileMaker Server will always look to the Local Security Group first before it looks to the Domain Controller. So contrary to what is implied, the mechanism described in the paper will work when the OSX FileMaker Server machine is bound to either an AD or an OD domain. On Windows OS however, the server machine is either bound or not bound. When it is bound to an AD (is a member server of an AD domain) it will skip the local accounts and groups and always look for the domain accounts. While it is possible to force FileMaker Server to look first on the local machine when bound to an Active Directory domain, that is neither default nor standard behavior. But it is still possible to test local External Authentication when the Windows FileMaker Server is bound to an AD.

What’s Needed? FileMaker Server installed on your local machine…(page 2). We do not believe this is a good policy. We do not advocate running FileMaker Server and FileMaker Pro simultaneously on the same machine. We are aware that some developers do this and have FileMaker Pro become a guest of that FileMaker Server instance and access their files thereby. Especially if the external data source file reference is of the relative type, file:filename rather than the FileMaker network type, fmnet:/HostIP/filename, we believe there could be instances where files opened by relationships or scripts via Table Aliases on the Graph may not open as expected as a guest of FileMaker Server. Much more testing and some definitive declaration from FileMaker, Inc. Engineering are needed to determine actual FileMaker behavior in these circumstances.

Setting it up. You can replicate the relevant EA setup…(page 3). This is, at best, only partly correct. Local Security Groups do not behave in exactly the same fashion as Domain Groups. This is particularly true for Single Sign-On (SSO) which is only possible when a Windows OS workstation connects to a FileMaker Server on Windows Server and where the server is a member of the Active Directory Domain. Some developers fail to make a critical distinction between External Server Authentication and SSO. They are not the same. In the former, available for both Macintosh and Windows, the Account can be authenticated; however the user must enter credentials to access the file. Those credentials are then authenticated by the server after the user enters them. In SSO, however, the user does not have to enter credentials again to access the database once he or she is authenticated to the domain. [Note: on Macintosh SSO capabilities can be emulated to an extent by use of the KeyChain]. With Local Groups however, users must enter credentials to access the file; SSO is not operative (again with the KeyChain nuance). Thus, if the developer was expecting not to enter credentials, confusion may well ensue.

The other aspect is that the mechanics of authenticating against local accounts is different than authenticating against an OD or AD. There are factors that do not come into play with local authentication such as clock synchronization and lag time incurred by the physical distance between the FileMaker Server machine and the AD or OD machine. This translates into mimicking the EA setup, but not replicating it.

FileMaker Pro Login window (page 5) and Account in the ‘Production Coordinators’ Group (page 7). Mr. Richman’s account is styled differently here one place than the other (Mark Richman vs. mrichman). This may cause the process to fail. We believe the paper should have attempted to explain the difference to avoid confusion. On the Macintosh platform the short name is the one used by FileMaker Server and Open Directory, not the long name that is the more user recognizable one. Thus, an Account named Steven Blackwell will be reduced to the short form stevenblackwell. Note the absence of spaces and the use of all lowercase letters. When establishing Accounts on either platform, we recommend the use of all lowercase names without spaces. Likewise we recommend the use of a similar construct for the Group names, both on the server and in the file. (See contrary example at bottom of page 6). We also encourage the use of a construct similar to this one: fm_solutionname_groupname for this, inasmuch as it is easily and quickly identifiable both as a FileMaker Group in either AD or OD and as part of a specific solution.

Account in the ‘Production Coordinators’ Group (page 7). We note that the example given here for adding Accounts in OS X is utilizing the OS X client software, not the OS X Server software. While this is to be expected because the developer presumably is working on a client machine for development purposes, the UI and process on OS X Server may be somewhat different. Various versions of OS X Server have taken different approaches to this. The WorkGroup Manager however has been the utility most frequently used on the Server version to create Groups, create Accounts, and to assign Accounts to Groups. On Windows OS, the UI is more nearly identical between client and server versions.

In addition to the foregoing, there is at least one critical test the process described in the article cannot address. A key requirement for External Server Authentication, and a key point of failure in many such deployments, is a mismatch between the Group Name on the Server or on the Domain Controller and the Group Name in the FileMaker Pro file. They must match exactly. We previously offered a recommendation for the syntax of such names. To test how the system will work in the production environment, we recommend deployment of a test file configured with the Group names and set for External Server authentication, together with external Groups in the proper place. Users can then attempt to log into that file. A successful log-in can be made to create a new record with Account Name, workstation information, and Privilege Set name, all for developer review. Failed attempts will be logged by FileMaker Server if administrators enable proper logging. Additionally, obvious failures will manifest themselves to the user. When using such a file, be sure to disable auto-log-in options in the test file.

—Summary—

In summary then, we do not believe that the underlying premise of the paper is valid. There really is no need to have External Authentication to test the “security” of the file, inasmuch as the Privilege Sets will function identically irrespective of the authentication model. Additionally, we believe that some of the procedures described in the paper are insufficiently nuanced given distinctions between Domain authentication and Local Group authentication behaviors. Finally, the paper recommends a scenario regarding FileMaker Server and FileMaker Pro’s simultaneous use on the same machine that we do not believe is prudent. We welcome further discussion and debate within the developer community about these items.

[1] It is possible to make one Account attached to a given Privilege Set behave differently than other Accounts attached to the same Privilege Set do. But that is independent of the authentication model used.

Steven H. Blackwell

Locks, Keys, and Lock-Picking

By

Steven H. Blackwell

Platinum Member Emeritus, FileMaker Business Alliance

Recently, an experienced FileMaker Pro developer posed a question on developer group list about the behavior of FileMaker Pro files. Paraphrased, that question is as follows:

We've come across a small, but possible, security issue.



If a user has clicked the "Remember my password in my keychain", 
anyone can log in to the FMP system if the person has access to the computer.

Is there a way to prevent or manage this?

First, this is a good question. It pertains both to Macintosh and to Windows OS, even though the latter doesn’t have KeyChains.

Second, this really is not a FileMaker issue per se. It’s an OS level security issue and turns on how to control unintended access to network resources (or sometimes to local ones) from an authenticated workstation. A principal use of the KeyChain with FileMaker Pro on Macintosh OS is to mimic the Single Sign On capability found with External Server Authentication on the Windows OS.

The general threat vector here is focused on a workstation left unattended and thus vulnerable to having its log-in or similar information misused to access some digital or physical resource such as a FileMaker file or a network share.

In the same thread, another developer noted you can begin a hardening process for the workstation by using the option to require a password to wake from screen saver. Expanding on that approach, you can cause further hardening by utilizing other options for workstation management. These however may be very onerous or not practical.

Third, there are ways to manage the KeyChain itself, some of which are found in an Apple Support Forum thread. https://discussions.apple.com/thread/3048021?start=0&tstart=0

Some of the information regarding FileMaker Pro contained in that Apple Forum thread is, I believe, incorrect. FileMaker Pro does not automatically store log-in credentials for a file in the KeyChain; a user must select that option. So, the question then becomes, as originally asked, how can that practice be prevented or (alternatively) how can the effects of such storage be mitigated or overridden?

In the KeyChain utility, under the Edit Menu, you can require that the LogIn KeyChain be entered after a number of minutes of inactivity. This is probably better that the screen saver option.

At one time, before the introduction of Snow Leopard and Lion, it was possible to restrict the ability for the KeyChain to work with certain applications. I do not know whether that is still the case. Perhaps someone else can state definitively.

The problem with these settings, however, is that they are accessible to the end user unless an Administrator has set up the workstations and restricted user access. So unless the organization has taken these restrictive steps, there are weaknesses to this approach.

Another way to force log-outs of the workstation, and thus require a re-authentication, is through the use of proximity devices. This procedure is employed in many organizations. Basically there is a device attached to the computer and a device attached to the user (usually a card or a USB type device). If the two devices are separated by some pre-defined distance, the workstation is forced to log-out.

Fourth, there are ways to make FileMaker Pro ignore the KeyChain and still require the user to provide credentials. The following FileMaker Pro Pro script can be used for that purpose. This presumes an auto-log-on process with an Account and password attached to a Privilege Set called “LowLow” with the script set to run on launch:

Allow User Abort [ Off ]

Set Error Capture [ On ]

If [ Exact ( Get ( AccountPrivilegeSetName ) ; "[Full Access]" ) ]

Exit Script [ ]

End If

Re-Login [ ]

If [ Exact ( Get ( AccountPrivilegeSetName ) ; "LowLow" ) ]

Beep

Beep

Close Window [ Current Window ]

// Exit Application

End If

The effect of this script is to initiate a Re-Login when the file automatically opens with the auto-login. If the Account Privilege Set Name remains that of the auto-login Account, the system responds to block access. You can have it close the window or exit altogether as you wish.

Such a script’s accessibility must be controlled through the various Privilege Sets so as to prevent its being bypassed or tampered with by an external attack. File Access Protection options in FileMaker® Pro 11 can assist in that regard. This was one very specific reason for that feature’s being implemented and designed to work as it does.

The ever-inventive Mr. Kevin Frank, a well-known and long-time FileMaker developer, has suggested an alternative scripting approach in an entry on his BLOG: http://www.filemakerhacks.com/?p=2632

Fifth, and finally, there are some actions that can act directly on the KeyChain itself. The following Apple Event script was being cited several years ago in various forums as a method to delete FileMaker Pro KeyChains. I have not tested it extensively and do not make any specific warranties about it:

set my_name to name of window 1

tell application "Keychain Scripting"

launch

set my_keychains to (every keychain)

set {FM_keys, FM_names} to {{}, {}}

repeat with k in my_keychains

if name of k is not "System.keychain" and name of k is not "Microsoft_Intermediate_Certificates" then

unlock k

set my_keys to every generic key of k

repeat with i from 1 to count of my_keys

set key_type to creator type of item i of my_keys

if key_type is «class FMP7» then

set FM_name to name of item i of my_keys

if FM_name is my_name then

delete item i of my_keys

end if

end if

end repeat

-- lock k

end if

end repeat

end tell

There are several places where such a script might be run, including from within FileMaker Pro itself.

This is an interesting topic, and it’s one I raised in several places in FileMaker Security: The Book. I am going to take this under advisement again, and I may have more to say about it at a latter date.

Steven H. Blackwell

July 26th 2011

Did You Hear What I Said?

By

Steven H. Blackwell

News media on both sides of the Atlantic were all agog last week over the alleged hacking of cellular phone voice mail accounts of politicians and crime victims by reporters of the now defunct News of the World tabloid. These are serious matters, and much of the coverage has been appropriately professional. Other media coverage however can be characterized in my view as lurid and as having an undertone of “Look what we caught the other guy doing!”

Irrespective of the tone of the coverage however, there has been very little coverage or explanation of how relatively easy it was to access these voicemail accounts. One American media outlet WNYC [
] and noted security blogger Brian Krebs [
] have both explored this issue in some detail. Both point to the relative ease with which these voicemails were accessed.

All of this brings me to the key point I want to make in this posting: namely that wireless networks are frequently completed unsecured and wide open for eavesdropping. It has now been ten years since I cautioned about this vulnerability in a presentation at the 2001 DevCon in Orlando, Florida. This vulnerability is even more widespread today than it was decade ago. While this is distinct from unsecured cellular voice mail accounts, the underlying concepts are the same.

Wireless Internet access in public areas is now widespread. Whether it’s coffee shops, restaurants and cafes, airports, hotel lobbies, or even public streets and parks, wireless Internet access is pervasive, readily accessible, and almost expected as a matter of course. And it’s just as accessible to someone who wants to snoop on what you’re sending over the Internet as it is to you. An eavesdropper’s reading your email, both inbound and outbound, is easy. Capturing your email log-on credentials, or credentials to organization file servers or web sites, or passwords to on-line financial accounts can be easily done if your access methods or the network you are using isn’t protected.

Moreover, such unprotected networks offer access points to unprotected shares and to unprotected hosted FileMaker files (on FileMaker Server) that might be present on machines connected to the network. Even if protected, if credentials for these are obtained, or if they are easily guessed, contents of the share or hosted files may be at risk. Additionally, unscrupulous persons might be able to introduce malware onto these machines.

All of this of course could include many of the wireless networks likely to be found at the upcoming 16
th
FileMaker DevCon in San Diego. Wireless networks in the hotel public areas as well as in the conference functions areas, networks that may be accessible in physically adjacent nearby buildings, and any point-to-point networks that might be created using the public switched telephone network from someone’s laptop all furnish avenues of access.

So when using wireless networks ask yourself who might be affirmatively able to answer the question “
Did You Hear What I Said?”
Use VPN’s or SSL or HTTPS sites to access emails or on-line sites to lessen the likelihood of someone’s monitoring your transmissions. If accessing remote networks, consider using two-factor authentication methods. Do not presume that no one is eavesdropping, because someone can be.

It is perfectly possible using readily available and inexpensive software programs for someone with a laptop computer to be outside the DevCon Exhibit Hall during lunch, or outside a session meeting room, or on the hotel terrace by the pool and capture the target IP address, account names, and passwords that
others are transmitting
on whatever network everyone happens to be using.

As with all security questions there are always balances to be achieved. We trade confidentiality in some instances for the convenience of ready accessibility. If so, let’s make that an informed choice, not an inadvertent one.
Steven H. Blackwell

Back Me Up, Don’t Take Me Out, Are You Never Gonna Do That?

--By--

Steven H. Blackwell

June 13th 2011

Well, with apologies to Emilia De Poret, this adaptation of her hit song’s title pretty well describes the system and process of FileMaker Pro file backups.

Most all developers and IT Administrators who design or manage FileMaker solutions and deploy them in conjunction with FileMaker Server understand that a good backup system is absolutely one of several major requirements to assure the integrity and availability of business data the files contain.

But a significant number of developers and administrators do not understand what best practices are for making backups and for managing the backups once they are created. This article focuses on these two elements: making backups and managing backups.

Almost without exception, the best way to make a backup of a FileMaker Pro file is to have FileMaker Server create a verified backup of the file. Such backups should usually reside on the local server itself. This is the primary backup of the file. More on this later. While there are at least two other good methods for making backups, this is probably the one most used by, and most familiar to, FileMaker developers and IT Administrators who support FileMaker solutions.

Understanding why backups are made is important in understanding how to make them and how to manage them. The purpose of making a backup is not to have one or more copies of a file. The purpose of making a backup is to be able to restore a production file to its previous state in the event of some incident. Administrators must test backups regularly to assure that such restoration can actually occur.

The primary FileMaker backup is your Golden Asset. It forms the basis for any needed restoration. As a result, it should be treated with care and respect. What does such careful treatment entail?

First, do not open or tamper with these files, or open them up to see what might or might not be in them. Second, make a copy of them to some separate location. That second copy, the secondary backup, can then be pushed out to, or swept up by, other enterprise backup systems for either on-site or off-site storage.

Third, do not run anti-virus scanning software on the primary backup files. FileMaker Tech Info #5807 (http://thefmkb.com/5807) does a good job of explaining the damage such anti-virus software can do to the FileMaker files. But the regimen it suggests is not strict enough in my view. While the article notes that the backup destination can be scanned after the backup occurs, I would never do this to the primary backups. If such scans are really needed, it is a better and a safer practice to do them either on the secondary backup or on the copy that the enterprise backup software archives.

Fourth, the Golden Asset nature of the primary backup files argues forcefully in my view against doing anything to or with them other than copying them. If you need to restore a production file from a backup, use a copy of the primary backup. Don’t use the primary backup itself. Protecting the primary backup assures that it is available and unsullied.

Fifth, leave the primary backup files in the place where FileMaker Server put them when it created them. If they are needed elsewhere, make a copy of them. Administrators need to manage the retention frequency of the files to assure that there is always adequate hard drive space for them, while at the same time maintaining sufficient differential backup history. FileMaker Server allows managing this retention frequency by a setting in the Administration Console.

I mentioned there were at least two other good methods for creating backups and managing the backup process. The first of these is the Pause-Copy-Resume process. In this operation a Pause command is issued to the hosted files, in turn causing a cache flush and a suspension of the ability of users to write data to the files. While they are in this state, the files may be safely copied by an OS level action to a directory. When the copying is completed, a Resume command can return the files to their normal working state. This allows users to resume their work.

Such a process is complex to manage; it requires a good knowledge of a scripting language appropriate to the particular Operating System that manages the server, either Windows Server or Macintosh Server. It also requires a knowledge of the FileMaker Server Command Line Interface. Rob Russell of SumWare in New Zealand has posted one example of how to do this. (http://www.sumware.net/robfm2/?p=27) Wim Decorte of Connecting Data in Bermuda (http://www.connectingdata.com) has another example as well. A PDF of that is attached directly to this article. Thanks, Wim and Rob. The Command Line reference information can be found on the FileMaker, Inc. website at http://www.filemaker.com/support/product/docs/fms/fms11_help.pdf at pages 166-188, especially at pp. 179 and 182.

Another backup process uses an incremental approach to updating a master backup once that master backup is made (usually in the overnight hours when activity is minimal). This technique employs the fmDataGuard™ system from WorldSync, Inc. in Berkeley, California (http://worldsync.com). In this process the fmDataGuard system records all the changes made to the FileMaker files after the master backup runs. FileMaker Server then makes frequent backups of the much smaller audit log file where the changes are recorded. If a restoration is required, the audit log is used to update the master backup and to bring the files back to any given point since the master’s creation. This process is known as roll-forward. A case study describing its actual use is found at http://worldsync.com/fmDataGuard/case_linear_blue.html.

So, to summarize about FileMaker backups:

1. Let FileMaker Server be FileMaker Server and do the work of creating the primary backup.

2. Don’t take out, move, or use the primary backup. Make copies of it instead.

3. Manage the retention frequency of backups to assure that adequate space for a series of backups is available on the hard drive where the primary backup directory resides.

4. The primary backup is your Golden Asset needed to implement a restoration if one is required. Protect that Golden Asset.

MoreBackups_v3.pdf

Steven H. Blackwell

The Power and Advantages Of External Server Authentication With FileMaker Server

By

Steven H. Blackwell

May 9th 2011

Since the advent of FileMaker® Server 7 in 2004, FileMaker developers have been able to employ External Server Authentication for controlling Identity and Access Management to FileMaker files when hosted by FileMaker Server. Yet, either from lack of knowledge or from incorrect assumptions about the process, many do not employ this powerful option.

First, a little background information might be useful to further understanding of this process. Most developers are aware that a FileMaker file can contain multiple Accounts and that each individual Account is attached to a given Privilege Set. The Account, together with its password, serves to determine who is accessing the file and that the person accessing is who he or she claims to be. Who are you, and are you actually whom you claim to be? Once authenticated, the user is admitted to the file with the privileges defined in the Privilege Set associated with the Account.

When a system contains one or two Accounts and maybe only a couple of files, this construct of Accounts and Privileges is reasonably easy to manage. But for many users across many files, management is far more complex. This has lead some developers to construct ersatz log-on and security systems of varying degrees of complexity in an attempt to manage the system. I have seen literally scores of these over the past seven years. Almost completely without exception, they have proved highly vulnerable, easy to defeat, and susceptible to manipulation. They detract from, and damage, security in the files where they are used.

External Server Authentication allows us to remove the Accounts and passwords from the FileMaker file and place those Accounts and passwords either on a Domain Controller or directly on the FileMaker Server machine itself. Accounts on the server are placed into Groups, each of which can contain many Accounts. In the FileMaker files themselves, instead of individual Accounts, developers can create identically named Groups and attach each to an individual Privilege Set. These Groups must exactly match those created on the server.

When a user seeks access to a file hosted by FileMaker Server where External Server Authentication is employed, FileMaker Server queries the server (either itself or the Domain Controller) to determine the authenticity of the Account. If the Account is deemed valid, then the user is connected to the FileMaker file with the correct set of privileges. FileMaker Server matches the Group name in the file to the Group name on the server that houses the Account to determine what that set of Privileges should be. This process works to authenticate users connecting by FileMaker Pro clients as well as by Instant Web Publishing and by Custom Web Publishing.

This process works with Active Directory on Windows Server, with Open Directory on Macintosh Server, and with local security groups on either platform, although in slightly different ways. However, contrary to popular belief, it does not work with generic LDAP server connections. Part of the FileMaker Server Administration Console has a configuration panel for LDAP. This has nothing at all to do with External Server Authentication. Additionally, and again contrary to popular belief, a Domain Controller is not required to make External Server Authentication work. The external Groups can be on the FileMaker Server itself.

So why use External Server Authentication? What are its capabilities? What are its benefits? What are its advantages? There are a number of these.

1. Use of External Server Authentication dramatically simplifies Account management, especially for many users across multiple files. Once the system is set up correctly, the Account name and password need be entered only one time and in only one place. It does not have to be entered individually in each file. For a system with 25 users and 15 files, that would be 375 separate entries in individual files, versus 25 entries in one place with External Server Authentication. The likelihood for error is dramatically reduced.

2. When using External Server Authentication and updating an existing FileMaker solution, the developer does not have to worry about reconciliation of Accounts and passwords added or deleted since the prior update. This is very helpful, especially when using The Separation Model™ construct. Accounts are not in the files, including UI and logic files. So there is nothing there that changes when a older version of a file is swapped out for a newer one.

3. External Server Authentication takes advantage of the security system that an IT department has already established in either a small organization or a large one. FileMaker developers can thereby leverage the usefulness and power of these assets. FileMaker developers and DBA’s are freed of the burden of managing Identity and Access Management by utilizing assets already in place.

4. In some circumstances, developers can take advantage of the power, usefulness, and convenience of Single SignOn, (SSO) also called Single Source LogOn. In such a system, once a user is authenticated by the Domain Controller for access to network assets such as file servers, printers, etc., that same authentication can be passed seamlessly to FileMaker Server. The user is then not required to enter additional credentials to access the FileMaker files. Users need to remember only one set of credentials; they are therefore thought not to be as likely to write their credentials down somewhere and leave them where they can be discovered. SSO works from Windows OS workstations to FileMaker Server running on a Windows OS Server. It does not work in any other configuration of Operating Systems; however, it can be emulated on Macintosh OS workstations by use of the KeyChain. Inappropriate KeyChain use can itself be a problem; such misuse can be managed. That is a topic perhaps for a future Blog posting here.

5. External Server Authentication, when used with a Domain Controller, can extend the scope of tools for Credentials Lifecycle Management. Length and complexity of passwords are better controlled. The same is true for blocking the repetitive use of the same password. Additionally Domain Controllers can manage the permissible days and times and locations of log-ons. Additionally, Domain Controllers can prevent simultaneous log-ons with the same credentials. External Server Authentication thus expands the range of Identity and Access Management controls beyond those found in the native FileMaker file itself.

There are a number of different configuration scenarios for External Server Authentication depending on the specific mix of Operating Systems in place among FileMaker Server machines, user workstations, and Domain Controllers. This topic is covered in vast detail in a White Paper I co-authored with FileMaker Server world class expert Wim Decorte. That paper, Server External Authentication, was last updated for FileMaker® Server 9 in 2008. However it contains information still pertinent and useful for FileMaker® Server 11.

To recap, External Server Authentication offers FileMaker developers and DBA’s as well as IT managers flexibility, ease of Account management, and utilization of a range of IT created security assets. It should be a core part of every FileMaker developer’s arsenal.

Steven H. Blackwell

Permissive Versus Restrictive Privileges In FileMaker Pro Databases

—By—

Steven H. Blackwell

April 25th 2011

In older versions of FileMaker Pro, those prior to FileMaker® Pro 7, privileges were, by default, permissive. This means that users were allowed to perform all actions by default. With the introduction of the modern versions of the FileMaker Family of Products, with their appropriate focus and attention to industry standards in the security realm, the default privileges became restrictive. This means that databases privileges, especially access to tables and records, are off or restricted by default and have to be specifically enabled for a user’s Privilege Set. Even for the [Full Access] Privilege Set, privileges related to connectivity to hosted files have to be enabled by the developer.

This change began in Version 7 and has continued to the present-day FileMaker® Pro 11 where significant additional protections were added, principally File Access Protection. This is an option that developers may invoke that prevents unauthorized references to a file that could result in data manipulation, script execution, value list item extraction, and Design Function penetrations in ways most developers did not contemplate happening. Additionally, in FileMaker Pro 11, the Available menu commands options setting for a newly created subordinate Privilege Set was changed from Full to Minimum to make that privilege bit’s behavior consistent with all the others. Thus, all privilege bit settings for a newly created subordinate level Privilege Set are either off or set at the most restrictive option.

When FileMaker Pro 7 was released, these changes caused some confusion and even a bit of consternation among both new and experienced users and developers. While much of that has abated over time, it still occasionally surfaces. Yet, I would assert, the present restrictive privilege settings are the correct ones to employ. Why?

A guiding principle of information asset security is the Rule of Least Privileges. That principle holds a user should have all necessary privileges to perform his or her respective role in the database system, but no greater privileges. The FileMaker Pro Role-based Privileges System conforms to this important industry standard principle.

In older versions developers had to try to close all open avenues of access to their database systems. Frequently such actions failed simply because even experienced developers did not know all the “open windows” so to speak. They could close and lock the “front door” and often the “back door” as well. But some windows would be left wide open. This made effective security implementation difficult, threatening both client data and developer intellectual property. The modern-day version of the product closes these wide-open avenues. Now, developers, for the overwhelming part, must explicitly authorize access and privileges. This allows them to protect client’s data and business processes management as well as to secure their own intellectual property.

Preservation of Confidentiality, Integrity, and Availability of digital assets, and sometimes of physical ones as well, is the over-arching purpose of information security in the modern world. FileMaker® Pro 11, the latest iteration of the product, provides more tools and features to accomplish effective security implementation than any prior version of the product. The Rule of Least Privileges is at its best implementation with the current version. I urge developers to employ these security features to their maximum effect.

Steven H. Blackwell

Steven H. Blackwell

Welcome to the first posting to my new FileMaker Security blog. From time to time, I’ll be discussing issues of significance and importance related to FileMaker Pro and FileMaker Server security. In all these discussions I will keep foremost the concept that security is supposed to be focused on the preservation of the Confidentiality, Integrity, and Availability (CIA) of digital assets, and sometime of physical ones.

This first posting will focus on issues related to cloud computing security for FileMaker Pro. The cloud is all the rage these days. Yet despite that high level of interest, cloud computing, especially in the FileMaker world, is poorly understood and confused with other elements to which it has no real relationship.

Gartner has estimated that some 60% of organizations are currently actively considering cloud computing. These organizations are eager to take advantage of the elasticity, scalability, and cost benefits that cloud computing offers.

Despite these benefits and despite the interest in cloud computing that organizations express, there are some serious caveats and reservations about taking an organization’s information assets and putting them into the cloud. If a data owner wants to employ the cloud, it must make serious efforts to guarantee trust, security, and control in cloud environments. Otherwise, its digital assets are at serious risk for having their Confidentiality, Integrity, and Availability breached.

At the 2010 RSA Security Conference in San Francisco, Phil Dunkleberger, President of PGP Computing, a leading information security industry company, offered the prescient and discerning observation that despite all the advantages the cloud might be able to offer, people are not flocking to the cloud and likely will not be doing so. Why? They don’t trust the cloud, he said. And there is good reason for their not trusting it.

FileMaker Pro solution developers and IT personnel administering FileMaker servers hosting those solutions need to take special care to be aware of these items. First, and foremost, there is no real “cloud computing” to speak of in the FileMaker world. Merely having remote hosting of FileMaker Pro databases on virtual or physical servers offered by some service provider somewhere outside the organization’s work locations does not, by any means, constitute Software as a Service (SaaS), Hardware as a Service (HaaS), or Platform as a Service (PaaS). SaaS, HaaS, and PaaS are the core elements of cloud computing.

Notwithstanding this however, there are any number of lessons and strictures drawn from cloud computing that can be applied to remote hosting of FileMaker databases. There are a variety of core questions for the owners of FileMaker Pro databases to ask about remote hosting, starting with “Why do you want to do this?” Usual answers include such elements as lack of organization expertise about FileMaker Server administration and configuration and desire to provide 24/7 monitoring of the servers. Good answers perhaps, but organizations may want to ask what other reasons they have for wanting remote hosting. And then they also will want to ask whether the risks associated both with the cloud and with remote hosting outweigh the benefits provided.

So here are a few core questions owners and administrators of FileMaker Pro databases may want to ask. There has been a lot of information in recent months published in various White Papers and Podcasts and offered at the 2011 RSA Security Conference about these concerns. Interested readers may want to explore these resources further, inasmuch as this is by no means a comprehensive list.

1. How are data protected, isolated, and shared? Whether you have trade secrets or commercial processes, or confidential organizational information about finances, customers/clients, or your own personnel information stored in your database, how are you going to protect these data once they go to a remote location. Not only that, but how are you going to assure data availability and integrity as well?

2. How will you address the loss of perimeter based controls present in the local enterprise? Remote sites likely will bypass organization security policies and procedures your organization has in place.

3. How will you address the challenges of multiple users’ sharing of common resources? These multi-tenancy issues can be especially difficult. How do you assure that some other organization that is also using the same provider or the same server hardware as you are isn’t able to access or to view your data? In other words, how safe is a multi-tenancy arrangement? How are the risks of using it going to be managed?

4. Who has responsibility for compliance with regulatory and statutory items related to any customer/client/member data that are stored in the database? Generally, such responsibility remains with organization that owns the data. It cannot for the most part be transferred to the provider. Significantly, if there is a breach, who bears responsibility and liability? Whose insurance covers this liability, partially or (not likely) fully?

5. What are the applicable laws governing access to the data housed at the remote site? These likely will vary according to the jurisdiction where the data actually are housed. Those laws in different jurisdictions will not be the same necessarily as are the laws where the organization itself operates or where it is legally registered and/or incorporated.

6. As the owner of the data, do you know what the scope of the protection is for the data that the provider is obligated to provide? What conditions govern the use and disclosure of data? And presuming such provider safeguards are identified or promised (even contractually), how does the owner of the data monitor the provider’s safeguards? And if shortcomings are detected, what is the responsibility of the provider to undertake any remedial action identified through such an audit process?

7. Who bears the cost of dealing with any breaches currently estimated at $204 per record?

8. Finally, if the arrangement with the remote provider collapses (for any number of reasons), how does the owner of the data terminate its relationship with provider and recover all its data and all its backups, and leave no copies of the data behind at the remote hosting site?

As a practical matter most providers will not have protections in place, and that increases the liability of the owners of the data. And so, despite the benefits of both cloud computing and remote hosting, data owners need to ask themselves whether a variety of risks associated both with the cloud and with remote hosting outweigh the benefits provided. They will want to ask how to guarantee and maintain trust, security, and control in these environments. I look forward to further discussion of these items in the FileMaker community.

Steven H. Blackwell

×

Important Information

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