Cybersecurity

Article Dean Dorton

A federal class-action lawsuit was filed in the U.S. District Court Western Kentucky District of Kentucky Louisville Division against Norton Healthcare on behalf of employees and patients whose personal information was stolen from Norton’s servers in a cyber attack earlier this year.

Cyber attacks on healthcare systems and providers of all sizes have seen a sharp uptick since the beginning of the COVID-19 pandemic. Threats continue to grow as the number of connected devices across more networks increases. Combined with cloud services gaining in popularity, this creates a larger attack surface for bad actors constantly evolving the sophistication of their efforts. Everything from patient admissions information and payment records to private electronic health records (EHRs), e-doctor visits, medical device wearables, and portable medical technologies can all be susceptible to compromise.

But a healthy cyber security posture can help defend against more than just an attack on a network, devices, or even an organization’s reputation: It can aid in protecting the most vulnerable among us.

By understanding the challenges at hand and putting mitigation efforts in place, healthcare providers can work toward the all-important triad of confidentiality, integrity, and availability of information. Meanwhile, they ensure access to vital patient data at the most crucial moments in the continuum of care.

The Most Common Healthcare Cyber Threats

As the technology we rely on to deliver cutting-edge care continues to advance, so too do the complexities and stealth of cyber attacks.

The most common purpose of an attack, as we’ve noted, is accessing sensitive information to either sell or for personal use. The methods of these attacks, however, can be as varied as the attackers, including destruction of data and industrial espionage.

In the context of healthcare cyber security, here are a few threats causing the greatest damage to bottom lines — and reputations.

Ransomware

When a machine or a device is infected by ransomware, the files and other data are typically encrypted, access is denied, and ransom is demanded. Patient care services are particularly vulnerable to this type of attack due to their high dependence on technology combined with the critical nature of their daily operations. In fact, ransomware attacks on the sector occurred at a rate of four incidents per week in the first half of 2021.

Health records are a low-risk, high-reward target for cybercriminals because each record can fetch a high value on the underground market. Unfortunately, ransom payment doesn’t always result in the return of the stolen information.

Phishing

Many significant security incidents are caused by a variety of phishing attacks. The effectiveness can be attributed to criminals targeting the weakest link in the cyber security chain: people. Unwitting users may click on a malicious link or open a malicious attachment and infect their computer systems with malware that ultimately divulges information or enables access to it.

Cloud Storage Threats

Many healthcare providers have been switching to cloud-based storage solutions for greater convenience, and an “always on” connectivity. Unfortunately, not all cloud-based solutions are HIPPA compliant, making them easy targets for intruders. Threats include improper access management, data breach, data leak, loss of sensitive data, and misconfiguration of cloud storage. What’s more, some organizations don’t properly encrypt the data — or implement restrictions — before transmitting.

Be sure to utilize a private cloud or an on-premise data center to regularly secure and encrypt data.

Internal Threats

In our high-level primer on cyber security, we share research indicating that 90% of cyber claims stem from some type of human error or behavior. As more healthcare professionals access sensitive patient information on more devices — some which are still unsecured — the likelihood of an attack increases. While some internal threats can be malicious, most are the result of negligence or unwitting compromise.

Give your healthcare organization a first step in the right direction to mitigating risks, safeguarding your valuable data, and protecting your reputation. Connect with Dean Dorton for a cyber security risk assessment today.

Article Dean Dorton

According to the Verizon 2022 Data Breach and Investigations Report, 84% of data breaches entail payment account data, while 93% are driven by financial motives.

Credit card data is highly valuable and sought after by malicious actors, leading to the need for strong security measures. In response to evolving tactics, the Payment Card Industry Data Security Standard (PCI DSS) has introduced version 4.0 to enhance the protection of credit card data.

This guide provides an overview of the major changes introduced in PCI DSS 4.0, categorized as operational requirements (for sales and customer relations) and technical requirements (for information technology group). It aims to help organizations understand and implement these updates to safeguard cardholder data effectively.

Getting Started with PCI DSS 4.0

  • Document, assign, and ensure understanding of roles and responsibilities associated with each of these requirements.
  • Perform and document risk analysis/assessment for new requirements.
  • Broaden the concept of “network segmentation” to include a wider range of segmentation controls.

1. Install and Maintain Network Security Controls

Technical responsibilities for this step include the following:

  • Replace “firewalls” and “routers” with “network security controls” to accommodate various technologies.
  • Review configurations of network security controls at least once every six months.
  • Secure configuration files to maintain the integrity of security controls.
  • Implement security controls on any computing device connecting to untrusted networks and the cardholder data environment (CDE).

2. Protect Stored Account Data

Technical responsibilities for this step include the following:

  • Minimize data storage through data retention and disposal policies, verified at least every three months.
  • Encrypt electronically stored sensitive authentication data (SAD) before authorization.
  • Prevent copying or relocation of primary account numbers (PAN) during remote access.
  • Use cryptographic hashes or disk/partition-level encryption to render PAN unreadable on removable electronic media.

Operational responsibilities for this step include the following:

  • Ensure third parties storing data on behalf of the organization comply with data retention and disposal policies.
  • Maintain an inventory of trusted keys and certificates used for PAN transmission over open, public networks.

3. Protect Cardholder Data During Transmission Over Open Networks

Technical responsibilities for this step include the following:

  • Confirm the validity and non-revocation of certificates used to safeguard PAN during transmission.
  • Maintain an inventory of trusted keys and certificates used for PAN transmission.

4. Protect Systems and Networks from Malicious Software

Technical responsibilities for this step include the following:

  • Define the frequency of periodic evaluations for system components not at risk for malware based on targeted risk analysis.
  • Implement processes and mechanisms to detect and protect against phishing attacks.

Operational responsibilities for this step include the following:

  • Define the frequency of periodic evaluations for system components not at risk for malware based on targeted risk analysis.
  • Implement processes and mechanisms to detect and protect against phishing attacks.

5. Develop and Maintain Secure Systems and Software

Technical responsibilities for this step include the following:

  • Maintain an inventory of internal, external, and third-party software components for vulnerability and patch management.
  • Deploy an automated solution for detecting and preventing web-based attacks on public-facing web applications.
  • Manage all loaded payment page scripts by authorizing and assuring their integrity through written justifications.

6. Restrict Access to System Components and Cardholder Data

Technical responsibilities for this step include the following:

  • Assign application and system accounts and related access privileges based on the least privilege necessary.
  • Review access by application and system accounts on a frequency defined in the risk analysis.
  • Increase password length to a minimum of 12 characters (or 8 if the system doesn’t support 12 characters).
  • Implement Multi-Factor Authentication (MFA) for all access into the CDE.
  • Ensure MFA systems are resistant to replay attacks, cannot be bypassed, and use at least two different authentication factors.

Operational responsibilities for this step include the following:

  • Review all user accounts and access privileges, including third-party/vendor accounts, at least every six months.

7. Restrict Physical Access to Cardholder Data

Technical responsibilities for this step include the following:

  • Define the frequency and types of inspections for point of interaction (POI) devices in the targeted risk analysis.

8. Log and Monitor All Access to System Components and Cardholder Data

Technical responsibilities for this step include the following:

  • Use automated mechanisms for performing audit log reviews.
  • Define periodic log reviews for system components not covered by automated mechanisms.
  • Detect, alert, and address failures of critical security control systems promptly.

Operational responsibilities for this step include the following:

  • Define periodic log reviews for system components not covered by automated mechanisms.

9. Test Security of Systems and Networks Regularly

Technical responsibilities for this step include the following:

  • Manage all applicable vulnerabilities not ranked as high-risk or critical.
  • Perform authenticated scanning for internal vulnerability assessments.
  • Deploy change and tamper-detection mechanisms for HTTP headers and payment pages received by consumer browsers.

10. Support Information Security with Organizational Policies and Programs

Technical responsibilities for this step include the following:

  • Document and review cryptographic cipher suites, protocols, hardware, and software technologies annually.
  • Document and confirm PCI DSS scope and conduct reviews upon significant changes.
  • Review and update the security awareness program annually to address new threats.
  • Include threats and vulnerabilities in security awareness training that could impact CDE security.
  • Define the frequency of training for incident response personnel based on targeted risk analysis.
  • Implement incident response procedures for the detection of unexpected storage of PAN.

Operational responsibilities for this step include the following:

  • Support flexible PCI DSS requirements with targeted risk analysis.
  • Document and confirm PCI DSS scope annually and upon significant changes.
  • Include threats and vulnerabilities in security awareness training, including the acceptable use of end-user technologies.
  • Define the frequency of training for incident response personnel based on targeted risk analysis.
  • Implement incident response procedures for the detection of unexpected storage of PAN.

Implementing the updated PCI DSS 4.0 requirements is crucial for organizations to protect credit card data from unauthorized access. By following the guidelines outlined in this guide, organizations can enhance their network security, minimize data storage, encrypt sensitive information, restrict access, monitor systems, and support information security with effective policies and programs. Adhering to these measures will help mitigate the risk of credit card data falling into the wrong hands and ensure compliance with the latest PCI DSS standards.

Article Dean Dorton

For a long time, multi-factor authentication (MFA) has been considered one of the best ways to protect an organization’s assets. So much so that in 2019, Microsoft released an article stating that MFA would prevent 99.9% of attacks on accounts.

Nowadays, while MFA is still a key aspect of cybersecurity for business as well as personal use, it is the not the cure-all that it once was. Bad actors have adapted their tactics and found ways to work around MFA security measures.

Why is MFA not Enough Anymore?

Multi-factor authentication uses a combination of multiple factors to assist with proving you are who you say you are. These factors include:

  1. Something you know – This is usually a password.
  2. Something you have – This can be using your phone to receive an SMS text, an authenticator app, etc.
  3. Something you are – This is usually a physical characteristic like a palm scan or a retina scan.

To have true multi-factor authentication, there must be at least two separate factors used in conjunction. For example, this might look like using a password alongside an authenticator app. In this scenario, a user would sign into their account with their username and password and then receive a prompt to either accept a push notification or enter a code to access the desired resources.

Recently, however, threat actors have adapted their tactics to work around the MFA workflow, meaning these standard MFA practices are no longer enough to protect users and their data.

What are Threat Actors Doing?

One of the tactics threat actors have been using is an AiTM framework, or an attacker-in-the-middle framework. Under this approach, the attacker inserts a fake landing page in between the user and the legitimate application. For example, they will pass a fake landing page to the end user for Office365 utilizing a phishing email. When the user enters their credentials and accepts the push or enters the MFA code, the attacker obtains both pieces of key information and can hijack the session.

Another tactic threat actors utilize is stealing session cookies from your browser. If you are authenticated to your email or other sensitive sites, the threat actor can use malware to steal your sessions and gain access to your personal data. SIM-swapping attacks are also common and take place when a threat actor social engineers your mobile carrier to allow them to swap their controlled SIM card with yours. From there, they can gain access to your number to steal any sort of MFA codes that may be sent via text message.

One of the more frequent attacks that Dean Dorton’s Cybersecurity team has observed among major corporations is “MFA fatigue”. This is when a threat actor gains access to your credentials either through phishing or other means (data breaches, password guessing, etc.) and then sends MFA pushes to your device until you are bothered enough that you accept it.

What Can We Do?

There are a few approaches you can take to further secure your MFA.

  1. Utilize more phish-resistant MFA methods. This could be by utilizing a hardware token, such as a YubiKey, or using additional challenges along with the push notification based off risk. An example of this would be Microsoft’s Number Challenges for high-risk sign-ins in which before the authentication is established, the user must provide a number populated on their screen to their device to sign in.
  2. Avoid using text messages as an additional factor if possible. SIM swapping attacks can occur rather easily and text messages are not an ideal and secure method for MFA codes.
  3. Ensure all devices are protected with endpoint security software to avoid malware-based attacks.
  4. If experiencing excessive MFA requests that you did not initiate, continue to deny them, change your password immediately and if there is an option in your authenticator software, report the attempts as fraudulent.

If you have further questions and need assistance with evaluating your current MFA solution, please reach out to Dean Dorton’s Cybersecurity Experts today.

Article Dean Dorton

It’s late at night the day before an important deadline. You are rushing to complete a project that you have been diligently working on for months. You run into a snag and run a quick Google search for some software to help you complete your task. You find some software and click download. Next thing you know your computer is frozen from a virus. You notice a particular name that seems odd so you run another Google search from your phone and discover it is a new strand of malware and that the best course of action is to re-install your operating system. All the hard work you have put in is gone, as the latest changes to the project were not saved. You think to yourself, “what could I have done differently? I have an antivirus program installed on my machine, why was this not caught?”

 The harsh reality is that standard antivirus programs are not enough in today’s threat landscape.

In order to adequately protect oneself at an enterprise level, one needs an Endpoint Detection and Response (EDR) tool.

Why is my Antivirus Not Enough?

Most traditional AV providers use signature-based algorithms to prevent malware from being installed on your machine. This means that it identifies the file based off a unique pattern or hash (a mathematical algorithm to generate a unique set of numbers and letters) of the file. For a more in depth explanation of hashing, read this SentinelOne article. For a while, this type of detection worked because new signatures could continuously be generated for files and be blocked, but as always, the threat actors adapted and began heavily obfuscating their code so that the hash generated for the file was not the same as its unobfuscated counterpart leading to it bypassing AV solutions entirely.

What is EDR?

EDR stands for Endpoint Detection and Response. It’s the current generation of protection for endpoints (you may also have heard of XDR which is an attempt to expand the capabilities of EDR, but frankly, the product is in it’s infancy). EDR allows cybersecurity and IT professionals to not only identify threats, but it also allows them to respond. These solutions gather telemetry data constantly from endpoints and rather than using a signature-based solution to detection, it uses a heuristic (or behavioral) approach. These solutions don’t focus on the hash of a file or if the file in unique to the device, it’s monitoring how the file behaves to determine whether it’s malicious or not. A good example is a spreadsheet sent over email with macros enabled. Now the spreadsheet itself may not be malicious, but what if the macro is? The file is detected by the EDR solution and the analyst is able to respond. These solutions are also continuously enriched with the latest threat intelligence. Threat intelligence is essentially a digestible version of the latest threats, threat actors, and their various tactics. Often threat actors are creatures of habit and they follow a specific set of steps in each cyber-attack. The EDR solution will gather this intelligence and incorporate it into the platform. They also will generally include some sort of proactive threat hunting component, actively seeking out potential threats rather than waiting for them to become active.

Why Does Any of this Matter?

A natural thought is: how does this apply to my company and me? The facts is that threat actors are continuously evolving. They are finding new and creative ways to breach environments and you and your business are no exception. This ingenuity creates a headache on the defensive-side as we are often playing a cat-and-mouse game of staying ahead of attackers. A good EDR solution helps to bridge that gap. Instead of an analyst spending their day perusing threat intelligence feeds to gather malicious hashes to input, they can spend their time on other important security tasks, such as vulnerability management.

Another key takeaway here is that no tool is a magic bullet. The people that use the tool are just as important as the tool itself. Without proper training, the alerts could go unnoticed or be inadvertently marked as a false positive, when it is in fact a legitimate threat. Any tool (especially EDR) is only as effective as its wielder. Keep that in mind as an EDR solution is considered.

Within cybersecurity, if you are not evolving, you are dying.

A traditional AV solution is not good enough in 2023. If you are concerned about your current cyber security posture and would like to discuss with Dean Dorton’s Cyber Security Professionals, feel free to reach out using the contact information below.

Jordan Johnson | Cyber Security Consultant
jjohnson@ddaftech.com
859.425.7659

Article Dean Dorton

Anyone who hasn’t just arrived from the Stone Age recognizes the importance of maintaining a healthy cybersecurity program. Healthy things grow and so our cybersecurity efforts should be adapting to the ever-changing threats that are trying to push our organizations towards extinction.

Doing cybersecurity right isn’t cheap. Most colleges and universities have a dinoburger budget and can’t afford the brontosaurus ribs. How do you get the resources to protect your systems and data? One way is to communicate that some cybersecurity efforts are required and not doing them can result in loss of grant funding.

The Gramm-Leach-Bliley Act (GLBA) has been around for years, but only had a real impact on colleges and universities for the last 3 to 4 years. Like a cybersecurity program, data security laws have a need to evolve and adapt to changing threats. The standards for the safeguarding components of GLBA have been updated. Some of the updates revise prior rules while others are brand new.

Old Rule New Rule
Designate the employee(s) responsible for coordinating the information security program. A single “qualified individual” (QI) is designated to oversee, implement, and enforce the information security program. The QI may be an employee, affiliate, or service provider.
Perform a Risk Assessment Perform a risk assessment and update it periodically.
Risk assessment should include criteria for the evaluation and categorization of identifying risks. This is the use of a cyber security framework. I.E., NIST, ISO, CIS.
Risk Assessment should include criteria for the assessment of the confidentiality, integrity, and availability of information including adequacy of existing controls.
Risk assessment should include requirements identifying how risks will be mitigated based on the assessment and how the ISP will address risks.
Identify safeguards for each risk identified Identify safeguards for each risk identified.
Safeguards designed should cover – Access controls, Data inventory, Encryption, Secure application development, Multifactor authentication, Secure disposal, Change management and Monitoring and logging user activity
Annual penetration testing and vulnerability scanning*
Policies and procedures addressing – security awareness training and information security personnel are qualified and trained.
Proper oversight of service providers addressing – selevtion process, contract wording and periodic assessment.
Have a written incident response plan.*
QI to prepare and present a written report to the board of directors, at least annually, on the status of the compliance with the information security program. *

There is a new exemption rule for small organizations. If you maintain student financial aid information for less than 5,000 students, some new rules are not required. Rules marked with an asterisk (*) are applicable to the exemption rule.

The date for having these controls in place is December 9, 2022. At a minimum, you should be able to demonstrate the new rules are being met before your next Single Audit is performed in 2023.

Subscribe to Dean Dorton Insights to stay up-to-date with the latest regulatory changes.

Explore IT Audit & Compliance Services

Kevin W. Cornwell, CPA | IT Audit Associate Director
kcornwell@deandorton.com
502.566.1011

Article bop-admin

Recent years have seen a dramatic increase in the amount of publicly accessible web applications. As more organizations have expanded their internet presence, web application attacks have become increasingly profitable for threat actors. Recent vulnerabilities such as Log4j have also brought more intense scrutiny to web applications. If your organization hosts business-critical applications or is allowing customers to access their data through the web, it is no longer sufficient to rely simply on traditional external security assessments.

Why network testing is not enough

While traditional external vulnerability testing may include some light unauthenticated web application scanning, automated scanning cannot be relied upon to validate the security of web applications in the same way that it can be for network and host vulnerabilities. Every web application is unique, and automated scanning tools lack the context to catch many vulnerabilities. The only effective way to test web applications involves manual testing, supplemented with the targeted use of automated tools.

Testing from an unauthenticated context is also a problem. According to a review of 2021 breaches performed by Verizon, around 80% of the web application breaches in 2021 were attributed to stolen credentials rather than technical vulnerabilities. This represents a significant increase since 2017, when the number was 50%. The increase in this can be attributed to two attack methods: phishing and credential stuffing.

Phishing continues to be a major and successful attack vector for stealing credentials. Despite improvements in detection and response capabilities, threat actors have continued to find success with this technique. Credential Stuffing leverages large sets of usernames and passwords, usually stolen in data breaches and sold on the dark web.

An attacker will take these sets of credentials and use automated tools to test them against a wide array of websites, looking for sites where the user reused the same username and password combination. Because these methods involve the attacker gaining authenticated access to the application, it is important to ensure that any security testing is performed from an authenticated perspective.

How to perform an authenticated web application assessment

When evaluating if your web application is sufficiently comprehensive, a good resource to use is the Offensive Web Application Security Project (OWASP) Top 10. OWASP monitors web application vulnerabilities and breaches and compiles the most common types of vulnerabilities. The current list was updated in late 2021 and includes the following categories from most to least prevalent:

  1. Broken Access Control
  2. Cryptographic Failures
  3. Injection
  4. Insecure Design
  5. Security Misconfiguration
  6. Vulnerable and Outdated Components
  7. Identification and authentication Failures
  8. Software and Data Integrity Failures
  9. Security Logging and Monitoring Failures
  10. Server-Side Request Forgery

If your organization is hosting externally accessible web applications that store sensitive data, it is important to ensure that your security assessment methodology is covering at least the areas covered in the OWASP Top 10.

Penetration testing can be used to cover the majority of the OWASP Top 10 categories. The goal of the penetration test is to identify vulnerabilities from an external perspective using manual testing and targeted automated tools. The test should be performed with a white or grey box perspective, where the tester is given access to the application and one or two accounts of each role in order to sufficiently cover access control issues both between users of the same privilege level and between users of different privilege levels. With a white box approach, the tester could also be provided the source code of the application. Additionally, the tester should be provided with information about the architecture of the application and the software suites and tools in use on the back end to better understand how to attack the application.

Why penetration testing is not enough

Not all areas of the OWASP Top 10 can be covered sufficiently by a penetration assessment, so the testers should also meet with the developers to discuss the areas of Insecure Design, Software and Integrity Failures, and Logging and Monitoring. These areas cannot be observed from an external perspective so a collaborative approach should be used to ensure coverage.

With this approach, you can ensure that your application is secure against the most prevalent web application vulnerabilities in the threat landscape right now and ensure that your user’s data is secure.

Cyber Security Services

Gui Cozzi
Cybersecurity Practice Lead
gcozzi@ddaftech.com • 859.425.7649