deft/tracker.org

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

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

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

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


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

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

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

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

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

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

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

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

Private Intel.

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

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

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

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

@Matthieu: do we send a warning email?

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

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

Order of deletion is important.

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

Design doc.

****** Monetization

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

****** Playbook retrieval API

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

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

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

For Mark
 "ao-bootstrap"

For Matt:

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

Used By UI:
 "iroh-registry"

For GE:

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

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

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

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

Discuss Uses cases #1.

***** Notes

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

Notion about when to delete data.

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

***** Actions

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

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

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

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

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

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

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

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

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

***** Notes

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

update problem.

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

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

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

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

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

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

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

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

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

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

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

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

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

New hires:

- @Vidun_Jayakody Automation
- @Geaog-Nokila_Pavlov

@John: upgrade platform, thanks to @Adam

****** QA

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

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

****** Service

@GB People deliver XDR in my absence.

****** Engine

@Eric

****** Integration

@Mark

****** UI Dar

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

****** UI Sabrina

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

****** Documentation @Mary


****** Demos

@Scott_McLeod incident report

@Mike next time.

@Sam_Waggoner


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

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

I can attest that our team intensively uses:

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

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

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

To me it seems we have interrest in contributing back to the open source Clojure community.
Not only it improve the maintenance quality of essential libs to our
architecture but it also helps during hiring.
Now, regarding how much we should give, this probably depend a lot of our
current budget.