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
- Robert Heinemann
- Muddasar Ahmed
- rouzaut
- Byung-Woo Jun
- Brian Smith (Unlicensed)
- s.silvius
- PUT YOUR NAME HERE
Key
X: Indicates what is in-scope for ONAP
BP: Indicates a best practice
P: Partially in-scope (group consensus is mixed).
...
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 1 | Phase 2 | Phase 3 | Phase 4 | Phase 5 | |
|---|---|---|---|---|---|
| Objective | Standardize Project Logging for Security | Standardized Collection of Log Data | Project logs are collected to central location | Project Logs are enriched with container metadata | All projects mandated for security logging |
| Activities | Define and specify fields required to support effective security analytics | Work with projects to write logs to STDOUT |
|
| |
| Outcome | Partial list of fields designated as Best Practice for Jakarta | Designated as Global Requirement for Jakarta | Working POC and demonstration to ONAP community |
|
|
| Timeframe | J Release - Complete | J Release - Complete | J to K Release - 3Q22 | K Release - 3Q22 | L 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.
From a 2017 AT&T Doc on ONAP Logging
"Application logging” refers to logs written by ONAP component “applications”.
"System/infrastructure logging” refers to the separate/related set of logs produced by software components not developed for ONAP (e.g. DBMS, application container, web servers, ‘middle boxes’, JVM, OS, hypervisor, etc.) that are used in the implementation of these components." (See reference #4).
Scope
...
1
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) | |||||||
| Lifecycle | Application | Container(k8s and Docker) | Infrastructure | Application | Container | Infrastructure | ||
| How they are generated | Generation | X | X | How they are made available | ||||
| Collection | X | X | ||||||
| Monitoring | ||||||||
| Alerting | ||||||||
| Response | P | P | X | X | ||||
Phase 1 will focus on logs of ONAP events.
Phase 2 will focus on logs of events from services orchestrated by ONAP
Notes
At a high level there are 5 broad categories in regards to Security Event Management (Or is this a Security Event Lifecycle?)
Generation
- Within ONAP both containers and infrastructure generate raw data that have security concerns.
- Containers (xNFs)
- 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
These below refer to the ONAP (Application and Infrastructure Columns)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Further refinement for this document only the keywords REQUIRED, RECOMMENDED and OPTIONAL will be used.
PLEASE CONSIDER THE BELOW THE MOST UP TO DATE LIST. While transferring data here from various spreadsheets and PPTs there were several errors corrected (duplicates, wrong ID number, wrong VNF REQ Numbers).
Logging Practice Requirements (Proposed)
Security Logging Best Practice
Security Event Generation Requirements (Proposed)
Metadata for Security Events (Proposed)
Steps for approval: POC → Best Practice → Global Requirement
Best Practices and Risk Analysis for an Operator
<TODO>
Best Practices for operators to collect and correlate logs
<TODO>
Tagging
...
Collection
- There currently is a SECCOM proposal that specifies what type of data should be logged where it should be logged to.
- How these logs would be collected and aggregated is specified by the ONAP NextGen Presentation by Byung.
- ONAP Next Generation Security & Logging Architecture#ONAPLogging
- old presentation slide deck (see the above link for the latest on) https://wiki.onap.org/download/attachments/103416997/ONAP-Next-Generation-Security-Logging-2021-5-25-v1.pptx?version=1&modificationDate=1621953519000&api=v2
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]
...
Key: X: Indicates what is in-scope for ONAP P: Partially in-scope (group consensus is mixed). | ||||||
| Page Tree | ||||||
|---|---|---|---|---|---|---|
|
References
- https://www.enisa.europa.eu/publications/security-in-5g-specifications
- https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-for-5g-networks
- VNF Requirements List: 9. Requirement List — onap master documentation
- ONAP application1 logging guidelines – Revision 1.0 (4/11/2017
- VNFCloud Readiness Requirements for OpenECOMP
- What to Log - Developer Wiki - Confluence (onap.org)
- Types of EELF Logs - Developer Wiki - Confluence (onap.org)
- Logging Enhancements Project — onap master documentation
Attachments
ONAP Logs Security Management |
Logging Source Reference Diagrams | ||||||||||||
Proposed Container Logging Requirements |
Container Logging Requirements GAP Analysis against ATT&CK |
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
...
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)
- 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. - 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. - 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?
References
- https://www.enisa.europa.eu/publications/security-in-5g-specifications
- https://www.enisa.europa.eu/publications/enisa-threat-landscape-report-for-5g-networks
- VNF Requirements List: 9. Requirement List — onap master documentation
- ONAP application1 logging guidelines – Revision 1.0 (4/11/2017
- VNFCloud Readiness Requirements for OpenECOMP
- What to Log - Developer Wiki - Confluence (onap.org)
- Types of EELF Logs - Developer Wiki - Confluence (onap.org)
- Logging Enhancements Project — onap master documentation
Attachments
...
| View file | ||||
|---|---|---|---|---|
|
ONAP Logs Security Management
rouzaut , FEB-20201
...
| View file | ||||
|---|---|---|---|---|
|
Logging Source Reference Diagrams
Muddasar Ahmed , JUL-2021
...
| View file | ||||
|---|---|---|---|---|
|
Proposed Container Logging Requirements
Amy Zwarico, rouzaut, FEB-2021
| View file | ||||
|---|---|---|---|---|
|
...
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.