Security Bloggers Network 
SBN

Cybersecurity in Healthcare: Beyond the Myths

Avatar photo by Thomas Segura on February 12, 2024

Cybersecurity in Healthcare: Beyond the Myths

This article was originally published at TheHackerNews

Let's begin with a thought-provoking question: among a credit card number, a social security number, and an Electronic Health Record (EHR), which commands the highest price on a dark web forum?

Surprisingly, it's the EHR, and the difference is stark: according to a study, EHRs can sell for up to $1,000 each, compared to a mere $5 for a credit card number and $1 for a social security number. The reason is simple: while a credit card can be canceled, your personal data can't.

This significant value disparity underscores why the healthcare industry remains a prime target for cybercriminals. The sector's rich repository of sensitive data presents a lucrative opportunity for profit-driven attackers. For 12 years running, healthcare has faced the highest average costs per breach compared to any other sector. Exceeding an average of $10 million per breach, it surpasses even the financial sector, which incurs an average cost of around $6 million.

The severity of this issue is further illustrated by a more than threefold increase in reported "hacking or IT incidents" to the US Department of Health & Human Services (HSS) from 2018 to 2022.

Cybersecurity in Healthcare: Beyond the Myths
Number of breaches reported to the US Department of Health & Human Services (HHS) as per law. A hacking or IT incident is a type of breach that involves a technical intrusion.cyber

The primary adversary in this scenario is a well-known threat: ransomware. This form of cyberattack has increasingly targeted the healthcare sector, exploiting the critical nature of patient care to exert pressure. Ransomware cartels find the healthcare industry an ideal target due to several factors:

  • Innovations in medical technology, including diagnostic tools, telemedicine, wearable health devices, and digital imaging, have led to an increased reliance on digital systems.
  • High Digitalization: The healthcare sector is driven by innovation, with many third parties manipulating very sensitive data like EHRs.
  • Resource Constraints: Many healthcare organizations suffer from understaffing and a lack of cybersecurity expertise, leaving their (often legacy) IT environments vulnerable to attacks.
  • High Stakes: The imperative to maintain patient care creates strong incentives for healthcare organizations to pay ransoms, making them attractive targets.

Despite these challenges, the situation isn't entirely dire. A key strategy for protecting sensitive data involves adopting the mindset of an attacker.This approach sheds light on the cost-benefit calculus of potential attackers, identifying which assets they might target and their likely methods of attack.

An important realization in this context is that the nature of threats hasn't necessarily become more sophisticated; rather, the attack surface – the range of potential points of vulnerability – has expanded. By focusing on asset inventory and monitoring the attack surface, organizations can gain a strategic advantage. Viewing their own systems from the attacker's perspective enables them to anticipate and counteract potential threats, effectively turning the tables on the attackers.

How ransomware work

The stereotypical image of hackers as solitary figures conducting multi-million dollar cyber heists clad in black hoodies is largely a myth. Today's cybercrime landscape is much more sophisticated, resembling an industry with its own sectors and specializations. This evolution has been facilitated by anonymous networks and digital currencies, which have transformed ransomware into a commodified business.

Cybercrime has indeed become more organized, yet the fundamental tactics remain largely unchanged. The primary strategy still involves exploiting human errors and capitalizing on "low-hanging" vulnerabilities within the vast software ecosystem.

A key insight into the mindset of cybercriminals is recognizing that they operate as businesses. They invariably opt for the most cost-effective and straightforward methods to achieve their goals. This includes specialization in areas like gaining initial access to IT environments, which is then sold to other criminal entities like gangs, affiliates, nation-states, or even other Initial Access Brokers (IABs).

Ironically, hacking web applications might seem almost outdated compared to the simpler strategy of exploiting publicly accessible data for profit. A poignant example is the breach of 23andMe clients' genetic records. This breach was not a result of direct hacking; rather, the attacker used credentials leaked from other sites, accessed the data, and then monetized it on the dark web.

The source of such exploitable data is often surprisingly simple. Sensitive information, including API keys, tokens, and other developer credentials ("secrets"), is frequently left exposed on platforms like GitHub. These credentials are particularly valuable as they provide direct access to lucrative data, making them a prime target for cybercriminals seeking easy profits.

Why catching secrets before they do could be your lifesaver

In 2022, a staggering 10 million secrets were found leaked on GitHub, as reported by the security firm GitGuardian. This represents a 67% increase from the previous year, indicating that roughly one in every ten code authors exposed secrets during this period.

This sharp increase can be attributed to the pervasive nature of secrets in modern software supply chains. These secrets, which are essential for connecting various IT components such as cloud services, web apps, and IoT devices, are also prone to escaping oversight and becoming significant security risks. Cybercriminals are keenly aware of the value of these leaked secrets, as they can provide access to internal IT systems or even direct entry to terabytes of unprotected data.

The recent disclosure by Becton Dickinson (BD) of seven vulnerabilities in their FACSChorus software, as reported by the HIPAA Journal, is a stark reminder of the ongoing application security challenges in the healthcare sector. One notable vulnerability, CVE-2023-29064, involved a hardcoded secret in plaintext that could potentially grant administrative privileges to unauthorized users.

To defend against such vulnerabilities, it's essential for organizations to adopt a stance of continuous vigilance. Automatically monitoring your organization's presence on platforms like GitHub is critical to prevent surprises from exposed secrets. It's equally important to have a dedicated team conducting thorough research to identify any exposed assets, misconfigured data storage, or hardcoded credentials within your digital infrastructure.

Taking proactive measures is key, and one practical step is to consider a free complimentary GitHub attack surface audit provided by GitGuardian. Such an audit can offer valuable insights, including an evaluation of the organization's digital footprint on GitHub. It can highlight the number of active developers using professional emails, the extent of potential leaks linked to the organization, and identify the ones that could be exploited by malicious actors.

Moreover, to further strengthen your cybersecurity posture, integrating honeytokens into your security strategy is advisable. Honeytokens serve as decoys that can lure and detect unauthorized access, significantly reducing the Mean Time to Detection (MTTD) of breaches. This approach adds an additional layer of security, helping to contain the reach of potential attackers and mitigate the impact of a breach.

Wrap up

The prominent threat to the healthcare sector comes from ransomware groups, which have evolved into sophisticated, business-like operations. To counter these dangers, healthcare organizations need to engage in vigilant, proactive strategies. Key among these is the regular monitoring of digital footprints on platforms like GitHub and conducting thorough research to identify and safeguard against exposed assets. This approach is vital to protect patient data and privacy. Utilizing services like the free GitHub attack surface audit can provide invaluable insights into potential vulnerabilities.

As technology continues to evolve, the nature of cybersecurity threats will inevitably progress. It's imperative for the healthcare industry to stay ahead of these challenges. This includes not only implementing the latest security technologies but also fostering a culture of security awareness among all staff members.

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Automated Secrets Detection authored by Thomas Segura. Read the original post at: https://blog.gitguardian.com/unveiling-the-cyber-threats-to-healthcare-beyond-the-myths/

Thomas Segura
Avatar photo

Thomas Segura

What You Need to Scale AppSec Thomas Segura - Content Writer @ GitGuardian Author Bio Thomas has worked both as an analyst and as a software engineer consultant for various big French companies. His passion for tech and open source led him to join GitGuardian as technical content writer. He focuses now on clarifying the transformative changes that cybersecurity and software are going through. Website:https://www.gitguardian.com/ Twitter handle: https://twitter.com/GitGuardian Linkedin: https://www.linkedin.com/company/gitguardian Introduction Security is a dilemma for many leaders. On the one hand, it is largely recognized as an essential feature. On the other hand, it does not drive business. Of course, as we mature, security can become a business enabler. But the roadmap is unclear. With the rise of agile practices, DevOps and the cloud, development timeframes have been considerably compressed, but application security remains essentially the same. DevSecOps emerged as an answer to this dilemma. Its promise consists literally in inserting security principles, practices, and tools into the DevOps activity stream, reducing risk without compromising deliverability. Therefore there is a question that many are asking: why isn't DevSecOps already the norm? As we analyzed in our latest report DevSecOps: Protecting the Modern Software Factory, the answer can be summarized as follows: only by enabling new capacities across Dev, Sec and Ops teams can the culture be changed. This post will help provide a high-level overview of the prerequisite steps needed to scale up application security across departments and enable such capabilities. From requirements to expectations Scaling application security is a company-wide project that requires thorough thinking before an y decision is made. A first-hand requirement is to talk to product and engineering teams to understand the current global AppSec maturity. The objective at this point is to be sure to have a comprehensive understanding of how your products are made (the processes, tools, components, and stacks involved). Mapping development tools and practices will require time to have the best visibility possible. They should include product development practices and the perceived risk awareness/appetite from managers. One of your objectives would be to nudge them so they take into account security in every decision they make for their products, and maybe end up thinking like adversaries. You should be able to derive security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate these into a common set for all applications, setting goals to align the different teams collaborating to build your product(s). Communicating transparently with all relevant stakeholders (CISO, technical security, product owner, and development leads) about goals and expectations is essential to create a common ground for improvement. It will be absolutely necessary to ensure alignment throughout the implementation too. Open and accessible guardrails Guardrails are the cornerstone of security requirements. Their nature and implementation are completely up to the needs of your organization and can be potentially very different from one company to the other (if starting from scratch, look no further than the OWASP Top10). What is most important, however, is that these guardrails are open to the ones that need them. A good example of this would be to centralize a common, security-approved library of open-source components that can be pulled from by any team. Keep users' accessibility and useability as a priority. Designing an AppSec program at scale requires asking “how can we build confidence and visibility with trusted tools in our ecosystem?”. For instance, control gates should never be implemented without considering a break-glass option (“what happens if the control is blocking in an emergency situation?”). State-of-the-art security is to have off-the-shelf secure solutions chosen by the developers, approved by security, and maintained by ops. This will be a big leap forward in preventing vulnerabilities from creeping into source code. It will bring security to the masses at a very low cost (low friction). But to truly scale application security, it would be silly not to use the software engineer's best ally: the continuous integration pipeline. Embed controls in the CI/CD AppSec testing across all development pipelines is the implementation step. If your organization has multiple development teams, it is very likely that different CI/CD pipelines configurations exist in parallel. They may use different tools, or simply define different steps in the build process. This is not a problem per se, but to scale application security, centralization and harmonization are needed. As illustrated in the following example CI/CD pipeline, you can have a lot of security control steps: secrets detection, SAST, artifact signing, access controls, but also container or Infrastructure as Code scanning (not shown in the example) (taken from the DevSecOps whitepaper) The idea is that you can progressively activate more and more control steps, fine-tune the existing ones and scale both horizontally and vertically your “AppSec infrastructure”, at one condition: you need to centralize metrics and controls in a stand-alone platform able to handle the load corresponding to your organization’s size. Security processes can only be automated when you have metrics and proper visibility across your development targets, otherwise, it is just more burden on the AppSec team's shoulders. In turn, metrics and visibility help drive change and provide the spark to ignite a cultural change within your organization. Security ownership shifts to every engineer involved in the delivery process, and each one is able to leverage its own deep (yet partial) knowledge of the system to support the effort. This unlocks a world of possibilities: most security flaws can be treated like regular tickets, rule sets can be optimized for each pipeline based on criticality, capabilities or regulatory compliance, and progress can be tracked (saved time, avoided vulnerabilities etc.). In simpler terms, security can finally move at the DevOps speed. Conclusion Security can’t scale if it’s siloed, and slowing down the development process is no longer an option in a world led by DevOps innovation. The design and implementation of security controls are bound to evolve. In this article, we’ve depicted a high-level overview of the steps to be considered to scale AppSec. This starts with establishing a set of security requirements that involve all the departments, in particular product-related ones. From there it becomes possible to design guardrails to make security truly accessible with a mix of hard and soft gates. By carefully selecting automated detection and remediation that provide visibility and control, you will be laying a solid foundation for a real model of shared responsibility for security. Finally, embedding checks in the CI/CD system can be rolled out in multiple phases to progressively scale your security operations. With automated feedback in place, you can start incrementally adjusting your policies. A centralized platform creates a common interface to facilitate the exchange between application security and developer teams while enforcing processes. It is a huge opportunity to automate and propagate best practices across teams. Developers are empowered to develop faster with more ownership. When security is rethought as a partnership between software-building stakeholders, a flywheel effect can take place: reduced friction leads to better communication and visibility, automating of more best practices, easing the work of each other while improving security with fewer defects. This is how application security will finally be able to scale through continuous improvement.

thomas-segura has 61 posts and counting.See all posts by thomas-segura