Activity Description

The goal of this activity is to develop a set of security requirements, security best practices and define a realistic plan to bring consistent logging across ONAP to support security analytics.

Roadmap


Phase 1Phase 2Phase 3Phase 4Phase 5
ObjectiveStandardize Project Logging for SecurityStandardized Collection of Log DataProject logs are collected to central locationProject Logs are enriched with container metadataAll projects mandated for security logging
ActivitiesDefine and specify fields required to support effective security analyticsWork with projects to write logs to STDOUT
  • Develop  architecture
  • Develop POC
  • Augment architecture to enrich log data with container metadata

OutcomePartial list of fields designated as Best Practice for JakartaDesignated as Global Requirement for JakartaWorking POC and demonstration to ONAP community
  • Working POC
  • Additional log fields set as best practice
  • Initial log fields set as global requirement
  • All security fields set as Global Requirement
  • Logging Architecture set as Global Requirement
TimeframeJ Release - CompleteJ Release - CompleteJ to K Release - 3Q22K Release - 3Q22L Release - 1Q23

Scope of Activity

In an effort to scope the activity the following table was developed.

The below matrix is organized by log lifecycle across ONAP Components and Services.  The components and services are further broken down by application, container and infrastructure.  For the purposed of this activity application, container and infrastructure are defined as follows: 

  • Application: This refers to runtime containerized application
  • Container: This refers to the container platform and orchestration software that ONAP interfaces with.  For example, docker and K8S.
  • Infrastructure: This refers to any physical, virtualization, element managers, and/or operating system components.

Our immediate focus is on defining what logs should be generated (see Log Generation below) and how they should be collected (see Log Collection below) for ONAP Components only.  This is indicated as Phase 1 in the table below.  Ultimately we want to create a POC then have approved as a Best Practice then as a Global Requirement.

Phase

1 - (ONAP Based Events)

2 - (events from services orchestrated by ONAP)


ONAP Components (e.g., DCAE, SDC, etc.)Services (xNF, xApps)
LifecycleApplication

Container

InfrastructureApplicationContainerInfrastructure
GenerationXX



CollectionXX



Monitoring





Alerting





ResponsePP
XX

Key: X: Indicates what is in-scope for ONAP                 P: Partially in-scope (group consensus is mixed).

Expand all   Collapse all





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
  3. VNF Requirements List: 9. Requirement List — onap master documentation
  4. ONAP application1 logging guidelines – Revision 1.0 (4/11/2017
  5. VNFCloud Readiness Requirements for OpenECOMP
  6. What to Log - Developer Wiki - Confluence (onap.org)
  7. Types of EELF Logs - Developer Wiki - Confluence (onap.org)
  8. Logging Enhancements Project — onap master documentation

Attachments

ONAP Logs Security Management
fabian rouzaut , FEB-20201

Logging Source Reference Diagrams
Muddasar Ahmed , JUL-2021

Proposed Container Logging Requirements
Amy Zwarico, fabian rouzaut, FEB-2021

Container Logging Requirements GAP Analysis against ATT&CK
Robert Heinemann , Muddasar Ahmed MAY-2021


Misc. Notes

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

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

QUESTIONS (Or Advanced Use Cases)

  1. In terms of security logging, should we handle ONAP components differently than Service Components hosted in ONAP?
    Muddasar: Any transections carried out for a service(5G, virtualization and SDN) should generate Application Logs  by ONAP Containers.  I would think life cycle management of a service (instantiation and changes) may have some information buried in the ONAP logs.  Transections events for service design, service deployment within and outside the ONAP components  thru ONAP APIs should be part of the ONAP logging.  
  2. How do we handle the use case where ONAP is being used to deploy and manage a security infrastructure?
    Muddasar: I think it may be similar to above.  I think ONAP will not be used to do OAM of security infrastructure, with exception that ONAP may play a role in the instantiation of some of security network elements.  Example:  A service design may require deployment of FW/IDS/IPS.  ONAP transection may be limited to requesting VIMs/EMs  to deploy/change network elements and perhaps deploy base configuration.  Logs generated by network elements may flow thru a different path(different virtualized enclaves) to a different collector similar to XNFs.  
  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?
    Muddasar:  I believe Data Exposure Service (DES) can provide this facility.  I think question here should be that once logs are created, are there any internal ONAP consumers for that information?  

Best Practices and Risk Analysis for an Operator

<TODO>

Best Practices for operators to collect and correlate logs

<TODO>

Tagging

Muddasar put your thoughts here :Adding metadata or label tags close to log source or by the log source is a good practice.  Tags can be added by a local driver for Service and Container ID/name (fqdn) as logs received by logging driver.  As ONAP XNF containers will log to stdout/stderr I/O streams, a host or sidecar based collector should be able to add tags for sending source prior to moving the logs to centralized collection location. 

As part of log generation other information elements can be added by the application.  we should consider what needs to be a requirement:  Event_Type (Access, Operation, Error).  Logging enahncement project in the past listed format and options, see Logging Enhancements Project Proposal.




  • No labels