The Complexity and Low-Security Maturity of the Modern Healthcare Ecosystem: Part 2

The Complexity and Low-Security Maturity of the Modern Healthcare Ecosystem: Part 2

In the first of our two-part series, we covered the unhygienic security practices and the impact of the modern healthcare ecosystem. This final installment digs deeper and provides useful recommendations for alleviating those risks.

Privacy Enigma

However, containing the said issues or implementing privacy and security controls is challenging and not short of pitfalls. Fundamentally, privacy is a complex issue that jurisdictionally falls into different areas. There is no clear sense of the definition of “privacy.” What constitutes a privacy violation, who is responsible or accountable among the involved stakeholders in the event of a breach and so forth.

Also, the notion of “privacy paradox” is disconcerting and undermines the efforts to manage security and privacy. Privacy paradox implies that people’s privacy concerns and expectations are diverse and contradictory in terms of theory and outcomes and that despite people’s clearly expressed concerns about their privacy, there is a simultaneous lack of appropriate secure behavior (for instance sharing of sensitive information on social media).

Moreover, healthcare providers tend to prioritize health care utility and safety while manufacturers prioritize intended device features over security and privacy. The shortage of quality technical resources and the sheer difficulty in managing third-party environments such as the cloud or social networking healthcare promotion sites also hinder their efforts to create a sufficient cross-functional privacy and security team. Compliance is also expensive and IoT device constraints (limited power and resources) mean that privacy controls can slow down medical devices and reduce the usable battery life. In some medical devices such as pacemakers, critical functionalities cannot be updated immediately if a patch is available. These limitations further deter manufacturers from producing products with enhanced security and privacy features and manage them through the lifecycle of the product.

Nonetheless, it is inherently difficult to track the flow of PII/PHI data. Data may be collected and used in many systems throughout an organization and across the continuum of the healthcare industry, in hospitals, rehabilitation centers, insurance agencies, and so forth. The more places the data exists, the more systems an organization has to track, maintain, and protect. Even privacy-preserving mechanisms have their shortcomings. There is an inherent trade-off between information loss and confidentiality protection because the reduction in granularity results in diminished accuracy and utility of the data.

Conclusion

Regardless of the issues, regulations such as the FDA, HIPAA, the HITECH Act, GDPR, etc. are making inroads in preserving individual privacy and security. In addition to the existing principles as recommended by the regulations, we recommend the following practices that can help alleviate the risks:

  • Privacy by Design – all applications (mobile apps, software, etc.) and devices whether they are “clearly” for medical purposes or “indented” for medical purposes must follow privacy by design principles. This also involves restricting the overcollection of data and employing privacy-preserving mechanisms on data stores.
  • Privacy Policy Notices – must be simple, yet distinctly elaborate on the types of data collected, its intended usage, and the stakeholders involved. Doing so will provide consumers the opportunity to be aware of how their information will be used and by whom, in turn, helping them make an informed choice regarding the product.
  • Accountability – Clearly defining data ownership and the responsibilities of the involved stakeholders in the event of a breach might help deter the unethical motives.
  • Awareness Programs – consumers need to be educated on their rights, and how to make use of technology-assisted healthcare without undermining their privacy.
  • Periodic Risk Analysis – this includes the “covered entities” (as defined by HIPPA) regularly reviewing their records to track access to PHI and evaluating the effectiveness of security measures put in place from risks such as unauthorized access, destruction, modification, or disclosure of data.
  • End-of-Life Management – in recent times, several breaches have been attributed to poorly discarded medical devices that store PHI. Device manufacturers and healthcare providers must uphold procedures and policies that address issues that arise as a result of devices reaching their end of life.
  • Third-party audits – medical devices must be tested for security and privacy issues by an independent third party and include provisions in the management cycle to address issues unfound during the audits. All such reports, if made public, can help healthcare providers make an informed choice and not rely on public databases that are strewn with vague information.
  • Expanding the definition of “covered entities” – HIPAA only regulates the healthcare industry, and thus only applies to what the law considers “covered entities” and their “business associates.”. If the medical information is disclosed to anyone else, HIPAA would not apply. For instance, any information provided to a social networking site, or one’s employer, or a wellness app will often not be protected by the existing medical privacy regulations.

 

The Complexity and Low-Security Maturity of the Modern Healthcare Ecosystem

The Complexity and Low-Security Maturity of the Modern Healthcare Ecosystem

The modern healthcare ecosystem is undeniably rewarding to one and all. It dramatically improves the efficiency of healthcare services, optimizes healthcare workflows, and originates cutting-edging research that improves vitality. But it is also immensely complex and inherently insecure, with a high susceptibility to security threats, especially from threat actors whose primary intention is to either commit fraud, obtain non-prescribed drugs, or secure ransom.

A Privacy Nightmare?!

The complexity and low-security maturity of the ecosystem primarily stem from the presence of diverse legacy and modern technologies that have significant inherent vulnerabilities (OWASP IoT Top 10) and contrasting security pre-requisites that cloud the prevailing efforts. Unhygienic security practices such as casual data sharing in conversations, social media, and chat groups also exacerbate the situation. Other, yet common issues that add to the complexity include:

  • Unethical motives – selling PHI data to advertising agencies
  • Acquisitions – consolidation of assets and practices is common in the healthcare industry and security is only as strong as the weakest link
  • Inept and Garbled Privacy Policies – facilitate and encourage users to share data thoughtlessly
  • Disclosure Exceptions – the government is exempted from privacy rules regarding national security by law. Therefore, healthcare providers occasionally do reveal sensitive information in good faith to uphold the safety and security of the public.
  • Misrepresented Public Records – FDA requires physicians and healthcare providers to report issues with devices and in some cases, this is voluntary and cumbersome. Therefore, an issue gets tagged with another issue as a subsidiary to save up on the paperwork. This therefore results in not painting the complete picture of issues for a device accurately and hence physicians who reply on these publicly accessible reports to assess the safety of the devices prior to prescribing it to their patients may inadvertently prescribe an insecure product.
  • “Intended for medical purpose” – there are situations in which a product is not conceived by its manufacturer to be used “clearly” for medical purposes, but “intended” to be used for medical purposes, such as wellness apps and wearables. This means that manufacturers of medical apps and devices that may incidentally be medical devices do not have to create them to the same security standards required for conventional medical devices according to the law.
  • Unchecked and Uncontrolled
    • Data collection: One might not realize it, but PII and PHI are often added to a mandated public database without one’s consent in the name of national interest
    • Data usage by third parties – In an instance, it was also found that third-party analytical services could potentially link data from the fitness and health applications to other applications that contain identifying information about the user, leading to Big-brother like surveillance

The Impact

In gist, the ecosystem as a whole is an avenue for dire and far-reaching medical data privacy violations, the impact of which is manifold. It can lead to excessive fines and reputational damage for both healthcare providers and manufacturers in the event of a breach.

At an individual level, privacy violations can spring stigma, embarrassment, and discrimination, in turn resulting in unemployment, loss of health insurance and housing, and so forth. Patients may lose trust in their care provider, resulting in ineffective communication between physician and patient.

At a societal level, loss of individual trust may lead to unacceptance of medical assistive technologies, thereby hampering the efficient development and successful rollout of E-health technologies into society. Moreover, trust engenders individuals to participate in and support research if they believe their privacy is being protected (The equation is simple: higher quality data means higher quality medical care).

At a national level, it can also lead to an espionage-like situation as was evident with the Cambridge Analytica scandal. It may result in a situation where a private, for-profit, or a government organization knows and owns a lot of data about individuals, while the individuals do not know much about the company or government entity. This situation combined with unchecked usage of PII/PHI data by the data owners can inspire authoritarian intrusions into citizens’ private lives and unfairly scrutinize citizens based on opaque computer algorithms.

In part two we will cover the privacy enigma and conclude with best practices to preserve privacy.

The Age of IoT Is Here – Is Your Enterprise Secure?

The Age of IoT Is Here – Is Your Enterprise Secure?

Whether you were ready for it or not, your network is likely supporting hundreds if not thousands of connected endpoints at this very moment. When we talk about IoT, especially in the enterprise, we’re not just talking about connected refrigerators anymore. IoT is powering manufacturing lines, medical devices, and entire cities.

The possibilities for IoT have never been greater, and neither have the stakes. Just look at what happened in 2016 when Mirai, the infamous IoT botnet, took down major websites like Netflix, Twitter, and Amazon via a massive distributed denial-of-service attack using hundreds of thousands of compromised IoT devices.

Nonetheless, 2018 will be the tipping point for IoT in the enterprise with nearly half expected to deploy IoT solutions by the end of the year. What has made the explosion of IoT adoption possible is also its Achilles heel? The diversity and volume of device manufacturers, platforms, and use cases have made it nearly impossible to standardize any type of security controls. Many device manufacturers don’t even prioritize security, often because their customers don’t. The onus, therefore, is and will likely continue to be on the consumer – whether that’s an individual or an enterprise.

A lack of standard security controls isn’t the only thing standing in the way of securing IoT environments. IoT environments look different than traditional enterprise networks. They’re inherently more complicated and fragmented, requiring a different approach to security architecture. This also makes it much more difficult to have visibility and control over every connected device. Industry standards and regulations are just as fragmented and obscure. Many organizations have published their own set of best practices, but there is not a universally agreed upon standard as of yet.

To that end, Kudelski Security has spent the last year researching the current state of IoT in the enterprise and the best practices for securing it. The findings are presented in our IoT Security Reference Architecture, which is designed to help enterprise security teams build a strategy for secure IoT deployments using a combination of people, process, and technology.

Inside the architecture, the team provides an overview of the differences between IoT and traditional network environments; the IoT security threats, challenges, and business impacts enterprises face; IoT security best practices at the people, process, and policy level; and the security controls and technical measures IoT enterprises should have in place.

The reference architecture takes into account numerous security guidelines and standards, with the two primary sources of inspiration being ENISA’s Baseline Security Recommendations for IoT in the context of Critical Information Infrastructures and the Industrial Internet Consortium’s Industrial Internet of Things Volume G4: Security Framework. (A full list of IoT guidelines is available in the report.)

This guide is best-suited to organizations who already have IoT devices deployed in their environment. We recommend comparing the best practices presented in the architecture with existing security controls to identify security gaps or complementary technology solutions to improve IoT security efforts.

To download the IoT Security Reference Architecture, click here.

 

Operational Technology: The Next Cyber Battlefront

Operational Technology: The Next Cyber Battlefront

Critical infrastructure sectors are vital to the functioning of modern societies and are vulnerable to damage from natural disasters, and physical incidents. However, ever since its consolidation with IT networks, Operational Technology (OT) threat landscape has increasingly evolved to accommodate cyber-attacks similar to that of IT networks as well; the same categories of malware that attack IT computers have become relevant to OT computers and systems and the isolation of OT networks can no longer seem to be considered an effective protective measure to OT networks.

Furthermore, international fragmentation regarding cybersecurity policies and procedures and misalignment of incentives for cybersecurity best practices act as formidable hindrances, placing OT practitioners in a difficult position of balancing the market pressures of rapid innovation and sustained investments.

Building upon our success in digital security, our study into the OT threat landscape has helped us summarize that misconfiguration, vulnerable hardware and software components, poor cybersecurity practices by subcontractors, outdated network components, and lack of cybersecurity awareness have been the predominant features easing the OT threat actors’ efforts over the years. Furthermore, IT-based security mechanisms in OT environments have been far less than optimal – firewalls causing excessive latency, undependable threat quarantining techniques, labor-intensive patch/update mechanisms, and unsuitable restore mechanisms. Hence, while we cannot assume that the current IT controls can transition to OT networks, defense-in-depth mechanisms can act as guiding points for securing OT environments – effective policies and procedures revolving around risk management, training and awareness, audits and assessments act as enablers to apply security controls from a standpoint of acceptable risk and prioritize safety and reliability. Physical security, network and host monitoring, and application management complement the efforts of OT security personnel.

Therefore, Kudelski Security believes in weaving together science, technology, and policy to develop sophisticated, yet practical, solutions that will help secure information, computer and network assets in various critical infrastructure sectors. Our Embedded Security Suite provides a three-pronged approach that ensures security is integrated throughout the OT product and system lifecycle and helps guarantee long-term confidentiality, integrity, availability, and safety.

Did this blog interest you or your organization? To better understand your OT risk posture and protection mechanisms that can be applied, click here to read our Operational Technology white paper.

Securing Industrial Control Systems: A Holistic Defense-In-Depth Approach

Securing Industrial Control Systems: A Holistic Defense-In-Depth Approach

Critical infrastructure is infused with proprietary protocols and software, air-gapped networks, and robust physical security systems—an amalgam that effectuated the notion of “security by obscurity” in the industrial control systems (ICS) community. Still, business needs eventually necessitated the convergence of information technology (IT) and ICS architectures. Although this seems like a match made in heaven, from an IT perspective, designing visibility and control into a system that inherently lacks them is a challenge that can be painful.

However, IT’s “defense-in-depth” security approach could be effective for ICS security. After all, this strategy employs a holistic approach to protect all assets—people, technology, operations, and adversarial awareness—while considering its interconnections and dependencies to provide effective layers of monitoring and protection based on exposure to cybersecurity risks (Figure 1).

1. A holistic approach. A defense-in-depth security approach employs a holistic methodology to protect all assets while considering dependencies to provide effective layers of monitoring and protection based on exposure to risks. Courtesy: Kudelski Security

1. A holistic approach. A defense-in-depth security approach employs a holistic methodology to protect all assets while considering dependencies to provide effective layers of monitoring and protection based on exposure to risks. Courtesy: Kudelski Security

The following highlights plausible best-practices for securing ICS environments using a defense-in-depth approach (Figure 2).

2. Defense-in-depth framework. Application and data security are at the center of all security efforts. Courtesy: Kudelski Security

Policy, Procedures, and Training

An effective ICS security program depends on the willingness of the operations staff and management to accept security as an enabler for all computer-oriented activities, as well as their ability to apply controls from a standpoint of acceptable risk.

With this in mind, organizational leadership must clearly define and communicate cybersecurity roles, responsibilities, expectations for performance, and authorities for managers, system administrators, and users through training programs and policies, while holding individuals accountable for their performance. This minimizes the likelihood of organizational personnel inadvertently disclosing sensitive information regarding supervisory control and data acquisition (SCADA) system design, operations, or security controls. Likewise, good management practices in handling delicate situations, recognizing and rewarding employees, and looking after their well-being can help diffuse potential insider threats.

Risk Management

Designing an effective ICS security architecture requires a risk model that maps functional requirements of these complex systems and provides a holistic image of potential real-world consequences. A thorough risk analysis procedure consists of identifying all assets (including software, network elements, and people) in the organization, as well as risk drivers or threats such as disgruntled employees, terrorists, hostile countries, and more.

Establishing a “Red Team” to identify potential attack scenarios and evaluate system vulnerabilities can help detect plausible intrusion methods, which should be evaluated as risks and categorized based on their likelihood of occurrence and impact to the organization. Note that actionable policies and procedures, along with monitoring and feedback, should be part of the risk management program. Periodic review is essential to stay current with evolving threat landscapes.

Vendor and Supply Chain Management

Organizations regularly employ contractors and third-party vendors who do not have uniform cybersecurity policies and practices. This creates exploitable weaknesses in the operations chain. Therefore, it is recommended that third-party requests be reviewed by IT—as well as legal and other relevant departments—with proper documentation. Documentation should be accompanied by regularly scheduled compliance reviews/revalidation, all based on assessed risks while confining intellectual property access to a need-to-know basis only. Likewise, rigid guidelines for evaluating the purchase of new SCADA devices must be established.

Incident Response Management

A comprehensive cyber incident response plan should include both proactive (to prevent incidents) and reactive measures (to detect and manage an incident). Therefore, it is recommended to establish a 24/7 incident monitoring program with the ability to detect threats to the ICS network. Having a comprehensive response plan (such as isolation strategies and disabling affected accounts) when adversarial activity is detected is also important. As critical is having a restoration plan—including establishing system backups (redundant hardware and fault-tolerant systems)—and disaster recovery plans (fallback mechanisms).

Audit and Assess

Auditing eliminates the “paths of least resistance” that an attacker could exploit. This involves technical audits of SCADA devices and networks, physical security surveys, and assessments of all remote sites connected to the SCADA network. This will identify security concerns while maintaining compliance with standards such as NIST-80053, NERC CIP, French ANSSI, CIDX/ACC, AGA 12, API, ISA/IEC 62443, CPNI, CPNI, ISO 27001, and others.

Compliance with standards/regulations does not guarantee continuous security, but it does provide a snapshot of required controls at a point-in-time. Considering numerous factors affect the security of a system throughout its life cycle, periodic testing and verification are important in achieving optimal security.

Physical Security

Physical considerations typically refer to a ringed architecture of layered security measures that restricts access to users to fulfill their duties only. Some measures include authentication for physical access such as key cards and biometrics, facility monitoring (cameras and motion detectors), perimeter defense (fences and anti-vehicle ditches), and visitor escort procedures.

Network Management

Securing ICS against modern threats requires well-planned and implemented strategies to give network defense teams a chance to quickly and effectively detect, counter, and expel an adversary. Therefore, it is recommended to:

  • Document network architecture and identify critical systems, connections to SCADA networks, and host-to-host communications paths. Evaluate the risks and disconnect items that aren’t required.
  • Physically separate corporate and control domains. Ensure isolation of ICS networks from untrusted networks and allow real-time connectivity to external networks only if there is a defined business requirement or control function.
  • Logically segment networks and isolate critical parts of systems. Demilitarized zones (DMZ) and data warehousing provide a secure buffer zone where services and data can be shared and secure transfer of data from the SCADA network to business networks can be ensured.
  • Deploy network access control and manage authentication (preferably two-factor or more) by requiring separate credentials for corporate and control network zones, and store these in separate trust stores. Never share active directories, RSA ACE servers, or other trust stores between corporate and control networks.
  • Require any remote access to be operator-controlled and time-limited. Firewalls, virtual private networks, callback (for dial-up), multi-factor authentication, user access control, and intrusion detection can provide “secure” remote access to computer networks.
  • Engage network monitoring tools and complement them by enabling logging on all systems. Regularly audit system logs to detect suspicious activity as soon as possible.
  • Take measures to avoid “watering hole” attacks. Use a web domain name (DNS) reputation system. Get updates from authenticated vendor sites. Validate the authenticity of downloads. Insist vendors digitally sign updates and publish hashes via an out-of-bound communications path, and require they use these to authenticate.
  • Lockdown all unused ports, services on routers, switches, and network daemons. Change all default configurations and passwords.
  • Deploy deception networks to boost the odds of finding an adversary early and mitigating overall damage.

Host Management

Asset inventory is an accurate baseline for identifying necessary security controls. Having identified the assets, lock down all unused ports and services on the host, and restrict privileges to only those needed. Also, manage authentication (preferably multi-factor) with secure password policies—stressing length over complexity—which should be unique and changed at least every 90 days. Harden the host by methods that include application dynamic whitelisting, memory protection, write protection and read protection.

Implement change management policies and procedures for protection against improper modifications prior to, during, and after commissioning. Have a configuration/patch management program centered on the safe importation and implementation of trusted patches. Monitor host activity and alert unauthorized changes.

Application and Data Management

Applications and data are critical elements of ICS environments. Avoid embedding hard-coded passwords in ICS applications. Also, demand that vendors disclose any backdoors or vendor interfaces to your SCADA systems and expect them to provide systems that are capable of being secured.

Conduct an initial assessment (static and dynamic analysis) and ensure compatibility of the application with the host operating system before deploying it. Restrict access to the application and data only to intended users. Finally, it is recommended to use cryptographic controls and data sanitation techniques to maintain the integrity and authenticity of the data collected.

3. ICS threat spectrum. State-sponsored actors have the motivation, capabilities, and means to be especially disruptive, but defense-in-depth security solutions are particularly effective against those threats. Courtesy: Kudelski Security

No environment is 100% secure. A threat-actor, through intent, capability, and opportunity, will always pose a threat to an ICS network by trying to compromise an organization’s systems through its operations, personnel, technology, and other vulnerabilities. Implementing the strategies and controls presented in this article can greatly improve the security posture of ICS.

This said, the determination of a security control is context-based, and there might arise a situation where ICSs have functional or operational properties that disallow application of a security control. In such cases, it is recommended to identify, assess, and implement necessary compensatory controls and ensure the SCADA security policies and standards complement the organization. IT security policies should also evolve to meet changing threat profiles and be scalable to accommodate different standards and regulations.

It needs to be foremost in everyone’s mind that in the SCADA world, availability, reliability, and stability are the most important criteria to be considered.

Vishruta Rudresh is senior cybersecurity researcher at Kudelski Security www.kudelskisecurity.com.

Courtesy of Power Magazine. Read the original article here.