The Secure Auditable File Exchange Protocol (SAFE) is a method of securely and auditably transferring data files and has significant advantages over conventional ‘open standards’ file transfer protocols such as FTP.
An intrinsic property of the SAFE client software is that it records a full audit trail of every file sent and received from sending application to recipient application. This information can be used to determine the precise date and time every file reached each stage in its journey to its destination.
For example, the log files record a time and date stamp for:
Furthermore, the encapsulation method can also support any level of encrypted data should it be so required, subject to the capabilities of the operating system. We will have a recommended list of encryption standards (AES-256, AES-512 for block mode and SHA-1, SHA-256, SAH-512 for hash functions).
The SAFE client software has been designed in a way that makes it simple to integrate its functions into existing message/document exchange processes such as EDI. Using EDI as an example, what’s required is that the existing EDI system must be capable of exporting outbound messages into a physical file and importing inbound messages from a physical file.
The standard FTP protocol does not provide a reliable means of transferring data in that the end of the file transfer is indicated by a line close on the data port. As a consequence, it can be difficult to detect between a line fail and a genuine end of file. There is also no feature within the FTP standard which enables both ends of the file transfer to confirm the integrity of the file transfer.
FTP over SSL does improve reliability and security of the transfer, but does not provide the status tracking capabilities of the SAFE protocol.
Validating the full integrity of each block of data was one of the prime considerations in the development of SAFE. The SAFE protocol implements a protocol standard where the data is encapsulated in header, data and trailer blocks. The receipt of a trailer block indicates an end of file condition and the block contains control information which enables the protocol to determine the completeness and integrity of the transfer.
Other protocols such as AS2 do provide a robust and reliable file transfer protocol with the provision of message integrity checks and message disposition notifications, but these can be costly and difficult to implement. AS2 also requires an inbound session through the firewall which makes it far less secure. AS2 has been developed from existing ‘open protocols’ such as S/MIME over HTTP. However, there are different interpretations of these standards which can cause problems when implementing connections between systems. Although the Drummond Group have created interoperability testing, this has not eliminated all the connectivity problems and users do report issues when attempting to establish connections. Indeed so unconvincing is the Drummond Group interoperability testing that they themselves don’t guarantee any level of interoperability at all. AS2 will remain too complex and costly to implement throughout its life.
Described below is a summary of the SAFE Protocol, illustrating how it could be used in an environment where structured data, in this case EDI data, can be exchanged with a higher level of security than provided by commercial Value Added Networks.
In the event of an interruption or failure of communications, SAFE will ensure that only complete messages have been transmitted. Once communications are restored SAFE will “re-start” the transmission of the file and continue to transport data with full integrity. The sender and recipient will then both have full knowledge of the successful file exchange. The guarantee SAFE provides is that whatever data was sent has been received in its entirety without compromising any data integrity.
Below is an illustration of how Advance Information Broker (AIB) from AdvanceFirst Technologies works whilst utilising the SAFE (Secure Auditable File Exchange) Protocol.
SOX, or more specifically the Sarbanes Oxley Act of 2002, was enacted by the US Congress as a result of the Enron scandal and the subsequent investigations by the SEC and Department of Justice into a series of other US companies that have either been indicted for fraud or have had to significantly restate earning because of a failure to accurately capture income and expenses. Companies headquartered in the US or those dealing with US firms must comply with these regulations.
As a result of working with a number of our customers who are US Subsidiaries operating in Europe, where some have migrated our software to the United States and Canada and those who are suppliers to US organisations, we are increasingly meeting requests for assurances of our software’s compliance to SOX requirements.
Whilst SOX is primarily focussed on the accuracy and auditability of financial reporting, IT security is also important under SOX in that it enhances the reliability and integrity of financial reporting. This was set out in a document published by a Public Accounting committee created as a result of SOX which stated that “senior management can’t just certify controls on the system, these controls also have to control and report on the way financial information is generated, accessed, collected, stored, processed, transmitted and used through the system.”
In short with regard to the internal and external transfer of data and SOX compliance, the following is a list of what is required: –
SAFE caters for all the above requirements as a standard operational part of the protocol.
When AdvanceFirst looked at how to achieve this level of logging and recording data, we found no existing data communication protocol to be suitable, so the SAFE protocol was developed. To our knowledge SAFE is the only fully SOX compliant protocol currently in existence which is practical to use and easy to implement.
As of today all other communication protocols are redundant. Why use insecure protocols when you can be SAFE?