deft/tracker.org at 6b27fe6c7103fc493e764ee6f31d6096438b4845

yogsototh/deft

Fork 0

Yann Esposito (Yogsototh) c1d2459d0c

save

2024-08-14 11:35:42 +02:00

140 KiB

Raw Blame History

2024

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

Ask completion time for FMC Proxy
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
Super Bowl
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:

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

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

[2024-01-24 Wed 16:05]

Presentation

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

DONE Create AO Clients work

SCHEDULED: <2024-02-09 Fri 11: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

CHAT Guy doc work chat

CLOCK: [2024-02-01 Thu 17:02]–[2024-02-01 Thu 20:51] => 3:49

[2024-02-01 Thu 17:02] SXO is a consumer of the high impact incidents. Current schema: ```json {"event_type":"private-intel/incident/high-impact/created", "incident_id": String} ``` To receive status updates of these incident we propose to make SXO also a consumer of all status update of every incident being high impact or not. The expectation is that there will not be too many update events. For this we will change the configuration of the webhook to also match on events of type "private-intel/note/updated". The schema of these events will be: ```clojure (s/defschema UpdatedField {:field s/Keyword :action (s/enum "modified" "added" "deleted") :value (st/optional-keys {:before s/Any :after s/Any})}) (s/defschema PrivateIntelIncidentData {:event_type (s/enum "private-intel/incident/updated") :incident_id s/Str :updated_fields [UpdatedField]}) ```

DONE Prepare Meeting PIAM work work

SCHEDULED: <2024-02-01 Thu>

CLOCK: [2024-02-01 Thu 08:49]–[2024-02-01 Thu 17:02] => 8:13

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

Auto select the org-id to be this non-XDR / IROH-only enterprise-id org

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.

Remarks / Question

1 XDR org per PIAM Enterprise-id

This would make a LOT of things trivial. In particular:

Exchanging PIAM and IROH token. Except perhaps org-level IROH token (depending on current PIAM ability to have enterprise-level tokens) And thus will simplify everything related to selecting a tenant. In particular SSX, Module instances, etc…

Work involved:

Add a constraint mechanism to prevent duplicate enterprise_id (in the same Region).
(optional) Add a constraint to prevent duplicate cross region (to enforce 1 enterprise on all XDR instances (Region & geo))
Add a flag to know if this Org is PIAM without XDR enabled or if it also include an active XDR account. So discussion about what would users in this special org would be allowed to do on a PIAM created Org without XDR product attached. Could they still add/remove modules, etc…
Change our code so most field will be sync'ed from SCSO to XDR during user login. This way, if a user change his name, email, in SCSO, it will affect XDR on next login.
1. Perhaps there is another sync mechanism we could use to sync even if the user does not login into XDR.

Risks

Upgrade existing tenant without enterprise-id but should be manageable with TAC IMO.
Some modules are restricted to have at most 1 module instance (by the product) which might change. For example if this single Enterprise-id (XDR org) buy multiple time the same product. Still should not be that difficult to change by other teams.

1 IROH org per PIAM Enterprise-id + 1 attached XDR orgs

I am not sure it would be possible without a huge amount of work as all our APIs (external web apis as well as internal code API) expect a specific org-id. I wouldn't explore this possibility to "share" data from one Org to another One. It would not only make the code to write this very difficult to write, but also open a lot more potential security issues.

Guy Response

Current status:

SXO is a consummer of high impact incident creation event. Current schema:

2024-W06

2024-02-05 Monday

MEETING Jyoti Meeting work meeting

CLOCK: [2024-02-05 Mon 19:49]–[2024-02-05 Mon 21:44] => 1:55

[2024-02-05 Mon 19:49]

Agenda (to discuss about)

Notes

PIAM Auth team.

Then need S2S tokens.

Actions

MEETING Trigger Aut rules on status update. work meeting

CLOCK: [2024-02-05 Mon 16:01]–[2024-02-05 Mon 16:30] => 0:29

[2024-02-05 Mon 16:01]

Agenda (to discuss about)

Notes

Actions

2024-02-06 Tuesday

MEETING SX EOL bi-Weekly work meeting

[2024-02-06 Tue 20:28]

Agenda (to discuss about)

Review Action Items List
Review current quarter commitments
Status against milestones
Discuss Issues, Risks, Blockers
Dependencies status
Review features ready for next release

Notes

@Maribell impact when SX EOL end. Date very high at risk of customer not being impacted. Pb with PIAM alignment.

Supporting the product teams to makes those EOL.

@Prerna: Make a checklist for SX itself. We need to understand if things moved to XDR for the EOL, Navigation, URLs, etc…

Inventory of all these things.

Planing phase in Q3, Q4 execution which ends with SX EOL on July 31th.

1-click setup, SSE, SSX, through SecureX.

Couple of things we have done, and what we want to do going forward.

Make a list of SX mention in XDR.
List of mentions from IROH and ops too. The domains.
Check the XDR URLs.
ops: redirect security.cisco.com to xdr.security.cisco.com
most questions about REBRANDING

@Michelle searching for SecureX mentions. @Dar / @Michelle: search in 3rd parties.

Ribbon

@Robert: we could make a message asking them to upgrade to the Ribbon. @Prerna: build some kind of flow to build that. @Derrick: upgrade button maybe? @Robert: depend on UX/UI/Doc

@Hisan: a single doc? @Prerna: no

@Maribell: Native modules. SE, Umbrella

Actions

DONE Find all SecureX mention in IROH

SCHEDULED: <2024-02-20 Tue 13:00>

DONE Check with Jyoti about moving visibility.* URLs

SCHEDULED: <2024-02-27 Tue 18:00>

MEETING XDR Platform (Admin & Management) Core Team work meeting

[2024-02-06 Tue 18:06]

Agenda (to discuss about)

Notes

@Derek: plan @Sukanthi: plan @Namrata: Focus on Core team updates. Meant to focus on our Q3 delivery. We will have Q4 things. @Sukanthi: have a single place to see everything when we cannot attend the meeting. @Derek: I'll go ahead and go to Aha release (v2.12.0 and v6.12.0) @Carlos_Diaz: Carlos and Paul, are here for TD&R colleagues to advocate support. Tech leads necessitate in their project. Architecture confirmation. @Prerna: PO of feature and management. RBAC, Provisioning, Multi-Tenancy, Admin page. In Design phase. @Derek: keep sharing with us.

Actions

MEETING Weekly work meeting

CLOCK: [2024-02-06 Tue 17:04]–[2024-02-07 Wed 18:37] => 25:33

[2024-02-06 Tue 17:04]

Agenda (to discuss about)

Notes

Yann

DONE AO Rules issue help
DONE Support PIAM token (no nbf)
DONE PIAM trigger onboarding on PIAM (SCC) Attach
DONE Sync with AO to help Rules (trigger on incident status update)
DONE removed AO client rate-limit
DONE Help PIAM Design Proposal
DONE Help with SCC Attach
DONE Help with Impersonation via TAC Portal
DONE Helped SE Team with Legacy Provisioning
DOING Create New AO Client to reduce rate-limit + org-level clients
ON HOLD/NEED HELP: IOPS Report Failure
TOPIC nb of real paid customer in prod?

Actions

2024-02-08 Thursday

MEETING Notifications Discussions work meeting

CLOCK: [2024-02-08 Thu 14:29]–[2024-02-08 Thu 15:29] => 1:00

[2024-02-08 Thu 14:29]

Agenda (to discuss about)

Notes

@Matt: Kirill wanted to use one topic for output? And each implementation would consume this topic and deliver notifs for this topic.

@Kirill: save status in DB

@Kirill: do we need it.

@Yann: rate limit,

Actions

DONE Respond to SCA work

SCHEDULED: <2024-02-08 Thu 14:00> [2024-02-08 Thu 08:31]

2024-02-09 Friday

DONE Create AI Clients work

CLOCK: [2024-02-09 Fri 09:47]–[2024-02-09 Fri 15:26] => 5:39

[2024-02-09 Fri 09:47]

DONE Create AI Clients complete comment work

SCHEDULED: <2024-02-09 Fri 12:00> [2024-02-09 Fri 09:12]

2024-W07

2024-02-12 Monday

MEETING Breach Suite - Brownfield Exposure work meeting

CLOCK: [2024-02-12 Mon 19:50]–[2024-02-12 Mon 21:27] => 1:37

[2024-02-12 Mon 19:50]

@Kelli: previous discussion about Brownfield exposure Is is something dangerous that need immediate action. Pb with region. Let's talk about the brownfield.

rec started and summarized

@Kelli: in our previous conversation, Travis one of the thing we discussed update updating people. What is the process? @Travis: yes we'll share doc and this is not complication. For every product we have a Business and Technical decision maker. Rotating of OAuth creds go to technical decision maker. We let prodcut team choose by themselve. We've gone back to be director of Engineering for both. Going forward should be approved to at least Directory level.

We are consider asking approved has been approved, including Suites.

@Kelli: Brownfield Discussion Where we need to go. My understanding is that for the implementation for a Brownfield flow due to SecureX EOL Migration. What happens is a cases created in TAC and someone help customer to migrate. And then go to in SCC connect. Which is different for other products. This is a SecureX flow, it opens the possibility to a standalone customer to attach that to a Breach Suite, Breach Brownfield scenario that I don't know we support.

@Travis: two different things.

being able to bring a tenant provisioning outside of SCC inside SCC (unrelated to product paid), done by team, XDR, SE, etc… @Kelli who is initiating @Danny I will be the one initiating @Kelli just XDR or SE? @Travis they are working on it (@Simon_Seibaa confirm) @Travis they can have manual process. @Kelli ok I understand but it can affect a suite when a product does that. We haven't suite e2e testing.
@Travis, product into SCC it opens different workflows. one of the, apply a License or Subscription to a Tenant. For example add a Suite. Multiple examples of this, a modification call for that tenant. Having a SCC will also provide the ability to purge data or other features.

@Jyoti: you need an entitlement. @Travis: when you attach the API there is no subscription to it. The customer still needs to apply the entitlement. @Jyoti: 2nd thing, how does a product know it is part of a Suite? @Travis: ask the question of what is different? The way suite started this is just this tier in this product. Same as bought separately. The entitlements provided to products is the same to XDR standalone. @Kelli: XDR specifically has add-ons what if you are bringing that into a suite. @Travis: you cannot. @Kelli: SCC will recognize that situation so the attach it knows which work with that and which don't. @Travis: We transform everything as Entitlements. If you have a subscription applied to it. And apply a different subscription to it and it will push the new entitlements. @Jyoti: no entitlement at first, so no entitlements. @Travis: First need to link and attach the Suite license. @Jyoti: if they have asked for add-ons it will be erased? @Travis: it will not be erased, the existing subscription, will be replaced because we have two subscriptions. It simply an update of the entitlements. The UI about history of entitlement does not exist yet, shoud be done in Q4. @Jyoti: The customer might be confused. How to choose. @Travis: most of the case should be ok. Would have better UI in Q4. Ask do you want to use the existing XDR or create a new one? @Jyoti: they could be applied separately. @Travis: yes it is possible. They don't need to terminate old subscription. @Jess_Munos: if I'm a SE customer and I don't have any Suite product. But I have Orbital already deployed. And I buy a Suite. And I provision XDR, those provisioning would create a new IROH account. So something is happening in the backend. Is there something to prevent duplication? Then using the new ones instead of the correct old one. @Jyoti: Two separate XDR tenants, with two separate IROH accounts. I don't know if this a use case we ever heard for our PMs. @Travis: That is not something that is true today. They could have a trial and have a new paid XDR tenant. They want to buy a higher tier + a suite with lower tier. They bought both of them and could choose. @Jyoti: expected nothing is shared. Then there two separate things? @Kieran: looks like a greenfield not a brownfield scenario. If they do that, they will loose the add-ons by doing that. @Travis: ah yes, they will loose them. @Jesse: we don't have the solution yet to manage these issues. What do we thing timeline will be to have the solution in place? Or do we need to fix that on the fly. @Travis: can you be more specific? @Jesse: Having effectively multiple tenant for customer with existing product deployement? We have currently deployed products. Now we have duplicates all over the place. @Travis: we will provide a kafka notification for attach subscriptions. When they onboard they need to subscribe to that, they'll gonna have to go and search if an existing exist. They can kind of migrate from the platform tenant. But this is highly contextual of the service. This is cannot be done generically.

@April_Luk: Another question, for a user perspective I am not aware there is an XDR org provisionned. I purchased another product what occurs to this account. @Jyoti: It is like a shared service IROH, with a new provisioning it will generate something separately. @Kelli: can you explain it again to me. If a customer does bring in an existing XDR and attach to the suite, we're assuming these common services will not be part of? @Jyoti: in a suite, if XDR does not exist, the tenant is used as the shared. If they set up before then it is separate. @Kelli: what will be different for a customer greenfield breach suite vs brownfield scenario. What would be different. @Jyoti: If this is new, it will not have its own set of integration. When you go to that XDR, SE and DI UI, it can appear completly different because the integration will be entirely different. @Kelli: is the customer will be expecting this. @Travis: we must talk before and after platform. XDR have multiple. Some of these formely products shoudl migrate to reconcile duplication. We don't have platform services, in two quarter to go to that process to get everything converge. @Kelli: I hear you Travis, I'm glad we are planning the future. But what about user expectation. We are pruning use cases that the user will not have because we put in a new account and information will be destroyed. Is that not the only thing that will be different. I'd like to pose some questions. In term customer expectation. Do you have any though Olga? For the a user could attach a XDR tenant to a suite, in a greenfield scenario every product communication but this will break with brownfield scenario. @Travis: it is broken because the it's not the same login. It goes far broader. @Kelli: I'm glad you broad that up. It impacts other things as well. @Olga: we don't want they have a worse experience if they bought instead of not buying it. @Kelli: is the current situation is not ideal. With this Brownfield scenario. we've got one of two path. Let it go with subpar experience, or we are specific not allowed attaching of these things untile we solve this. @Anthony_Brandelli: let me jump here. Let's talk just about the attach function. That shouldn't change the current state. It's going to be no different. We would prefer to get better. We should try as a customer. We keep jumping different concept between different calls. @Kelli: What I'm hearing you don't see it's a problem. @Anthony this is a problem, but not where this is a problem. I am looking to be more specific. The problem, is not in this first step doing the attach. @Kelli: link to SCC I don't think there is a problem there. "Product Instance Invitation Flow" should be fine. But when it is broad in a Suite, this is where ther is a problem. @Anthony: Have we tried common scenario? @Kelli: no @Jyoti: A question is, if there is a suite, should a user could be allowed to bring an XDR org into this one? They have everything is working. Later they want bring in XDR. @Travis: example about different tier. @Travis: if a customer buy somthing from us they should have the right to use it. @Kelli: I can propose to share a miro board to building out the cases. We want this to work, and this case we need to talk about it. @April: I did reach out to the UX team, Brian Mallone. They are working on Suite UX. Only Greenfield only for now. They already have a miro board. I'm not sure it will be in timeline for brownfield. They are still on greenfield. I think we should brought Brian to see what they already have. @Prerna: we are good for XDR customer but for Breach Suite we need to make a call. @Kelli: I am not sure what that means between alocard and Suite. @Prerna: Danny and the group are working on that list. @Kelli: check conversion request has also purshached a suite. @Alain_Soucie: In the miro board make ti clear about area where a manual fix is not available.

MEETING AI sync work meeting

[2024-02-12 Mon 17:05] @Derek: doing the PGM stuff @Prena: PO of this work. Q3 and longer. Added Derek as PGM and Michelle and Houman. with docs and QA effort. Our feature team, doc, QA. Glad everybody was able to join.

Project board: https://github.com/orgs/advthreat/projects/44/views/1

Question about the structure of the meeting?

@Sabrina: would be useful to have people from the AI team. Because the backend will be working with the AI, but not really for us the UI.

@Brook: whoever is going consuming the endpoint we'll building make sense here.

@Prerna: Setup connection. Enabled XDR UI, Vercel and AWS VPC (AI UI) API Gateway or not? @Trent: worked on a gateway for INT. Direct VPC communication route is not able yet. @Sabrina: who to talk to. @Masaki: a name? @Prerna: let's follow up with Jyoti. AI Ops team offline. @Brooke: have you done Server Side Events (SSE). @Sabrina: would you talk with them? @Prerna: Jyoti talking about it. @Yann: we could create an API Gateway, but it will not support SSE.

@Prerna: look at the toast. Access token. @Yann: doc provided @Trent: looks good, need to take a closer look. @Prerna: Sabrina question? @Sabrina: onboarding work? Doing the toast, they are onboarded? @Trent: onboarding done. You just click a little thing and got the 3 modals. It is in localStorage.

@Prerna: looking latest Figma links.

MEETING Revoke Token Design work meeting

CLOCK: [2024-02-12 Mon 18:00]–[2024-02-12 Mon 18:50] => 0:50 CLOCK: [2024-02-12 Mon 17:03]–[2024-02-12 Mon 17:54] => 0:51

[2024-02-12 Mon 17:03]

We have access and refresh tokens. (There are also session token, kind of access token but can only be created during login, login is not an OAuth2 flow, this is like a custom OAuth2 Authorization flow).

Goal:

Expose an endpoint to revoke tokens
- refresh token: an application has been authorized by a user. They get a refresh token. That user authorized this application multiple times (potentially on different devices). The user would like to prevent this application to use this refresh token again.
- access token: we would like to prevent this access token to work again (max age 24h on server, cannot be changed). For this the current revocation mechanism is ok.

Other missing but important aspect of revocation. During OAuth2 flow.

MEETING Brownfield Meeting work meeting

CLOCK: [2024-02-12 Mon 16:30]–[2024-02-12 Mon 17:03] => 0:33

[2024-02-12 Mon 16:30] @Prerna: Questions about Brownfields How many customers we have provisioned so far.

@Danny: only Superball, but not finished the script.

@Prerna: concern with PIAM PGM. @Danny: Kelly, concerned about the Breach Suite. It's done from us to remove geo restriction of the suite. We cannot link EU XDR while paying on NAM-only Breach Suite.

@Danny: EA (Enterprise Agreements) 3 years come with other stuff.

2024-02-13 Tuesday

MEETING Q4F24 Priorities work meeting

CLOCK: [2024-02-13 Tue 17:06]–[2024-02-14 Wed 14:08] => 21:02

[2024-02-13 Tue 17:06]

Agenda (to discuss about) https://ciscosecurity.aha.io/bookmarks/epic_priority_lists/7327660358823831258/7335125708892975084
Notes
- INFRA-Expand Cisco XDR geo
  - @Crystal need to discuss with Engineering. After the SX EOL it would be a lot easier to accomplish that.
  - @Gayan staging env.
  - @Namrata, Engineering taking a deeper look right now knowing this is a priority on next quarter. Automation, modernizing some infra.
  - @Brianna, more business operation oriented, we need a certain state for Q1.
- Reduce false positive incidents
- MITRE phase 2
Actions

2024-02-14 Wednesday

MEETING Option 1 of PIAM using IROH work discussion

CLOCK: [2024-02-14 Wed 14:08]–[2024-02-14 Wed 19:34] => 5:26

[2024-02-14 Wed 14:08]

Option1 - A minimal headless IROH tenant to serve other common services and UI

1 SCC account <=> 1 IROH headless account. Same as an unactivated org but has an enterprise_id and no Entitlement. Onboard: CSC and DI during provisioning.

What about SXO and SCA? Without SXO/SCA it will imply a change in the UI to have a specific UI for these "headless XDR Orgs"

User PIAM token can be exchanged for a User IROH token in this headless Org.

Working services:

iroh-auth
iroh-int
iroh-sse
iroh-api-gateway
iroh-webhooks

Scenario - Common IROH without XDR

Integrations

There will be a new scope for integrations called 'enterprise'. This scope will imply that the integration can only be configured via the SCC UI and will show up as read-only in the XDR UI.

What is an "integration" in this context and how XDR UI could be able to show one?
Once the integration is configured, interactions with it can be supported via the IROH API gateway/IROH proxy from the common iroh tenant. DI will use the iroh proxy to communicate with its sources.

If an integration is like a common module. Currently SCC do not use the onboarding directly. We only support onboarding for: CSC, DI, SCA and SXO. It would mean DI could not use any other module until other team support the onboarding process and SCC is able to use it.

Scenario - Separate XDR tenant in the enterprise

What about Org switching? Should we hide the headless Orgs in the org selector in XDR UI?

With the actual system, DI can already keep refresh tokens for all tenant.
And using the ~enterprise_id~ as indicator can know which XDR tenants are related together.

So I am not sure we need an exchange mechanism as DI can, at any time, have a token for any XDR org or headless org.

As the user purchases XDR, a new iroh tenant will be spun up for XDR in the enterprise

Provisioning

The XDR IROH tenant will be provisioned by PIAM when a license is acquired for XDR. This will be a fully functional IROH tenant will all XDR services being available

Suite Applications

The services this IROH tenant spins up upon being provisioned are the XDR specific service:

SXO - Orchestration/Automate
SCA - Analytics
DAP - Data lake

Integrations

The XDR Integrations UI will show the available and configured integrations using existing mechanisms.
The integrations in the XDR tenant will NOT be used by DI. They will only be used by SXO, enrichment and DAP (Engineering ask to PM)
The iroh-proxy service will only serve XDR components
This will ensure that DI in the common iroh tenant doesn't need to be notified of the XDR integration sources
The common integrations will not be used by XDR components (Engineering ask to PM). This will ensure the separation of iroh-proxy services to their own tenants.

TBD: There might be a need in the future to show integrations from the common iroh tenant as read-only

Common DI-XDR communication

The DI module is used for enrichment and DI sends updates to XDR when assets are updated. In order to continue using this functionlity,

The DI module will need to be used with the IROH-auth token for the common iroh tenant. In the future when the PIAM auth is available, it will use that as the module auth-type. The XDR tenant will need a client to talk to the common iroh tenant for this purpose.
As there are asset updates in DI, the XDR tenant will need to be notified. For this, DI will need to be able to call the XDR tenant API using an iroh-auth token that will work.

iroh to iroh communication

Since there is a need for both the common iroh and the XDR iroh to talk to each other for the shared DI, there will need to be an oauth handshake when the XDR iroh tenant is provisioned with the common iroh tenant. This will result in both backends having iroh-auth tokens to talk to each other.

As more XDR tenants are added to the enterprise, they will also go through the handshake with common iroh similar to above.

Pros

Closer to the platform model where the common services are separated from XDR services
Data retention policies can be applied to XDR independent of common iroh
Telemetry for XDR not mixed with common iroh
Allows for a model for common integrations for the shared services

Cons

Need to establish communication between 2 iroh tenants
Need to maintain separate iroh-auth tokens in the browser for common and XDR UIs or build a mechanism to get these tokens at run-time for the UI

2024-02-15 Thursday

MEETING SCA Meeting for fixing tenants work meeting

CLOCK: [2024-02-15 Thu 18:29]–[2024-02-15 Thu 22:14] => 3:45

[2024-02-15 Thu 18:29]

Agenda (to discuss about)
Notes
Actions

MEETING XDR v2 instant demo work meeting

CLOCK: [2024-02-15 Thu 16:00]–[2024-02-15 Thu 17:14] => 1:14

[2024-02-15 Thu 16:00]

Agenda (to discuss about)
Notes
Actions

2024-W08

2024-02-20 Tuesday

CANCELED [#B] Estimate Common Org Option 1 work

SCHEDULED: <2024-02-26 Mon 10:00>

State "CANCELED" from "IN-PROGRESS" [2024-02-29 Thu 18:53]
we'll go with option 2

[2024-02-20 Tue 20:45]

MEETING SX EOL work meeting

CLOCK: [2024-02-20 Tue 20:22]–[2024-02-20 Tue 21:01] => 0:39

[2024-02-20 Tue 20:22]

Agenda (to discuss about)

2024-02-21 Wednesday

MEETING SCA Convergence to XDR work meeting

CLOCK: [2024-02-21 Wed 17:06]–[2024-02-21 Wed 17:57] => 0:51

[2024-02-21 Wed 17:06]

Agenda (to discuss about)
- We develop an execution plan.
- Establish and build Epics.
- Then commiting for Q4 and beyond.
Notes
Actions

2024-W09

2024-02-26 Monday

MEETING Meraki Geo work meeting

CLOCK: [2024-02-26 Mon 20:01]–[2024-02-28 Wed 18:57] => 46:56

[2024-02-26 Mon 20:01]

Agenda (to discuss about)

Hello Team,

Sorry for the Friday meeting, we still have a few items that came up in our discussion today. I am adding Jyoti and Yann to discuss further. @Yann, I know it’s late for you so we can record the meeting and follow up async.

Possible discussion points: How should we map a region from Meraki Dashboard to XDR? Is there a way to pull this via API or during OAUTH exchange? Do the URLs vary between regions or are they proxied? Are clients specific to a region? Could the client belong to multiple region?

Notes Waiting for @Jyoti. Andy Yong. Global client.

Actions Return URLs per region.

2024-02-28 Wednesday

MEETING API DEsign Meeting work meeting

CLOCK: [2024-02-28 Wed 18:57]–[2024-02-28 Wed 21:15] => 2:18

[2024-02-28 Wed 18:57]

Agenda (to discuss about)
Notes

Status Updates

@Mark spin up multpile http proxies to have multiple IPs

@Matt Kafka vs SQS discussion. Should end up with kafka probably shared with Automation.

@Yann Status update

Brownfield blocked by PIAM currently.
from DI: dump XDR vs SX orgs for data usage
FMC proxy: Wanderson put a lot of effort to make this work, currently blocked due to FMC lack of confidence, need more testing.
New Clients with Meraki (I will create them, I do not have a list of scopes yet I will probably use the ribbon one)
New Clients for Automation (Santosh)
request to remove XDR flag?
request to re-provision SCA for TMEs
AI confusion why not use modules? @Jyoti, need to use the same session token. @Jyoti, add a flag
option-1 sizing: in progress @Jyoti, go to option 2 only. everything is shared. Common IROH tenant. Question: will DI be external, like no XDR tier.

@Jyoti to @Guillaume add new statuses.

Actions

prevent different tenant with the same enterprise.

2024-03-01 Friday

DONE Meraki Clients discussion work

SCHEDULED: <2024-03-01 Fri 11:00> [2024-03-01 Fri 09:47]

2024-W10

2024-03-04 Monday

MEETING Meraki OAuth Effort work meeting

CLOCK: [2024-03-04 Mon 18:37]–[2024-03-04 Mon 20:47] => 2:10

[2024-03-04 Mon 18:37]

Agenda (to discuss about)
Notes
- @Evan_Johnson; effort private beta with OAuth Effort.
- Vasundra PM.
- Familiar from Ken Mayer.
- @Ken
  - We're building a OAuth2 server. Integration testing between Meraki Auth et Meraki API for 3rd parties. For now XDR to start with. No UI, no UX. Vanilla OAuth. We just have API key. Only two per person. Two way OAuth authorization. RFC 6749. Could not use PIAM because the user base is too different.
- @Jyoti talk to Sindhu Gopi, for PIAM team, because they don't want us to do that.
  
  @Questions:
  - server 2 server ?
  - access token format ? JWT ?
    - scopes in the JWT?
  - refresh token format ? JWT / something else ?
Actions

2024-03-05 Tuesday

MEETING XDR Admin & Management Core Team work meeting

CLOCK: [2024-03-05 Tue 18:05]–[2024-03-05 Tue 19:08] => 1:03

[2024-03-05 Tue 18:05]

Agenda (to discuss about)
Notes
Actions

2024-W11

2024-03-11 Monday

MEETING JIRA Handoff work meeting

[2024-03-11 Mon 19:59]

DONE Prepare a SCC MFE deep-dive presentation work

SCHEDULED: <2024-03-11 Mon 12:00> [2024-03-11 Mon 19:59]

CHAT Shams Jamal to ask for revert and test work chat

[2024-03-11 Mon 18:52]

CHAT Pujan to revert webhook change (as warned) work chat

[2024-03-11 Mon 18:48]

DONE Updated IROH-Auth doc on login work

[2024-03-11 Mon 18:24]

CHAT Help Jeff Markey on entitlement API work chat

[2024-03-11 Mon 18:23]

DONE Appeler Sundesk pour la RFID work

SCHEDULED: <2024-03-12 Tue 10:00> [2024-03-11 Mon 18:18]

CHAT Provided TAC Portal ro access to Roman Eremin work chat

[2024-03-11 Mon 18:17]

CHAT Told Constantin Deleanu to call Murali if SXO onboarding fails work chat

[2024-03-11 Mon 18:17]

CHAT Explain re-onboarding script update to Danny work chat

[2024-03-11 Mon 18:16]

CHAT Changed the SXO webhook for Pujan Trivedi work chat

[2024-03-11 Mon 18:16]

MEETING Jerome & Patrick discussion work meeting

[2024-03-11 Mon 18:55]

CHAT Put XDR Flag on 2 XDR org for Soumya work chat

CLOCK: [2024-03-11 Mon 18:15]–[2024-03-11 Mon 20:01] => 1:46

[2024-03-11 Mon 18:15]

DONE Repondre a SXO webhook work

SCHEDULED: <2024-03-11 Mon 17:30> [2024-03-11 Mon 16:42]

IN-PROGRESS Morning tour work

CLOCK: [2024-03-11 Mon 08:02]–[2024-03-11 Mon 08:37] => 0:35

[2024-03-11 Mon 08:02]

2024-03-13 Wednesday

CANCELED Talk to Kirill about the hackaton idea work

SCHEDULED: <2024-03-14 Thu 11:00>

State "CANCELED" from "TODO" [2024-03-15 Fri 10:24]

[2024-03-13 Wed 18:38]

MEETING API Design Meeting work meeting

[2024-03-13 Wed 18:24]

Agenda (to discuss about)
Notes
- PIAM & SCC
- Ops modernization
- AO boostraping OOM issue
- Telemetry missing events
Actions

DONE Prepare new steps for Provisioning work

SCHEDULED: <2024-03-14 Thu 11:00> [2024-03-13 Wed 18:01]

Headless: DI & CSC XDR: DI, CSC, SXO, SMA Update: add SXO & SMA

CANCELED Produire le PIAM Token Exchange endpoint work

CLOSED: [2024-08-12 Mon 10:03] SCHEDULED: <2024-03-18 Mon 11:00>

State "CANCELED" from "HOLD" [2024-08-12 Mon 10:03]
State "HOLD" from "HOLD" [2024-03-27 Wed 18:16]
on hold
State "HOLD" from "IN-PROGRESS" [2024-03-27 Wed 18:16]
on hold

CLOCK: [2024-03-13 Wed 17:57]–[2024-03-13 Wed 18:41] => 0:44

[2024-03-13 Wed 17:57]

MEETING PIAM Ryan Meeting work meeting

CLOCK: [2024-03-13 Wed 16:15]–[2024-03-13 Wed 17:57] => 1:42

[2024-03-13 Wed 16:15]

Agenda (to discuss about)

Can a token have:
- multiple headless tenant (1 per region, multiple per region?) who would be in charge of preventing this?
- multiple XDR tenant? (I think the answer is yes)
Two "Token Exchanges" usage:
1. User uses SCC UI, they get a PIAM token, we need to select and show them an IROH Org (headless tenant)
2. DI has a PIAM Token, they use this PIAM token directly or we need to provide some IROH Access Token to continue to use a working mechanism with modules.

For case 1. How can we ensure to select a single Org?

For case 2. My guess is that we can:

Create an API asking for a specific tenant and provide the token for it
Create an API that returns all tokens for all valid tenants (XDR & Headless).

Notes

1 Platform Service Group.

Enterprise -> Region -> PlatformGroup -> IROH Org -> SSX Tenant

Keep track of the product-tenant-id inside the Org.

Add a query param to the UNIVERSAL PROVISION API to distinguish between Headless/XDR.

Actions

CHAT SXO webhook conf change room work chat

[2024-03-13 Wed 15:55]

CHAT Blocker, SXO onboarding failing discussion room work chat

[2024-03-13 Wed 15:55]

CHAT Brownfield using NAM instead of PREVIEW for TEST room work chat

CLOCK: [2024-03-13 Wed 15:54]–[2024-03-13 Wed 16:15] => 0:21

[2024-03-13 Wed 15:54]

2024-03-14 Thursday

CANCELED Write Token Exchange API Issue work

CLOSED: [2024-08-12 Mon 10:03] SCHEDULED: <2024-03-18 Mon 10:00>

State "CANCELED" from "HOLD" [2024-08-12 Mon 10:03]
State "HOLD" from "IN-PROGRESS" [2024-03-28 Thu 18:31]
asked to hold this work

[2024-03-14 Thu 16:35]

2024-03-15 Friday

DONE Disable rate-limit for client-8d4dc846-0424-4aeb-a3fa-b93b5f76cc3c (Santosh) work

SCHEDULED: <2024-03-15 Fri 16:00>

[2024-03-15 Fri 15:33]

DONE Add XDR flag for Josh Tompkins (webex DM) work chat

SCHEDULED: <2024-03-15 Fri 14:00> [2024-03-15 Fri 14:25]

DONE Open new emails for James Moser Org webex-msg work

SCHEDULED: <2024-03-15 Fri 16:00> [2024-03-15 Fri 09:30]

DONE Promote two SXO client org-level-auth + everyone + trusted work

SCHEDULED: <2024-03-15 Fri 10:00> [2024-03-15 Fri 09:16]

DONE Add XDR flag to org for SXO work

SCHEDULED: <2024-03-15 Fri 10:00> [2024-03-15 Fri 09:16]

2024-W12

2024-03-18 Monday

MEETING Brownfield check meeting work meeting

[2024-03-18 Mon 17:36]

Agenda (to discuss about)
Notes
Actions

MEETING SX EOL, support Secure Client UI on top of the rest work meeting

[2024-03-18 Mon 17:36]

Agenda (to discuss about)
Notes
Actions

CHAT Add SXO clients to trusted, rate-limit removed work chat

CLOCK: [2024-03-18 Mon 17:35]–[2024-03-18 Mon 21:43] => 4:08

[2024-03-18 Mon 17:35]

2024-03-19 Tuesday

MEETING SX EOL bi-weekly work meeting

CLOCK: [2024-03-19 Tue 19:36]–[2024-03-19 Tue 23:22] => 3:46

[2024-03-19 Tue 19:36]

Agenda (to discuss about)
Notes @Maribell phase 1 meeting yesterday with Dario. Dario will create a phase 2 Epic. The existing Epic will be phase 1.

@Prerna: you all attended SX EOL last week, discussed with external product. IROH Tenant creation for Secure Client, Umbrella, etc… There will be a "common" IROH tenant that will work like SecureX. If there is no XDR Entitlement it remains in the background.

We will give them an Interim UI, trimmed down version of XDR UI.
- only My Account Page
- Integrations
- Users Management
Just Secure Client Devices, and some admin pages.

Users should not be able to perform the following actions with this UI:
- Any incident activity
- Incident investigation
- Automation workflow and response action

For existing orgs, in SX supporting Secure Client. We need a list of those orgs from our PM team. We will add that flag to those orgs there will be a differentiation between XDR and Trimmed down UI. There will be a visual indication in the Registration UI.

@Jyoti: Do we want to show the ribbon in the interim UI? @Robert, @Dar, @Jyoti: no, easier, not really useful.

@Prerna:

Role Management.

Error pages
Actions

DONE Answer for SXO webhooks msg work

SCHEDULED: <2024-03-19 Tue 10:00> [2024-03-19 Tue 09:10]

2024-03-20 Wednesday

MEETING API Design Meeting work meeting

CLOCK: [2024-03-20 Wed 17:31]–[2024-03-20 Wed 22:16] => 4:45

[2024-03-20 Wed 17:31]

Agenda (to discuss about)
Notes
Actions

2024-03-21 Thursday

DONE Revert webhook conf for SXO work

SCHEDULED: <2024-03-21 Thu 14:00> [2024-03-21 Thu 09:33]

2024-03-22 Friday

CHAT Proposal for impersonation room work chat

CLOCK: [2024-03-22 Fri 09:11]–[2024-03-22 Fri 09:25] => 0:14

[2024-03-22 Fri 09:11]

Good morning!

I think in regards to the meeting we had yesterday I can propose the following:

keep the impersonation UI inserted inside XDR only in INT and TEST as this is great for UI dev (and probably also backend devs) but might be a risk in PROD just to make it discoverable from the UI js code.
create another impersonate endpoint that will generate a session token for the Org Virtual user which will be read-only. And use the "impersonate with a link" method, which mean it would be easy to deploy a UI behind the VPN (similar the TAC Portal) that could use this for PMs need of just taking a look without affecting the telemetry (for the telementry to be used, the token should have telemetry:write scope, which will be removed from this specific token)
For TAC I think the blocker is related to the user aknownledge and approval of being impersonated. And for that, I don't think we have a technical solution yet so I will keep the impersonate endpoint hidden out of the TAC API until the UX is clearly defined.

2024-W13

2024-03-25 Monday

MEETING Brownfield work meeting

[2024-03-25 Mon 15:31]

How things are going Danny?

Looks ok.

@Houman: nothing rest to be done on our side @Danny: Simon did mention a similar API for batch update

CHAT Fix wrong ff on TEST org work chat

[2024-03-25 Mon 14:14]

T.J. Busch

Hi Yann, Not sure if you can help with this / fix it easily but it looks like on Friday one of our Teams XDR accounts had the xdr feature flag remvoed and replaced with cisco/feature-flag/xdr-ai-assistant. Are you able to quickly add back cisco/feature-flag/xdr or should the xdr-ai-assistant cover the XDR flag as well and would need to be investigated further by whatever team added it to our acct?

Test Env, Org:755757aa-5a62-4938-b9dc-1d57b301d6cc

CHAT Answered to AI Onboarding work chat

CLOCK: [2024-03-25 Mon 10:08]–[2024-03-26 Tue 08:47] => 22:39

[2024-03-25 Mon 10:08]

2024-03-26 Tuesday

DONE Provide Sizing of XDR-E-164 Aha work

SCHEDULED: <2024-03-28 Thu 14:00> [2024-03-26 Tue 19:47]

MEETING SX EOL Phase 1 Planning work meeting

[2024-03-26 Tue 19:05]

Agenda

Any questions for PM?
- Decision on landing page?
Engineering Questions
- Yann - do we need to set-up INT and TEST domains or just the PROD URLs will suffice I think it makes more sense to use the same pattern for a new domains and have a specific domain for INT, TEST and all 3 PROD region.
- Jyoti - domain name for the SCC interim UI. Does the PIAM team have a preference?
- Dar/Derrick – Error pages update
- Murali - We have a couple of MDR tenants listed below, who are heavy users of the Automation workflows today. This morning, I asked Briana to check if they have already shifted from SecureX to XDR. If not, have they been informed or is it being taken care of? I brought up this concern to prevent any unexpected surprises for the MDR folks after SecureX EOL. It would also be beneficial to ascertain if they have shifted all their current organizations to XDR, or to understand their strategy concerning this EOL efforts.
  - Current MDR Tenants (NAM)
    - tenant=42ac91b9-d9df-48d8-a1d0-8c76988d0a9f / tenant_name=MDR-Stage-RTP12
    - tenant=e26d4c89-5942-48b3-89de-95495537b012 / tenant_name=[DEV] Cisco Managed Services -Operate, Cisco Systems
    - tenant=c87b61da-dd8a-4aac-8ccb-4ef4329e1bfe / tenant_name="Cisco Managed Services - Operate, Cisco Systems

Any other open questions for Phase 1?

Prerna - Feature estimation and release planning

Notes

Landing Page

@Maribell: 1st question, landing page? @Dar: Use the landing page of Secure Client UI @Prerna: first question for landing page. We don't need MFE and just a landing page.

URLs ok

Domain preferences (Jyoti to check)

Error Page

@Derrick, add some message, contact.
@Yann, still possible to see error page from both XDR and Interim UI.
@Prerna: see where these error are appearing. Be sure there is no XDR mention. Branded to Cisco and not XDR, nor SX. So not a must have.
@Maribell: nice to have

other notes

release target?

Dar, impact on Q3? @Prerna: ops work on new domains Interim UI Dev. @Maribell: when is your team starting? Rough estimate? @Dar not yet, this week.

@Jyoti: we shouldn't add XDR flag automatically for internal orgs.

@Yann Ask Question: what is the behavior for SX-only, disabled, data deletion, etc…? @Jyoti: yes @Prerna: we will see with PM, we cannot take the decision ourselve

@Prerna: invitation links to update

Actions

@Yann: add SC flag or XDR flag for orgs with clients with availability everyone.
Use two roles for Interim UI (Secure Client)
Update invite URLs

Provide Sizing

2 releases in April, rest for Q4.

XDR-E-164

CHAT Provisioning tokens msg work chat

[2024-03-26 Tue 18:57]

CHAT Discuss about AI provisioning work chat

CLOCK: [2024-03-26 Tue 08:47]–[2024-03-26 Tue 20:09] => 11:22

[2024-03-26 Tue 08:47]

DONE Update Meraki clients (redirects) work

[2024-03-26 Tue 08:47]

2024-03-27 Wednesday

DONE Check AI API onboarding if it is difficult work

SCHEDULED: <2024-03-28 Thu 10:00> [2024-03-27 Wed 18:51]

MEETING AI Provisioning meeting work meeting

[2024-03-27 Wed 18:31] Check if this would be difficult to use the actual API

MEETING API Design Meeting work meeting

CLOCK: [2024-03-27 Wed 17:31]–[2024-03-27 Wed 18:51] => 1:20

[2024-03-27 Wed 17:31]

CII Auth? (Dar is here)
Going CAP for a customer
Discussion about the product https://app.vidcast.io/share/80d99919-ee01-4592-95dc-f404d3ef3673
@Eric discuss about verdict and caching
@Jyoti TTP

DONE Repondre au FMC proxy room work

DONE Help Meraki msg work

DONE Create Dashboard UI Clients in TEST and PROD

DONE Fix FMC Proxy issue with Bearer

DONE PR to add :r and :w to the scopes

2024-03-28 Thursday

CHAT fix Meraki redirects in TEST work chat

CLOCK: [2024-03-28 Thu 12:15]–[2024-03-28 Thu 18:32] => 6:17

[2024-03-28 Thu 12:15]

2024-03-29 Friday

CHAT Search for user without any user-name work chat

CLOCK: [2024-03-29 Fri 19:17]–[2024-03-29 Fri 22:14] => 2:57

[2024-03-29 Fri 19:17]

["not",{"like-match":["_%"],"search-in-paths":[["user-name"]]}]

DONE Answer to Engine room work

SCHEDULED: <2024-03-29 Fri 10:00> [2024-03-29 Fri 09:12]

DONE Take a look at doc msg work

SCHEDULED: <2024-03-29 Fri 10:00> [2024-03-29 Fri 09:10]

DONE Answer to Meraki msg work

SCHEDULED: <2024-03-29 Fri 10:00> [2024-03-29 Fri 09:10]

DONE Retrieve SCSO name field msg work

SCHEDULED: <2024-03-29 Fri 10:00> [2024-03-29 Fri 08:48]

PIAM Provisioning does not provide any user name (search for issue)
SCSO should provide a user name
user-name is not a mandatory field for a user, due to these specific temporary case where the user is created and need to be used before the name field exists

Good morning everyone,

First things first:

the only fields that are guaranteed to exist for a User are:
- user-id
- org-id
- role
- scopes
- enabled?
- create-at This is visible from the public User schema visible via Swagger UI for example. (can be found here https://visibility.amp.cisco.com/iroh/profile/index.html#/Profile/get_iroh_profile_accounts) See screenshot too where mandatory fields are marked by a red asterix.
When and why a User might not have a user-name field?
1. We recently introduced PIAM universal provisioning. This new mechanism does not provide any user name. So a user is created in our DB with only a user-email. Until the user login via SCSO, the User will not have any user-name.
2. If SCSO does not provide any User name during the login step. While this is technically possible for SCSO not to provide this field I doubt that SCSO do not enforce the user name to be mandatory. More technically, we use the `name` claim from the `id_token` returned by PIAM during the OpenID Connect login flow.
3. SPECIAL CASE; in particular for playbook, Automation generate tokens for Org Virtual Users. Such virtual users are a Virtual ADMIN user. The user-name (as well as user-nick) for these virtual user exists and is set to the Org Name (which is guaranteed to exists). For obvious reason these virtual users do not have any user-email field. We use these virtual users to ensure that any admin of an org can be disabled without breaking an OAuth2 integration.

2024-W14

2024-04-02 Tuesday

DONE Check search-users optimization work

SCHEDULED: <2024-04-02 Tue 10:00> [2024-04-02 Tue 12:10]

DONE Check FMC bug msg work

SCHEDULED: <2024-04-02 Tue 10:00> [2024-04-02 Tue 10:45]

DONE Answer Olympics invitation issues jira work

SCHEDULED: <2024-04-02 Tue 10:00> [2024-04-02 Tue 10:37]

2024-04-03 Wednesday

DONE XDR Threat Response Workshop work

SCHEDULED: <2024-04-03 Wed 10:00> [2024-04-03 Wed 18:18]

DONE Answer to FMC for deploying in TEST work

SCHEDULED: <2024-04-03 Wed 10:00> [2024-04-03 Wed 18:17]

DONE Fix invitation bug, renew a few customer invites work

SCHEDULED: <2024-04-03 Wed 10:00> [2024-04-03 Wed 18:16]

MEETING Threat Hunting Workshop work meeting

CLOCK: [2024-04-03 Wed 11:03]–[2024-04-03 Wed 21:47] => 10:44

[2024-04-03 Wed 11:03]

Build a lab that replicate a real life attack.

Presentation:

I am Yann Esposito, I am a software engineer specialized in authentication and authorization. I built the XDR authentication and authorization engine which is an OAuth2 and OpenID Connect Provider.

Favorite number, 42 because this is the answer to Life the Universe and Everyting, second favorite number is the 5th tower of power of 2

Least favorite password, the DUO ones, that are only 4 numbers.

What would you like to get out of this?

I which to understand what our customer are experiencing and perhaps find inspiration for new features I could push.

SOC:

2024-04-05 Friday

DONE Provide github tickets to Prerna msg work

SCHEDULED: <2024-04-05 Fri 10:00> [2024-04-05 Fri 10:17]

DONE Config les Client Automation Rules cs DM Santosh work

SCHEDULED: <2024-04-05 Fri 10:00> [2024-04-05 Fri 09:50]

Santosh Kumar Aitha • Below are Prod Clients to be marked as org virtual user and mark to as "everyone" along with ratelimits

APJC:

client-1b94b23c-e61d-4d2f-9455-9a1dd222c338 —> disable rate limit client-443ae2d6-b440-4b5a-a2d4-e2a605181e8f

EU:

client-ef005243-4a5e-41ad-8e9e-0cc6e487d8e7 —> disable rate limit client-05b641cc-d596-4ad7-bc63-b63522b41ef3

NAM:

client-4ad2d3dc-038d-4f9e-acbf-68a047277526 —> disable rate limit client-ad4e2af1-c790-4457-bdd3-1a0e66f52506

2024-W15

2024-04-09 Tuesday

IN-PROGRESS Think about idle time mechanism work

[2024-04-09 Tue 17:54]

MEETING Suites QA test suite work meeting

CLOCK: [2024-04-09 Tue 16:03]–[2024-04-10 Wed 14:46] => 22:43

[2024-04-09 Tue 16:03]

Requirements solidified

2024-04-11 Thursday

MEETING RBAC Custom Roles work meeting

CLOCK: [2024-04-11 Thu 15:03]–[2024-04-14 Sun 21:33] => 78:30

[2024-04-11 Thu 15:03]

Notes

Provide scopes to PIAM,

from @Jyoti: too granular
@Arun this is almost custom roles.
@RobGresham: how do we sync the authorizations to PIAM.
- Enterprise want to understand between asset and casebook, enrich and event, etc…
- Presets should be in PIAM
@RobGresham: SCC:
Actions Write down technical spec
1. Create a new "Almost Empty Role" (telemtry:write, vault/... )
2. Create an API with a set of scopes for PIAM (all but the one in the Almost Empty Role)
3. Check with PIAM that the role + scopes will be provided in the id_token during login
4. Update IROH-Auth login to use the role and scopes from SCSO
  - if scope is admin, user or sat use it, otherwise use the new almost empty role and add the scopes to the additional-scopes of this user.

2024-04-12 Friday

DONE Update OAuth2 clients msg work

SCHEDULED: <2024-04-12 Fri 10:00> [2024-04-12 Fri 09:54]

2024-W16

2024-04-15 Monday

DONE Add sc flag to legacy provisioning API for SE work

SCHEDULED: <2024-04-15 Mon 10:00> [2024-04-15 Mon 17:55]

IN-PROGRESS Dev apps in Org work

CLOCK: [2024-04-15 Mon 16:55]–[2024-04-16 Tue 00:47] => 7:52

[2024-04-15 Mon 16:55]

CHAT Santosh (add asset scope to clients) work chat

[2024-04-15 Mon 16:45]

MEETING Brownfield disabled work meeting

CLOCK: [2024-04-15 Mon 16:31]–[2024-04-15 Mon 16:45] => 0:14

[2024-04-15 Mon 16:31]

@Danny; POV moting other to STC in Q4, their going to start with PIAM.

Entitlement removed
User with XDR-only roles

@Danny;

@Patricia: On XDR disabled. Make all admin, read-only. Disable non-admin.

2024-04-16 Tuesday

DONE Prepare a presentation about all use cases for SX EOL Phase 1 work

SCHEDULED: <2024-04-23 Tue 10:00> [2024-04-16 Tue 17:07]

What occurs during downgrade
What occurs for an XDR admin
What occurs for an SX admin when they go XDR after 31th July
What occurs to Sat user in XDR if they downgrade to SC?
What should be the roles

MEETING Core team SX EOL work meeting

CLOCK: [2024-04-16 Tue 16:35]–[2024-04-16 Tue 18:30] => 1:55

[2024-04-16 Tue 16:35]

Agenda (to discuss about)
Notes
Actions

DONE Merge apps in Org work

SCHEDULED: <2024-04-16 Tue 10:00> [2024-04-16 Tue 16:31]

DONE Fix invite flaky test work

SCHEDULED: <2024-04-16 Tue 10:00> [2024-04-16 Tue 16:30]

DONE Update PIAM link tenants work

SCHEDULED: <2024-04-16 Tue 10:00> [2024-04-16 Tue 16:30]

DONE Talk with Austin Haas work

SCHEDULED: <2024-04-16 Tue 10:00> [2024-04-16 Tue 11:44]

DONE Attach script for Danny work

SCHEDULED: <2024-04-16 Tue 10:00> [2024-04-16 Tue 10:41]

DONE Answer to Brooke about JWT with audiences work

SCHEDULED: <2024-04-16 Tue 10:00> [2024-04-16 Tue 10:41]

2024-04-18 Thursday

MEETING Meraki onboarding work meeting

CLOCK: [2024-04-18 Thu 16:32]–[2024-04-18 Thu 19:47] => 3:15

[2024-04-18 Thu 16:32]

Agenda (to discuss about)
Notes
Actions

2024-04-19 Friday

DONE Create a Test Org for Dan sc-only work

SCHEDULED: <2024-04-19 Fri 10:00> [2024-04-19 Fri 09:11]

2024-W17

2024-04-22 Monday

MEETING Brownfield work meeting

CLOCK: [2024-04-22 Mon 16:30]–[2024-04-23 Tue 10:15] => 17:45

[2024-04-22 Mon 16:30]

relink.

Reversion of XDR account. Check with roles.

2024-04-23 Tuesday

IN-PROGRESS Engine client on INT deactivated work

CLOCK: [2024-04-23 Tue 14:32]–[2024-04-24 Wed 20:06] => 29:34

[2024-04-23 Tue 14:32]

DONE UI for feature-flags work

SCHEDULED: <2024-04-25 Thu 10:00> [2024-04-23 Tue 09:04]

DONE Review Mark PR token cache work

SCHEDULED: <2024-04-23 Tue 10:00>

CLOCK: [2024-04-23 Tue 10:15]–[2024-04-23 Tue 14:32] => 4:17

[2024-04-23 Tue 09:03]

2024-04-24 Wednesday

DONE Write a comment about redirection with SC and XDR work

SCHEDULED: <2024-04-24 Wed 19:00> [2024-04-24 Wed 18:59]

DONE Check JIRA ticket ticket work

SCHEDULED: <2024-04-24 Wed 10:00> [2024-04-24 Wed 10:19]

2024-04-25 Thursday

MEETING Custom Roles RBAC work meeting

CLOCK: [2024-04-25 Thu 18:02]–[2024-04-26 Fri 01:59] => 7:57

[2024-04-25 Thu 18:02]

Agenda (to discuss about)
Notes
Actions

MEETING Didi CII provisioning/integration with XDR work meeting

CLOCK: [2024-04-25 Thu 15:03]–[2024-04-25 Thu 16:06] => 1:03

[2024-04-25 Thu 15:03]

Customer need to define roles in their own IdPs.

Product does not support IdP initiated login.
@Didi: Okta is not enough to support Orgs
@Ryan: we will continu with Okta
@Didi: we must support customer RBAC from their IdP
Use docs https://wwwin-github.cisco.com/cisco-sbgidm/docs/blob/master/access-control/index.md
@Ryan: Focus technical discussion.
@Didi: 2% of DUO customer use private IdP, 50% of the logins

2024-04-26 Friday

MEETING Monthly work meeting

CLOCK: [2024-04-26 Fri 17:58]–[2024-04-29 Mon 17:01] => 71:03

[2024-04-26 Fri 17:58]

Pres:

Ops team moved toward using JSON. Still work in proress.
GE managed to cleanup the problem with SCA while still progressing on MITRE
Mario worked on adding a metric lib to improve our ability to understand the code
Kirill worked on notifications, worked on email format, notification preferences, automatic link to assigned incident,
Myself on SX EOL phase 1
Preparing for Q4

@Jyoti intro

Some escalation. Great to see how we resolved those issues. No blaming just great collaboration.

Updates

Ops

2 releases, and 100% up-time
disaster recovery gaps tests
SX EOL we are working on

Release status

2 releases, nothing surprised.
many patches in prod.
one patch today, and probably next week before RSA May 6, no prod Env.
Working checking everything is good before RSA.
Moved to JIRA, please reach out to Patricia

Engine

triage

Simonson

@Jyoti

Phase 1 SX EOL - July 31 Brand new UI for customer that did not upgrade to XDR but have Secure Client. SC has deps on DI.

CANCELED Check module msg work

SCHEDULED: <2024-04-26 Fri 10:00>

State "CANCELED" from "TODO" [2024-04-30 Tue 18:16]

[2024-04-26 Fri 09:06]

2024-W18

2024-04-29 Monday

MEETING But Santosh work meeting

CLOCK: [2024-04-29 Mon 17:01]–[2024-04-29 Mon 21:48] => 4:47

[2024-04-29 Mon 17:01]

Agenda (to discuss about)
Notes
Actions

DONE James Moser chat work

SCHEDULED: <2024-04-29 Mon 10:00> [2024-04-29 Mon 10:36]

DONE Hisan Mitre flag work

SCHEDULED: <2024-04-29 Mon 10:00> [2024-04-29 Mon 10:36]

2024-04-30 Tuesday

DONE AI Assistant Provisioning work

SCHEDULED: <2024-04-30 Tue 10:00> [2024-04-30 Tue 10:46]

DONE Ask Adam URLs for AI assistant provisioning work

SCHEDULED: <2024-05-01 Wed 10:00> [2024-04-30 Tue 18:15]

2024-W20

2024-05-13 Monday

DONE Lead Performance Reflections work

SCHEDULED: <2024-05-13 Mon 10:00> [2024-05-13 Mon 10:04]

Over the past six months, our team has delivered several significant accomplishments that have met and exceeded expectations based on each member's role:

Olivier:
- Added support for XDR Tier module filtering: This accomplishment has allowed the support of the monetization of our product.
- Delivered MITRE Matrix: By delivering this feature, Olivier helped improve the security posture of our clients by enabling them to align their security controls with industry-standard frameworks like MITRE ATT&CK. This has contributed significantly to our product's value proposition and market competitiveness.
- Improved node configuration mechanism: The improved node configuration mechanism has streamlined the setup process for our developers, reducing the time it takes for them to configure and deploy our product and opening a way to improve multi region support.

Wanderson:
- CDO Integration: This integration allowed us to continue to support SSE integration even after the planned SX EOL.
- PIAM Universal Provisioning: By adding support for PIAM universal provisioning, Wanderson built an essential part of the system to provision new XDR account for our customers.
- Added PIAM Brownfield account linking: This feature allowed our clients to integrate existing SecureX accounts with the PIAM platform, ensuring a smooth onboarding process and reducing the time required to adopt our product fully.
- To achieve these tasks, Wanderson also added JWKS support for external API providers like PIAM (Okta), FMC, and any other type of JWT provider: This addition has made it easier for us to integrate with third-party services, improving overall interoperability and flexibility.
Myself (Additional Contributions):
- Added the API and UI to manage feature flags: By providing a dedicated interface for managing feature flags, I have empowered other teams like UI developers, QA, POs, and PMs to make changes independently without relying on your team, thus improving overall efficiency.
- Helped architecture and plan detailed technical details for features: My involvement in the planning process has ensured that our product's development is well-coordinated and aligned with business objectives, leading to more successful feature launches.
- Helped other teams integrate with XDR/IROH (particularly SCA, Meraki, AI Assistant team): My efforts have facilitated collaboration between different teams within the organization, fostering a culture of cross-functional cooperation and driving innovation across various products.
- Started planning for providing long-running dashboard: This initiative will enable users to monitor their security posture over an extended period, improving overall visibility and decision-making capabilities. This will also improve our ability to make demos of our product.
- Technical Design to Improve XDR session security: My contribution has ensured that our product remains secure by implementing improvements in session security, thus protecting client data and maintaining trust with our user base.
- Assisted SXO with their new integration: By supporting the successful integration of another team's work into your own, I have demonstrated a commitment to collaboration and ensuring seamless experiences for all users across different products.
- Prepare the work for future PIAM integration into XDR: My proactive planning has set the stage for a smooth integration between our two platforms in the future, enabling us to deliver even more value to clients as we continue to grow and evolve.

2024-05-14 Tuesday

MEETING Core Team: SX EOL

CLOCK: [2024-05-14 Tue 16:35]–[2024-05-14 Tue 22:26] => 5:51

[2024-05-14 Tue 16:35]

Agenda (to discuss about)
Notes
Actions

DONE Write up the bomb SX EOL date issue work

SCHEDULED: <2024-05-15 Wed 10:00> [2024-05-14 Tue 16:57]

I feel there might be some confusion about the mechanism introduced to change the SX EOL technical date from the backend.

The SX EOL works will need a mechanism different from the usual release process.

Instead of having a change of behavior occuring after a realease we need instead to release a product that contains two different behaviors (see later for details) in the same release but will change after some date.

This put two difficulties:

testing before the date
rollback to previous behavior after the date

More technically:

After SX EOL, the business logic will change in the backend for SX-only users. From the discussion we had yesterday:

before SX EOL:
- most org works as of today
- for Org manually flagged to be "SC-only":
  - the scopes of their user will be different. These users will not be able to use SX nor XDR, they will be forced to use SC UI. And users in theses orgs will not be able to perform Automation actions, Response action or access private intel (manage incident in particular).
  - the modules will be filtered to only accept a few, I think only DI, CSC and SE (orbital does not use a module).
after SX EOL:
- XDR org => nothing change
- all SX orgs will be considered as if they had the SC-only flag (changed from our discussion yesterday)

In the UI the logic will also change:

before SX EOL:
- for XDR org reaching any UI (SX, SC, XDR) => redirect them to XDR
- for SX org (withouth the SC flag) reaching any UI => redirect to SX
- for SC-only org reaching any UI => redirect to SC Interim UI
after SX EOL:
- for XDR org reaching any UI => redirect to XDR
- for SX or SC org => redirect to SC UI

As consequence, for both the backend and the frontend code we need a place where we need to check if we reached SX EOL. And depending on that check, the code behaves differently.

Now, we face two issues:

testing both the before and after SX EOL behavior before the SX EOL date for QA in the TEST environment.
In case of major bug (any kind) be able to rollback to the behavior of before SX EOL.

A technical solution to this problem is to have the API to returns a boolean with "we've reached SX EOL". So both the backend and the UI could sync and know which behavior they should use.

And add an endpoint that QA could use to change the date of SX EOL in TEST, so QA could test both scenario in TEST.

Also, it is necessary to have the backend return the “we’ve reached SX EOL date” and not separate this check from the backend and the frontend to prevent UI bugs (due for example to browser date being wrong).

So I hope this clarify why we need this work and this is not due to SX EOL date change risk. This is necessary to handle a non standard release.

Best, Yann.

2024-05-15 Wednesday

MEETING API Design Meeting work meeting

[2024-05-15 Wed 18:34]

Agenda (to discuss about)
- @Yann: priorities:
  - SX EOL Phase 1, in progress
  - AI Provisionning (not sure what the status is, need to contact Adam)
  - AI/MITRE feature flags
  - Meraki Integration (add webhook on SCA module creation)
  - Browfield requests maintenance (looks ok)
  - Added work with Orbital / SE provisioning (part of SX EOL Phase 1 anyway)
Notes
Actions

MEETING SX EOL Orbital work meeting

[2024-05-15 Wed 16:37]

Agenda (to discuss about)
Notes
Actions

MEETING Integration Oort (CII) work meeting

CLOCK: [2024-05-15 Wed 15:00]–[2024-05-15 Wed 19:24] => 4:24

[2024-05-15 Wed 15:00]

Notes
- Andy and CII
- Yana: 1st: POC that Nico done on MFE auth strategy 2nd: CII Integration in General
1st: @Nico_Batalla micro-frontend,
Actions
- someone to send back the demo and video of the PoC

2024-05-17 Friday

IN-PROGRESS Ping Adam for URLs of onboarding work

CLOCK: [2024-05-17 Fri 10:39]–[2024-05-17 Fri 11:37] => 0:58

[2024-05-17 Fri 10:39]

DONE Answer Ihor work

SCHEDULED: <2024-05-17 Fri 10:00> [2024-05-17 Fri 09:54]

DONE Answer Austin Haas work

SCHEDULED: <2024-05-17 Fri 10:00> [2024-05-17 Fri 09:54]

2024-W21

2024-05-22 Wednesday

MEETING API Design Meeting work meeting

CLOCK: [2024-05-22 Wed 18:03]–[2024-05-22 Wed 22:03] => 4:00

[2024-05-22 Wed 18:03]

Data Analytics Platform.

Platform Team reach out to us to help. Sighting context. Incident Bundle.

Remote module, Yanis, and folks on our team that can work in python that can help out.

I need to identify in our team. Send someone from our team to them. Give me some names for people that will be candidate for that work.

They are making a lot of assumption on the data and mapping.

GE would be perfect.

Actions

Need names to work with SCA to work in Python.

DONE onboarding AI etc… webex work

SCHEDULED: <2024-05-22 Wed 10:00> [2024-05-22 Wed 09:06]

2024-05-23 Thursday

MEETING Redirection for SX EOL work meeting

[2024-05-23 Thu 17:37]

Logic for the new UI for SC before and after SX EOL.

@Jyoti: my understanding.

Before sx.

SX org should be redirected to SC UI. XDR should be redirected to XDR

IN-PROGRESS AI onboarding work

CLOCK: [2024-05-23 Thu 16:53]–[2024-05-23 Thu 18:26] => 1:33

[2024-05-23 Thu 16:53]

./ai-direct-onboard -e nam –org-id '8a64aced-2299-41be-9faa-5caf7a16043e' :nam,8a64aced-2299-41be-9faa-5caf7a16043e,aalishah@xentaurs.com,{:id "8a64aced-2299-41be-9faa-5caf7a16043e", :name "Xentaurs", :taskId "8a64aced-2299-41be-9faa-5caf7a16043e"} https://xdr-ai-api.us.security.cisco.com/api/v1/tenants {:cached nil, :request-time 926, :repeatable? false, :protocol-version {:name "HTTP", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x73e25780 "org.apache.http.impl.client.InternalHttpClient@73e25780"], :chunked? false, :reason-phrase "OK", :headers {"x-amzn-RequestId" "875c80c9-2209-4612-8e28-d2900d6080bc", "Content-Type" "application/json", "Content-Length" "49", "X-Ratelimit-Limit" "0", "X-Ratelimit-Remaining" "0", "x-amzn-Remapped-Content-Length" "49", "X-Ratelimit-Reset" "0", "Connection" "close", "x-amz-apigw-id" "YOrAuGLOIAMEblQ=", "x-amzn-Remapped-Date" "Thu, 23 May 2024 14:53:30 GMT", "Date" "Thu, 23 May 2024 14:53:31 GMT", "Vary" "Origin"}, :orig-content-encoding nil, :status 200, :length 49, :body {:taskId "8a64aced-2299-41be-9faa-5caf7a16043e"}, :trace-redirects []}

for o in 'a39fb3c0-47af-4b82-9a56-b4998f154217' '794047a5-b023-489e-b5ee-6407fcdf0daa' '674c5065-9567-4e71-808d-75cb4e8b5520' 'e44139d5-63bd-42dc-a548-62b3f4f5c749'; ./ai-direct-onboard -e nam –org-id "$o"; end :nam,a39fb3c0-47af-4b82-9a56-b4998f154217,mnaranjo@chla.usc.edu,{:id "a39fb3c0-47af-4b82-9a56-b4998f154217", :name "Childrens Hospital Los Angeles", :taskId "a39fb3c0-47af-4b82-9a56-b4998f154217"} https://xdr-ai-api.us.security.cisco.com/api/v1/tenants {:cached nil, :request-time 1404, :repeatable? false, :protocol-version {:name "HTTP", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x36cdcae0 "org.apache.http.impl.client.InternalHttpClient@36cdcae0"], :chunked? false, :reason-phrase "OK", :headers {"x-amzn-RequestId" "6a3df1e2-b9ca-4baf-9b14-836ef39cf44f", "Content-Type" "application/json", "Content-Length" "49", "X-Ratelimit-Limit" "0", "X-Ratelimit-Remaining" "0", "x-amzn-Remapped-Content-Length" "49", "X-Ratelimit-Reset" "0", "Connection" "close", "x-amz-apigw-id" "YOrQRGkdoAMEhCw=", "x-amzn-Remapped-Date" "Thu, 23 May 2024 14:55:11 GMT", "Date" "Thu, 23 May 2024 14:55:11 GMT", "Vary" "Origin"}, :orig-content-encoding nil, :status 200, :length 49, :body {:taskId "a39fb3c0-47af-4b82-9a56-b4998f154217"}, :trace-redirects []} nil :nam,794047a5-b023-489e-b5ee-6407fcdf0daa,mrodrigue@roomandboard.com,{:id "794047a5-b023-489e-b5ee-6407fcdf0daa", :name "Room & Board", :taskId "794047a5-b023-489e-b5ee-6407fcdf0daa"} https://xdr-ai-api.us.security.cisco.com/api/v1/tenants {:cached nil, :request-time 697, :repeatable? false, :protocol-version {:name "HTTP", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x7aca299e "org.apache.http.impl.client.InternalHttpClient@7aca299e"], :chunked? false, :reason-phrase "OK", :headers {"x-amzn-RequestId" "e704a69c-5e08-4c61-96fa-93c7b0ef1c93", "Content-Type" "application/json", "Content-Length" "49", "X-Ratelimit-Limit" "0", "X-Ratelimit-Remaining" "0", "x-amzn-Remapped-Content-Length" "49", "X-Ratelimit-Reset" "0", "Connection" "close", "x-amz-apigw-id" "YOrRBFKNIAMEbeg=", "x-amzn-Remapped-Date" "Thu, 23 May 2024 14:55:15 GMT", "Date" "Thu, 23 May 2024 14:55:15 GMT", "Vary" "Origin"}, :orig-content-encoding nil, :status 200, :length 49, :body {:taskId "794047a5-b023-489e-b5ee-6407fcdf0daa"}, :trace-redirects []} nil :nam,674c5065-9567-4e71-808d-75cb4e8b5520,richard.tippett@corebridgefinancial.com,{:id "674c5065-9567-4e71-808d-75cb4e8b5520", :name "Corebridge Financial", :taskId "674c5065-9567-4e71-808d-75cb4e8b5520"} https://xdr-ai-api.us.security.cisco.com/api/v1/tenants {:cached nil, :request-time 990, :repeatable? false, :protocol-version {:name "HTTP", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x7aca299e "org.apache.http.impl.client.InternalHttpClient@7aca299e"], :chunked? false, :reason-phrase "OK", :headers {"x-amzn-RequestId" "c5142478-75cb-4416-a9bb-47d490ba4447", "Content-Type" "application/json", "Content-Length" "49", "X-Ratelimit-Limit" "0", "X-Ratelimit-Remaining" "0", "x-amzn-Remapped-Content-Length" "49", "X-Ratelimit-Reset" "0", "Connection" "close", "x-amz-apigw-id" "YOrRrE80IAMEBqA=", "x-amzn-Remapped-Date" "Thu, 23 May 2024 14:55:19 GMT", "Date" "Thu, 23 May 2024 14:55:19 GMT", "Vary" "Origin"}, :orig-content-encoding nil, :status 200, :length 49, :body {:taskId "674c5065-9567-4e71-808d-75cb4e8b5520"}, :trace-redirects []} nil :nam,e44139d5-63bd-42dc-a548-62b3f4f5c749,omar@xentaurs.com,{:id "e44139d5-63bd-42dc-a548-62b3f4f5c749", :name "ATSG PROD", :taskId "e44139d5-63bd-42dc-a548-62b3f4f5c749"} https://xdr-ai-api.us.security.cisco.com/api/v1/tenants {:cached nil, :request-time 704, :repeatable? false, :protocol-version {:name "HTTP", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x280099a0 "org.apache.http.impl.client.InternalHttpClient@280099a0"], :chunked? false, :reason-phrase "OK", :headers {"x-amzn-RequestId" "ce1e9cc2-c2d2-4c36-b86a-349c1b074ea5", "Content-Type" "application/json", "Content-Length" "49", "X-Ratelimit-Limit" "0", "X-Ratelimit-Remaining" "0", "x-amzn-Remapped-Content-Length" "49", "X-Ratelimit-Reset" "0", "Connection" "close", "x-amz-apigw-id" "YOrSYHiiIAMEOQg=", "x-amzn-Remapped-Date" "Thu, 23 May 2024 14:55:23 GMT", "Date" "Thu, 23 May 2024 14:55:24 GMT", "Vary" "Origin"}, :orig-content-encoding nil, :status 200, :length 49, :body {:taskId "e44139d5-63bd-42dc-a548-62b3f4f5c749"}, :trace-redirects []} nil

DONE bad-module work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 08:17]

DONE Robert Harris redirect bug? jira ticket work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 08:19]

DONE Remove manual flag https://ciscosecurity.aha.io/features/XDR-698 work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 08:22]

DONE Test AI onboarding headers INT and TEST work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 08:22]

DONE Ask Prerna about NAM Beta customer and who did it work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 08:23]

DONE Poser et/ou vendre les congés 12j non pris. work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 11:05]

DONE Write down redirect logic work

SCHEDULED: <2024-05-23 Thu 10:00> [2024-05-23 Thu 18:05]

The logic in the UI:

the UI will call the /whoami endpoint This will contain:

{"org" {"main-app" APP}
"metas" {"apps" {APP {"url" "URL of APP"}}}

Then the logic BEFORE AND AFTER SX EOL will be exactly the same:

let app = whoami.org["main-app"];
let expectedURL = whoami.metas.apps[app].url;
if (currentURL does not match expectedURL) {
 redirectTo(expectedURL);
}

The logic in the backend

Before SX EOL:

orgs with the XDR Flag => will have main app XDR
orgs without the XDR Flag, without the SC Flag => will have main app SX
orgs without the XDR Flag but with the SC Flag => will have the main app SC

After SX EOL:

orgs with the XDR Flag => will have main app XDR
orgs without the XDR Flag => will have main app SC
no org will have their main app be SX

Configuration in the backend

For every deployed environment (INT, TEST, PROD NAM, PROD EU, PROD APJC), in the config.edn we will have a mapping looking like (example for PROD NAM):

{...
 :apps {:xdr {:url "https://xdr.us.security.cisco.com"}
        :sx {:url "https://securex.us.security.cisco.com"}
        :sc {:url "https://secure-client.us.security.cisco.com"}}
  ...}

2024-W22

2024-05-27 Monday

CHAT Answer to Dan work chat

CLOCK: [2024-05-27 Mon 10:58]–[2024-05-27 Mon 15:46] => 4:48

[2024-05-27 Mon 10:58]

const me = await irohClient.get("/profile/whoami");
const mainApp = me?.data?.org?["mainApp"];
const applicationLoaded = getApplicationLoaded();

if   (mainApp != applicationLoaded) {
    // ERROR CASE
    // THE USER IS ON AN APP HE IS NOT AUTHORIZED TO USE
    switch (mainApp) {
        case "xdr":
            // Let's console.warn this for debugging purposes when log preservation is on
            console.warn("You do not have access to " + applicationLoaded + "."
                         + " You will be redirected to XDR");
            clearSession();
            // Send you to Secure Client
            window.location = `https://${XDRMap.get(eitherHostname())}`;
            break;
        case "sc":
            // Let's console.warn this for debugging purposes when log preservation is on
            console.warn("You do not have access to " + applicationLoaded + "."
                         + " You will be redirected to Secure Client UI");
            clearSession();
            // Send you to XDR ;; I invented here
            window.location = `https://${secureClientXDRMap.get(eitherHostname())}`;
            break;
        case "sx":
            // Let's console.warn this for debugging purposes when log preservation is on
            console.warn("You do not have access to " + applicationLoaded + "."
                         + " You will be redirected to SecureX");
            clearSession();
            window.location = `https://${newAndOldUrlMap.get(eitherHostname())}`;
            break;
        default:
    }
}

const me = await irohClient.get("/profile/whoami");
const mainApp = me?.data?.org?["mainApp"];
const applicationLoaded = getApplicationLoaded();

function redirectTo(app) {
    console.warn("You do not have access to " + applicationLoaded + "."
                 + " You will be redirected to " + app);
    clearSession();
    // Send you to app
    let mapping = null;
    switch(app) {
        case "xdr": mapping = XDRMap; break;
        case "sc": mapping  = SecureClientXDRMap; break;
        case "sx": mapping = newAndOldUrlMap; break;
    }
    window.location = `https://${mapping.get(eitherHostname())}`;
}

if   (mainApp != applicationLoaded) {
    redirectTo(mainApp)
}

DONE Keep link to history comment should I revert it? work

SCHEDULED: <2024-05-27 Mon 10:00> [2024-05-27 Mon 11:17]

2024-05-28 Tuesday

MEETING XDR Ribbon Auth work meeting

CLOCK: [2024-05-28 Tue 16:32]–[2024-05-28 Tue 17:32] => 1:00

[2024-05-28 Tue 16:32]

Auth we need to go to SX portal, create the client-id and secret and register that.

But for the plugin will work with SSO auth. The user is just log in.

User create the client, but new.

Currently SWA are using Client Creds. Tell them this will continu to work.

Proposed to use Device Grant instead as this is the recommended way to do it.

2024-05-29 Wednesday

MEETING Core Team SX EOL work meeting

CLOCK: [2024-05-29 Wed 16:01]–[2024-05-29 Wed 23:58] => 7:57

[2024-05-29 Wed 16:01]

CTR and visibility URL: Talk about visibility UI and other endpoints.

2024-W23

2024-06-03 Monday

DONE Check if we could use stored procedure for delete table iroh line work

SCHEDULED: <2024-06-03 Mon 10:00> [2024-06-03 Mon 09:38]

DONE Answer to Christian Saunders work

SCHEDULED: <2024-06-03 Mon 10:00> [2024-06-03 Mon 09:39]

DONE Check chat with Eugene Chan work

SCHEDULED: <2024-06-03 Mon 10:00> [2024-06-03 Mon 09:45]

DONE Create an issue for /onboard_meraki webhook, check that in JIRA work

SCHEDULED: <2024-06-03 Mon 10:00> [2024-06-03 Mon 17:38]

https://cisco-sbg.atlassian.net/issues/XDR-3988?filter=-1

Meraki INT: 80a909ec-99ab-4cbc-9d42-b59bb9ef669b TEST: 43829fec-75a0-4c76-b9ec-f2b22c469589 NAM: 43829fec-75a0-4c76-b9ec-f2b22c469589 EU: 43829fec-75a0-4c76-b9ec-f2b22c469589 APJC: 43829fec-75a0-4c76-b9ec-f2b22c469589

DONE Update orgs with sc flag work

SCHEDULED: <2024-06-03 Mon 10:00> [2024-06-03 Mon 17:46]

INT: 047a89bf-5d2e-4392-b770-ad4821a82acf d5e7a415-85ca-4be8-8773-e35d03f889d0

TEST: 5c2abff3-4257-45d8-b923-55e51008e4ef 77e1a03b-db53-5d6a-8f7d-26dfedb45ff8 c395f3c8-723b-4d15-b8b7-e17bec459c6b e3d94782-47cf-4145-9db3-092bb1db2b6a

2024-06-04 Tuesday

MEETING SX EOL work meeting

[2024-06-04 Tue 17:19]

Agenda (to discuss about)
Notes
Actions Remove even more scopes: casebook, playbook, enrich

MEETING SX EOL Core Team work meeting

[2024-06-04 Tue 16:35]

Agenda (to discuss about)
Notes
Actions

MEETING Olivier 1-1 work meeting

CLOCK: [2024-06-04 Tue 15:34]–[2024-06-04 Tue 21:47] => 6:13

[2024-06-04 Tue 15:34]

Part en islande.

2024-06-05 Wednesday

DONE Comment on Orbital 1-click/0-click webex work

SCHEDULED: <2024-06-05 Wed 10:00> [2024-06-05 Wed 08:04]

CANCELED Add semi-public docs for Entitlement recommendations work

SCHEDULED: <2024-06-24 Mon 10:00>

State "CANCELED" from "TODO" [2024-06-24 Mon 09:17]
Forgot what I meant, probably onboarding and not entitlemetn

[2024-06-05 Wed 10:33]

DONE Create webhooks for SCA on Meraki module change work

SCHEDULED: <2024-06-05 Wed 10:00>

CLOCK: [2024-06-05 Wed 15:03]–[2024-06-05 Wed 19:11] => 4:08

[2024-06-05 Wed 15:03]

const m = {"sca":{"int"  :"client-e1fa7b2c-95a0-4a1a-bd89-489fc5eba225",
                  "test" :"client-0f13385b-68b6-48e4-be7d-93d68add97b5",
                  "nam"  :"client-71bf9096-dc08-4bb2-b837-e5fe5c4652bc",
                  "eu"   :"client-1a44e201-ffe4-439d-bf74-9e95dc2ac1a1",
                  "apjc" :"client-a37b0daa-50b8-492b-8fb3-337c6bfb5bad"},
           "sca_url":{"int" :"https://tr-relay-dev-srv2.dev-srv.dev.obsrvbl.com/onboard_meraki",
                      "test":"https://tr-relay-staging1.staging.obsrvbl.com/onboard_meraki",
                      "nam" :"https://tr-relay-production.obsrvbl.obsrvbl.com/onboard_meraki",
                      "eu"  :"https://tr-relay-eu-prod1.eu-prod.obsrvbl.com/onboard_meraki",
                      "apjc":"https://tr-relay-anz-prod1.anz-prod.obsrvbl.com/onboard_meraki"},
           "meraki": {"int"  :"80a909ec-99ab-4cbc-9d42-b59bb9ef669b",
                      "test" :"43829fec-75a0-4c76-b9ec-f2b22c469589",
                      "nam"  :"43829fec-75a0-4c76-b9ec-f2b22c469589",
                      "eu"   :"43829fec-75a0-4c76-b9ec-f2b22c469589",
                      "apjc" :"43829fec-75a0-4c76-b9ec-f2b22c469589"}};

{
    "webhook_type": "url",
    "name": "SCA Meraki Change",
    "org_id": "system",
    "source": "iroh-events",
    "auth": {
        "type": "iroh-jwt",
        "conf": {
            "client_id": m["sca"][region]
        }
    },
    "event_filter_map": {
        "module_instance_visibility": "org",
        "module_type_id": m["meraki"][region]
    },
    "url": m["sca_url"][region]
    "user_id": "system",
    "client_id": "system",
    "event_type_filter": [
        "module-instance/restricted",
        "module-instance/reactivated",
        "module-instance/updated",
        "module-instance/created",
        "module-instance/deleted"
    ],
    "authenticate-as-emitter?": true,
    "visibility": "global",
}

INT

const m = {"sca":{"int"  :"client-e1fa7b2c-95a0-4a1a-bd89-489fc5eba225",
                  "test" :"client-0f13385b-68b6-48e4-be7d-93d68add97b5",
                  "nam"  :"client-71bf9096-dc08-4bb2-b837-e5fe5c4652bc",
                  "eu"   :"client-1a44e201-ffe4-439d-bf74-9e95dc2ac1a1",
                  "apjc" :"client-a37b0daa-50b8-492b-8fb3-337c6bfb5bad"},
           "sca_url":{"int" :"https://tr-relay-dev-srv2.dev-srv.dev.obsrvbl.com/onboard_meraki",
                      "test":"https://tr-relay-staging1.staging.obsrvbl.com/onboard_meraki",
                      "nam" :"https://tr-relay-production.obsrvbl.obsrvbl.com/onboard_meraki",
                      "eu"  :"https://tr-relay-eu-prod1.eu-prod.obsrvbl.com/onboard_meraki",
                      "apjc":"https://tr-relay-anz-prod1.anz-prod.obsrvbl.com/onboard_meraki"},
           "meraki": {"int"  :"80a909ec-99ab-4cbc-9d42-b59bb9ef669b",
                      "test" :"43829fec-75a0-4c76-b9ec-f2b22c469589",
                      "nam"  :"43829fec-75a0-4c76-b9ec-f2b22c469589",
                      "eu"   :"43829fec-75a0-4c76-b9ec-f2b22c469589",
                      "apjc" :"43829fec-75a0-4c76-b9ec-f2b22c469589"}};

{
    "webhook_type": "url",
    "name": "SCA Meraki Change",
    "org_id": "system",
    "source": "iroh-events",
    "auth": {
        "type": "iroh-jwt",
        "conf": {
            "client_id": CLIENT_ID
        }
    },
    "event_filter_map": {
        "module_instance_visibility": "org",
        "module_type_id": MODULE_TYPE_ID
    },
    "url": SCA_URL,
    "user_id": "system",
    "client_id": "system",
    "event_type_filter": [
        "module-instance/restricted",
        "module-instance/reactivated",
        "module-instance/updated",
        "module-instance/created",
        "module-instance/deleted"
    ],
    "authenticate-as-emitter?": true,
    "visibility": "global"
}

2024-W24

2024-06-10 Monday

IN-PROGRESS Diagram for tomorrow work

[2024-06-10 Mon 18:39]

skinparam handwritten false
skinparam shadowing false

skinparam sequence {
ParticipantFontName Chalkboard;
ParticipantBackgroundColor white;
ParticipantBorderColor #37C
GroupBorderColor #888
ArrowColor #37C
LifeLineBorderColor #37C
}

participant PIAM as piam
participant "Secure Endpoint" as se
participant "IROH" as iroh
participant "Orbital" as orbital


group Provisionning

piam->se: Provisioning Request
se->iroh: POST /iroh/oauth2/token (client_id,client_secret)
iroh->se: 200 OK (Bearer JWT)
se->iroh: POST /iroh/provisioning/platform/org
iroh->se: org-id (and full Org)
se->iroh: POST /iroh/provisioning/platform/user
iroh->se: user-id (and full User)
se->iroh: POST /iroh/provisioning/platform/onboard/{user-id}/orbital
iroh->orbital: POST {orbital}/onboarding (admin user JWT)
orbital->orbital: provision using Org-id/User-id in the JWT
orbital->iroh: POST /iroh/iroh-int/module-instance (with JWT Create module)
iroh->orbital: 201 OK (Created module)
orbital->orbital: Any internal work for finalizing the provisioning
orbital->iroh: 200 OK (+ any body)
iroh->se: 200 OK (+ body returned by orbital)
end

/yogsototh/deft/media/commit/6b27fe6c7103fc493e764ee6f31d6096438b4845/SE_Orbital_provisioning.png

IN-PROGRESS Change webhook for SXO in test work

[2024-06-10 Mon 18:29]

MEETING Prototype XDR integration work meeting

CLOCK: [2024-06-10 Mon 16:35]–[2024-06-10 Mon 21:31] => 4:56

[2024-06-10 Mon 16:35]

DONE Change AI Assistant onboarding conf webex work

CLOSED: [2024-08-12 Mon 10:03] SCHEDULED: <2024-06-10 Mon 10:00>

State "DONE" from "HOLD" [2024-08-12 Mon 10:03]
State "HOLD" from "IN-PROGRESS" [2024-06-10 Mon 15:57]
Waiting for answer from Abhiram.

CLOCK: [2024-06-10 Mon 15:51]–[2024-06-10 Mon 15:57] => 0:06

[2024-06-10 Mon 09:20]

DONE Check non-admin login discussion webex work

SCHEDULED: <2024-06-10 Mon 10:00> [2024-06-10 Mon 09:23]

DONE Check scopes for Rekha webex work

CLOSED: [2024-08-12 Mon 10:03] SCHEDULED: <2024-06-10 Mon 10:00>

State "DONE" from "HOLD" [2024-08-12 Mon 10:03]
State "HOLD" from "TODO" [2024-06-10 Mon 15:58]
Tiffany Russell is taking care of it.

[2024-06-10 Mon 09:31] jira ticket https://cisco-sbg.atlassian.net/browse/XDR-4186

DONE Enable ai-assistant for 1ffd5ddc-025a-42c0-9219-8844f6f4335b [prerna dm] work

SCHEDULED: <2024-06-10 Mon 10:00> [2024-06-10 Mon 09:34]

DONE PR scopes work

SCHEDULED: <2024-06-10 Mon 10:00> [2024-06-10 Mon 15:50]

CANCELED Check Live Demo of Secure Client Management UI (SX EOL) work

SCHEDULED: <2024-06-11 Tue 10:00>

State "CANCELED" from "TODO" [2024-06-17 Mon 16:33]
Yolo

[2024-06-10 Mon 16:36]

2024-06-11 Tuesday

MEETING Test Plan work meeting

CLOCK: [2024-06-11 Tue 16:39]–[2024-06-12 Wed 09:58] => 17:19

[2024-06-11 Tue 16:39]

SX Only Org:

No login for some swagger UI (point 4?) point 8. shoudl list XDR and SC instead point 10. Visibility

XDR Only Org:

SCC Org:

Account switcher only SCC org

No mention to SecureX or XDR in error messages during the flow.

2024-06-12 Wednesday

IN-PROGRESS Create SXSO bookmark for SC work

CLOCK: [2024-06-12 Wed 09:58]–[2024-06-12 Wed 21:36] => 11:38

[2024-06-12 Wed 09:58]

DONE Register onboarding endpoint (see ihor dm) work

SCHEDULED: <2024-06-12 Wed 10:00> [2024-06-12 Wed 09:21]

Hi Yann, could you please register the onboarding service for secure endpoint test env, here is our onboarding url

https://console.qa1.immunet.com/securex_modules/onboarding

DONE Another AI Assistant (dm Prerna) work

SCHEDULED: <2024-06-12 Wed 10:00> [2024-06-12 Wed 09:22]

Hi Yann, another org id for Ai Assistant Private Preview. Org ID (NA), a2232e2c-a8c4-4044-a8ae-9fdeadda0dc9

DONE Check invitation redirects jira ticket work

SCHEDULED: <2024-06-12 Wed 10:00> [2024-06-12 Wed 09:44]

2024-W25

2024-06-17 Monday

MEETING Brownfield with Prerna work meeting

CLOCK: [2024-06-17 Mon 15:30]–[2024-06-18 Tue 16:35] => 25:05

[2024-06-17 Mon 15:30]

Agenda (to discuss about)
Notes
Actions batch AI onboarding script for all XDR orgs

2024-06-18 Tuesday

MEETING Core Team SX EOL work meeting

CLOCK: [2024-06-18 Tue 16:35]–[2024-06-18 Tue 21:26] => 4:51

[2024-06-18 Tue 16:35]

Notes
Actions
- Contact SE/Orbital about creating a module. To prepare the future.

DONE Re-check onboarding v2 for AI work

SCHEDULED: <2024-06-24 Mon 10:00> [2024-06-18 Tue 08:34]

DONE Ecrire issue pour Olivier rewrite URL work

SCHEDULED: <2024-06-24 Mon 10:00> [2024-06-18 Tue 17:22]

Objectif: Eviter les redirections.

Nous avons plusieurs URL chacune avec une UI/App différente.

XDR, SX et SC.

Lorsque quelqu'un va sur l'URL d'un des produits sans avoir de session. L'UI redirige l'User vers l'URL suivante:

<APP_URL>/iroh/iroh-auth/login/sxso?origin=<APP_URL>

L'user est redirigé, il s'authentifie via l'IdP SXSO. Si l'user a plusieurs comptes, il est redirigé vers la registration UI pour choisir son compte et il est redirigé vers <ORIGIN>. S'il n'a qu'un seul compte, on le redirige directement vers <ORIGIN>.

Nous voudrions intercepter juste avant que le serveur ne renvoie une 302 mais après que l'user ait selectionné son compte pour remplacer, si besoin la valeur d'ORIGIN. Attention, beaucoup de valeurs différentes d'ORIGIN peuvent être données, pas seulement celle des 3 App officielles. Nous voudrions donc avoir l'algorithme suivant:

(defn rewrite-origin
  [{:keys [sc sx xdr] :as ctx}
   main-app
   url]
  (let [app-urls (set (map :url [sc sx xdr]))
        origin (url/origin url)]
    (if (contains? app-urls origin)
      (let [main-app-url (case main-app
                              :sc  (:url sc)
                              :sx  (:url sx)
                              :xdr (:url xdr))]
        ;; replace the origin of URL by main-app-url
        (replace-origin url main-app-url))
      ;; if the origin of the redirect URL is not one of the known app
      ;; we do not rewrite the origin URL
      url)))

En utilisant cet algorihtme nous aidons l'UI et nos customer a ne pas subir de redirections inutiles. Si un user qui n'a pas accès à XDR est redirigé vers XDR alors nous remplaçons l'URL de XDR par l'URL de SecureClient (ou SX avant SX EOL) ce qui permet d'éviter à l'UI de rediriger l'user de nouveau. De plus celà permet d'éviter des "boucles manuelles" de login potentielles. Imaginons le cas suivant:

User va sur l'URL d'XDR
Il choisit son compte SC-only
Il va vers XDR
l'UI d'XDR le redirige vers l'URL de SC
l'User est redirigé vers l'account selection
L'User selectionne son compte XDR
L'user va vers SC UI
L'UI de SC redirige l'user vers l'URL de XDR
GOTO 2

L'UI a les moyen de force login le bon user account. Mais il est preferrable d'intervenir à l'étape 2 et de réécrire l'URL de redirection pour envoyer cet utilisateur vers l'UI de SC directement après qu'il ait sélectionné son compte SC-only et pas XDR.

Plus techniquement, les emplacements:

Dans IROH Auth la route de login.
Dans IROH Auth UI l'API de redirection lors de la selection de compte

English translation

Objective: Prevent Redirections.

We have multiple URLs, each with a different UI/App (XDR, SX, and SC).

When someone accesses one of these product URLs without having an existing session, the UI redirects them to the following URL:

<APP_URL>/iroh/iroh-auth/login/sxso?origin=<APP_URL>

The user is redirected, authenticates via SXSO IDP, and if they have multiple accounts, they are directed to a registration UI to select their account. If they only have one account, they are directly sent back to <ORIGIN>.

We want to intercept just before the server returns a 302 response after the user has selected their account, replacing the origin value as needed.

Note that many different values of ORIGIN can be provided, not just those from the three official Apps. We would like an algorithm that follows this:

(defn rewrite-origin
   [ctx main-app url]
   (let  [app-urls (set (map :url [sc sx xdr]))
          origin (url/origin url)]
     (if (contains? app-urls origin)
       (let [main-app-url (case main-app
                               :sc (:url sc)
                               :sx (:url sx)
                               :xdr (:url xdr))]
         ; replace the origin of URL by main-app-url
         (replace-origin url main-app-url))
       ; if the origin of the redirect URL is not one of the known app
       ; we do not rewrite the origin URL
      url)))

Using this algorithm, we can help our UI and customers avoid unnecessary redirections. If a user without access to XDR is redirected to XDR, we replace the XDR URL with the SecureClient (or SX before SX EOL) URL, which allows us to prevent further manual login loops.

Imagine the following scenario:

User accesses an XDR URL.
They select their SC-only account.
They go to the XDR UI.
The XDR UI redirects them back to the SC URL.
The user is redirected to the account selection page.
The user selects their XDR account.
The user goes to the SC UI.
The SC UI redirects them back to the XDR URL.
GOTO 2

The UI has the means to force login with the correct user account, but it is preferable to intervene at step 2 and rewrite the redirect URL to send this user directly to the SC UI after they have selected their SC-only account.

Technically speaking:

In IROH Auth, the route for login.
In IROH Auth UI, the API for redirection during account selection.

2024-W25

2024-06-17 Monday

DONE Create a JIRA ticket for PIAM bookmark & clients creation work

SCHEDULED: <2024-06-17 Mon 10:00> [2024-06-17 Mon 07:41]

DONE Check Mario Design

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Check SXSO Migration webexteams://im?space=331b38f0-6218-11e9-9aae-c5b8cb291b23&message=c60913e0-2f44-11ef-b4aa-312c6fa65a31

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Inject wisdom webexteams://im?space=b5844a30-2e19-11ee-b0bb-8575ace105f3&message=91aadea0-2fe7-11ef-a989-b39fcd216ef7

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Revert ORG (Danny messages)

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Answer Andrew webexteams://im?space=2c456ef0-3e7f-11ed-9e26-35248da09ee2&message=30b37c20-2f46-11ef-895a-b5cc6fe75295

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Answer Yuri webexteams://im?space=fd803b50-e2cb-11eb-a044-cb6978877ae3&message=881ef7c0-2ef9-11ef-8199-2718148ea2ff

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Answer to Jilian

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Check orbital webexteams://im?space=68f439c0-7a5c-11ee-9e3c-6f3b2158786b&message=b03ffe50-2f14-11ef-b812-337b71447fc0

SCHEDULED: <2024-06-24 Mon 10:00>

DONE Check avec Guillaume multiple webhook webex work

SCHEDULED: <2024-06-17 Mon 10:00> [2024-06-17 Mon 08:10]

2024-W26

2024-06-24 Monday

DONE Add SC flag in PROD work

SCHEDULED: <2024-06-24 Mon 10:00> [2024-06-24 Mon 15:56]

NAM User Advantage tjbusch+se0603u01@cisco.com E2E-User-ADV-NAM tjbusch+se0603u01@cisco.com EU User Essentials tjbusch+se0603u02@cisco.com E2E-User-ESS-EU tjbusch+se0603u02@cisco.com APJC User Advantage tjbusch+se0603u03@cisco.com E2E-User-ADV-APJC tjbusch+se0603u03@cisco.com

2024-06-25 Tuesday

MEETING Orbital / SE work meeting

CLOCK: [2024-06-25 Tue 16:36]–[2024-06-25 Tue 22:34] => 5:58

[2024-06-25 Tue 16:36]

@Melvin_Wiens @Eugene_Chan

Act on it.

@Ihor Finding the clients to add new. Find IP Addresses.

Share doc for de-onboarding Orbital to Eugene.

DONE Check Mario work work

SCHEDULED: <2024-06-25 Tue 10:00> [2024-06-25 Tue 10:01]

DONE Make all OAuth2 trusted client XDR org work

SCHEDULED: <2024-06-25 Tue 10:00> [2024-06-25 Tue 10:51]

2024-W27

2024-07-01 Monday

MEETING Atlanta Debrief work meeting

[2024-07-01 Mon 15:58]

Agenda (to discuss about)
Notes
Actions

DONE Change onboarding config for SE TEST work

SCHEDULED: <2024-07-01 Mon 10:00> [2024-07-01 Mon 10:30]

Hey Yann, our Ops said that IROH should have access to Secure Endpoint test env via this url - console-ext.qa1.immunet.com. Could you please verify it and if so please update the onboarding url for Secure Endpoint

2024-W28

2024-07-09 Tuesday

MEETING SX EOL Core team work meeting

CLOCK: [2024-07-09 Tue 16:35]–[2024-07-11 Thu 12:50] => 44:15

[2024-07-09 Tue 16:35]

2024-07-10 Wednesday

DONE Check virtual user for SSE with claim alias work

SCHEDULED: <2024-07-10 Wed 10:00> [2024-07-10 Wed 09:35]

CANCELED delete customer user https://cisco-sbg.atlassian.net/browse/XDR-5585 work

SCHEDULED: <2024-07-11 Thu 10:00>

State "CANCELED" from "TODO" [2024-07-10 Wed 18:22]
Provided another solution

[2024-07-10 Wed 18:07]

DONE finish to write https://cisco-sbg.atlassian.net/browse/XDR-5649 work

SCHEDULED: <2024-07-11 Thu 10:00> [2024-07-10 Wed 18:46]

2024-07-12 Friday

MEETING Monthly Meeting work meeting

CLOCK: [2024-07-12 Fri 15:39]–[2024-07-12 Fri 19:03] => 3:24

[2024-07-12 Fri 15:39]

Services Team

Matt: checking OCSF see if we can use this format

Integrations:

Meraki integration should come very soon.

SX EOL

Wanderson and Olivier: preparation, new SC-only UI, all dev tasks done
Help Secure Endpoint/Orbital team
Help SMA team

Auth front:

Wanderson: Fix an issue with async Universal Provisioning
Wanderson: Provisioning maintenance, ability for provisionner to pass bodies to the provisionned service.

Provisioning:

Remove some org from XDR to get back to SX-only
Prepare batch onboarding of the AI Assistant
Create some QA accounts
Olivier and Guillaume work on the MITRE Matrix progress

Data Cleanup:

Olivier and Guillaume also will work on providing data cleanup mechanism to delete all orgs data from customer request and perhaps in the future on entitlement expiration.
Guillaume to also provide a quick delete mechansim for two customers

Mario:

node init that should help spawning new Geos by keeping the fixtures in a git repository.

Shafiq and Kirill work on Kafka Kirill: InstantMessaging module methods to prepare the work on providing instant messaging modules.

Ops:

Preparation for EKS (Kubernetes) in particular Patrick made a big configuration organisation change taking advantage of clojure aero. Now the configuration is splitted between ops-focused details and node-administration ones.

Ambrose:

improve Swagger API descriptions.

2024-W29

2024-07-15 Monday

MEETING Meeting with Santosh work meeting

CLOCK: [2024-07-15 Mon 16:33]–[2024-07-16 Tue 16:35] => 24:02

[2024-07-15 Mon 16:33]

Q1 feature we want to see if platform to implement it.

Exchange Page in Automation. Now go public to a market place for unauthenticated users.

There will be a link to install that could be clicked to unauthenticated user.

DONE James Moser, list of deprecated API after SX EOL work

SCHEDULED: <2024-07-16 Tue 10:00> [2024-07-15 Mon 17:27]

DONE Create SMA orgs work

SCHEDULED: <2024-07-15 Mon 10:00> [2024-07-15 Mon 21:37]

logs

for e in int test nam eu apjc; ./xdr-provision.sh -e $e --org-name 'Secure Malware Analytics OAuth Client Owner' --user-name 'sma-oauth-client-owner' --user-email 'sma-external-account-owners@cisco.com'

  end
Modules to onboard
[:csc :di]
create Org
POST https://visibility.int.iroh.site/iroh/provisioning/platform/org
Search user sma-external-account-owners@cisco.com in org 58924873-6d6d-4632-9e4c-74738e9d2f26
POST https://visibility.int.iroh.site/iroh/provisioning/platform/search/users
create User
POST https://visibility.int.iroh.site/iroh/provisioning/platform/user
onboarding :csc
POST https://visibility.int.iroh.site/iroh/provisioning/platform/onboard/73b1038b-3d4f-4ba5-a5ac-d3e44f331833/csc
HTTP ERROR: {:cached nil, :request-time 3742, :repeatable? false, :protocol-version {:name "HTTP", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x3b77940f "org.apache.http.impl.client.InternalHttpClient@3b77940f"], :chunked? false, :reason-phrase "Failed Dependency", :headers {"Content-Type" "application/json;charset=utf-8", "X-Content-Type-Options" "nosniff", "Content-Length" "951", "Alt-Svc" "h3=\":4443\"; ma=2592000", "X-Ctim-Version" "1.3.17", "Strict-Transport-Security" "max-age=31536000; includeSubDomains", "X-Iroh-Config" "f7e18aa52dc1553adf491aad5e9503ab0cf032ff", "Connection" "close", "X-Ratelimit-Org-Limit" "8000", "X-Iroh-Version" "1ab6866eca5327cd162c79a2c455a8ce382fd85c master", "X-Jwt-Version" "v2.10-c6d9cfc8557986505b91", "Date" "Mon, 15 Jul 2024 19:34:30 GMT", "Vary" "Accept-Encoding", "X-Iroh-Api-Version" "1.0.107", "X-Request-Id" "HxubYwRzHatQFwQADb-24"}, :orig-content-encoding "gzip", :status 424, :length 951, :body {:http-error "clj-http: status 500 {:cached nil, :request-time 3305, :repeatable? false, :protocol-version {:name \"HTTP\", :major 1, :minor 1}, :streaming? true, :http-client #object[org.apache.http.impl.client.InternalHttpClient 0x584b5acd \"org.apache.http.impl.client.InternalHttpClient@584b5acd\"], :chunked? false, :reason-phrase \"Internal Server Error\", :headers {\"X-Cache\" \"Error from cloudfront\", \"x-amzn-RequestId\" \"561dca05-4d95-43b2-974f-09786be67069\", \"Via\" \"1.1 aae0c8231be15466b169b68f10d6a918.cloudfront.net (CloudFront)\", \"Content-Type\" \"application/json\", \"Content-Length\" \"186\", \"x-amzn-Remapped-Content-Length\" \"186\", \"Connection\" \"close\", \"x-amz-apigw-id\" \"a9_3KEI6vHcEuBw=\", \"X-Build-Information\" \"xdr-ga-2.1.4:f9d139d5\", \"X-Amz-Cf-Pop\" \"IAD79-C1\", \"X-Amzn-Trace-Id\" \"Root=1-669579c7-5e88921419c325a212e943a4;Parent=7675e9bfd0518e34;Sampled=1;lineage=f9dcbb03:0|56b3328d:0\", \"Date\" \"Mon, 15 Jul 2024 19:34:34 GMT\", \"Vary\" \"Origin\", \"X-Amz-Cf-Id\" \"anoRz_Eskkh0UX-2dCGeZGd890BjjWU4LpS98ByLYiHuUoqHswqZTA==\"}, :orig-content-encoding nil, :status 500, :length 186, :body \"{\\\"code\\\":27,\\\"details\\\":\\\"An error occured while trying to onboard a business with SecureX.\\\",\\\"msg\\\":\\\"securex onboard failure\\\",\\\"errors\\\":[\\\"Response Payload Error: module_health_check_failed\\\"]}\\n\", :trace-redirects []}", :trace_id "ctx-ac46c5f2-b353-4860-a8ac-308174692e97", :error "sub_service_failure", :error_description "The onboarding service :csc failed"}, :trace-redirects []}
onboarding :di
POST https://visibility.int.iroh.site/iroh/provisioning/platform/onboard/73b1038b-3d4f-4ba5-a5ac-d3e44f331833/di
{:org
 {:scim-status "activated",
  :name "Secure Malware Analytics OAuth Client Owner",
  :activation-metas
  {:activated-with {:provisioning {:client-id "client-provisioning"}},
   :user-id "00000000-1111-477c-bae3-1d7527f4e80b",
   :timestamp "2024-07-15T19:34:29.362Z"},
  :id "58924873-6d6d-4632-9e4c-74738e9d2f26",
  :created-at "2024-07-15T19:34:29.362Z"},
 :user
 {:role "admin",
  :user-name "sma-oauth-client-owner",
  :user-email "sma-external-account-owners@cisco.com",
  :org-id "58924873-6d6d-4632-9e4c-74738e9d2f26",
  :user-id "73b1038b-3d4f-4ba5-a5ac-d3e44f331833",
  :created-at "2024-07-15T19:34:30.579Z"},
 :onboarding-results
 {:csc {},
  :di
  {:status 200,
   :body
   {:status 200,
    :body
    {:data
     {:enableSXOrganization "7576b4fa-ecd7-4376-88a5-c69fa7537728"}},
    :headers
    {:x-amzn-RequestId "a94d6578-e27b-4b19-a6e7-1bf6274c3257",
     :X-Amz-Cf-Id
     "kNZ3cbHMpyeqi_RzUeWQaKYYrXl5tQxAXKoNPb8vI7LOSdLR1aEyIw==",
     :Alt-Svc "h3=\":443\"; ma=86400",
     :Access-Control-Allow-Origin "*",
     :Date "Mon, 15 Jul 2024 19:34:49 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 aa77c72923f68604fa8f6f77bfdaa2dc.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "IAD61-P2",
     :x-amz-apigw-id "a9_3vG1ZIAMEA0w=",
     :Content-Length "72",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-669579ca-2e8cced1233f5a1c0812c959;Parent=7308d403f0972905;Sampled=0;lineage=9765f2b1:0"}}}}}
Modules to onboard
[:csc :di]
create Org
POST https://visibility.test.iroh.site/iroh/provisioning/platform/org
Search user sma-external-account-owners@cisco.com in org a4a758f1-b338-4ed2-8ba0-bfcf80f3b36b
POST https://visibility.test.iroh.site/iroh/provisioning/platform/search/users
create User
POST https://visibility.test.iroh.site/iroh/provisioning/platform/user
onboarding :csc
POST https://visibility.test.iroh.site/iroh/provisioning/platform/onboard/7fdc53ae-7e74-4398-8036-f3c65961e500/csc
onboarding :di
POST https://visibility.test.iroh.site/iroh/provisioning/platform/onboard/7fdc53ae-7e74-4398-8036-f3c65961e500/di
{:org
 {:scim-status "activated",
  :name "Secure Malware Analytics OAuth Client Owner",
  :activation-metas
  {:activated-with {:provisioning {:client-id "client-provisioning"}},
   :user-id "00000000-1111-477c-bae3-1d7527f4e80b",
   :timestamp "2024-07-15T19:34:51.983Z"},
  :id "a4a758f1-b338-4ed2-8ba0-bfcf80f3b36b",
  :created-at "2024-07-15T19:34:51.983Z"},
 :user
 {:role "admin",
  :user-name "sma-oauth-client-owner",
  :user-email "sma-external-account-owners@cisco.com",
  :org-id "a4a758f1-b338-4ed2-8ba0-bfcf80f3b36b",
  :user-id "7fdc53ae-7e74-4398-8036-f3c65961e500",
  :created-at "2024-07-15T19:34:53.456Z"},
 :onboarding-results
 {:csc
  {:status 200,
   :body
   {:status 200,
    :body {},
    :headers
    {:x-amzn-RequestId "3cc1c76a-2abb-4193-80f1-de572042989f",
     :X-Amz-Cf-Id
     "df1ehr_JZ2dMdZD-YrBB3yztexjdJ-DC6RmwqbhnHYfR7HZnhRE3BA==",
     :X-Build-Information "xdr-ga-2.1.4:a42a20c7",
     :Vary "Origin",
     :Date "Mon, 15 Jul 2024 19:34:55 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 477f2815176dbf316918cf19d9dc3eb6.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "IAD55-P4",
     :x-amzn-Remapped-Content-Length "3",
     :x-amz-apigw-id "a9_6vGz9YosEYtw=",
     :Content-Length "3",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-669579de-343d625568789c8f0bd537d4;Parent=0944912f758a68b1;Sampled=0;lineage=3a9bdf0b:0|2a6207fd:0"}}},
  :di
  {:status 200,
   :body
   {:status 200,
    :body
    {:data
     {:enableSXOrganization "485a6b33-cebf-4ecf-9651-537157eb0d8f"}},
    :headers
    {:x-amzn-RequestId "4d03f9af-365b-4a58-9003-df32807352f3",
     :X-Amz-Cf-Id
     "x-Nfd_acrsZsQUGyouqXbQX3-U7EAa4tZn3zLz1H2AVAgAVP3bZU5A==",
     :Alt-Svc "h3=\":443\"; ma=86400",
     :Access-Control-Allow-Origin "*",
     :Date "Mon, 15 Jul 2024 19:35:12 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 8348c06ca24c7faf1ae00ad6facc20b2.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "IAD89-P2",
     :x-amz-apigw-id "a9_7BEowoAMEc6Q=",
     :Content-Length "72",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-669579df-57d994c800ee0c88009ae3d0;Parent=0363157c31bf9480;Sampled=0;lineage=e76a69e5:0"}}}}}
Modules to onboard
[:csc :di]
create Org
POST https://visibility.amp.cisco.com/iroh/provisioning/platform/org
Search user sma-external-account-owners@cisco.com in org 0ef51cf8-99b5-4043-a906-4fc633dfc492
POST https://visibility.amp.cisco.com/iroh/provisioning/platform/search/users
create User
POST https://visibility.amp.cisco.com/iroh/provisioning/platform/user
onboarding :csc
POST https://visibility.amp.cisco.com/iroh/provisioning/platform/onboard/1a28e57a-d346-4a6f-b312-5c2d4cfc5245/csc
onboarding :di
POST https://visibility.amp.cisco.com/iroh/provisioning/platform/onboard/1a28e57a-d346-4a6f-b312-5c2d4cfc5245/di
{:org
 {:scim-status "activated",
  :name "Secure Malware Analytics OAuth Client Owner",
  :activation-metas
  {:activated-with {:provisioning {:client-id "client-provisioning"}},
   :user-id "00000000-1111-477c-bae3-1d7527f4e80b",
   :timestamp "2024-07-15T19:35:15.016Z"},
  :id "0ef51cf8-99b5-4043-a906-4fc633dfc492",
  :created-at "2024-07-15T19:35:15.017Z"},
 :user
 {:role "admin",
  :user-name "sma-oauth-client-owner",
  :user-email "sma-external-account-owners@cisco.com",
  :org-id "0ef51cf8-99b5-4043-a906-4fc633dfc492",
  :user-id "1a28e57a-d346-4a6f-b312-5c2d4cfc5245",
  :created-at "2024-07-15T19:35:16.745Z"},
 :onboarding-results
 {:csc
  {:status 200,
   :body
   {:status 200,
    :body {},
    :headers
    {:x-amzn-RequestId "79763300-3efb-46ff-bd47-9961ef3f483f",
     :X-Amz-Cf-Id
     "cdesoSVs2QMeB1Db6X-BQOhrQ7-vREzkygXtvYPcbcsWaV4BG3Ipcg==",
     :X-Build-Information "xdr-ga-2.1.4:0cae9e0a",
     :Vary "Origin",
     :Date "Mon, 15 Jul 2024 19:35:18 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 68a3b1d5c75429221abc685a453afb60.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "IAD12-P3",
     :x-amzn-Remapped-Content-Length "3",
     :x-amz-apigw-id "a9_-WFjdIAMEhWQ=",
     :Content-Length "3",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-669579f5-3e7456726ee330ef0ab40afd;Parent=156e86bf8f89c187;Sampled=1;lineage=3779c2de:0|a04b4774:0"}}},
  :di
  {:status 200,
   :body
   {:status 200,
    :body
    {:data
     {:enableSXOrganization "ccb9275e-5900-4a88-b666-0bb7dc373c58"}},
    :headers
    {:x-amzn-RequestId "fdf263af-2f8f-4f7e-808c-08e57d198474",
     :X-Amz-Cf-Id
     "GzCqzy0Y197dw2r5jPeYMXBWSr2aYDWHhsd0j1M0sSuvZsb32jRk4w==",
     :Alt-Svc "h3=\":443\"; ma=86400",
     :Access-Control-Allow-Origin "*",
     :Date "Mon, 15 Jul 2024 19:35:30 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 040f8a2cdffe1cf7a35d28e06c3ed574.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "IAD89-P1",
     :x-amz-apigw-id "a9_-mE60CYcENmw=",
     :Content-Length "72",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-669579f6-5bcea0691e19743e0d1ef1c6;Parent=5a73032770a5ce1a;Sampled=0;lineage=0a2928ab:0"}}}}}
Modules to onboard
[:csc :di]
create Org
POST https://visibility.eu.amp.cisco.com/iroh/provisioning/platform/org
Search user sma-external-account-owners@cisco.com in org 4903a04f-409c-4c5e-bc12-efe2eab3d026
POST https://visibility.eu.amp.cisco.com/iroh/provisioning/platform/search/users
create User
POST https://visibility.eu.amp.cisco.com/iroh/provisioning/platform/user
onboarding :csc
POST https://visibility.eu.amp.cisco.com/iroh/provisioning/platform/onboard/d65d1c3a-4e74-453a-8697-807d31ab76cf/csc
onboarding :di
POST https://visibility.eu.amp.cisco.com/iroh/provisioning/platform/onboard/d65d1c3a-4e74-453a-8697-807d31ab76cf/di
{:org
 {:scim-status "activated",
  :name "Secure Malware Analytics OAuth Client Owner",
  :activation-metas
  {:activated-with {:provisioning {:client-id "client-provisioning"}},
   :user-id "00000000-1111-477c-bae3-1d7527f4e80b",
   :timestamp "2024-07-15T19:35:32.739Z"},
  :id "4903a04f-409c-4c5e-bc12-efe2eab3d026",
  :created-at "2024-07-15T19:35:32.740Z"},
 :user
 {:role "admin",
  :user-name "sma-oauth-client-owner",
  :user-email "sma-external-account-owners@cisco.com",
  :org-id "4903a04f-409c-4c5e-bc12-efe2eab3d026",
  :user-id "d65d1c3a-4e74-453a-8697-807d31ab76cf",
  :created-at "2024-07-15T19:35:33.544Z"},
 :onboarding-results
 {:csc
  {:status 200,
   :body
   {:status 200,
    :body {},
    :headers
    {:x-amzn-RequestId "e3c374b1-af4f-4b0e-a39f-ebf2d9d1fb17",
     :X-Amz-Cf-Id
     "KXyyZMhyqdGn4CpyOSS9s0TipWriOvHowd2g6X2tNVxUitpywbIoNw==",
     :X-Build-Information "xdr-ga-2.1.4:0cae9e0a",
     :Vary "Origin",
     :Date "Mon, 15 Jul 2024 19:35:34 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 a9b2260e7964d946bfaccecd2e947938.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "DUB2-C1",
     :x-amzn-Remapped-Content-Length "3",
     :x-amz-apigw-id "a-AA9HPLjoEETrQ=",
     :Content-Length "3",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-66957a05-2ea963a21a6cd9082482c73c;Parent=4fee4c377fa099be;Sampled=1;lineage=47431257:0|dc5b7a88:0"}}},
  :di
  {:status 200,
   :body
   {:status 200,
    :body
    {:data
     {:enableSXOrganization "db0b15c9-b281-4d1f-98a5-f9c34e3cab36"}},
    :headers
    {:x-amzn-RequestId "512de4c8-c1ea-4a66-bd1c-6dac1359f0e1",
     :X-Amz-Cf-Id
     "GvJ__8EwtLEkJD12IGV_qDQ0vtBT_-szNdtZky4S0RIRbncsIKdFNw==",
     :Alt-Svc "h3=\":443\"; ma=86400",
     :Access-Control-Allow-Origin "*",
     :Date "Mon, 15 Jul 2024 19:35:49 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 4d362c0e30ca2cfa3855b041727beaa2.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "DUB2-C1",
     :x-amz-apigw-id "a-ABKEWuFiAETVA=",
     :Content-Length "72",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-66957a07-0a23047e2d8e10d021b40dcf;Parent=283a550361fab92c;Sampled=0;lineage=1d6099ec:0"}}}}}
Modules to onboard
[:csc :di]
create Org
POST https://visibility.apjc.amp.cisco.com/iroh/provisioning/platform/org
Search user sma-external-account-owners@cisco.com in org 9e8b1e53-eec4-42cd-b914-f776d8da4142
POST https://visibility.apjc.amp.cisco.com/iroh/provisioning/platform/search/users
create User
POST https://visibility.apjc.amp.cisco.com/iroh/provisioning/platform/user
onboarding :csc
POST https://visibility.apjc.amp.cisco.com/iroh/provisioning/platform/onboard/c09c5bad-e1c6-44fb-a50e-e3028cf32029/csc
onboarding :di
POST https://visibility.apjc.amp.cisco.com/iroh/provisioning/platform/onboard/c09c5bad-e1c6-44fb-a50e-e3028cf32029/di
{:org
 {:scim-status "activated",
  :name "Secure Malware Analytics OAuth Client Owner",
  :activation-metas
  {:activated-with {:provisioning {:client-id "client-provisioning"}},
   :user-id "00000000-1111-477c-bae3-1d7527f4e80b",
   :timestamp "2024-07-15T19:35:53.396Z"},
  :id "9e8b1e53-eec4-42cd-b914-f776d8da4142",
  :created-at "2024-07-15T19:35:53.397Z"},
 :user
 {:role "admin",
  :user-name "sma-oauth-client-owner",
  :user-email "sma-external-account-owners@cisco.com",
  :org-id "9e8b1e53-eec4-42cd-b914-f776d8da4142",
  :user-id "c09c5bad-e1c6-44fb-a50e-e3028cf32029",
  :created-at "2024-07-15T19:35:56.149Z"},
 :onboarding-results
 {:csc
  {:status 200,
   :body
   {:status 200,
    :body {},
    :headers
    {:x-amzn-RequestId "7f52a8fe-b271-4638-9628-2c10dad25207",
     :X-Amz-Cf-Id
     "FMd6BYDeS9lUl5nTJeugM62owSw75D3C-pjqdM16ShP0ekmM-r2YYg==",
     :X-Build-Information "xdr-ga-2.1.4:0cae9e0a",
     :Vary "Origin",
     :Date "Mon, 15 Jul 2024 19:36:02 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 026dc3b853bedb1ebeb86b2eb35e80c6.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "NRT57-P3",
     :x-amzn-Remapped-Content-Length "3",
     :x-amz-apigw-id "a-AEnGPwNjMEJEw=",
     :Content-Length "3",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-66957a1d-023a69fa487721026868b56f;Parent=2440fdb828a9c69e;Sampled=1;lineage=351ecf9c:0|df3edd73:0"}}},
  :di
  {:status 200,
   :body
   {:status 200,
    :body
    {:data
     {:enableSXOrganization "04d76533-c65c-4c58-90bf-54eb158f608e"}},
    :headers
    {:x-amzn-RequestId "1b260d5a-9cc0-4c90-affd-4c3cbfd3c098",
     :X-Amz-Cf-Id
     "sEEyUlri3hDbeVfUxtWdvTKsBBtdeoEBt6M68BrfkZEyf7FfiS6TuA==",
     :Alt-Svc "h3=\":443\"; ma=86400",
     :Access-Control-Allow-Origin "*",
     :Date "Mon, 15 Jul 2024 19:36:23 GMT",
     :X-Cache "Miss from cloudfront",
     :Via
     "1.1 c4d3c830670ce1a9bbbd3fdb2abb310c.cloudfront.net (CloudFront)",
     :X-Amz-Cf-Pop "NRT20-P1",
     :x-amz-apigw-id "a-AFkGuLSwMETqw=",
     :Content-Length "72",
     :Connection "close",
     :Content-Type "application/json",
     :X-Amzn-Trace-Id
     "Root=1-66957a23-5d7472695ffeab4b23638942;Parent=6a14389e445f91d7;Sampled=0;lineage=1cf66d40:0"}}}}}

DONE Onboard AI APIs for all XDR orgs work

SCHEDULED: <2024-07-16 Tue 10:00> [2024-07-15 Mon 21:48]

2024-07-16 Tuesday

MEETING Core Team SX EOL work meeting

CLOCK: [2024-07-16 Tue 16:35]–[2024-07-16 Tue 21:35] => 5:00

[2024-07-16 Tue 16:35]

Blockers?

Blockers

none really

Comments

SE modules to disable?

@Jyoti: should we disable SE modules? SE in user suite. I want to enable SC. That provision IROH and Orbital.

A module also created for SE.

Should DI use that SE module? @Briana: don't think so @Dario: don't fully understand

@Jyoti: user suite has the product.

Conclusion: make demo…

Prerna

changes to the redirects

DONE Write a ticket with the bookmarks work

SCHEDULED: <2024-07-16 Tue 10:00> [2024-07-16 Tue 16:29]

JIRA: https://cisco-sbg.atlassian.net/issues/CSEAC-1396

DONE AI to enable work

SCHEDULED: <2024-07-16 Tue 10:00> [2024-07-16 Tue 16:43]

Orgs to enable AI Assistant for

Organization

edmcnich - cisco Organization ID 03a78cc5-9f53-406c-a722-fa78a57c5695

2)Organization Cisco - pcardot Organization ID 41603826-608e-4a4e-8b62-b17f9064f9bd

2024-07-17 Wednesday

MEETING API Design Meeting work meeting

CLOCK: [2024-07-17 Wed 18:36]–[2024-07-17 Wed 19:08] => 0:32

[2024-07-17 Wed 18:36]

SX EOL

no script with a flag SC @Jyoti: Orbital / SE / IROH Suites, are user and breach suite. In breach there is XDR, but not in User. User suite need, IROH for Secure Access, and SE, and Orbital This is still the glue. Orbital, used the same iroh org-id. They are having their own tenant id. Their mapping will change. SE will setup, via user interaction and will provision IROH. 2 1-click setup. both modules are in enabled state. When they have DI, they will be able to see data from these modules. I have a discussion with PM if this is what we want. We should have the ability to have these modules but can we disable them so DI cannot use them. @Matt: We want to create a module but not to use it. @Yann: also upgrade. @Jyoti: create but being disabled. And prevent enabled from the API.

DONE Batch AI onboarding https://cisco-sbg.atlassian.net/browse/XDR-4729 work

SCHEDULED: <2024-07-17 Wed 10:00> [2024-07-17 Wed 09:50]

DONE Answer question from Jyoti about module instance filtering for SC-only orgs work

SCHEDULED: <2024-07-17 Wed 10:00> [2024-07-17 Wed 09:50]

DONE Answer question to Jyoti about SSX events filtering for XDR work

SCHEDULED: <2024-07-17 Wed 10:00> [2024-07-17 Wed 09:51]

DONE Answer Prerna msg work

SCHEDULED: <2024-07-17 Wed 10:00> [2024-07-17 Wed 09:52]

DONE Answer to Brooke, check webhooks msg work

SCHEDULED: <2024-07-17 Wed 10:00> [2024-07-17 Wed 09:58]

2024-07-18 Thursday

DONE Trust SMA clients msg work

SCHEDULED: <2024-07-18 Thu 10:00> [2024-07-18 Thu 09:41]

INT: "client-03353b43-ff32-4161-9ffc-bb7ce1a12ff7" TEST: "client-046f2e3a-74fa-4f24-bff4-76d0df6e1152" PROD NAM: "client-97d8ce92-3199-4aba-b303-648aa8d02315" PROD EU: "client-7ebc566b-936d-494e-abda-31924cc02673"

2024-07-19 Friday

MEETING SX EOL open issues work meeting

CLOCK: [2024-07-19 Fri 17:59]–[2024-07-20 Sat 01:25] => 7:26

[2024-07-19 Fri 17:59]

DI integration

SE will help the DI onboarding. Will make some API calls from that.

2024-W30

2024-07-23 Tuesday

MEETING Jyoti talks about Orbital change work meeting

[2024-07-23 Tue 19:53]

Agenda (to discuss about)
Notes
Actions

MEETING SE Meeting SX EOL work meeting

[2024-07-23 Tue 17:12]

Agenda (to discuss about)
Notes
Actions

MEETING SX EOL Core Team work meeting

CLOCK: [2024-07-23 Tue 16:37]–[2024-07-23 Tue 19:53] => 3:16

[2024-07-23 Tue 16:37]

Agenda (to discuss about)
Notes
Actions

DONE Change to 6am EST SX EOL work

SCHEDULED: <2024-07-23 Tue 10:00> [2024-07-23 Tue 16:48]

2024-07-26 Friday

DONE Build a tk-search that loop other pagination in iroh-script work

SCHEDULED: <2024-07-29 Mon 10:00> [2024-07-26 Fri 18:15]

2024-W31

2024-07-29 Monday

DONE Présentation depart vacances Cisco work

SCHEDULED: <2024-07-29 Mon 10:00> [2024-07-29 Mon 09:18]

DONE Créer les clients et envoyer la doc work

SCHEDULED: <2024-07-29 Mon 10:00> [2024-07-29 Mon 17:34]

2024-07-31 Wednesday

DONE Veiller au grain pour les org diffs work

SCHEDULED: <2024-07-31 Wed 10:00> [2024-07-31 Wed 08:18]

DONE Check CSC clients that would probably explain the issue work

SCHEDULED: <2024-07-31 Wed 10:00> [2024-07-31 Wed 08:26]

140 KiB Raw Blame History Unescape Escape

2024

2024-W02

2024-01-08 Monday

DONE Upgrade/Downgrade meeting work meeting

2024-01-10 Wednesday

MEETING Q3 Quadrant Slides Readout work meeting

Agenda (to discuss about)

Notes

Actions

2024-W03

2024-01-16 Tuesday

DONE Perform brownfield Superbowl work

MEETING XDR Platform / Automation / Insights / Analytics Planning Session work meeting

Agenda (to discuss about)

Notes

Actions

2024-01-17 Wednesday

MEETING API Design Meeting work meeting

Agenda (to discuss about)

Notes

Actions

MEETING Superbowl link work meeting

Agenda (to discuss about)

Notes

Actions

MEETING Discussion GE quarter work meeting

Agenda (to discuss about)

Notes

Actions

IN-PROGRESS Attempt to trigger XDR/SCC connection work

2024-W04

2024-01-24 Wednesday

MEETING API Design Meeting work meeting

Note

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

Agenda (to discuss about)

Notes

Actions

MEETING MITRE Meeting work meeting

Questions

Sub-techniques?

2024-01-26 Friday

MEETING Monthly Engineering work meeting

Agenda (to discuss about)

Notes

Actions

2024-W05

2024-01-29 Monday

MEETING Impersonate Meeting work meeting

Agenda (to discuss about)

Notes

Actions

2024-01-31 Wednesday

MEETING SCA Integration work meeting

Agenda (to discuss about)

Notes

Actions

DONE Create AO Clients work

DONE ask cherry-pick work

2024-02-01 Thursday

CHAT Guy doc work chat

DONE Prepare Meeting PIAM work work

Jyoti

Guy Response

2024-W06

2024-02-05 Monday

MEETING Jyoti Meeting work meeting

Agenda (to discuss about)

Notes

Actions

MEETING Trigger Aut rules on status update. work meeting

Agenda (to discuss about)

Notes

Actions

2024-02-06 Tuesday

MEETING SX EOL bi-Weekly work meeting

Agenda (to discuss about)

Notes

140 KiB

Raw Blame History