Surviving and Passing SOC Audits – Part One

Surviving and Passing SOC Audits – Part One

For over three decades, I have been intricately involved in numerous SOC audits, encompassing both internal and external penetration tests, as well as

Changing PWDLASTSET in Active Directory
Use PowerShell to Check .NET version and update
Deprecating TLS 1.0 and TLS 1.1

For over three decades, I have been intricately involved in numerous SOC audits, encompassing both internal and external penetration tests, as well as a variety of network security assessments within the private sector and government defense fields, for both medium and large corporate environments. Through this article, I aim to impart a wealth of insights, methodologies, and best practices that have not only enabled me to navigate these audits but also to excel in them, consistently earning commendable evaluations.

Given the extensive nature of this subject, it will be segmented into multiple sections to enhance organizational clarity and readability.

First, let’s clear up what is a SOC Audit?

A SOC (System and Organization Controls) audit is a comprehensive examination conducted by an independent third-party auditor to assess the effectiveness of a service organization’s internal controls. These controls typically involve data security, privacy, availability, processing integrity, and confidentiality measures that ensure customer information is protected and services are provided as promised.

The audit is designed to build trust between a service organization and its customers by demonstrating that the company follows best practices for securing and managing the information entrusted to their care.

There are different types of SOC audits, such as SOC 1, SOC 2, and SOC 3, each focusing on various aspects like financial reporting, data security/privacy controls, or providing a general overview of assurance for public distribution. The outcome of a SOC audit can significantly impact a company’s reputation and client trust, making it a critical component of regulatory compliance and risk management.

The Initial Process

Typically you will start off engaging with the third party audit team with a kick-off meeting which might consist of the following:

  • Discuss what areas will be reviewed, what is expected.
  • Submit network information for discovery like IP address ranges, user accounts to pentesters.

The first part of the audit consists of answering many questions and providing documents, policies, diagrams, etc. All evidence that is used to determine is the company following best practices and in compliance with its own policies.

Internal/External Penetration Testing

The state of your network can significantly influence the volume of remediation required. It is strongly advised to ensure your network is fully optimized prior to conducting penetration testing. This proactive approach is crucial because any vulnerabilities identified during the testing will be documented as initial findings, which may negatively impact the perception of your network’s security among clients.

With experience, you will develop the expertise to identify and address potential vulnerabilities consistently throughout the year, thereby minimizing the number of findings in your penetration reports. Alternatively, by continuing to engage with this article, you will receive guidance on identifying and rectifying issues before they escalate into findings, ultimately enhancing your network’s security.

For the auditor to conduct penetration testing, it is essential to facilitate access to the internal network. If the testing is to be performed remotely, this generally involves establishing a secure VPN connection from the tester’s system to your internal network. It is standard practice to mandate that the tester utilizes the VPN capabilities of the edge firewall with Multi-Factor Authentication (MFA) enforced. Subsequent to this, the tester should have Remote Desktop Protocol (RDP) access exclusively to a designated jump server. This server should be configured with only the essential applications required to establish an SSH connection to the internal penetration testing server. Please note, it is necessary to provision a dedicated penetration testing machine within your network infrastructure, which is commonly a Linux Virtual Machine (VM), with Kali Linux being the frequent choice.

Upon completion of the penetration testing, you will receive a Penetration Findings Report. The number of opportunities for remediation and subsequent re-scanning may vary based on your organization’s relationship with the auditing firm, typically ranging from one to two instances. It is crucial to promptly develop a spreadsheet upon receipt of the report, documenting the following details: Finding Name, Discovery Date, Severity, Current Status, Remediation Actions, Remediated Date, and pertinent Notes. This document will serve as your Penetration Findings Remediation Tracking Spreadsheet.

Auditors will expect to review this spreadsheet to verify that findings have been addressed, to understand the rationale for any unremediated issues, or to acknowledge the executive management’s acceptance of certain risks. Additionally, you are entitled to include a “Management Statement” within the Final Penetration Report. This statement can be used to dispute findings or to clarify why a particular finding does not constitute a risk within your operational context. Should you encounter such a scenario, it is advisable to request the inclusion of a management statement. Here is an exemplar of a management statement utilized for an IPv6 vulnerability:

Management Response
In response to the unmanaged IPv6 finding on the 2023 penetration test, this is on an internal network that is not exposed to the outside and would require a bad actor to first gain access to the internal network to be in any way exploitable. Microsoft does not allow and does not recommend blocking IPv6 traffic because many Microsoft Windows processes rely on IPv6 and would also cause a five second system startup delay. (

COMPANY has put the following controls in place to mitigate the possibly of exploitation:
• Domain Group Policy to disable IPv6 components for all systems.
• Domain Group Policy to enable the IPv4 Preferred over IPv6 policy for all systems.
• Blocking UDP ports 546 and 547 at both physical switch and host firewalls in vCenter.
• IPv6 Firewalling is enabled in all Palo Alto firewalls.
• IPv6 has been disabled on all network adapters on every system.
• Active DHCPv6 in each domain both in office and in data center.
• Active monitoring for malicious IPv6 traffic.

COMPANY management feels with these controls in place that the risk level is low; they are also in the process of updating all switches to support DHCP Guard, which is the preferred recommended remediation for this finding.

This will help greatly by explaining right away to your customers that may request to see the report more about the finding and your remediation efforts.

*The scope of your company’s services to clients may necessitate both internal and external penetration testing. Additionally, web application testing becomes pertinent if your company provides Software as a Service (SaaS) offerings.

Please ensure to communicate emphatically to the penetration testers that they are engaging with a production environment. It is imperative that their activities do not disrupt business operations. Throughout the penetration testing process, all IT personnel must be vigilant and promptly address any alerts or anomalies, which may include false positives resulting from the testing activities.

It is essential to recognize that penetration testers serve as allies in our cybersecurity efforts. Their expertise assists in uncovering potential vulnerabilities within our network—weaknesses that, if left undetected, could be exploited by malevolent entities to infiltrate, exfiltrate sensitive data, or disrupt our network’s integrity.

Continue to Part Two