THE SAFE PROTOCOL

Secure Auditable File Exchange (SAFE) Protocol

Is your company in a SAFE place?

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.

SAFE enables:

• All files sent and received to be comprehensively logged by each SAFE client
• Status information is fed back to each SAFE client as each file reaches its final destination
• All file exchanges are subjected to three levels of integrity checking to ensure complete and accurate delivery. Digital Certificate exchange / Hash totaling / AES 256 encryption
• SAFE encapsulates both structured and unstructured data, including binary data, into secure packets which allows it to determine recipient, file type and control information. AMMX does not open or read the file contents; the type of data is determined by the profile of the folder it has been extracted from.

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:

• When the file was collected by the client
• When the file was sent to the SAFE/AMMX server
• When the file was processed by the server
• When (date and time) the file was authenticated
• When the file was placed in the recipient’s mailbox to await collection
• When the file was collected by the recipient client

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.

SAFE:

• Allows data to be exchanged securely and auditably, within a local/international trading community or organisation.
• Removes the need to send data via a commercial VAN (faster, better, cheaper, safer)
• All files sent and received are comprehensively logged by each SAFE client.
• Status information is fed back to each SAFE client as each file reaches its final destination.
• All file exchanges are subject to three levels of integrity checking to ensure complete and accurate delivery.
• SAFE is “EDI-aware” which allows it to determine recipient, file type and control information from the contents of the file being transported.
• SAFE also supports the exchange of unstructured (binary) data
• SAFE records a full audit trail of every file sent and received which can be used to determine the precise date and time every file reached each stage in its journey to its destination.
• No files can be exchanged between sender and recipient mailboxes unless a valid trading relationship has been set up between both parties.

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.

SAFE and SOX Compliance

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: –

Logging and recording of the following data:

• User Authentication
• Sender system identification
• File/application identification for sending
• Recipient system identification
• File/application identification for receipt
• Full status tracking – Date and time of sending file, Date and time of receiving file and Date and time confirmation of receipt by application (final destination checking)
• Full integrity checking of data – Hash totalling (error checking) and MDN’s (Message Disposition Notifications)

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?