5.9 KiB
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 theadditional-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:
- xdr org (contains :xdr, we do not care about :sc nor :sx)
- sc org (does not contain :xdr, but contain :sc, we do not care about :sx presence)
- sx-only org (does not contain :xdr nor sc, but contain :sx)
- 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
andao
andresponse
:
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:
- Add the
sc
flag to these org - Support async onboarding as well
- 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
- Support adding the
Questions
-
What about downgrade?
XDR orgs have more 3 roles SC orgs have 2 roles
- customer start with SC
- customer then buy XDR, set some user to SAT role (security analyst neither admin nor user)
- 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?