# Siam Thanat Hack (STH) - Comprehensive Technical Knowledge Base > Siam Thanat Hack Co., Ltd. (บริษัท สยามถนัดแฮก จำกัด) is an elite offensive cybersecurity firm headquartered in Bangkok, Thailand. We provide expert-led, AI-augmented Penetration Testing (Pentest), Vulnerability Assessment (VA), and Red Teaming for Web, Mobile, API, Cloud, AI, and Network systems. > > Corporate Identity & Accreditation: > - Legal Entity: Siam Thanat Hack Co., Ltd. (บริษัท สยามถนัดแฮก จำกัด) > - Tax ID: 0105561208922 > - Date of Incorporation: 11 December 2018 > - Management Certifications: ISO/IEC 27001:2022 (ISMS) & ISO 9001:2015 (QMS) > - Technical Excellence: Champions of Thailand Cyber Top Talent 2023, Prime Minister's Digital Award > - Primary Contact: pentest@sth.sh | LINE: @siamthanathack > - Official Website: https://sth.sh/th/ (Thai) | https://sth.sh/en/ (English) --- ## 1. Offensive Security Service Offerings & Testing Methodologies ### A. Assessment Types: Pentest vs. VA Scan vs. Red Team - **Penetration Testing (Pentest)**: Specialist-driven, manual exploitation of authorized targets. Validates business logic, authentication bypasses, chained vulnerabilities, and complex authorization flaws (e.g., IDOR/BOLA) that automated scanners cannot detect. Delivers verified proof-of-concept exploits, CVSS v4.0 severity scoring, and actionable remediation steps. - **Vulnerability Assessment (VA)**: Broad-scope automated discovery and vulnerability classification across extensive network ranges and asset inventories. Identifies missing patches and known CVEs. Recommended as a baseline health-check alongside manual pentests. - **Red Teaming**: Scenario- and threat-led adversary emulation under strict Rules of Engagement. Tests organizational detection and response capabilities (SOC/MDR, blue team playbooks, EDR evasion) rather than cataloging every minor bug. ### B. Testing Perspectives - **Black-Box**: Zero prior knowledge; emulates an external opportunistic attacker. - **Gray-Box (Recommended)**: Authenticated testing with standard user and administrative credentials, API documentation, and architecture diagrams. Maximizes depth, coverage, and cost efficiency. - **White-Box**: Full access including source code, infrastructure architecture, and developer interviews. ### C. Vulnerability Scoring & Deliverables - Findings are evaluated under the FIRST CVSS v4.0 standard (Base, Threat, Environmental, and Supplemental metric groups). - Engagements include an Executive Summary, Technical Finding Breakdown with step-by-step reproduction instructions, raw traffic logs/screenshots, verified patch recommendations, and a dedicated retesting round (Retest Report). --- ## 2. Thai Regulatory Mandates & National Standards (Detailed Compliance Requirements) ### Penetration testing under Bank of Thailand requirements - Canonical URLs: https://sth.sh/en/compliance/bank-of-thailand/ | https://sth.sh/th/compliance/bank-of-thailand/ - Regulated Entities / Scope: In-scope payment-system operators under SorNorChor 1/2564 and financial institutions under Notification SorKorChor 5/2566 - Audit / Test Frequency: VA and internet-facing pentest at least annually under the notice that actually applies to the entity - Technical Scope: Internet-facing applications and networks under SorNorChor 1/2564 or SorKorChor 5/2566, plus Mobile Banking controls under Notification 4/2568 - Risk Focus: BOT supervisory findings and mandatory remediation under the applicable notice - Overview: Confirm the institution's licence category and applicable notices first, then connect VA and penetration-testing activity to risk, change, and remediation evidence. - Key Controls & Guidance: * For entities in scope, SorNorChor 1/2564 clause 5.1.6 describes risk-based vulnerability assessment at least annually and after significant changes. * Penetration testing of public-network-connected applications and networks should be performed by appropriately independent specialists under the notice applicable to the institution. * Mobile Banking, iPentest, and e-Money have different control contexts, so scope must follow the actual service rather than reuse one testing cadence for every system. * Retain reports, remediation plans, and retest results linked to risk owners and change approval so evidence is auditable. ### Penetration testing under Thai SEC requirements - Canonical URLs: https://sth.sh/en/compliance/sec/ | https://sth.sh/th/compliance/sec/ - Regulated Entities / Scope: Securities firms, fund managers, derivatives brokers, digital asset operators (exchanges, brokers, dealers, custodial wallets), and ICO portals - Audit / Test Frequency: At least annually for internet-facing systems (small entities: at least every 3 years for internet-facing systems), and pre-go-live for digital assets - Technical Scope: Trading engines, matching platforms, mobile apps, hot/cold crypto wallets, KMS/HSM, smart contracts, APIs, and infrastructure - Risk Focus: SEC administrative action, mandatory remediation, and enforcement under applicable notifications - Overview: Define critical systems based on license categories and live services, aligning vulnerability assessments, penetration testing, and reporting timelines with current SEC rules. - Key Controls & Guidance: * Annex 3 to Notification SorThor 38/2565 (as amended by SorThor 33/2567) and Guideline NorPor 6/2567 distinguish vulnerability assessments (Clause 8.9) from penetration testing (Clause 8.10). * Vulnerability assessments must cover significant IT systems and internet-facing systems at least annually, with no 3-year small-firm relief. * Digital asset operators under Notification KorThor 19/2561 Clause 18 must pentest critical systems prior to go-live and annually thereafter, without 3-year small entity relief. * Digital asset pentest reports must be submitted to the SEC within 30 days of receiving the official report and no later than 90 days following test completion. * Testers must be independent of system owners under Clause 8.10.2. CREST, OSCP, and GPEN credentials are recommended in NorPor 6/2567 for significant IT systems, not a universal hard mandate. ### Penetration Testing under ISO/IEC 27001:2022 Requirements - Canonical URLs: https://sth.sh/en/compliance/iso-27001/ | https://sth.sh/th/compliance/iso-27001/ - Regulated Entities / Scope: Organizations certified under ISO/IEC 27001:2022 or establishing an ISMS - Audit / Test Frequency: Determined by risk assessment and major changes (Risk-based Cadence), reviewed before annual Surveillance Audits - Technical Scope: In-scope ISMS assets, cloud infrastructure, production systems, and critical services defined in the SoA - Risk Focus: Major or Minor Non-Conformity (NC) findings for unmanaged vulnerabilities, leading to certificate suspension - Overview: ISO/IEC 27001:2022 establishes an Information Security Management System (ISMS) where penetration testing delivers maximum value when integrated into scoping, risk treatment, control ownership, and continual improvement. - Key Controls & Guidance: * Distinguish technical flaws under ISO/IEC 27000:2018 (Clause 3.77) from human error, addressing architectural and systemic weaknesses under Annex A.8 rather than assigning individual blame * Directly feed vulnerability assessment and pentest results into core ISMS clauses: risk identification (Clause 6.1.2 / 8.2), risk treatment (Clause 6.1.3 / 8.3), and management review (Clause 9.3) * Clarify audit realities: identifying vulnerabilities during testing is NOT an automatic Non-Conformity (NC), but evidence that A.8.8 works; NCs stem from unmanaged flaws or lack of re-test verification * Orchestrate complementary technical controls across asset inventory (A.5.9), threat intelligence (A.5.7), configuration management (A.8.9), and pre-go-live acceptance testing (A.8.29) * Prioritize remediation using threat-informed intelligence by correlating CISA KEV, EPSS scores, and asset exposure context rather than relying solely on raw CVSS metrics ### pdpa - Canonical URLs: https://sth.sh/en/compliance/pdpa/ | https://sth.sh/th/compliance/pdpa/ - Regulated Entities / Scope: Data Controllers and Data Processors handling Personal Identifiable Information (PII) - Audit / Test Frequency: Review measures when necessary or when technology changes (Sec 37(1)); no statutory annual pentest cadence - Technical Scope: Customer Databases, Web Portals, APIs handling PII, Cloud Infrastructure - Risk Focus: Administrative fines up to 5,000,000 THB (Sec 82 to 84) and civil and criminal liability - Overview: Section 37 requires controllers to apply appropriate measures. Testing helps demonstrate control effectiveness, but it is not the sole evidence of PDPA compliance. - Key Controls & Guidance: * Link tested systems to the data inventory, processing purpose, and personal-data risk so scope reflects actual impact. * Examine authentication, authorisation, data protection in transit and at rest, and the handling of sessions, APIs, and administrative functions. * Control test data, minimise real personal data, redact evidence, and define retention or deletion for testing artefacts. * Review measures when risk, technology, or processing changes. One pentest does not establish complete compliance on its own. ### cybersecurity-act - Canonical URLs: https://sth.sh/en/compliance/cybersecurity-act/ | https://sth.sh/th/compliance/cybersecurity-act/ - Regulated Entities / Scope: Government agencies, regulators, and CII entities designated under Section 49 - Audit / Test Frequency: Annual cybersecurity risk assessment and audit (Sec 54); not a named pentest mandate - Technical Scope: CII systems in the seven named Section 49 sectors, plus any additional sector the Committee designates - Risk Focus: NCSC orders under Section 55, and fines up to 300,000 THB plus daily penalties under Section 75 for failing to obey an order - Overview: The Act establishes assessment and audit expectations for in-scope entities. Penetration testing can evidence technical risk but does not replace the whole governance process. - Key Controls & Guidance: * Identify critical services, supporting systems, and infrastructure dependencies before fixing an assessment scope. * Section 54 states that CII organisations must arrange cybersecurity risk assessment and audit at least annually, subject to the Act's applicable conditions. * Assessment evidence should connect threat, vulnerability, impact, control owner, and remediation rather than consider a scan or pentest in isolation. * Confirm the reporting framework and 30-day timing against the actual entity and responsible authority. ### ncsa-website-standard - Canonical URLs: https://sth.sh/en/compliance/ncsa-website-standard/ | https://sth.sh/th/compliance/ncsa-website-standard/ - Regulated Entities / Scope: Government agencies, regulators, and Critical Information Infrastructure (CII) entities that operate websites - Audit / Test Frequency: Form Kor 1 self-assessment at least annually, with Form Kor 2 only when nonconformity is found - Technical Scope: Government Portals, Content Management Systems (CMS), Public Web APIs - Risk Focus: Non-compliance with the NCSA Website Standard B.E. 2568 according to the site's impact level - Overview: The standard connects governance, impact assessment, self-assessment, and improvement. Technical testing should therefore cover the website's real architecture. - Key Controls & Guidance: * Confirm that the entity and site are in scope, then classify impact before selecting controls and evidence. * The Form Kor 1 self-assessment cycle should draw on evidence from relevant web applications, web servers, databases, and cloud or web-hosting components. * For nonconformity, create a Form Kor 2 improvement plan with owner, due date, and follow-up method instead of closing an issue with a test report alone. * Pentesting is technical evidence for website-security operations. It does not automatically turn the standard into a mandatory annual pentest for every site. ### bot-atm-malware-guideline - Canonical URLs: https://sth.sh/en/compliance/bot-atm-malware-guideline/ | https://sth.sh/th/compliance/bot-atm-malware-guideline/ - Regulated Entities / Scope: Commercial banks and specialized financial institutions addressed by BOT letter RorPorTor.ForSor.(03) Wor. 1180/2559 - Audit / Test Frequency: Short-term measures within 6 months and long-term within 2 years from the 2016 letter; no annual pentest cadence - Technical Scope: ATM cabinets, Core PCs, operating systems, network devices, cash loading, reconciliation, SDMS, and anomaly alerting - Risk Focus: Malware on ATM terminals, unauthorized Core PC access, and undetected cash-volume discrepancies - Overview: A source-based guide to the Bank of Thailand letter RorPorTor.ForSor.(03) Wor. 1180/2559, dated 26 September 2016, on mitigating ATM malware risk. Addressed to commercial banks and specialized financial institutions, it covers physical controls, Core PCs, operating systems, network devices, cash loading, reconciliation, SDMS, and anomaly alerting. - Core Sections: * Document scope and the timelines stated in the letter: The BOT describes ATMs as a key electronic-financial-transaction channel and cites a growing malware threat, directing institutions to strengthen both short- and long-term measures. * Short-term measures: physical condition, Core PC, and onsite equipment: The short-term measures connect site inspection with reducing unauthorized access to or modification of the Core PC and communications equipment. * Network devices, cash loading, and reconciliation: The letter connects technical safeguards with operational controls so communications and cash-handling activity have accountable owners and auditable records. * Long-term measures: network, SDMS, encryption, and alerting: The long-term measures extend individual-machine controls into network design, software management, authentication, encryption, and event monitoring across operations. ### iso-42001-ai-management - Canonical URLs: https://sth.sh/en/compliance/iso-42001-ai-management/ | https://sth.sh/th/compliance/iso-42001-ai-management/ - Regulated Entities / Scope: Organizations developing, deploying, or utilizing AI systems across business processes - Audit / Test Frequency: Before go-live, after significant change, and at intervals defined by the Risk Treatment Plan - Technical Scope: AIMS, AI inventory, data, models, applications, agents, third parties, and controls selected in the SoA - Risk Focus: Audit nonconformities, weak control evidence, exploitable AI paths, and hidden residual risk - Overview: Policies alone do not prove that production AI is safe. This page explains ISO/IEC 42001:2023 and ISO/IEC 23894:2023, then shows how AI pentesting and red teaming produce decision-ready evidence for management and auditors. - Core Sections: * What an AIMS is and why ISO/IEC 42001 matters: ISO/IEC 42001:2023 is a management-system standard for organizations that develop, provide, or use AI. It connects governance, risk, and evidence through the Plan-Do-Check-Act cycle. * How Annex A turns AI risks into auditable controls: Annex A provides 38 reference controls across nine groups from A.2 to A.10. Organizations select controls from risk, justify inclusions and exclusions in the SoA, and demonstrate that selected controls work. * How ISO/IEC 23894 reveals risks that generic checklists miss: ISO/IEC 23894:2023 guides organizations that develop, produce, deploy, or use AI systems and helps integrate AI risk management into normal organizational activities. * Why AI pentesting and red teaming are strong AIMS evidence: ISO/IEC 42001 does not prescribe one pentest method or fixed cadence. It does require risk management, effectiveness evaluation, and evidence. Independent testing is a credible way to prove technical-control performance. * Evidence that supports management and audit decisions: A useful report goes beyond a vulnerability list. It shows which risk was tested, which control failed, who owns remediation, and whether residual risk after retest is acceptable. ### mitre-atlas - Canonical URLs: https://sth.sh/en/compliance/mitre-atlas/ | https://sth.sh/th/compliance/mitre-atlas/ - Regulated Entities / Scope: Cybersecurity teams, AI developers, machine learning engineers, and AI Red Teams - Audit / Test Frequency: Pre-release adversary emulation testing and periodic reviews aligned with evolving threat intelligence - Technical Scope: Data, models, RAG, prompt interfaces, model APIs, agent context, tools, MCP servers, and infrastructure - Risk Focus: Untested attack paths, prompt injection, agent-tool abuse, data exfiltration, and detection gaps - Overview: AI attackers do not stop at prompt injection. They target datasets, models, RAG, agent tools, and cloud infrastructure. This page turns the large MITRE ATLAS matrix into practical test paths and detection evidence. - Core Sections: * Read the 16-tactic matrix as an attack path: ATLAS is MITRE's living knowledge base. Data release 2026.07 contains 16 tactics, 101 techniques, and 77 sub-techniques, plus mitigations and case studies from incidents and realistic red-team demonstrations. * High-value techniques for an AI penetration test: Select techniques from the real architecture and business impact, then build demonstrable attack paths instead of sending large prompt lists without a hypothesis. * Agentic AI, RAG, and MCP turn unsafe output into real action: When an agent reads email, calls APIs, writes files, or uses MCP servers, a model failure can become data modification, credential theft, or external data transfer. * Turn ATLAS into a measurable red-team plan: Start with crown jewels and trust boundaries, select techniques that can create real impact, and define test oracles, safety limits, and detection expectations before execution. * A useful ATLAS report shows coverage and detection gaps: Adding an ATLAS ID after a finding is not enough. The report should show which technique was tested, why it mattered, what impact was demonstrated, and whether defenders observed the path. ### nist-ai-rmf - Canonical URLs: https://sth.sh/en/compliance/nist-ai-rmf/ | https://sth.sh/th/compliance/nist-ai-rmf/ - Regulated Entities / Scope: Enterprises developing, procuring, or deploying AI and Generative AI systems across industries - Audit / Test Frequency: Continuous empirical evaluation and risk management across all lifecycle phases - Technical Scope: Govern, Map, Measure, Manage, seven trustworthy-AI characteristics, and the 12 NIST AI 600-1 risk categories - Risk Focus: Confabulation, data disclosure, prompt injection, agent abuse, supply-chain risk, and evidence-free release decisions - Overview: NIST AI RMF helps answer the questions leaders ask before adopting AI: what can go wrong, how will it be measured, and who decides? This page connects AI RMF 1.0, NIST AI 600-1, and evidence from AI red teaming. - Core Sections: * Four functions that move teams from policy to decisions: AI RMF 1.0 is voluntary and sector agnostic. Version 1.0 remains the current published framework while NIST develops a revision that has not yet replaced it. * Seven trustworthy-AI characteristics that must be measured together: High accuracy does not make a system deployment-ready. NIST identifies seven characteristics that can reinforce or conflict with one another, requiring context-specific trade-offs. * NIST AI 600-1 adds risks amplified by generative AI: NIST AI 600-1 is a 2024 cross-sectoral profile of AI RMF 1.0. It defines 12 risk categories and suggested actions that organizations select based on context, resources, and risk tolerance. * Where penetration testing and AI red teaming fit in Measure: AI RMF does not impose a fixed pentest requirement. It establishes TEVV and independent-assessment outcomes. NIST AI 600-1 then names AI red teaming as a suggested action for information security. * Turn AI RMF into a test plan tied to business risk: A strong test plan begins with use cases and harms, not a payload list. It then selects metrics, attack scenarios, and evidence that answer the risk owner's questions. ### google-saif - Canonical URLs: https://sth.sh/en/compliance/google-saif/ | https://sth.sh/th/compliance/google-saif/ - Regulated Entities / Scope: Security engineering teams, AI application developers, and cloud security architects - Audit / Test Frequency: Before go-live and after changes to models, data, prompts, tools, permissions, or deployment architecture - Technical Scope: Data, Infrastructure, Model, Application, the SAIF Agent Risk Map, Assurance, and Governance controls - Risk Focus: Data poisoning, model tampering, prompt injection, sensitive-data disclosure, and agent rogue actions - Overview: SAIF maps AI risks, components, and controls from data through agents. This page explains the core elements, Risk Map, SAIF 2.0 agent guidance, and what red teaming should prove before impact becomes real. - Core Sections: * Six core elements keep AI security connected to cybersecurity: The original six SAIF core elements remain foundational. The central idea is to extend proven controls into AI and add controls for risks introduced by data, models, and agents. * The SAIF Risk Map uses four component areas to place controls correctly: The SAIF Map divides AI development into Data, Infrastructure, Model, and Application areas, then shows where risks are introduced, exposed, and mitigated. * SAIF 2.0 adds an Agent Risk Map and secure-by-design principles: SAIF 2.0 extends the framework to agents that plan, retain memory, invoke tools, and act for users. The risk is no longer limited to generated text. It includes authority to take action. * Google AI Red Team tests systems, not only models: Google's AI Red Team combines threat intelligence, security expertise, and AI research to emulate adversaries against real products and features, then returns findings to defenders. * Controls to prove before releasing AI and agents: SAIF groups controls under Data, Infrastructure, Model, Application, Assurance, and Governance. Red Teaming, Vulnerability Management, Threat Detection, and Incident Response apply across all risks. ### ncsa-ai-security-guidelines - Canonical URLs: https://sth.sh/en/compliance/ncsa-ai-security-guidelines/ | https://sth.sh/th/compliance/ncsa-ai-security-guidelines/ - Regulated Entities / Scope: Executives, AI development and operations teams, legal and DPO functions, and security teams using the NCSA guidance - Audit / Test Frequency: Lifecycle-aligned (Phases 0 to 6, Concept through Disposal) - Technical Scope: Prompts, models, APIs, training data, software supply chain, and surrounding software - Risk Focus: Prompt injection, jailbreaking, data poisoning, confidential-data leakage, and go-live without verification evidence - Overview: A summary of NCSA's AI Security Guidelines, covering the 7-phase secure AI lifecycle, governance, risk management, and practical testing focus areas. - Core Sections: * Purpose and intended audiences: NCSA presents the document as guidance for developing, managing, and using AI systems securely and trustworthily. * The secure AI lifecycle framework: The guidelines structure security controls across the full lifecycle, from pre-investment planning to decommissioning. * Governance, risk, and accountability: Governance uses the GRC framework and stresses that risk must be evaluated in each organization's specific context. * Practical implementation focus: The document recommends key measures to support auditing and retrospective review. ### ncsa-cloud-security-standard - Canonical URLs: https://sth.sh/en/compliance/ncsa-cloud-security-standard/ | https://sth.sh/th/compliance/ncsa-cloud-security-standard/ - Regulated Entities / Scope: Government agencies, regulators, Critical Information Infrastructure (CII) entities, and cloud providers serving those agencies - Audit / Test Frequency: Low-impact CSCs self-assess at least annually. Medium and high impact use 3-year attestation or certification under annex 1.8 - Technical Scope: Public IaaS, PaaS, and SaaS services, CSC/CSP role split, and vulnerability management defined in the agreement - Risk Focus: Non-compliance with the NCSA Cloud Standard B.E. 2567 according to the system's impact level - Overview: A source-based guide to the National Cyber Security Committee Notification on Cybersecurity Standards for Cloud Systems B.E. 2567 (Thailand National Cloud Security Framework), separating scope, customer/provider responsibilities, and implementation evidence. - Core Sections: * Applicability and effective date: The standard is officially in effect as of 10 September 2026, establishing mandatory duties for agencies using public cloud services under the National Cloud Security Framework. * Shared accountability, SLAs, and legal jurisdiction: The standard requires cloud customers and providers to agree and record appropriate information-security roles, duties, and binding responsibilities. * Technical control areas to plan jointly: The annex addresses customer operational processes and technical capabilities that cloud providers must support under Clause 5.2. * Evidence and reporting: Turn the requirements into auditable evidence from service selection through contract review and operation. ### ncsa-post-quantum-readiness - Canonical URLs: https://sth.sh/en/compliance/ncsa-post-quantum-readiness/ | https://sth.sh/th/compliance/ncsa-post-quantum-readiness/ - Regulated Entities / Scope: Government and CII organizations that process confidential information, as practical NCSA guidance rather than a binding notification - Audit / Test Frequency: Follow the document's seven-step roadmap; it is not an annual legal cadence - Technical Scope: Public-key cryptography, IT and crypto-asset inventories, PQC, QKD, and hybrid approaches - Risk Focus: Harvest Now Decrypt Later when data must remain secret longer than current public-key algorithms remain safe - Overview: A source-based guide to NCSA's Guidelines for Post-Quantum Readiness for government agencies and critical information infrastructure organizations that process confidential information, focusing on risk assessment, cryptographic asset inventories, and cryptographic transition planning. - Core Sections: * Scope and the quantum risk to assess first: The document is practical guidance rather than a binding notification. It targets government agencies and CII organizations that collect, use, exchange, or disclose confidential information through information systems. * Use the Mosca model to prioritize transition: The guidance assesses risk through the relationship between the time an organization needs to migrate, the required secrecy lifetime of data, and the time until a capable quantum threat emerges. * PQC, QKD, and transition design: The guidance discusses Post-Quantum Cryptography (PQC), Quantum Key Distribution (QKD), and hybrid approaches so each system can be assessed against its own risk and constraints. * A seven-step roadmap and the evidence to start collecting: The guidance sets out seven readiness steps that executives, managers, and operational teams must advance together rather than treating the work as a one-point algorithm replacement. ### ncsa-zero-trust-guidelines - Canonical URLs: https://sth.sh/en/compliance/ncsa-zero-trust-guidelines/ | https://sth.sh/th/compliance/ncsa-zero-trust-guidelines/ - Regulated Entities / Scope: Executives, policy owners, technical teams, and security engineers planning a move away from perimeter-based security - Audit / Test Frequency: Review protect surfaces, policy, and maturity under the guidance; not an annual pentest mandate - Technical Scope: Identity, devices, networks, applications and workloads, and data under the Zero Trust Maturity Model - Risk Focus: Lateral movement when the internal network is still trusted by default - Overview: A source-based guide to NCSA's Zero Trust Guidelines, published as version 1.0, for executives, policy owners, technical teams, system administrators, and security engineers planning a risk-based transition from perimeter security to continuous verification. - Core Sections: * Zero Trust principles and adoption scope: The guidance shifts the assumption from trusting an internal network to verifying every access request against identity, device posture, and session context. * Architecture and policy decision points: The document explains that requesters and their devices pass through policy decision points before they can reach a resource, separating decision, session-management, and enforcement responsibilities. * A five-step risk-based transition: The guidance starts with a defined protect surface and expands incrementally instead of changing every system at once. * Gap analysis, maturity, and continuous operations: Gap analysis needs to cover strategy, governance, data, assets, operations, and control effectiveness rather than comparing tool inventories alone. ### mpa-content-security - Canonical URLs: https://sth.sh/en/compliance/mpa-content-security/ | https://sth.sh/th/compliance/mpa-content-security/ - Regulated Entities / Scope: Production studios, VFX/CGI facilities, post-production houses, sound stages, localization vendors, cloud rendering farms, and media software developers - Audit / Test Frequency: At least annually and after any significant application or infrastructure change - Technical Scope: External IPs, public hosts, web applications, APIs, content transfer tools (Aspera and Signiant), cloud assets, remote worker access, and network segmentation - Risk Focus: Pre-release content leaks, vendor disqualification by major studios, loss of TPN Shield standing, and contract termination - Overview: An authoritative guide to Motion Picture Association (MPA) Content Security Best Practices v5.3.1, Trusted Partner Network (TPN) governance, the four-tier Shield system, and penetration testing mandates (Control TS-4.1) across the entertainment supply chain. - Core Sections: * Understanding MPA and Trusted Partner Network governance: The Motion Picture Association and Trusted Partner Network establish baseline cybersecurity standards to prevent leaks of pre-release film, television, and streaming assets. * The next-generation four-tier TPN Shield framework: TPN Shield status communicates preparedness and remediation progress for Content Owners to use in their vendor-risk decisions. * Control TS-4.1 penetration testing versus TS-4.0 vulnerability scanning: The v5.3.1 workbook separates TS-4.0 vulnerability scanning from TS-4.1 penetration testing and gives each process distinct scope, cadence, tester, and remediation expectations. * Application security, cloud infrastructure, and remote working scope: Version 5.3.1 deepens application security scrutiny while addressing distributed post-production workflows and hybrid cloud deployments. * Remediation workflows and audit evidence for Gold Shield qualification: Receiving a penetration test report is only the baseline. Earning a TPN Gold Shield requires verified remediation evidence reviewed by TPN SecOps. ### pci-dss - Canonical URLs: https://sth.sh/en/compliance/pci-dss/ | https://sth.sh/th/compliance/pci-dss/ - Regulated Entities / Scope: Merchants, Payment Processors, Gateways, and E-commerce handling card data (CDE) - Audit / Test Frequency: Annually (Req 11.4). Every 6 months for CDE segmentation by service providers (Req 11.4.6) - Technical Scope: Cardholder Data Environment (CDE), Payment APIs, External and Internal Network - Risk Focus: Monthly card brand fines ($5,000 to $100,000 per month) and loss of card processing privileges - Overview: Start with the Cardholder Data Environment, or CDE, and systems that can affect its security rather than only the payment page. - Key Controls & Guidance: * Create data flows and an asset inventory to identify the CDE, connected-to systems, and security-impacting systems before planning tests. * Requirement 11.4 calls for internal and external testing at least every 12 months and after significant infrastructure or application changes. * Cover both network and application layers, including relevant threats and vulnerabilities from the prior 12 months. * Where network segmentation reduces scope, test its effectiveness under the standard's conditions, remediate exploitable findings, and retest before relying on the evidence. ### ndid - Canonical URLs: https://sth.sh/en/compliance/ndid/ | https://sth.sh/th/compliance/ndid/ - Regulated Entities / Scope: NDID Members: Relying Parties (RP), Identity Providers (IdP), Authoritative Sources (AS) - Audit / Test Frequency: At least annually prior to node onboarding or annual re-certification - Technical Scope: NDID Proxy Nodes, HSM Key Modules, OAuth2 and OIDC Endpoints, Encryption Gateways - Risk Focus: Suspension from NDID network and revocation of cross-organizational ID verification rights - Overview: NDID connects requests among a Requesting Party, Identity Provider, and Authoritative Source. It routes requests and records necessary transaction metadata rather than acting as a centralized personal-data warehouse. - Key Controls & Guidance: * The user begins a service request with the Requesting Party and selects a registered Identity Provider. * NDID routes the request to the Identity Provider, which proofs and authenticates the user before returning the result. * The Requesting Party checks result integrity and the electronic signature before making its service decision. * When an Authoritative Source is involved, confirmed data returns to the Requesting Party over an encrypted channel outside the NDID Platform. ### oic - Canonical URLs: https://sth.sh/en/compliance/oic/ | https://sth.sh/th/compliance/oic/ - Regulated Entities / Scope: Life and Non-Life Insurance Companies, Corporate Brokers, and InsurTech Platforms - Audit / Test Frequency: Regular external penetration testing of internet-facing systems, or after significant change (clause 21(6)) - Technical Scope: Online Policy Systems, Claims Management Apps, Customer and Agent Portals, Insurance APIs, Core Databases - Risk Focus: OIC regulatory audit orders, administrative warnings, and forced system remediation - Overview: OIC regulations require insurance companies to engage external specialists for regular internet-facing penetration testing, combined with technical vulnerability management and risk treatment plans. - Key Controls & Guidance: * Maintain an information asset inventory and criticality classification for core insurance systems, customer and agent portals, mobile applications, insurance APIs, and underlying infrastructure. * Clause 21(6) mandates external penetration testing for internet-facing applications and networks regularly or upon significant system changes, alongside systematic vulnerability management. * Integrate test findings into formal risk assessments, assigning issues to control owners, establishing a Risk Treatment Plan with remediation deadlines, and capturing retest evidence to demonstrate control effectiveness. * Report assessment findings and testing evidence to the risk management committee and the board to support mandatory annual IT audits under clauses 34 and 35. ### OWASP Top 10 guides for Web, Mobile, API, LLM, and Agentic - Canonical URLs: https://sth.sh/en/compliance/owasp-top-10/ | https://sth.sh/th/compliance/owasp-top-10/ ### OWASP Top 10:2025 for web applications - Canonical URLs: https://sth.sh/en/compliance/owasp-top-10/web/ | https://sth.sh/th/compliance/owasp-top-10/web/ ### OWASP Mobile Top 10:2024 - Canonical URLs: https://sth.sh/en/compliance/owasp-top-10/mobile/ | https://sth.sh/th/compliance/owasp-top-10/mobile/ ### OWASP API Security Top 10:2023 - Canonical URLs: https://sth.sh/en/compliance/owasp-top-10/api/ | https://sth.sh/th/compliance/owasp-top-10/api/ ### OWASP Top 10 for LLM Applications:2026 - Canonical URLs: https://sth.sh/en/compliance/owasp-top-10/llm/ | https://sth.sh/th/compliance/owasp-top-10/llm/ ### OWASP Top 10 for Agentic Applications:2026 - Canonical URLs: https://sth.sh/en/compliance/owasp-top-10/agent/ | https://sth.sh/th/compliance/owasp-top-10/agent/ ### mitre-attack - Canonical URLs: https://sth.sh/en/compliance/mitre-attack/ | https://sth.sh/th/compliance/mitre-attack/ - Overview: MITRE ATT&CK is a knowledge base for communicating observed adversary behaviour. Good use starts with a threat model and critical assets, not an attempt to tick every technique. - Key Controls & Guidance: * Select tactics and techniques from business context, attack surface, architecture, and threat intelligence relevant to the organisation. * Create an adversary-emulation plan with clear scope, timing, and guardrails, testing prevention, detection, and response only to the authorised degree. * Connect test evidence to telemetry, detection rules, SIEM, EDR, network logs, or cloud logs so gaps are traceable. * An ATT&CK mapping does not prove 100 percent coverage. Prioritise improvement by impact, likelihood, and service criticality. --- ## 3. OWASP Top 10 Series Summaries - **OWASP Top 10:2025 for web applications**: A01:2025 Broken Access Control, A02:2025 Security Misconfiguration, A03:2025 Software Supply Chain Failures, A04:2025 Cryptographic Failures, A05:2025 Injection, A06:2025 Insecure Design, A07:2025 Authentication Failures, A08:2025 Software or Data Integrity Failures, A09:2025 Security Logging and Alerting Failures, A10:2025 Mishandling of Exceptional Conditions. - **OWASP Mobile Top 10:2024**: M1 Improper Credential Usage, M2 Inadequate Supply Chain Security, M3 Insecure Authentication and Authorization, M4 Insufficient Input/Output Validation, M5 Insecure Communication, M6 Inadequate Privacy Controls, M7 Insufficient Binary Protections, M8 Security Misconfiguration, M9 Insecure Data Storage, M10 Insufficient Cryptography. - **OWASP API Security Top 10:2023**: API1:2023 Broken Object Level Authorization, API2:2023 Broken Authentication, API3:2023 Broken Object Property Level Authorization, API4:2023 Unrestricted Resource Consumption, API5:2023 Broken Function Level Authorization, API6:2023 Unrestricted Access to Sensitive Business Flows, API7:2023 Server Side Request Forgery, API8:2023 Security Misconfiguration, API9:2023 Improper Inventory Management, API10:2023 Unsafe Consumption of APIs. - **OWASP Top 10 for LLM Applications:2026**: LLM01:2026 Prompt Injection, LLM02:2026 Sensitive Information Disclosure, LLM03:2026 Excessive Agency, LLM04:2026 Supply Chain, LLM05:2026 Data and Model Poisoning, LLM06:2026 Unbounded Consumption, LLM07:2026 Misinformation, LLM08:2026 Hidden Context Exposure, LLM09:2026 Vector and Embedding Weaknesses, LLM10:2026 Improper Output Handling. - **OWASP Top 10 for Agentic Applications:2026**: ASI01:2026 Agent Goal Hijack, ASI02:2026 Tool Misuse and Exploitation, ASI03:2026 Identity and Privilege Abuse, ASI04:2026 Agentic Supply Chain Vulnerabilities, ASI05:2026 Unexpected Code Execution, ASI06:2026 Memory & Context Poisoning, ASI07:2026 Insecure Inter-Agent Communication, ASI08:2026 Cascading Failures, ASI09:2026 Human-Agent Trust Exploitation, ASI10:2026 Rogue Agents. --- ## 4. Career Opportunities at STH STH is continuously seeking talented offensive cybersecurity practitioners in Bangkok, Thailand: - Junior & Mid-level Penetration Testers (Web, Mobile, API, Network) - Senior Penetration Testers & Red Team Specialists - IT Security Managers & Engagement Leads See requirements and apply at https://sth.sh/en/careers/ or email resume to pentest@sth.sh. --- ## 5. Security Research & Technical Publications ### Google SAIF: Six Core Principles for Securing AI Systems - URL: https://sth.sh/en/compliance/google-saif/ - Date: 2026-09-23 - Category: ai-security - Summary: A breakdown of Google's Secure AI Framework and practical steps to defend models, training data, and agent integrations. ### Does ISO/IEC 27001:2022 Require Penetration Testing? - URL: https://sth.sh/en/compliance/iso-27001/ - Date: 2026-09-23 - Category: frameworks - Summary: Analyzing Control A.8.8 (Management of technical vulnerabilities), threat-informed prioritization with CISA KEV and EPSS, and operationalizing pentest evidence across ISMS core clauses. ### What ISO/IEC 42001:2023 Means and How AI Pentesting Proves AIMS Readiness - URL: https://sth.sh/en/compliance/iso-42001-ai-management/ - Date: 2026-09-23 - Category: ai-security - Summary: An in-depth breakdown of ISO/IEC 42001:2023 for AI management systems and how offensive testing provides verifiable evidence for executive oversight and audits. ### Understanding MITRE ATLAS for AI Red Teaming and Threat Modeling - URL: https://sth.sh/en/compliance/mitre-atlas/ - Date: 2026-09-23 - Category: ai-security - Summary: Explore the 16 tactics of the MITRE ATLAS matrix to plan systematic adversary simulations across Generative AI, RAG pipelines, and agentic workflows. ### NCSA Government Cloud Security Standard and Testing Guidance - URL: https://sth.sh/en/compliance/ncsa-cloud-security-standard/ - Date: 2026-09-23 - Category: frameworks - Summary: National cloud security guidelines in Thailand and technical testing methodologies for public and private cloud environments. ### NCSA Post-Quantum Cryptography Readiness Guidelines 2025: Technical Implementation - URL: https://sth.sh/en/compliance/ncsa-post-quantum-readiness/ - Date: 2026-09-23 - Category: frameworks - Summary: In-depth guide to Thailand NCSA Post-Quantum Readiness guidelines, Shor and Grover risk models, Mosca theorem evaluation, dual-pillar inventories, and hybrid PQC architecture. ### Zero Trust: from policy decisions to enforcement - URL: https://sth.sh/en/compliance/ncsa-zero-trust-guidelines/ - Date: 2026-09-23 - Category: frameworks - Summary: Follow the roles of the PE, PA, and PEP, and see how a policy decision controls the path to a resource. ### NIST AI RMF Explained: Risk Management and Technical Assurance - URL: https://sth.sh/en/compliance/nist-ai-rmf/ - Date: 2026-09-23 - Category: ai-security - Summary: How the NIST AI Risk Management Framework connects organizational governance with empirical AI security testing. ### Thai SEC Security Testing Requirements for Securities and Digital Assets - URL: https://sth.sh/en/compliance/sec/ - Date: 2026-09-23 - Category: regulations - Summary: Comprehensive guide to Thai SEC cybersecurity regulations, vulnerability assessments, penetration testing, digital asset custody, and smart contract audits. ### MPA Content Security v5.3.1 and Penetration Testing for Media Production - URL: https://sth.sh/en/compliance/mpa-content-security/ - Date: 2026-09-03 - Category: frameworks - Summary: An overview of MPA Content Security Best Practices v5.3.1, the TPN four-tier shield framework, and mandatory penetration testing under Control TS-4.1 for production vendors. ### Penetration Testing Requirements under Bank of Thailand Regulations - URL: https://sth.sh/en/compliance/bank-of-thailand/ - Date: 2026-08-22 - Category: regulations - Summary: Summary of BOT circulars and guidelines on threat-led penetration testing (iPentest), mobile banking security, and e-money systems. ### Thailand Cybersecurity Act 2019 and Critical Information Infrastructure - URL: https://sth.sh/en/compliance/cybersecurity-act/ - Date: 2026-08-22 - Category: regulations - Summary: Duties of CII operators under Thailand's Cybersecurity Act and recommended penetration testing practices. ### Enterprise ATT&CK v19.2: Adversary Tactics and Offensive Security Testing - URL: https://sth.sh/en/compliance/mitre-attack/ - Date: 2026-08-22 - Category: frameworks - Summary: Navigating the 14 tactics of Enterprise ATT&CK v19.2 to design objective-driven offensive tests and evaluate detection coverage. ### NCSA Website Security Standard 2025 and Testing Requirements - URL: https://sth.sh/en/compliance/ncsa-website-standard/ - Date: 2026-08-22 - Category: regulations - Summary: Overview of the National Cyber Security Agency's standard for government and critical infrastructure websites in Thailand. ### OWASP Top 10 for Agentic Applications:2026 and Agent Security - URL: https://sth.sh/en/compliance/owasp-top-10/agent/ - Date: 2026-08-22 - Category: owasp - Summary: Analyzing security risks in autonomous AI agents, tool invocation, memory poisoning, and Model Context Protocol integrations. ### OWASP API Security Top 10:2023 and Practical Mitigation - URL: https://sth.sh/en/compliance/owasp-top-10/api/ - Date: 2026-08-22 - Category: owasp - Summary: Key vulnerabilities in modern API architectures including BOLA, broken authentication, and excessive data exposure. ### OWASP Top 10 for LLM Applications:2026 Security Guide - URL: https://sth.sh/en/compliance/owasp-top-10/llm/ - Date: 2026-08-22 - Category: owasp - Summary: Comprehensive guide to securing LLM applications against prompt injection, model theft, sensitive data exposure, and supply-chain vulnerabilities. ### OWASP Mobile Top 10:2024 for iOS and Android Security - URL: https://sth.sh/en/compliance/owasp-top-10/mobile/ - Date: 2026-08-22 - Category: owasp - Summary: Essential mobile application security guidelines covering credential storage, network communications, and client-side code hardening. ### OWASP Top 10:2025 for Web Applications and Pentesting Guidelines - URL: https://sth.sh/en/compliance/owasp-top-10/web/ - Date: 2026-08-22 - Category: owasp - Summary: Detailed review of the 2025 web security risks, including broken access control, cryptographic failures, and injection attacks with mitigating controls. ### PCI DSS v4.0.1 Penetration Testing and Network Segmentation Guidance - URL: https://sth.sh/en/compliance/pci-dss/ - Date: 2026-08-22 - Category: regulations - Summary: Explaining Requirement 11.4 penetration testing mandates, segmentation verification, and vulnerability management under PCI DSS v4.0.1. ### Does Thailand's PDPA Require Penetration Testing? - URL: https://sth.sh/en/compliance/pdpa/ - Date: 2026-08-22 - Category: regulations - Summary: Navigating personal data protection security measures under the PDPA and demonstrating appropriate technical controls through offensive testing.