Sarbanes-Oxley FTP Server - 10 Steps Towards Compliance
The Sarbanes-Oxley Act of 2002 requires that public companies implement IT controls to assure the accuracy of company financial records. These controls must include IT processes that provide for the security of data, central management of user accounts and the ability to audit and report on both internal and external file transfers.
This article focuses on ways in which you can configure your FTP server to be Sarbanes-Oxley compliant.
Disclaimer. These steps if followed properly should assist you in meeting compliance but in no way guarantee that you will pass a SOX audit by following these steps alone.
It is important to SOX compliance that you be able to track who is accessing company resources. Many FTP servers have anonymous access enabled by default, making it impossible to track who is behind anonymous connections. By disabling anonymous access to your FTP server you ensure that only authorized users are granted access to company resources.
Access rules should be implemented either at the firewall or FTP server level that restrict access to the FTP server based on client IP address. This ensures that only known users from known sources are able to access your FTP servers.
In order to demonstrate that you have control over what resources your users may access it is good practice to use a central user repository. Examples of central user repositories include LDAP, Active Directory and relational databases. Having your FTP server (and other applications) authenticate users against a central repository makes the process for revoking a users access rights a simple matter of disabling or deleting the user in the repository. This is compared against applications that each have their own separate user repository, where revoking a users access requires updating the repository for each application the user has access to. This is obviously more error prone than using a central repository as it requires knowledge of what applications a user has access to.
FTP servers by default are typically configured to accept unencrypted FTP sessions. Users connecting using an unencrypted FTP session risk account credentials and data being intercepted by unauthorized users. To help meet Sarbanes-Oxley data security requirements you should configure your FTP server to allow only SSL encrypted FTP sessions.
Sarbanes-Oxley compliance is big on making sure that routine processes are automated and well documented. Therefore, any FTP jobs that exchange data with your customers should be automated and thoroughly documented. This demonstrates to a SOX auditor that you know exactly what data is entering and leaving your company FTP servers. All file transfer activity for these processes should also be logged and report accessible as defined in the Log FTP server activity and Report on FTP server activity steps.
In the event your FTP server is attacked you should have automated processes in place designed to prevent further attack and possible unauthorized access to the system. FTP server attacks come in various flavors, however the most common is a brute-force password attack. In a brute-force password attack the attacker is trying to gain unauthorized access by guessing the password of a known user account. This attack can take time however with the aid of tools that automate FTP login, accounts can be easily compromised given enough time. You should have automated processes in place that detect if an account has unsuccessfully attempted login too many times within a given period and automatically disable the account and/or block the source IP address from further connections. This process should also notify one or more system administrators of the incident so they may investigate the incident further.
When data uploaded to your FTP server you may consider adding automated processes for encrypting that data to protect it while at rest. Public-key encryption tools like OpenPGP are ideal for managing this process. Encrypting data at rest ensures that even if an attacker gained access to your system they would not be able to read the data without the decryption key.
In the event of a server crash or corrupt FTP server configuration you should have processes in place to restore your FTP server configuration easily. Ideally your FTP server configuration files should be backed up on a regular basis, at a minimum each time the server configuration is updated. Documentation that details how to backup and restore FTP server configuration files should also be made available.
Establish processes that log all FTP server activity. Ideally this data should be logged to a secure remote repository to prevent any tampering. An example of a secure remote repository might be a relational database with limited user access only allowing for reading and adding records with permissions that prevent the update or deletion of existing records.
The ability to easily report on FTP server activity is critical in the event of an audit or security breach. For example, in the event of a security breach you need to be able to quickly identify what files were accessed in order to assess and respond to the breach. In the last year alone several million records have been stolen from financial institutions and businesses that handle sensitive data. Unfortunately the true scope of many of these incidents is often unknown until months later. This is due in large part to poor logging and reporting tools. Ideally you should run reports on a regularly scheduled basis. This will help you to become familiar with your own traffic patterns and more easily identify a security breach should it occur.
Summary
We hope that this article was useful in identifying ways to assist you in making your FTP servers Sarbanes-Oxley compliant. Please view the JSCAPE Secure FTP Server - Sarbanes-Oxley Compliance Statement for more information on how JSCAPE Secure FTP Server addresses compliance needs.
More information on JSCAPE Secure FTP Server
Download JSCAPE Secure FTP Server Evaluation
|
