deft/tracker.org

* 2023
** 2023-W26
*** 2023-06-29 Thursday
**** CANCELED Investigate invite bug                              :work:
SCHEDULED: <2023-07-03 Mon 11:00>
:LOGBOOK:
- State "CANCELED"   from "TODO"       [2023-07-11 Tue 10:51] \\
  Whatever
:END:
[2023-06-29 Thu 11:06]

https://github.com/advthreat/response/issues/1888

Deleted user-id c59db89d-212a-4a0c-92d0-ff1a2c7de25b
** 2023-W27
*** 2023-07-04 Tuesday
**** MEETING 1-1 Wanderson                                        :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-04 Tue 16:04]--[2023-07-04 Tue 16:33] =>  0:29
:END:
[2023-07-04 Tue 16:04]
***** Agenda (to discuss about)
- Provisioning
  - PIAM status
  - Orbital/Single SE status
- RBAC status
- offsite
***** Notes
***** Actions
- create a backlog of technical work to do
*** 2023-07-05 Wednesday
**** DONE Cleanup all "TO DELETE" entities                        :work:
SCHEDULED: <2023-07-28 Fri 11:00>
[2023-07-05 Wed 19:51]
*** 2023-07-06 Thursday
**** CANCELED Remove ability to create new Org                    :work:
SCHEDULED: <2023-07-06 Thu>
:LOGBOOK:
- State "CANCELED"   from "TODO"       [2023-07-11 Tue 10:52] \\
  Whatever
:END:
[2023-07-06 Thu 16:19]
** 2023-W28
*** 2023-07-11 Tuesday
**** DONE IROH Sync                                               :work:
SCHEDULED: <2023-07-11 Tue 17:00>
[2023-07-11 Tue 10:49]
**** DONE IROH-Auth weekly                                        :work:
SCHEDULED: <2023-07-11 Tue 16:35>
[2023-07-11 Tue 10:49]
**** DONE 1-1 Wanderson                                           :work:
SCHEDULED: <2023-07-11 Tue 16:05>
[2023-07-11 Tue 10:49]
**** DONE 1-1 Olivier                                             :work:
SCHEDULED: <2023-07-11 Tue 15:35>
[2023-07-11 Tue 10:48]
**** DONE Lead Weekly                                             :work:
SCHEDULED: <2023-07-11 Tue 15:00>
[2023-07-11 Tue 10:48]
**** DONE Provide doc to Guy Mackenzy                             :work:
SCHEDULED: <2023-07-11 Tue 11:30>
[2023-07-11 Tue 10:13]
**** DONE Create Entitlement Presentation                            :work:
SCHEDULED: <2023-07-11 Tue 10:30> DEADLINE: <2023-07-12 Wed 15:00>
[2023-07-11 Tue 10:12]
*** 2023-07-12 Wednesday
**** DONE Make enterprise_id mandatory field for PIAM endpoints   :work:
DEADLINE: <2023-07-12 Wed 18:00> SCHEDULED: <2023-07-12 Wed>
[2023-07-12 Wed 17:14]
**** MEETING Monetization first meeting                           :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-12 Wed 16:07]--[2023-07-12 Wed 17:07] =>  1:00
:END:
[2023-07-12 Wed 16:07]
***** Notes

tier
*** 2023-07-13 Thursday
**** DONE Review [[https://github.com/advthreat/iroh/pull/8043][[Olivier PR] Check IROH node start in test]] :work:
SCHEDULED: <2023-07-13 Thu>
[2023-07-13 Thu 12:11]
**** DONE Add enterprise_id to many orgs [[https://github.com/advthreat/securex-ui-shell/issues/297#issuecomment-1633099674][list here]] :work:
SCHEDULED: <2023-07-13 Thu 14:30>
[2023-07-13 Thu 12:06]
**** DONE Provide Q1 technical items                              :work:
DEADLINE: <2023-07-13 Thu 16:00> SCHEDULED: <2023-07-13 Thu>
[2023-07-13 Thu 11:57]


1. *IROH-Auth Testing Framework-Refactor*:
   IROH-Auth passed through many different evolution phases and different refactor
   tentatives. Most of them failed to achieve.
   One of the result is that the tests are scattered, some should be removed
   entirely.
   Some test are very complex to understand, and still not
   entirely migrated to the new better norm.
   We reclaim some official time to fix that discrepancy in the code, because it
   could either hide some bugs, or make development of certain features a lot
   harder longer than expected.

   Main concrete ideas:
   - improve DBFixture service,
   - try to regroup tests details into the same test-file so a reader will not be
    forced to dig between different files to understand what is going on.
2. *Developer Targeted documentation*.
   Currently the descriptions of the APIs in Swagger UI lack of precision.
   We could greatly improve the understanding of developer facing it by
   adding examples, and cleaner content in swagger UI.
3. *IROH-Auth isolation*
   A potential effort to think how we could improve the reliability and security
   of IROH by isolating IROH-Auth from the rest of IROH. This question
   was raised multiple times, but we do not have yet a definitive answer about what
   would be an ideal solution.
   - potentially, this could mean improving building time, and development time
     by decoupling Auth from the more feature-oriented work.
   - potentially, open new unexpected integration solution by having
     iroh-auth-only specific nodes, and perhaps even, removing the IROH-Auth
     service from other nodes entirely
   - Seems like a natural "next-step" related to the work related to specific nodes.

This one is more feature oriented as we know we will need this soon:

4. *Token Exchange Service*
   We need to produce a service that could provide the ability for an entity to
   get access to other tokens.
   To make this safe and useful, we need to go beyond the Token Exchange RFC and
   consider how to build an access rule system, logging, and keep track of the
   token chain.
   So first take the time to have a clear understanding of the feature needed,
   search and find a technical solution, and design the work to be done.

   We have a current working first example with the Account Switching.
   We should extend this to improve Impersonation (for TAC and some Devs),
   future work with PIAM, and open the door to other integration mechanisms.

**** DONE Sustaining items for Q1                                 :work:
SCHEDULED: <2023-07-13 Thu 17:00>
[2023-07-13 Thu 11:56]

** 2023-W29
*** 2023-07-17 Monday
**** MEETING Deep dive XDR Monetization                           :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-17 Mon 16:31]--[2023-07-17 Mon 17:31] =>  1:00
:END:
[2023-07-17 Mon 16:31]
***** Agenda (to discuss about)
***** Notes
- hide 3rd party modules to "Essentials" users
***** Actions
- Restrict via the API too
**** DONE Add scopes to Scott Burnettes orgs/clients?                :work:
SCHEDULED: <2023-07-17 Mon 11:00>
[2023-07-17 Mon 08:58]
*** 2023-07-19 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-19 Wed 18:47]--[2023-07-19 Wed 19:42] =>  0:55
:END:
[2023-07-19 Wed 18:47]
***** Agenda (to discuss about)
***** Notes
****** Data Retention

How to delete private-intel events older than 90 days?
How to delete orgs data?

Private Intel.

Incidents related to other entities.
If we delete data older than 90 days?

@Jyoti: if an incident is closed you can clear it.

****** Deleting all data from an Org

If no one logs for 90 days. We can delete it.
All users, modules, OAuth2 clients, etc…

@Matthieu: do we send a warning email?

@Jyoti: how to delete data in other components.
Send a notification.

IROH Events for deletion.
Keep the main topic, and create sub-filtered topics.

Order of deletion is important.

1. Mark the Org as archived state (no login, only accessible through Cisco clients)
2. send notifications to all cisco components that need to cleanup
3. wait 1 week
4. real deletion

Design doc.

****** Monetization

Lot of cases for upgrading.
In all these case, we do not have Entitlement. So no enforcement.

****** Playbook retrieval API

Read entities from public-intel, and UI call that API instead of a static file.
We had a design doc where we talked about this API.

***** Actions
**** DONE API Design Meeting                                      :work:
SCHEDULED: <2023-07-19 Wed 18:30>
[2023-07-19 Wed 14:36]
** 2023-W30
*** 2023-07-25 Tuesday
**** DONE Retrieve the list of entities from IROH Auth               :work:
SCHEDULED: <2023-07-25 Tue>
[2023-07-25 Tue 17:38]

#+begin_src clojure
IROH-Auth
  no entities dbs
    "auth-codes"
    "auth-requests"
    "auth-responses"
    "auth-login-filters"
    "oauth-client-presets"
    "oauth-code"
    "oauth-csrf"
    "oauth-device-grant-user-auth"
    "oauth-grants"
    "oauth-trusted-clients"
    "revoked-jwt"
    "revoked-entities"

For Mark
 "ao-bootstrap"

For Matt:

 "amp-user-credentials"
 "archived-module-instances"
 "iroh-events"
 "module-cache"
 "module-instances"
 "module-type-patches"
 "module-types"
 "notifications"
 "sse-tenants"
 "sse-users"
 "tiles-cache"
 "webhook-results"
 "webhooks"

Used By UI:
 "iroh-registry"

For GE:

 "ctia-investigate-talos-hunt"
 "enrichment-status"
 "feedback"
 "incident-summary"
 "iroh-async-sessions"
 "private-intel-cache"
 "risk-score"
 "threat-hunt-status"
#+end_src

**** DONE Ask Paul Cichonski about the quantity values               :work:
SCHEDULED: <2023-07-25 Tue 19:00>
See data retention, should be 90, 180, 365.
What would be the value, how should I compute?

SCHEDULED: <2023-07-25 Tue>
[2023-07-25 Tue 17:36]
**** MEETING XDR Monetization: XDR data retention                 :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-25 Tue 16:31]--[2023-07-25 Tue 17:51] =>  1:20
:END:
[2023-07-25 Tue 16:31]
***** Agenda (to discuss about)

- https://github.com/advthreat/iroh/issues/8135
- https://ciscosecurity.aha.io/epics/SECUREX-E-897

Discuss Uses cases #1.

***** Notes

What happens when this user goes.
Clearing data in 90 days.

Notion about when to delete data.

- Create or update for device.
- Create for incident, sightings, relationships.
- Comment on Incident recent, can we delete the incident?

***** Actions

****** Ask @Paul about the add-on quantity value for data retention

Data Retention is 90 days by default, add-on to go 180, or 365.
Need to sync with PIAM because these are not the values in the first doc.

**** MEETING 1-1 Wanderson                                        :work:meeting:
[2023-07-25 Tue 16:04]
***** Agenda (to discuss about)

****** Things to handle during my vacations.
:LOGBOOK:
CLOCK: [2023-07-25 Tue 16:04]--[2023-07-25 Tue 16:31] =>  0:27
:END:

1. P1: fix XDR bugs, quick improvements
2. Add ~insights~ scope for DI (take care of updating the client, perhaps fix the
   issue with non existing root scope. Could potentially be a real improvement).
3. Add event on Entitlement change. Optionally configure a webhook for this
   event, depend on the need. Check with Matt and Guy.
4. Perhaps:
   - Disable Org creation if SX EOL is officially announced.
   - [NO] improve provisioning script. Check if module exist before invoking /onboard
   - work related to short tokens (expose a token-exchange route not the RFC
     one, a simpler to use one).

5. Think about exposed data structure to make every type of org explicit and
   centralize the business logic to help the UI.
   - Retrieve a full list of Org case:
     - created via PIAM or not
     - XDR-enabled?
     - SX-enabled?
     - Entitlements/no-Entitlement

     We should be able to give a field to the UI (and other teams)
     so they know how to react.

     For example for Orbital-only or SE-only orgs, not sure if we will use SX or
     XDR UI.

     Should we add an Org field like ~external-product-only-org? s/Bool~
     And if true, affect the scopes accordingly to ensure they could not use
     neither SX nor XDR paid features.

***** Notes

****** Work on the Events for the Entitlements

update problem.

***** Actions
**** MEETING 1-1 Olivier                                          :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-25 Tue 15:05]--[2023-07-25 Tue 16:04] =>  0:59
:END:
[2023-07-25 Tue 15:05]
***** Agenda (to discuss about)

****** Things to handle during my vacations.

1. P1: fix XDR bugs, quick improvements
2. Add ~insights~ scope for DI (take care of updating the client, perhaps fix the
   issue with non existing root scope. Could potentially be a real improvement).
3. Add event on Entitlement change. Optionally configure a webhook for this
   event, depend on the need. Check with Matt and Guy.
4. Perhaps:
   - Disable Org creation if SX EOL is officially announced.
   - improve provisioning script. Check if module exist before invoking /onboard
   - work related to short tokens (expose a token-exchange route not the RFC
     one, a simpler to use one).

5. Think about exposed data structure to make every type of org explicit and
   centralize the business logic to help the UI.
   - Retrieve a full list of Org case:
     - created via PIAM or not
     - XDR-enabled?
     - SX-enabled?
     - Entitlements/no-Entitlement

     We should be able to give a field to the UI (and other teams)
     so they know how to react.

     For example for Orbital-only or SE-only orgs, not sure if we will use SX or
     XDR UI.

     Should we add an Org field like ~external-product-only-org? s/Bool~
     And if true, affect the scopes accordingly to ensure they could not use
     neither SX nor XDR paid features.

***** Notes
***** Actions
**** DONE XDR Data Retention Policy Implementation Discussion        :work:
SCHEDULED: <2023-07-25 Tue 16:30>
[2023-07-25 Tue 11:07]
**** DONE 1-1 Wanderson                                              :work:
SCHEDULED: <2023-07-25 Tue 16:05>
[2023-07-25 Tue 11:06]
**** DONE 1-1 Olivier                                                :work:
SCHEDULED: <2023-07-25 Tue 15:35>
[2023-07-25 Tue 11:00]
*** 2023-07-27 Thursday
**** DONE Message Equipe                                          :work:
SCHEDULED: <2023-07-26 Wed 14:00>
[2023-07-27 Thu 11:45]

- P1. (prob. 30%) XDR Bug fixes
- P1. (prob. 20%) Scott Burnette issue with the Provisioning API / OAuth2 clients
- P2. (prob. 10%) Help Jyoti with ~xdr-provisioning~ script
- P2. FY24Q1 Monetization: Prepare the PR for Disable Org Creation.
- P3. FY24Q1 Monetization: Entitlements Events;
  Check with Matthieu before configuring a webhook for /Automation/
  (previously Orchestration, previously SXO, previsouly AO) as it
  might not be necessary.
- P4. Dashboard https://github.com/orgs/advthreat/projects/7/views/9
  - [RBAC] ~insights~ scope + sync with DI team (Roman Eremin)
  - (prob. 10%) [RBAC] if asked to prevent non-admin to create clients,
    add ~admin~ to the scopes in the routes of the IROH Auth client web service.
  - Config Simplification + Presentation for the team
- P4. *Universal Provisioning Flow* (PIAM want to rename themselve "Security Cloud").
- P4. Designs
  + New Org concepts that need to be exposed:
    List the concepts we want to be exposed for each org.
    - ~:xdr-enabled?/sx-enable?~ perhaps a single ~:enabled-products [:xdr :sx]~.
    - ~piam-managed?~ etc…
    - Notion of Product (XDR, SX, but also, visibility, Orbital, SE).
      Effects on configuration, init of nodes, etc…
  + Token Exchange (not the RFC).
    We want to:
     - Give the ability for someone with a JWT to generate another one with some
       restrictions and complete tracking.
       Restrictions by default:
         - do not extend the :exp
         - do not change user
         - do not change org
       Tracking:
         - should be an ~act~ claim that could be recursive and we should take great
           care of not making that grow.
           It is ok not to have ~act~ in some cases like:
           - Org switching
           - format switching
           because the real owner is always the same.
           It is not ok to forget ~act~ if there is an impersonation involved.
           Typically during provisioning, real impersonation, etc…
     - Main difficulty; what is the correct data structure to represent rules of
       allowed JWT exchanges.

- Take care of asks that could leak internal abstractions:
  - do not return the full list of allowed modules, IROH-Int will take care of
    the filtering business rule.
  - use scopes, not role to filter for permissions
- Sync with Matt with everything related to modules for Monetization. Not just
  directly with Guy, Matt needs to know.

**** CANCELED XDR-flag [[https://github.com/advthreat/response/issues/1906#issuecomment-1652405093][1906]] :work:
SCHEDULED: <2023-07-27 Thu 11:45>
:LOGBOOK:
- State "CANCELED"   from "TODO"       [2023-07-28 Fri 13:23]
:END:
[2023-07-27 Thu 11:30]

*** 2023-07-28 Friday
**** MEETING Monthly Engineering                                 :work:meeting:
:LOGBOOK:
CLOCK: [2023-07-28 Fri 18:01]--[2023-07-28 Fri 19:04] =>  1:03
:END:
[2023-07-28 Fri 18:01]
***** Agenda (to discuss about)
***** Notes
****** Operation

@Gayan
Good release.
Pass it to John. Metrics.

New hires:

- @Vidun_Jayakody Automation
- @Geaog-Nokila_Pavlov

@John: upgrade platform, thanks to @Adam

****** QA

@Houman: XDR finally in production. Thanks for the fixes.
Everything went pretty well.
Performance testing, everything went pretty well in TEST.
Documented in a wiki page.

@Pujan_Trivedi: Thanks everyone for answering that quickly and efficiently.

****** Service

@GB People deliver XDR in my absence.

****** Engine

@Eric

****** Integration

@Mark

****** UI Dar

@Dar, thanks for @Jilian and ...
@Rekah refactoring. Lots of bug fixes.

****** UI Sabrina

- Congrats everyone.
- Code freeze for a while, so lot of bug fixes.
- Features been worked on.
- Search for relation.
- Configurable layout.
- Performance improvements.
- Lucas, bunch of telementry
- Miroslav, incident breadcrumb.
- Advance table.

****** Documentation @Mary


****** Demos

@Scott_McLeod incident report

@Mike next time.

@Sam_Waggoner


***** Actions
**** DONE Monthly Engineering Meeting                                :work:
SCHEDULED: <2023-07-28 Fri 18:00>
[2023-07-28 Fri 11:34]
**** DONE Answer Namrata                                          :work:
SCHEDULED: <2023-07-28 Fri>
[2023-07-28 Fri 10:20]

I am not sure about the amount of money.
But, if this is Clojurist Together, I can give more precise answer.
Looking here: https://www.clojuriststogether.org/projects/

I can attest that our team intensively uses:

- Bozhidar work (he develop cider, and most of us use it everyday, and I know he
  maintain and update the work)
- Michiel Borkent (he develop babashka which we also use daily to write scripts
  that are easier to write. And he is also very active)
- Tommi Reiman, our API uses compojure-api and lot of his related libraries.
  Even if this is very stable, he continues to work on libraries that we could
  potentially use to improve part of our internal system, like provide a better
  documentation for developer about the expectation of our routing.
- Peter Taoussanis, we use his redis and timber lib (so DB access + logs)

And looking at funded projects here are the one we use every day:

- cider (daily in our editor)
- clj-kondo (in our editor for writing code + used in our CI)
- clj-http (this is an essential lib we use to call other APIs)
- babashka / SCI (daily + used in our CI + used for admin tasks)
- clojure-lsp (used daily in our editor)
- dependabot (used daily in our CI)

To me it seems we have interrest in contributing back to the open source Clojure community.
Not only it improve the maintenance quality of essential libs to our
architecture but it also helps during hiring.
Now, regarding how much we should give, this probably depend a lot of our
current budget.
** 2023-W33
*** 2023-08-16 Wednesday
**** MEETING Data Deletion for Privacy                            :work:meeting:
:LOGBOOK:
CLOCK: [2023-08-16 Wed 18:02]--[2023-08-17 Thu 17:59] => 23:57
:END:
[2023-08-16 Wed 18:02]
***** Agenda (to discuss about)
???
***** Notes
@Prerna: XDR Data Deletion spreadsheet still in progress.
@Petr: start without X
background standardize for deletion policy.
When do we remove the registration info.
45 days post licence expiration.
storage archive.
We need to make some solid statement on deletion.
Review what we have for SCA, and do the same for XDR.

@Jake_Wyzgoski: I don't know what we do
@Derrell_Winder: Let me check
@Jake: describe to see if it align?
@Chris_Duane: it is product by product. I haven't seen anything implementing
that would stop a user to use after their license expires.

@Yann: we don't even have a clear idea about what occurs after license expires.
Current state, you can still use XDR with reduced access.

@Chris_Duane: not aware to any plan.

@Peter: this is the first discussion about it.
Data retention, etc…  Is there any establish best practice policy to follow?
License has expires.

@Jake: we need to check if 45 days is the right time or something better.

@Y: we should probably centralize this question to PIAM.

@Chris: I feel finding a standard retention.

@Peter: deletion when we want, we say, during the year.

@Prerna: default for inactivity. nobody login for 90 days then delete.

@Y: Legal? I think it's delete on demand, and for sale, you can recover your
account for N days, after that, you are not guaranteed to have your previous data back.

@Peter: word the think with, either the user ask for deletion or no real policy.

@Michael_Schultz: SCA keep lot of data beyond retention policy. So it cost money.

@Chris_Duane: Talk about exceptions.

@Petr: from a legal what is our obligation what should we say?

@Derrell_Winder: not a concern for me.
- On-request mandatory
- 45 days?

@Petr: What do you keep? Or is it about everyting?
Took a wording from SCA back to start from scratch.

@Chris: PIAM not sure what the plan is.

@Derrell_Winder: what does this 14 month refers to? (in the Data sheet)

@Petr: regroup back to finalize the PDS and

***** Actions
???
**** DONE Answer to Brandon                                       :work:
SCHEDULED: <2023-08-16 Wed>
[2023-08-16 Wed 10:10]
*** 2023-08-17 Thursday
**** MEETING PIAM Universal API (SCIM)                            :work:meeting:
:LOGBOOK:
CLOCK: [2023-08-17 Thu 17:59]--[2023-08-18 Fri 12:16] => 18:17
:END:
[2023-08-17 Thu 17:59]
***** Agenda (to discuss about)
How is it helping us to do this.
***** Notes

@Paul: UI flow. We can do that for XDR.
2nd part, Universal Flow, standardize the flow.
Suite became a thing, some more than just XDR.

Existing tenants. Unrelated.

@Prerna: Brianna expect that universal does not support brown field customers.

@Paul: she talked to Travis. We have this notion to provide any kind of meta-data.
We can collect answers to the XDR API.

@Yann: risk about the body to send.

@Prerna: what about adding values from customer questions.
Does this working.

@Paul: Developing right now.

@Prerna: we probably need the UI... Enforcing

@Paul: Offer basis, XDR is sold right now is to an offer called "XDR SSE" hidden
flow. Suite is a completely different offer and pids. Suite is using our UI base flow.
They'll see XDR as one of the thing they could buy. Only for NAM.

@Prerna: US only right now for PIAM.

@Paul: Brit Suite from XDR side nothing change.

@Prerna: For the brit suite, the universal PIAM API is what is sending info to IROH.

***** Actions

*** 2023-08-18 Friday
**** IN-PROGRESS Fix SE Clients                                   :interruption:work:
:LOGBOOK:
CLOCK: [2023-08-18 Fri 12:16]--[2023-08-18 Fri 23:47] => 11:31
:END:
[2023-08-18 Fri 12:16]
** 2023-W34
*** 2023-08-21 Monday
**** MEETING Monetization                                         :work:meeting:
:LOGBOOK:
CLOCK: [2023-08-21 Mon 16:06]--[2023-08-21 Mon 16:36] =>  0:30
:END:
[2023-08-21 Mon 16:06]
***** Agenda (to discuss about)
***** Notes
***** Actions

- [ ] Provide a doc about the new APIs for entitlements for devs.
*** 2023-08-23 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-08-23 Wed 18:34]--[2023-08-24 Thu 16:02] => 21:28
:END:
[2023-08-23 Wed 18:33]
***** Agenda (to discuss about)
***** Notes

****** 3rd party integrations (Ian's team)

@Jyoti:
 Jyoti preview problem with data quality.
  PIAM want to go full speed, with 3rd party integrations they are going to support.
  Ian not very diligent, just copy/pasting rolling new integrations.
  Don't go with the logic.
  Finally, peer-review.

  QA does not know what to test.
  Configuration issues with the modules.

  Whatever we do, we should have a check-list for review.
  What data included, proper targets, relations.
  Tactics as we need, etc…

@Guillaume: we gave advise but we never reviewed the code
@Matt: no process to review the content of 3rd party modules.
Documentation is a bit messy. Nothing is currently in place.

@Jyoti: I've been asking Namarata to add this process to check integration quality.

***** Actions


**** MEETING Data Retention bi-weekly                             :work:meeting:
:LOGBOOK
CLOCK: [2023-08-23 Wed 18:00]--[2023-08-23 Wed 18:34] =>  0:34
:END:
[2023-08-23 Wed 18:00]
***** Agenda (to discuss about)
***** Notes

- doc from Yann
- discussion about 365 vs 90 for deletion.

XDR going back to SX

***** Actions
**** CHAT Help Prerna answer question for SE                      :work:chat:
[2023-08-23 Wed 17:56]
**** CHAT Give master perm to Wanderson                           :work:chat:
[2023-08-23 Wed 17:56]
**** CHAT Help Rekha call /token                                  :work:chat:
:LOGBOOK:
CLOCK: [2023-08-23 Wed 17:46]--[2023-08-23 Wed 18:00] =>  0:14
:END:
[2023-08-23 Wed 17:55]
**** CANCELED Nominate Recognitions                               :work:
SCHEDULED: <2023-08-24 Thu 10:00>
:LOGBOOK:
- State "CANCELED"   from "TODO"       [2023-09-06 Wed 18:21]
:END:
[2023-08-23 Wed 17:49]
**** DONE Write Issue for SE                                      :work:
SCHEDULED: <2023-08-23 Wed 16:30>
[2023-08-23 Wed 16:01]
*** 2023-08-24 Thursday
**** MEETING Team meeting                                         :work:meeting:
[2023-08-24 Thu 16:34]
***** Agenda (to discuss about)
***** Notes
***** Actions
**** MEETING Monetization                                         :work:meeting:
:LOGBOOK:
CLOCK: [2023-08-24 Thu 16:02]--[2023-08-24 Thu 21:33] =>  5:31
:END:
[2023-08-24 Thu 16:02]
***** Notes
@Guillaume: tour of the team.
@Matt:
@Y:

- Made a Doc to help devs using the Entitlements
- Asked to support an SCIM-like API to help provision from PIAM.
  I consider this as low-priority for now.
  - We will need that API to support external tokens (from PIAM)
  - We will need to support asynchronous call
  - We also need to adapt the data structure, update the users data and
    potentially meta datas to apply to external onboardings.
- Asked to create many Orgs for dev purposes, so created a few personal scripts.
- Olivier discovered a potential bug with the webhook JWT generated.
- Webhooks needs to be configured by Wanderson
- Jillian asked to improve one profile endpoint to support more metas infos
- I am in a conversation to help UI support neverending session for dashboards
  via refresh tokens.
- Yuri from DI asked to be able to support client creation via UI with
  read-only. I feel we should probably provide an improved API with the full
  tree-structure of the exhaustive scopes. But UX should be involved in my opinion.
- Olivier worked on a very promissing API to simplify how we create svc-helpers.

@Mario:

- Ambrose memory fix. in Schema creating a memory leak.
- Ambrose merge a patch endpoint for bundle update
- Mario merged a PR that fix a feature
- Mario yesterday message from Brian Mallony, high impact incident, Threat
  hunting, Talos blog post weekly. And we create indicators.
  Brian created sightings, that weren't yield.
  Reach out to Michael Simonson.
  Something has changed in Talos team post. The sighting didn't yield incident.
  Not sure why the incident hadn't been created.
  Discovery; one and only one incident created specificly for Talos since July
  the 10th.
  There is something with the Talos Threat Hunt.
  Only for Talos Blogpost Hunt.

@Patrick:

Datadog check, false error. Google returns 500 error.

Questions:

@Olivier: is the Ambrose fix in PROD?
I have concern about the timber logs.

@Matt: Mario, work of Ambrose, with the Patch bundle.
Kirill added some event when an incident is updated.
Ambrose did not query the same in the patch bundle.
@Mario: I will mention that to him today.

***** Actions
:LOGBOOK:
:END:

** 2023-W36
#+BEGIN: clocktable :scope subtree :maxlevel 4 :timestamp nil :link nil :tags t :narrow 36! :match "work"
#+CAPTION: Clock summary at [2023-09-11 Mon 10:51]
| Tags          | Headline                   | Time     |          |          |          |
|---------------+----------------------------+----------+----------+----------+----------|
|               | *Total time*                 | *1d 22:17* |          |          |          |
|---------------+----------------------------+----------+----------+----------+----------|
|               | \_  2023-W36               |          | 1d 22:17 |          |          |
|               | \_    2023-09-05 Tuesday   |          |          |     3:06 |          |
| work, meeting | \_      Weekly Team        |          |          |          |     1:32 |
| work, meeting | \_      Weekly Leads       |          |          |          |     1:34 |
|               | \_    2023-09-06 Wednesday |          |          | 1d 19:11 |          |
| work, meeting | \_      API Design Meeting |          |          |          | 1d 17:11 |
| work, meeting | \_      FMC Plan with Paul |          |          |          |     2:00 |
#+END:

*** 2023-09-05 Tuesday
:LOGBOOK:
:END:
**** MEETING Weekly Team                                          :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-05 Tue 17:03]--[2023-09-05 Tue 18:35] =>  1:32
:END:
[2023-09-05 Tue 17:03]
***** Agenda (to discuss about)
***** Notes
***** Actions
**** MEETING Weekly Leads                                         :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-05 Tue 15:16]--[2023-09-05 Tue 16:50] =>  1:34
:END:
[2023-09-05 Tue 15:16]
***** Agenda (to discuss about)
****** Offsite
Semaine du 9 octobre.
***** Notes
***** Actions
**** DONE Leads Meeting                                           :work:
SCHEDULED: <2023-09-05 Tue 15:00>
:PROPERTIES:
:Effort:   1:00
:END:
[2023-09-05 Tue 10:36]
*** 2023-09-06 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-06 Wed 18:31]--[2023-09-08 Fri 11:42] => 41:11
:END:
[2023-09-06 Wed 18:31]
***** Agenda (to discuss about)
IROH as a common service

CSC, and DI will move in Secure Cloud access.

How to reuse the UI, how to continu to make this function.
CSC.
They also need to talk to SE, other cisco integrations.

DI need to talk to all other integrations.

What happens to our modules.

Thinking about IROH and a few of its services, IROH headless.

See proposal:

https://github.com/advthreat/response/pull/2026



***** Notes
***** Actions
**** MEETING FMC Plan with Paul                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-06 Wed 16:31]--[2023-09-06 Wed 18:31] =>  2:00
:END:
[2023-09-06 Wed 16:31]
***** Agenda (to discuss about)
***** Notes
***** Actions
*** 2023-09-08 Friday
**** DONE Check Client [[webexteams://im?space=b5136a40-6687-11ed-9679-4b10798d7c1a&message=722b1960-4dc4-11ee-9508-fba85c9bfccf][Webex]] :work:
SCHEDULED: <2023-09-08 Fri 14:00>
:LOGBOOK:
CLOCK: [2023-09-08 Fri 11:42]--[2023-09-08 Fri 13:12] =>  1:30
:END:
[2023-09-08 Fri 11:42]
** 2023-W37
*** 2023-09-11 Monday
**** DONE Avance on Org Level Clients                                :work:
SCHEDULED: <2023-09-12 Tue 14:00>
[2023-09-11 Mon 20:57]
**** MEETING 1-1 Jyoti Yann                                       :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-11 Mon 19:28]--[2023-09-12 Tue 00:36] =>  5:08
:END:
[2023-09-11 Mon 19:28]
***** Agenda (to discuss about)
???
***** Notes
Didi discussion, another discussion source.
Need to figure out, DI, etc…

Sequence Diagrams.

To talk: - signing keys from OKTA

***** Actions

- Advance on Org leve clients.
  - fix https://github.com/advthreat/iroh/issues/7582
  - plan to update the client to use virtual
**** DONE Envoyer une liste d'amin par org [[https://github.com/Cisco-PosaaS/oak/issues/8664][Issue]] [[webexteams://im?space=b5136a40-6687-11ed-9679-4b10798d7c1a&message=11a76c20-5098-11ee-9e49-49fc7799be2b][Yuri]] :work:
SCHEDULED: <2023-09-12 Tue 11:00>
[2023-09-11 Mon 19:00]
**** DONE Envoyer les org-id à conserver (OAuth2 clients, master users) à Petr :work:
SCHEDULED: <2023-09-12 Tue 10:30>
[2023-09-11 Mon 18:59]
**** DONE Answer to [[webexteams://im?space=b5136a40-6687-11ed-9679-4b10798d7c1a&message=2298ba80-507e-11ee-a39b-619063280a9c][Yuri]] :work:
SCHEDULED: <2023-09-11 Mon 11:30>
:LOGBOOK:
CLOCK: [2023-09-11 Mon 11:02]--[2023-09-11 Mon 19:00] =>  7:58
:END:
[2023-09-11 Mon 11:02]
*** 2023-09-12 Tuesday
**** MEETING 1-1 Wanderson meeting                                :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-12 Tue 16:34]--[2023-09-13 Wed 08:20] => 15:46
:END:
[2023-09-12 Tue 16:34]
***** Agenda (to discuss about)
Reviewing
https://github.com/advthreat/iroh/pull/8300/files?short_path=fd98974#diff-fd98974c31ef730c3067abab7684e51eb6be875ee368a148d1ab660d832e5abc
***** Notes
***** Actions
****** TODO Create a new full description about JWKSService.

  - ~cache-jwks~:
    - perform the call to the JWKS server and if successful update PG (if needed)
    - the PG should contain:
      - details about JWKS payload
      - prepare a RAM (service context) public key from the JWKS payload
  - ~get-jwks~: you only check the RAM service context
    Returns a hashmap indiced with ~kid~ and values should be public keys.
    If fails: ~(log/WARN )~ : either an attack or the JWKS updated For OPS Please
    RESTART THE NODES!!!!.
  - ~check-jwt-signature~:
     1. decode JWT
     2. get kid
     3. retrieve kid from  ~(get (get-jwts) kid)~
     4. Check signature
  - ~validate-claims~:
     1. decode JWT
     2. check ~aud~  and ~exp~

****** TODO The doc does not say if fields are mandatory or not.
Which one are mandatory?

Example: https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/provisioning/common-provisioning/apireference/Models/Entitlement.md

And more precisely:

https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/provisioning/common-provisioning/apireference/Models/Tenant.md

*** 2023-09-13 Wednesday
**** MEETING Monetization                                        :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-13 Wed 19:30]--[2023-09-13 Wed 21:15] =>  1:45
:END:
[2023-09-13 Wed 19:30]
***** Agenda (to discuss about)
***** Notes
***** Actions
*** 2023-09-14 Thursday
**** MEETING Monetization Demo                                    :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-14 Thu 16:31]--[2023-09-14 Thu 17:25] =>  0:54
:END:
[2023-09-14 Thu 16:31]
***** Agenda (to discuss about)
***** Notes
***** Actions
** 2023-W38
*** 2023-09-19 Tuesday
**** MEETING Weekly Team Meeting                                  :work:meeting:
[2023-09-19 Tue 17:02]
***** IROH-Auth
- Talk about DI virtual users
- Progress on Universal Provisioning API (interesting Engineering challenges)
- Talk with Automation about Org virtual users
***** Notes
- Offsite

**** MEETING 1-1 Wanderson                                        :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-19 Tue 16:13]--[2023-09-19 Tue 17:54] =>  1:41
:END:
[2023-09-19 Tue 16:13]
***** Agenda (to discuss about)
***** Notes
***** Actions
****** Questions for PIAM
******* TODO Do you send a different URL for every provisioning call? Or is the URL fixed and should be configured?

**** DONE Prepare Automation Meeting (Org virtual user)           :work:
SCHEDULED: <2023-09-19 Tue>
[2023-09-19 Tue 10:05]

Why Org Virtual User?
https://github.com/Cisco-PosaaS/oak/issues/8664#issuecomment-1717653336

Why not "main Admin" of the Org?
Some admin could individually have different permissions and properties that
might not be something we'd like to provide the to clients.

Changes?

None, nothing changed. The email could be filled with something that was not an
email for very old accounts, but this claim was never mandatory.
You just got lucky every JWT had an email.
See: https://visibility.amp.cisco.com/iroh/doc/iroh-auth/index.html
Where ~email~ is explicitly marked as "optional".

Short Tokens?

Where ~email~ are removed from the claims.
We keep only:

- "iss"
- "iat"
- "exp"
- "nbf"
- "jti"
- "aud"
- "sub"
- "https://schemas.cisco.com/iroh/identity/claims/format"
- "https://schemas.cisco.com/iroh/identity/claims/user/id"
- "https://schemas.cisco.com/iroh/identity/claims/org/id"
- "https://schemas.cisco.com/iroh/identity/claims/oauth/refresh-token-jti"
- "https://schemas.cisco.com/iroh/identity/claims/oauth/client/id"
- "https://schemas.cisco.com/iroh/identity/claims/oauth/user/id"
- "https://schemas.cisco.com/iroh/identity/claims/oauth/client/owner/id"
- "https://schemas.cisco.com/iroh/identity/claims/oauth/grant"
- "https://schemas.cisco.com/iroh/identity/claims/oauth/kind"

In particular, no ~scope~, no ~email~, no ~user name~, etc…

*** 2023-09-20 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-20 Wed 18:29]--[2023-09-20 Wed 21:09] =>  2:40
:END:
[2023-09-20 Wed 18:29]

Offsite:

@Jyoti:
  High level vision, XDR:
  - AI team on top of the incident manager.
  - MDR requirements
  - Wednesday afternoon

***** G2

Telemetry.
@Gbuisson: give them access to data.

***** Yann status update

- lot of work related to the design of Universal Provisioning API with Wanderson.
  - Planned a new meeting next week with PIAM and SCA to check the design.
  - New design implies many changes, (expect at least 4 release cycles):
    - support PIAM tokens but also understand how to check them securely (for
      now this is not clear)
    - support worker run on constant interval that would run on a single instance.
    - support lock.
- SE, SX-only provisioning with 0-click module setup support (https://github.com/advthreat/iroh/issues/8266)
  blocked work related to SE provisioning, waiting for PR approval. Still no
  ping from SE team yet. (https://github.com/advthreat/iroh/pull/8275)
  - talked with Automation about the Org-level users yesterday, I think we are on
    track with Murali. I think Santosh probably feels better about it.
    They will need another client and they could automatically
    get the tokens for the client generating Org-level tokens using tokens of the
    first client because their client has ~oauth~ scope.
- still many small tasks related to fixing provision related bugs.
  - Yesterday, and today asked by Danny to create an SX-only Org for Arizona
    University directly asked by Brianna.
  - Today, pinged by Matthew Franks because CSC onboarding is failing on EU.
  - QA team asking to create SX-only orgs (Hissan yesterday)
- Heard about plan for custom roles, should be part with Petr planning. Just to
  check if PMs expectations are easy to reach. For example a notion that an user
  could have multiple roles. I don't think it would be difficult to do that in
  IROH, but this might become a potential breaking change if external
  integration looking at the ~role~ claim in JWT or in the ~whoami~ endpoint.
- Still keep track that Olivier feels good working on modules with Matt.
  I think he appreciate to be exposed to other part of IROH he is used to.
**** MEETING Prepare Universal API Meeting                        :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-20 Wed 16:32]--[2023-09-20 Wed 18:29] =>  1:57
CLOCK: [2023-09-20 Wed 14:47]--[2023-09-20 Wed 14:50] =>  0:03
:END:
[2023-09-20 Wed 14:47]
***** Actions

***** Questions for PIAM:

****** TODO Optional Fields in PIAM doc

The doc does not say if fields are mandatory or not.
Which one are mandatory?

Example: https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/provisioning/common-provisioning/apireference/Models/Entitlement.md

And more precisely:


https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/provisioning/common-provisioning/apireference/Models/Tenant.md

****** TODO How to check for PIAM ownership of the PIAM token

I guess verifying the signature will not be enough.
Should we check a specific ~sub~ claim?
etc…

****** TODO Do you send a different callback URL for every provisioning call? Or is the URL fixed and should be configured?

*** 2023-09-21 Thursday
**** MEETING VPN Swagger                                          :work:meeting:
:LOGBOOK:
CLOCK: [2023-09-21 Thu 16:02]--[2023-09-22 Fri 17:39] => 25:37
:END:
[2023-09-21 Thu 16:02]

SBG CTO is looking accross access.
*** 2023-09-22 Friday
**** DONE Do Data Retention Policy [[https://github.com/advthreat/iroh/pull/8384/files][ISSUE]] :work:
SCHEDULED: <2023-09-25 Mon 10:00>
:LOGBOOK:
CLOCK: [2023-09-22 Fri 17:39]--[2023-09-22 Fri 20:59] =>  3:20
:END:
[2023-09-22 Fri 17:39]
** 2023-W39
*** 2023-09-27 Wednesday
**** DONE Advisory Lock Service [[https://shiroyasha.io/advisory-locks-and-how-to-use-them.html][Article]] :work:
SCHEDULED: <2023-09-27 Wed 11:00>
[2023-09-27 Wed 09:25]
** 2023-W39
*** 2023-09-25 Monday
**** DONE Préparer Rewards Olivier                                :work:
SCHEDULED: <2023-09-25 Mon 14:30>
[2023-09-25 Mon 11:15]

***** Big things you did between Juyly 2022/August 2023:

****** XDR
- *RBAC
- Expose Entitlements
- [Provisioning] Update Entitlements
****** Generic
- Org Virtual User, very big win.
  - Org Level Authorization in clients
- Public but hidden APIs
****** Devs
- IROH Configs and service graph discovery
- Public dev doc (template, deploy, etc…)
- Changelog
- Code coverage
***** Rewards

Great throughput, Generic and Quality.
Not much I can ask for on my end.

**** DONE Préparer Rewards 1-1 Wanderson                          :work:
SCHEDULED: <2023-09-25 Mon 14:00>
[2023-09-25 Mon 11:14]

***** Big things you did between July 2022 / August 2023:

****** XDR
- Expose Entitlements
- scopes/permissions endpoints

****** Generic
- Short Tokens, not in use yet, but Automation wants them.
- Many code maintenance + bugfix/support

****** Devs
- some code fixes/refactos

***** Rewards

Compare to other members, very good but sometime you had some lack of
consistence I affect to many of your life challenges.
Last few months this totally changed, so this will probably change.
Even like this you still are a very strong contributor.
I will probably be able to negociate for more next year.

**** DONE Créer template offsite                                  :work:
SCHEDULED: <2023-09-25 Mon 12:00>
[2023-09-25 Mon 11:13]

** 2023-W40
*** 2023-10-02 Monday
**** IN-PROGRESS Presentation Custom Roles                        :work:
:LOGBOOK:
CLOCK: [2023-10-02 Mon 18:11]--[2023-10-03 Tue 18:49] => 24:38
:END:
[2023-10-02 Mon 18:11]
**** DONE Ecrire Presentation/Document custom roles               :work:
SCHEDULED: <2023-10-02 Mon 16:00>
[2023-10-02 Mon 15:38]
*** 2023-10-05 Thursday
**** DONE Finaliser personal presentation                         :work:
SCHEDULED: <2023-10-09 Mon 10:00>
[2023-10-05 Thu 21:13]
**** DONE Préparer présentation IROH 2.0                          :work:
SCHEDULED: <2023-10-09 Mon 09:00>
[2023-10-05 Thu 21:13]
** 2023-W42
#+BEGIN: clocktable :scope subtree :maxlevel 4 :timestamp nil :link nil :tags t :narrow 36! :match "work"
#+CAPTION: Clock summary at [2023-10-23 Mon 11:20]
| Tags          | Headline                      | Time     |          |         |         |
|---------------+-------------------------------+----------+----------+---------+---------|
|               | *Total time*                    | *1d 12:26* |          |         |         |
|---------------+-------------------------------+----------+----------+---------+---------|
|               | \_  2023-W42                  |          | 1d 12:26 |         |         |
|               | \_    2023-10-16 Monday       |          |          | 1d 3:56 |         |
| work, meeting | \_      Monetization          |          |          |         | 1d 3:56 |
|               | \_    2023-10-18 Wednesday    |          |          |    3:02 |         |
| work, meeting | \_      Custom Roles with Guy |          |          |         |    3:02 |
|               | \_    2023-10-20 Friday       |          |          |    5:28 |         |
| work, meeting | \_      Detect Unused Orgs    |          |          |         |    5:28 |
#+END:

*** 2023-10-16 Monday
**** DONE Reserver Ecran                                             :work:
SCHEDULED: <2023-10-24 Tue 10:40>
[2023-10-16 Mon 17:42]
**** DONE Factures offsite                                        :work:
SCHEDULED: <2023-10-17 Tue 10:00>
[2023-10-16 Mon 17:41]
**** MEETING Monetization                                         :work:meeting:
:LOGBOOK:
CLOCK: [2023-10-16 Mon 16:02]--[2023-10-17 Tue 19:58] => 27:56
:END:
[2023-10-16 Mon 16:02]
***** Agenda (to discuss about)
***** Notes
***** Actions
- Add discussion about upgrade/downgrade session [[webexteams://im?space=27f93cd0-5190-11ee-bd8d-35c3d6dd9f2f][Channel]]
**** DONE Create clients [[webexteams://im?space=fc0e4f90-527d-11ee-98f2-0faa9801585c][SSE]]                                      :work:
SCHEDULED: <2023-10-16 Mon 15:00>
[2023-10-16 Mon 11:11]
*** 2023-10-18 Wednesday
**** MEETING Meraki OAuth2 discussion                             :work:meeting:
[2023-10-18 Wed 17:09]
***** Agenda (to discuss about)
***** Notes
***** Actions
**** MEETING JWT and Entitlements                                 :work:meeting:
[2023-10-18 Wed 16:31]
***** Agenda (to discuss about)
***** Notes
***** Actions
**** MEETING Custom Roles with Guy                                :work:meeting:
:LOGBOOK:
CLOCK: [2023-10-18 Wed 16:01]--[2023-10-18 Wed 19:03] =>  3:02
:END:
[2023-10-18 Wed 16:01]
***** Agenda (to discuss about)
How to get JWTs
How to retrieve Entitlements
***** Notes

@Andrew_Parisi
Data retention for conure.



***** Actions

*** 2023-10-20 Friday
**** MEETING Detect Unused Orgs                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-10-20 Fri 16:01]--[2023-10-20 Fri 21:29] =>  5:28
:END:
[2023-10-20 Fri 16:01]
***** Agenda (to discuss about)
***** Notes
***** Actions
** 2023-W43
*** 2023-10-23 Monday
**** MEETING FMC delegate OAuth2 Device Grant                  :work:meeting:
:LOGBOOK:
CLOCK: [2023-10-23 Mon 16:31]--[2023-10-23 Mon 17:59] =>  1:28
:END:
[2023-10-23 Mon 16:31]
***** Agenda (to discuss about)
***** Notes
***** Actions
*** 2023-10-24 Tuesday
**** MEETING Staging decision                                     :work:meeting:
:LOGBOOK:
CLOCK: [2023-10-24 Tue 20:06]--[2023-10-24 Tue 21:26] =>  1:20
:END:
[2023-10-24 Tue 20:06]
***** Agenda (to discuss about)
***** Notes
***** Actions
*** 2023-10-26 Thursday
**** MEETING XDR Data Retention Sync                              :work:meeting:
:LOGBOOK:
CLOCK: [2023-10-26 Thu 17:31]--[2023-10-26 Thu 18:01] =>  0:30
:END:
[2023-10-26 Thu 17:30]
***** Agenda (to discuss about)
***** Notes
***** Actions
** 2023-W44
*** 2023-10-30 Monday
**** DONE Delete PIAM clients created by me                       :interruption:work:
:LOGBOOK:
CLOCK: [2023-10-30 Mon 17:13]--[2023-10-30 Mon 18:16] =>  1:03
:END:
[2023-10-30 Mon 17:13]

#+begin_src
./get-client -e test --client-id 'client-092cc2a4-4a91-41d5-a153-caf2304f64a6'
{:env :test,
 :client
 {:name "PIAM-Provisioning-TEST",
  :availability "org",
  :scopes ["cisco/platform"],
  :grants ["client-creds"]},
 :owner
 {:user-id "cbab92a3-d606-4c74-895c-0c8921dce6ef",
  :user-name "Yann (MASTER)",
  :user-email "yaesposi@cisco.com",
  :additional-scopes
  ["iroh-admin" "cognitive" "iroh-master" "cisco" "global-intel"]},
 :org
 {:id "33b2cdbf-0d67-42f3-8a20-ca96fac4e20c",
  :name "Y ORG (master-user)"}}
#+end_src
** 2023-W45
*** 2023-11-06 Monday
**** DONE undo upgrade on enterprise-id                              :work:
SCHEDULED: <2023-11-07 Tue 10:00>
[2023-11-06 Mon 18:39]
**** DONE Planifier visite médicale                               :work:
SCHEDULED: <2023-11-06 Mon 14:00>
[2023-11-06 Mon 10:42]
*** 2023-11-07 Tuesday
**** MEETING Weekly Lead Meeting                                  :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-07 Tue 15:07]--[2023-11-07 Tue 16:37] =>  1:30
:END:
[2023-11-07 Tue 15:07]
***** Agenda (to discuss about)
***** Notes

Mario on centralizing CTIA/private-intel

***** Actions

** 2023-W46
*** 2023-11-14 Tuesday
**** MEETING User + Breach Suite Priority                         :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-14 Tue 17:35]--[2023-11-14 Tue 18:17] =>  0:42
:END:
[2023-11-14 Tue 17:35]
***** Agenda (to discuss about)

Our current customer experience isn’t great – we rely on personal contact to the
admin to provision the products in a very specific order, and then a manual
correction on the back end.
This is because both XDR and Secure Access set up a Secure X org, which is
necessary for Breach and User Suites, respectively – but in the Combo Suite
there’s currently no way for them to coordinate and only set up one org.
Align on the priority of fixing this issue Proposed resolution, is this the
right path forward

Please forward the meeting if I have not included all the right representatives.

XDR:  Briana, Jyoti
Secure Access:  Nirmal, Justin (Sangeeta, Matt optional)
Secure Endpoint:  Ivlana, Alain
E2E Test:  JJ, April
PMO:  Sukanthi
PM Ops:  Mandy

***** Notes
***** Actions
*** 2023-11-15 Wednesday
**** MEETING API Design Meeting                                :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-15 Wed 19:15]--[2023-11-15 Wed 22:14] =>  2:59
:END:
[2023-11-15 Wed 19:15]
***** Agenda (to discuss about)
***** Notes
***** Actions

****** DONE Add a check for the module.
SCHEDULED: <2023-11-16 Thu 14:00>

*** 2023-11-16 Thursday
**** MEETING Universal PIAM flow check-in                      :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-16 Thu 16:29]--[2023-11-17 Fri 18:02] => 25:33
:END:
[2023-11-16 Thu 16:29]
***** Agenda (to discuss about)
***** Notes
***** Actions

Open work:

Admin work:
 - Have an OAuth2 client credentials to answer back to PIAM
 - Have a reasonable value for waiting time of failure (I would say 24h)
 - Potentially add a mechanism to send an error email to an internal TAC support
   team about a problem for some customer during the provisioning that need
   manual intervention
 -
*** 2023-11-17 Friday
**** MEETING Monthly Engineer Meeting                             :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-17 Fri 18:02]--[2023-11-17 Fri 20:10] =>  2:08
:END:
[2023-11-17 Fri 18:02]
***** Agenda (to discuss about)
***** Notes
***** Actions
** 2023-W47
*** 2023-11-21 Tuesday
**** MEETING XDR / PIAM common provisioning api coordination                        :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-21 Tue 18:05]--[2023-11-21 Tue 21:27] =>  3:22
:END:
[2023-11-21 Tue 18:05]
***** Agenda (to discuss about)
Checks work to be done.
What the timeline is looking like?


***** Notes
***** Actions
** 2023-W48
*** 2023-11-28 Tuesday
**** DONE org-level-auth for DI clients                              :work:
SCHEDULED: <2023-11-28 Tue 14:00>
[2023-11-28 Tue 09:56]
*** 2023-11-29 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-29 Wed 18:45]--[2023-11-29 Wed 21:21] =>  2:36
:END:
[2023-11-29 Wed 18:45]
***** Agenda (to discuss about)
***** Actions
***** Notes
****** Common Org

Have a common org for SE and other internal products.

- CDO effort piece stopped. PIAM will take that.

@Jyoti: Staging

Ask from PM. Nobody from the Engineering team wants to do this.

Asked to us explain why it would take 1 year.
So created a document, started with Murali.

Ops came back on estimation.
Couple of hours.

PM came back, what for a brand new region.
Ops let's use the same script.
PM why was that one year.

Be very clear of the steps after it was setup.
All the configurations we need.
Number of steps, clearly call out assumptions and dependencies.
Etc… Add up all the work for all integrations.

PIAM
**** MEETING SCC Script (brownfield provisioning)                 :work:meeting:
:LOGBOOK:
CLOCK: [2023-11-29 Wed 17:55]--[2023-11-29 Wed 18:44] =>  0:49
:END:
[2023-11-29 Wed 17:55]
***** Agenda (to discuss about)
***** Notes

Danny will run a script to trigger user-email+org-id => start flow to attach to
enterprise-id & entitlements

***** Actions

** 2023-W49
*** 2023-12-04 Monday
**** MEETING Scoring Escalation Devs Sync                         :work:meeting:
:LOGBOOK:
CLOCK: [2023-12-04 Mon 15:20]--[2023-12-04 Mon 21:56] =>  6:36
:END:
[2023-12-04 Mon 15:20]
***** Agenda (to discuss about)
***** Notes
***** Actions

- monitor failed pushed incidents
- improve robustness of incidents scoring by having default quick score + harder score
*** 2023-12-08 Friday
**** MEETING IROH Sync                                            :work:meeting:
:LOGBOOK:
CLOCK: [2023-12-08 Fri 17:08]--[2023-12-09 Sat 09:31] => 16:23
:END:
[2023-12-08 Fri 17:08]
***** Agenda (to discuss about)
- Retrospective

***** Notes
****** Guillaume (4/5)
- Communication Quality: 4/5
- Well:
- Badly:
  - CRITICAL ESCALATION INCIDENT.
    Went undetected.
    Too confident in monitoring.
****** Yann (4/5) ...
****** Matt (4/5)
+ positive: data dog
+ negative:
+ suggestions:
   + put name into anonymous function
****** Mario (4/5)
+ positive:
  - people are implicated
  - many patches that improved the situation
+ negative:
  - lot of people impacted
  - accounting for every task
+ Suggestion:
  - keep track of successful/failed jobs
****** Olivier (4/5)
+ positive:
+ negative:
  - nb of PG queries
+ suggestions:
  - could have tried to help
****** Jerôme (?/5)
+ positive
  - we will improve our monitoring
+ negative:
  - monitoring
+ suggestion:
  - we could have been helpful to retrieve logs for example.
  - work on monitoring
  - add sentry to get all trace back
****** Ambrose (?/5)
+ postive:
  - great resume from GB
+ negative:
  - incident and CPU, cut corners
+ suggestion:
  - ...
****** Kirill (4/5)
+ positive:
  - great to see how people collaborating
+ negative:
  - ns, db functionality, relation logic,
  - process to introduce big architecture changes.
  - not actively collaborating on PR
+ suggestion
  - look more to other's PRs
  - big architecture changes
****** Shafiq (?/5)
+ positive:
  - identified the mapping issue in the iroh-event feature
+ negative:
  - ...
+ suggestion:
***** Actions
** 2023-W50
*** 2023-12-14 Thursday
**** MEETING Refresh tokens                                       :work:meeting:
:LOGBOOK:
CLOCK: [2023-12-14 Thu 19:06]--[2023-12-15 Fri 15:51] => 20:45
:END:
[2023-12-14 Thu 19:06]
***** Agenda (to discuss about)
***** Notes

- Create Trusted clients (read only) with longer refresh tokens
- Write the doc for the UI team
***** Actions
**** DONE Refresh tokens  (doc + create read-only clients)           :work:
SCHEDULED: <2023-12-15 Fri 11:00>
[2023-12-14 Thu 19:06]
*** 2023-12-15 Friday
**** DISC Sync with team                                          :work:discussion:
:LOGBOOK:
CLOCK: [2023-12-15 Fri 15:51]--[2023-12-15 Fri 17:21] =>  1:30
:END:
[2023-12-15 Fri 15:51]

** Initial


For the end of the week, I feel I didn't sync'd enough with both of you.

So let me give a short update about what is going on.

1. I started working on finally provide a correct impersonating mechanism.
   It will use the same JWT generation as the login mechanism. Providing not
   only an access token but also a refresh token.

   - If you impersonate, your user details are saved in an ~act~ claim that will
     contain an user identity.
   - If you use an impersonated JWT to switch account, the new JWT will keep the
     same ~act~ claim as the first impersonated claim.
   - I don't think we need to go down up to the point of tracking OAuth2
     clients, but this is a possibility.
2. I will have a meeting with Danny an Prerna to provide a script that will make
   customer responsible for connecting their PIAM account to their XDR account.
   The script looks like something very easy to write and provide.
   We'll see.
3. I started a discussion with the UI team because I was pinged by Piotr to have
   a long living dashboard (so very long session to show an XDR dashboard).
   Here is what I proposed:

   1. create a few specific trusted clients (with dummy password...) for which
      refresh tokens expires only after 1 month.
   2. When the user want to display a long living dashboard, the UI could switch
      the tokens used from the session token to the token retrieved from this
      client by using the `/iroh/oauth2/custom/tokens` route.

 4. A similar discussion spawned with Chris Duane about providing a safer
    mechanism to hand JWT to the AI component. And I proposed the exact same
    solution.
    Create a specific client and hand over these new token we can control more
    easily than a user session token.
 5. The priority is still Universal Provisioning fixes and improvements. This is
    why I didn't started to talk about the rest of the work yet
 6. After looking at the fiasco that was trying to use events to create a cache
    for Entitlement Summary. Not much a fiasco, but a clear reminder that
    concurrent (or even worse distributed) event systems are a nightmare to
    internalize and understand.
    We could have a longer discussion about this if you feel inclined.
 7. Last but not least in anyway, we might finally start a new big chunck of work
    to support multi-region/sub-region. We worked with GB on a new design that
    would provide the ability to our customer to select their prefered AWS
    deployment region while minimizing the impact on the ops, development teams
    and other integrated teams. For now, this is just a proposal that we bubbled
    up to the PMs. We will see if this is accepted or if there is another plan to
    support more geos.

** ChatGPT English corrected

As the end of the week approaches, I feel like I haven't synced enough with both of you. To provide a brief update on my progress, here are some key points:

1. I have been working on implementing an impersonating mechanism that uses JWT generation similar to the login process. This will not only generate an access token but also a refresh token. If you use an impersonated JWT to switch accounts, the new JWT will retain the same ~act~ claim as the first impersonated claim. While it may be possible to track OAuth2 clients, I don't think we need to go that far.
2. I have a meeting scheduled with Danny and Prerna to provide them with a script that will enable customers to connect their PIAM account to their XDR account. The script should be relatively easy to write and implement. We'll see how it goes.
3. I recently had a discussion with the UI team because Piotr pinged me about creating a long-living dashboard. To achieve this, I proposed the following solution:
	* Create a few trusted clients (with dummy passwords) for which refresh tokens expire only after one month.
	* When the user wants to display a long-living dashboard, the UI can switch from using the session token to retrieving a token from this client by using the `/iroh/oauth2/custom/tokens` route.
4. A similar discussion took place with Chris Duane about providing a safer mechanism for handing JWTs to the AI component. I suggested creating a specific client and controlling these new tokens more easily than user session tokens.
5. The priority remains fixing and improving Universal Provisioning, which is why I haven't started discussing other work yet.
6. After attempting to use events to create an Entitlement Summary cache, I was reminded of the challenges associated with concurrent (or even distributed) event systems. We could have a longer discussion about this if you're interested.
7. Lastly, we might finally begin working on a new project to support multi-region/sub-region deployment options. Our team has proposed a design that would allow customers to select their preferred AWS deployment region while minimizing the impact on ops, development teams, and other integrated teams. This is currently being reviewed by PMs, and we'll see if it's accepted or if there are alternative plans in place.

** 2023-W51
*** 2023-12-19 Tuesday
**** MEETING 1-1 Olivier                                          :work:meeting:
:LOGBOOK:
CLOCK: [2023-12-19 Tue 15:32]--[2023-12-19 Tue 22:00] =>  6:28
:END:
[2023-12-19 Tue 15:32]
***** Agenda (to discuss about)
***** Notes
***** Actions
*** 2023-12-20 Wednesday
**** IN-PROGRESS Investigate org-not-found for DI                 :work:
:LOGBOOK:
CLOCK: [2023-12-20 Wed 09:48]--[2023-12-20 Wed 22:42] => 12:54
:END:
[2023-12-20 Wed 09:48]
* 2024
** 2024-W02
*** 2024-01-08 Monday
**** DONE Upgrade/Downgrade meeting                               :work:meeting:
:LOGBOOK:
*** 2024-01-10 Wednesday
**** MEETING Q3 Quadrant Slides Readout                           :work:meeting:
:LOGBOOK:
CLOCK: [2024-01-10 Wed 16:06]--[2024-01-12 Fri 09:46] => 41:40
:END:
[2024-01-10 Wed 16:06]
***** Agenda (to discuss about)
***** Notes
- Meraki MX: IROH 1-click (S)
- XDR-E-95 : impersonating Portal
***** Actions
** 2024-W03
*** 2024-01-16 Tuesday
**** DONE Perform brownfield Superbowl                            :work:
SCHEDULED: <2024-01-16 Tue>
[2024-01-16 Tue 19:07]
**** MEETING XDR Platform / Automation / Insights / Analytics Planning Session :work:meeting:
:LOGBOOK:
CLOCK: [2024-01-16 Tue 18:16]--[2024-01-16 Tue 21:45] =>  3:29
:END:
[2024-01-16 Tue 18:16]
***** Agenda (to discuss about)
***** Notes
***** Actions
*** 2024-01-17 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
[2024-01-17 Wed 18:10]
***** Agenda (to discuss about)
****** Yann Topics
1. Ask completion time for FMC Proxy
2. ES strategies
   a. Detect non-cisco Org and apply retention rule
   b. Rate-limit NGFW entities creations per org
   c. Split XDR-only data from SecureX data to another cluster
   d. Migrate to some GraphDB
3. Super Bowl
4. Demo

***** Notes
****** @Jyoti: Things to do
******* Hierarchical Modules

 Hierarchical Modules
   First Microsoft endpoint, then Defender.
   Jyoti takes notes.
   
******* JAMF

To @Matt Use the client creds.
Just a few minutes, and ask them to test. Make a PR.
For new user, they enter user and password, then we get a token and use to
request the classic API.

@Matt: to know if there is an issue within JAMF UI, you should contact Aaron.

******* Integration that need a session (Checkpoint)

@Matt: discussion between Matt Van Der Host and GB and did not see this
integration in the Airtable. 
@Jyoti: asking for the github ticket. Assign Shafiq to this ticket, but also
keep Mark in the loop.

******* How can we handle On-Prem products? (Design Item)

Doing via SSX, AO Remote, and also Cisco Telemetry.
Something we need to figure out maybe with CDO.
Which one should be standardized?
Design item.

******* CDO Firewall Proxy

Tentative 2 releases (mid-Feb)

- @Jyoti: ping me if we have something else.

***** Actions
**** MEETING Superbowl link                                       :work:meeting:
[2024-01-17 Wed 17:17]
***** Agenda (to discuss about)
***** Notes
***** Actions
**** MEETING Discussion GE quarter                                :work:meeting:
[2024-01-17 Wed 14:39]
***** Agenda (to discuss about)
- XDR Incident Correlation ; Planning Blocker <no IROH involvement>
- IM/AUT Incident Response Enhancements ; Lisa to send details on dependencies
- MITRE ATTACK ;
- ES XDR-only store plan ;
***** Notes
- depasser les IOPS

***** Actions
**** IN-PROGRESS Attempt to trigger XDR/SCC connection            :work:
:LOGBOOK:
CLOCK: [2024-01-17 Wed 14:28]--[2024-01-18 Thu 18:09] => 27:41
:END:
[2024-01-17 Wed 14:28]

#+begin_src bash
#!/usr/bin/env bash
OKTA_URL='https://ciscob2b.okta.com/oauth2/ausr5ltkvjT6lODuy357'
CLIENT_ID=XXX
CLIENT_SECRET=XXX
ORG_ID="1bc3e2c7-8aaf-440c-bc82-9b9a3f538283"
USER_EMAIL="nikm@wblservices.com"
# SCOPE="security:global:provisioning-status:write"
SCOPE="security:xdr:provisioning:tenants-attach"
JWT=$( curl -XPOST "$OKTA_URL/v1/token" \
            -u "$CLIENT_ID:$CLIENT_SECRET" \
            -H "Content-Type: application/x-www-form-urlencoded" \
            -H "Accept: application/json" \
            -d 'grant_type=client_credentials&scope='"$SCOPE" | jq '.access_token' | sed 's/"//g' )
curl -XPOST "$OKTA_URL/v1/productInstanceInvitation" \
     -H "Authorization: Bearer $JWT" \
     -H 'Content-Type: application/json' \
     -d '{"region":"NAM","productExternalTenantId":"'"$ORG_ID"'","users":["'"$USER_EMAIL"'"]}'
#+end_src
** 2024-W04
*** 2024-01-24 Wednesday
**** MEETING API Design Meeting                                   :work:meeting:
[2024-01-24 Wed 19:05]
- What was discussed
- What was decided
*- What are the next tasks and who is taking care of them
***** Note
- @Jyoti: Microsoft Defender start this week. Discussion with @Mark.
- @Jyoti: discuss about modernizing iroh-async; perhaps use kafka. Need a
  discussion with GE.
- @Jyoti Create a new IROH-AI service to work with AI backend.
  We need to proxy to them.
  The AI service will be core service.
  for Q3 SOC assistant.

***** TODO Add to Q3: SOC Assistant create iroh-ai module to proxy to AI backend; assign Mark or maybe Tiffany

**** MEETING All Hands                                            :work:meeting:
:LOGBOOK:
CLOCK: [2024-01-24 Wed 18:33]--[2024-01-25 Thu 21:58] => 27:25
:END:
[2024-01-24 Wed 18:33]
***** Agenda (to discuss about)
***** Notes

Some internal AI/ML spaces for collaboration:
- networkGPT | Join: https://eurl.io/#gHbta7lro
- Generative AI Explorers | Join: https://eurl.io/#Z4vekB6ph
- AI_ChatGPT | Join: https://eurl.io/#nbJWbnj12
- GAI Engineering Forum | Join: https://eurl.io/#k9dt-XxWv
- Artificial Intelligence and Machine Learning | Join: https://eurl.io/#Bk7grXKuV
- Cisco Enterprise Chat AI - Support - https://eurl.io/#cVPv-NLF7

***** Actions
**** MEETING MITRE Meeting                                        :work:meeting:
:LOGBOOK:
CLOCK: [2024-01-24 Wed 16:05]--[2024-01-24 Wed 16:08] =>  0:03
:END:
[2024-01-24 Wed 16:05]
- Presentation

1. Phases
  1. Talos visualisation (product Tacticts & Techniques coverage)
  2. How many incidents per technique

Going Forward:

- probably dynamic product coverage from Talos     
- Recommendations (which product to add)  
- perhaps Scores (from Kenna)  
  
**** Questions

***** Sub-techniques?

Not visible, every things goes in the biggest bucket.
At least for phase 1.

*** 2024-01-26 Friday
**** MEETING Monthly Engineering                                  :work:meeting:
:LOGBOOK:
CLOCK: [2024-01-26 Fri 17:24]--[2024-01-26 Fri 19:17] =>  1:53
:END:
[2024-01-26 Fri 17:24]
***** Agenda (to discuss about)
***** Notes
****** IROH Services Team

******* Performances
- New Datadog Monitoring, Visualizations & Alerts (thanks to Jerome and Patrick)
  Really improved visibility of our work and the impact on performance.
  - In particular new JMX metrics for clj-http connections. Thanks Matt!
  - Kafka monitoring.

- New Alerting  (thanks to Patrick)
  Very important to detect performance issues as quickly as possible.

- We improved many aspect of our platform, in particular in iroh-async, but not
  only, we also improved some PG requests.

******* Quality
- Improved our system to declare error statuses with schemas. Thanks Ambrose!
- Ongoing node configuration improvements.

******* Features

- Ambrose worked on asset rescoring.
- Data Retention cleanup for events in Postgres
- Universal Provisioning:
  - Part of it Support External JWT, from Okta, but also FMC.
- Brownfield customer, ability to upgrade existing SecureX users to XDR
- Impersonator tracking which if delivered should help TAC and quality teams.

******* Bonus

Great work and dedication to discover, and resolve production issues.
Thanks to everyone involved!

Still Planning Many improvements learned from these events.

***** Actions

** 2024-W05
*** 2024-01-29 Monday
**** MEETING Impersonate Meeting                                  :work:meeting:
:LOGBOOK:
CLOCK: [2024-01-29 Mon 15:59]--[2024-01-29 Mon 22:28] =>  6:29
:END:
[2024-01-29 Mon 15:59]
***** Agenda (to discuss about)

Hi All,

I would like to have a chat with this group regarding this epic https://ciscosecurity.aha.io/epics/XDR-E-145 (Priority 21 in Q3 list).
We have a separate ask from the XDR TAC team to  enable user impersonation for the TAC engineering for troubleshooting purposes, which is a discovery only effort for Q3.

@Petr Cernohorsky (pcernoho) does this epic relate to user impersonation as well? Or is this something specific to incidents, that does not involve Yann and the team to develop user impersonation infrastructure?

***** Notes

New Portal, with read-only impersonation + stats per org (nb of incident,
selection, sort, etc…)

***** Actions

Wait for UX to design

*** 2024-01-31 Wednesday
**** MEETING SCA Integration                                      :work:meeting:
[2024-01-31 Wed 17:09]
***** Agenda (to discuss about)

@Namrata: top priority for the team.
What are the priorities.
New features that do not exist in XDR to integrate.
Forming to form a backlog for us to converge.

Ask @Crystal to share a timeline.

Technical side of things, plan to implement the things to support the convergence.
On both teams.

This is the intent of the conversation.

***** Notes

- @Crystal (Crystal Storar) low hanging fruit from the customer.
  Wrong login page.
  User Management to sync between SCA and XDR.
  SCA Free Trial, should probably disappear.
- @Jyoti: we need a deeper dive. We need to go page by page.
  And have that discussion.
- @Crystal: already happened.
- @Jeff (Jeff Markey)
- @Namrata low hanging fruit vs big step
  please Crystal share the timeline?
- @Crystal cautious about public timeline.
  We have an obligation to deliver outcome to our customers via XDR through this
  contract period.
  12 to 18 month for the convergence.
  Goal, move feature from SCA to XDR step by step.
- @Jeff what about removing features? Do they have access to XDR?
- @Crystal yes.
- @Jeremy how many people, how are we gonna cut some features to make that happen?
- @Namrata first form the backlog, then the timeline will be tied to this.
  ... Integration configuration being top priority.
  Let's focus on that.
  Then the devices page to send that to DI to leverage network behaviour.
- @Crystal another big one, merge into investigate.
- @Derrick the Device view you mentioned is evaluated this quarter.
- @Namrata Top Priorities:
  Integration UX, Device leverage, Investigate and User Management.

***** Actions
**** IN-PROGRESS Create AO Clients                                :work:
SCHEDULED: <2024-01-31 Wed 20:00>
:LOGBOOK:
CLOCK: [2024-01-31 Wed 16:11]--[2024-01-31 Wed 20:53] =>  4:42
:END:
[2024-01-31 Wed 16:11]

- Remove rate-limit of client 1
- Put rate-limit back of client 0
- Create new client with org-level-authorization
**** DONE ask cherry-pick                                         :work:
SCHEDULED: <2024-01-31 Wed 15:00>
[2024-01-31 Wed 14:16]
*** 2024-02-01 Thursday
**** Prepare Meeting PIAM work                                    :work:
SCHEDULED: <2024-02-01 Thu>
:LOGBOOK:
CLOCK: [2024-02-01 Thu 08:49]
:END:
[2024-02-01 Thu 08:48]



***** Jyoti

Option 2: Having a Common IROH per enterprise that’s converted to XDR when XDR is purchased

Assumptions:
  - There can only be one XDR per region per enterprise - SCC should enforce it
  - One common iroh per region per enterprise
  - IROH will have an API to exchange a PIAM token with an IROH token
  - API to provision the iroh tenant in the enterprise should exist
    - Provisioning should include a flag to indicate that this is a common tenant
  - SCC UI should support the iroh backend for integrations
  - XDR will need to get the PIAM token to talk to SSX (service scoped token)

Sub-Option 1 - IROH token in the browser
  -  Separate iroh-auth tokens in the browser per region
  -  When are these tokens generated?
  -  Front end to backend uses IROH session token
  -  Service to service uses IROH token
  -  All iroh services continue to use the IROH token

Sub-Option 2
  -  Browser only stores the PIAM token
  -  Backends of microapps support the PIAM token
  -  Front end to backend uses PIAM session token
  -  Service to service uses IROH token
  -  Integrations (iroh-int) works with PIAM token
  -  Iroh-proxy works with PIAM token

SSX
  -  SSX enterprise tenant is created when enterprise is born
  -  XDR will call the SSX enterprise using the PIAM token
  -  Common iroh does not need to provision SSX
  -  Iroh-sse service will need to work with PIAM token

Firewall
  -  Device OAuth flow will get proxied to CDO
  -  CDO will register the devices with the CDO SSX tenant
  -  If CDO is not brought into the enterprise, XDR will not see the devices registered via CDO (*)

Integrations
  -  If common integrations that are not to be used by XDR, there should be a flag in the module type to allow for that logic
  -  New API in iroh-int for SCC Integration UI

Open Question:
  -  If a common tenant existed and the XDR tenant was brought in later to be attached to the Enterprise, how is the common iroh tenant handled?
  - If the attach operation happens before the common iroh tenant exists, this will not be a problem


****** Remarks/Questions

******* PIAM  ↔ IROH Token Exchange

On: "IROH will have an API to exchange a PIAM token with an IROH token"

What does precisely mean?

An IROH token is linked to a specific ~org-id~.
The PIAM token does not have any ~org-id~.
So not many options:

1. Auto select the ~org-id~ to be this non-XDR / IROH-only ~enterprise-id~ org
2. In order to exchange, someone must provide one of the matching ~org-id~ (with
   potential exchange)

   #+begin_src
   Client => IROH: I have this PIAM token, give me an IROH token
   IROH => Client: You have many matching IROH Identities, here there are:
       1. PIAM Global Org (just enterprise-id)
       2. org-1
       ...
       n. org-n
   Client => IROH:
       1. org-n
   #+end_src

Proposal: Do both and more by supporting 2 as well as:

#+begin_src
Client => IROH: I have this PIAM token, give me an IROH token for my PIAM Global Org
IROH => Client: Here it is
#+end_src

#+begin_src
Client => IROH: I have this PIAM token, give me an IROH token for my Org org-1
IROH => Client: Here it is
#+end_src

******* modules and PIAM token

#+begin_quote
Sub Option 2
  ...
  - Integrations (iroh-int) works with PIAM token
  - Iroh-proxy works with PIAM token
#+end_quote

For this:

Case 1:

If the relay module directly support PIAM token, we would need the opposite
service.
Exchange an IROH token for a PIAM token.
Because modules are called even out of session.

#+begin_src
IROH => PIAM: I have this IROH token, give me a PIAM token
#+end_src

And then add a new authorization mechanism in module-types.

But this goes with potential security risks as the PIAM token might provide more
scopes/authorizations/capabilities than the IROH token.

Case 2: The module/relay is unchanged, we need to retrieve the IROH token from
the PIAM token. See previous section.

******* SSX called from IROH

#+begin_quote
 XDR will call the SSX enterprise using the PIAM token
#+end_quote

Same potential issue. How could XDR get the PIAM token.

There are many different PIAM tokens. So:

- Is the PIAM token tied to a single user?
- Do we support Enterprise-level PIAM token?
- Could we get a PIAM token from an IROH token without privilege escalation?
- Would the PIAM token could be retrieved from an XDR org, or from the
  special Enterprise Org?

******* New API in iroh-int for SCC Integration UI?
not sure what is needed there.

******* Open questions

The way I envisionned it:

Always an Enterprise Org which is invalid for XDR usage, just focused on PIAM functionalities.
With potential bridges (like copying module-instances between this main Org and
the real XDR org).

If the customer also need XDR, then we create another XDR org, again with
potential bridges such that the XDR Org could be affected by the Enterprise Org.