Blockchain has the potential to be one of the most disruptive technologies since the invention of the Internet. There is an entire class of problems with distributed reconciliation of data entries that this can potentially solve. The creators of Blockchain saw past its initial usage for cryptocurrency implementation toward a future where many distributed applications can utilize this technology to craft auditable and verifiable solutions for a variety of problems. Healthcare and finance, in particular, will benefit greatly.

However, in the initial euphoria about Blockchain, there are notes of caution. While this is a new technology, this does not change the basic tenets of information security. We have to be very careful to reconcile implementations with the requirements of the HIPAA Security Rule, HITECH Act, and if used for financial or Revenue Cycle transactions, the guidance issued by the American Institute of Certified Public Accountants (AICPA). Auditors use the AICPA guidance to audit systems of record, and their focus is much like the HIPAA Security Rule, which is on providing provable, auditable, reasonable, and appropriate safeguards to protect transactional and data integrity. While the HIPAA Security Rule focuses on patient data and electronic medical records, the AICPA guidance focuses on general ledgers and accounting. With Blockchain, these two worlds converge.

With that, we will focus on four ways we can improve the security of Blockchain in healthcare and provably implement systems that meet HIPAA and AICPA requirements. By first, storing the minimum necessary data on the blockchain, enforcing collaboration to always ensure that there is never a computational majority, having distributed accountability for systems security, and finally, enforcing strong identity and key management processes, we can meet those security standards.

Blockchain is a loosely defined format. There is no limit on what information can be stored in it. The insults hurled at the FBI using Blockchain messages on Bitcoin after the Silk Road takedown are direct evidence of that. The HIPAA Privacy Rule and Security Rule both enforce the principle of minimum necessary information. In addition, there is no current way to effectively enforce auditing read access of Blockchain implementations. This means that there is no way to safely put Protected Health Information or any information that can be reverse-engineered to reveal it on the Blockchain without compromising it, even private Blockchain.

What is possible, however, is to store either direct links to systems storing PHI that require authentication that also audit access, or the cryptographic checksums of PHI that probably cannot be reverse-engineered. If you do store PHI on your Blockchain, you then have to assume that anyone who has access to it has access to all of the information in it, and if there is a breach of that information, all of that information will be considered breached as there is no way to prove otherwise. Combining the use of systems with authentication and auditing with cryptographic checksums to verify and validate data improves security and provides a distributed method of proving it. Storing data itself on a Blockchain weakens it by removing audit controls.

Another way to weaken Blockchain is the 51% problem. This is the case where if some entity has control of more than 50% of the computational power in it, that they will be able to literally rewrite history and alter transactions. The major purpose of it is to provide a distributed verification and validation process which is predicated on the principle that no one entity has a majority. Any implementation of Blockchain in healthcare needs to have strict contracts, covenants, and controls where all entities monitor the total processing power and usage, and make sure to either increase or dial back the processing power utilized to verify and validate transactions.

The recent implementations of Blockchain as a Service (BaaS) from IBM and Microsoft provide the technical mechanisms to do so for most organizations. All parties involved need to adhere to this principle. The reason why is because it is a basic tenet of both HIPAA and AICPA guidance to protect the confidentiality, integrity, and availability of data. Having one entity in a distributed system with the ability to change all three by having the power to alter data violates that.

With distributed systems comes distributed accountability. While the technology behind Blockchain is sound based on current cryptographic standards, there will always be vulnerabilities in the implementations of said systems. Whether it be the potential for introducing predictable patterns into one-time-pad implementations, as Neal Stephenson illustrated in the book Cryptonomicon, or a more real-world example such as the Heartbleed and KRACK vulnerabilities, there will always be weaknesses.

The issue with Blockchain is that they have the potential to not only affect the integrity of data for one entity, but also for all Blockchain participants. Organizations need to realize that this will affect them. Participants in both public and private Blockchains need to have a strong vulnerability management program and shared security standards in place. Just because the system uses strong cryptography does not mean it is immune.

Private blockchains need to strictly enforce this via contracts, covenants, controls, cross-monitoring of systems, and allowing other participants to view, manage, and potentially exclude transactions from all participating entities that do not meet standards. Under both the HIPAA Security Rule and AICPA guidance, organizations are required to have programs that continually assess and address risk. Making sure that Blockchain implementations meet these standards via multiple means is one larger step toward acceptance. Systems such as Mt. Gox were compromised through bad vulnerability management and associated processes.

This also extends to downstream systems that output data to Blockchains. Just because a system outputs data to one does not mean that the data itself is secure. There has been a push to use Blockchain to store data from Internet of Things (IoT) devices. While this is an excellent way to aggregate data from a number of devices in one verifiable place, it does not change that systems need to generate this data using a verifiable and valid process. Blockchain cannot be used as a step to validate system integrity for the IoT, or provide integrity to data generated from legacy systems that cannot be effectively mitigated for risk or documented. Implementation of a Blockchain system requires full end to end integrity and a verifiable process, or else you’re doing nothing more than validating bad data with cryptography.

Verifying process also means verifying who makes entries. The current Blockchain implementations do not provide for strong identity management, nor should they. Identity Management is a distributed process that shows, in a series of steps, how an entity is able to gain access to a set of systems, with periodic checks to ensure validity of said entity.  Both the HIPAA Security Rule and AICPA guidance require that access to transactional systems, whether they have PHI, financial, or Revenue Cycle data, have strong identity management processes behind them.

What this means for Blockchain is that private implementations need to have shared processes that all parties agree on, enforced by contracts and covenants, that demonstrate that only entities who need direct access to either read or create/alter entries are authorized to do so. Shared provisioning, de-provisioning, and validation processes are a must.  Just because the system is distributed does not mean that each entity can continue existing processes. To ensure total system integrity requires the adoption of shared identity management processes that meet industry standards, and are auditable by all parties. The continuation of existing processes means that there are potentially components that cannot be audited.

As another part of this, strong key and certificate management processes are a must. There needs to be a set standard for usage and continual management of encryption keys and certificates from a trusted certificate authority that all parties agree to, enforced using both technical and contract means, to ensure that only trusted certificates are used as part of the verification and validation process.

The compromise of multiple certificate authorities such as DigiNotar to issue certificates in the names of major companies such as Google and Microsoft only show how important this step is, as impersonation is a very real possibility. The usage of self-signed certificates as part of a Blockchain implementation does not provide a verifiable step that demonstrates that encryption follows a known good provable methodology.  Reputable certificate authorities have multiple checks and balances to ensure the integrity in the certificate generation and issuance processes, and are regularly audited. Self-signed certificates do not have that integrity or process behind them.

Blockchain is full of promise for healthcare, finance, and Revenue Cycle. It has the potential to dramatically increase integrity and collaboration, and provide for distributed applications that once were not thought possible. However, there are still vulnerabilities to address. By reducing data to what is absolutely necessary, having shared vulnerability management across all participants with strong agreed-upon standards, even for downstream systems, enforcing collaboration and preventing a computational majority, along with strong identity management, HIPAA and AICPA standards can be enforced, even in a distributed environment, and security can be increased for all participants. This leads to Blockchain being disruptive in a positive way by increasing integrity and security, and enabling a new class of applications and services that benefit healthcare at all levels.

The post Four Ways to Improve the Security of Blockchain appeared first on Security Current.

In this three-part series, Academic Health Care CISO Mitch Parker shares his insights on ransomware, incident response and best practices for building a world class prevention program. Read parts one and two.

As I mentioned in my previous articles on ransomware, I have spoken at numerous industry conferences and discussed the growing threat of ransomware with many of my peers. Through this ongoing dialogue, I have identified a number of key considerations and best practices for addressing what has become a serious issue in healthcare. I covered points 1-4 in the second installment of this series and will now cover the remaining points and summarize.

Fifth, healthcare organizations need to have a comprehensive educational plan.  This should not just be a one-time email you send to the user community.  This needs to be in your organization’s security awareness and training program, which should be updated at least yearly.

Security awareness and training are required under the HIPAA Security Rule.  If you are audited due to a security incident, one of the first items that the auditor will ask for is your training program and evidence of completion by staff members.  This plan should include at least one competency-based training section, and a training presentation for departments and organizations that covers core policies and procedures.

Sixth, your security strategy needs to include organizational integration.  Although there have been a lot of arguments over the reporting structure of the senior information security executive in the organization, the key measure of their success should be their ability to work across traditional boundaries with stakeholders outside of IT.

A ransomware or security incident response plan is not useful if it only involves IT.  You need to involve your identified key stakeholders across your organization in plan development, especially the Regulatory Affairs personnel, or else the plan will not be as successful as it should be.

The seventh key consideration is maintenance.  Your organization ideally should identify its key applications; know who the key personnel are, and understand how to maintain them.  These applications, along with the other computing devices in your organization, need to be kept up to date.  If they can’t be maintained for multiple reasons, you need to segment these applications so they only have access to what they absolutely need to for business purposes.

Each of these applications needs downtime procedures, and you need to work with your customers and stakeholders to ensure that customers develop them, maintain them, and exercise them so that when an event occurs, they are prepared and able to function.  The yearly Hazard Vulnerability Analysis required by the Joint Commission can be used to measure and evaluate this.

The eighth best practice is Defense In Depth.  Your organization needs to implement a well-maintained strategy involving layers of defense at multiple levels to protect organizational assets, detect potential threats, and minimize damage to attacks.

This starts with risk assessments and finishes with the mitigating tactical implementations of anti-malware, network segmentation, firewalls, intrusion detection/prevention, SSL/TLS inspection, proxy servers, identity and access management, and other defensive tools to protect you.  This strategy needs to be continually evaluated for effectiveness, and just buying something will not fix that.

The ninth, and most critical key consideration, is to stay informed.  There are multiple channels where you can find information about cyber threats to the healthcare sector.

These include Infragard (www.infragard.org), the National Cyber-Forensics and Training Alliance (www.ncfta.net), FBI (www.fbi.gov), HITRUST CyberRX (hitrustalliance.net/cyberrx), National Health Information Sharing and Analysis Center (NH-ISAC) (www.nh-isac.org), the College of Healthcare Information Management Executives (CHIME) (chimecentral.org), and the American Hospital Association (www.aha.org).

You should also know who the other security executives in your market are, how to contact them, and attend local meetings of your ISSA, Infragard, CISO Executive Network, or (ISC)2 chapters to network and share threat information with each other.

If you follow these steps, you should be able to craft a strategy for your organization that will help you not only face the threat of ransomware attacks, but also have a plan in place for other security incidents.

With the ever-increasing amounts of security vulnerabilities, threat actors exploiting them, and emphasis on shipping products and fixing them later, there will always be attacks that have the potential for crippling healthcare organizations.  Your strategy should be to have one, and not be reliant upon magic bullets to find and fix issues.  Eventually, those tools will fail, and you will be left to rely upon your plans.

It’s important to integrate with your organization and develop plans and strategies to address the issue of ransomware and what to do when an event occurs and your defenses fail.  This will help your healthcare organization meet its HIPAA/HITECH and Joint Commission requirements for Risk Management, Risk Mitigation, Information Management, and Downtime Procedures.

The post Ransomware in Healthcare – Strategies for Protecting the Enterprise – Part Three appeared first on Security Current.

In this three-part series, Academic Healthcare CISO Mitch Parker shares his insights on ransomware, incident response and best practices for building a world-class prevention program. Read part one.

As a preamble to this list of key considerations and best practices, let me first say that all organizations should plan to be attacked.  While there may be many solutions in the marketplace that claim to stop ransomware, eventually they will fail.  There will always be an exception to the rule that will make it past your defenses and cause damage.

You need to be able to react, and not point the finger at a product for not protecting your network.  You need to have Defense in Depth and comprehensive incident response and downtime plans for addressing your HIPAA/HITECH and Joint Commission requirements.  Neither a solution nor a one-page document claiming the solution protections will satisfy these requirements.

First, you need to have good incident response teams to be able to handle these events.  When we developed our teams, one of our key goals was to have a cross-disciplinary team that included our IT department, communications, emergency management, and nursing in order to ensure we had input and support from critical stakeholders in both IT and the rest of the organization.

We also had a Tech Team made up of the customer support, tech services/system administration, and networking teams to triage issues.  This is critical for managing both the application and technology aspects of an attack.

Secondly, you need to understand how your organization communicates.  One of the major issues with security is that there are often multiple communications methods to reach the right people.  When we brought in the communications, emergency management, and nursing team members, we adapted our incident response plan to utilize the Hospital Incident Command System (HICS).

This step allowed us to hook into the existing communications infrastructure, and most importantly, a leadership communications structure that we could utilize to notify people of the event.  Most importantly, it puts incident response into a structure that health care organizations already know how to use.

However, IT departments need to make sure that there is a “point person” designated to interface between them and the HICS leadership structure for ransomware attacks, and that the person understands their role.

Third, it is critical to hold tabletop exercises to gauge readiness.  You need to know where the gaps in your organization are so you can resolve them. You need to understand how your organization works, and where the gaps are at so your team can build the plan.  You also need to understand who to empower to make decisions, and why.

Fourth, you need a comprehensive incident response plan.  This incident response plan needs to address the following areas:

• Initial Triage – how to determine whether a PC on your network has been infected and what channels will be notifying you
• Tech Team Notification – how to notify key tech team stakeholders that there is a potential ransomware attack
• Asset Discovery – identifying key asset information (PC Name, IP address, MAC address, physical location, jack number/switch port)
• Quarantine – how to isolate this PC from the rest of the network to prevent further damage and minimize business impact
  • Also, you should include how to isolate any potential evidence for law enforcement or information security
• Footprint Discovery – identify what mapped network shares and applications the infected resources had access to
• Footprint Examination – comprehensive examination of resources to determine impact.
  • Develop a checklist for your organization to examine critical applications and resources in addition to just mapped drives
• Determination – make the determination as to whether or not you have been attacked
• Application Owner Notification – notify the application owners of any affected resources of the issue and its impact on their application resources
• Containment – determine how to best contain the infection and make the recommendation to your “point person”
• Application Triage – triage damage and prepare initial estimates, along with downtime and Mean Time To Recovery (MTTR)
• Stakeholder Notification – notification to organization stakeholders, such as the administrator on call, that there is an impact, and for them to communicate with their key teams
• Customer Communication – notify customers that there is an issue and provide instructions on what to do
  • Ideally provide this out of band using secure text messaging and have templates ready with your communication/call center
• Downtime Procedures – have affected customers go to downtime procedures for the affected processes and applications until successful restoration and testing
• Application Restoration – restore affected applications to a usable state, test their status, and periodically update customers on status, including what may and may not be functional
• Restoration of Service – end of Incident

Solid communication and incident response plans are key to addressing ransomware attacks, but there are a number of other key considerations that should be built into a strong security program. In part three, I will go through the remaining best practices and key factors that I have identified after extensive discussions with other security executives and industry thought leaders.

The post Ransomware in Healthcare – Strategies for Protecting the Enterprise – Part Two appeared first on Security Current.

In this three-part series, Academic Health care CISO Mitch Parker shares his insights on ransomware, incident response and best practices for building a world class prevention program.

Ransomware has been the buzzword du jour for the past year in computer security.  This mostly unsophisticated attack type uses deception and already-existing means of communication to destroy the integrity of systems and shut down businesses by holding their critical assets for cryptocurrency ransom via encryption.

In my opinion, there has been little thought to either mitigating the risks caused by ransomware attacks, or an overall attempt to use products to fix what a good incident management process should.

In addition, newer versions of ransomware are utilizing more sophisticated means to cloak themselves, bypass defenses, and cause damage, propelling this threat as one of the industry’s most critical.

The first important item to keep in mind is that most computers are based on the Von Neumann architecture, where memory holds both data and the programs that manipulate it.  Therefore, it is always possible to manipulate data to affect stored programs, and vice versa.  One doesn’t need Phrack 49, Smashing the Stack for Fun and Profit, to tell you that.

Secondly, it is generally considered impossible to determine with 100% accuracy whether or not a program is malicious without actually running it.  Newer ransomware variants employ techniques such as encryption, polymorphism, and digitally signed code using stolen code signing certificates, and have defeated most, if not all, anti-malware programs on the market. Therefore, it is important to have an incident management process in place to deal with the inevitable.

Complicating matters, the Department of Health and Human Services, Office of Civil Rights (OCR), has issued guidance that considers ransomware attacks reportable breaches for healthcare organizations and other covered entities under HITECH.

There have been a number of reported ransomware attacks at hospitals and healthcare systems across the United States, including Medstar, Kansas Heart Hospital, and several affiliates of larger health systems.

As part of the guidance given by OCR, you have to conduct a risk analysis on the effects of the attack (http://www.hhs.gov/hipaa/for-professionals/breach-notification/) to determine what records have been breached, and report it just like misdirected or stolen information.

Under HIPAA and HITECH, if you are considered a covered entity or business associate, you must not only protect against reasonably anticipated threats or hazards, but also conduct a risk analysis to ensure that your organization implements reasonable and appropriate controls.

One other important item of note is that recent ransomware attacks have shut down access to critical systems such as Electronic Medical Records (EMR), which have become essential to operations for healthcare organizations around the globe.  These attacks have impacted patient care and caused affected organizations to divert patients to other hospitals to receive care, delaying treatment to those who need it most.

The Joint Commission, which is the main organization that certifies and accredits healthcare organizations and programs in the United States, has two requirements for its member organizations to follow.

Joint Commission Standard IM.01.01.03 requires hospitals to plan for the management of interruptions to information processes.  This requires organizations to be able to plan for and manage downtimes.  Hospitals are also required by the Joint Commission to conduct annual Hazard Vulnerability Analysis exercises, and have since 2001.  These exercises require hospitals to conduct a systematic analysis to identify hazards or risks that will impact their facility, which includes computer and network downtimes.

Together, these standards hold healthcare organizations accountable for preparation and incident management, and as ransomware attacks grow in sophistication and frequency, it is critical for security teams to reevaluate and refine their approaches to protecting the enterprise.

Over the past year, I have given a number of presentations and webinars on the topic of ransomware, including the Ransomware in Healthcare summit in Philadelphia this past April that had 67 attendees from 37 different organizations.

Dialogue during this conference revealed several key factors that healthcare organizations should possess to be able to survive a ransomware attack.  In part two, I will begin going through the first four of nine best practices and key factors for building a strong security program. 

The post Ransomware in Healthcare – Strategies for Protecting the Enterprise – Part One appeared first on Security Current.

There were two security incidents over the past week that drew a lot of attention. The first was the ransomware attack against Medstar, a health system based out of Columbia, MD.

The second, which received less publicity, was the Neo-Nazi propaganda sent out by infamous Internet troll Weev to publicly accessible printers across the Internet.

Out of the two attacks, the much more dangerous one was Weev’s attack.  This article will discuss why this is the case, and how organizations can protect themselves from similar attacks in the future.  What Weev did was not a direct attack, but shows how one misstep can expose an organization and potentially put them at serious risk.

Printers are very sophisticated devices with operating systems and powerful processors.  The current consumer printers available offer Dropbox support, Google Cloud Print, scan to email, and saving to USB flash drives or memory cards.

Corporate devices will additionally support saving to network file shares or even SharePoint sites using saved credentials, meaning that the printer is a full participant on the network.  Many of them, in addition to running proprietary firmware such as HP FutureSmart, run embedded Linux as firmware.

This is a problem if port 9100 is open to the Internet, able to receive raw PostScript files and prints them out.  Let’s walk through how.

Firstly,  PostScript is an interpreted programming language.  This means that this programming language is subject to the same vulnerabilities as others such as C, and a malformed PS or PDF file can be used to execute arbitrary code through an interpreter (source: https://www.cvedetails.com/vulnerability-list/vendor_id-7640/Ghostscript.html).

One of the major ways to cut costs is to use Open Source or Gnu Public License (GPL) libraries.  Even though some of these printer manufacturers have not disclosed it, Ghostscript or a derivative of it may be at the heart of the print engine for many of these devices, opening it and the printer up to potential compromise.

Secondly, in many organizations, printer support is contracted out to a third-party company, and is not under the purview of IT.  This means that there is little control over these devices, and that there are outsourced staffs that work on them, and often have exclusive administrative access to the devices.  These devices often are checked only when there is a problem preventing printing, not when there is a published security issue.

This leads to the devices themselves.  Many of them, in addition to running Linux, may be running an older kernel or firmware version that is susceptible to vulnerabilities.  As many of them are considered ancillary devices, they may not be getting the kernel or firmware updates they should be getting.  Coupled with the third-party support situation, this leads to a number of printers being on networks that may not be as protected as the desktops or laptops that print to them.

Another complicating factor with these printers is that many of them have to remain at a certain firmware level.  There are accounting, auditing, and chargeback software packages such as FollowMe from Ringdale Software, PaperCut, or numerous others that require hooks into the firmware, or in the case of FollowMe, custom printer firmware.

This means that even if there are firmware updates available, updating the printers may affect other line of business applications, and in the case of law firms that use FollowMe, billable items.  For companies that use printers for printing reports or other critical business information, there may be issues when changing the firmware that affect how they display the final product.

Multi-function printers also now can store credentials of users and fully interact with directory services such as Active Directory for purposes of authenticating users, looking up mail recipients, and looking up phone/fax numbers.  They also store credentials for scanning to file shares, SharePoint, FTP sites, and email.

This means that these devices are fully participating members of the network.  Some of the less careful administrators, to save time, may have given a service account with more access than needed.  This means that there is an account out there on these printers with access to the network, and in some cases, it may have access to a lot more than it needs.

This leads to the big question.  If a device like this is open on port 9100 to the outside world, what else is open?  What can we do to protect ourselves?  There are potentially serious consequences, especially if these printers are used to print any regulated (FERPA, HIPAA, PCI) information.  If one of these printers were to be compromised with a corrupt print job, which is a likely occurrence, how would you even know what was printed to the printer and potentially breached?  We’re going to talk about some solutions.

First things first, if you have any printers or other devices that have inbound Internet access other than an updated version of Secure Shell, turn them off immediately.  There is no reason in 2016, especially with the number of free Virtual Private Network or OpenSSH configurations out there, to not offer encrypted and protected access to network resources.

Second, you need to do a risk assessment of your printing devices.  You need to be asking the following questions:

• Can you create printer VLANs?  If you have the ability to do so, segment the printers off on their own network segment with only access to the resources they need, such as directory services, print servers, and file shares, but nothing else.
• Are you using print servers or print management software?  Print servers or management software allow you to log and audit print jobs, scanner jobs, and other actions taken on the device.
• What is the firmware update process for printers?
  • Who is responsible?
  • Who will be performing the updates?
  • How often will the updating take place?
  • Is there a testing process for testing software and/or firmware updates with applications?
• Does the manufacturer encrypt the information on the printer hard drives?
• In case of an emergency, can the systems administrators and InfoSec staff get administrative access to the devices?
• Have the passwords to the devices been changed from factory defaults?
• Do the service accounts have access to only what they need, and nothing else?
  • How will you enforce this?
• If there is a third-party service contract, what are the terms and conditions under which the vendor will service and support the device?
  • Do security updates count as a service call or are they included?
  • Will they even support the updates?
• Does your vulnerability scanning software support printers?
• Who do you report security issues to at the manufacturer or vendor?
  • What is their security response process?

Third, you need to continually revisit, at least yearly, your risk assessment if not more often.  We need to make sure that everyone is on board and working to protect networks and information.  This is critical, as these devices present significant residual risk.  They’re not just printers.  When a $100 printer can connect over WiFi upload to Dropbox or Google Drive, and accept printouts from Google Cloud Print, they’re full-fledged computers that also print and scan.

Printing anti-Semitic material to printers at universities across North America is a horrible way to get attention.  When an event like this happens, there are two questions that we have to ask, and have hopefully answered today, which is why it happened in the first place, and what we can do to mitigate this in the future.

What Weev did could have been a lot worse, and could have resulted in serious damage to customers, networks, and data.  The purpose of writing this was to show the risks, and to show what we can to do prevent something like this from happening in the future.

The post CISO Advises Enterprises on How to Combat Latest Printer-based Attacks appeared first on Security Current.