yogsototh/deft
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
deft/tracker.org
Yann Esposito (Yogsototh) 136c8c4be4
save
2023-08-09 15:00:50 +02:00

19 KiB
Raw Blame History

2023

2023-W26

2023-06-29 Thursday

CANCELED Investigate invite bug   work

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

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

[2023-06-29 Thu 11:06]

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

Deleted user-id c59db89d-212a-4a0c-92d0-ff1a2c7de25b

2023-W27

2023-07-04 Tuesday

MEETING 1-1 Wanderson   work meeting

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

[2023-07-04 Tue 16:04]

Agenda (to discuss about)

  • Provisioning

    • PIAM status
    • Orbital/Single SE status
  • RBAC status
  • offsite
Notes
Actions
  • create a backlog of technical work to do

2023-07-05 Wednesday

DONE Cleanup all "TO DELETE" entities   work

SCHEDULED: <2023-07-28 Fri 11:00> [2023-07-05 Wed 19:51]

2023-07-06 Thursday

CANCELED Remove ability to create new Org   work

SCHEDULED: <2023-07-06 Thu>

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

[2023-07-06 Thu 16:19]

2023-W28

2023-07-11 Tuesday

DONE IROH Sync   work

SCHEDULED: <2023-07-11 Tue 17:00> [2023-07-11 Tue 10:49]

DONE IROH-Auth weekly   work

SCHEDULED: <2023-07-11 Tue 16:35> [2023-07-11 Tue 10:49]

DONE 1-1 Wanderson   work

SCHEDULED: <2023-07-11 Tue 16:05> [2023-07-11 Tue 10:49]

DONE 1-1 Olivier   work

SCHEDULED: <2023-07-11 Tue 15:35> [2023-07-11 Tue 10:48]

DONE Lead Weekly   work

SCHEDULED: <2023-07-11 Tue 15:00> [2023-07-11 Tue 10:48]

DONE Provide doc to Guy Mackenzy   work

SCHEDULED: <2023-07-11 Tue 11:30> [2023-07-11 Tue 10:13]

DONE Create Entitlement Presentation   work

SCHEDULED: <2023-07-11 Tue 10:30> DEADLINE: <2023-07-12 Wed 15:00> [2023-07-11 Tue 10:12]

2023-07-12 Wednesday

DONE Make enterprise_id mandatory field for PIAM endpoints   work

DEADLINE: <2023-07-12 Wed 18:00> SCHEDULED: <2023-07-12 Wed> [2023-07-12 Wed 17:14]

MEETING Monetization first meeting   work meeting

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

[2023-07-12 Wed 16:07]

Notes

tier

2023-07-13 Thursday

DONE Review [Olivier PR] Check IROH node start in test   work

SCHEDULED: <2023-07-13 Thu> [2023-07-13 Thu 12:11]

DONE Add enterprise_id to many orgs list here   work

SCHEDULED: <2023-07-13 Thu 14:30> [2023-07-13 Thu 12:06]

DONE Provide Q1 technical items   work

DEADLINE: <2023-07-13 Thu 16:00> SCHEDULED: <2023-07-13 Thu> [2023-07-13 Thu 11:57]

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

    Main concrete ideas:

    • improve DBFixture service,
    • try to regroup tests details into the same test-file so a reader will not be forced to dig between different files to understand what is going on.
  2. Developer Targeted documentation. Currently the descriptions of the APIs in Swagger UI lack of precision. We could greatly improve the understanding of developer facing it by adding examples, and cleaner content in swagger UI.

  3. IROH-Auth isolation A potential effort to think how we could improve the reliability and security of IROH by isolating IROH-Auth from the rest of IROH. This question was raised multiple times, but we do not have yet a definitive answer about what would be an ideal solution.

    • potentially, this could mean improving building time, and development time by decoupling Auth from the more feature-oriented work.
    • potentially, open new unexpected integration solution by having iroh-auth-only specific nodes, and perhaps even, removing the IROH-Auth service from other nodes entirely
    • Seems like a natural "next-step" related to the work related to specific nodes.

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

  1. Token Exchange Service We need to produce a service that could provide the ability for an entity to get access to other tokens. To make this safe and useful, we need to go beyond the Token Exchange RFC and consider how to build an access rule system, logging, and keep track of the token chain. So first take the time to have a clear understanding of the feature needed, search and find a technical solution, and design the work to be done. We have a current working first example with the Account Switching. We should extend this to improve Impersonation (for TAC and some Devs), future work with PIAM, and open the door to other integration mechanisms.
DONE Sustaining items for Q1   work

SCHEDULED: <2023-07-13 Thu 17:00> [2023-07-13 Thu 11:56]

2023-W29

2023-07-17 Monday

MEETING Deep dive XDR Monetization   work meeting

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

[2023-07-17 Mon 16:31]

Agenda (to discuss about)
Notes
  • hide 3rd party modules to "Essentials" users
Actions
  • Restrict via the API too
DONE Add scopes to Scott Burnettes orgs/clients?   work

SCHEDULED: <2023-07-17 Mon 11:00> [2023-07-17 Mon 08:58]

2023-07-19 Wednesday

MEETING API Design Meeting   work meeting

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

[2023-07-19 Wed 18:47]

Agenda (to discuss about)
Notes
Data Retention

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

Private Intel.

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

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

Deleting all data from an Org

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

@Matthieu: do we send a warning email?

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

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

Order of deletion is important.

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

Design doc.

Monetization

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

Playbook retrieval API

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

Actions
DONE API Design Meeting   work

SCHEDULED: <2023-07-19 Wed 18:30> [2023-07-19 Wed 14:36]

2023-W30

2023-07-25 Tuesday

DONE Retrieve the list of entities from IROH Auth   work

SCHEDULED: <2023-07-25 Tue> [2023-07-25 Tue 17:38]

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

For Mark
 "ao-bootstrap"

For Matt:

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

Used By UI:
 "iroh-registry"

For GE:

 "ctia-investigate-talos-hunt"
 "enrichment-status"
 "feedback"
 "incident-summary"
 "iroh-async-sessions"
 "private-intel-cache"
 "risk-score"
 "threat-hunt-status"
DONE Ask Paul Cichonski about the quantity values   work

SCHEDULED: <2023-07-25 Tue 19:00> See data retention, should be 90, 180, 365. What would be the value, how should I compute?

SCHEDULED: <2023-07-25 Tue> [2023-07-25 Tue 17:36]

MEETING XDR Monetization: XDR data retention   work meeting

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

[2023-07-25 Tue 16:31]

Agenda (to discuss about)

Discuss Uses cases #1.

Notes

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

Notion about when to delete data.

  • Create or update for device.
  • Create for incident, sightings, relationships.
  • Comment on Incident recent, can we delete the incident?
Actions
Ask @Paul about the add-on quantity value for data retention

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

MEETING 1-1 Wanderson   work meeting

[2023-07-25 Tue 16:04]

Agenda (to discuss about)
Things to handle during my vacations.

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

  1. P1: fix XDR bugs, quick improvements
  2. Add insights scope for DI (take care of updating the client, perhaps fix the issue with non existing root scope. Could potentially be a real improvement).
  3. Add event on Entitlement change. Optionally configure a webhook for this event, depend on the need. Check with Matt and Guy.

  4. Perhaps:

    • Disable Org creation if SX EOL is officially announced.
    • [NO] improve provisioning script. Check if module exist before invoking /onboard
    • work related to short tokens (expose a token-exchange route not the RFC one, a simpler to use one).

  5. Think about exposed data structure to make every type of org explicit and centralize the business logic to help the UI.

    • Retrieve a full list of Org case:

      • created via PIAM or not
      • XDR-enabled?
      • SX-enabled?
      • Entitlements/no-Entitlement

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

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

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

Notes
Work on the Events for the Entitlements

update problem.

Actions
MEETING 1-1 Olivier   work meeting

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

[2023-07-25 Tue 15:05]

Agenda (to discuss about)
Things to handle during my vacations.
  1. P1: fix XDR bugs, quick improvements
  2. Add insights scope for DI (take care of updating the client, perhaps fix the issue with non existing root scope. Could potentially be a real improvement).
  3. Add event on Entitlement change. Optionally configure a webhook for this event, depend on the need. Check with Matt and Guy.

  4. Perhaps:

    • Disable Org creation if SX EOL is officially announced.
    • improve provisioning script. Check if module exist before invoking /onboard
    • work related to short tokens (expose a token-exchange route not the RFC one, a simpler to use one).

  5. Think about exposed data structure to make every type of org explicit and centralize the business logic to help the UI.

    • Retrieve a full list of Org case:

      • created via PIAM or not
      • XDR-enabled?
      • SX-enabled?
      • Entitlements/no-Entitlement

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

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

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

Notes
Actions
DONE XDR Data Retention Policy Implementation Discussion   work

SCHEDULED: <2023-07-25 Tue 16:30> [2023-07-25 Tue 11:07]

DONE 1-1 Wanderson   work

SCHEDULED: <2023-07-25 Tue 16:05> [2023-07-25 Tue 11:06]

DONE 1-1 Olivier   work

SCHEDULED: <2023-07-25 Tue 15:35> [2023-07-25 Tue 11:00]

2023-07-27 Thursday

DONE Message Equipe   work

SCHEDULED: <2023-07-26 Wed 14:00> [2023-07-27 Thu 11:45]

  • P1. (prob. 30%) XDR Bug fixes
  • P1. (prob. 20%) Scott Burnette issue with the Provisioning API / OAuth2 clients
  • P2. (prob. 10%) Help Jyoti with xdr-provisioning script
  • P2. FY24Q1 Monetization: Prepare the PR for Disable Org Creation.
  • P3. FY24Q1 Monetization: Entitlements Events; Check with Matthieu before configuring a webhook for Automation (previously Orchestration, previously SXO, previsouly AO) as it might not be necessary.

  • P4. Dashboard https://github.com/orgs/advthreat/projects/7/views/9

    • [RBAC] insights scope + sync with DI team (Roman Eremin)
    • (prob. 10%) [RBAC] if asked to prevent non-admin to create clients, add admin to the scopes in the routes of the IROH Auth client web service.
    • Config Simplification + Presentation for the team
  • P4. Universal Provisioning Flow (PIAM want to rename themselve "Security Cloud").

  • P4. Designs

    • New Org concepts that need to be exposed: List the concepts we want to be exposed for each org.

      • :xdr-enabled?/sx-enable? perhaps a single :enabled-products [:xdr :sx].
      • piam-managed? etc…
      • Notion of Product (XDR, SX, but also, visibility, Orbital, SE). Effects on configuration, init of nodes, etc…

    • Token Exchange (not the RFC). We want to:

      • Give the ability for someone with a JWT to generate another one with some restrictions and complete tracking. Restrictions by default:

        • do not extend the :exp
        • do not change user
        • do not change org

        Tracking:

        • should be an act claim that could be recursive and we should take great care of not making that grow. It is ok not to have act in some cases like:

          • Org switching
          • format switching

          because the real owner is always the same. It is not ok to forget act if there is an impersonation involved. Typically during provisioning, real impersonation, etc…

      • Main difficulty; what is the correct data structure to represent rules of allowed JWT exchanges.

  • Take care of asks that could leak internal abstractions:

    • do not return the full list of allowed modules, IROH-Int will take care of the filtering business rule.
    • use scopes, not role to filter for permissions
  • Sync with Matt with everything related to modules for Monetization. Not just directly with Guy, Matt needs to know.
CANCELED XDR-flag 1906   work

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

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

[2023-07-27 Thu 11:30]

2023-07-28 Friday

MEETING Monthly Engineering   work meeting

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

[2023-07-28 Fri 18:01]

Agenda (to discuss about)
Notes
Operation

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

New hires:

  • @Vidun_Jayakody Automation
  • @Geaog-Nokila_Pavlov

@John: upgrade platform, thanks to @Adam

QA

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

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

Service

@GB People deliver XDR in my absence.

Engine

@Eric

Integration

@Mark

UI Dar

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

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

@Scott_McLeod incident report

@Mike next time.

@Sam_Waggoner

Actions
DONE Monthly Engineering Meeting   work

SCHEDULED: <2023-07-28 Fri 18:00> [2023-07-28 Fri 11:34]

DONE Answer Namrata   work

SCHEDULED: <2023-07-28 Fri> [2023-07-28 Fri 10:20]

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

I can attest that our team intensively uses:

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

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

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

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