https://www.notion.so/cybnity/463-c6a6af4c73b3487ca34446cefe776ca9

https://www.notion.so/cybnity/469-1d7f624f7da64ad7bf816d5473961025

https://www.notion.so/cybnity/445-ff00a4d306b94c71a420c60ef1f92b83

https://www.notion.so/cybnity/473-9cd88fb418264a2eb244afbdea3b2d85

https://www.notion.so/cybnity/304-3cb0d71684de4bfa9e275ebf6163c8f0

https://www.notion.so/cybnity/460-8cb76bbc0b3a4ecb869546c7d1d4e70c

https://www.notion.so/cybnity/272-bb4b02d3f3d24b3c96aa04559357624d

https://www.notion.so/cybnity/461-9d5ed9bb12524abb9c8a2ad6c5902cf5

REQ_SEC_10 : Control the flow of information and access across network boundaries in computing and communications infrastructures, and to enforce the proper separation of user groups, a suite of access control devices and accompanying access control policies are used

Rationale: Determine the following for communications across network boundaries:
• What external interfaces are required
• Whether information is pushed or pulled
• What ports, protocols, and network services are required
• What requirements exist for system information exchanges; for example, trust relationships, database replication services, and domain name resolution processes.

https://www.notion.so/cybnity/448-325f77d3daad49ef89ad8d529cd02a57

https://www.notion.so/cybnity/446-db4c69bed1304685ab50258b5641c791

REQ_MAIN_3: Internal queues and topics are only used per application domain and/or feature perimeter without visibility/access by other domains
Internal queues and topics are only used per application domain and/or feature perimeter without visibility/access by other domains
implementation: Each feature and/or application module requiring internal uses of channels (e.g Kafka topics implementing a feature’s process; UI capability’s module implementing capabilities command chain) is only authorized (e.g dedicated permission scheme) to use them.
The elements of infrastructure supporting each bounded context (application domain) shall implement a commands bus (that is imperative as “make this action”) and a event messages bus (notifications coming from the domain aggregated objects like “order confirmed”) that are independent.

Tech: redis, kafka

https://www.notion.so/cybnity/467-9ecc900642964dcb9ffd02d4ddad3436

https://www.notion.so/cybnity/317-3d595dc378864e75885d0a2974449a37

https://www.notion.so/cybnity/451-d5cfa0ecd1dd44a6b412839a5c80005a

REQ_SCA_2: Each applicative module (e.g an application grouping several features regarding a bounded context; an application grouping several capabilities regarding a capabiy domain) own a dedicated group of consumers required by its embedded functions

impl: All the consumers (e.g capability Verticle using dedicated Redis channels) implemented by a UI Capability domain module (e.g capabilities module deployable as independent component on a JVM process) are categorized as one group of consumers in front of the messaging queues (e.g Redis topics) and consume one partition dedicated to each capability. Same approach is implemented for all the consumers of a Feature domain module which are categorized into one group for consumption of messaging queues (e.g Kafka topics) for consume one partition per feature use case.

tech:java: redis: kafka

feature: https://www.notion.so/cybnity/318-971ac0548f074d44937c85d749b27421

security control: https://www.notion.so/cybnity/IA-8-4-Use-of-defined-profiles-edd0d23d78504ef7a48acce0d4ae1181?pvs=4

https://www.notion.so/cybnity/471-a2f7516030c34763ba3e654dbb73834d

HAProxy APIs Gateway

• see if change of keycloak's health url could be interesting to be used as written at : https://www.keycloak.org/server/health
• installation of SSL https://www.haproxy.com/blog/haproxy-ssl-termination/

Node.JS

• implementation of foundation web-reactive-frontend integration with keycloak
  • plug of keycloak over keycloak configuration file (adapter of access-control-sso-adapter-impl) auto-packaged during the helm configuration of the nodejs web app
  • nodejs server-side automatically discover dynamically at runtime the keycloak.json file according to the webapp module's layer (allow to adapter to use the good keycloak client profile)
  • SSL usage between frontend and keycloak
• FRONTEND FEATURES : capabilities developed as default basic user interfaces flow
  • user create account and credentials on existing realms (with/without async validation step by tenant id/realms owner) via domain process of ac-control-service
    • user can access from existing account to organization realm only when ciso accepted his registration (or rejected it) with MFA
  • new user without organization create account AND organization (tenant ID) with automatic tenantId creation (realms in keycloak)
    • autocreate roles, permissions in realms (application modules, default roles according to the default framework for organization)
    • organization's root user considered can access to front with profil access to admin console only to manage manually internal users (no access to technical configurations), else could by replaced by future profile UI in reactjs
    • any valid and authorized user can see his profile (e.g sso page with attributes values; future replacement by frontend reactjs views)

Validate behaviors

• manual test of tester account regarding deployed nodejs front app

• unit tests campaign of integration (bdd test) over http allowing to deploy in staging environment with check of integrated frontend app, keycloak/postgresql

  • creation of test account over http (keycloak standard page) reusable by test campaign
  • authentication test with tester account and received tokens read/check (embedded mandatory information like tenant-user, role(s), access/user/refresh token)
  • refresh token test allowing continuity of web-frontend usage over base expiration period
  • logout test validating session closed and token removed

• Keycloak adapter for NodeJS doc

JAVA

• implementation of ac-adapter-impl library including the dynamic read of keycloak.json files (connector as layer module: use of good keycloak client adapter according to the server app layer that is running and using the adapter) embedded into any server module using the library

• ADMINISTRATION FEATURES

  • configurationmanager (domain layer) via keycloak admin rest api via keycloak-admin-client java library
    • auto-discovery of the realms to connect according to the deployed K8s cluster (application context read by the instantiated ac-adapter-api)
    • create default client adapters, permissions required by cybnity modules for run
    • autostart when ac-service started (to init keycloak and open accesses to other adapters)
    • replace manual procedure doc by the auto-procedure realized by ac-service module
  • created sub-project dedicated to ac-adapter-impl/keycloak-adapter-impl as default implementation (allowing to implement futures additional UIAM solutions compatibility) and sub-projects of ac-translator/keycloak-translator dependency
  • adapter fonctions allowing creation of realms (organization=tenantid) by a new user of frontend with/without existent realm

• packaging and unit test validating the dynamic behavior of the adapter api and impl libraries reusable by any java component (ui layer components, rts components...) requiring to validate (sso token check) or to read user information (role, permission, user description) from application and domain layers area

• Keycloak adapter for Java doc

• Keycloak multi-tenancy doc

• Use OpenID connect protocol : OIDC is an extension of OAuth2, with data structures in JSON format (JWT), and simple HTTPS flows for transport. User identity data (“claims”) are issued in a JSON web token (ID Token). The claims will include a persistent identifier and user data defined by the requested scopes. Conventionally, this token is digitally signed, and may also be encrypted where required.

• With Vert.x extension (backend api)

• implementation of operational state check regarding the sso server (via client dedicated to module type), including the dynamic packaging of keycloak.json apdater configuration (helm), the link to ac-adapter libraries (api, impl) from a ui layer module or from a application layer module

• unit tests campaign of integration regarding the sso check use case tests required by the capability/domain/applicative component reusing the ac-adapter facade during application processes (e.g validation of endpoint request during a command entry received over the uis space)

  • OIDC / OAuth2 doc
  • Authenticity signature of content sent (not encrypted) with JWT token https://vertx.io/docs/vertx-auth-jwt/java/
  • Auth common authentication & authorization
  • See potential of using Multi-factor authent with google https://vertx.io/docs/vertx-auth-otp/java/ option

• Authentication : see Java JAAS and Jaas tutorial documentations

• Keycloak java client documentation

tech: keycloak

https://www.notion.so/cybnity/40-5eefc1a4251147fd8b6d19aad353eaa8

Search cybersecurity risks that are assessed (e.g in progress, finalized and consistents, reviewed) with consideration of threats, vulnerabilities, likelihoods and impacts analysis performed given a realistic visibility for their management (e.g identification of control measures to implement) regarding existent assets, and/or future (e.g projects in progress). This scope consider the processes initialized and/or finalized of risks identication, assessment, analysis.

REQ_FCT_53: https://www.notion.so/cybnity/Find-assessed-risks-97090742f19e475d83c4a3b9cadbb5d4?pvs=4

https://www.notion.so/cybnity/447-d01de61153714443ae8fc294300b773a

REQ_MAIN4: https://www.notion.so/cybnity/REQ_MAIN_4-8513483dd519412087185e24134453bc?pvs=4
As Clusterizable independent unit per technical or functional concern:

• One Vert.x Verticle is deployable per JVM and per CPU core for each technical concern (e.g Bridge for routing a an API http/rest or event bus API exposed to Internet) according to the exposed protocol, and with securized isolation (e.g dedicated settings and sla)
• Each technical service (e.g Vert.x bridge Verticle for protocol routing as backend gateway) or functional service (e.g UI capability entry point exposing a capabilities domain’s api; one feature Verticle per JVM per CPU core on computation units) is packaged/deployable as an independent applicative component on an independent JVM and CPU core (e.g allowing horizontal scalability).

Components: vertx server, reactjs, docker, K8s cluster

TODO

• create helm github repository supporting the helm chart source codes

  • configure repositoy, workflows...
  • branch rules, roles, permission

• develop multi-environments support from charts/sub-charts with migration of existing sh scripts (Node areas)

  • see help docs
    • https://github.com/marketplace/actions/helm-deploy
    • https://medium.com/swlh/deploying-to-kubernetes-with-helm-and-github-actions-14825e6df1f2
    • https://helm.sh/docs/howto/chart_releaser_action/

• develop workflow CI (based on existing helm chart for one envt without specific cluster configuration) that deploy a version into a github environnement (not self-hosted used with public repo; minikube based) allowing to test components during a common development, or during a tests campaign execution of Test stage

• Infrastructure services area

  • Defense platform cluster as Kubernetes Local Dev cluster (deployable as mono instance cluster of modules into a Minikube stack)

    • Provisioning management of networking, load balancer, database, users, permissions... and Kubernetes cluster (orchestration management) via Helm (Local cluster for dev on workstation's Minikube; "Staging & QA" cluster for test on OVHCloud)

    • Docker image & resources configuration management via Helm source codes (Configuration of systems' resources, logs, forwarding ports of Docker image, Kubernetes objects (e.g baseline/live replica cluster allowing pre-prod dress rehearsal, canary cluster for code changed and rollout with automated recovery, production/live cluster) supporting environments/infrastructures deployment AT APPLICATION LEVEL

    • Control Plane

      • API server (including https public root certificates) and Controller Manager > Cloud provider API link > cluster external ip address
      • Volumes configuration as stateful set (and \deployment\local-deployment.yaml file definition)

    • User interfaces area as Kubernetes Node (including external ip address)

      • Kube-Proxy (including inside/outside cluster network session rules)

    • Domains I/O area Node (including external ip address)

      • Kube-Proxy (including inside/outside cluster network session rules)

    • Domains area Node (including external ip address)

      • Kube-Proxy (including inside/outside cluster network session rules)

    • Infrastructure Services Area Node (including external ip address)

      • Kube-Proxy (including inside/outside cluster network session rules)
  • Infrastructure services zone firewall
  • Domains zone firewall as Calico enforcer, kubernetes network policy

• Foundation common modules

  • UI area
    • Internet DMZ firewall as calico enforcer, kubernetes network policy
    • UIS brokers registry system as zookeeper cluster (helm project)
      • Kubernetes control plan (\service\uis-broker-service.yaml file definition)
      • Kubernetes control plan (\service\uis-broker-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
    • Users Interactions Space - UIS system as Redis cluster (helm project)
      • Kubernetes control plan (\service\uis-service.yaml file definition)
      • Kubernetes control plan (\service\uis-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
    • Reactive messaging gateway system as vert.x backend server (helm project)
      • Kubernetes control plan (\service\backend-service.yaml file definition)
      • Kubernetes control plan (\service\backend-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
    • Web reactive frontend system as ReactJS and Node.js server (helm project)
      • Kubernetes control plan (\service\frontend-service.yaml file definition)
      • Kubernetes control plan (\service\frontend-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
  • Domains I/O area
    • Domains API zone firewall as calico enforcer, kubernetes network policy
    • DIS brokers registry as Zookeeper cluster (helm project)
      • Kubernetes control plan (\service\dis-broker-service.yaml file definition)
      • Kubernetes control plan (\service\dis-broker-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
    • Domains Interactions Space as Kafka cluster (helm project)
      • Kubernetes control plan (\service\dis-service.yaml file definition)
      • Kubernetes control plan (\service\dis-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
  • Domains area

• Access control domain deployable modules

  • Infrastructure services area
  • UI area
    • Keycloack SSO backoffice & database server as PostgreSQL server, Keycloack backoffice server supporting the API delegation for teams members permissions, accounts etc.. managed by a final user (e.g CISO) : Helm project
      • Keycloack SSO service (defined in infrastructure area over Kubernetes Node) and in UI layer (only login view module) as delegation login screen from CYBNITY frontend
      • delegation adapter usable from access control domain gateway to check sso from many areas (ui for sso login, doamin for sso token check)
    • access control ui - e.g security team member permissions, ui capabilities server
      • Kubernetes control plan (\service\access-control-domain-ui-service.yaml file definition)
      • Kubernetes control plan (\service\access-control-domain-ui-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
  • Domains I/O area
    • access control domain gateway system as Vert.x server
      • Kubernetes control plan (\service\access-control-domain-gw-service.yaml file definition)
      • Kubernetes control plan (\service\access-control-domain-gateway-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)
  • Domains area
    • Migrate Postgresql module from ui layer into the infrastructure layer (including access to keycloack back office) + open network connection between SSO service to node
    • Access control process module system as Flink server (rts process module, apache flink, apache flink cep, kafka client, mongodb client, zookeeper client)
      • Flink server (Docker image) including port as dedicated Docker image template
      • Kubernetes control plan (\service\access-control-domain-process-service.yaml file definition)
      • Kubernetes control plan (\service\access-control-domain-process-systems-deployment.yaml file definition)
      • Volumes configuration as stateful set linking to systems-deployment file
      • Kubernetes POD (see Assembly strategy )
      • Kubernetes Service (including POD VPN address, POD unique IP address)

• Update the Implementation View documentation regarding:

  • the packaging models (docker and kubernetes components level)
  • the configuration-management (helm resources and settings level per specific docker image)
  • the system IaC (terraform IaC and systems level)
  • update the containerized system documentation about systems platform
  • the runtime dependencies overview between deployable components and macro-links between them (e.g CYBNITY system components level between park of CYBNITY Docker Images executed into Kubernetes services activated)
  • the map of logical stream ports (e.g internal / external) helping to understand the path of events/interactions flow between the Kubernetes Nodes (supposed deployable as application Space Based Architecture; with visibility on location where security policy about permissions/flow opened are controlling the runtime perimeters)

• tech: kubernetes, docker, terraform, helm

https://www.notion.so/cybnity/449-98c2ab42abfd429cbaefaf6922b49a51

https://www.notion.so/cybnity/468-c3a2266259f94deca9c364abb11e8b2f

https://www.notion.so/cybnity/459-8f5cf3c8b523425b95249dee2f10ffef

https://www.notion.so/cybnity/443-22b4271c18fd4b86a2bcad613529bf0e

https://www.notion.so/cybnity/464-20e408a03c48464cbece268c633887d1

https://www.notion.so/cybnity/465-817bc6f89ff442cba1788924ff3172c8

https://www.notion.so/cybnity/321-358d1d8dcd2442848cb900783d654822

https://www.notion.so/cybnity/379-07c321bd117e490aa5e1832c3746546b

https://www.notion.so/cybnity/472-102e61be3cf443f08997ab4286d0aa0f

REQ_SEC_21: The users, their devices, the third-parties systems or any solution using the applications are uniquely identified (e.g based on logical information like name, contact, a digital object; and/or based on physical information like owned object, device id, biometrics) during their interactions

An identity may represent an actual user or a process with its own identity, e.g., a program making a remote access. Unique identities are a required element in order to be able to:
• Maintain accountability and traceability of a user or process
• Assign specific rights to an individual user or process
• Provide for non-repudiation
• Enforce access control decisions
• Establish the identity of a peer in a secure communications path
• Prevent unauthorized users from masquerading as an authorized user.

help: identity/account implementation in access-control domain shall be inspired by https://freeduse.atlassian.net/wiki/spaces/IR/pages/6225984/BAI03.01+Entities+Design+Specification for mapping/integration and encapsulation of Keycloack api

• url and ports documentation about the local-dev environment helping to enhance the development context easily when new pod/service are included into the dev cluster

HAProxy APIs Gateway

• packaged module for minikube deployment as apis gateway
• plug with keycloak routes allowing oauth2 authentication for web-reactive-frontend application
• plug and usage of Ingress Controller by HAProxy service regarding url path-based routing (in place of services/ports mapping)

Node.JS

• Implementation of foundation web-reactive-frontend integration with keycloak
  • base html/react js page as default html single page
    • requiring secure access
  • Configuration of the reverse proxy for routing rule from external 80 to frontend + sameSite cookie modification in header (allowing browser with tracking protection)
    JAVA
• ADMINISTRATION FEATURES
  • created sub-project dedicated to ac-adapter-impl/keycloak-adapter-impl as default implementation (allowing to

https://www.notion.so/cybnity/444-39c830770a634e6eb7149a8826549146

REQ_MAIN_1 : https://www.notion.so/cybnity/REQ_MAIN_1-3459109933554db8a4a36623823e8b0a

• description: One deployable module is build/delivered per applicative domain (bounded context) including several embedded features

• implementation: Each application domain is packaged as a Vert.x application (ready for independent deployment/runtime on one JVM process, and allowing horizontal scalability in several JVM instances) exposing the application domain API. The assigned features perimeter (e.g categorized security features per application) is embedded (e.g deployed Verticle in same JVM memory) in the packaged application which can be integrated via Vert.x local event bus (e.g sync calls between application’s features Verticles) and/or via Kafka brokers (e.g async calls with local or external other features/domains API).

• external help documentations:

  • helm+docker: https://ignaciocicero.medium.com/docker-kubernetes-helm-a-comprehensive-step-by-step-using-java-df83f6780d80
  • dockerfile+minikube: https://suedbroecker.net/2020/01/23/how-to-develop-a-customized-dockerfile-using-minikube/
  • docker images + helm: https://www.ibm.com/docs/en/siffs/2.0.3?topic=repository-deploying-docker-images-through-helm

• Infrastructure services area

  • Standard basic Docker Linux image with Java runtime (Eclipse Temurin JDK/JRE) reusable by domain implementation module (e.g helm configuration at application level for common image parameters, policies...)

• Foundation common modules

  • UI area

    • Users Interactions Space - UIS system as Redis cluster
      • Redis server (Docker image via Helm) including port as dedicated Docker image template
    • Reactive messaging gateway system as vert.x backend server
      • Vert.x web server (Java component)
      • Reactive backend server (Docker image) including port as dedicated Docker image template
    • Web reactive frontend system as ReactJS and Node.js server
      • Node.js server (NodeJS built ReactJS webapp)
      • Web reactive frontend server (Docker image) including port as dedicated Docker image template

  • Domains area

    • DIS brokers registry as Zookeeper/Kafka cluster
      • zookeeper 3.7 server as cybnity template (Docker image including port as dedicated Docker image template) named services-registry
      • services-registry based image built in infrastructures/registry/system for Kafka brokers cluster as dedicated services-registry-container)
    • Domains Interactions Space as Kafka cluster
      • Kafka server (Docker image) including port as dedicated Docker image template
      • kafka cluster system managed as systems/charts of IaC infrastructure project including zookeeper/kafka integrated clusters

  • Domains I/O area

    • access control domain gateway system as Vert.x server
      • Vert.x server (Docker image) including port as dedicated Docker image template

• Update the Implementation View documentation regarding:

  • the modular systems projects, structure of modules projects (https://github.com/cybnity/foundation/blob/feature-61/implementations-line/systems/README.md)
  • put REQ_MAIN_1 annotations into implementation source codes (helm provisionning file of image, pom.xml generating docker module)
  • the architecture of systems
  • the system IaC (terraform IaC and systems level)

• tech: docker, helm

https://www.notion.so/cybnity/49-da07e4db380940dc83434b411d09a3b9

https://www.notion.so/cybnity/242-fa72c1415bbd48388512caf82447a7c9

https://www.notion.so/cybnity/27-0fe8e96760864d25b791d89ab658c610

https://www.notion.so/cybnity/311-210680c3921e4c2da0b9472f0e620597

IA-5(1):
For password-based authentication: 

• Maintain a list of commonly-used, expected, or compromised passwords and update the list [Assignment: hosting organization-defined frequency] and when organizational passwords are suspected to have been compromised directly or indirectly; 
• Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a); 
• Transmit passwords only over cryptographically-protected channels; 
• Store passwords using an approved salted key derivation function, preferably using a keyed hash; 
• Require immediate selection of a new password upon account recovery; 
• Allow user selection of long passwords and passphrases, including spaces and all printable characters; 
• Employ automated tools to assist the user in selecting strong password authenticators; and 
• Enforce the following composition and complexity rules: [Assignment: hosting organization-defined composition and complexity rules].

https://www.notion.so/cybnity/466-b4cede26f4a04e59b35f42d26badb4d7

https://www.notion.so/cybnity/455-1c9de87b47c14819bc8d8ee0ad15e14a

https://www.notion.so/cybnity/450-2866c1bf72ce4da7b48f962a2444c6c6

https://www.notion.so/cybnity/457-e2654fa674634c3d9b2902baa0f78ddd

https://www.notion.so/cybnity/43-a03755cf1ade49ba9033f69c3e9eaf75

https://www.notion.so/cybnity/462-537f5ec0acf14fc68140cee037a299e5

https://www.notion.so/cybnity/44-9aab846c1d1a43f08a86d70966fae422

https://www.notion.so/cybnity/453-121772cd0f5f468d81bc5fb5cb4335f7

https://www.notion.so/cybnity/48-9c9718d9d4f24b58a95d5285c7ba2993

https://www.notion.so/cybnity/315-6129d082a3cd47aea718dd9fa5044ef1

https://www.notion.so/cybnity/452-0972e7891f86475dbcf927dce265fd61

https://www.notion.so/cybnity/454-452f0645dd524fd1b57d07a68a368a3d

REQ_SEC_3 : TenantId support is implemented to allow notification of several users attached to a same company and/or solution infrastructure dedicated to a company
The exchanges to multiple connected users of a same company (e.g security team authorized/connected on a dedicated solution instance receiving a transversal notification event on eventbus/tenantId/all/* or via eventbus/all/*) are possible with total confidentiality (without possible visibility for other companies and/or infrastructures when solution is deployed on a Cloud/SaaS strategy).

ech: Vert.x Web; sockJS event bus bridge

upgrade fact repository and store persistence interface contract (immutable project) to support tenant id segregation according to the page 401 DDD book

https://www.notion.so/cybnity/316-14f5e81c710047d98df5ed55811c4c57

https://www.notion.so/cybnity/456-0d1dbf6461d34d0283b17273ae804375

https://www.notion.so/cybnity/378-5c56775d138d49cbaf0a8e0848aefc85

https://www.notion.so/cybnity/366-56273d6eb27148e9b51f2fa63fe7d163

https://www.notion.so/cybnity/458-498cc0a780544209b8d08376aedd6eae

https://www.notion.so/cybnity/470-d6ee577002c144fabef39fa4dabb8470