Upload files to "q1-security audit"

2026-07-28 18:07:28 +00:00
--- a/audit/Ghaymah_Security_Audit_Formal.md
+++ b/audit/Ghaymah_Security_Audit_Formal.md
@@ -0,0 +1,203 @@
 # Security Audit Report
 ## Ghaymah Cloud (ghaymah.systems)
 | Field | Detail |
 |---|---|
 | Report Title | External Security Assessment of Ghaymah Cloud |
 | Target System | ghaymah.systems and associated public documentation |
 | Assessment Type | Passive, black-box, open-source intelligence (OSINT) review |
 | Date of Assessment | July 28, 2026 |
 | Classification | For academic/coursework use |
 ---
 ## 1. Executive Summary
 This report presents an external security assessment of Ghaymah Cloud, a platform-as-a-service (PaaS) provider offering managed compute, container hosting, managed databases, object and block storage, and AI model hosting. The assessment covers fifteen points organized into five categories: Container Security, Network Security, the OWASP Top Ten (subset), Data Security, and Identity and Access Management (IAM).
 The assessment was conducted using publicly available information only. No authenticated access, active scanning, or intrusive testing was performed. Consequently, the findings in this report distinguish between claims made directly by the provider, facts directly observable from the public website, and matters that cannot be confirmed without internal or authenticated access. Two specific findings requiring attention are identified in Section 4.2 and Section 3.3.
 ## 2. Scope and Methodology
 ### 2.1 Scope
 The assessment was limited to the following sources:
 1. The Ghaymah Cloud public website (ghaymah.systems)
 2. The dedicated security disclosure page (ghaymah.systems/security)
 3. The published shared-responsibility model documentation (ghaymah.systems/shared-responsibility-model)
 The authenticated customer dashboard (deploy.ghaymah.systems) was not tested beyond confirming the existence of its login interface, as this would constitute active testing requiring formal, scoped authorization.
 ### 2.2 Methodology
 The assessment methodology consisted of a passive review of publicly published material. No port scanning, vulnerability scanning, credential testing, injection testing, or interaction with authenticated systems was conducted. This boundary reflects standard practice: active testing of a production system requires a documented scope of work, defined rules of engagement, and direct coordination with the provider's security team, independent of any informal permission that may have been granted for this exercise.
 ### 2.3 Evidence Classification
 Each finding in this report is assigned one of the following classifications:
 | Classification | Definition |
 |---|---|
 | Verified (Self-Reported) | The provider states this control directly on its own published materials. |
 | Observed | The fact is directly observable from the public website (e.g., site structure, HTTP response behavior). |
 | Not Externally Verifiable | The matter cannot be confirmed without internal or authenticated access, and is noted as an evidence gap rather than assumed to be present or absent. |
 | Finding | A specific gap or inconsistency identified during the course of this assessment. |
 A full internal audit would replace items classified as "Not Externally Verifiable" with evidence obtained through configuration review, policy documentation, penetration test reports, and interviews with responsible personnel. This distinction represents the primary limitation of an externally conducted review relative to a complete audit.
 ---
 ## 3. Container Security
 ### 3.1 Multi-Tenant Workload Isolation
 Ghaymah operates a managed Kubernetes platform underlying its container deployment product. Customers submit source code or a Dockerfile, and the platform performs the build and deployment process. According to the published shared-responsibility documentation, Ghaymah is responsible for the Kubernetes control plane, platform updates, and patching, while the customer retains responsibility for container-level configuration and application monitoring.
 Classification: Verified (Self-Reported), with a gap. Specific isolation mechanisms, including network policy enforcement, runtime sandboxing, and node-level tenant segregation, are not disclosed in public documentation. This is common practice among providers, but it means the strength of tenant isolation cannot be independently confirmed through external review.
 ### 3.2 Container Registry Security
 Ghaymah provides a dedicated container registry product for image storage and management, offered separately from the primary deployment pipeline.
 Classification: Verified (Self-Reported) with respect to the existence of the product. The corresponding product page is rendered client-side and did not expose static detail regarding image vulnerability scanning, image signing, or default access-control configuration. Confirmation of these controls would require review from within the authenticated dashboard.
 ### 3.3 Build Pipeline and CI/CD Security
 The platform's core function is the automated building of container images from customer-submitted source code or Dockerfiles, including automatic framework detection, supported by a dedicated CI/CD product. This architecture requires the platform to execute arbitrary, untrusted customer-supplied code during the build process.
 Classification: Observed, as an architectural characteristic derived from the product description. This represents the highest-risk surface identified for container security in this assessment, given the potential for build-time sandbox escape or supply-chain injection through automated build steps. No public documentation describes the isolation controls applied to the build environment. This item is recommended as a priority topic for any follow-up internal review.
 ---
 ## 4. Network Security
 ### 4.1 Transport Encryption (TLS)
 Published documentation states the use of TLS 1.3 for data in transit. Every application deployed on the platform is automatically issued a free SSL certificate and a dedicated HTTPS subdomain.
 Classification: Verified (Self-Reported).
 ### 4.2 Perimeter Defense (Firewall, Web Application Firewall, and Monitoring)
 Ghaymah states that it operates firewall systems that monitor and block unauthorized access attempts before they reach customer infrastructure, supported by continuous, twenty-four-hour automated monitoring, with a stated average detection time of under one minute.
 Classification: Verified (Self-Reported). Specific detail regarding the distributed-denial-of-service mitigation provider, content delivery network, or edge network architecture is not published. This is a reasonable disclosure boundary for a provider to maintain, but it means these claims cannot be independently corroborated through external review.
 ### 4.3 Domain Name System and Subdomain Architecture
 Each deployed application is assigned a subdomain under the shared ghaymah.systems domain, with optional custom domain support available at higher service tiers.
 Classification: Observed, with an associated finding. Any platform that issues subdomains to customers on a shared parent domain carries an inherent structural risk of subdomain takeover, arising from DNS records that remain active after an associated application or domain mapping has been removed. This is a standard item in external attack-surface assessments for this class of architecture. It is noted here as a risk category rather than a confirmed vulnerability, as verification would require testing beyond the scope of this review.
 ---
 ## 5. OWASP Top Ten (Selected Subset)
 The following three categories from the OWASP Top Ten (2021) were selected for assessment on the basis that they are the categories for which public evidence is available. The remaining categories require authenticated or code-level testing and are outside the scope of this review.
 ### 5.1 A02:2021 — Cryptographic Failures
 Published controls include AES-256 encryption for data at rest, TLS 1.3 for data in transit, and encrypted connections for the managed PostgreSQL service.
 Classification: Verified (Self-Reported). These are appropriate algorithm choices if implemented as described. However, a stated encryption coverage figure does not, by itself, constitute evidence of correct key management, key rotation procedures, or certificate pinning practices, none of which are disclosed publicly.
 ### 5.2 A05:2021 — Security Misconfiguration and Vulnerability Management
 Ghaymah states that security patches are applied promptly upon release and that the platform undergoes regular penetration testing conducted by independent security professionals.
 Classification: Verified (Self-Reported), with a finding. The security disclosure page references a vulnerability-reporting channel at the path /security/report. This path returned an HTTP 404 (Not Found) response at the time of this assessment. This constitutes a verifiable configuration or content gap: an advertised responsible-disclosure channel that is not currently reachable. This finding should be communicated directly to Ghaymah, given the stated availability of a direct point of contact.
 ### 5.3 A07:2021 — Identification and Authentication Failures
 The customer login interface is located at deploy.ghaymah.systems/login and is implemented as a client-side-rendered application. No server-rendered markup is exposed to a passive request, meaning that controls such as multi-factor authentication availability, password policy, account lockout or rate-limiting behavior, and session management cannot be assessed through external review without creating an account and interacting directly with the application, which would exceed the passive scope of this assessment.
 Classification: Not Externally Verifiable. This item should be treated as an open item requiring internal confirmation rather than an assumed strength or weakness.
 ---
 ## 6. Data Security
 ### 6.1 Encryption at Rest and in Transit
 Consistent with Section 5.1, published documentation states the use of AES-256 encryption at rest and TLS 1.3 in transit, with encrypted connections specifically noted for the managed PostgreSQL service.
 Classification: Verified (Self-Reported).
 ### 6.2 Backup and Recovery
 Backup frequency is tiered according to service plan. Daily backups are provided beginning at the g4.medium tier, with hourly backups at the g5.large tier and above. Availability service-level agreements of 99.9 percent and 99.95 percent are stated for the g6.xlarge and g7.2xlarge tiers, respectively. The managed PostgreSQL service is separately described as including automatic backups.
 Classification: Verified (Self-Reported). This represents a reasonable, tier-differentiated backup posture. Recovery time objective (RTO), recovery point objective (RPO), and backup encryption or immutability characteristics are not specified in public documentation.
 ### 6.3 Data Ownership, Retention, and Breach Notification
 Published documentation states that data ownership remains with the customer, with an explicit statement that Ghaymah claims no rights over customer data, and includes a commitment to prompt notification in the event of a security incident affecting customer data.
 Classification: Verified (Self-Reported). These represent policy commitments rather than technical controls. Their practical effectiveness depends on the incident-response process and contractual terms, which are not published in full on the reviewed pages.
 ---
 ## 7. Identity and Access Management
 ### 7.1 Shared-Responsibility Boundary for Identity and Access Management
 The published shared-responsibility model explicitly assigns responsibility for access and identity management, including user and permission administration and application-level security, to the customer, while Ghaymah retains responsibility for securing the management platform, application programming interfaces, and underlying infrastructure.
 Classification: Verified (Self-Reported). This division of responsibility is clearly documented and is consistent with industry-standard shared-responsibility frameworks used by established cloud providers. This is assessed as a positive finding, as the documentation is clearer on this point than that of many comparable providers.
 ### 7.2 Platform-Side Customer Authentication
 A dedicated login portal exists for the customer dashboard.
 Classification: Observed, with respect to the existence of the interface. Consistent with Section 5.3, specific authentication capabilities, including multi-factor authentication, single sign-on support, and scoping of application programming interface tokens, are not visible through external review, as the application is rendered client-side. This item is identified as the highest-priority item for direct verification with Ghaymah's technical team, given that Identity and Access Management is one of the five required assessment categories.
 ### 7.3 Internal and Administrative Access Control
 Published documentation states that Ghaymah maintains an integrated identity and access management system intended to ensure that appropriate personnel access appropriate resources at appropriate times, representing a least-privilege access claim with respect to Ghaymah's own internal staff access to customer infrastructure.
 Classification: Verified (Self-Reported), at the level of a general policy statement. No detail is provided regarding role granularity, administrative access logging and auditing, or just-in-time access provisioning. This represents a common gap between provider-stated security posture and independently verified security posture, of the kind typically closed through third-party attestation such as a SOC 2 Type II report. This gap is noted as a standard audit observation rather than as a criticism of the provider.
 ---
 ## 8. Summary of Findings
 | Item | Assessment Point | Category | Classification |
 |---|---|---|---|
 | 1 | Multi-tenant container isolation | Container Security | Verified (Self-Reported); isolation detail undisclosed |
 | 2 | Container registry security | Container Security | Verified (Self-Reported); scanning and signing detail undisclosed |
 | 3 | Build pipeline and CI/CD security | Container Security | Observed; highest-risk surface identified; controls undisclosed |
 | 4 | Transport encryption (TLS) | Network Security | Verified (Self-Reported) |
 | 5 | Perimeter defense (firewall, WAF, monitoring) | Network Security | Verified (Self-Reported); specifics undisclosed |
 | 6 | DNS and subdomain architecture | Network Security | Observed; structural subdomain-takeover risk category identified |
 | 7 | Cryptographic controls (OWASP A02) | OWASP Top Ten | Verified (Self-Reported) |
 | 8 | Patch management and vulnerability disclosure (OWASP A05) | OWASP Top Ten | Finding: disclosure endpoint returns HTTP 404 |
 | 9 | Authentication mechanisms (OWASP A07) | OWASP Top Ten | Not Externally Verifiable |
 | 10 | Encryption at rest and in transit | Data Security | Verified (Self-Reported) |
 | 11 | Backup and recovery | Data Security | Verified (Self-Reported); tiered by service plan |
 | 12 | Data ownership and breach notification | Data Security | Verified (Self-Reported); policy commitment |
 | 13 | Shared-responsibility IAM boundary | Identity and Access Management | Verified (Self-Reported); clearly documented |
 | 14 | Customer-facing authentication (MFA/SSO) | Identity and Access Management | Not Externally Verifiable |
 | 15 | Internal and administrative access control | Identity and Access Management | Verified (Self-Reported); general statement only |
 ---
 ## 9. Recommendations
 1. Repair or update the responsible-disclosure endpoint at /security/report. An advertised vulnerability-reporting channel that returns an error response undermines the stated commitment to engaging with security researchers.
 2. Obtain and review actual penetration test reports and any relevant compliance certifications, such as SOC 2, ISO 27001, or PCI-DSS where applicable, rather than relying solely on self-reported claims published on the website.
 3. Directly verify authentication controls, including multi-factor authentication availability, session timeout behavior, and API key scoping, through authorized testing of the dashboard.
 4. Request documentation regarding build-pipeline isolation controls, given that the platform executes arbitrary customer-supplied code as its core function.
 5. Request clarification of subdomain lifecycle management procedures to rule out dangling DNS records and associated subdomain takeover risk following application deletion.
 ## 10. Conclusion
 Based on the information published by Ghaymah Cloud, the provider demonstrates a generally structured approach to security, including a clearly documented shared-responsibility model, stated use of appropriate encryption standards, and a public commitment to regular security testing and patching. However, as with any assessment limited to publicly available information, a substantial portion of the required evidence, particularly regarding authentication mechanisms, internal access control granularity, and container isolation controls, could not be independently verified. One concrete finding, the non-functional vulnerability disclosure endpoint, was identified and should be addressed. A complete audit of the fifteen points identified in this report would require direct, authorized access to internal documentation, configuration, and personnel.
 ## 11. Sources
 1. ghaymah.systems (homepage; product and pricing structure)
 2. ghaymah.systems/security (security and privacy documentation)
 3. ghaymah.systems/shared-responsibility-model (shared-responsibility model documentation)
 4. ghaymah.systems/security/report (referenced vulnerability disclosure endpoint; returned HTTP 404 at time of assessment)