yogsototh/deft
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
deft/tracker.org
Yann Esposito (Yogsototh) 0110eee062
save
2024-02-01 15:16:14 +01:00

74 KiB
Raw Blame History

2023

2023-W26

2023-06-29 Thursday

CANCELED Investigate invite bug   work

SCHEDULED: <2023-07-03 Mon 11:00>

  • State "CANCELED" from "TODO" [2023-07-11 Tue 10:51]
    Whatever

[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

CLOCK: [2023-07-04 Tue 16:04]–[2023-07-04 Tue 16:33] => 0:29

[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>

  • State "CANCELED" from "TODO" [2023-07-11 Tue 10:52]
    Whatever

[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

CLOCK: [2023-07-12 Wed 16:07]–[2023-07-12 Wed 17:07] => 1:00

[2023-07-12 Wed 16:07]

Notes

tier

2023-07-13 Thursday

DONE Review [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 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:

  1. 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

CLOCK: [2023-07-17 Mon 16:31]–[2023-07-17 Mon 17:31] => 1:00

[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

CLOCK: [2023-07-19 Wed 18:47]–[2023-07-19 Wed 19:42] => 0:55

[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]

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"
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

CLOCK: [2023-07-25 Tue 16:31]–[2023-07-25 Tue 17:51] => 1:20

[2023-07-25 Tue 16:31]

Agenda (to discuss about)

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.

CLOCK: [2023-07-25 Tue 16:04]–[2023-07-25 Tue 16:31] => 0:27

  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

CLOCK: [2023-07-25 Tue 15:05]–[2023-07-25 Tue 16:04] => 0:59

[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 1906   work

SCHEDULED: <2023-07-27 Thu 11:45>

  • State "CANCELED" from "TODO" [2023-07-28 Fri 13:23]

[2023-07-27 Thu 11:30]

2023-07-28 Friday

MEETING Monthly Engineering   work meeting

CLOCK: [2023-07-28 Fri 18:01]–[2023-07-28 Fri 19:04] => 1:03

[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

CLOCK: [2023-08-16 Wed 18:02]–[2023-08-17 Thu 17:59] => 23:57

[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

CLOCK: [2023-08-17 Thu 17:59]–[2023-08-18 Fri 12:16] => 18:17

[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

CLOCK: [2023-08-18 Fri 12:16]–[2023-08-18 Fri 23:47] => 11:31

[2023-08-18 Fri 12:16]

2023-W34

2023-08-21 Monday

MEETING Monetization   work meeting

CLOCK: [2023-08-21 Mon 16:06]–[2023-08-21 Mon 16:36] => 0:30

[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

CLOCK: [2023-08-23 Wed 18:34]–[2023-08-24 Thu 16:02] => 21:28

[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

CLOCK: [2023-08-23 Wed 17:46]–[2023-08-23 Wed 18:00] => 0:14

[2023-08-23 Wed 17:55]

CANCELED Nominate Recognitions   work

SCHEDULED: <2023-08-24 Thu 10:00>

  • State "CANCELED" from "TODO" [2023-09-06 Wed 18:21]

[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

CLOCK: [2023-08-24 Thu 16:02]–[2023-08-24 Thu 21:33] => 5:31

[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

2023-W36

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
Clock summary at [2023-09-11 Mon 10:51]

2023-09-05 Tuesday

MEETING Weekly Team   work meeting

CLOCK: [2023-09-05 Tue 17:03]–[2023-09-05 Tue 18:35] => 1:32

[2023-09-05 Tue 17:03]

Agenda (to discuss about)
Notes
Actions
MEETING Weekly Leads   work meeting

CLOCK: [2023-09-05 Tue 15:16]–[2023-09-05 Tue 16:50] => 1:34

[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>

[2023-09-05 Tue 10:36]

2023-09-06 Wednesday

MEETING API Design Meeting   work meeting

CLOCK: [2023-09-06 Wed 18:31]–[2023-09-08 Fri 11:42] => 41:11

[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

CLOCK: [2023-09-06 Wed 16:31]–[2023-09-06 Wed 18:31] => 2:00

[2023-09-06 Wed 16:31]

Agenda (to discuss about)
Notes
Actions

2023-09-08 Friday

DONE Check Client Webex   work

SCHEDULED: <2023-09-08 Fri 14:00>

CLOCK: [2023-09-08 Fri 11:42]–[2023-09-08 Fri 13:12] => 1:30

[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

CLOCK: [2023-09-11 Mon 19:28]–[2023-09-12 Tue 00:36] => 5:08

[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
DONE Envoyer une liste d'amin par org Issue 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 Yuri   work

SCHEDULED: <2023-09-11 Mon 11:30>

CLOCK: [2023-09-11 Mon 11:02]–[2023-09-11 Mon 19:00] => 7:58

[2023-09-11 Mon 11:02]

2023-09-12 Tuesday

MEETING 1-1 Wanderson meeting   work meeting

CLOCK: [2023-09-12 Tue 16:34]–[2023-09-13 Wed 08:20] => 15:46

[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

CLOCK: [2023-09-13 Wed 19:30]–[2023-09-13 Wed 21:15] => 1:45

[2023-09-13 Wed 19:30]

Agenda (to discuss about)
Notes
Actions

2023-09-14 Thursday

MEETING Monetization Demo   work meeting

CLOCK: [2023-09-14 Thu 16:31]–[2023-09-14 Thu 17:25] => 0:54

[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

CLOCK: [2023-09-19 Tue 16:13]–[2023-09-19 Tue 17:54] => 1:41

[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:

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

2023-09-20 Wednesday

MEETING API Design Meeting   work meeting

CLOCK: [2023-09-20 Wed 18:29]–[2023-09-20 Wed 21:09] => 2:40

[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

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

[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

CLOCK: [2023-09-21 Thu 16:02]–[2023-09-22 Fri 17:39] => 25:37

[2023-09-21 Thu 16:02]

SBG CTO is looking accross access.

2023-09-22 Friday

DONE Do Data Retention Policy ISSUE   work

SCHEDULED: <2023-09-25 Mon 10:00>

CLOCK: [2023-09-22 Fri 17:39]–[2023-09-22 Fri 20:59] => 3:20

[2023-09-22 Fri 17:39]

2023-W39

2023-09-27 Wednesday

DONE Advisory Lock Service 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

CLOCK: [2023-10-02 Mon 18:11]–[2023-10-03 Tue 18:49] => 24:38

[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

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
Clock summary at [2023-10-23 Mon 11:20]

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

CLOCK: [2023-10-16 Mon 16:02]–[2023-10-17 Tue 19:58] => 27:56

[2023-10-16 Mon 16:02]

Agenda (to discuss about)
Notes
Actions
  • Add discussion about upgrade/downgrade session Channel
DONE Create clients 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

CLOCK: [2023-10-18 Wed 16:01]–[2023-10-18 Wed 19:03] => 3:02

[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

CLOCK: [2023-10-20 Fri 16:01]–[2023-10-20 Fri 21:29] => 5:28

[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

CLOCK: [2023-10-23 Mon 16:31]–[2023-10-23 Mon 17:59] => 1:28

[2023-10-23 Mon 16:31]

Agenda (to discuss about)
Notes
Actions

2023-10-24 Tuesday

MEETING Staging decision   work meeting

CLOCK: [2023-10-24 Tue 20:06]–[2023-10-24 Tue 21:26] => 1:20

[2023-10-24 Tue 20:06]

Agenda (to discuss about)
Notes
Actions

2023-10-26 Thursday

MEETING XDR Data Retention Sync   work meeting

CLOCK: [2023-10-26 Thu 17:31]–[2023-10-26 Thu 18:01] => 0:30

[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

CLOCK: [2023-10-30 Mon 17:13]–[2023-10-30 Mon 18:16] => 1:03

[2023-10-30 Mon 17:13]

./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)"}}

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

CLOCK: [2023-11-07 Tue 15:07]–[2023-11-07 Tue 16:37] => 1:30

[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

CLOCK: [2023-11-14 Tue 17:35]–[2023-11-14 Tue 18:17] => 0:42

[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

CLOCK: [2023-11-15 Wed 19:15]–[2023-11-15 Wed 22:14] => 2:59

[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

CLOCK: [2023-11-16 Thu 16:29]–[2023-11-17 Fri 18:02] => 25:33

[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

CLOCK: [2023-11-17 Fri 18:02]–[2023-11-17 Fri 20:10] => 2:08

[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

CLOCK: [2023-11-21 Tue 18:05]–[2023-11-21 Tue 21:27] => 3:22

[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

CLOCK: [2023-11-29 Wed 18:45]–[2023-11-29 Wed 21:21] => 2:36

[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

CLOCK: [2023-11-29 Wed 17:55]–[2023-11-29 Wed 18:44] => 0:49

[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

CLOCK: [2023-12-04 Mon 15:20]–[2023-12-04 Mon 21:56] => 6:36

[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

CLOCK: [2023-12-08 Fri 17:08]–[2023-12-09 Sat 09:31] => 16:23

[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

CLOCK: [2023-12-14 Thu 19:06]–[2023-12-15 Fri 15:51] => 20:45

[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

CLOCK: [2023-12-15 Fri 15:51]–[2023-12-15 Fri 17:21] => 1:30

[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.
  1. 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.
  2. 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
  3. 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.
  4. 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.
  1. 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.
  2. The priority remains fixing and improving Universal Provisioning, which is why I haven't started discussing other work yet.
  3. 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.
  4. 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

CLOCK: [2023-12-19 Tue 15:32]–[2023-12-19 Tue 22:00] => 6:28

[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

CLOCK: [2023-12-20 Wed 09:48]–[2023-12-20 Wed 22:42] => 12:54

[2023-12-20 Wed 09:48]

2024

2024-W02

2024-01-08 Monday

DONE Upgrade/Downgrade meeting   work meeting

2024-01-10 Wednesday

MEETING Q3 Quadrant Slides Readout   work meeting

CLOCK: [2024-01-10 Wed 16:06]–[2024-01-12 Fri 09:46] => 41:40

[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

CLOCK: [2024-01-16 Tue 18:16]–[2024-01-16 Tue 21:45] => 3:29

[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

    1. Detect non-cisco Org and apply retention rule
    2. Rate-limit NGFW entities creations per org
    3. Split XDR-only data from SecureX data to another cluster
    4. 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

CLOCK: [2024-01-17 Wed 14:28]–[2024-01-18 Thu 18:09] => 27:41

[2024-01-17 Wed 14:28]

#!/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"'"]}'

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

CLOCK: [2024-01-24 Wed 18:33]–[2024-01-25 Thu 21:58] => 27:25

[2024-01-24 Wed 18:33]

Agenda (to discuss about)
Notes

Some internal AI/ML spaces for collaboration:

Actions
MEETING MITRE Meeting   work meeting

CLOCK: [2024-01-24 Wed 16:05]–[2024-01-24 Wed 16:08] => 0:03

[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

CLOCK: [2024-01-26 Fri 17:24]–[2024-01-26 Fri 19:17] => 1:53

[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

CLOCK: [2024-01-29 Mon 15:59]–[2024-01-29 Mon 22:28] => 6:29

[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>

CLOCK: [2024-01-31 Wed 16:11]–[2024-01-31 Wed 20:53] => 4:42

[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>

CLOCK: [2024-02-01 Thu 08:49]

[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)

    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

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

Client => IROH: I have this PIAM token, give me an IROH token for my PIAM Global Org
IROH => Client: Here it is
Client => IROH: I have this PIAM token, give me an IROH token for my Org org-1
IROH => Client: Here it is
modules and PIAM token

Sub Option 2 …

  • Integrations (iroh-int) works with PIAM token
  • Iroh-proxy works with PIAM token

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.

IROH => PIAM: I have this IROH token, give me a PIAM token

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

XDR will call the SSX enterprise using the PIAM token

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.