" access control Archives - LuxSci

Posts Tagged ‘access control’

Improve Account Security by Enabling Multifactor Authentication

Tuesday, May 17th, 2022

This month, the Cybersecurity and Infrastructure Security Agency (CISA) launched an initiative called MFA May to encourage individuals and businesses to enable multifactor authentication for their accounts. This article defines multifactor authentication and explains why organizations should implement it to improve the security of their accounts.

multifactor authentication

 

What is Multifactor Authentication?

Multifactor authentication requires users to present two or more credentials to log in to their accounts. Multifactor authentication is sometimes called two-factor authentication for this reason. The first factor required is a typical username and password. The second factor is usually a code contained within a text, email, or push notification. The user must enter this numerical code to confirm that they are logging into the account. Sometimes an authenticator application is used to generate the code. Instead of a numerical code, the second factor could be a biometric marker like a thumbprint scan.

By requiring a second piece of information to log in to an account, multifactor authentication increases the security of accounts. Even if a hacker gets ahold of your password, they will be unable to log in to an account without the second piece of authentication.

How Multifactor Authentication can Stop Cybercriminals

As you can tell, multifactor authentication is an effective tool for limiting account access. A study by Microsoft found that users who enable multifactor authentication for their accounts will block 99 percent of automated attacks.

It is easier than ever before for hackers to acquire users’ passwords. Data breaches compromise millions of account credentials each year, which can be purchased on the dark web for pennies. Hackers can also use dictionary attacks to guess simple passwords using computer technology. Lastly, users may unwittingly hand over their credentials to a malicious actor during a phishing attack.

However, administrators can stop these attacks by enabling multifactor authentication. Even if a hacker knows your password, they will be unable to access your account without that second piece of information.

How to Enable Multifactor Authentication

Many vendors now offer multifactor authentication. We recommend enabling it as often as possible, especially for sensitive accounts like email, financial accounts, and medical records.

LuxSci has offered options for multifactor authentication to our users for over a decade. Users have the flexibility to choose the second option for authentication. They can choose to send a token to an alternate email address or enable a third-party app like DuoSecurity or Google authenticator to validate their identities. Please contact our support team to learn more about enabling multifactor authentication on your LuxSci account.

Conclusion: Why Use Multifactor Authentication

Cyber threats are increasing across all industries. Although HIPAA does not yet require users to implement multifactor authentication, security experts strongly recommend it. Enabling multifactor authentication is an inexpensive and effective way to improve your security posture. Although users may object to the extra step, enforcing multifactor authentication as an administrator is a smart move.

HIPAA Compliance for Mobile Apps

Tuesday, November 9th, 2021

Many people rely on mobile devices to access the Internet, and apps are a convenient way to deliver online services. The health industry has also turned to mobile apps to provide health care services on the go.

In some industries, developing apps may be relatively straightforward. However, those that deal with PHI need to understand the HIPAA compliance requirements for mobile apps. If your company’s app isn’t HIPAA compliant, it could result in heavy fines or a data breach, which could seriously harm your business’s finances and its reputation.

To develop a HIPAA-compliant app, privacy and security need to be considered from the start.

hipaa compliance for mobile apps

What Exactly Is an App?

Before we get too deep into HIPAA compliance, we should take a step back and clarify what an application is. Most people use them every day, but not everyone will know how they differ from other kinds of software.

At its highest level, an app is a software program that is designed to help users perform activities. This contrasts with system software, such as an operating system, which generally works in the background.

The three main types are web apps, desktop apps and mobile apps. Web apps run in your browser, things like your webmail or Google Translate. Desktop apps tend to be full-featured, while mobile apps are stripped-back versions that focus on making the most out of the tablet or smartphone experience. There are also hybrid apps that embed mobile websites inside apps.

While Microsoft Word and the alarm clock on your phone are both apps, people will often be referring to mobile apps when they use the term.

Does My App Need to Be HIPAA-Compliant?

Health and wellness apps have become more sophisticated and are often recommended by medical practitioners to help patients manage medical conditions. However, not every app is required to meet HIPAA regulations. To determine whether an app should be HIPAA-compliant, consider whether your business practices make you a covered entity or a business associate of an entity.

Another complex aspect is understanding what actually counts as PHI. PHI is identifiable information that includes medical test results, prescriptions, billing details and insurance, among an array of other things. Weight loss data, calories burned, heart rate and other similar readings are not normally considered PHI unless they are attached to identifiable information.

If your business processes PHI as a covered entity or a business associate, you are subject to HIPAA regulations. If your company offers services directly to customers that are unrelated to their healthcare provider or insurance, it is unlikely to be covered by HIPAA.

Because of this, apps like MyFitnessPal are exempt from the regulations, because they don’t process PHI, nor do they conduct their business through healthcare providers. Conversely, an app from your health plan that stores your healthcare records would be regulated under HIPAA. Similarly, email, chat, texting, and video conferencing apps that may be used by healthcare providers to communicate with their patients would also need to be HIPAA-compliant. 

If you do not secure PHI properly, you could be subjected to financial penalties. The FTC recently announced it will begin enforcing the Health Breach Notification Rule for health apps. The rule requires entities to deliver breach notices to customers by first class mail no later than 60 calendar days after discovering a breach. Companies must also notify the FTC and in some cases, the media. Companies can face penalties up to $43,000 per violation per day for noncompliance.

HIPAA Compliance for Mobile Apps

If your company has an app that falls under HIPAA regulations, you will need to put serious consideration into its privacy and security measures. It is best to keep HIPAA in mind from the earliest planning stages to ensure that the app is compliant and to reduce the chance of penalties or any significant breaches. App security starts with corporate compliance; your company and your developers need to do all of the things necessary for compliance (see HIPAA Compliance Checklist), including training, risk assessments, etc.

From the app design stage forward, you should limit the use and sharing of PHI in your App to the minimum that is necessary to complete the task. If your data is processed by any outside entities, you will also need to sign a business associate agreement (BAA) with them to ensure that they are complying with the regulations as well.

You should also understand the additional risks that come with processing PHI on devices. Smartphones and tablets can easily be lost or stolen and they have a range of features that bring new security challenges.

Developing an app brings up a different set of complications when compared to SaaS (software-as-a-service .. i.e. using web-based applications), because apps generally store data locally and need access control measures in place to ensure that the data is secure. Because of this, it is best to go above and beyond HIPAA regulations to safeguard your customer data.

Control Access to Protect PHI

Access control is critical for apps that process PHI. Mobile devices have a high risk of being stolen or accessed by unauthorized entities. With the right access control measures in place, the risk of anyone being able to view sensitive patient data is minimized.

First, ensure that your app can only be accessed with a unique ID. To authenticate their identity, a user also needs to prove who they are. Require the use of a strong password or biometric data (like fingerprints) to login.

If PHI is going to be available in an app, automatic logoff is important for preventing unauthorized access. People often keep their apps logged in and leave their devices unattended. Without automatic logoff after a set period of time, the user’s PHI becomes more vulnerable to unauthorized access. Many apps neglect auto-logoff and keep users logged in indefinitely, relying instead on the device’s own login and logoff functionality instead. This may be sufficient to pass your HIPAA risk assessments; however, it is far more secure (though far more annoying) to institute app-level login and logoff requirements. Perhaps the pervasiveness of biometrics will make remove the annoyance factor of requiring authentication to gain access on demand.

We highly recommend that app developers institute auto-lockout after a short period of inactivity and use fingerprints or other means to resume access. Several access failures should cause your app to back off and require the full regular password to re-authenticate. This mitigates the weaker nature of a fingerprint or pin for access resumption.

Encrypt App Data

Encryption is another key aspect of preventing PHI from being exposed. Data should be encrypted at all times except when it is in use. This prevents anyone who may be listening in from accessing the data. Instead of being able to view the PHI, all they will see is ciphertext. Data encryption can safeguard PHI from other running apps and from attackers who may be trying to break into a device’s hard drive. Relying on a device’s disk encryption provides a basic layer of safety, but it does not protect data against other malicious running apps.

Auditing to Monitor Access

Any HIPAA-compliant app should have mechanisms in place to monitor and log access to PHI. These logs help detect any unauthorized access in the event of a breach.

HIPAA-Compliant Web Hosting

Apps are often just the front-end interface of a company’s website. To protect data on the back-end, host the website with a HIPAA-compliant provider. Your company needs to sign a business associate agreement with the provider to ensure that they are safeguarding PHI. LuxSci offers HIPAA-compliant hosting and we even have a free eBook that goes through the subject in more depth.

Keep Your App Updated

The threat landscape is constantly changing. Update your app whenever new vulnerabilities are discovered to protect patient data. Outdated apps are easy targets for hackers, so it is essential to patch regularly.

Be Careful with Push Notifications

Push notifications are visible even when a screen is locked. Do NOT include PHI in these notifications. If someone else sees a push notification that contains PHI, it could be considered an unauthorized access violation. This unauthorized disclosure could result in fines for your organization.

Mobile Apps Are Easy to Use, but Are They Secure?

Many healthcare organizations are seeing the value in developing apps for their patients because of their simple nature and ubiquity. While apps can certainly be useful, companies need to tread carefully and consider HIPAA regulations from the start.

Devices and apps introduce a range of security and privacy issues. It is exceedingly important that adequate measures are taken to guard the PHI of users. If neglected, your organization could face significant penalties or a serious breach. When developing a mobile application, consider your security and compliance requirements from the start.

Zero Trust and Dedicated Servers

Tuesday, July 6th, 2021

We will continue on in our series on Zero Trust, this time discussing Zero Trust and dedicated servers. As a quick recap, the Biden Administration ordered all federal agencies to develop a plan to adopt Zero Trust Architecture. This is a security model that begins with the assumption that even an organization’s own network may be insecure.

It accepts that bad actors may be able to penetrate the network, therefore a network designed under the Zero Trust model is built to make security perimeters as small as possible. Zero Trust Architecture also involves constantly evaluating those who are inside the network for potential threats.

One of the core aspects of Zero Trust Architecture is the concept of trust zones. Once an entity is granted access to a trust zone, they also gain access to other items in the trust zone. The idea is to keep these trust zones as small as possible to minimize what an attacker would be able to access if there is a breach.

Dedicated servers are a critical component of trust zones and Zero Trust Architecture as a whole.

zero trust and dedicated servers

The Role of Dedicated Servers in Zero Trust Architecture

Dedicated servers are an important part of Zero Trust Architecture. LuxSci customers can host their services on their own dedicated servers or server clusters, instead of sharing a server with other clients who may introduce additional threats. This isolates an organization’s data and resources from other entities, creating a small trust zone.

LuxSci also uses micro-segmentation to protect each customer’s server cluster. Our solution is host-based, and the endpoints are protected by firewalls. Each customer’s server (or cluster of servers) is dynamically configured in a micro-segment using server-level firewalls. This means that each customer is separated from others, and there is no privileged access between customers.

As a dynamic host-based micro-segmentation solution, this setup adapts fluidly to software modifications, service alterations, customer changes, and new developments in the threat landscape (as detected by automated systems).

Our customers can also choose to place a static traditional network firewall in front of their assets. This acts as an additional line of defense. With this traditional firewall on top, both customer assets and the dynamic micro-segment are placed in a well-defined network segment with added ingress and egress rules.

Access Controls

LuxSci’s dynamic host-based micro-segmentation solution is complemented by our flexible and highly configurable access controls. These include:

  • Two-factor authentication
  • Time-based logins
  • IP-based access controls
  • APIs that can be restricted to the minimum needed functionality
  • Application-specific passwords

These configuration options allow your organization to tailor access to your systems on a more granular level, limiting unauthorized access while still making resources available where necessary.

Limiting access and verifying user identities are important aspects of Zero Trust Architecture. These access controls fit hand-in-hand with our micro-segmentation setup for protecting server clusters.

Zero Trust: Dedicated Servers vs Shared Cloud Systems

A shared cloud system is not suited to the Zero Trust model, because the data and computations for different customers are managed in a shared environment. This means that segmentation isn’t possible, so the potential threats from other customers on shared resources can’t be eliminated. The risks of using a shared cloud server have been well-documented elsewhere. The industry’s shift to Zero Trust Architecture only reinforces the importance of using dedicated server environments.

Compared to cloud environments, dedicated servers are better aligned with Zero Trust Architecture. LuxSci’s dynamic customer micro-segmentation isolates customers from each other, protecting your organization from these additional threats. A second layer of network firewalls only serves to reinforce the separation, making the defenses even more formidable.

Contact our team if you want to learn more about how dedicated servers and Zero Trust Architecture can help to protect your organization from advanced threats.

What exactly does HIPAA say about Email Security?

Friday, August 30th, 2013

Performing daily business transactions through electronic technologies is accepted, reliable, and necessary across the nation’s healthcare sectors. Therefore, electronic communications and email have become a standard in the healthcare industry as a way to conduct business activities that commonly include:

  • Interacting with web-savvy patients;
  • Real time authorizations for medical services;
  • Transcribing, accessing and storing health records;
  • Appointment scheduling;
  • Referring patients; and
  • Submitting claims to health plan payers for payment of the services provided.

Read the rest of this post »

Ultimate Control: Manage Access to Your Services with Custom Firewalls

Saturday, October 13th, 2012

Can I block this one IP that is scanning our accounts?  Can I restrict my account so that people can only access it from our office network, or require that they authenticate to WebMail first (using two-factor authentication)?

LuxSci is constantly asked for fine-grained access controls by customers who are in shared environments (sharing the same servers with many other accounts).  However, blocking access from IP addresses globally at the request of one customer may potentially affect other customers using the same system.

That is, until now. LuxSci customers can now configure their own custom firewalls to allow and deny access as they see fit without affecting other customers sharing the same server(s).

Read the rest of this post »