3706 lines
140 KiB
Org Mode
3706 lines
140 KiB
Org Mode
* 2024
|
||
** 2024-W02
|
||
*** 2024-01-08 Monday
|
||
**** DONE Upgrade/Downgrade meeting :work:meeting:
|
||
:LOGBOOK:
|
||
*** 2024-01-10 Wednesday
|
||
**** MEETING Q3 Quadrant Slides Readout :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-10 Wed 16:06]--[2024-01-12 Fri 09:46] => 41:40
|
||
:END:
|
||
[2024-01-10 Wed 16:06]
|
||
***** Agenda (to discuss about)
|
||
***** Notes
|
||
- Meraki MX: IROH 1-click (S)
|
||
- XDR-E-95 : impersonating Portal
|
||
***** Actions
|
||
** 2024-W03
|
||
*** 2024-01-16 Tuesday
|
||
**** DONE Perform brownfield Superbowl :work:
|
||
SCHEDULED: <2024-01-16 Tue>
|
||
[2024-01-16 Tue 19:07]
|
||
**** MEETING XDR Platform / Automation / Insights / Analytics Planning Session :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-16 Tue 18:16]--[2024-01-16 Tue 21:45] => 3:29
|
||
:END:
|
||
[2024-01-16 Tue 18:16]
|
||
***** Agenda (to discuss about)
|
||
***** Notes
|
||
***** Actions
|
||
*** 2024-01-17 Wednesday
|
||
**** MEETING API Design Meeting :work:meeting:
|
||
[2024-01-17 Wed 18:10]
|
||
***** Agenda (to discuss about)
|
||
****** Yann Topics
|
||
1. Ask completion time for FMC Proxy
|
||
2. ES strategies
|
||
a. Detect non-cisco Org and apply retention rule
|
||
b. Rate-limit NGFW entities creations per org
|
||
c. Split XDR-only data from SecureX data to another cluster
|
||
d. Migrate to some GraphDB
|
||
3. Super Bowl
|
||
4. Demo
|
||
***** Notes
|
||
****** @Jyoti: Things to do
|
||
******* Hierarchical Modules
|
||
|
||
Hierarchical Modules
|
||
First Microsoft endpoint, then Defender.
|
||
Jyoti takes notes.
|
||
******* JAMF
|
||
|
||
To @Matt Use the client creds.
|
||
Just a few minutes, and ask them to test. Make a PR.
|
||
For new user, they enter user and password, then we get a token and use to
|
||
request the classic API.
|
||
|
||
@Matt: to know if there is an issue within JAMF UI, you should contact Aaron.
|
||
******* Integration that need a session (Checkpoint)
|
||
|
||
@Matt: discussion between Matt Van Der Host and GB and did not see this
|
||
integration in the Airtable.
|
||
@Jyoti: asking for the github ticket. Assign Shafiq to this ticket, but also
|
||
keep Mark in the loop.
|
||
******* How can we handle On-Prem products? (Design Item)
|
||
|
||
Doing via SSX, AO Remote, and also Cisco Telemetry.
|
||
Something we need to figure out maybe with CDO.
|
||
Which one should be standardized?
|
||
Design item.
|
||
******* CDO Firewall Proxy
|
||
|
||
Tentative 2 releases (mid-Feb)
|
||
|
||
- @Jyoti: ping me if we have something else.
|
||
***** Actions
|
||
**** MEETING Superbowl link :work:meeting:
|
||
[2024-01-17 Wed 17:17]
|
||
***** Agenda (to discuss about)
|
||
***** Notes
|
||
***** Actions
|
||
**** MEETING Discussion GE quarter :work:meeting:
|
||
[2024-01-17 Wed 14:39]
|
||
***** Agenda (to discuss about)
|
||
- XDR Incident Correlation ; Planning Blocker <no IROH involvement>
|
||
- IM/AUT Incident Response Enhancements ; Lisa to send details on dependencies
|
||
- MITRE ATTACK ;
|
||
- ES XDR-only store plan ;
|
||
***** Notes
|
||
- depasser les IOPS
|
||
***** Actions
|
||
**** IN-PROGRESS Attempt to trigger XDR/SCC connection :work:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-17 Wed 14:28]--[2024-01-18 Thu 18:09] => 27:41
|
||
:END:
|
||
[2024-01-17 Wed 14:28]
|
||
|
||
#+begin_src bash
|
||
#!/usr/bin/env bash
|
||
OKTA_URL='https://ciscob2b.okta.com/oauth2/ausr5ltkvjT6lODuy357'
|
||
CLIENT_ID=XXX
|
||
CLIENT_SECRET=XXX
|
||
ORG_ID="1bc3e2c7-8aaf-440c-bc82-9b9a3f538283"
|
||
USER_EMAIL="nikm@wblservices.com"
|
||
# SCOPE="security:global:provisioning-status:write"
|
||
SCOPE="security:xdr:provisioning:tenants-attach"
|
||
JWT=$( curl -XPOST "$OKTA_URL/v1/token" \
|
||
-u "$CLIENT_ID:$CLIENT_SECRET" \
|
||
-H "Content-Type: application/x-www-form-urlencoded" \
|
||
-H "Accept: application/json" \
|
||
-d 'grant_type=client_credentials&scope='"$SCOPE" | jq '.access_token' | sed 's/"//g' )
|
||
curl -XPOST "$OKTA_URL/v1/productInstanceInvitation" \
|
||
-H "Authorization: Bearer $JWT" \
|
||
-H 'Content-Type: application/json' \
|
||
-d '{"region":"NAM","productExternalTenantId":"'"$ORG_ID"'","users":["'"$USER_EMAIL"'"]}'
|
||
#+end_src
|
||
** 2024-W04
|
||
*** 2024-01-24 Wednesday
|
||
**** MEETING API Design Meeting :work:meeting:
|
||
[2024-01-24 Wed 19:05]
|
||
- What was discussed
|
||
- What was decided
|
||
*- What are the next tasks and who is taking care of them
|
||
***** Note
|
||
- @Jyoti: Microsoft Defender start this week. Discussion with @Mark.
|
||
- @Jyoti: discuss about modernizing iroh-async; perhaps use kafka. Need a
|
||
discussion with GE.
|
||
- @Jyoti Create a new IROH-AI service to work with AI backend.
|
||
We need to proxy to them.
|
||
The AI service will be core service.
|
||
for Q3 SOC assistant.
|
||
***** TODO Add to Q3: SOC Assistant create iroh-ai module to proxy to AI backend; assign Mark or maybe Tiffany
|
||
**** MEETING All Hands :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-24 Wed 18:33]--[2024-01-25 Thu 21:58] => 27:25
|
||
:END:
|
||
[2024-01-24 Wed 18:33]
|
||
***** Agenda (to discuss about)
|
||
***** Notes
|
||
|
||
Some internal AI/ML spaces for collaboration:
|
||
- networkGPT | Join: https://eurl.io/#gHbta7lro
|
||
- Generative AI Explorers | Join: https://eurl.io/#Z4vekB6ph
|
||
- AI_ChatGPT | Join: https://eurl.io/#nbJWbnj12
|
||
- GAI Engineering Forum | Join: https://eurl.io/#k9dt-XxWv
|
||
- Artificial Intelligence and Machine Learning | Join: https://eurl.io/#Bk7grXKuV
|
||
- Cisco Enterprise Chat AI - Support - https://eurl.io/#cVPv-NLF7
|
||
***** Actions
|
||
**** MEETING MITRE Meeting :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-24 Wed 16:05]--[2024-01-24 Wed 16:08] => 0:03
|
||
:END:
|
||
[2024-01-24 Wed 16:05]
|
||
- Presentation
|
||
|
||
1. Phases
|
||
1. Talos visualisation (product Tacticts & Techniques coverage)
|
||
2. How many incidents per technique
|
||
|
||
Going Forward:
|
||
|
||
- probably dynamic product coverage from Talos
|
||
- Recommendations (which product to add)
|
||
- perhaps Scores (from Kenna)
|
||
**** Questions
|
||
***** Sub-techniques?
|
||
|
||
Not visible, every things goes in the biggest bucket.
|
||
At least for phase 1.
|
||
*** 2024-01-26 Friday
|
||
**** MEETING Monthly Engineering :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-26 Fri 17:24]--[2024-01-26 Fri 19:17] => 1:53
|
||
:END:
|
||
[2024-01-26 Fri 17:24]
|
||
***** Agenda (to discuss about)
|
||
***** Notes
|
||
****** IROH Services Team
|
||
******* Performances
|
||
- New Datadog Monitoring, Visualizations & Alerts (thanks to Jerome and Patrick)
|
||
Really improved visibility of our work and the impact on performance.
|
||
- In particular new JMX metrics for clj-http connections. Thanks Matt!
|
||
- Kafka monitoring.
|
||
|
||
- New Alerting (thanks to Patrick)
|
||
Very important to detect performance issues as quickly as possible.
|
||
|
||
- We improved many aspect of our platform, in particular in iroh-async, but not
|
||
only, we also improved some PG requests.
|
||
******* Quality
|
||
- Improved our system to declare error statuses with schemas. Thanks Ambrose!
|
||
- Ongoing node configuration improvements.
|
||
******* Features
|
||
|
||
- Ambrose worked on asset rescoring.
|
||
- Data Retention cleanup for events in Postgres
|
||
- Universal Provisioning:
|
||
- Part of it Support External JWT, from Okta, but also FMC.
|
||
- Brownfield customer, ability to upgrade existing SecureX users to XDR
|
||
- Impersonator tracking which if delivered should help TAC and quality teams.
|
||
******* Bonus
|
||
|
||
Great work and dedication to discover, and resolve production issues.
|
||
Thanks to everyone involved!
|
||
|
||
Still Planning Many improvements learned from these events.
|
||
***** Actions
|
||
** 2024-W05
|
||
*** 2024-01-29 Monday
|
||
**** MEETING Impersonate Meeting :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-29 Mon 15:59]--[2024-01-29 Mon 22:28] => 6:29
|
||
:END:
|
||
[2024-01-29 Mon 15:59]
|
||
***** Agenda (to discuss about)
|
||
|
||
Hi All,
|
||
|
||
I would like to have a chat with this group regarding this epic https://ciscosecurity.aha.io/epics/XDR-E-145 (Priority 21 in Q3 list).
|
||
We have a separate ask from the XDR TAC team to enable user impersonation for the TAC engineering for troubleshooting purposes, which is a discovery only effort for Q3.
|
||
|
||
@Petr Cernohorsky (pcernoho) does this epic relate to user impersonation as well? Or is this something specific to incidents, that does not involve Yann and the team to develop user impersonation infrastructure?
|
||
***** Notes
|
||
|
||
New Portal, with read-only impersonation + stats per org (nb of incident,
|
||
selection, sort, etc…)
|
||
***** Actions
|
||
|
||
Wait for UX to design
|
||
*** 2024-01-31 Wednesday
|
||
**** MEETING SCA Integration :work:meeting:
|
||
[2024-01-31 Wed 17:09]
|
||
***** Agenda (to discuss about)
|
||
|
||
@Namrata: top priority for the team.
|
||
What are the priorities.
|
||
New features that do not exist in XDR to integrate.
|
||
Forming to form a backlog for us to converge.
|
||
|
||
Ask @Crystal to share a timeline.
|
||
|
||
Technical side of things, plan to implement the things to support the convergence.
|
||
On both teams.
|
||
|
||
This is the intent of the conversation.
|
||
***** Notes
|
||
|
||
- @Crystal (Crystal Storar) low hanging fruit from the customer.
|
||
Wrong login page.
|
||
User Management to sync between SCA and XDR.
|
||
SCA Free Trial, should probably disappear.
|
||
- @Jyoti: we need a deeper dive. We need to go page by page.
|
||
And have that discussion.
|
||
- @Crystal: already happened.
|
||
- @Jeff (Jeff Markey)
|
||
- @Namrata low hanging fruit vs big step
|
||
please Crystal share the timeline?
|
||
- @Crystal cautious about public timeline.
|
||
We have an obligation to deliver outcome to our customers via XDR through this
|
||
contract period.
|
||
12 to 18 month for the convergence.
|
||
Goal, move feature from SCA to XDR step by step.
|
||
- @Jeff what about removing features? Do they have access to XDR?
|
||
- @Crystal yes.
|
||
- @Jeremy how many people, how are we gonna cut some features to make that happen?
|
||
- @Namrata first form the backlog, then the timeline will be tied to this.
|
||
... Integration configuration being top priority.
|
||
Let's focus on that.
|
||
Then the devices page to send that to DI to leverage network behaviour.
|
||
- @Crystal another big one, merge into investigate.
|
||
- @Derrick the Device view you mentioned is evaluated this quarter.
|
||
- @Namrata Top Priorities:
|
||
Integration UX, Device leverage, Investigate and User Management.
|
||
***** Actions
|
||
**** DONE Create AO Clients :work:
|
||
SCHEDULED: <2024-02-09 Fri 11:00>
|
||
:LOGBOOK:
|
||
CLOCK: [2024-01-31 Wed 16:11]--[2024-01-31 Wed 20:53] => 4:42
|
||
:END:
|
||
[2024-01-31 Wed 16:11]
|
||
|
||
- Remove rate-limit of client 1
|
||
- Put rate-limit back of client 0
|
||
- Create new client with org-level-authorization
|
||
**** DONE ask cherry-pick :work:
|
||
SCHEDULED: <2024-01-31 Wed 15:00>
|
||
[2024-01-31 Wed 14:16]
|
||
*** 2024-02-01 Thursday
|
||
**** CHAT Guy doc :work:chat:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-01 Thu 17:02]--[2024-02-01 Thu 20:51] => 3:49
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-01 Thu 08:49]--[2024-02-01 Thu 17:02] => 8:13
|
||
:END:
|
||
[2024-02-01 Thu 08:48]
|
||
***** Jyoti
|
||
|
||
Option 2: Having a Common IROH per enterprise that’s converted to XDR when XDR is purchased
|
||
|
||
Assumptions:
|
||
- There can only be one XDR per region per enterprise - SCC should enforce it
|
||
- One common iroh per region per enterprise
|
||
- IROH will have an API to exchange a PIAM token with an IROH token
|
||
- API to provision the iroh tenant in the enterprise should exist
|
||
- Provisioning should include a flag to indicate that this is a common tenant
|
||
- SCC UI should support the iroh backend for integrations
|
||
- XDR will need to get the PIAM token to talk to SSX (service scoped token)
|
||
|
||
Sub-Option 1 - IROH token in the browser
|
||
- Separate iroh-auth tokens in the browser per region
|
||
- When are these tokens generated?
|
||
- Front end to backend uses IROH session token
|
||
- Service to service uses IROH token
|
||
- All iroh services continue to use the IROH token
|
||
|
||
Sub-Option 2
|
||
- Browser only stores the PIAM token
|
||
- Backends of microapps support the PIAM token
|
||
- Front end to backend uses PIAM session token
|
||
- Service to service uses IROH token
|
||
- Integrations (iroh-int) works with PIAM token
|
||
- Iroh-proxy works with PIAM token
|
||
|
||
SSX
|
||
- SSX enterprise tenant is created when enterprise is born
|
||
- XDR will call the SSX enterprise using the PIAM token
|
||
- Common iroh does not need to provision SSX
|
||
- Iroh-sse service will need to work with PIAM token
|
||
|
||
Firewall
|
||
- Device OAuth flow will get proxied to CDO
|
||
- CDO will register the devices with the CDO SSX tenant
|
||
- If CDO is not brought into the enterprise, XDR will not see the devices registered via CDO (*)
|
||
|
||
Integrations
|
||
- If common integrations that are not to be used by XDR, there should be a flag in the module type to allow for that logic
|
||
- New API in iroh-int for SCC Integration UI
|
||
|
||
Open Question:
|
||
- If a common tenant existed and the XDR tenant was brought in later to be attached to the Enterprise, how is the common iroh tenant handled?
|
||
- If the attach operation happens before the common iroh tenant exists, this will not be a problem
|
||
****** Remarks/Questions
|
||
******* PIAM ↔ IROH Token Exchange
|
||
|
||
On: "IROH will have an API to exchange a PIAM token with an IROH token"
|
||
|
||
What does precisely mean?
|
||
|
||
An IROH token is linked to a specific ~org-id~.
|
||
The PIAM token does not have any ~org-id~.
|
||
So not many options:
|
||
|
||
1. Auto select the ~org-id~ to be this non-XDR / IROH-only ~enterprise-id~ org
|
||
2. In order to exchange, someone must provide one of the matching ~org-id~ (with
|
||
potential exchange)
|
||
|
||
#+begin_src
|
||
Client => IROH: I have this PIAM token, give me an IROH token
|
||
IROH => Client: You have many matching IROH Identities, here there are:
|
||
1. PIAM Global Org (just enterprise-id)
|
||
2. org-1
|
||
...
|
||
n. org-n
|
||
Client => IROH:
|
||
1. org-n
|
||
#+end_src
|
||
|
||
Proposal: Do both and more by supporting 2 as well as:
|
||
|
||
#+begin_src
|
||
Client => IROH: I have this PIAM token, give me an IROH token for my PIAM Global Org
|
||
IROH => Client: Here it is
|
||
#+end_src
|
||
|
||
#+begin_src
|
||
Client => IROH: I have this PIAM token, give me an IROH token for my Org org-1
|
||
IROH => Client: Here it is
|
||
#+end_src
|
||
******* modules and PIAM token
|
||
|
||
#+begin_quote
|
||
Sub Option 2
|
||
...
|
||
- Integrations (iroh-int) works with PIAM token
|
||
- Iroh-proxy works with PIAM token
|
||
#+end_quote
|
||
|
||
For this:
|
||
|
||
Case 1:
|
||
|
||
If the relay module directly support PIAM token, we would need the opposite
|
||
service.
|
||
Exchange an IROH token for a PIAM token.
|
||
Because modules are called even out of session.
|
||
|
||
#+begin_src
|
||
IROH => PIAM: I have this IROH token, give me a PIAM token
|
||
#+end_src
|
||
|
||
And then add a new authorization mechanism in module-types.
|
||
|
||
But this goes with potential security risks as the PIAM token might provide more
|
||
scopes/authorizations/capabilities than the IROH token.
|
||
|
||
Case 2: The module/relay is unchanged, we need to retrieve the IROH token from
|
||
the PIAM token. See previous section.
|
||
******* SSX called from IROH
|
||
|
||
#+begin_quote
|
||
XDR will call the SSX enterprise using the PIAM token
|
||
#+end_quote
|
||
|
||
Same potential issue. How could XDR get the PIAM token.
|
||
|
||
There are many different PIAM tokens. So:
|
||
|
||
- Is the PIAM token tied to a single user?
|
||
- Do we support Enterprise-level PIAM token?
|
||
- Could we get a PIAM token from an IROH token without privilege escalation?
|
||
- Would the PIAM token could be retrieved from an XDR org, or from the
|
||
special Enterprise Org?
|
||
******* New API in iroh-int for SCC Integration UI?
|
||
not sure what is needed there.
|
||
******* Open questions
|
||
|
||
The way I envisionned it:
|
||
|
||
Always an Enterprise Org which is invalid for XDR usage, just focused on PIAM functionalities.
|
||
With potential bridges (like copying module-instances between this main Org and
|
||
the real XDR org).
|
||
|
||
If the customer also need XDR, then we create another XDR org, again with
|
||
potential bridges such that the XDR Org could be affected by the Enterprise Org.
|
||
****** 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:
|
||
|
||
1. Add a constraint mechanism to prevent duplicate enterprise_id (in the same Region).
|
||
2. (optional) Add a constraint to prevent duplicate cross region (to enforce 1
|
||
enterprise on all XDR instances (Region & geo))
|
||
3. 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…
|
||
4. 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.
|
||
a. 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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-05 Mon 19:49]--[2024-02-05 Mon 21:44] => 1:55
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-05 Mon 16:01]--[2024-02-05 Mon 16:30] => 0:29
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-06 Tue 17:04]--[2024-02-07 Wed 18:37] => 25:33
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-08 Thu 14:29]--[2024-02-08 Thu 15:29] => 1:00
|
||
:END:
|
||
[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 [[webexteams://im?space=ad5dc9f0-c5ed-11ee-a4c5-fb1787add317][SCA]] :work:
|
||
SCHEDULED: <2024-02-08 Thu 14:00>
|
||
[2024-02-08 Thu 08:31]
|
||
*** 2024-02-09 Friday
|
||
**** DONE Create AI Clients :work:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-09 Fri 09:47]--[2024-02-09 Fri 15:26] => 5:39
|
||
:END:
|
||
[2024-02-09 Fri 09:47]
|
||
**** DONE Create AI Clients complete [[https://github.com/advthreat/securex-ui-shell/issues/514#issuecomment-1932496690][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-12 Mon 19:50]--[2024-02-12 Mon 21:27] => 1:37
|
||
:END:
|
||
[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.
|
||
1. 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.
|
||
2. @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:
|
||
:LOGBOOK:
|
||
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
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-12 Mon 16:30]--[2024-02-12 Mon 17:03] => 0:33
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-13 Tue 17:06]--[2024-02-14 Wed 14:08] => 21:02
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-14 Wed 14:08]--[2024-02-14 Wed 19:34] => 5:26
|
||
:END:
|
||
[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.
|
||
|
||
#+begin_comment
|
||
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"
|
||
#+end_comment
|
||
|
||
|
||
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.
|
||
#+begin_comment
|
||
What is an "integration" in this context and how XDR UI could be able to show one?
|
||
#+end_comment
|
||
|
||
- 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.
|
||
#+begin_comment
|
||
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.
|
||
#+end_comment
|
||
****** Scenario - Separate XDR tenant in the enterprise
|
||
|
||
#+begin_comment
|
||
What about Org switching? Should we hide the headless Orgs in the org selector
|
||
in XDR UI?
|
||
#+end_comment
|
||
|
||
|
||
#+begin_src
|
||
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.
|
||
#+end_src
|
||
|
||
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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-15 Thu 18:29]--[2024-02-15 Thu 22:14] => 3:45
|
||
:END:
|
||
[2024-02-15 Thu 18:29]
|
||
- Agenda (to discuss about)
|
||
- Notes
|
||
- Actions
|
||
**** MEETING XDR v2 instant demo :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-15 Thu 16:00]--[2024-02-15 Thu 17:14] => 1:14
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
- State "CANCELED" from "IN-PROGRESS" [2024-02-29 Thu 18:53] \\
|
||
we'll go with option 2
|
||
:END:
|
||
[2024-02-20 Tue 20:45]
|
||
**** MEETING SX EOL :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-20 Tue 20:22]--[2024-02-20 Tue 21:01] => 0:39
|
||
:END:
|
||
[2024-02-20 Tue 20:22]
|
||
- Agenda (to discuss about)
|
||
*** 2024-02-21 Wednesday
|
||
**** MEETING SCA Convergence to XDR :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-21 Wed 17:06]--[2024-02-21 Wed 17:57] => 0:51
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-26 Mon 20:01]--[2024-02-28 Wed 18:57] => 46:56
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-02-28 Wed 18:57]--[2024-02-28 Wed 21:15] => 2:18
|
||
:END:
|
||
[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 [[webexteams://im?space=b5844a30-2e19-11ee-b0bb-8575ace105f3&message=5c5d9830-d666-11ee-96f8-cded4ea1ae28][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-04 Mon 18:37]--[2024-03-04 Mon 20:47] => 2:10
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-05 Tue 18:05]--[2024-03-05 Tue 19:08] => 1:03
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-11 Mon 18:15]--[2024-03-11 Mon 20:01] => 1:46
|
||
:END:
|
||
[2024-03-11 Mon 18:15]
|
||
**** DONE Repondre a [[https://github.com/advthreat/incident-manager/issues/2408][SXO webhook]] :work:
|
||
SCHEDULED: <2024-03-11 Mon 17:30>
|
||
[2024-03-11 Mon 16:42]
|
||
**** IN-PROGRESS Morning tour :work:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-11 Mon 08:02]--[2024-03-11 Mon 08:37] => 0:35
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
- State "CANCELED" from "TODO" [2024-03-15 Fri 10:24]
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
- 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
|
||
:END:
|
||
[2024-03-13 Wed 17:57]
|
||
**** MEETING PIAM Ryan Meeting :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-13 Wed 16:15]--[2024-03-13 Wed 17:57] => 1:42
|
||
:END:
|
||
[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:
|
||
a. Create an API asking for a specific tenant and provide the token for it
|
||
b. 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 [[*webexteams://im?space=47c17620-e148-11ee-bb7f-b544af00ee33][room]] :work:chat:
|
||
[2024-03-13 Wed 15:55]
|
||
**** CHAT Blocker, SXO onboarding failing discussion [[webexteams://im?space=5ea12da0-e13d-11ee-a581-b9ddc7f36159][room]] :work:chat:
|
||
[2024-03-13 Wed 15:55]
|
||
**** CHAT Brownfield using NAM instead of PREVIEW for TEST [[webexteams://im?space=06fcf5e0-9dca-11ee-baad-23b6ab543fdf][room]] :work:chat:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-13 Wed 15:54]--[2024-03-13 Wed 16:15] => 0:21
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
- 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
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
:END:
|
||
[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 [[webexteams://im?space=331b38f0-6218-11e9-9aae-c5b8cb291b23&message=97c18840-e22e-11ee-b9e1-e78ab649c17a][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-18 Mon 17:35]--[2024-03-18 Mon 21:43] => 4:08
|
||
:END:
|
||
[2024-03-18 Mon 17:35]
|
||
*** 2024-03-19 Tuesday
|
||
**** MEETING SX EOL bi-weekly :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-19 Tue 19:36]--[2024-03-19 Tue 23:22] => 3:46
|
||
:END:
|
||
[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 [[webexteams://im?space=47c17620-e148-11ee-bb7f-b544af00ee33&message=2b747830-e57d-11ee-9595-cf0ffe963bb2][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-20 Wed 17:31]--[2024-03-20 Wed 22:16] => 4:45
|
||
:END:
|
||
[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 [[webexteams://im?space=a950c770-e7be-11ee-a86d-41e6b0cb7428][room]] :work:chat:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-22 Fri 09:11]--[2024-03-22 Fri 09:25] => 0:14
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-25 Mon 10:08]--[2024-03-26 Tue 08:47] => 22:39
|
||
:END:
|
||
[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 [[webexteams://im?space=5daec1a0-d7c0-11ed-92fa-6d628c54e741&message=c8df0740-eb98-11ee-9472-bff1df65375b][msg]] :work:chat:
|
||
[2024-03-26 Tue 18:57]
|
||
**** CHAT Discuss about AI provisioning :work:chat:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-26 Tue 08:47]--[2024-03-26 Tue 20:09] => 11:22
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-27 Wed 17:31]--[2024-03-27 Wed 18:51] => 1:20
|
||
:END:
|
||
[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 [[webexteams://im?space=721f8dc0-cd12-11ee-a899-374931ff16ab][room]] :work:
|
||
**** DONE Help Meraki [[webexteams://im?space=b5844a30-2e19-11ee-b0bb-8575ace105f3&message=17b44eb0-ebb3-11ee-92d3-d133b7376b1b][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-28 Thu 12:15]--[2024-03-28 Thu 18:32] => 6:17
|
||
:END:
|
||
[2024-03-28 Thu 12:15]
|
||
*** 2024-03-29 Friday
|
||
**** CHAT Search for user without any user-name :work:chat:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-03-29 Fri 19:17]--[2024-03-29 Fri 22:14] => 2:57
|
||
:END:
|
||
[2024-03-29 Fri 19:17]
|
||
|
||
#+begin_src
|
||
["not",{"like-match":["_%"],"search-in-paths":[["user-name"]]}]
|
||
#+end_src
|
||
**** DONE Answer to Engine [[webexteams://im?space=a1c4c7c0-ed3d-11ee-8f4b-23ee1d8b63f9][room]] :work:
|
||
SCHEDULED: <2024-03-29 Fri 10:00>
|
||
[2024-03-29 Fri 09:12]
|
||
**** DONE Take a look at doc [[webexteams://im?space=ff60e0b0-8d3b-11ee-a677-3d6eefa66fd9&message=b4945060-ed41-11ee-babd-c99a359c3dac][msg]] :work:
|
||
SCHEDULED: <2024-03-29 Fri 10:00>
|
||
[2024-03-29 Fri 09:10]
|
||
**** DONE Answer to Meraki [[webexteams://im?space=b5844a30-2e19-11ee-b0bb-8575ace105f3&message=d7b48fe0-ed52-11ee-ba18-2782508ab6e6][msg]] :work:
|
||
SCHEDULED: <2024-03-29 Fri 10:00>
|
||
[2024-03-29 Fri 09:10]
|
||
**** DONE Retrieve SCSO name field [[webexteams://im?space=76c797f0-ed51-11ee-a701-6dfa1ca0626f&message=922e7e10-ed6e-11ee-88e4-61f35a45a3c1][msg]] :work:
|
||
SCHEDULED: <2024-03-29 Fri 10:00>
|
||
[2024-03-29 Fri 08:48]
|
||
|
||
1. PIAM Provisioning does not provide any user name (search for issue)
|
||
2. SCSO should provide a user name
|
||
3. 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:
|
||
|
||
1. 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.
|
||
|
||
2. When and why a User might not have a user-name field?
|
||
|
||
a. 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.
|
||
b. 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.
|
||
c. 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 [[webexteams://im?space=721f8dc0-cd12-11ee-a899-374931ff16ab&message=996530f0-f036-11ee-9037-211a83a01eed][msg]] :work:
|
||
SCHEDULED: <2024-04-02 Tue 10:00>
|
||
[2024-04-02 Tue 10:45]
|
||
**** DONE Answer Olympics invitation issues [[https://cisco-sbg.atlassian.net/browse/XDR-990][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-03 Wed 11:03]--[2024-04-03 Wed 21:47] => 10:44
|
||
:END:
|
||
[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 [[webexteams://im?space=de666fe0-e85a-11ee-b2be-31ed59f4a874&message=746f8370-f2bd-11ee-8848-d956ec5eff8d][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-09 Tue 16:03]--[2024-04-10 Wed 14:46] => 22:43
|
||
:END:
|
||
[2024-04-09 Tue 16:03]
|
||
|
||
Requirements solidified
|
||
*** 2024-04-11 Thursday
|
||
**** MEETING RBAC Custom Roles :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-11 Thu 15:03]--[2024-04-14 Sun 21:33] => 78:30
|
||
:END:
|
||
[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 [[webexteams://im?space=db149a90-e8b4-11eb-9fdb-3b8d98a2bf4d&message=276f5bd0-f822-11ee-8915-41040ecb3969][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-15 Mon 16:55]--[2024-04-16 Tue 00:47] => 7:52
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-15 Mon 16:31]--[2024-04-15 Mon 16:45] => 0:14
|
||
:END:
|
||
[2024-04-15 Mon 16:31]
|
||
|
||
@Danny;
|
||
POV moting other to STC in Q4, their going to start with PIAM.
|
||
|
||
1. Entitlement removed
|
||
2. 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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-16 Tue 16:35]--[2024-04-16 Tue 18:30] => 1:55
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-18 Thu 16:32]--[2024-04-18 Thu 19:47] => 3:15
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-22 Mon 16:30]--[2024-04-23 Tue 10:15] => 17:45
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-23 Tue 14:32]--[2024-04-24 Wed 20:06] => 29:34
|
||
:END:
|
||
[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 [[https://github.com/advthreat/iroh/pull/9208][token cache]] :work:
|
||
SCHEDULED: <2024-04-23 Tue 10:00>
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-23 Tue 10:15]--[2024-04-23 Tue 14:32] => 4:17
|
||
:END:
|
||
[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 [[https://cisco-sbg.atlassian.net/browse/XDR-1598][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-25 Thu 18:02]--[2024-04-26 Fri 01:59] => 7:57
|
||
:END:
|
||
[2024-04-25 Thu 18:02]
|
||
- Agenda (to discuss about)
|
||
- Notes
|
||
- Actions
|
||
**** MEETING Didi CII provisioning/integration with XDR :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-25 Thu 15:03]--[2024-04-25 Thu 16:06] => 1:03
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-26 Fri 17:58]--[2024-04-29 Mon 17:01] => 71:03
|
||
:END:
|
||
[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 [[webexteams://im?space=b5136a40-6687-11ed-9679-4b10798d7c1a&message=2525a150-0343-11ef-9fc2-2d92d0fafd0a][msg]] :work:
|
||
SCHEDULED: <2024-04-26 Fri 10:00>
|
||
:LOGBOOK:
|
||
- State "CANCELED" from "TODO" [2024-04-30 Tue 18:16]
|
||
:END:
|
||
[2024-04-26 Fri 09:06]
|
||
** 2024-W18
|
||
*** 2024-04-29 Monday
|
||
**** MEETING But Santosh :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-04-29 Mon 17:01]--[2024-04-29 Mon 21:48] => 4:47
|
||
:END:
|
||
[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:
|
||
|
||
1. 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.
|
||
|
||
|
||
2. 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.
|
||
|
||
3. 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
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-14 Tue 16:35]--[2024-05-14 Tue 22:26] => 5:51
|
||
:END:
|
||
[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:
|
||
|
||
1. testing before the date
|
||
2. 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:
|
||
|
||
1. testing both the before and after SX EOL behavior before the SX EOL date for
|
||
QA in the TEST environment.
|
||
2. 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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-15 Wed 15:00]--[2024-05-15 Wed 19:24] => 4:24
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-17 Fri 10:39]--[2024-05-17 Fri 11:37] => 0:58
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-22 Wed 18:03]--[2024-05-22 Wed 22:03] => 4:00
|
||
:END:
|
||
[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… [[webexteams://im?space=de666fe0-e85a-11ee-b2be-31ed59f4a874&message=1d03acc0-1774-11ef-83c0-7fc37d118b0f][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-23 Thu 16:53]--[2024-05-23 Thu 18:26] => 1:33
|
||
:END:
|
||
[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 [[webexteams://im?space=b8c12c60-18dd-11ed-8af1-af2bd6a6c8a4&message=109752c0-1869-11ef-8d9f-95e173807070][bad-module]] :work:
|
||
SCHEDULED: <2024-05-23 Thu 10:00>
|
||
[2024-05-23 Thu 08:17]
|
||
**** DONE Robert Harris redirect bug? [[https://cisco-sbg.atlassian.net/browse/XDR-3194][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:
|
||
|
||
1. the UI will call the ~/whoami~ endpoint
|
||
This will contain:
|
||
|
||
#+begin_src js
|
||
{"org" {"main-app" APP}
|
||
"metas" {"apps" {APP {"url" "URL of APP"}}}
|
||
#+end_src
|
||
|
||
2. Then the logic BEFORE AND AFTER SX EOL will be exactly the same:
|
||
|
||
#+begin_src js
|
||
let app = whoami.org["main-app"];
|
||
let expectedURL = whoami.metas.apps[app].url;
|
||
if (currentURL does not match expectedURL) {
|
||
redirectTo(expectedURL);
|
||
}
|
||
#+end_src
|
||
***** 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):
|
||
|
||
#+begin_src clojure
|
||
{...
|
||
: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"}}
|
||
...}
|
||
#+end_src
|
||
** 2024-W22
|
||
*** 2024-05-27 Monday
|
||
**** CHAT Answer to Dan :work:chat:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-27 Mon 10:58]--[2024-05-27 Mon 15:46] => 4:48
|
||
:END:
|
||
[2024-05-27 Mon 10:58]
|
||
|
||
#+begin_src js
|
||
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:
|
||
}
|
||
}
|
||
#+end_src
|
||
|
||
|
||
#+begin_src js
|
||
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)
|
||
}
|
||
#+end_src
|
||
**** DONE Keep link to history comment [[webexteams://im?space=b62bf8f0-6062-11ed-9564-a57f2c094899&message=8862d630-142c-11ef-b965-7f09fb9de79f][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-28 Tue 16:32]--[2024-05-28 Tue 17:32] => 1:00
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-05-29 Wed 16:01]--[2024-05-29 Wed 23:58] => 7:57
|
||
:END:
|
||
[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 [[https://github.com/advthreat/iroh/blob/77b700a7793db56c55aea8816ca030c4a90edb59/services/tk-stores/src/tk_stores/crud_store/postgres.clj#L114][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-04 Tue 15:34]--[2024-06-04 Tue 21:47] => 6:13
|
||
:END:
|
||
[2024-06-04 Tue 15:34]
|
||
|
||
Part en islande.
|
||
*** 2024-06-05 Wednesday
|
||
**** DONE Comment on Orbital 1-click/0-click [[webexteams://im?space=68f439c0-7a5c-11ee-9e3c-6f3b2158786b&message=946af9d0-22d2-11ef-b3fd-d1b4af0c75a8][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>
|
||
:LOGBOOK:
|
||
- State "CANCELED" from "TODO" [2024-06-24 Mon 09:17] \\
|
||
Forgot what I meant, probably onboarding and not entitlemetn
|
||
:END:
|
||
[2024-06-05 Wed 10:33]
|
||
**** DONE Create webhooks for SCA on Meraki module change :work:
|
||
SCHEDULED: <2024-06-05 Wed 10:00>
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-05 Wed 15:03]--[2024-06-05 Wed 19:11] => 4:08
|
||
:END:
|
||
[2024-06-05 Wed 15:03]
|
||
|
||
|
||
#+begin_src js
|
||
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",
|
||
}
|
||
#+end_src
|
||
***** INT
|
||
|
||
#+begin_src js :var region="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"
|
||
}
|
||
#+end_src
|
||
|
||
#+RESULTS:
|
||
** 2024-W24
|
||
*** 2024-06-10 Monday
|
||
**** IN-PROGRESS Diagram for tomorrow :work:
|
||
[2024-06-10 Mon 18:39]
|
||
|
||
#+begin_src plantuml :file SE_Orbital_provisioning.png
|
||
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
|
||
#+end_src
|
||
|
||
#+RESULTS:
|
||
[[file: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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-10 Mon 16:35]--[2024-06-10 Mon 21:31] => 4:56
|
||
:END:
|
||
[2024-06-10 Mon 16:35]
|
||
|
||
X
|
||
**** DONE Change AI Assistant onboarding conf [[webexteams://im?space=de666fe0-e85a-11ee-b2be-31ed59f4a874&message=0fa75120-2364-11ef-905f-f3038d0b970a][webex]] :work:
|
||
CLOSED: [2024-08-12 Mon 10:03] SCHEDULED: <2024-06-10 Mon 10:00>
|
||
:LOGBOOK:
|
||
- 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
|
||
:END:
|
||
[2024-06-10 Mon 09:20]
|
||
**** DONE Check non-admin login discussion [[webexteams://im?space=ff60e0b0-8d3b-11ee-a677-3d6eefa66fd9&message=4d06df10-2434-11ef-acbc-1da1c6b70925][webex]] :work:
|
||
SCHEDULED: <2024-06-10 Mon 10:00>
|
||
[2024-06-10 Mon 09:23]
|
||
**** DONE Check scopes for Rekha [[webexteams://im?space=b8c12c60-18dd-11ed-8af1-af2bd6a6c8a4&message=b4112a10-241d-11ef-a6d8-0b2d4f62e498][webex]] :work:
|
||
CLOSED: [2024-08-12 Mon 10:03] SCHEDULED: <2024-06-10 Mon 10:00>
|
||
:LOGBOOK:
|
||
- 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.
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
- State "CANCELED" from "TODO" [2024-06-17 Mon 16:33] \\
|
||
Yolo
|
||
:END:
|
||
[2024-06-10 Mon 16:36]
|
||
*** 2024-06-11 Tuesday
|
||
**** MEETING Test Plan :work:meeting:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-11 Tue 16:39]--[2024-06-12 Wed 09:58] => 17:19
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-12 Wed 09:58]--[2024-06-12 Wed 21:36] => 11:38
|
||
:END:
|
||
[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 [[https://cisco-sbg.atlassian.net/browse/XDR-4425][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-17 Mon 15:30]--[2024-06-18 Tue 16:35] => 25:05
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-18 Tue 16:35]--[2024-06-18 Tue 21:26] => 4:51
|
||
:END:
|
||
[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:
|
||
|
||
#+begin_src clojure
|
||
(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)))
|
||
#+end_src
|
||
|
||
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:
|
||
|
||
1. User va sur l'URL d'XDR
|
||
2. Il choisit son compte SC-only
|
||
3. Il va vers XDR
|
||
4. l'UI d'XDR le redirige vers l'URL de SC
|
||
5. l'User est redirigé vers l'account selection
|
||
6. L'User selectionne son compte XDR
|
||
7. L'user va vers SC UI
|
||
8. L'UI de SC redirige l'user vers l'URL de XDR
|
||
9. 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:
|
||
|
||
#+begin_src clojure
|
||
(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)))
|
||
|
||
#+end_src
|
||
|
||
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:
|
||
|
||
1. User accesses an XDR URL.
|
||
2. They select their SC-only account.
|
||
3. They go to the XDR UI.
|
||
4. The XDR UI redirects them back to the SC URL.
|
||
5. The user is redirected to the account selection page.
|
||
6. The user selects their XDR account.
|
||
7. The user goes to the SC UI.
|
||
8. The SC UI redirects them back to the XDR URL.
|
||
9. 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 [[webexteams://im?space=b5844a30-2e19-11ee-b0bb-8575ace105f3&message=91faa760-2a78-11ef-8adc-eb6b680c3fe6][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-06-25 Tue 16:36]--[2024-06-25 Tue 22:34] => 5:58
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-09 Tue 16:35]--[2024-07-11 Thu 12:50] => 44:15
|
||
:END:
|
||
[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>
|
||
:LOGBOOK:
|
||
- State "CANCELED" from "TODO" [2024-07-10 Wed 18:22] \\
|
||
Provided another solution
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-12 Fri 15:39]--[2024-07-12 Fri 19:03] => 3:24
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-15 Mon 16:33]--[2024-07-16 Tue 16:35] => 24:02
|
||
:END:
|
||
[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
|
||
|
||
#+begin_src
|
||
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"}}}}}
|
||
#+end_src
|
||
**** 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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-16 Tue 16:35]--[2024-07-16 Tue 21:35] => 5:00
|
||
:END:
|
||
[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
|
||
|
||
- SX
|
||
**** 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
|
||
|
||
1) 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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-17 Wed 18:36]--[2024-07-17 Wed 19:08] => 0:32
|
||
:END:
|
||
[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 [[webexteams://im?space=ff60e0b0-8d3b-11ee-a677-3d6eefa66fd9&message=90e5be70-43b2-11ef-9dfb-5323a38542be][msg]] :work:
|
||
SCHEDULED: <2024-07-17 Wed 10:00>
|
||
[2024-07-17 Wed 09:52]
|
||
**** DONE Answer to Brooke, check webhooks [[webexteams://im?space=47c17620-e148-11ee-bb7f-b544af00ee33&message=16757b30-4399-11ef-81b7-bd7ffdce2735][msg]] :work:
|
||
SCHEDULED: <2024-07-17 Wed 10:00>
|
||
[2024-07-17 Wed 09:58]
|
||
*** 2024-07-18 Thursday
|
||
**** DONE Trust SMA clients [[webexteams://im?space=854d1670-4039-11ef-a843-397a7288f473&message=4542e0a0-44a8-11ef-8fc1-e307e75a73ca][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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-19 Fri 17:59]--[2024-07-20 Sat 01:25] => 7:26
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
:END:
|
||
[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:
|
||
:LOGBOOK:
|
||
CLOCK: [2024-07-23 Tue 16:37]--[2024-07-23 Tue 19:53] => 3:16
|
||
:END:
|
||
[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]
|
||
** 2024-W33
|
||
*** 2024-08-13 Tuesday
|