You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 23 Next »

This is a working document.

The below matrix is a representation of the log management categories (lifecycle) in relation to the two categories of run-time logs (logs of ONAP events, logs of events from services orchestrated by ONAP).

Team Members

  • Amy Zwarico
  • Bob Heinemann
  • Muddasar Ahmed
  • Fabian Rouzaut
  • PUT YOUR NAME HERE

Key

X: Indicates what is in-scope for ONAP

P: Partially in-scope (group consensus is mixed).


Infrastructure: This is physical, virtual and container components.

Phase12

ONAPService (xNF, xApps)
LifecycleApplicationInfrastructureApplicationInfrastructure
GenerationXX

CollectionXX

Monitoring



Alerting



ResponsePPXX

Phase 1 will focus on logs of ONAP events.

Phase 2 will focus on logs of events from services orchestrated by ONAP

Actions

  • Amy: List of proposed events that should be collected from ONAP and Metadata
  • Muddasar: Determine if there is a standard terminology regarding logging architecture terms.  Eg., Are the categories in the above table industry accepted?

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

  • Fabian: Initial investigation of ONAP responding to security events.

Notes

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

Generation

Proposed Security Event Generation Requirements

[CON-LOG-REQ-1] The container and container application MUST log successful and unsuccessful authentication attempts, e.g., authentication associated with a transaction, authentication to create a session, authentication to assume elevated privilege. [Reference: R-54520]

[CON-LOG-REQ-2] The container and container application MUST log logoffs. [Reference: R-55478]

[CON-LOG-REQ-3] The container and container application MUST log starting and stopping of security logging. [Reference: R-13344]

[CON-LOG-REQ-4] The container and container application MUST log success and unsuccessful creation, removal, or change to the inherent privilege level of users. [Reference: R-07617]

[CON-LOG-REQ-5] The container and container application MUST log connections to the network listeners of the container. [Reference: R-94525]

[CON-LOG-REQ-6] The container and container application MUST log the addition and deletion of files in the container.

Proposed Required Metadata for Security Events

[CON-LOG-REQ-7] The container and container application MUST log the field “date/time” in the security audit logs. [Reference: R-97445]

[CON-LOG-REQ-8] The container and container application MUST log the field “protocol” in the security audit logs. [Reference: R-25547]

[CON-LOG-REQ-9] The container and container application MUST log the field “service or program used for access” in the security audit logs. [Reference: R-06413]

[CON-LOG-REQ-10] The container and container application MUST log the field “success/failure” in the security audit logs. [Reference: R-15325]

[CON-LOG-REQ-11] The container and container application MUST log the field “Login ID” in the security audit logs. [Reference: R-89474]

[CON-LOG-REQ-19] The container MUST be capable of automatically synchronizing the system clock daily with the Operator’s trusted time source, to assure accurate time reporting in log files. It is recommended that Coordinated Universal Time (UTC) be used where possible to eliminate ambiguity owing to daylight savings time. [Reference: R-629534]

Tagging

Muddasar put your thoughts here

Collection

Proposed Collection of Container Logs

[CON-LOG-REQ-13] The container MUST have security logging for the container and container application active from initialization. [Reference: R-84160]

[CON-LOG-REQ-20] The container and container application MUST use the STDOUT for security logs collection [Reference: REQ-374]

Data Stewardship

What is the data life cycle within ONAP?

What happens to the data as it goes to log stash?

Will it go to AAI?

TODO: Draw out a few scenarios

If there is no consumer it may be written to archive.

Archival data vs live data

Monitoring

  • Includes Enrichment, Analysis, and Reporting.
  • It is expected that this function out of scope for ONAP.  A CSP / MNO will make used of a SIEM.  ONAP's role is to provide a means to export security event data.  This is where analytics are stored and applied to the data the is ingested from ONAP.
  • Presentation by Fabian pertaining to Analysis: ONAP Logs Security Managment1.pptx

 Alerting

  • Possibly to include mitigation and actions.   
  • If we expect ONAP to respond to security events in a closed loop manner, then there needs to be a way for events generated by the SIEM to be ingested back into ONAP.

Response

Comments from Chakar, paraphrased, (7/20/2021 SECCOM Meeting)

  • We need to disambiguate "Logging" vs "Data Collection".
  • Logging from ONAP and Logging from xNF are not the same.

There are two types of responses to consider.

  • ONAP responding to a security event in a service.
  • ONAP responding to a security event within ONAP.  ONAP's ability to respond to itself is only possible in some limited and specific situations.  What are these situations?

Terms

This is place where we can standardize our language.

  • Security Data: This is raw data that by itself may not be enough to indicate a security event.
  • Security Event: 
  • Analytic

QUESTIONS (Or Advanced Use Cases)

  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

Attachments


  • No labels