Good Data Quality is Better Security (Archive Post)

Data quality is not a glamourous subject. It is not the type of topic that headlines a conference or becomes front-page news. It is more typically suited for help guides and reference manuals that few individuals relish reading. However, organizations that acknowledge the importance of data quality and have strong data quality programs significantly reduce privacy and security risks. They also lower the potential costs associated with data breaches, the legal risks, and potential size of business interruptions.

Data quality issues start when information is created. This includes incorrect information, data entry errors, and inaccurate document conversion such as conversion of text contained within image files (e.g., a screen shot from a patient management system). Data quality issues also arise as data is being processed, transferred or stored.

1. Build a foundation of knowledge and fluency about data.

“Understanding data” means moving deeper than simply understanding that a database stores records or that a file contains information. Knowledge of data means taking the time to understand that data exists in different layers and structures and can be readily transformed. Additionally, data can be defined as discreet elements (e.g., a data element that stores date time information) and have assigned roles and restrictions. Investment in the language of data can improve control over data and enable better decisions on information security and privacy.

2. Don’t leave data design and quality decisions to the development team or an IT group.

This could place data at significant risk including possible loss, misuse and insecurity. Development teams are often provided with high-level requirement such as “design a secure form to collect user data”. While this directive may appear clear, privacy and security risks reside in the implementation of this directive. To achieve better security and privacy, more attention must be directed to clarify the method of data form collection, transmission and storage of data. Further validations should be provided so that data is corrected before it is stored.

3. Articulate security and privacy concepts in terms that assist developers integrate better security.

Regulations and policies concerning privacy and information security often address data from a systems perspective. Terms such as “protect the perimeter” articulate protection of a network and the systems and data within the network. “Protect the perimeter” does not clearly translate design into a more secure system.

Developers and analysts work with data in the context of business and user requirements. Developers also work under tight budget constraints and significant systems complexity where one requirement may consist of several steps. As security and privacy requirements continue to mature, understanding the needs and workflow of developers will facilitate better “baked in” security and privacy.

4. Extend security and privacy requirements to how data is created, changed, stored, transmitted and deleted.

Security requirements typically speak at a high level and leave a substantial gap in clarity with respect to data. As an example, a business may have a requirement where social security numbers (SSNs) are encrypted at rest. At the same time, the company may display SSNs in a web application where the SSNs are partially hidden by form design but otherwise are present and unprotected.

5. Embed security analysis into the QA process.

Security testing is often the purview of InfoSec groups and external consultants who evaluate software that exists in an operations environment (also referred to DevOps or Production). This includes the use of tools and the knowledge to locate and remediate vulnerabilities. The pitfall with this approach to security testing is that vulnerabilities are not identified before software is released. Using tools such as Seeker (which analyzes software for vulnerabilities during the QA process) can improve overall application security by reducing the number of possible vulnerabilities in software design.

CASE: Data at Risk (by Design)

Organizations are at increased risk of security incidents due to un-defined or poorly specified software requirements. One such example is inadequate articulation of secure password storage. Poor design is initiated when developers or an IT group receive a directive to secure user passwords. However, securing passwords can mean many things including:

  • Storing clear text passwords in a secure database.
  • Using well-known mathematical formulae to convert passwords into what are called hash values.
  • Storing software code or algorithms to secure passwords in the same data file or directory as the password data.
  • Storing password hints with passwords.
  • Forgetting to secure the folders where data is stored (which leaves the door open to the risk of exfiltration)
  • Not requiring strong password rules for the creation of passwords.
  • Not validating passwords prior to storing passwords.
  • Leaving administrative passwords in the same location as customer data.
  • Creating a backdoor for developers as an easy means to administrate or perform corrections.
  • Not requiring or allowing time for developers who wrote the code for securing passwords to create documentation that explains the code.
  • Leaving design implementation to a developer who may not be available or reachable after code implementation

Accountability for data design, use and quality should exist across an organization. With less of a technical divide, organizations can improve the conversation on how to better protect data with the appropriate use of security to balance risk and cost. Attention to detail at the bottom (the data level) may also deliver secondary benefits such as cleaner customer data, reduction in time to resolve customer issues, or better disaster recovery.

HIPAA Data Leakage – Is Your Protected Health Information Secure? (Archive Post)

The misnomer of HIPAA compliant software is prevalent in the health care industry. Too often, HIPAA-regulated entities rely on vendor controls and claims of compliance as a substitute for their own HIPAA security programs. While the vendor software itself may meet the requirements of HIPAA compliance for the discrete functions it performs, the truth of the matter is that no software or system that handles Protected Health Information (PHI) is HIPAA compliant until it has undergone a risk assessment by the regulated entity to determine the efficacy of its security controls in the user’s environment.

Adherence to HIPAA required risk management processes and industry-best practices should protect organizations from attacks. HIPAA requires that both covered entities and business associates maintain a security management process to implement policies and procedures to prevent, detect, contain, and correct security violations. The foundational step in the security management process is the risk assessment, which requires regulated entities to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the entity.

HIPAA compliant risk assessment

NIST Special Publication 800-66 identifies a protocol organizations may use for conducting a HIPAA compliant risk assessment. 800-66 generally identifies nine steps an organization should take in this regard. Significantly, the first two steps of the risk assessment process should be read together to identify all information systems containing PHI and ensure that all PHI created, maintained, or transmitted by the system is being maintained appropriately and that security controls are applied.

In the context of third party software and systems, the risk assessment process should be used to identify hidden repositories of PHI where unintended business functions or improper implementation cause PHI to be located outside of an organization’s secure environment. If third party software and systems are not identified within the scope of a risk assessment, and a disclosure or audit occurs, the government may impose penalties for not conducting a thorough risk assessment. Additionally, there is potential for third party lawsuits if a disclosure results. In a data breach dispute, the argument usually boils down to whether the controls the organization had in place were reasonable to protect PHI. In many cases, the plaintiffs use HIPAA as a standard of care, so that if an organization was not in compliance, the plaintiffs will argue the organization did not take reasonable steps to protect PHI.

While not conducting an accurate and thorough risk assessment may result in regulatory enforcement or litigation risk, failing to identify hidden repositories of PHI may also result in other HIPAA violations. If data is stored outside of its intended repository, it is unlikely that an appropriate data classification and associated security controls have been applied to the hidden repository. The result is that it is unlikely the HIPAA regulated entity is meeting the required technical implementation specifications of the HIPAA Security Rule with regard to the information contained in the hidden repository. In such situations it is unlikely that an organization has appropriate access and audit controls in place on systems that are not intended to store PHI.

Common vulnerabilities in electronic medical record (EMR) software

Software is developed for a specific purpose, such as managing patient information or insurance billing. Software’s core functionality is created during the development cycle, and security may be incorporated into the development process, or it may be an afterthought. Security is optimal when it exists within a software application and the environment where the application is hosted.

  1. At the device level where the software is installed, software integrates with its host operating system, file system and network environment. The intersection between an application and its host environment could create significant PHI exposure risk.
  2. Software, particularly database software, is often vulnerable due to poor security upgrade practices and loose configurations.
  3. Even when security features are established, those features may be changed to appease users or to simplify IT tasks.
  4. Delayed software upgrades or improper upgrade installation may increase the potential for compromise.
  5. External communication channels are often incorporated into software applications to enable functionality, such as transmitting faxes/emails, or to allow access by outside administrative support. These communication channels are often left unsecured with default configuration settings and administrative credentials.
  6. Audit logs are typically developed to support a specific software application, but use of audit logs may be disabled or ignored.

A recent recent data breach investigation

In a recent data breach investigation, Kivu encountered an integrated EMR software solution that stored patient records, including social security numbers (“SSNs”), on a Windows server. While the EMR application had protected access with unique credentials assigned to users, the server itself was accessible to all employees with domain credentials. The EMR software offered complete practice management capability in a single offering (such as patient management, prescriptions ordering and tracking, patient communications and billing).

The EMR software and the server housing the EMR software lacked appropriate controls to secure PHI. The presence of EMR login credentials in text-searchable files potentially negated the use of encryption for the EMR database. Unsecured directories provided the opportunity for any user to browse the server and potentially locate files containing patient data.

The audit capabilities of the EMR software were limited to the EMR database. As a result, externally stored files with patient data were outside the reach of the EMR software. PHI could have been exfiltrated without leaving evidence of file activity. For example, on a Windows computer, a hacker could use a Robocopy command to copy files, and the use of this command would leave no evidence of file access.

Using sophisticated search tools employing data pattern recognition, Kivu was able to identify numerous instances of PHI on the compromised server. The client was surprised by the result because they believed the EMR system was secure and HIPPA compliant. This was a painful lesson in the numerous (and dangerous) ways that sensitive data can leak from an otherwise secure system.

See archived attachment for further information: Forensic Analysis Reveals Data Leaks in HIPAA Compliant Software.

Originally posted in Kivu Labs blog.