Access Management Policy

SOC 2 Criteria: CC6.2, CC6.3, CC6.4, CC6.5, P4.3

Keywords: Access, Least privilege principle, Least access principle, Role change, Access reviews

Background

Access to Bramble systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized use or access of the organization’s information systems. 

Purpose

The purpose of this procedure is to provide a policy and guideline for creating, modifying, or removing access to the company’s network and data by creating, changing or deleting the network account configuration for a User. Bramble access controls are guided by the principle of least privilege and need-to-know.

Scope

These controls apply to information and information processing systems at the application and operating system layers, including networks and network services.

The access request project is used to request and track the following access-related activities:

  1. New Access Requests
  2. Access Removal Requests
  3. Access Reviews
  4. New Service Account Requests

The Temporary Service Providers Lifecycle Management project is used for requesting and tracking all short-term non Bramble team member (consultant, vendor, contractor, etc.) access:

  1. Vendor Access Request

Usage guidelines for each of the access templates is outlined on the Team Member enablement’s handbook page.

These templates should be used during the onboarding process and throughout the employment tenure of a Brambler. Access required as part of the team member’s onboarding should be requested using the New Access Requests or if applicable, one of the available Role-based entitlements templates.

Roles & Responsibilities:

Bramble’s Security Officer is responsible for updating, reviewing, and maintaining this policy.

Access Establishment and Modification

Requests for access to Bramble Platform systems and applications are made formally using the following process:

  1. A Bramble workforce member initiates the access request by creating an Issue in the Bramble ticketing system.
    1. User identities must be verified prior to granting access to new accounts.
    2. Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
    3. For new accounts, the method used to verify the user’s identity must be recorded on the Issue.
  2. The Security Officer will grant or reject access to systems as dictated by the employee’s job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
  3. If the request is rejected, it goes back for further review and documentation.
  4. If the review is approved, the request is marked as “Done”, and any pertinent notes are added.

Access Reviews

All access to Bramble systems and services is reviewed and updated on an annual basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:

  1. The Security Officer initiates the review of user access by creating an Issue in the Bramble Ticketing System
  2. The Security Officer is assigned to review levels of access for each Bramble workforce member.
  3. If user access is found during review that is not in line with the least privilege principle, the Security Officer may modify user access and notify the user of access changes.
  4. Once the review is complete, the Security Officer then marks the ticket as “Done”, adding any pertinent notes required.

Workforce Clearance

  • The level of security assigned to a user to the organization’s information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user’s job classification.
  • All access requests are treated on a “least-access principle."
  • Bramble maintains a minimum necessary approach to access to Customer data.

Access Control Policy and Procedures

  • All new access or permissioning change requests that are not part of a team member’s baseline role-based entitlements will require a New Access Request.

  • Shared accounts may not be used for in order to comply with PCI-DSS requirements. Currently, Bramble’s financial controls prohibit the use of shared accounts within the following applications: Xero

  • Shared and group credentials are restricted. Any systems that require shared accounts or credentials and are not yet implemented or configured into G Suite must have an Access Request approved and an exception to this policy for each user. Bulk access requests are not allowed for shared or group credentials.

  • All access requests must be approved by the team member’s manager with the exception of:

    • ARs for Google Workspace email distribution lists for internal Bramble team members
    • ARs for Slack groups for internal Bramble team members
    • ARs using a role based template

    Please note that ARs for access to internal systems for “external to Bramble individuals” (eg. customers, prospects) require managerial approval. This includes access to Google Workspace security groups also require managerial approval.

  • Access requests are required when requesting a role above developer (i.e. maintainer, owner) on the following GitLab repositories and Groups:

  • Repos:

    • brmbl-io
    • infra
    • website
    • handbook
    • blog
  • Groups:

    • Bramble - top level group permissions
  • Access requests should be submitted when requesting explicit access to private groups, sub-groups, and repositories in order to facilitate deprovisioning.

  • Requests for access to Infrastructure assets (servers and databases) require a second layer of approval from Infrastructure Management.

  • All access requests must be provisioned as approved. An AR that is approved without a role specified should not be provisioned until the role being requested is identified and re-approved.

  • Administrative permissions should be considered operational in nature. This means that they are granted for the sole purpose of system management, configuration, and support. They should be recognized as privileged accounts and as such, activities must be logged and the logs protected and regularly reviewed.

  • Time-based access may be provided if administrative action is required for a set period of time. This should be documented as part of the Access Request SLAs.

  • All requests for new service accounts require a New Service Account Request

  • All requests for new service accounts must be approved by a member of Infrastructure Management.

  • In regard to support during or prior to provisioning, please do not tag the Security Operations team in the AR issue; to ask Security for help with AR assignments, please use the #it_help channel.

  • If admin-level access is being requested, the request must be approved by the team member’s manager and Infrastructure Management if applicable.

Role Based Access Control (RBAC) Requirements

Bramble has an established RBAC via the formalization and maintainence of Baseline Role-Based Entitlements. RBAC is subject to continuous control monitoring by the Security Compliance team to ensure that Bramble meets it’s regulatory and compliance obligations related to user access to information. Additionally, as noted per the requirements in the role baseline template, changes to permissions on these documents are required to be reviewed and approved by the Director or Senior Leader or Manager of the team that the role belongs to. If an update is proposed by a Manager or above, it should be reviewed by another, more senior manager of the team that role belongs too.

The structure of the baseline role-based entitlements ensures that team members receive the appropriate access privileges when they join Bramble. These templates are based off of one of the following:

  • A team member’s title (excluding levels, such as Junior, Senior, etc.), as listed in their HR employment profile
  • A combination of a team member’s title (excluding levels, such as Junior, Senior, etc.) listed in their Gusto employment profile AND their specific job specialty

Specific instructions for the creation, review, and maintenance of these templates can be found here. These instructions also include details on any nuances that should be considered as part of the creation of the template.

Access Control Process Exceptions

  • An access request is not required for Google Drive folders or files.
  • Managerial approval is not required when requesting access to:
    • ARs for Google Workspace email distribution lists for internal Bramble team members
    • ARs for Slack groups for internal Bramble team members
    • ARs using role based templates

Bulk Access Requests

  • Bulk access requests are those that are for multiple Bramble team-members. Bulk requests can be submitted for the following three types of requests:

    • Email aliases/forwarding in Google Workspace.
    • The adding of team members to Slack groups.
    • All Bramble team-members listed on the Access Request have the same manager and the same level of access is being requested.

    Please note that the above use cases do not apply to ADMIN-level access, which needs to be submitted using the one issue per Bramble team-member rule.

Access Requests and Onboarding

During the onboarding process, the manager should determine which email and slack groups the new team member should be added to. Also determine if new team member will need access to the dev server, which is used by engineers to prepare fixes for security issues . If so, request the creation of a new dev.brmbl.io account with the same email the team member has on GSuite and an invitation to the test account as an IC. Fill out one access request for both the groups and Dev account if needed.

Principle of Least Privilege

Bramble operates its access management under the principle of least privilege. Under least privilege, a team member should only be granted the minimum necessary access to perform their function. An access is considered necessary only when a Brambler cannot perform a function without that access. If an action can be performed without the requested access, it’s not considered necessary. Least privilege is important because it protects Bramble and its customers from unauthorized access and configuration changes and in the event of an account compromise by limiting access.

Least Privilege Reviews for Access Requests

  • A least privilege review should be performed by a system’s administrator and the manager of the team member for whom access is being requested. System administrators should be provided security training that includes specific training on least privilege and its application.
  • To perform a least privilege review, compare the rationale provided for the service(s) to which access is being requested with the level of access being requested.
    • Consider whether the access requested provides the team member access beyond what is required per the information provided in the rationale section of the access request.
  • If the access requested provides the team member only the access they require to perform what’s in the rationale section of the access request, the access request should be approved. In this case, simply proceed with approving the access request. An access request approval is considered confirmation the request has been reviewed for least privilege. Once your approval has been submitted, there’s no more action for you to take for the least privilege review.
  • If the access requested provides the team member access beyond what is required in the information provided in the rationale section of the access request, the request doesn’t align with the principle of least privilege and the request should be temporarily rejected until the appropriate access can be defined. To reject an access request on the basis of least privilege, respond to the issue with the following information:
    • Which service(s) are being requested excessive permissions.
    • A specific example of why the requested access is excessive. For example, a team member is requesting Super Admin access on Google Workspace only for provision user accounts, but the Super Admin role provides access far beyond just user account provisioning.
    • An alternative level of access and brief explanation how the new level of access allows the team member to fulfill their role. For example, a User Admin role on Google Workspace allows the team member to provision user accounts while not also providing all the other access a Super Admin role would. If no alternative can be given, the access request should be approved in the interest of the team member’s productivity.
  • Should there be disagreement on an access request rejection on the basis of least privilege, an exception request should be submitted. An exception request is important because it provides a clearly defined escalation process, promotes transparency, and allows us to appropriately track any deviations from policy.

Deprovisioning

  • In the case of a separation from the company, all access will be deprovisioned within 3 business days from the date on which the offboarding request is submitted unless otherwise specified.
  • All attempts will be made for individual access removal requests to be processed within the SLA requested. If no SLA is noted, access will be deprovisioned within 3 business days of the submission of the issue.
  • If access removal needs to occur immediately, please follow the panic email procedures, which will alert the Security Team on-call.

Job Transfers

  • An access review should be documented and performed as part of a formal job transfer. The review should be perfomed by the new manager of the team member who is transferring to a new role.
  • Upon notification of a reassignment or transfer, management reviews the Brambler’s access for appropriateness. Access that is no longer required is revoked and documented.

Access Reviews

  • Access reviews will be formally documented using the Access Reviews template.
    • The Security Operations team will periodically perform an access review of Bramble infrastructure accounts, to include a least privilege review.
    • The Internal Audit team will periodically perform an access review of financial application accounts, to include a least privilege review, as part of routine audits. A comprehensive access audit may be performed based on an annual risk assessment.
    • For source code security, access reviews for brmbl-io owners and maintainers will be performed quarterly by the Security Compliance team and verified by Infrastructure for appropriate permissions.
  • As part of an access review, existing access may be modified or revoked. New access (not modification of existing access) requires the submission of a New Access Request.
  • An access review includes two parts:
    • review current access and access level appropriateness, i.e. Does team member need access and are the system entitlements that they have appropriate?
    • recertification of appropriateness of access and entitlements, i.e. Approve continued access to system at the same level
  • Please note that access reviews should include a least privilege review. This is considered as part of the review of appropriateness of system entitlements, aka access level.
  • Review and recertification is generally performed by team member’s manager or someone above them in their reporting hierarchy. For example, review can be performed by a Director and include their direct reports' direct reports.
  • If reviewer is not the manager of team member, reviewer should be the system owner or the data owner, or an individual with sufficient understanding of the system(s), the system entitlements, and the ability to assess the appropriateness of the access granted.
  • Reviewers must never recertify their own access; this must be reviewed and recertified by an alternate system administrator, system owner, or the primary reviewer’s manager (or someone above them in their reporting hierarchy).
  • An access review should be documented and performed as part of a formal job transfer. This should be initiated by the team member transferring and their new manager.

Please refer to the Access reviews page for additional information.

Access Control Procedure Activities

Bramble’s access controls include the following control activities:

  1. user registration and de-registration
  2. user access provisioning
  3. removal of adjustment of user access rights
  4. management of privileged access rights
  5. management and use of secret authentication information
  6. review and recertification of user access rights
  7. secure log-on procedures
  8. management of passwords and tokens
  9. access to privileged utility programs
  10. access to program source code

Account Naming Conventions

  • app.brmbl.io Administrator Account Naming Convention:

  • Use user’s Bramble Google Workspace email +admin@brmbl.io as the email address: username+ADMIN@brmbl.io

  • brmbl.io admin account name should the user’s normal account with -admin appended: username-admin

  • The admin account “Full name” should include text to indicate it is an admin account: First Last (Admin)

  • brmbl.io Bot Account Naming Convention:

    • Use email for the group who owned the bot +[TASK NAME]-bot@brmbl.io as the email address: GROUP+TASK-BOT@brmbl.io
    • brmbl.io bot account name should start with gitlab and append with the task name and -bot: gitlab-task-bot
    • The bot account “Full name” should include text to indicate it is an bot account: First Last (Bot)
  • Temporary Contractor Account Naming Convention: username-CTR@brmbl.io

Group Membership Reports for Managers

If you would like to check whether or not a team-member is a member of a Slack or a Google Workspace group, you can view the following group membership reports:

Google Workspace Group Membership Reports

Slack Group Membership Reports

Unique Account Identifiers

Every service and application must use unique identifiers for user accounts and prevent the re-use of those identifiers.

For example, if a user account is identified with a username, there can only be one account with that username. Accounts may eventually be deleted and that username (or other unique identifier) intentionally released for re-use, but that new account may not have the same permissions or access as the first account that was deleted. This doesn’t preclude the use of shared accounts (except where it is strictly forbidden, like in-scope PCI systems) and applies to both individual and shared accounts. If a shared account is used, that account must have a unique identifier in the same way an individual, non-shared account does.

This is required to allow the actions of any given account to be associated back with that particular account. If two accounts share an identifier, if a malicious action were taken, we’d have no way of identifying which of the two accounts performed that malicious action. It’s also important to preserve the confidentiality of information; if access or permission are given to an account, they should only be given to the specific account for which they were intended.

Automatic Logoff

  • Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).

Employee Workstation Use

All workstations at Bramble are company owned, and all are laptop products running Mac OSX or Linux.

  • Workstations may not be used to engage in any activity that is illegal or is in violation of organization’s policies.
  • Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or “X-rated”. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual’s race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through the organization’s system.
  • Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization’s best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
  • Solicitation of non-company business, or any use of organization’s information systems/applications for personal gain is prohibited.
  • Users may not misrepresent, obscure, suppress, or replace another user’s identity in transmitted or stored messages.
  • Workstation hard drives must be encrypted
  • All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.

Exceptions

Exceptions to this procedure will be tracked as per the Information Security Policy Exception Management Process.

References