Skip to Content

Security Policy

Approved: 2025-09-08
Owner: Anthony Potdevin

1. Purpose & Scope

This policy defines the security practices required to protect the confidentiality, integrity, and availability of Amboss Technologies, Inc. systems, data, and infrastructure.

It applies to all employees, contractors, and third parties with access to company resources.

2. Roles & Responsibilities

  • Security Owner (CTO): accountable for compliance, monitoring, and incident response coordination.
  • All Engineers: Shared responsibility for securing code, infrastructure, and data.
  • Contractors: Must follow the same security policies as employees; access is time-bound and limited to what is necessary.
  • Management: Responsible for approving access, ensuring compliance, and reviewing incidents.
  • Incident Reporting: All employees and contractors must report suspected security incidents immediately via the [email protected] email or the #security-alerts Slack channel.

3. Security Policy & Governance

  • Amboss Technolgies, Inc. maintains this documented security policy and reviews it annually.
  • Compliance is verified through internal reviews at least twice per year.
  • Vendor best practices (AWS, Kubernetes, GitHub, Datadog) are followed, but controls are codified in this document to prevent ad hoc reliance.
  • Sensitive internal emails must be sent using PGP encryption.

4. Insurance

  • Amboss Technologies, Inc. will evaluate and maintain cyber liability insurance appropriate for its stage and customer data sensitivity.
  • This insurance will provide financial coverage in the event of data breaches, downtime, or cyber extortion.

5. Access Control

Principle of Least Privilege

  • All IAM roles, kubeconfigs, and service accounts must grant only the minimum permissions required.

Authentication

  • Google Workspace is the central identity provider.
  • MFA is required wherever supported (Google, AWS, GitHub, VPN, Datadog).

AWS Access

  • Root account is locked down and only used for critical account-level changes.

Kubernetes Access

  • Separate contexts for dev and prod.
  • Contractors may only access dev unless explicitly approved.

VPN

  • Required for production access.

6. Device Security (BYOD)

  • All devices accessing company systems must:
    • Use full-disk encryption.
    • Be protected by password or biometric lock.
    • Be kept up-to-date with security patches.
    • Have antivirus or endpoint protection enabled (e.g., CrowdStrike, SentinelOne, or OS-native AV).
  • Lost or stolen devices must be reported immediately.
  • Personal devices must not store unencrypted company secrets.

7. Secrets Management

  • Bitwarden is the company password manager.
  • SOPS is used for encrypting secrets in GitHub repos.
  • No secrets are stored in plaintext in code or CI/CD pipelines.
  • Secrets are rotated immediately after a compromise.

8. Infrastructure Security

AWS Security

  • GuardDuty enabled.
  • CloudTrail enabled.
  • S3 buckets must be private by default and encrypted (SSE-S3 or KMS).
  • RDS and ElastiCache (Redis) must not be publicly accessible.

Kubernetes Security

  • RBAC enforced.
  • Pod Security Standards applied (restrict privileged containers).
  • NetworkPolicies used to isolate namespaces.
  • Image sources must come from trusted registries only.
  • Containers must run as non-root where possible.
  • Regularly update cluster versions and node AMIs.

9. CI/CD Security

GitHub

  • MFA required for all accounts.
  • Branch protection required for develop and main branches.
  • Signed commits are required for all merges into develop and main branches.
  • PR reviews mandatory before merge.

Dependency Management

  • Snyk is used to perform automated dependency vulnerability checks in the build pipeline.

10. Monitoring & Threat Detection

Logging

  • Centralized in Datadog.
  • AWS CloudTrail, GuardDuty, and Kubernetes audit logs integrated.

Network Monitoring

  • Datadog and GuardDuty used to detect malicious network traffic.
  • Anomalies and unusual traffic patterns trigger alerts.

Security Alerts

  • At least one engineer is on-call at all times for real-time security alerts.
  • Datadog alerting pipeline ensures no gaps in monitoring coverage.

11. Incident Response

Roles & Responsibilities

  • On-call engineers are assigned automatically via Slack channels to ensure 24/7 coverage.

Reporting

  • All suspected or confirmed incidents must be reported immediately via [email protected] or the #security-alerts Slack channel.
  • The Security Owner acknowledges and tracks each incident.

Escalation

  • Security incidents must be escalated immediately to the on-call engineer.
  • Critical incidents escalated to management within 1 hour.

Documentation

  • All incidents are logged in the company Google Drive as a Google Doc.
  • Postmortems required for high-severity incidents.

Response Drills

  • Conducted at least annually to validate effectiveness of processes.

12. Business Continuity & Disaster Recovery

Backups

  • Automated daily RDS and S3 backups enabled.
  • Backups encrypted and stored in separate region.

Disaster Recovery Plan

  • Restoration procedures tested at least annually.

Tier 1 (High Severity Systems)

  • Core production apps, databases, authentication, monitoring.
  • RTO: < 4 hrs, RPO: < 1 hr.

Tier 2 (Medium Severity Systems)

  • Containers, dev/test environments, analytics.
  • RTO: < 24 hrs, RPO: < 8 hrs.

Tier 3 (Low Severity Systems)

  • Non-critical apps, archives.
  • RTO: 72 hrs, RPO: 24 hrs.

Continuity Plan

  • Critical operations documented, including communication, customer support, and minimal engineering functions.
  • Plans updated after each significant infra change or business expansion.

13. Contractor Access

  • Access must be approved by management.
  • Contractors are provisioned temporary accounts with least privileges.
  • All access revoked immediately after engagement ends.

14. Training & Awareness

  • Engineers must stay current with AWS and Kubernetes security best practices.

15. Policy Review

  • This policy is reviewed at least annually or after a major security incident.
  • Changes must be approved by management and communicated to all staff.
Last updated on
Rails