Sarbanes Oxley (SOX)
The Sarbanes Oxley Act is a US federal law, enacted on 30th July 2002, governing financial reporting and accountability processes within public companies. The legislation was brought into force as a safeguard, following a succession of corporate accounting scandals, involving a number of high profile organisations. These companies purposefully manipulated financial statements, costing investors billions of dollars.
Sarbanes Oxley (SOX) contains 11 titles, detailing specific actions and requirements that must be adopted for financial reporting, ranging from corporate board responsibilities to criminal penalties incurred as a consequence of non-compliance. The most significant of these titles in terms of data transfer is section 404.
Sarbanes Oxley Standards
Section 404 states companies governed by SOX are required to:
- Publish information in their annual reports, stating the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting, detailing the scope and adequacy.
- Include an assessment of the effectiveness of internal controls.
What are the implications of SOX in terms of file transfer?
In order to provide this information and ensure compliance with US law, public accounting companies must implement large file transfer processes that ensure:
- The accurate recording of all financial data, including auditing logs.
- Regulate access to and modification of all financial data by unauthorised users.
- Track activity of data as it crosses application and organisational barriers.
Our specialists at Pro2col can help you to source and implement a SOX compliant secure file transfer solution to suit your business requirements. Please contact us on 0333 123 1240 for more information.
Secure File Transfer
Security is of paramount importance in today’s corporate environments, due to the sensitive nature of the information that they hold. Industry standards such as PCI DSS, Sarbanes Oxley and HIPAA dictate an organisation’s responsibility to secure such information and as such, the need for secure file transfer solutions has become a priority.
A number of secure file transfer protocols have been developed over the years as a solution to the issue of data security. As there are several different ways of sending and receiving files e.g. HTTP (via a web browser), FTP (client to server) and Email, there are a variety of security protocols used to secure communication channels. The key secure file transfer protocols include:
- FTPS (FTP run over SSL/TLS)
- SFTP (SSH – Secure Shell protocol)
The FTPS and HTTPS file transfer protocols send files over a TCP connection. This TCP connection has a TLS(transport layer security) or SSL (secure socket layer) security layer that runs beneath the FTP and HTTP protocols. SSL simplified is a protocol that establishes an agreement between a client/browser and a server. The sending side uses a public key to encrypt a data file, which is then sent using either the FTP or HTTP file transfer protocol. The receiving side will have, as part of the agreement, a unique private key that can decrypt the data file.
SFTP is not FTP run over SSH, but rather a stand alone secure file transfer protocol designed from the ground up. The file transfer protocol itself does not provide authentication and security; it expects the underlying protocol (SSH) to secure this. SSH is used to establish a connection between a client and server that acts like an encrypted tunnel. This encrypted tunnel protects any data files that are sent via this secure connection.
If you want to find out more information about secure file transfer solutions, please contact Pro2col on 0333 123 1240.
Self-provisioning is the ability for individual end users and partners to set up (or “provision“) their own accounts.
Self-provisioning is a common element of most cloud services but remains relatively rare in file transfer applications. A major difference between those environments is that self-provisioning in cloud services usually involves linking a credit card or other form of payment to each provisioned account. This gives cloud services two important things that encourage the use of self-provisioning: a third-party validation of a user’s identity and an open account to bill if things go astray. File transfer environments also involve a lot of trusted links and require, either by law or regulation, human intervention before such a link is authorised.
BEST PRACTICE: Self-provisioning may or may not be right for your environment. As is the case with many types of automation, evaluation of this technology in a file transfer environment should involve a cost-benefit analysis of manually provisioning and maintaining groups of users vs. building a self-provisioning application that meets your organisation’s standards for establishing identity and access. An common alternative that lies between manual provisioning and self-provisioning is the ability to delegate permission to provision a partner’s user to a particular partner’s administrator. (File transfer Community Management often involves delegating provisioning privileges this way.)
The Single Euro Payments Area (SEPA) is an EU initiative to unify payments within the EU. It is primarily driven by the European Payments Council. (SEPA is not, by itself, a standard.)
Service Level Agreement
A file transfer service level agreement (SLA) establishes exactly what a particular customer should expect from a particular file transfer provider, and how that customer should seek relief for grievances.
A file transfer SLA will often contain the following kinds of service expectations:
Availability: This expresses how often the file transfer service is expected to be online. An availability SLA is often expressed as a percentage with a window of downtime. For example: “99.9% uptime except for scheduled downtime between 2:00am and 5:00am on the second Sunday of the month.”
Different availability SLAs may be in effect for different services or different customers. Availability SLAs are not unique to file transfer; most Internet-based services contain an availability SLA of some kind.
Round-Trip Response Time: This expresses how fast a complete response to a submitted file will be returned. A round-trip response time SLA is often expressed as a certain length of time. For example, “we promise to return a complete response for all files submitted within 20 minutes of a completed upload”. Sometimes a statistical percentage is also included, as in “on average, 90% of all files will receive a completed response within 5 minutes.”
The reference to “round-trip” response time rather than just “response time” indicates that the time counted against the SLA is the total time it takes for a customer to upload a file, for that file to be consumed and processed internally, and for any response files to be written and made available to customers. Simple “response time” could just indicate the amount of time it would take the system to acknowledge (but not process) the original upload.
Different round-trip response time SLAs may be in place for different customers, types of files or times of day. Round-trip response time SLAs are similar to agreements found in physical logistics: “if you place an order by this time the shipment will arrive by that time.”
Completed Body of Work: This expresses that a particular set of expected files will arrive in a particular window and will be appropriately handled, perhaps yielding a second set of files, within the same or extended window. For example, “we expect 3 data files and 1 control file between 4pm and 8pm everyday, and we expect 2 response files back at any time in that window but no later than 9pm”
Files in a body of work can be specified by name, path, size, contents or other pieces of metadata. There are typically two windows of time (“transmission windows“) associated with a body of work: the original submission window and a slightly larger window for responses.
SLAs can be set up between independent partners or between departments or divisions within an organisation. A less stringent form of SLA known as an operating level agreement (OLA) when it is between two departments in the same organisation, especially when an OLA is set up to help support a customer-facing SLA.
BEST PRACTICE: A good file transfer SLA will contain expectations around availability and either round-trip response times or expected work to be performed in a certain transfer window, as well as specific penalties for failing to meet expectations. File transfer vendors should provide adequate tools to monitor SLAs and allow people who use their solutions to detect SLA problems in advance and to compensate customers appropriately if SLAs are missed.
SFTP File Transfer
SFTP file transfer or the ‘SSH file transfer protocol’ as it is more formally known, is a network communications protocol used for sending data securely over a network. A common misconception associated with SFTP is that it uses FTP run over SSH – this is not the case. SFTP, sometimes referred to as ‘secure file transfer protocol’, is an independent protocol that has been developed from scratch.
Built to look and feel like FTP due to its popularity, SFTP was developed as a secure alternative to FTP. Based on the Secure Shell protocol, SFTP encrypts both the data before transmission and the commands (using SSH key-exchange algorithms) between servers. This provides dual protection against eavesdroppers and hackers, ensuring any data sent using this SFTP remains totally secure.
Not only a dedicated file transfer protocol, SFTP enables permission and attribute manipulation, file locking and more functionality. Saying this, a draw back associated with the use of SFTP is the limited number of client applications available that are actually compatible with SFTP servers.
The default port for SFTP is port 22.
If you would like to know what Pro2col can do for you in terms of secure file transfer, please contact us on 0333 123 1240.
SHA-1 (“Secure Hash Algorithm #1”, also “SHA1”) is the second most common data integrity check standard (a.k.a. “hash”) used throughout the world today. SHA-1 codes are 160-bit numbers and are usually represented in hexadecimal format (e.g., “de9f2c7f d25e1b3a fad3e85a 0bd17d9b 100db4b3”).
SHA-1 is the least secure hash algorithm NIST currently supports in its FIPS validated cryptography implementations. However, SHA-1 is faster than SHA-2 (its successor) and is commonly available in file transfer technology today (e.g., FTP’s unofficial “XSHA1” command).
BEST PRACTICE: Modern file transfer deployments should use FIPS-validated SHA-1 or SHA-2 implementations for integrity checks. Some SHA-1 usage is already prohibited in high-security environments.
SHA-2 (“Secure Hash Algorithm #2”) is the most secure hash algorithm NIST currently supports in its FIPS validated cryptography implementations. SHA-2 is really a collection of four hashes (SHA-224, SHA-256, SHA-384 and SHA-512), all of which are stronger than SHA-1.
Complete SHA-2 implementations in file transfer are still uncommon but becoming more common as time passes.
A “SHA-3” contest to find a future replacement for SHA-2 is currently underway and expected to conclude in 2012.
BEST PRACTICE: Modern file transfer deployments should use FIPS validated SHA-1 or SHA-2 implementations for integrity checks.
SHA-224 is the 224-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”). It is not a unique hash algorithm within the SHA-2 standard but is instead a truncated version of SHA-256. See “SHA-2” for more information.
SHA-256 is the 256-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”). Like SHA-512, it is one of two unique algorithms that make up a SHA-2 hash, but SHA-256 is optimized for 32-bit calculations rather than 64-bit calculations. See “SHA-2” for more information.
SHA-3 refers to the new hash algorithm NIST will choose to someday replace SHA-2. A contest to select the new hash is scheduled to conclude in 2012.
SHA-384 is the 384-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”). It is not a unique hash algorithm within the SHA-2 standard but is instead a truncated version of SHA-512. See “SHA-2” for more information.
SHA-512 is the 512-bit component of the “SHA-2” data integrity check standard (a.k.a. “hash”). Like SHA-256, it is one of two unique algorithms that make up a SHA-2 hash, but SHA-512 is optimized for 64-bit calculations rather than 32-bit calculations. See “SHA-2” for more information.
SLA is an abbreviation for “Service Level Agreement“, which is a specific contract between a customer and a provider that lays out exactly what each side can expect from the other. The minimum amount of work and minimum level of due care that a file transfer operations team is responsible for is often determined by the SLAs it must meet.
See “Service Level Agreement” for more information.
SMTP is an email protocol used to push messages and attachments from server to server. Many technologies have been used to secure SMTP over the years, but the best technologies available today use SSL (version 3) or TLS to secure the entire SMTP connection.
SMTP typically uses TCP port 25 to move unsecured traffic and often uses TCP port 465 to move secured traffic. Use of alternate ports with SMTP is extremely common to reduce connections from spammers who try to exploit servers listening on the most common ports.
BEST PRACTICES: SMTP should always be secured using SSL (version 3) or TLS. If your file transfer deployment uses email notifications, then email sent through SMTP should either always be accepted within a few seconds or should be automatically queued up in the file transfer application in case of delay. If SMTP services are unreliable and no queue mechanism exists in your file transfer solution, then a standalone mail server relay should be implemented to ensure that timed-out notifications do not cause unnecessary delay or failure of file transfer activities.
SSH File Transfer
SSH (Secure Shell) is a network protocol used to establish a secure connection between a client and server. Once a connection has been established, it acts like an encrypted tunnel down which data can be exchanged securely. SSH file transfer is used to maintain the confidentiality and integrity of data communications over insecure networks such as the Internet.
SSH file transfer also provides password authentication using public-key cryptography. This form of cryptography works on a Private Key, Public Key system – the sending side has one of each, as does the receiving side of the transfer. Messages are encrypted with the recipient’s public key and can only be decrypted with the corresponding private key.
Originally developed as a replacement for Telnet and other insecure remote shells SSH is used principally on Linux and Unix based systems to access shell accounts.
The default port for SSH is port 22.
SSL (“Secure Sockets Layer”) was the first widely-deployed technology used to secure TCP sockets. Its use in HTTPS (HTTP over SSL) allowed the modern age of “ecommerce” to take off on the world wide web and it has also been incorporated into common file transfer protocols such as FTPS (FTP over SSL) and AS2.
In modern usage, “protected by SSL”, “secured by SSL” or “encrypted by SSL” really means “protected by TLS or SSL version 3, whichever gets negotiated first.” By 2010 clients and servers knew how to negotiate TLS sessions and will attempt to do so before trying SSL version 3 (an older protocol). Version 2 of SSL is considered insecure at this point and some clients and servers will attempt to negotiate this protocol if attempts to negotiate TLS or SSL version 3 fail, but it is rare that negotiation falls through to this level.
SSL depends on the use of X.509 certificates to authenticate the identity of a particular server. The X.509 certificate deployed on an SSL/TLS server is popularly referred to as the “server certificate”. If the name (CN) on the server certificate does not match the DNS name of a server, clients will refuse to complete the SSL/TLS connection unless the end user elects to ignore the certificate name mismatch. (This is a common option on web browsers and FTP clients.) If the server certificate is expired, clients will almost always refuse to complete the SSL/TLS connection. (Ignoring certificate expiration is usually not an option available to end users.) Finally, if the server certificate is “self signed” or is signed by a CA that the client does not trust, then most clients will refuse the connection. (Browsers and FTP clients usually have the option to either ignore the CA chain or import and trust the CA chain to complete the negotiation.)
Optional X.509 client certificates may also be used to authenticate the identity of a particular user or device. When used, this certificate is simply referred to as a “client certificate.” File transfer servers either manually map individual client certificates to user codes or use LDAP or Active Directory mappings to accomplish the same goal. File transfer servers rarely have the ability to ignore expired certificates, often have the ability to import a third-party CA certificate chain, and often have the ability to permit “self-signed” certificates.
Whether or not client certificates are in use, SSL/TLS provides point-to-point encryption and tamper protection during transmission. As such, SSL/TLS provides sufficient protection of “data in motion”, though it provides no protection to “data at rest.”
SSL/TLS connections are set up through a formal “handshake” procedure. First, a connecting client presents a list of supported encryption algorithms and hashes to a server. The server picks a set of these (the combination of algorithms and hashes is called a “ciphersuite”) and sends the public piece of its X.509 server certificate to the client so the client can authenticate the identity of the server. The client then either sends the public piece of its X.509 client certificate to the server to authenticate the identity of the client or mocks up and sends temporary, session-specific information of a similar bent to the client. In either case, key exchange now occurs.
When you hear numbers like “1024-bit”, “2048-bit” or even “4096-bit” in relation to SSL, these numbers are referring to the bit length of the keys in the X.509 certificates used to negotiate the SSL/TLS session. These numbers are large because the exchange of keys in asymmetric public-key cryptography requires the use of very large keys, and not every 1024-bit (etc.) number is a viable key.
When you hear numbers like “80-bit”, “128-bit”, “168-bit” or even “256-bit” in relation to SSL, these numbers are referring to the bit length of the shared encryption key that is negotiated during the handshake procedure. This number is dependent on the algorithm available on clients and servers. For example, the AES algorithm comes in 128-bit, 192-bit and 256-bit editions, so these are all possible values for software that supports AES.
It is uncommon to refer to hash bit lengths in conversations about SSL; instead the named hash – typically MD5 or SHA-1 – is typically stated instead.
The three most important implementations of TLS/SSL today are Microsoft’s Cryptographic Providers, Oracle’s Java Secure Socket Extension (“JSSE”) and OpenSSL. All of these libraries have been separately FIPS validated and all may be incorporated into file transfer software at no charge to the developer.
BEST PRACTICE: The SSL/TLS implementation in your file transfer clients and servers should be 100% FIPS validated today. More specifically, the following file transfer protocols should be using FIPS validated SSL/TLS code today: HTTPS, FTPS, AS1, AS2, AS3 and email protocols secured by SSL/TLS. Modern file transfer software supports the optional use of client certificates on HTTPS, FTPS, AS1, AS2 and AS3 and allows administrators to deny the use of SSL version 2. If you plan to use a lot of client certificates to provide strong authentication capabilities, research the level of integration between your file transfer software, your enterprise authentication technology (e.g., Active Directory) and your PKI infrastructure.
Subject Access Requests (SARs)
Under GDPR, the data subject has the right to request all personal data a data controller has on them. This includes their supply chain.
The Society for Worldwide Interbank Financial Telecommunication (SWIFT) runs a popular system used by banks around the world to quickly exchange transactions with each other. Most international interbank messages use this system. Unlike clearing houses or other institutions that provide intermediate or final settlement of financial transactions, SWIFT is simply a secure transaction service. Remote banks may use the system to directly transact with one another, but SWIFT is not itself responsible in any activity that may occur within any bank-to-bank transaction.
SWIFT provides limited file transfer services. For example, SWIFTNet Mail can be used to intercept messages bearing attachments and route them to other SWIFT members through the SWIFT network rather than the open network. Internally, SWIFT has standardized on XML-wrapped transactions in its store-and-forward architecture.
Though an early advocate of near-realtime geographic redundancy across continents (North America and Europe), SWIFT pulled all operations back into the EU in 2009 after a 2006 ruling in which the Belgium government declared that SWIFT cooperation with U.S. Federal authorities were a breach of Belgian and EU privacy laws. (Today, cloud service providers often avoid spanning geopolitical boundaries because of this and similar landmark rulings.)