Vendor Breach Involved PHI Exposure on GitHub
Several Healthcare Entities Issue Notices to Patients About Incident
… “Security needs to be assessed from different angles,” notes Tom Walsh, founder of consulting firm tw-Security. “Most often, the focus is on the front-end security controls of an application that control access to databases. Hackers will often attack the backend – databases.”
“Therefore, security needs to be assessed from the backend – databases and data repositories – as well as the front-end apps – the user-friendly interface,” he notes.
A software development life cycle policy should define when “real identifiers” are allowed to be used, Walsh says. That’s usually in the last phase of testing, before software code gets promoted into production. Once code has been tested, however, real identifiers need to be purged, he says.
“Be sure to check nontraditional locations for PHI” during final stages of software development, Walsh says, noting that those areas include application trouble tickets, which sometimes include a screenshot that contains PHI.
“It is important to remove or sanitize the examples that are sent in association with a trouble ticket once the ticket is closed out,” he says.
Transaction logs will also contain real identifiers, according to Walsh. “These audit logs may get backed up and retained for a long time, even after the real identifiers were purged from the system.”
The best way to prevent inadvertent exposure of PHI during software development is to use “dummy data” wherever possible, rather than actual identifiers, he says.
Also, “where feasible, periodically run searches or scans for any residual PHI that may inadvertently have been left behind by software developers.”
For more information or to schedule a FREE initial consultation – contact tw-Security.
Read More
