QUESTIONS TO ASK AUDITOR

Depending on your organization, if your organization is yet to acquire SOC 2 certification. The project manager will liaise with the audit team to get the project framework in acquiring a SOC 1 & 2 certification. 

 For study purposes;You can start your conversation or email like this:

I am the cybersecurity compliance analyst. The essence is to understand the timeline and the expectation from me and you with regards to SOC

Questions:

What should be done on our side.

Scope and purpose:

1. Can you provide a detailed explanation of the scope and purpose of the 13 SOC list you sent us? 

2. Are we getting more SOC list? How will the information be exchanged.

Controls:

3. Could you specify the exact controls and criteria we need to implement and document for each SOC list.

4. How often should we plan for progress review meetings to ensure we are on track.

AUDIT EVIDENCE -SOC 2

  When it Comes to a SOC 2 Report

In terms of common audit evidence, there are three categories:

1. Governance and Risk Management

This includes evidence such as:

• An organizational chart
• Policies and procedures
• Leadership meetings to govern the organization (e.g., information risk council)
• Risk assessment and risk register
• Penetration tests and vulnerability scans, along with evidence that actions are being taken based on those results
• Incident response and business continuity policies and procedures, including tabletop exercises
• Vendor risk assessments

2. Human Resources (HR)

Many do not realize that SOC 2 includes HR controls. HR will need to provide:

• Employee roster
• Documentation for employee onboarding and offboarding
• New hire checklist compliance
• Onboarding processes, including background checks and performance reviews
• Employee handbook
• Evidence of security awareness training

3. Technical Controls

This includes evidence such as:

• IT asset inventory
• Network and data flow diagrams
• Access lists for networks, key systems, and cloud environments
• Configuration settings for hardware, laptops, and password policies
• Multifactor authentication status
• Endpoint protection measures (e.g., antivirus software on laptops)
• System development life cycle documentation (e.g., change tickets, QA and testing evidence)
• Monitoring and alert configurations
• Backup procedures for system recovery

Audit Workflow

The majority of your audit will involve providing audit evidence to the auditor, reviewing that evidence, and engaging in a cycle of acceptance or rejection. Here's a typical workflow between you and the auditor:

1. Information Request: The auditor will send you a SOC 2 request list, detailing nearly 100 different requests.
2. Gather Evidence: You will interpret these requests, gather screenshots of configuration settings, download access lists, and retrieve policies.
3. Upload Evidence: Typically, you will upload these documents to a cloud repository like ShareFile or OneDrive.
4. Review and Feedback: The auditor will review each file and determine whether to accept or reject the evidence. If accepted, you move forward. If rejected, you will receive an email detailing additional information needed.

Common Challenges

• File Naming: Ensure files are named accurately to avoid confusion.
• Feedback Visibility: Lack of visibility into whether the auditor has reviewed your evidence can be frustrating.
• Coordination: Coordinating with stakeholders (e.g., engineers) to gather necessary evidence can be complex.

Best Practices

1. Ask Your Auditor: Clarify how information will be exchanged.
2. Request Process: Understand the process for requesting evidence.
3. Feedback Process: Ensure you know how feedback will be provided and what constitutes acceptable evidence.

*************

How Auditor conduct the Audit SOC2 .

 So when it comes to thinking through how the auditor is actually going to conduct the audit, there's really only three types of audit techniques that we use to assess your organization.

1. Those are walkthroughs, 

2. Inspection of evidence and 

3. Observation of processes.

So that's literally the terminology that they use to describe what they're doing.

So I'll walk through those so you can you'll know how that applies to our organization.

So first walkthroughs are simply meetings with IT and talk about how the network is designed. Our network diagram and talk about data flow. They'll schedule a meeting with the engineering team and talk through product overviews, change control, SDLC.

These are literally interviews with the people on our team to understand how processes work and they'll hear directly from our team members.

However, an auditor is not permitted to rely exclusively on walkthroughs to perform an audit.

So SOC 2 requires that you look at evidence to also validate anything that someone said, which is our second process, an audit reuse.

And this is the most common process that an auditor will use to audit.

And there's a whole ecosystem of;

So if you've never been through an audit, what basically happens is the SOC 2 auditor will provide you a whole request list of type of information they need. Just like for SOC 2, there's usually at least 100 line items that'll include things like policies, configuration settings, system access lists, change tickets.

Then our team is going to go start grabbing screenshots, You're going to pull down the policy and you're going to upload it to the auditor's portal and the auditors will review all the evidence.

And then based on their review, they're probably going to come back with questions or want some clarification, or they may even have additional requests that they need to make to get through the audit.

So that's the most robust and time consuming piece of the audit, is that inspection of evidence part.

The third way an auditor will audit our organization is through observation. If you have an on prem data center or server closet, they might want to look at that data center to make sure it has physical and environmental controls there.

If you have a facility, they might inspect the locks on each door to make sure they're actually physically locked.

WHAT AUDITORS WRITE DOWN:

This is what the auditor is writing down. So for a SOC 2, you're going to have controls. You might have 50 or 100 controls.

So our example control here ;Is our company maintaining security policies and procedures. Policies and procedures are made available to employees and the company's policy document repository.

So then how will the auditor review that?

What will they do to test that control?

So there's two test procedures.

The auditor will inspect the company's security policies and procedures to determine if policies are documented and up to date. So they inspected the policy.

The second thing they do is inspect the company's policy document repository to determine if policies and procedures are made available to the employees and the company's policy document repository.

So to to audit test. They looked at the policy and they read it.

Then they made sure that that policy was actually available to all the employees. Through the document repository, like the control said, the thing that's going to impact you is the evidence that they're requesting to validate that.

So the two pieces of evidence that an auditor would request to validate this control is one, the information

security policy, and two, they're probably going to ask for screenshots of your document repository to validate that you actually have a document repository and the whole company has access to it.

So that's how one control might have two different evidence requests.

And if you have 50 or 100 controls, you can see how that might be 100 or 200 pieces of evidence.

So I hope that adds some clarity to what the auditor is actually doing and how they're testing us.

"In Scope" for SOC 2 Reports

Understanding "In Scope" for SOC 2 Reports

Detailed Explanation

When something is considered "in scope" for a SOC 2 audit, it means that it will be reviewed and scrutinized during the audit process. These elements are assessed to ensure they meet the Trust Services Criteria and demonstrate the organization's commitment to security, availability, confidentiality, processing integrity, and privacy.

This includes various aspects of our organization operations, technology, and processes that are relevant to the criteria being evaluated.

Trust Services Criteria in Scope

Each of the five Trust Services Criteria can be in scope depending on what is relevant to our organization and the needs of our customers:

1. Security: Always in scope as it is mandatory. It covers measures to protect the system against unauthorized access and breaches.
2. Availability: In scope if the reliability and uptime of your system are important to your customers. It involves disaster recovery and business continuity planning.
3. Confidentiality: In scope if protecting sensitive information is critical. It ensures that data is only accessible to authorized personnel.
4. Processing Integrity: In scope if our system processes transactions or data that must be accurate and complete. It ensures that processes are functioning correctly and producing accurate results.
5. Privacy: In scope if personal information is managed and needs to comply with privacy regulations. It involves the policies and procedures for handling personal data.

Systems and Components in Scope

Various systems and components of your organization can be in scope for a SOC 2 audit. 

1. Primary Application/Product/Service: The main system or service you provide to your customers. For example, if you offer a SaaS application, this application will be in scope.
2. Supporting People and Processes: The employees and processes that support the operation and security of the primary system. This could include customer support teams, IT personnel, and operational workflows.
3. Physical Locations: Any physical offices or data centers where your operations are conducted. These locations will be assessed for physical security and operational controls.
4. Technology Stack: The infrastructure and software tools that support your primary system. This includes our corporate network, cloud infrastructure, databases, and any tools used for development and change management (e.g., Jira).
5. Supporting Corporate Systems: Other systems that indirectly support the primary system, such as your email system, HR systems, and legal or contract management systems.

Why "In Scope" Matters

Determining what is in scope is crucial for several reasons:

1. Relevance: Ensures that the audit focuses on the areas that are most important to your customers and stakeholders.
2. Compliance: Helps ensure that all relevant parts of your system comply with the Trust Services Criteria.
3. Transparency: Provides a clear and comprehensive view of your organization’s controls and processes to the auditors.
4. Cost and Effort: Affects the complexity and cost of the audit. More in-scope elements mean more requirements, evidence, and audit steps.

Practical Steps to Determine Scope

1. Identify Key Systems and Processes: Determine which systems and processes are critical to your service and your customers.
2. Engage Stakeholders: Discuss with internal stakeholders and customers to understand their expectations and requirements.
3. Collaborate with Auditors: Engage your auditors early to get their input on what should be in scope based on their experience and expertise.
4. Evaluate Impact: Consider the impact of including additional criteria and systems in scope on the cost and complexity of the audit.
5. Document Scope: Clearly document what is in scope for your SOC 2 audit to ensure alignment and understanding across your organization.

This report provides a comprehensive overview of what "in scope" means for SOC 2 audits and outlines the importance and practical steps to determine the scope effectively.

SOC 2- Scoping Report Overview

   When it comes to scoping a SOC 2 report, there are two primary considerations:

1. The Trust Services Criteria.
2. The system in scope that is being audited.

Trust Services Criteria

The SOC 2 audit evaluates your system against the Trust Services Criteria, which includes one mandatory criterion and four optional ones.

1. Security (Common Criteria): This is mandatory for every SOC 2 audit. Security involves ensuring that your system is protected against unauthorized access, both physical and logical.

2. Availability: This criterion examines whether your system is available for operation and use as committed or agreed upon. It covers uptime, disaster recovery, and continuity planning.

3. Confidentiality: This criterion evaluates how your system protects confidential information, ensuring that data is only accessible to those who are authorized.

4. Processing Integrity: This examines if your system achieves its purpose accurately, completely, and in a timely manner. For instance, if your application processes financial transactions, it ensures the integrity of these processes.

5. Privacy: This criterion evaluates how personal information is collected, used, retained, disclosed, and disposed of in conformity with your privacy notice and criteria set forth by the American Institute of Certified Public Accountants (AICPA).

Selecting Trust Services Criteria

Choosing which of the Trust Services Criteria to include in your SOC 2 audit depends on the needs of your report's readers:

• Security is mandatory and relevant to all readers.
• Availability, Confidentiality, Processing Integrity, and Privacy should be considered based on what is most relevant to your application, product, and services, and what your customers expect to see.

Consulting with your auditor can help determine which criteria are most applicable. Note that including more criteria can increase the cost and complexity of the audit due to additional requirements and evidence.

System in Scope

Determining the system in scope for your SOC 2 report is flexible but must be relevant to your readers. Key elements to consider include:

• Application/Product/Service: The primary system that your customers use should be in scope. For SaaS providers, this would be the SaaS application.
• Supporting People and Processes: Include all personnel and processes that support the primary system.
• Locations: If you have physical offices or data centers, these may also need to be in scope.
• Technology Stack: Include all technologies that support the primary system, such as your corporate network, cloud infrastructure, and tools like Jira for change management.
• Supporting Corporate Systems: Systems that support your primary system, like your corporate network, email, HR, and legal or contract management systems, should also be in scope.

Summary

When scoping your SOC 2 report, ensure that the criteria and systems included are relevant and applicable to your customers, internal stakeholders, and the readers of your report. Flexibility is available, but alignment with customer expectations and internal relevance is crucial for a successful audit.

By following these guidelines, you can effectively scope your SOC 2 report to meet the necessary requirements and provide valuable assurance to your stakeholders.

Classifications of CEH Attack

Important Attack Classifications to Be Aware Of:

Passive Attacks:

• Objective: Malicious actors gather information by inspecting network traffic.
• Methods: Packet sniffing, network traffic analysis, decryption.
• Characteristics:
  • Hard to detect.
  • Involves collecting clear-text passwords and other sensitive information.
  • Comparable to passive-aggressive behavior: subtle and not raising red flags.

Examples:

• Packet Sniffing: Capturing data packets as they travel through a network.
• Network Traffic Analysis: Examining the flow of data to gather information.
• Decryption: Breaking encrypted data to access sensitive information.

Analogy:

• Imagine a stalker observing you from a distance, noting down your routines and systems without direct interaction. They gather information such as business hours, system types, and operating systems, all without raising any alarms.

Technical Methods:

• Network Sniffing and Traffic Analysis: Tools like Wireshark can be used to monitor network traffic. This can reveal clear-text passwords, names, dates, systems, IP addresses, and other sensitive data.
• WiFi Decryption: Weak WiFi passwords can be cracked, allowing access to systems and data undetected.

Lets do abit of hands-on. Go to your browser and search  "Grayhatwarfare":

• Public buckets in cloud technology, like AWS S3, can be scanned passively. This means attackers don't need to interact with the systems directly but can search for keywords or file extensions to find sensitive information. This method can reveal AWS keys or other critical data stored in public buckets. 

For example:

if I'm looking for keywords, give me a keyword. Like? Key and search. 

"Key".

As a free user, you should see 2,468 from the 8,200  Million, that's million files. In the index, and you can look down here and scroll. You can click on these EXTENSION. So there is tech key, this is a PNG.That's where the file extension thing would come in handy.

If that was your target, I could look for, obviously the premium edition is gonna allow you to target a whole lot easier as we hve kind of seen in there. The buckets are public, you're not breaking anything.

I like that because it just keeps us moving in and talking about things that are relevant to this and that is a very relevant thing, that this is a great way to gain passive information about your targets, like their AWS keys or other sensitive information that's in an AWS S3 bucket. Because that never happens, no one ever puts sensitive information in a public bucket.

These classifications and examples highlight the various motives behind cyber attacks and the subtle yet effective methods used to gather information and disrupt operations.

ATTACKERS MOTIVES

 COMMON REASONS: 

Why are they attacking companies:

 1.    Curiosity (fun facts) : They started interesting with a-bit of research and grew into it. Another one. Will be someone praising you for doing something unique, "bragging rights". Some people want to get attention either good or bad. 

2.    Denial of service: Disrupting biz. For example, disrupting your competitors from making wave.The hacker goal will be slow down your business. 

3.    Hacktivists: They don't like you, they think you're wrong, s they hack for a cause. 

4.    Political: This will be more like nation hacking another country's government. (fighting each other).

5.    Cyber-terrorist: The worst of the worst. They go after physical infrastructure, power, people, water to hurt people. As scary as it sounds, that's the world we live in.

 

6.    Cybercrime: Using cyber mechanisms to make money. This is the largest motivator for bad hackers to do what they have to do.