Most data security professionals would say the most critical aspects of a managed file transfer (MFT) solution are reliability and uptime, high levels of security, and data flows that are speedy and efficient. However, I believe that reporting functionality—i.e., giving visibility into data flows, files, and other aspects of the system–are of equal importance. In this blog, we will take a brief look at this under-valued functionality using bTrade’s TDXchange as a representative MFT example.
TDXchange contains a thorough and extensive set of reporting tools which cover virtually every aspect of the application. These capabilities extend beyond what other 
MFT solutions offer, which typically provide only basic reports, if any at all. The various types of reports we provide are all conveniently located within the dashboard menu item and broken out into seven sub-menu items.
Additionally, these reports are not limited to a visual representation within the graphical interface of the application. Many reports may be exported to comma-separated files, Microsoft Excel, as well as Adobe PDF formats. The data may be exported and viewed in text format or as graphical representations such as pie charts and/or bar graphs. This makes it much easier to get the data where you want it, and how you want it, in as few steps as possible. Below is a brief outline of each report.
Messages – This dashboard displays metrics on the number of successful, failed, pending and total messages. These metrics are further summarized both by protocol (e.g. AS2, SFTP, SSH, etc.) and the specific adapter (e.g. Directory Monitor, AS2 Server 1, SFTP Server 3, etc.). The report is generated for the timeframe specified.
Transactions – This dashboard displays a graphical representation (bar graph or pie chart) of the messages count for the given timeframe. The graphical representation may be separated by days, weeks, months, or years.
Participants – This dashboard displays metrics on the number of inbound and outbound messages for each participant in a given timeframe. This is further summarized by successful, failed, or pending messages, if the file was inbound, outbound, and total count, as well as which protocol was used for each.
Mailboxes – This dashboard displays metrics on the number of mailbox messages received or sent for each participant and their mailbox(es). It is further summarized by the Participant Name, Mailbox Name, In/Out, Pending, Total Size, Last Logged In, and Status.
Certificates – This dashboard displays certificates which will be expiring within a given timeframe. It is further summarized by the Participant, Certificate Name, Type, Created Date, Expiration Date, Serial Number, Issuer, and Details.
Services – This dashboard displays the status of all services (e.g. FTP, SFTP, AS2, etc) that have been created. Each service may also be started or stopped directly from this dashboard. You can see the number of connected users for each service and may view the detailed logs for each as well.
Connections – This dashboard displays the details on the number of connections to other systems.
If you would like to see screenshots of various types of reports described above which are outlined in the TDXchange User Guide, or would like to see a live demo of this functionality, please contact us any time.
Comments Off on Reporting: Valuable MFT Processes Which Are Commonly Overlooked
MFT Nation has written previously about whether the Health Insurance Portability and Accountability Act (“HIPAA”) requires the use of encryption. In that post, we noted that HIPAA requires use of data security measures, including encryption, whenever it’s “reasonable and appropriate” to do so, and suggested that very few situations exist where it would not be reasonable and appropriate to use encryption as a data security measure. The subject of this post is an FTC case in which regulators flesh out further details about reasonable and appropriate data security measures, including what level of encryption will suffice to pass muster with the FTC and under HIPAA.
FTC vs. Henry Schein Practice Solutions, Inc.
The FTC initiated a proceeding against a company that develops and sells dental practice management software alleging that the company made knowingly false statements that its software provides industry-standard encryption that meets the security requirements of HIPAA. The FTC offered the following compelling evidence showing that the company knew it was making false statements about the level of encryption in its software:
- In 2010, the vendor who helped develop the software advised that it used a proprietary algorithm that had not been tested publicly and was less secure and more vulnerable than widely-used, industry-standard encryption algorithms, such as Advanced Encryption Standard (“AES”) encryption.
- In addition, the company knew that regulators have recommended that healthcare providers follow guidance from the National Institute of Standards and Technology (“NIST”) to help them meet their regulatory obligations, and NIST guidance recommends AES encryption.
- On June 10, 2013, the United States Computer Emergency Readiness Team (“US-CERT”) issued a Vulnerability Note describing the form of data protection used in the company’s software as a “weak obfuscation algorithm.”
- On June 16, 2013, NIST published a corresponding vulnerability alert stating that the vendor had agreed to re-brand the data protection as “Data Camouflage” so it would not be confused with standard encryption algorithms, such as AES encryption.
- Despite receiving notice of the US-CERT Vulnerability Note and the vendor’s decision to re-brand in June 2013, the company continued to disseminate marketing materials stating that its software “encrypts” patient data and offers “encryption.”
Lessons Learned
To secure data, whether you are storing it or transmitting it internally/externally, follow NIST’s guidance and ensure that you have the capability to encrypt the data using the Advanced Encryption Standard.
Although the FTC has targeted only a handful of data security cases involving an entity that is subject to HIPAA, the FTC appears to be applying tougher standards than HIPAA’s requirements (e.g., requiring a specific type of encryption than what HHS historically has interpreted HIPAA as requiring).
For the first time ever in a data security case, the consent order includes a financial payment of $250,000, and the FTC settlement does not preclude a HIPAA action by HHS or by one or more of the states. So perform periodic risk assessments of your data security infrastructure to ensure that there are no security/compliance holes.
If you want to learn more about HIPAA compliance, or need a solution that has NIST-recommended AES encryption, please contact us at info@btrade.com. If you want to keep updated on developments in the world of secure file transfer and data security, follow us on Twitter, Facebook, LinkedIn, Google+, and our blog MFT Nation.
Comments Off on When is Encryption Not Encryption? When it’s Not.
MFT Nation promised to provide updates on developments in the FTC v. Wyndham Worldwide Corp. data security case. True to our word, we want to let you know the case has settled. You may recall that MFT Nation described the FTC’s complaint as a “case study for what not-to-do in the rapidly changing world of data security,” because Wyndham allegedly did not make use of “reasonable” data security measures such as encryption and firewalls.
We decided to follow the case hoping that the parties’ divergent positions would produce a litigation process conducive to further defining what constitutes “reasonable” data security standards. For example, the FTC’s complaint details a lengthy list of alleged “security insufficiencies” that allowed hackers to gain access to internal networks multiple times over an 18-month period, yet Wyndham stated publicly that it chose to fight the lawsuit because of its “strong belief” that it had deployed reasonable data security measures. Whereas the FTC alleged Wyndham’s lax data security practices allowed hackers to effect $10.6 million in fraudulent credit card transactions, Wyndham still maintains that it “has not received any indication that any hotel customers experienced financial loss as a result of these attacks.”
Given the settlement, we will not have the benefit of the litigation process to determine where the truth lies. Wyndham issued a statement saying the settlement “sets a standard for what the government considers reasonable data security of payment card information.” I wouldn’t go that far, but let’s take a look at the settlement terms to see if they provide any guidance relating to data security practices.
Under the settlement, Wyndham is required to implement a “comprehensive information security program” and thereafter “maintain” it for a period of 20 years. The settlement document lists the required “administrative, technical, and physical safeguards” of the program. Basically, it requires Wyndham to identify “material internal and external risks,” implement “reasonable safeguards to control the risk,” and staff the program with competent employees/contractors. There is nothing new or earth-shaking about that.
In addition, Wyndham must retain an independent auditor to perform annual audits under the Payment Card Industry Data Security Standard (PCI-DSS), a series of data security protocols for organizations that handle major credit cards. Again, there is nothing new or earth-shaking about ensuring that an entity handling credit card transactions complies with industry standard data security protocols.
The FTC said the settlement was noteworthy because it requires Wyndham to adhere to standards “exceeding” those of the PCI-DSS, specifically including a requirement for Wyndham to protect the perimeter of its networks by using a firewall to create a barrier between its own servers and those of franchisees. The lack of a firewall between franchisees’ servers and Wyndham’s own servers was a “critical gap that left the door open to hackers on three separate occasions,” according to a post-settlement statement from the FTC.
The FTC raises an important point about perimeter security. Some folks have suggested that perimeter security is unnecessary as long as the data is protected end-to-end using encryption—regardless of which channels it goes through or its eventual destination. The reasoning behind this so-called data security approach is that the encrypted data can be accessed only by the intended party and no one else. But this line of reasoning has a lot of holes. For example, encryption becomes useless once a network intrusion has occurred and cybercriminals operate with stolen valid user credentials.
Encryption is an essential component of any good data security infrastructure, but it is not, and cannot be the only piece. All good data security infrastructures deploy a layered approach which includes firewalls and encryption, among other things. A firewall is essential where there is any external connectivity, either to other networks or to the internet. It is important that firewalls are properly configured, as they are a key weapon in combating unauthorized access attempts.
The FTC imposed no monetary penalties against Wyndham, but explained that it lacks authority in most data security cases to get civil penalties, although the agency is seeking that authority from Congress.
If you have questions about this case or want to discuss your data security practices with bTrade, send a confidential email to info@btrade.com.
Comments Off on FTC vs. Wyndham Epilogue: Settling for Less
MFT solutions offer, which typically provide only basic reports, if any at all. The various types of reports we provide are all conveniently located within the dashboard menu item and broken out into seven sub-menu items.
