deft/notes/sx_eol_phase_1.org

SX EOL Phase 1

• Epic SecureX EOL Phase 1
  • Functional Specification
  • Technical Specification
    • Org Applications
    • Org View update
    • Expose an API to manage app flags
    • Write a script to update (by batch) the app flag of an Org
    • Org Application => Scopes Matrix
    • Depending on XDR apps reduce the visible and allowed list of module-types
    • Secure Endpoint Provisioning
    • Add value in whoami to state we reached SX EOL
• Tasks
• Questions

tags

Cisco

aha

https://ciscosecurity.aha.io/epics/XDR-E-164?active_tab=related

jira

https://cisco-sbg.atlassian.net/browse/XDR-1523

Epic SecureX EOL Phase 1

Functional Specification

• Org Flag

  • XDR Orgs (as usual)

  • SC Orgs:

    • only two roles (admin and user)

    • authorizations:

      • manage clients
      • manage users (remove allow non-admin user section, should be checked by default)
      • manage devices
      • audit logs
      • profile
      • integrations (module-instances)
      • no incident activity
      • no incident investigation
      • no Automation workflow nor response action
  • SX-only Orgs (after EOL disabled)
• script to init Org flags
• create a new matrix Org-flags => role->scopes matrix
• reduce module-type
• provision script for SC-only orgs
• Check the org-view provided to Registration-UI to provide the applications flags

• Org switching

  • SC Interim UI shows only SC orgs
  • XDR UI only show XDR orgs
• Rebrand HTML Error pages (invitation, org join, account disabled, org disabled)
• SE should be able to provision new IROH Org for SC and Orbital

Technical Specification

Org Applications

Add the following field to the Org:

:apps #{Application}

Where

(s/defschema Application
  ;; use comment here because the name will change but the keywords will not
  ;; and it will be useful to remember why we used `sc` if Secure Client is renamed to something
  ;; else for example
  (s/enum :xdr ;; XDR
          :sx ;; SecureX to disappear after 31th of July
          :sc ;; Secure Client
          ))

Make this field visible. With the following rules:

• org is enabled and has cisco/feature-flag/xdr in the additional-flags => provide :xdr app
• org is enabled and does not have the XDR flag => gives :sx app
• org is disabled => apps is the empty set

Note there is no way to have the sc flag without admin intervention

Org View update

Add a field sc-enabled? similar to sx-enabled? and xdr-enabled? to the OrgView visible from the Profile API.

Expose an API to manage app flags

Along the feature-flag API, add a new route that can add/remove App flags. Decide who can use this API and how (script?).

Write a script to update (by batch) the app flag of an Org

This would probably be run once before SX EOL date to init the Orgs.

Org Application => Scopes Matrix

With the introduction of these flags, we will now have 4 specific orgs kind:

1. xdr org (contains :xdr, we do not care about :sc nor :sx)
2. sc org (does not contain :xdr, but contain :sc, we do not care about :sx presence)
3. sx-only org (does not contain :xdr nor sc, but contain :sx)
4. disabled org; when apps is empty, then we should disable the org (can use get-org in the Org service for that, and we might update the DB accordingly)

(defn org-scopes-matrix
  [org]
  (condp contains? (:apps org)
    #{:xdr} xdr-scopes-matrix
    #{:sc} sc-scopes-matrix
    #{:sx} sx-scopes-matrix
    empty-scopes-matrix))

And then the user scopes will be provided with:

(defn user-scopes
  [org user]
  (let [scopes-matrix (org-scopes-matrix org)]
    (scopula/scopes-union
     (scopes-from-role (:role user) scopes-matrix)
     (:additional-scopes org)
     (:additional-scopes user))))

NOTE:

• Have a test checking the XDR scopes matrix is a superset of the SC scopes matrix.
• SC scopes matrix is XDR without the scopes private-intel and ao and response:

Depending on XDR apps reduce the visible and allowed list of module-types

Change the list of available module-types for SC-only Orgs. The Org service will contain a method named org-main-app and the logic should be:

(defn available-modules
  [org entitlement-tier]
  (case (org-main-app org)
    :xdr (xdr-available-module-types entitlement-tier)
    :sc sc-available-module-types
    :sx sx-available-module-types
    nil))

Secure Endpoint Provisioning

Secure Endpoint already use the provisioning routes. But we need some work to:

1. Add the sc flag to these org
2. Support async onboarding as well
3. When sc only provision CSC and DI

Add value in whoami to state we reached SX EOL

:before-sx-eol? (describe s/Bool "true before sx-eol false after.")

Tasks

• https://github.com/advthreat/iroh/pull/9175 Org Application
• https://github.com/advthreat/iroh/pull/9192 Org View with Apps
• https://github.com/advthreat/iroh/pull/9195 API to manage app flags
• Write a script to batch update apps of orgs
• https://github.com/advthreat/iroh/pull/9247 Add a scopes-matrix per org apps

• PR that will change SX orgs to SC orgs after SX EOL date.

  • Create a service that manage deadlines dates (from the backend)
  • Exposes the dates managed by this service to the /whoami endpoint
  • Have an Admin API able to change the list of timers
  • Have SX orgs become SC orgs after sx-eol? deadline.
• Org Applications change visibility of modules

• Provisioning

  • Support adding the sc app
  • Support async onboarding (or keep non async endpoints conf)
  • When sc app, only provision CSC and DI

Questions

• What about downgrade?

  XDR orgs have more 3 roles SC orgs have 2 roles

  1. customer start with SC
  2. customer then buy XDR, set some user to SAT role (security analyst neither admin nor user)
  3. customer leave XDR, so get back to XDR Should the TAC role user be back to user? What if a new role has fewer scopes than SC user? changing their role will mean escalation of authorization, should we disable them?