...

At a high level there are 4 broad categories in regards to Security Event Management (Or is this a Security Event Lifecycle?)

**There probably a body of work we can reference that spells this out.  ACTION: Literature review for that

• Generation
  • Within ONAP both containers and infrastructure generate raw data that have security concerns.
    • Containers (xNFs)
      • There currently a SECCOM proposal that specify what type of data should be logged where it should be logged to.  In this case STDOUT
        • TODO: List STDOUT REQ NUMBER HERE
      • That is documented here: https://wiki.onap.org/download/attachments/100895473/2021-02-22_LoggingRequirementEvents_v9.pptx?version=1&modificationDate=1619018452000&api=v2
    • Infrastructure (Docker and K8S)
      • There are a set of logs that both Docker and K8S generate that relate to security monitoring.
      •  That is documented here: https://wiki.onap.org/download/attachments/103419713/Logging%20-%20ATTACK%20to%20SECCOM_v3.pptx?version=1&modificationDate=1622560207000&api=v2
• Collection
• Analysis
• Action

QUESTIONS

1. In terms of security logging, should we handle ONAP components differently than Service Components hosted in ONAP?
2. How do we handle the use case where ONAP is being used to deploy and manage a security infrastructure?
3. What about security events in regards to the closed loop model?  Adversarial AI will be an issue that will need security monitoring in the near future.  Does this mean that orchestration / life cycle data from the DCAE needs to ingested by a SIEM?

References

1. https://www.enisa.europa.eu/publications/security-in-5g-specifications
2. https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-for-5g-networks

...