FileMaker Security in the Enterprise

Dimitris Kokoutsidis 29 mins0

Alan Deffenderfer, FileMaker DevCon 2017

Menu

Introduction to Enterprise FileMaker Security

To top

FileMaker is increasingly becoming a trusted tool in enterprise environments, and with this growth comes the need for heightened security. In this session, Alan Deffenderfer shares his firsthand experience working with FileMaker in the Defense Sector over a period of three and a half years. Throughout this time, Alan encountered both successes and challenges in meeting the compliance requirements of highly regulated environments.

The Importance of Security in Enterprise FileMaker

Enterprise systems manage vast amounts of sensitive data, from Personally Identifiable Information (PII), such as names, social security numbers, and dates of birth, to Protected Health Information (PHI) in healthcare settings. FileMaker’s ease of use and rapid development capabilities often make it an attractive platform for both citizen developers and enterprise IT teams. However, with great flexibility comes the need for comprehensive security measures.

The security framework for enterprise FileMaker deployments must focus on not just technical safeguards but also on management and operational controls. Enterprises must implement stringent measures, such as Encryption At Rest (EAR), access control policies, and user authentication mechanisms, to protect their systems from potential breaches.

In this session, Alan addresses the lessons learned from deploying FileMaker solutions in high-security environments, offering strategies that go beyond simple technical fixes and include holistic, defense-in-depth approaches to security.

The CIA Triad and Its Relevance to FileMaker

To top

Understanding the CIA Triad

The CIA Triad—Confidentiality, Integrity, and Availability—is the cornerstone of information security, especially within enterprise environments. Each element of the triad serves a specific function:

  1. Confidentiality: Ensures that sensitive information is accessible only to authorized individuals. In a FileMaker context, this includes setting up role-based access controls, limiting the number of users who can view or modify critical data, and ensuring strong authentication methods.
  2. Integrity: Guarantees that data remains accurate and consistent over its lifecycle. FileMaker developers must ensure that data is protected from accidental or malicious modification by implementing proper transaction handling and version control.
  3. Availability: Ensures that information is readily accessible to authorized users when needed. In enterprise settings, FileMaker systems must be configured to maximize uptime and ensure resilience against denial-of-service (DoS) attacks or other disruptions that could impact availability.

How the CIA Triad Applies to FileMaker Deployments

For FileMaker to be successful in an enterprise environment, all three pillars of the CIA Triad must be rigorously applied. One of the key features that support confidentiality in FileMaker is Encryption At Rest, which ensures that sensitive data is encrypted while stored in the database file.

Moreover, integrity in FileMaker can be safeguarded by using privilege sets, which control who can modify records or schema elements. It’s also crucial to enforce strong audit mechanisms, such as transaction logging, to detect and address any unauthorized data modifications.

Lastly, to ensure availability, enterprise-level FileMaker deployments must implement proper backup strategies, load balancing, and disaster recovery plans. Alan emphasizes the need to carefully plan for these aspects during deployment, ensuring that the solution can handle the demands of a large-scale enterprise environment.

FileMaker in High-Compliance Environments

To top

Challenges of Meeting Compliance in Defense and Other Regulated Sectors

Deploying FileMaker in environments like the Department of Defense (DoD) presents a unique set of challenges. Security requirements in these environments often go beyond what is typical in commercial enterprise settings, demanding a much higher level of rigor and compliance with frameworks like NIST, ISO 27001, and GDPR.

One of the most important considerations is that compliance isn’t just about securing the system at the technical level—it also includes management and operational controls. In the DoD, for example, separation of duties is required, meaning that the developer, database administrator (DBA), and system administrator roles must be kept distinct to reduce the risk of insider threats.

FileMaker as Shadow IT

In large enterprises, FileMaker is sometimes seen as shadow IT, meaning that it is not officially sanctioned by the corporate IT department. While FileMaker offers rapid development capabilities, its ease of deployment can cause tension with enterprise IT teams who are responsible for managing security across the organization.

Alan points out that one of the keys to overcoming this perception is to ensure that FileMaker solutions adhere to enterprise security frameworks from the outset. This includes implementing Encryption At Rest, securing data in transit using SSL certificates, and integrating FileMaker with enterprise authentication systems, such as Active Directory.

Bimodal IT in Enterprise Environments

Alan describes how FileMaker often functions in a bimodal IT environment, where it serves as a rapid application development tool that complements larger, more traditional enterprise systems. This dual mode allows for fast prototyping and solution development, but it also requires special care to ensure that security best practices are followed, even in these agile development cycles.

Common Security Terms Explained

To top

Key Security Terminology

Understanding security terminology is essential when working with enterprise IT teams, especially when deploying FileMaker solutions in high-compliance environments. Here’s a deeper dive into the key terms:

  1. Threat: A potential event that could cause harm to an organization’s systems or data. In the FileMaker context, threats can range from malicious insiders to external hackers attempting to breach the system.
  2. Vulnerability: A weakness in the system that can be exploited by a threat. Common vulnerabilities in FileMaker deployments might include weak user passwords, unsecured API endpoints, or misconfigured access privileges.
  3. Impact: The consequence of a successful attack or breach. For example, a breach of a FileMaker solution containing PII could result in fines, legal action, and damage to the organization’s reputation.
  4. Risk: The combination of the likelihood of a threat exploiting a vulnerability and the potential impact of that event. Risk assessment is a continuous process and must be updated regularly, especially as new vulnerabilities emerge or as the system grows in complexity.
  5. Countermeasures: The steps taken to mitigate threats and reduce vulnerabilities. Examples include enabling two-factor authentication (2FA), encrypting data at rest, and using firewalls to protect the FileMaker server.

How to Communicate Security Effectively

Alan emphasizes that knowing these terms is critical when engaging with clients, IT teams, and other stakeholders. Using clear and consistent terminology helps ensure that everyone is on the same page when discussing security measures for FileMaker deployments.

Mitigating Risk with Encryption At Rest

To top

The Importance of Encryption At Rest (EAR)

One of the simplest and most effective ways to mitigate risk in FileMaker deployments is by enabling Encryption At Rest (EAR). EAR ensures that sensitive data stored within the FileMaker file remains protected, even if the file is stolen or accessed outside of the secure environment.

Without EAR, anyone who gains access to the physical FileMaker file could potentially extract its contents. This is particularly important for solutions that handle PII, financial data, or medical records, as a data breach could lead to severe consequences, including regulatory fines and damage to the organization’s reputation.

Enabling EAR in FileMaker

Alan provides a detailed walkthrough on how to enable EAR in FileMaker:

  1. Move the File Off the Server: To enable encryption, first move the file off the server. It’s important to work with a backup or staging copy of the file during the encryption process.
  2. Use Developer Utilities: Open the Developer Utilities under the Tools menu, and select the file(s) you want to encrypt. In a multi-file solution, ensure that all relevant files are selected for encryption.
  3. Set the Encryption Password: Choose a strong password for the encryption, ideally following DoD-compliant standards (e.g., 15 characters with a mix of letters, numbers, and special characters).
  4. Shared Encryption Key: For solutions with multiple files, using a shared encryption key allows the FileMaker Server to decrypt all the files with a single password, simplifying management during deployment.

Advantages of EAR

EAR mitigates several key risks:

  • Prevents Data Theft: Even if the file is stolen, it cannot be opened or read without the encryption key.
  • Compliance: EAR helps organizations comply with regulatory requirements, such as GDPR and HIPAA, which mandate encryption for sensitive data.
  • Data Integrity: Encryption also helps protect the integrity of the data by ensuring that unauthorized users cannot tamper with it.

Deployment Strategies for Secure FileMaker Implementations

To top

Planning for Secure Deployments

Deploying FileMaker securely in an enterprise environment involves more than just turning on encryption. A well-thought-out lifecycle strategy must be in place to ensure that security measures evolve with the system. Alan emphasizes the importance of a defense-in-depth approach, where multiple layers of security are implemented to protect the system from various attack vectors.

Firewalls and Network Configuration

In a high-security enterprise environment, firewalls play a critical role in protecting the FileMaker server. The web server (such as Apache or IIS) that hosts WebDirect or custom web publishing must be secured with a firewall to ensure that unauthorized users cannot access the system. Proper port configurations and SSL certificates are also essential for securing data in transit.

Multi-Server Deployments

Alan also discusses the importance of multi-server deployments in large organizations. Separating the database server from the web server ensures that WebDirect traffic is isolated from the backend systems, providing an extra layer of security. In addition, using load balancers and redundant servers can help ensure that the system remains available even in the event of a hardware failure or denial-of-service (DoS) attack.

Operational Challenges in Defense and Enterprise Settings

To top

Separation of Duties and FileMaker Security Compliance

Separation of duties (SoD) is a principle designed to reduce the risk of fraud and errors by ensuring that no single individual has complete control over all aspects of a system. In high-compliance environments such as government or finance, enforcing SoD is mandatory.

In the context of FileMaker, implementing SoD can be challenging, but it’s crucial for compliance with certain regulatory frameworks like the Department of Defense’s Stig compliance. Here’s how it can be done:

  • Developers vs. DBAs: In an SoD-compliant environment, developers who build the solution should not be the ones deploying it. Instead, the responsibility for managing the FileMaker database (DBA tasks like backups, maintenance, and access control) should fall to a different individual or team.
  • Access Control: Developers may need to write scripts or design layouts, but they should not have access to sensitive data in the production environment. Likewise, DBAs should not modify the application’s business logic.
  • System Administrators: System administrators responsible for managing FileMaker Server should not have access to the databases hosted on it. Their job is to manage the infrastructure, not the data within it.

While this separation of duties adds complexity to the management of a FileMaker solution, it is a vital layer of protection against insider threats and compliance violations.

The Need for Custom SSL Certificates

To top

One of the most significant operational challenges Alan Deffenderfer faced while working in the Department of Defense (DoD) was the implementation of custom SSL certificates. SSL (Secure Sockets Layer) certificates are critical in enterprise environments, ensuring that all communication between the FileMaker Server and client applications (including FileMaker Pro, WebDirect, and custom web publishing systems) is encrypted and secure.

In the DoD and other high-security sectors, public certificate authorities (CAs) such as GoDaddy, Verisign, or DigiCert could not be used due to strict internal security policies. Publicly trusted CAs, while secure and widely accepted, were not allowed in these environments because the DoD required certificates to be issued by their own internal or approved certificate authority (CA). This policy was in place to ensure that all encryption keys and certificates were tightly controlled within the organization’s security perimeter.

Challenges of DoD-Issued Certificates

Unlike public CAs, DoD-issued SSL certificates often come with a unique set of challenges:

  1. Custom Configuration Requirements: FileMaker Server does not inherently trust certificates that are issued by non-public CAs. Therefore, when using DoD-issued certificates, administrators need to manually configure the server to recognize and accept these certificates. This involves importing the DoD’s root and intermediate CA certificates into FileMaker Server’s trust store to establish a valid chain of trust.
  2. Complexity of Deployment: FileMaker’s native SSL certificate handling is streamlined for certificates from public CAs, which are pre-trusted by most operating systems. However, internal certificates require additional steps, such as ensuring the private key and certificate signing request (CSR) are correctly generated, and the DoD certificate authority signs it properly. This process often involves back-and-forth communication between the IT security team and the system administrator managing the FileMaker deployment.
  3. Revocation and Compliance Management: DoD environments require rigorous management of certificate revocation lists (CRLs) and OCSP (Online Certificate Status Protocol) stapling. These ensure that if a certificate is compromised, it can be revoked swiftly, and clients will be notified if they are connecting to an invalid or revoked certificate. Ensuring compliance with DoD’s PKI (Public Key Infrastructure) requirements adds another layer of complexity, as these mechanisms must be configured and tested thoroughly.
  4. Certificate Rotation and Renewal: In high-compliance environments like the DoD, SSL certificates typically have a shorter lifecycle compared to commercial deployments. Regular rotation of certificates (e.g., every 6-12 months) is mandated to reduce the risk of using compromised keys. This means that FileMaker administrators need to plan for frequent renewals, which involve regenerating the CSR, obtaining a new certificate, and repeating the configuration process.

SSL Certificate Management in FileMaker 16

To top

With the release of FileMaker 16, there were several improvements to how SSL certificates were handled, but even these enhancements required careful planning in high-compliance environments. Some key improvements included:

  1. Streamlined Certificate Import Process: FileMaker 16 introduced a more intuitive process for installing and managing SSL certificates. While this made it easier for public certificates, custom certificates (like those from the DoD) still required manual steps. FileMaker Admin Console allowed for better visibility into the certificate status, helping administrators see whether the installed certificate was valid, expired, or not trusted.
  2. Improved SSL Configuration: FileMaker 16 enhanced the SSL/TLS (Transport Layer Security) protocols, providing better support for modern encryption standards and making the platform more robust against attacks like man-in-the-middle (MITM). However, when dealing with DoD-issued certificates, administrators needed to ensure that strong ciphers and forward secrecy were enforced in compliance with DoD encryption policies.
  3. Compatibility with DoD Requirements: Despite these improvements, using custom SSL certificates in DoD settings still required administrators to fully understand PKI architecture and how to configure FileMaker to work within those constraints. Alan noted that while FileMaker Server 16 simplified some aspects of SSL management, it did not eliminate the need for manual intervention when working with non-standard or custom certificates.

Best Practices for Deploying Custom SSL Certificates in FileMaker

To top

To successfully implement DoD-issued SSL certificates or other custom certificates in FileMaker, the following best practices should be followed:

Enable CRLs and OCSP Stapling: Implement Certificate Revocation List (CRL) checks and OCSP Stapling to ensure that invalid certificates are detected and not trusted by the system.

Generate the Certificate Signing Request (CSR) Correctly: Ensure the CSR is generated on the FileMaker Server and matches the server’s fully qualified domain name (FQDN). The CSR should be signed by the DoD’s internal CA.

Manually Install the CA Root and Intermediate Certificates: Import the root and intermediate CA certificates into the FileMaker Server’s operating system to establish trust for the custom certificate.

Configure SSL/TLS Settings in Compliance with DoD Standards: Ensure that strong encryption protocols (such as TLS 1.2 or higher) are enabled, and weak ciphers are disabled in the FileMaker Server configuration. This ensures compliance with DoD encryption standards.

Test the Certificate Thoroughly: Before going live, test the SSL certificate by accessing the FileMaker Server through various client applications (e.g., FileMaker Pro, WebDirect). Verify that the certificate is correctly installed, trusted, and that no security warnings are triggered.

Monitor and Manage Certificate Expiry: Use monitoring tools to keep track of certificate expiration dates, ensuring that certificates are renewed well before they expire to avoid service disruptions.

Key Takeaways

To top

In conclusion, deploying FileMaker in enterprise environments, especially in high-security sectors like defense, requires a thorough understanding of security principles and compliance requirements. The key takeaways from this session include:

  1. Encryption At Rest (EAR) is essential for protecting sensitive data. Every FileMaker solution that handles PII or other sensitive information should have EAR enabled.
  2. The CIA Triad—Confidentiality, Integrity, and Availability—should guide all security decisions in FileMaker deployments.
  3. Separation of duties and other operational controls are critical in high-compliance environments. Developers, DBAs, and system administrators should have distinct roles to prevent insider threats.
  4. Firewalls, SSL certificates, and secure network configurations are essential for protecting data in transit and ensuring that WebDirect and other web-based services are secure.
  5. FileMaker is often seen as shadow IT in large enterprises. Overcoming this perception requires demonstrating that FileMaker solutions can meet the same security and compliance standards as other enterprise systems.

By following these best practices, FileMaker developers and administrators can ensure that their solutions not only meet regulatory requirements but also stand up to the rigorous security demands of enterprise environments.

DevCon 2017 Alan Deffenderfer, ABD Enterprises

Dimitris Kokoutsidis