2025.1

In the digital age, cyber attacks are inevitable. At Niche Studio, we are taking a “zero trust”, “minimal infrastructure” approach to managing risk and information security.

This document describes our guiding principles and aspirations in managing risk and the building blocks of our security model.

Policy Statements¶

Niche Studio policy requires that:

(a) Niche Studio’s security program and operations should be designed and implemented with the following objectives and best practices:

• data-centric, cloud-first
• assume compromise therefore never trust, always verify
• apply controls using least-privilege and defense-in-depth principles
• avoid single point of compromise
• automate whenever possible, the simpler the better, less is more
• prompt self management and reward good behaviors

(b) Security shall remain a top priority in all aspects of Niche Studio’s business operations and product development.

Security Architecture¶

Niche Studio implements a multi-layered security architecture built on:

• Cloud Infrastructure: Binary Lane and DigitalOcean for compute resources
• CDN and Security: Cloudflare for DDoS protection, WAF, and global content delivery
• Storage: Wasabi Object Storage with Object Lock for immutable backups and archives
• Network Security: Tailscale for secure remote access and bastion host architecture
• Monitoring: Wazuh for security monitoring and threat detection
• Configuration Management: Ansible for automated server configuration and hardening

Cloud Architecture¶

Our cloud architecture follows these principles:

• Multi-Provider Strategy: Binary Lane and DigitalOcean for redundancy and vendor risk mitigation
• Immutable Infrastructure: Server configurations managed through Ansible playbooks
• Centralized Logging: All logs centralized through Wazuh and archived to Wasabi with Object Lock
• Automated Backups: Regular snapshots and backups with immutable retention policies
• Network Segmentation: Isolated environments with controlled access through bastion hosts

Centralized and Automated Operations¶

Niche Studio maintains centralized and automated operations through:

• Configuration Management: Ansible playbooks for consistent server hardening and configuration
• Access Control: Tailscale-based VPN with bastion host architecture for secure remote access
• Monitoring: Wazuh agents on all servers for centralized security monitoring
• Backup Management: Automated snapshots and Wasabi Object Lock for immutable long-term storage
• Incident Response: Automated alerting and centralized logging for rapid incident detection and response

Controls and Procedures¶

Niche Studio Security Principles¶

(1) Data-centric model; zero-trust architecture¶

“Zero Trust” is a data-centric security design that puts micro-perimeters around specific data or assets so that more granular rules can be enforced. It remedies the deficiencies with perimeter-centric strategies and the legacy devices and technologies used to implement them. It does this by promoting “never trust, always verify” as its guiding principle. This differs substantially from conventional security models which operate on the basis of “trust but verify.”

In particular, with Zero Trust there is no default trust for any entity — including users, devices, applications, and packets—regardless of what it is and its location on or relative to the corporate network. In addition, verifying that authorized entities are always doing only what they’re allowed to do is no longer optional; it’s now mandatory.

(2) “Air-Gapped” environments meet short-lived processes¶

We extend the zero-trust security model with a “Minimal Infrastructure” approach, where we use “Anything-as-a-Service” whenever possible, to harness the full power of the cloud. Cloud services allow us to contain and control access at a much more granular level, compared to operating on-premise infrastructure. Via access to the extensive APIs provided by the cloud services, we would be able to more easily integrate and automate security operations. Additionally, minimizing infrastructure significantly reduces always-on attack surfaces. Services that are not used are turned off, instead of being idly available which opens itself up to attacks. Together with Zero Trust, this security model and architecture enables a high degree of flexibility for end-user computing while maintaining the highest level of security assurance.

(3) Least-privilege temporary access¶

Cyber attacks are inevitable. When it comes to preparing for potential attacks, Niche Studio security operations take the approach that assumes a compromise can happen at any time, to any device, with little to no indicators. This is also an extension of the “zero trust” model. When building security operations, we carefully perform risk analysis and threat model, to identify potential single point of compromise and to avoid having the “keys to the kingdom”.

In other words, compromise of any single system or user or credential, should not easily lead to a broad or full compromise of the entire infrastructure or operations. For example, if an attacker gains access to a admin credential (e.g. Active Directory domain), it should not directly lead to the compromise of all systems and data in the environment.

(4) Immutable builds and deploys¶

The Niche Studio platform leverages a micro-service architecture. This means that the system has been decomposed into numerous small components that can be built and deployed individually. Before these components get deployed to our production environments, we thoroughly test and validate the changes in our lower environments which are completely isolated from production. This allows us to test upcoming changes while ensuring there is no impact to our customers.

As a particular build of a component progresses through our environments, it is important that the build does not change thus we ensure that each build is immutable. Once an immutable build has been validated in our lower (non-production) environments, we then deploy it to our production environment where the change will be available to Niche Studio customers and end-users.

Changes to our infrastructure (database schema changes, storage buckets, load balances, DNS entries, etc.) are also described in our source code and deployed to our environments just like the applications. This architectural approach to managing infrastructure is referred to as infrastructure as code and is a key requirement for fully automated deployments with minimal human touch.

(5) End-to-end data protection and privacy¶

It is of the utmost importance that Niche Studio provides for confidentiality (privacy), integrity and availability of its customer’s data. Your data is protected with end-to-end encryption, combined with strong access control and key management. We also prohibit our internal employees to access customer data directly in production. So your data remains safe and private at all times. We will never use or share your data without your prior consent.

(6) Strong yet flexible user access¶

We all know by now that “Passw0rd” makes a terrible password. Access control is so important we must get it right. That’s why we leverage tried-and-true technology such as SAML, OAuth, multi-factor authentication, and fine-grained authorisation to provide strong yet intuitive access options, both for our internal staff to access business resources and for our customers to access Niche Studio platform and services.

(7) Watch everything, even the watchers¶

You can’t protect what you can’t see.

As the famous strategist, Sun Tzu, once said, “Know thy self, know thy enemy. A thousand battles, a thousand victories.” It all starts with knowing ourselves. This applies to the infrastructure, environments, operations, users, systems, resources, and most importantly, data. It is important to inventory all assets, document all operations, identify all weaknesses, and visualize/understand all events.

This includes conducting various risk analysis, threat modeling, vulnerability assessments, application scanning, and penetration testing. Not only that, this requires security operations to keep an eye on everything, and someone should also “watch the watchers”.

At first, this would require significant manual effort and may seem impossible to keep up-to-date. Our goal is to automate security operations, so that this can be achieved programmatically as our operations evolve to become more complex.

Additionally, Niche Studio security team will actively monitor threat intelligence in the community, with feeds and information sharing platforms such as ACSC advisories and AusCERT to stay abreast of the attacker activities and methodologies.

(8) Centralized and automated operations¶

As much as possible, Niche Studio security will translate policy and compliance requirements into reusable code for easy implementation and maintenance. This allows us to truly be able to enforce policy and compliance in a fast and scalable way, rather than relying solely on written policies and intermittent manual audits. For example, end-point device policies may be translated into Wazuh rules and compliance may be enforced through the agent. Access Control policies for production environments are translated into cloud provider IAM policies and implemented via Terraform and Ansible code.

Automation makes it truly possible to centralize security operations, including not only event aggregation and correlation, but also the orchestration and management of previously siloed security controls and remediation efforts.

(9) Usable security¶

Security benefits from transparency, and should operate as an open-book. This allows the entire organisation to take responsibility for and accountability of adopting security best practices. Similar to code reviews and pull requests in the development process, Niche Studio security team makes security standards and practices available to all employees for feedback prior to adoption.

We emphasise on the usability and practicality of security. A security solution or process is not effective, if it is not being used, no matter how good it may be. Having impractical security would only generate noise, provide a false sense of security, and incur unnecessary cost. Nothing is perfect, but we embrace an agile mindset to test and try, and to continuously improve.

(10) Regulatory compliant and hacker verified¶

Security != Compliance. We cannot have one without the other.

Security Architecture¶

Niche Studio developed a security architecture on top of its three main infrastructure environments - Cloud (Binary Lane/DigitalOcean), DevOps, and workforce collaboration / end-user computing.

Architecture Diagrams¶

Detailed architecture diagrams of the in-scope networks, endpoints, applications as well as the security operations are developed and maintained by Notion.

Cloud Architecture¶

Cloud Native¶

• Designed for the cloud using true multi-tenant architecture
• Auto scaling across multiple data centers in multiple regions around the world
• Niche Studio services deployed inside private subnets with network segmentation
• Comprehensive security and compliance via cloud provider certifications
• Ongoing security testing by cloud providers and customers

Customer Benefits¶

• Infrastructure is tailored to our customer’s goals and usage patterns
• “Shared use” model reduces cost
• Nearly infinite compute and data capacity via cloud providers
• Customers can focus on solving business problems and not worry about infrastructure
• Automatic backup and recovery
• Continuous improvements via change control process
• Faster adoption of new technology

Evolution of Cloud Computing¶

1. Baremetal

   • A computer in someone else’s data center

2. Virtual Machine

   • A portion of a computer in someone else’s data center
   • In cloud environments, Virtual Machines are created from provider images

3. Container

   • A package of essential application libraries and code but not the core OS libraries - Simpler to scale a docker image because - No duplication of core OS processes (networking, filesystem, etc) - Typically a Docker container

4. Function

   • Just the application code that runs in a pre-built container

Niche Studio strives to leverage functions as the primary building blocks for our platform because:

• functions deploy more quickly than containers and virtual machines
• Cloud providers automatically scale serverless functions based on incoming requests
• they are short-lived processes which minimizes attack surface

Metrics, Measurements and Continuous Monitoring¶

A set of metrics / KPIs have been defined to assist in the measuring, reporting and optimizing the security program and the controls in place.

A security scorecard is produced every with updates to key metrics of the Niche Studio information security program, to measure its adoption and effectiveness.

The reports and scorecards are maintained by and can be accessed at Notion.

Quality of Service¶

Niche Studio strives to provide a high quality of service to all of its customers. This is accomplished through a security architecture that encompasses all of Niche Studio’s operations and provides high data confidentiality, integrity, and availability.

An overview of Niche Studio’s architecture is described in the Security Architecture section below. Niche Studio uses a highly scalable cloud architecture to provide system quality at all times.

All systems are monitored and measured in real time as described in the Application Service Event Recovery section below.

Niche Studio uses DevOps methodology as described in the Software Development Process section below to ensure a smooth delivery process of all systems and applications.

Status for external facing, customer applications and systems is published at https://nichestudio.crisp.watch/.

Application Service Event Recovery¶

Niche Studio will develop a status page to provide real time update and inform our customers of the status of each service. The status page is updated with details about an event that may cause service interruption / downtime.

A follow up root-cause analysis details (RCA) will be available to customers upon request after the event has transpired for further details to cause and remediation plan for the future. Event Service Level

Short (hours)¶

• Experience a short delay in service.
• Niche Studio will monitor the event and determine course of action. Escalation may be required.

Moderate (days)¶

• Experience a modest delay in service where processes in flight may need to be restarted.
• Niche Studio will monitor the event and determine course of action. Escalation may be required.
• Niche Studio will notify customers of delay in service and provide updates on Niche Studio’s status page.

Long (a week or more)¶

• Experience a delay in service and processes in flight may need to be restarted.
• Niche Studio will monitor the event and determine course of action. Escalation may be required.
• Niche Studio will notify customers of delay in service and provide updates on Niche Studio’s status page.

Software Development Process¶

Overview¶

Software development at Niche Studio follows a release strategy that provides traceability for production software changes. Features, enhancements, and bugs are written up as Issues in Notion. An engineer on a small team proposes changes necessary and creates a review for the team (Bitbucket, Github). Continuous integration (Bitbucket Pipelines, Github Actions) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: git-flow, github flow.

Niche Studio practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (using technologies such as Ansible) and managed under source control.

Niche Studio’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change – typically captured as part of the issue description/writeup).

Deployments to production are gated by change control process where an issue is opened which identify what is new/changed (Notion). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes. This process keeps the set of differences between the development environment and the production environment as low as possible.

In the continuous delivery mindset, features are not released by the deployment of code into production, instead features are enabled in production at the appropriate time (dark launching). Feature toggle enablement in production is gated by a change control ticket (Notion) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.

Development Environment Architecture¶

Local Development:

• Developers work on local machines with secure configurations
• Code repositories managed through Bitbucket, Github
• Local development databases isolated and secured
• Development tools and IDEs configured with security plugins

Staging Environment:

• Hosted on restricted cloud infrastructure
• Mirrors production environment configuration
• Client access provided for testing and approval
• Automated deployment from development branches

Production Environment:

• We use Binary Lane (NextDC Brisbane) and DigitalOcean for production hosting.
• Amazon SES is used for email sending and S3 occasionally for file delivery.
• We use bastion hosts and Tailscale VPN for administrative access; no direct SSH to production hosts.
• All changes deployed through automated processes

Secure Development Standards¶

Traceability of code changes allow for our software to be a living entity. Our current system for documenting changes is Notion. Every commit and/or Pull-Request, should have a Notion supplied that describes contextually why this change is necessary and reasonable. These artifacts over time allow for one to trace the lineage of why our production software and services change over time.

All Niche Studio git repositories have a company standard configuration from a Bitbucket, Github perspective. This standard is a guideline and can be relaxed, but socialize when those exceptions are needed. One example of an exception, is the wiki repository, as editing a wiki and always requiring a PR in this setting slows down ‘flow’.

• Code: <#>

• Repo settings: <#>

• Build: <#>

NOTE: The Sandbox project (and repos) do not follow this standard. And certain projects might be excluded (e.g. wiki).

Developers follow the branch strategy and code review process below:

1. All development uses feature branches based on the main branch used for the current release. Any changes required for a new feature or defect fix are committed to that feature branch.

   • These changes must be covered under 1) a unit test where possible, or 2) integration tests.
   • Integration tests are required if unit tests cannot reliably exercise all facets of the change.

2. Developers are strongly encouraged to follow the commit message conventions suggested by GitHub.

   • Commit messages should be wrapped to 72 characters.
   • Commit messages should be written in the present tense. This convention matches up with commit messages generated by commands like git merge and git revert.
   • Additionally, the commit messages should start with the Notion Issue ID when applicable.

3. Once the feature and corresponding tests are complete, a pull request (PR) will be created using the Bitbucket, Github web interface. The pull request should indicate which feature or defect is being addressed and should provide a high-level description of the changes made.

4. Code reviews are performed as part of the pull request procedure. Once a change is ready for review, the author(s) will notify other engineers using an appropriate mechanism, typically by adding reviewers as PR approvers.

   • Other engineers will review the changes, using the guidelines above.
   • Engineers should note all potential issues with the code; it is the responsibility of the author(s) to address those issues or explain why they are not applicable.
   • If changes/commits are made to a PR, it should reset previous approvals and require review and approvals again before the PR can be merged.
   • Once the review process finishes, each reviewer should approve the PR, at which point the original author(s) may merge their change into the main branch (i.e. master).
   • PR can only be merged with at least one approval from a reviewer other than the author.

5. If the feature or defect interacts with sensitive data, or controls access to sensitive data, or contains security/risky infrastructure changes to the target environment, the code changes must be reviewed by the Security team before the feature is marked as complete.

   • This review must include a security analysis for potential vulnerabilities such as those listed in the OWASP Top 10.
   • This review must also verify that any actions performed by authenticated users will generate appropriate audit log entries.

Release Strategy¶

Features, enhancements, and bugs are written up as issues (Notion). An engineer on a small team proposes changes necessary and creates a review for the team (Bitbucket, Github). Continuous integration (Bitbucket Pipelines, Github Actions) kicks off unit and functional tests which pass before changes are merged into the repository. Once the review is complete, the changes are now deployed to the development environment where regression and end-to-end tests are run before the new code replaces the existing in-service code (test then deploy model). Small teams can decide to follow a source-control branching strategy that makes sense: git-flow, github flow.

Niche Studio practices continuous delivery of code into production through multiple environments: development, testing, production. The deploy process and infrastructure roll-out are written as code (Terraform) and managed under source control.

Niche Studio’s multiple lower environments (dev, test) provide an ecosystem of sample data sets that can be used to exercise the application and services when test automation is run. The test environment is where the system is stressed for performance and scalability. Performance and scalability changes are driven by metric data captured through monitoring and logging (metrics before and after change - typically captured as part of the issue description/writeup).

Deployments to production are gated by change management process where an issue is opened which identify what is new/changed (Notion). Sign-offs are recorded by development, testing, security, and product management. Production roll-outs happen on a regular basis without impact to service. This continuous process allows for security updates to roll out regularly and with urgency. If there is impact to production, a rollback is performed to restore service and whatever caused the problem is reverted from source. This restarts the re-proposal approval process of source changes.

This process keeps set of differences between the development environment and the production environment as low as possible.

Features may be released via code deployments or features may be enabled in production at an appropriate time (dark launching). Feature toggle enablement in production is gated by the same change management ticket (Notion) that follows the software roll-out approval process. Feature toggle enablement in production can have a few more dependencies than code. Those dependencies include things like external documentation, early access programs, and internal playbooks for supporting the feature.

Automated Deployment (Trellis/Composer)¶

Trellis Framework:

• Ansible-based server provisioning and configuration
• Infrastructure as Code (IaC) approach
• Consistent server configurations across environments
• Automated security hardening and updates

Composer Integration:

• WordPress dependency management
• Automated plugin and theme updates
• Security vulnerability scanning
• Dependency conflict resolution

Deployment Process:

• Staging deployment for testing and client approval
• Production deployment only after approval
• Automated rollback capabilities
• Zero-downtime deployments where possible

Security Controls¶

Server Security:

• Ubuntu LTS with CIS Benchmark hardening
• Automated security updates via unattended-upgrades
• Fail2ban for intrusion prevention
• Cloudflare integration for DDoS protection

Network Security:

• Tailscale VPN for administrative access
• No external SSH access
• Firewall rules managed via Ansible
• SSL/TLS encryption for all connections

Access Management:

• Multi-factor authentication enforced
• Role-based access control
• Regular access reviews and updates
• Audit logging for all administrative actions

Client Data Protection¶

Data Handling:

• Client data isolated per project
• Encryption at rest and in transit
• Regular data backup and testing
• Secure data deletion procedures

Access Controls:

• Client access only to staging environments
• No production data access for clients
• Secure file transfer protocols
• All access logged and monitored

Privacy Compliance:

• Australian Privacy Act 1988 compliance
• Data sovereignty requirements met
• Client data processing agreements
• Regular privacy impact assessments

Detailed process and procedures for code promotion and production release: See Configuration and Change Management.