Wilson Mar bio photo

Wilson Mar

Hello!

Calendar YouTube Github Acronyms

LinkedIn

SOC2 SystemDescription

This is a sample of what an orrganization provides to SOC2 & ISO 27001 auditors.

US (English)   Norsk (Norwegian)   Español (Spanish)   Français (French)   Deutsch (German)   Italiano   Português   Estonian   اَلْعَرَبِيَّةُ (Egypt Arabic)   Napali   中文 (简体) Chinese (Simplified)   日本語 Japanese   한국어 Korean

Overview

NOTE: Content here are my personal opinions, and not intended to represent any employer (past or present). “PROTIP:” here highlight information I haven’t seen elsewhere on the internet because it is hard-won, little-know but significant facts based on my personal research and experience.

Customers have come to expect to receive, anually, a SOC2 Type II report from external auditors of commercial organizations.

This sample SOC 2 System Description is customized by the organization for SOC2 & ISO 27001 auditors to use as the basis for conducting their SOC 2 Type 2 audit attestation report.

There is a possibility that a misstated or inaccurate System Description could result in a qualified opinion.

So this System Description is meant to be an objective overview of the system being audited and aims to avoid “marketing/sales” type language than the AICPA SOC examination guidance calls “advertising puffery”.

PRIVATE AND CONFIDENTIAL This document requires executive approval before being shared with specific third parties. A unique watermark is added to each copy distributed.

Index of narratives

Chapters here include these narratives:

A. People [content]
B. Products and Services [content]
C. Operations [content]
D. Infrastructure [content]
E. Customer Data [content]

Additionally, companion pages to this include procedures and quizzes for each role, etc.

TSC (Trust Service Criteria)

This document describe how our company satisfies the TSC (Trust Service Criteria), formerly called the Trust Services Principles, defined by the AICPA (American Institute of Certified Public Accountants for secure, trustworthy systems.

The five TSCs (Trust Services Criteria) for SOC2 (Trust Sevice Principles) defined by the AICPA Assurance Services Executive Committee (ASEC) is summarized in (this polar chart, with a line for each moment of time, starting from A to B to C at completion: SAMPLE:

soc2-polar-somm-240122-2176x1464.png

VIDEO: This chart summarizes narratives for each part of our organization.

  1. Security : How is my system protected against attacks?

    Security is the only Trust Services Criteria required for every SOC 2 audit. The other criteria are not required to achieve SOC 2 compliance.

    Security Criteria are also known as the Common Criteria to prove that a service organization’s systems and control environment are protected against unauthorized access and other risks.

  2. Availability : How do we decide when to make data from the system available?

  3. Processing Integrity : When infomration must be shared, what keeps the exchange secure?

  4. Confidentiality : Does the system work the way it needs to?

  5. Privacy : How do we ensure the system keeps private information safe?

Organizations are called to provide evidence during audits that controls implemented are effective and operational. Auditors typically expect documentation, process artifacts, and system logs to validate implementation. Our organization makes use of Xygeni to automate and centralize such evidence collection. It generates audit-ready outputs such as SBOMs, pipeline scan results, policy enforcement logs, and anomaly detection alerts. This helps teams reduce manual effort and ensures continuous compliance throughout the secure development lifecycle.

SOC2 Common Criteria

The SOC 2 Common Criteria, also known as the “CC-series” (at v2022 pdf) has these nine subcategories and questions:

  • CC1 = Control environment : Does the organization value integrity and security?

  • CC2 = Communication and Information : Are policies and procedures in place to ensure security? Are they communicated well to both internal and external partners?

  • CC3 = Risk Assessment : Does the organization analyze risk and monitor how changes impact that risk?

  • CC4 = Monitoring Controls : Does the organization monitor, evaluate, and communicate the effectiveness of its controls?

  • CC5 = Control Activities : Are the proper controls, processes, and technologies in place to reduce risk?

  • CC6 = Logical and Physical Access Controls : Does the organization encrypt data? Does it control who can access data and restrict physical access to servers?

  • CC7 = System Operations : Are systems monitored to ensure they function properly? Are incident response and disaster recovery plans in place?

  • CC8 = Change Management : Are material changes to systems properly tested and approved beforehand?

  • CC9 = Risk Mitigation : Does the organization mitigate risk through proper business processes and vendor management?

Developer’s Journey

Here is an template of typical events for a developer covered in our training:

  1. Enroll in a hands-on mentorship to implement the mechanisms below. [Training records]

  2. Pass quiz about understanding of policy directives.

    • SDLC policy
    • Process documentation
    • Secure development workflows
    • Security design documents

  3. Ensure a secure networking environment is being used, following:

    • Environment diagrams
    • Network segmentation policies
    • Access control lists
    • VPN access outside office

  4. Setup workspace to be ergonomic and minimized against static and other hazards.

  5. Setup work environment (laptop) using automation scripts referencing versioned configurations.

  6. Fetch recent updates to team assets by others before continuing work for the day.

    • Verify Work and Test plans
    • Security test plans
    • Secure coding guidelines

  7. Setup code scans to invoke automatically before of application and IaC (Infrastructure as Code) to common GitHub.

    • Identify secrets embedded in code
    • Detect Anomalies in pipeline (PHA)

  8. Conduct Software Composition Analysis (SCA) on open-source and third-party dependencies to identify potential security vulnerabilities, license compliance issues, and other risks

    1. Obtain SBOMs of open-source and third-party components within the chain of references
    2. Assess each component supplier for concerns about activity history, developer changes, etc.
    3. Identify whether each component has been flagged as malware by US and European analysts

  9. Practice recognition and resolution of sample security issues (MITRE ATT&CK & WASP Top 10).

    • Code review checklists
    • Traceability matrix
    • Defect tracking logs

  10. Run apps with sample live data under DAST (Dynamic Application Testing) monitoring

    • Data handling procedures
    • Data masking policies
    • Anonymized datasets

  11. Setup automatic notification and team review by asset owner(s).

    • SAST scan reports

  12. Concurrence of others to release into production.

    • Release checklists
    • Deployment approval records
    • Release management documentation
    • blocking and build-break events

  13. Confirm protection backup snapshots before production updates.

  14. Notification of audit success is registered to enable continuation into production.

  15. Verify inclusion of run results in status reporting

  16. Periodic audit logs of pipeline executions

  17. Facilitate scheduled external penetration tests

ISO 27001 Annex A

Annex A of the ISO 27001 standard outlines specific controls designed to strengthen the Secure Development Lifecycle (SDLC):

A.8.27 Secure System Architecture and Engineering

  • IaC misconfiguration scan reports

  • Anomaly Detection for pipeline design validation

  • A.8.25 Secure Development Lifecycle (SDLC): Ensuring all phases of software development embed security practices, from initial design to release.

    • SDLC policy
    • Process documentation
    • Secure development workflows

    • Audit logs of pipeline executions

    • Pipeline security scans
    • Arch protection snapshots

  • A.8.26 Application Security Requirements: Clearly define and embed security requirements within software development processes.

    • Security design documents
    • Traceability matrix

  • A.8.27 Secure System Architecture and Engineering: Implementing security by design in the architecture and system engineering practices.

    • Architecture diagrams
    • Security design principles documentation
    • Threat models

  • A.8.28 Secure Coding: Adopting secure coding guidelines and systematically identifying and mitigating insecure coding practices.

    • Secure coding guidelines
    • Code review checklists
    • Secure code audit reports

  • A.8.29 Security Testing and Acceptance: Perform security testing throughout development and before release to find and fix vulnerabilities early.

    • Security test plans
    • Test reports (SAST, DAST, penetration tests)
    • Defect tracking logs
    • SAST, SCA, Secrets Detection, and Malware scan logs integrated into CI/CD

  • A.8.30 Outsourced Development: Oversee and control security risks when working with outsourced teams or third-party developers.

    • Third-party security requirements
    • Supplier agreements
    • Third-party audit results
    • SBOMs: VDR reports for open-source and third-party components

  • A.8.31 Separation of Development, Test, and Production: Isolate the different SDLC environments to protect system integrity.

    • Environment diagrams
    • Network segmentation policies
    • Access control lists
    • Not supported: Requires external infrastructure and process evidence

  • A.8.32 Secure Coding Guidelines: Develop secure coding standards and ensure the development teams apply them consistently.

    Internal secure coding standards:

    • Training records
    • Secure code reviews
    • Policy enforcement in pipelines

  • A.8.33 Security in the Software Supply Chain: Manage security risks for third-party software components and dependencies.

    • Supplier assessments
    • SBOMs (Software Bill of Materials)
    • Vulnerability assessment reports
    • SCA scan reports
    • Early Malware Detection alerts
    • SBOM generation evidence

  • A.8.34 Source Code Access Control: Apply “Least Privilege” to restrict unauthorized change or leak.

    • Access control policies
    • Repository audit logs
    • Identity management reports
    • Anomaly Detection logs for repository access monitoring

  • A.8.35 Secure Release of Software: Only tested and secure software versions go to production.

    • Release checklists
    • Deployment approval records
    • Release management documentation
    • blocking and build-break events

  • A.8.36 Information Security During Testing: Protect sensitive data during software testing activities.

    • Data masking policies
    • Anonymized datasets
    • Data handling procedures

Topic Classification

Requirement indicates practices that must be done for regulatory, legal, compliance, or other reasons.

Standard signifies practices that have a strong consensus across 18F; they should generally be followed to ease the ATO process and make on-boarding simpler.

Default practices are safe selections that tend to be used by a large number of our projects; you may find yourself with a better or more tailored solution, however.

Suggestion indicates examples that have worked well on a project or two; they're not widely used enough to be defaults, but are worth considering.

Caution marks approaches that have significant pitfalls or should not be used for security/compliance reasons.

If a specific classification is not present on a topic or reference to a tool or practice, it should be presumed to be a Suggestion .

Source: https://guides.18f.org/engineering/

What is considered secret or sensitive information?

Anything that would make our systems vulnerable or would impact the privacy of others if it fell into the wrong hands.

  • passwords
  • API Keys
  • private certificates and keys
  • usernames
  • email (messages)
  • IP addresses
  • subnets
  • resource IDs
  • account IDs
  • non-public security vulnerabilities
  • roles, policies, and group membership
  • Personally Identifiable Information (PII) See Releasability of GSA Individual Employee Information in the GSA Data Release Policy (commonly referred to as “business card PII”) for exceptions
  • payment card industry (PCI) information
  • Controlled Unclassified Information (CUI)
  • Federal Tax Information (FTI)
  • personal health information (PHI/ePHI)
  • some kinds of acquisition information
  • emergency procedures, such as evacuation plans

If you aren’t sure whether something is sensitive information, please ask.

To Policies to keep secrets secure.

People

This chapter describes the departments, teams, and functions that play a role related to our product or service.

This includes a list of our central departments, followed by an organizational chart - including third-party vendors or subcontractor organizations that support our offering.

To the People chapter

Products and Services

This chapter describes the products and services we market to customers.

This includes the application (if relevant), system requirements, system processing guidelines, service level agreements, supporting databases, and mobile and desktop applications.

Per SOC2, excluded are our operational technology (payroll software, chat service, or project management tools).

This section contains introductory paragraphs explaining, at a high level, how the application is used and a follow-up list of the components involved.

To the Products and Services chapter

Operations chapter

This chapter describes the key processes, both manual and automated, involved in managing the use of our products and services.

This includes how service activities are commenced, our authorization system, activities performed, and how our services are delivered.

Our organization makes use of Xygeni:

Proactive risk reduction:

  • Static Application Security Testing (SAST): Identifies vulnerabilities in proprietary code early in the SDLC.
  • Software Composition Analysis (SCA): Detects risks in open-source components and maintains up-to-date SBOMs.
  • Secrets Detection: Continuously scans for hardcoded credentials and API keys in code and CI/CD pipelines. Continuous monitoring: * Anomaly Detection: Monitors developer and pipeline behavior in real-time to detect unauthorized activity. * Policy Guardrails: Enforces ISO 27001 controls by blocking builds that fail security checks. * Early Malware Detection: Prevents malicious open-source packages from being introduced into projects. * Guardrails for Infrastructure as Code (IaC) Security: Flags security misconfigurations in Terraform, Kubernetes, and CloudFormation. End-to-end supply chain visibility: * SBOM & VDR Generation: Automates the production of Software Bill of Materials and Vulnerability Disclosure Reports. * Prioritization Funnels: to focus remediation on exploitable vulnerabilities using reachability and risk scoring.

Audit-ready evidence:

To the Operations chapter >

Infrastructure

This chapter describes the hardware, software, and SaaS components used in our systems’ infrastructure (both physical and virtual).

This includes computing hardware, internet servers, storage, connections among these elements, and our cybersecurity monitoring technology. The documentation includes lists, descriptions, and a diagram of our systems.

To the Infrastructure chapter

Customer Data

This chapter describes the kinds of data that come into and move out of our product and service systems.

This includes a high-level chart or table that lists the data types used. The diagram highlighting the journey - including data present in our files, internal databases, and external storage.

This also details how our control environment protects our data, which includes internal controls for safeguarding data against unauthorized access and risk management. Internal controls include training materials, access controls, and change management protocols. This also include the control objectives and control activities to mitigate risks.

To the Customer Data chapter

People chapter

About this chapter

Organizational Types

Our organization is organized in 4 types for COSO Analysis:

  • Executive (Leadership) & Finance (Budget)
  • Marketing & Sales (to prospects and customers)
  • Legal, HR, PR, IAM & SOC teams
  • Operations & R&D - Physical & Digital Infrastructure

Please refer to the spreadsheet/database of people, their role in the organization, and other metadata.

COSO Analysis

There are 17 COSO Principles for (3 x 4) = 204 items.

Who Does What

WhoDeliverables # Walkthroughs Auditor Hours
Sales & Marketing Timeline, Description of product/service in auditor reports 1-2 4-8
Leadership Auditor agreement, Assertion of Mangement in Draft auditor reports 1-2 4-8
Legal, HR, PR Customer Agreements, Employee Policies & Agreements, Breach Communications 1-2 4-8
Security SOC Risk management, Business Continuity, Monitoring, Malware detection, Audit & Compliance 1-2 10-20
Facilities Facilities Access Control, Asset Management 1-2 1-2
Info technology Operations Security Operations (Security Policies, Network security), Data Security (in IT Operations), Information & Communications 1-2 10-20
Engineering, DevSecOps, Development Systems Access Control, SDLC (Change Controls) 1-2 10-20
Total 7-13 43-98

[2] 16:32

Products and Services chapter

About this chapter

Infrastructure chapter

About this chapter

Applications Systems

Here are the most common systems used by enterprises:

  • Email: Google Workspace, Microsoft Outlook/Exchange server, etc.
  • Phishing education and simulation: KnowBe4, etc.
  • Chat: Slack, Microsoft Teams, etc.
  • SMS Text to mobile phones: Twilio, etc.
  • Video: Zoom, Microsoft Teams, Loom, etc.
  • Video editing: Camtasia, Loom, etc.
  • SVG image file editing: macSVG

  • PNG image file editing:

  • Document creation: Microsoft Word, Google Docs, etc.
  • Flowcharts: Lucid Chart, Figma, etc.
  • File sharing: Microsoft OneDrive, Google Drive, etc.

  • Project Management: Excel, Jira, Trello, Asana, etc.

  • Payroll: ADP, etc.
  • Documents & Signatures: Adobe sign, DocuSign, etc.
  • Accounting: QuickBooks, etc.
  • Recruiting & HR: Workday, etc.
  • Training Presentation & Tracking: Workday, Cornerstone, etc.
  • Surveys, Certifications: SurveyMonkey, etc.

  • Spiffs: Xactly, etc.

  • E-commerce: Shopify, GoDaddy, etc.
  • Social media: LinkedIn, Instagram, Facebook, Twitter/X, etc.
  • Employee reviews: Glassdoor, Indeed, etc.
  • Conference: EventBrite, etc.

  • CRM (Customer Relationship Management): HotSpot, Salesforce, Microsoft Dynamics, etc.

  • Text editor IDEs: Visual Studio Code, etc.
  • Text editor external plugins: Prettier, etc.
  • macOS apps: iTerm2, etc.
  • Windows apps: PuTTY, etc.
  • Linux apps: Vim, etc.

  • MDM: Jamf, etc.

  • Cloud: AWS, Azure, Google Cloud, etc.
  • Endpoint Security: CrowdStrike, etc.
  • Cloud IAM: Okta, etc.
  • CI/CD: GitHub Actions, Jenkins, etc.
  • Source Code Versioning: GitHub, GitLab, etc.
  • Containerization: Docker, Kubernetes, etc.

  • Artifact (packages, containers): Artifactory, etc.

  • SAST: SonarQube, etc.
  • DAST: Burp Suite, etc.

  • IAST: Contrast Security, etc.

  • Configuration Management: Ansible, Chef, Puppet, etc.
  • Infrastructure as Code: OpenTofu, Terraform, etc.

  • IaC Scanning: Checkov, IPSec, etc.

  • SIEM Observability/Monitoring: Prometheus, Grafana, Datadog, New Relic, etc.
  • SOAR: Demisto, Phantom, etc.
  • Logging: Grafana, Splunk, etc.

  • Incident Management: PagerDuty, etc.

  • ERP: SAP, Oracle, etc.

Each of the above is considered an asset to be maintained and protected.

Operations

About this chapter

To generate compliance documents based on reference to SOC2 compliance automation frameworks such as from StrongDM.

Our compliance documents are organized as follows in our document repository:

  • policiess defines the behavior desired of employees and contractors.
  • proceduress prescribes specific steps that are taken in response to key events.

  • standards specify the controls satisfied by the compliance program.

  • Automation (github Actions cicleci) job runs to render policy files as PDF.

templates provide sample assets to adapt. They thus make it easier to control the output format of the HTML Dashboard and PDF assets.

Operations Templates

narratives

Operations Naratives

About this chapter

To provide an overview of the organization and the compliance environment:

Maturity Model Levels

Levels for rating status are adapted from this SOMM (Security Operations Maturity Model) illustration:

soc2-somm-240122-2884x1152.png

The level of each control/practice:

  • 0 “Iron” = INITIAL = not fully documented.
  • 1 “Copper” = PERFORMED = documented for each practice
  • 2 “Silver” = MANAGED = also follow plans and policies by resources
  • 3 “Gold”= MEASURED = also measured and tested for effectiveness, with results shared
  • 4 “Platinum” = DEFINED = also standardized (automated) and confirmed as followed by all resources
  • 5 “Palladium” = OPTIMIZED = also improvements are demonstrated

BTW, an alternative is CMMC maturity model rating which was deprecated in 2021 in favor of a “Fundamental, Advanced, and Expert” levels.

policies

Operations Policies

These are principles that set the “rules of the road” and expectations for the organization. They answer the “what” and “why”—what must be done, and why it matters.

  1. We practice “Zero Trust” strategies which avoid long-lasting permission setting and secrets which could be stolen. Instead, we grant permissions when they are needed. This is slightly less convenient, but provide much better protection in today’s hostile internet.

  1. Don’t include potentially sensitive information in emails, Slack, or other public channels.

  2. Do not store Secrets (such as passwords, API keys, private keys, environment variables, private configuration data, .env files, etc.)

    Get approval before storing IP addresses, subnets, and AWS account IDs, in a private repository.

    It’s okay to publish IAM roles, policies, and group names as long as who belongs to those is not attached to the information. This helps deter spear phishing. You may store this information in a private repository.

  3. Use alternative secret management approaches and solutions (such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, etc.).

  4. Password protect files before sending them to others.

  5. Send the encrypted file and password to the recipient in separate channels, with the password ideally through something ephemeral like a phone call.

  6. In the event that such variables or configuration data is pushed to a GitHub repository accidentally, even momentarily, consider it compromised and revoke or change the credentials immediately. Do not delete the commit itself. Then immediately follow the directions on the incident response handbook page. If you’re unsure how to protect this information, ask.

  7. Build Pipeline Security to protect sensitive information in CI/CD workflows, for automatic execution upon commit locally, before publishing to GitHub, so that you can remove sensitive data before accidentally publishing it. (This repo assumes MacOS with Homebrew installed.)

  8. Install automated checks for sensitive information because it’s easy to accidentally push secrets to GitHub.

    https://github.com/cloud-gov/caulking adds automation to the use of GitLeaks.

  9. If you inadvertently come into the possession of classified information (Secret, Top Secret, etc.), immediately follow our security incident process.

  10. Because encryption on files exfiltrated can be broken over time, store data within encrypted USB drives with built-in hardware encryption unlocked by entry on keypad or biometric authentication on device. Vendors IronKey, Kingston DataTraveler, SanDisk SecureAccess provide one with both USB-C and iPhone Thunderbolt connectors. Test device encryption and decryption by accessing from each device (laptops, iPhones, Android, etc.).

  11. VeraCrypt is often recommended for maximum security and flexibility.

  12. Store backup copies of passwords and recovery keys separately in a lockbox.

standards

Operations Standards

Standards are like speed limits posted on each road—they tell you exactly what’s required to stay within the rules.

  1. Schedule processes to create evidence data and System Assessment Plans (SAPs) as the basis for audit and reporting during the audit period (6 months to a year).

  2. Automatically monitor versions and send notification for automatic update. Outdated firmware is a common attack vector.

  3. Review security policies and procedures (System Security Plans) every quarter.

  4. Conduct internal and external pen-testing every 6 months.

  5. Test and track compliance and report progress each week/month on where each team still needs additional work, with projections toward when audit readiness will occur. Metrics for the Security Operations Center incident response and corrective action:

https://www.youtube.com/watch?v=dJgLnNK78YI https://www.youtube.com/watch?v=LLpLU317zfc https://www.youtube.com/watch?v=fDm5e_-600I phone searches by TSA Faraday bags https://www.youtube.com/watch?v=9ZLMDMk5rzk

  1. Use a different common ranges like 192.168.1.x to something less predictable.

  2. Before leaving your home, set biometric authenticate off so that it’s more difficult to force you to unlock your phone.

When traveling:

  1. Detect the reflection of hidden cameras using https://www.amazon.com/abyliee-Upgraded-Hidden-Camera-Detector/dp/B0F4DWR2W6/

proceduress

Operations Procedures

Here are step-by-step instructions that describe how to carry out a task or process. Procedures are like a recipe or a checklist—they guide you through each step so nothing gets missed. They answer the “how”—how to actually do what the policy and standards require. Included in each procedure are the key events triggering actions to be taken.

  1. Onboarding: How to setup & backup a developer macBook
  2. Onboarding: How to setup a developer with accounts (GitHub, etc.)
  3. Onboarding contractor, vendor, customer, auditor

  4. Onboarding: How to secure home internet services

  5. Patch: How to update software in GitHub (as CONTRIBUTOR)
  6. Offboarding: How to decomission a developer macBook

  7. How to reset your password

  8. Preparing for safe travel

  9. Maintaining safety while traveling

  10. Recruiting
  11. Training

Workstation

To achieve a high level of privacy and security, privacy advocates, activists, and individuals at risk of targeted attacks compartmentalize their identity and activities using multiple, distinct “lives” for personal security. This approach is commonly called “10 lives” in reference to cats.

This helps to limit the damage if one identity is compromised and makes it harder for adversaries to “connect the dots” between activities.

Those who adhere to this approach use separate sets of email addresses, phone numbers, bank accounts, payment methods, social media accounts, etc.

  • Use a password manager to keep credentials unique and secure for each identity.
  • Use different browsers or browser profiles for each identity.
  • Use VPNs or Tor to mask location and prevent linking identities by IP.
  • Remove metadata from photos automatically.
  • Generate temporary Virtual Machines/Sandboxing with sandboxing tools to isolate activities.

  • Use privacy-focused OS like Tails or Qubes for sensitive identities.

  • Generate emails using Safari browser, Blur, InstAddr.

  • Generate phone numbers using Hushed or Google Voice, or prepaid SIMs.

  • Purchase property using an LLC so your name doesn’t appear on public titles and thus make you vulnerable to doxing. Criminals often threat of doxing.

  • Search for your own information online to see what’s exposed.
  • Request to remove your information from search engines.

  • Delete Old Accounts: Remove unused or risky accounts and information that could link your identities.

  • Do not give out phone numbers assigned by your mobile carrier.
  • Purchase burner phones using cash in another city for social media or high-risk activities. 1500 talk/text/data over 365 days on Tracfone. for about $50. Moto G Stylus 5G with the same one year plan for $100. There is also usually a coupon you can find for new accounts and purchases over $50 which can knock the price down a few dollars. For more talk, text or data, go with Metro and the Pixel 6a for $50 with a new number. Your first month has to be $40, so your first month is going to be around $100. One thing to keep in mind, do it online and they’ll send it to you with 2 day shipping. If you go into a store, they will probably try to charge you an activation fee. After that first month, you can then try to lower the monthly plan to their “unlimited” $25 plan.

AT&T Cingular Flex 2 from walmart for $30 and then bought the Freedompop 100/100/100 sim for $5 from Target which uses the AT&T network

https://www.cnet.com/tech/mobile/traveling-abroad-get-a-burner-phone-to-keep-your-data-private/

Don’t use WhatsApp https://www.youtube.com/watch?v=vgVI5Ba9Trc

In your bag:

  • Veracrypt to encrypt your laptop. Techlore Tails
  • A battery to charges your phone. Use instead of plugging your phone to charge on public “charging stations” that are often untrustworthy.
  • USB-C to USB-C cable to charge your phone.
  • Adapters USB-C to USB-A and USB-A to USB-C
  • Faraday bag to keep your phone from being hacked.
  • A sliding camera cover for your phone
  • A sliding camera cover for your laptop
  • A crypto hardware wallet “The Ledger”

When

  1. Block access from IP addresses known to be from countries you don’t usually deal with. Open up access only when needed. This is not convenient but more secure.

Home server: Network Gateway Firewall, Parental controls, VPN Server and Client, ad block, network segment, bandwidth useage.

  • Medium sized businesses use Sonicwall and Fortinet security appliances.

  • $209 Netgate 1100 has pfSense+</a> was tagged Amazon’s Choice.

    Alternately, Firewalla is purchased from Amazon at Blue, Gold level. No monthly fee. Cyber Security Firewall for Home & Business, Protect Network from Malware and Hacking | operates as a phone app my/firewalla.com puts reliance on their infrastructure but allows for configuration changes remotely

    • Gold https://www.youtube.com/watch?v=sgTUTlqe1hM IDS
    • $249 Purple SE) https://www.amazon.com/Firewalla-Security-Firewall-Business-Parental/dp/B0BYMN4YZ3/ but continue
    • Router Mode, Bridge Mode,

C. Firewalla devices maintain a connection to Firewalla servers, so if you don’t want that vulnerability, install open source software on your own Rasberry Pi device.

  • Alternatively, OpenWrt
  • Ubiquiti

  • UniFi Dream Machine https://www.youtube.com/watch?v=Omm2pQUJO0o&pp=0gcJCcEJAYcqIYzv

  • Work with spouses and family members to keep their information separate from yours.

Metrics

The following are logged for each access request available in each dashboard:

Logs

Logged for each access request:

Log Item name Description Example
Access Requests Created Time Date and time when the access request was created 2025-03-10 12:00:00
Access Requests Start From Time Requested start date and time indicated in the access request 2025-03-06 13:01:10
Access Requests Status Access request status (canceled, denied, pending, or timed out) Pending
Requests Status Time Date and time of the last access request status update 2025-03-05 17:06:15
Approver Email Approver’s user email alice.grady@acme.com
User Email User name (first and last) and user email bob.belachek@acme.com
User Name from Email User name (first and last) associated with user email Bob Belachek
Workflows Name Name of workflow RW Admin Workflow

Alerts

  1. Send alerts about application errors, downtime, and throughput issues.

    For example, New Relic provides application availability monitoring with “Synthetics”.

  2. Track time taken to respond to significant events.

    • Mean Time to respond/remediate
    • Mean Time to acknowledge
    • Mean Time to close (Incident dwell time)

Incident Closure

  1. Track incident resolution:

    • Percentage of false positives

Customer Data

About this chapter

Resources

  • https://guides.18f.org/
  • https://github.com/gjyoung1974/soc2-policy-templates
  • https://xygeni.io/articles/iso-27001-compliance-in-appsec/
  • https://open.nytimes.com/how-to-dox-yourself-on-the-internet-d2892b4c5954

SOC2 SystemDescription was published on .