180 lines
5.9 KiB
Org Mode
180 lines
5.9 KiB
Org Mode
:PROPERTIES:
|
|
:ID: c60e01f9-9513-46f7-85f8-994f90989b2f
|
|
:END:
|
|
#+title: SX EOL Phase 1
|
|
#+Author: Yann Esposito
|
|
#+Date: [2024-04-02]
|
|
|
|
- tags :: [[id:91f33b35-6e4e-4213-b214-972ee20722df][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~:
|
|
|
|
#+begin_src clojure
|
|
:apps #{Application}
|
|
#+end_src
|
|
|
|
Where
|
|
|
|
#+begin_src clojure
|
|
(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
|
|
))
|
|
#+end_src
|
|
|
|
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)
|
|
|
|
#+begin_src clojure
|
|
(defn org-scopes-matrix
|
|
[org]
|
|
(condp contains? (:apps org)
|
|
#{:xdr} xdr-scopes-matrix
|
|
#{:sc} sc-scopes-matrix
|
|
#{:sx} sx-scopes-matrix
|
|
empty-scopes-matrix))
|
|
#+end_src
|
|
|
|
And then the user scopes will be provided with:
|
|
|
|
#+begin_src clojure
|
|
(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))))
|
|
#+end_src
|
|
|
|
*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:
|
|
|
|
#+begin_src clojure
|
|
(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))
|
|
#+end_src
|
|
|
|
*** 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
|
|
|
|
#+begin_src clojure
|
|
:before-sx-eol? (describe s/Bool "true before sx-eol false after.")
|
|
#+end_src
|
|
|
|
* Tasks
|
|
|
|
- [X] https://github.com/advthreat/iroh/pull/9175 Org Application
|
|
- [X] [[https://github.com/advthreat/iroh/pull/9192]] Org View with Apps
|
|
- [X] 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?
|