Information Technology

• 1: Change Management
• 2: Disaster Recovery Policy
• 3: MacOS Software Management Using Munki and Autopkg
• 4: Using Bitwarden to manage passwords

1 - Change Management

Purpose

The purpose of this policy is to establish a streamlined change management control process that ensures all changes to major systems are effectively managed, minimising risk and ensuring system stability. This policy is supported by our continuous integration and continuous delivery (CI/CD) approach.

Scope

This policy applies to all team members involved in the development, testing, deployment, and maintenance of major systems within the organisation.

Roles & Responsibilities

Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.

Policy Statements, Standard, or Procedure

All changes to major systems must follow the procedures outlined below to ensure proper risk assessment, testing, authorisation, and control.

Change Proposal

• Documentation: Changes must be documented in our version control system (Github) with a clear description, rationale, and expected impact; this will generally be a pull request.
• Risk Assessment: The developer proposing the change must assess the risk level (low, medium, high) based on potential impact; this will usually be done in the pull request as a tag.
• Impact on Confidentiality, Integrity, and Availability: The developer must consider the impact of the change on the confidentiality, integrity, and availability of the system. See our Information Security Policy for more information.

Risk Review

• Second Developer Review: A second developer shall review the proposed change and risk assessment.
• Stakeholder Involvement: For medium or high-risk changes, additional stakeholders should be consulted, including consideration for time to deploy, potential impact, and rollback plan. This includes stakeholders internal to Vaxa, as well as any suppliers.

Testing

• Environment: All changes must be tested in a staging or test environment.
• Automated Tests: Ensure all automated tests pass before deployment, and that coverage is sufficient in the CI/CD pipeline.
• QA Verification: Relevant QA resources (including business takeholders) should conduct additional testing as needed.

Authorisation

• Approval: The second developer must approve all changes before deployment to production if a low-risk change, or if a medium or high-risk change, the CTO must approve.
• Documentation: Approval is documented in the version control system.

Deployment

• CI/CD Pipeline: Changes should deployed via the CI/CD pipeline where possible, but may be deployed manually where required.
• Scheduling: Consideration should be given to deployment timelines and potential impact on users; deployments in-hours is permissible if the risk mitigation plan is sufficient.

Rollback Plans

• Rollback Plan: A rollback plan must be documented for each change.
• Automated Rollback: The CI/CD pipeline should support automated rollback to the previous stable version, or a manual rollback plan should be documented.
• Initiation: The CTO can initiate a rollback in case of post-deployment issues.
• Incident Management: If a rollback is required, the incident management process should be followed.

Change Control Record Keeping

All changes, approvals, test results, and deployment logs are stored in version control for audit purposes. This are retained in line with our Data Retention Policy.

Exceptions

• Urgent Changes: In critical situations (e.g., emergency fixes), the standard procedure may be expedited. This shall be documented in the ticketing system, including rationale and any additional risks.

Compliance & Monitoring

• Periodic Reviews: The team lead will periodically review change records to ensure compliance.
• Team Meetings: Deviations from the policy will be discussed to prevent future occurrences.
• Automated Enforcement: Tools may be used to enforce aspects of the policy (e.g., requiring approvals before merge in Github), alongside our access control policy ensuring only authorised personnel can deploy.

References

• Information Security Policy
• Cloud Security Policy
• Secure Development Policy
• Data Retention Policy

2 - Disaster Recovery Policy

Purpose

Overview of why the controlled document is being implemented.

Scope

Who or what does the controlled document apply to.

Roles & Responsibilities

Who is responsible for doing what. This should refer to departments or roles instead of specific individuals.

Policy Statements, Standard, or Procedure

The details! Detail the specific policy, procedure, or process. This section can include step-by-step instructions or rules that must be followed.

Exceptions

Define how exceptions to the controlled document will be tracked.

Compliance & Monitoring

Define how compliance with the controlled document will be monitored and what checks will be performed (where applicable).

References

Procedure documents should map back to a governing policy or standard, and may relate to one or more procedures or other uncontrolled documentation. Policy documents may relate to an internal or external framework or legal requirement.

3 - MacOS Software Management Using Munki and Autopkg

This document provides a detailed overview of our Munki and Autopkg setup, which is used to manage software installations and updates across our organisation. It is designed to cover most things, from the basics for non-technical users to in-depth technical details for our administrators and contributors.

Introduction to Munki and Autopkg (For Non-Technical Users)

Imagine you have many computers in an organisation, and you need to install and keep software updated on all of them. Doing this manually would be very time-consuming and prone to errors. This is where Munki and Autopkg come in.

Munki is like an app store for our organisation’s computers, but it works in the background. It automatically installs new software, updates existing software, and even removes software when needed, all without requiring constant manual intervention. Think of it as an automated software delivery system that ensures everyone has the right tools and the latest versions.

Autopkg is a tool that works with Munki to make software management even easier. Autopkg automates the process of finding new versions of software, downloading them, and preparing them for Munki to install. It’s like a helper that constantly searches for updates so we don’t have to do it manually.

Why are Munki and Autopkg important?

• Consistency: They ensure everyone in the organisation is using the same versions of software, reducing compatibility issues and making troubleshooting easier.
• Security: Keeping software updated is crucial for security. Munki and Autopkg help us quickly deploy security updates to protect our systems, as required by our compliance frameworks e.g. Essential Eight.
• Efficiency: Automating software management saves a significant amount of time and effort, allowing our technical teams to focus on other important tasks.
• Reliability: Automated processes are less prone to human error, ensuring software deployments are reliable and consistent.

In short, Munki and Autopkg are essential tools that help us manage software efficiently, securely, and consistently across our organisation, ensuring everyone has the tools they need to work effectively.

Getting Started with Munki and Autopkg (Technical Focus)

For those involved in managing or contributing to our Munki and Autopkg setup, understanding the basic workflow and tools is essential.

Prerequisites

• Munki Client: The Munki client must be installed on all target macOS machines. This is typically handled as part of the standard macOS deployment process.
• Autopkg Installation: Autopkg needs to be installed on a designated machine used for managing recipes and running autopkg. Installation instructions can be found on the Autopkg GitHub page.
• Recipe Repositories: Autopkg relies on recipes to know how to download, process, and import software into Munki. We utilise several recipe repositories, primarily:
  • autopkg/recipes: The main repository containing a wide range of common software recipes.
  • vaxa-tech/autopkg-recipes: Our internal repository of recipes.
  • A mixture of other sources as required.
• Munki Repository: A shared repository where our Munki clients (workstations) download software packages and package information. Our repository is located in our Azure DevOps instance, specifically in the vaxa/vaxa-security/munki repository. This repository is then synced to Azure Blob Storage, and access from a workstation is facilitated via a Shared Access Token (downloaded via Intune) and middleware_azure.py.
• Azure DevOps Access: Access to our Azure DevOps organisation is required for contributing and approving package updates.

Initial Setup

Refer to each of the repositories for detailed setup instructions:

• vaxa-security/munki: here
• vaxa-tech/autopkg: here
• vaxa-tech/autopkg-recipes: here

Infrastructure

Our Munki and Autopkg infrastructure is designed for reliability, scalability, and automation.

Munki Repository Location

The Munki repository is hosted on Azure Blob Storage. This location was chosen because it integrates nicely with our Microsoft stack, and additionally has a lower cost for storing large files versus GitHub’s LFS (where we originally hosted Munki).

Autopkg Automation

Autopkg runs are automated using Azure DevOps Pipelines. We use Azure DevOps Pipelines to:

• Regularly run Autopkg: Autopkg is scheduled to run daily to check for updates to managed software.
• Process Recipes: Autopkg processes recipes to download new software versions, create Munki packages, and import them into the Munki repository.
• Generate Catalogs: After importing new or updated packages, Autopkg generates Munki catalogs to make the software available to clients.
• Trigger Azure DevOps Pipelines: For certain critical packages or workflows, Autopkg may trigger Azure DevOps pipelines for further automated testing or approval processes.

Azure DevOps Integration

We leverage Azure DevOps for:

• Recipe Management: Our custom recipes and overrides are stored and version-controlled in Azure DevOps repositories.
• Pull Request Workflow: Contributions and updates to recipes are managed through pull requests, ensuring code review and quality control.
• Automated Testing (Future): We plan to integrate automated testing into our Azure DevOps pipelines to further validate package updates before deployment.
• Approval Process: Pull requests for recipe changes require approval from designated team members before being merged and deployed.

Contributing New Packages

To contribute a new package to our Munki setup, follow these steps:

1. Identify a Recipe: Search existing recipe repositories to see if a recipe for the desired software already exists.
   • If a recipe exists, consider if it meets our needs and if an override is sufficient (see “Updating Packages” section).
   • If no recipe exists or existing recipes are unsuitable, you will need to create a new one.
2. Create a Recipe (If Necessary):
   • Recipe Type: Determine the appropriate recipe type (e.g., pkg, dmg, app).
   • Recipe Structure: Follow the standard Autopkg recipe structure, defining processors for downloading, extracting, packaging, and importing the software into Munki. Refer to existing recipes for examples.
   • Testing: Thoroughly test your recipe locally to ensure it correctly downloads, packages, and imports the software into your local Munki repository. Use autopkg run -v <YourRecipe.recipe> for verbose output and debugging.
3. Create an Override (Recommended): Instead of directly modifying recipes in the main repositories, create an override recipe in the autopkg/overrides directory. This allows us to customise recipes for our environment without affecting the base recipes. This is still secure because only the original base recipe is trusted; any changes to the base recipe will require manual review. Most of the time, you’ll want to change the catalogs in the override to release (until we get autopromote working).
4. Test the Override: Run your override recipe to ensure it works as expected: autopkg run -v <YourOverride.munki.recipe>.
5. Submit a Pull Request:
   • Commit your new recipe or override to a feature branch in your local Git repository.
   • Push your branch to our Azure DevOps repository.
   • Create a pull request targeting the main branch, clearly describing the new package and any relevant details.
6. Code Review and Approval: Your pull request will be reviewed by designated team members. Address any feedback and make necessary changes. Once approved, your pull request will be merged.
7. Automated Deployment: After merging, the automated Autopkg process will pick up the new recipe/override and begin managing the software package in our Munki environment.

Updating Packages

Updating existing packages is crucial for security and ensuring users have the latest features.

1. Autopkg Monitoring: Our automated Autopkg system regularly checks for updates to managed software based on the recipes and overrides.
2. Recipe Updates: When a new version of software is detected, Autopkg will:
   • Download the new version.
   • Create a new Munki package.
   • Import the package into the import catalog in our Munki repository.
3. Testing and Validation: Packages are initially imported into the import catalog for testing.
   • Testing Catalog: We have a testing Munki catalog for deploying updates to a subset of test machines.
   • Prerelease Catalog: Optionally, a prerelease catalog can be used for even earlier testing phases.
4. Catalog Promotion: After successful testing in the testing catalog, packages can be promoted to the release catalog to be deployed to all managed machines. Catalog promotion is typically done by:
   • Manual Promotion (Initial): Initially, catalog promotion may be a manual step performed by administrators after verifying the updated package.
   • Automated Promotion (Future): We aim to implement automated catalog promotion based on successful testing and approval workflows in Azure DevOps.
5. Override Adjustments: In some cases, updates may require adjustments to our override recipes. For example, if a software vendor changes the download URL or package format, we may need to modify the recipe’s Input variables or processors. These changes should be made via pull requests as described in the “Contributing New Packages” section.

Approving Pull Requests in Azure DevOps

The pull request workflow in Azure DevOps is essential for maintaining the quality and stability of our Munki and Autopkg setup.

1. Notification: When a pull request is created for recipe changes, designated team members will receive notifications in Azure DevOps.
2. Code Review: Reviewers should carefully examine the pull request, focusing on:
   • Recipe Logic: Verify the recipe logic is correct and efficient.
   • Security: Ensure the recipe downloads software from trusted sources and does not introduce security vulnerabilities.
   • Munki Integration: Confirm the recipe correctly imports packages into Munki with appropriate catalogs and pkginfo settings.
   • Testing: Check if the contributor has adequately tested the recipe.
3. Feedback and Discussion: Provide clear and constructive feedback to the contributor directly in the pull request. Engage in discussions to clarify any questions or suggest improvements.
4. Approval: Once the pull request meets the required standards and all concerns have been addressed, reviewers can approve the pull request in Azure DevOps.
5. Merge: After approval, the pull request can be merged into the main branch. This action triggers the automated deployment process, making the changes live in our Munki environment.

Relevant Information

• Icon Management: Icons for software packages are stored in the munki/icons directory. Ensure new packages have appropriate icons for a better user experience in Self Service (if used).
• Manifests: Munki manifests (munki/manifests) define which software packages are installed on different groups of machines. The site_default manifest is the primary manifest applied to most machines. Create or modify manifests as needed to customise software deployments for specific departments or user groups.
• Pkginfo Files: Pkginfo files (munki/pkgsinfo) contain metadata about each software package, such as name, version, description, and dependencies. Autopkg automatically generates pkginfo files based on recipes. Review and customise pkginfo files as needed for specific requirements.
• Troubleshooting: For troubleshooting Autopkg or Munki issues, consult the official documentation for Autopkg and Munki. Check log files for errors and use verbose output (-v flag) when running Autopkg commands for debugging.

This document provides a comprehensive guide to our Munki and Autopkg setup. By following these guidelines and procedures, we can ensure efficient, consistent, and secure software management across our organisation.

4 - Using Bitwarden to manage passwords

This guide explains how to use Bitwarden, Vaxa’s password manager, to securely store and manage passwords. Whether you’re new to password managers or already familiar with them, this guide will help you get the most out of Bitwarden while keeping your credentials secure.

Introduction to password managers

If you’ve never used a password manager before, think of it as a secure digital vault for all your passwords. Just as you might use a safe to store important documents, a password manager securely stores all your passwords in one encrypted location.

Why do we need password managers?

Most people struggle to remember unique, strong passwords for every website and application they use. This leads to common security problems:

• Password reuse: Using the same password across multiple sites means if one site is compromised, all your accounts using that password are at risk.
• Weak passwords: Passwords that are easy to remember (like “Password123” or your pet’s name) are also easy for attackers to guess.
• Written passwords: Writing passwords on sticky notes or in unencrypted documents creates security risks.
• Password fatigue: The mental burden of managing dozens or hundreds of unique passwords is overwhelming.

How does Bitwarden solve these problems?

• One master password: You only need to remember one strong master password to access all your other passwords.
• Strong, unique passwords: Bitwarden can generate long, random, unique passwords for every account, making them virtually impossible to guess or crack.
• Encrypted storage: All your passwords are encrypted with industry-standard encryption, protecting them even if someone gains access to Bitwarden’s servers.
• Cross-device sync: Access your passwords on your computer, phone, and tablet—they’re always available when you need them.
• Convenient auto-fill: Browser extensions and mobile apps can automatically fill in your credentials, saving time and reducing typing errors.

In essence, Bitwarden makes it easy to follow security best practices without adding complexity to your daily workflow. It’s an essential tool for protecting both our organisation’s security and your personal digital security.

Getting Started with Bitwarden

Accessing Your Work Bitwarden Account

Your Bitwarden account will be set up as part of your onboarding process. You’ll receive a Bitwarden login email.

This email will be delivered to your Vaxa email address. Follow the steps to setup your account and set a secure master password and two-factor authentication (2FA).

Setting your master password

Your master password is the key to your entire password vault, so it needs to be:

• Strong: Ideally at least 12-16 characters long, combining letters, numbers, and symbols.
• Memorable: You’ll need to remember this password, assume it cannot be reset if forgotten.
• Unique: Don’t use this password anywhere else.

Tip: Consider using a passphrase—a series of random words strung together (e.g., “correct-horse-battery-staple-mountain-7”). Passphrases are both strong and easier to remember than random character strings.

Installing Bitwarden

Bitwarden is available on multiple platforms:

• Browser extensions: Available for Chrome, Firefox, Safari, Edge, and other major browsers. This is the most convenient way to use Bitwarden day-to-day. We pre-install this in our preferred browser, Edge, so you just need to log in.
• Desktop Apps: Native applications for Windows, macOS, and Linux. In macOS, this is available in your Managed Software Centre, if not already installed by default.
• Mobile Apps: Apps for iOS and Android.
• Web Vault: Accessible at https://vault.bitwarden.com from any browser.

We recommend using the browser extension on your work computer as your primary method of accessing Bitwarden.

Basic navigation

Once logged in, you’ll see:

• My Vault: Your personal password storage area.
• Collections: Shared password collections for client work (more on this below).
• Password Generator: Tool for creating strong, random passwords.
• Settings: Account configuration, security settings, and preferences.

Using Bitwarden for work

Storing Your personal work passwords

Your personal work passwords should be stored in “My Vault”. These include:

• Your email account password
• Work applications and software
• Internal systems and tools
• Any other credentials that are unique to you

To add a new password:

1. Click the “+” button or “Add Item”
2. Select “Login” as the item type
3. Enter the name of the service, username, and password
4. You can also save the 2FA information here too, by getting the authenticator secret for the login and adding it to the “Authenticator Key” field (or you can use the ‘camera’ icon to scan a QR code if it’s on your screen).
5. Click “Save”

Tip: Use Bitwarden’s password generator when creating new passwords. Click the generate icon (⟳) in the password field to create a strong, random password.

Using client collections

Collections are shared vaults where teams can store and access passwords related to specific clients. This is essential for collaborative work where multiple team members need access to client systems.

What belongs in client collections?

• Client website and CMS credentials
• Client application logins
• Client service account credentials
• Shared access to client tools and platforms

What should NOT be in client collections?

• Your personal work passwords
• Client credentials that only you should access i.e. unique to you.
• Personal passwords unrelated to work

Accessing a client collection:

1. Navigate to the “Collections” section in Bitwarden
2. Click on the relevant client collection
3. You’ll see all passwords shared within that collection
4. Click on any item to view or copy credentials

Adding passwords to a collection:

1. Create a new item or edit an existing one
2. In the “Collections” section at the bottom, check the box for the relevant client collection
3. Save the item

Your collection permissions are managed by the client owner. If you need access to a collection that isn’t visible to you, contact your manager or the client owner.

Auto-Fill and using credentials

When you visit a website stored in your Bitwarden vault:

1. Click the Bitwarden extension icon in your browser
2. Find the matching login entry
3. Click it to auto-fill your credentials
4. Or use the keyboard shortcut (usually Cmd/Ctrl + Shift + L)

The browser extension will also offer to save new credentials when you log into a site that’s not yet in your vault.

Personal Bitwarden (free benefit)

As a Vaxa staff member, you receive a sponsored Bitwarden Families organisation as an employee benefit. This allows you to securely manage your personal passwords and share them with up to 5 friends or family members. We strongly encourage you to use this for your personal security—it helps keep your work and personal lives separate and secure.

Why separate work and personal passwords?

• Security boundaries: Keeps work and personal credentials separate, reducing risk if one is compromised. Vaxa has no access to your personal/family accounts—it’s completely private.
• Privacy: Your personal passwords remain private and under your control.
• Continuity: If you leave the organisation, you retain access to your personal Bitwarden account (though you may need to start paying for the subscription if you want to keep the Families features).

Vaxa has no visibility into your personal Bitwarden account or the passwords stored within it.

What to store in your personal Bitwarden:

• Banking and financial accounts
• Social media accounts
• Personal email accounts
• Shopping and subscription services
• Personal documents and secure notes
• Any other non-work-related credentials

What’s included in your sponsored Families organisation?

The sponsored Families plan includes premium Bitwarden features for all your users:

• Unlimited password storage and sync across all devices
• Advanced two-factor authentication (2FA) methods
• Encrypted file attachments
• Emergency access
• Secure password sharing within your family group
• 1 GB of encrypted storage (additional storage available for purchase)

Redeeming your sponsored Families organisation

Your personal Bitwarden Families organisation is completely separate from your work account—you’ll need a different master password and email address (your personal email) to set it up.

To redeem your free Families organisation:

1. Log in to your work Bitwarden account at https://vault.bitwarden.com
2. Navigate to Settings → Free Bitwarden Families
3. Enter your personal email address (not your work email)
4. Select Redeem
5. Check your personal email inbox for an invitation from Bitwarden
6. Follow the link in the email to accept the offer
7. Either log in with your existing personal Bitwarden account or create a new one
8. Complete the setup by naming your new Families organisation

Important notes:

• If you already have a personal Bitwarden account, use that email address when redeeming
• If you don’t have a personal account yet, you’ll create one during the redemption process
• Your personal Bitwarden Families organisation must be accessed at https://vault.bitwarden.com (the same URL as your work account, but using your personal email to log in)
• You can easily switch between your work and personal accounts using Bitwarden’s account switching feature
• As long as you’re employed at Vaxa, your Families organisation is completely free
• You should follow the same good security practices outlined in this guide when using your personal Bitwarden account

For detailed step-by-step instructions and troubleshooting, see the official Bitwarden guide on redeeming Families sponsorships.

Best practices

Creating strong passwords

When using Bitwarden’s password generator, we recommend:

• Minimum 16 characters for high-security accounts (email, banking, admin accounts)
• Minimum 12 characters for standard accounts
• Include uppercase, lowercase, numbers, and symbols
• Avoid dictionary words or personal information

When to share passwords vs. when not to

Share passwords via collections when:

• Multiple team members need access to the same client resource
• You’re collaborating on a project requiring shared credentials
• You need to provide temporary access to a colleague

DON’T share passwords when:

• They’re your personal work credentials
• The system supports individual user accounts (create separate accounts instead)
• Sharing would violate client agreements or security policies
• You’re unsure—ask your manager or IT first

Never share via:

• Email, Slack, or other messaging systems
• Unencrypted documents or spreadsheets
• Verbal communication in public spaces
• Screenshots or photos

Refer to our Information Security Policy for more details on our approach to information security.

Keeping Bitwarden Updated

Ensure you’re running the latest version of Bitwarden:

• Browser extensions typically update automatically
• Check for desktop and mobile app updates regularly
• Security updates are critical—install them promptly

Generally, on work devices, updates will be pushed to your device but you should be sure to accept and install them when prompted.

Getting Help

If you encounter issues with Bitwarden or have questions about password management:

• IT Support: For technical issues, account access, or collection permissions
• Information Security Group: For security-related questions or concerns
• Bitwarden Documentation: https://bitwarden.com/help/ for detailed guides

Remember, using Bitwarden correctly is one of the most impactful security practices you can adopt—both for protecting our organisation and for your personal digital security. If you’re ever unsure about how to handle a password or credential, ask for help rather than taking a shortcut that could compromise security.