How can a successful SOC2-compliant ISMS be built without power, money and allocated resources?
0 likes27 views
The document discusses building an information security management system (ISMS) compliant with SOC2 for a Kubernetes software company with limited resources. It outlines using threat modeling to identify key assets like Docker images, and developing initial security documents around principles, policies for vulnerabilities and releases. Challenges include prioritizing many vulnerabilities, demonstrating due care with transparency and commitments to customers. Building security is a long-term effort.
How can a successful SOC2-compliant ISMS be built without power, money and allocated resources?
- 1. How can a successful SOC2-compliant ISMS be built without power, money and allocated resources? Vsevolod Shabad vshabad@vshabad.com +7 777 726 4790
- 2. Briefly about me: the international octopus IT Cybersecurity Cloud Technologies Risk Management Compliance Data Science & ML Project Management Culture Changes Fraud Prevention 🇷🇺 🇰🇿 🇷🇸 🇧🇬 🇸🇬 🇹🇷
- 3. Briefly about company •US vendor of Kubernetes orchestration software in multi-cloud environments (AWS, Azure, GCP, …) •Geo-distributed team (~15 people) •Flat organisational structure led by CTO
- 4. What SOC2 means ISO 27001 SOC2 (SSAE 18) Formal title Information security, cybersecurity and privacy protection — Information security management systems — Requirements Statement on Standards for Attestation Engagements no. 18 Purpose Information Security Management System Trust Management System Content A specific set of controls (ISO 27001 Annex A, ISO 27002) + include/exclude justification A set of principles: • Security • Availability • Processing Integrity • Confidentiality • Privacy Compliance assessment Periodic • Periodic (SOC2 Type 1) – processes and politics • Continuous (SOC2 Type 2) – controls efficiency Information disclosure to interested parties Not intended By NDA
- 5. The typical SOC2 report (fragment)
- 6. The reasons for the supplier SOC2 certification • Customer benefit – Due Care for the Supply Chain Attack risks • Supplier benefit – the prerequisite for getting the tenders of large corporate customers Sonatype 8th Annual State of the Software Supply Chain report https://www.sonatype.com/resources/2023-software-supply-chain-report
- 7. Three components of Security Governance WHAT and WHY? • Standards, Policies, Guidelines HOW? • Procedures (+ automation) BY WHOM? • Personnel
- 8. Information security priority raising MISSION VALUES RISKS • A general feeling of a large accumulated technical debt • Transparency of the sales pipeline and current state • Salary delays + Personal authority of vCISO
- 9. How was chosen the key asset to protect • Discussed the importance of focus (thanks to the Kanban approach!) • Inventoried the potential threat actor groups and their interests • Determined which assets are most valued for them The key asset is the Docker image of the supplied software
- 10. The threat model fragment (STRIDE approach) Threat Desired Property Preventive control Detective Control Spoofing Authencity Docker Content Trust DOCKER_CONTENT_TRUST = 1 Tampering Integrity SHA256 Digest Tagging ‘docker pull’ return code Repudiation Non-Repudiability Personalized Docker Hub accounts Docker Hub Audit Logs Information Disclosure Confidentiality No No Denial of Service Availability Docker Hub Download Rate Limit Docker pull timeout Elevation of Privilege Authorisation Image vulnerability check Falco runtime monitoring Asset (object) – distributive Docker images of the supplied software Example of Trust Service Criteria: CC7.1 To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
- 11. First-stage documents • Key cybersecurity and trust principles for XXX company • Acceptable Use Policy • Release Publishing Policy • Vulnerability & Patch Management Policy • Vulnerability Check & Triage Procedure • Vulnerability Remediation Procedure • …
- 12. Key cybersecurity and trust principles… … Management Principles • Stewardship and Accountability. Everyone is responsible for protecting the information, and individuals are held accountable. • Risk Management. The information must not be stored without understanding and formally mitigating or accepting the risk. • Business Ownership. All employees and independent contractors own information security. Senior managers are involved in determining and accepting information security risks. • Privacy. Privacy and security are not a "zero-sum game". All aspects of privacy are weighed and incorporated into security practices. Architecture Principles • Defense In-Depth. A system should employ multiple levels of defense such that a single breach of one sub-system does not expose the entire system directly to an attacker. • Least Privilege Access. A user, system, or process should only be granted the minimum set of privileges they require to perform their designated job. • Segmentation. Sub-systems should be partitioned logically and isolated using physical devices and/or security controls. • … Statement of Responsibility • CTO is a senior manager who is ultimately accountable for all information risk assessments, security strategies, planning and budgeting, incident management, and information security implementation. CTO approves all components of the Company's ISMS and is solely accountable for authorizing any violation of the policies, standards, and procedures of the Company's ISMS based on his reasoned judgment. CTO provides a reasonable decision about the ISMS's scope and is solely accountable for all cybersecurity issues out of this scope. • …
- 13. Primarily used tools •Trivy (+ custom post-processor *) • Vulnerable third-party packages & libraries • Vulnerable build tools • Misconfigurations of Dockerfiles •Gosec (+custom post-processor *) • Vulnerable custom source code * False positives suppression
- 14. Key difficulties and ways to overcome • Too many identified critical vulnerabilities at the first launch + tight release deadlines • Demonstration of Due Care • Accepted Compromise: • Public disclosure of the list of open critical vulnerabilities at the moment of new release • CTO’s personal public commitment • Private notification of the key customers about open critical vulnerabilities two weeks before the public announce
- 15. Building ISMS is a marathon, not a sprint! https://calendly.com/vshabad +7 777 726 4790 (cell, WhatsApp, TG) vshabad@vshabad.com https://linkedin.com/in/vshabad