Security & Compliance

• 1: Selector Security and Compliance Posture
• 2: Selector Single Sign On

1 - Selector Security and Compliance Posture

Selector is highly invested in safeguarding client data and maintaining a robust security posture that meets and exceeds modern regulatory standards. We integrate a proactive “shift-left” approach by building security into the early stages of product planning.

Selector Security and Governance (Assurance)

Our security organization is led by tenured cybersecurity professionals, including a dedicated Chief Information Security Officer (CISO), who ensures policies remain current with regulatory and compliance needs.

Certifications and Audits

Selector demonstrates commitment to stringent industry standards through external, independent verification:

• SOC 2 Type 2 & ISO 27001 Certification: We engage an independent, third-party auditor (approved by the AICPA) to conduct comprehensive annual assessments of our SaaS infrastructure, development processes, and overall Information Security Management System (ISMS).
• Continuous Monitoring & Audit Coverage: We implement continuous monitoring across our enterprise and SaaS platform, conducting internal audits and periodic verification of our security controls.
• Vulnerability Management: We leverage a continuous vulnerability management framework, using tools like Trivy, Dependency Track and Snyk to generate and scan our Software Bill of Materials (SBOM), addressing potential vulnerabilities early in the development lifecycle.
• Annual Penetration Tests: Independent third-party experts conduct annual penetration tests on our code and infrastructure to proactively identify and remediate vulnerabilities, keeping us strong against evolving threats.

Access and Authentication Policies

We enforce strict controls over who can access our systems and how they authenticate.

• Role-Based Access Control (RBAC): The Selector platform supports RBAC to manage user privileges and groups, enforcing the Principle of Least Privilege to limit access to only necessary parts of the platform.
• Strong Authentication and SSO: Selector works with customers to configure Single Sign-On (SSO) using multiple identity providers, including Okta, Azure AD, Active Directory, Google, Ping ID, Generic OIDC, and SAML 2.0.
• No Backdoor/Local Dev Accounts in Production: Selector does not use backdoor accounts or hardcoded developer usernames and passwords in production systems. We do not maintain local user accounts on the platform’s underlying Operating System (OS).

Product and Customer-Facing Controls (Protection)

These security measures are implemented directly within the S2AP platform and its deployment model to protect customer environments and data.

Network and Instance Security

• Dedicated SaaS Tenancy: We provide a dedicated SaaS tenancy for each customer, ensuring effective isolation of data and infrastructure.
• Zero-Trust Network Model: We implement a Zero-Trust approach internally to limit access, and enforce network security via application and traditional firewalls and VPN-only access to our SaaS instances.
• Strict Access Control: Only allowed IP addresses and authenticated users have access to the hosted infrastructure. Cloud-based security tools continuously monitor user behavior and access to detect anomalies.
• Local VM Firewalling: Local firewalling is used on the Kubernetes services to ensure only desired traffic is permitted internally.
• On-Premise Guidance: For on-premises deployments, we work with customers to ensure correct external firewalling is configured and tested.

Data Protection and Privacy

Data Handling on S2AP features:

• Non-Retention of Sensitive Data: The S2AP platform does not retain any sensitive customer or user data such as MAC addresses, individual IP addresses, PII, PCI, or PHI. This ensures strict adherence to related compliance policies.
• Read-Only Client/Infrastructure Data: We maintain only client and infrastructure data in a read-only format to facilitate network performance monitoring for customers.
• Secure Code Practices: We perform continuous automated scans of our code base and leverage security tooling to review libraries for vulnerabilities, actively preventing accidental leaks of sensitive information.

Endpoint and Malware Protection

• Advanced Threat Detection: We use advanced threat detection and prevention features for our S2AP SaaS platform leveraging Cloud Service Provider capabilities.
• Endpoint Detection and Response (EDR): Effective EDR tools secure our on-premises and mobile devices, monitoring files and applications in real-time to instantly block and quarantine threats.
• Device Compliance: Our solution checks every laptop accessing our network to ensure antivirus and anti-malware software (like XProtect, Windows Defender, and Gatekeeper) is active.
• Email Security: Strong email filtering and quarantine capabilities utilize content-based, heuristic, and Bayesian filtering, to perform real-time scans to isolate suspected spam and harmful messages.

Patching, Resilience, and Incident Management (Operations)

Patch Management

Selector implements a comprehensive, automated patch management strategy across all assets:

• SaaS Infrastructure: We leverage the native automated patching service provided by our Cloud Service Provider (GCP) for centralized control over Linux and Windows systems.
• Enterprise and Endpoints: For our internal enterprise assets (Macintosh and Windows laptops), we automate patching using vendor-provided tools, with continuous monitoring from EDR solutions to verify effectiveness.
• Client-Premise Solutions: For Selector-managed SaaS solutions deployed on client premises, we provide risk-adjusted management solutions that ensure security and compliance proportional to the solution’s impact.
• Vulnerability Remediation: Vulnerabilities identified through our scanning tools are prioritized based on criticality and impact, with patching deployed efficiently via an automated process.

Backup and Business Continuity

We utilize cloud provider capabilities to ensure service resiliency and swift recovery:

• SaaS Backup and Redundancy: Our SaaS solution leverages Google Cloud’s infrastructure for real-time data replication, automated backups, redundancy, and global reach to protect customer data.
• Disaster Recovery (DR) Drills: We run annual drills to test our disaster recovery plans and ensure our team can effectively manage a disruption.
• On-Premise Guidance: For on-premises solutions, we guide customers on best practices for backups, system redundancy, and disaster recovery tailored to their specific setups.

Incident Response and Recovery

Selector maintains a well-defined Incident Response and Recovery (IRR) plan to minimize downtime and ensure transparency:

• Proactive Team: The Incident Response Team has clearly defined roles and conducts regular exercises (for example, simulated phishing and ransomware).
• Response Process: As soon as an issue is detected, the Site Reliability Team (SRE) assesses the situation and coordinates remediation.
• Communication: Our Business Continuity Plan (BCP) emphasizes clear and timely communication, providing regular, transparent updates to all involved stakeholders throughout the incident lifecycle.
• Post-Incident Review: After service is restored, a review is conducted to learn lessons and improve future processes.

2 - Selector Single Sign On

Overview

Single Sign-On (SSO) is an authentication scheme that allows a user to log in with a single set of credentials to any of several related, yet independent, software systems.

SSO is critical for enterprise security and user experience. It centralizes identity management, allows for automated onboarding/offboarding via a central Identity Provider (IdP), and eliminates “password fatigue” by allowing users to access S2AP using their existing corporate credentials.

Selector’s SSO allows customers to integrate the user roles defined in their IdP with S2AP roles to provide right sized access to their users.

SSO Integration Setup

Selector supports SSO configuration in S2AP UI and API. Selector customers who wish to set up SSO for S2AP login and access need to follow the following steps in their S2AP portal.

First, go to Integrations on the left hand side panel, and select Identity provider.

SSO Provider Type

Next, select Provider Type from the identity provider list. Selector supports several types of SSO, including popular providers such as Okta, Google, Microsoft Entra, and Ping. Selector SSO works with any vendor that supports the generic OpenID Connect (OIDC) standard with JSON Web Tokens (JWT).

SSO Setup

In the Setup window, customers need to provide three OIDC metadata items to set up an SSO OIDC integration.

1. Client ID: A unique, public identifier for the S2AP application within your Identity Provider. This ID tells the IdP which application is requesting the login.
2. Client Secret: A confidential “password” known only to S2AP and the IdP. The secret is used to verify the application’s identity when exchanging authentication codes for tokens.
3. Discovery URL or Manual Endpoint Setup:
   • The Discovery URL is the URL the client uses to discover OAuth 2.0 endpoints and configuration information. This is typically the Issuer URL with the phrase “.well-known/openid-configuration” appended.
     • if the “Use discovery endpoint” option is selected, then S2AP can usually derive the discovery URL based on the OIDC provider and authentication information.
     • For example, Microsoft calls this endpoint the OpenID Connect metadata document: https://login.microsoftonline.com/.../v2.0/.well-known/openid-configuration

The Redirect URI is provided to the Customer by Selector. After successful authentication, this URI forms the specific URL where the user is sent by the IdP. This redirect is automatically generated by the S2AP backend using Keycloak and is presented as a read-only field in the GUI.

There are also several security options. The Proof Key for Code Exchange (PKCE) is an extension to OIDC that prevents authorization code interception attacks. PKCE adds an extra layer of security by requiring a dynamically generated “secret” for every login attempt. Customers can select that option if they use PKCE security for SSO.

SSO Attribute Mappers

The Attribute Mappers window allows mapping of attributes like firstName, lastName, username, email, or other custom attributes that are found in the id_token claim. For Azure and Google, this step is often unnecessary because predefined mappers are added.

Selector maps first name, last name, email by default, so unless there is some custom mapping to be done, this screen can be skipped.

SSO Role Mapper

The Role Mappers window determines a user’s permissions in S2AP by mapping a user to a specific role in S2AP, based on group memberships in the IdP. For example, this could be the claims in the id_token.

To set up role mapping through SSO on S2AP, three things are needed:

• Claim (key): The name of the attribute (claim name), that contains the membership data. Example: groups (that a user is a member of), roles (that a user is granted).
• Value (value) : The specific value of the claim. For example, group name or group id.
• S2AP Role: The permission level to grant the user for access to S2AP resources (such as Admin, Regular, Read Only, or Custom).

The customer needs to provide Claim and Value to Selector so they can be mapped to appropriate roles on S2AP.

In addition, a Default Role can be set.

NOTE: Permissions are additive to the other role mappings that are specified, not a fallback. If a user belongs to multiple mapped groups, they receive the combined permissions of all those roles.

Example 1

  Claim key: groups

Claim Value: okta_admin, okta_noc1, okta_noc2, okta_noc3

Mapping (Okta role to S2AP role):

• okta_admin => ADMIN
• okta_noc1 => REGULAR
• okta_noc2 => READONLY
• okta_noc3 => custom_role1

If the token includes groups such as okta_noc3, okta_noc2, and so on, then the user is mapped to the READONLY S2AP role custom_role1 and gets the superset of permissions.

Example 2

If the Default role is set to Regular in the S2AP Role mapper screen, then a user in the okta_noc2 group gets a super set of Readonly and Regular user permissions.

SSO Summary

The final window shows a Summary JSON listing of the entire SSO configuration. You should review it and then click Save or go back to make any necessary changes.

FAQs

1. My SSO is not working. I am unable to log into my S2AP with SSO

   1. Check if your IDP secret is still valid. If this secret has expired you will not be able to log in. Quick check you can do: if SSO is set up to another environment try logging into that, if you are able to, then it is likely a secret issue. Update the secret in the S2AP portal and you should be good to go -- an admin user should be able to do this. Or reach out to your Selector CS/SE representative to help.

2. I am able to log in via SSO but I am not getting the correct role assignments. There can be a few reasons for this:

   1. Did you have local account access prior to SSO? Selector persists the first login, so delete the local user account and login via SSO, the new SSO mapped role should kick in.
   2. If that doesn’t work, ensure that the SSO mapper is configured correctly.
      1. Claim Column should have the “Key” -- groups or roles are the typical keys
      2. If that is correct, make sure the Value is correct (as configured in your IDP). If that is missing, or incorrect, the mappings will not be correct.

3. What is the default role, how does it work?

   1. The default role is meant to provide “default “ fallback that is assigned to any users that don’t match the Claim value criteria configured. It is additive to all other permissions. Example 1, if `user@john.doe’ is part of a group that is assigned Admin permissions, and a default role of Readonly is configured in the S2AP, they will get the superset permissions of admin and readonly. You should see something this in the Users page:

      

      Example 2, if `user@john.doe’ is part of a group that is assigned custom_role_1 permissions, and a default role of custom_role_2 is configured in the S2AP, they will get the superset permissions of custom_role_1 and custom_role_2.

4. Should I use the Value field or the Secret ID field value of the Microsoft Entra Secrets page?

   1. Microsoft Entra displays two different IDs on the Secrets page. For the Selector SSO configuration, you must provide the secret Value. A common error is providing the Secret ID (the UUID); if your value looks like a standard 36-character GUID, it is likely the wrong field. Please make sure you copy the Value column before leaving the page.