Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Activity Description

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

Actions

30 Jul 2021

...

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: 

...

13 Aug 2021

  • Review Requirements list Amy put together
  • Muddasar to provide links to NIST security logging standards: 

    https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-92.pdf

  • Fabian: Initial investigation of ONAP responding to security events.
  • Bob to provide Orchestration logging events
  • Log Template as suggested by Chakir on Tuesday call ( Apache 2 log template as an example.  Can we review work from Logging enhancement project?

Key

X: Indicates what is in-scope for ONAP

BP: Indicates a best practice

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

Definitions:

  • 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

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.

PhasePhase

1

1 -

(ONAP Based Events)

2 (events from services orchestrated by ONAP)


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

Container

(k8s and Docker)

InfrastructureApplicationContainerInfrastructureHow they are generated
GenerationXX



How they are made availableCollectionXX



Monitoring





Alerting





ResponsePP
XX

Phase 1 will focus on logs of ONAP events.

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

Image Removed

Notes

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

Generation

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)

Security Logging Events

Steps for approval: POC → Best Practice → Global Requirement

Metadata for Security Events (Proposed)

Working Session Agenda

...

Comments form Toine and VJ:

  • Toine
    • Will this work for non-transactional based logs?
    • Should this current framework cover more?
    • An extra field to identify that this is a security log.  Perhaps constrain with an ENUM.
    • Commented that he believes the container ID information is important to capture.
  • VJ:
    • Since this scope is security he would like to see this as a generalized structure used across ONAP.  DCAE has 30 containers and would like format to be applicable to all logging.
  • Both agreed that this is an important topic that should be brought forward to PTL meeting.

...

  • Discussion: Byung-Woo Jun Is possible to combine a POC and Best Practice for a single release.  If so, is this something that is possible for Toine's and VJ's projects?
  • Get on PTL meeting calendar to present security Logging Metadata
Security Log Structure

...

Timestamp

...

Log Type

...

Log Level

...

Transaction ID

...

Status Code

...

Severity

...

Container Data

...

Protocol

...

Service / Program Name

...

Log Message

...

Image Tag / Name

...

Image Digest

...

ID

...

Name

...

Principal ID

...

Role / Attribute ID

NOTE:

...

Example:

From Fabian: 

2021-09-10T14:50:37.929Z|d855a2c6-c58f-4d8d-b199-3382d11504d2|http-nio-8083-exec-5|/manage/health|kube-probe/1.19|||DEBUG|500||Headers : X-Content-Type-Options:nos

ISO 8601 TIMESTAMP: 2021-09-10T22:41:40+0000
Log Level: INFO
Transaction ID: 15a28073-3cce-495b-abb4-00771fa011b7
Status Code: COMPLETE
Severity: NONE
Container Image Name:
Container Image Digest:
Container ID: 
Container Name: 
Principal ID

...

Security Log Field Definitions

Type Synonyms:

REQUIRED: SHALL OR MUST
RECOMMENDED:  SHOULD
OPTIONAL: MAY

...

CON-SEC-LOG-01

CON-LOG-REQ-7

...

The container and container application MUST log the field “date/time” in the security audit logs. 

The value should be represented in UTC and formatted per ISO 8601, such as “2015-06-03T13:21:58+00:00”. The time should be shown with the maximum resolution available to the logging component (e.g., milliseconds, microseconds) by including the appropriate number of decimal digits. For example, when millisecond precision is available, the date-time value would be presented as, as “2015-06-03T13:21:58.340+00:00”.

...

R-97445

v1.3 Spec

...

The container and container application MUST log the field "Log type" in security audit logs.

This is a proposed field that came out from discussion with 2 PTLs on 9/17/2021.  This is meant to be a filter to distinguish from other types of logs tha tother projects a recurrently generations.

This field will adhere to the following ENUM ::= "AUDIT" | "METRICS" | "ERROR" | "DEBUG" | "SECURITY"

...


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

Page Tree
expandCollapseAlltrue
rootONAP Security Event Management
searchBoxtrue





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

View file
nameONAP Logs Security Managment1.pptx
height250

ONAP Logs Security Management
fabian rouzaut , FEB-20201

View file
nameLogging_ source reference diagrams.pptx
height250

Logging Source Reference Diagrams
Muddasar Ahmed , JUL-2021

View file
name2021-02-22_LoggingRequirementEvents_v9.pptx
height250

Proposed Container Logging Requirements
Amy Zwaricofabian rouzaut, FEB-2021

View file
nameLogging - ATTACK to SECCOM_v3.pptx
height250

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

...

The container and container application MUST use an appropriately configured logging level that can be changed dynamically.

The intention of this field is to not cause performance degradation via excessive logging. 

This field will adhere to the following ENUM ::= "FATAL" | "ERROR" | "WARN" | "INFO" | "DEBUG" | "TRACE"

The verbosity of the logging increases from left to right.

How do we synchronize these levels across projects and what the logging API they are using?

...

R-28168

(4)

...

Transaction ID

...

The container and container application MUST log Transaction ID

A transaction ID is a universally unique value that identifies a single transaction request within the ONAP platform. Its value is conformant to RFC4122 UUID. This value is readily and easily obtained in most programming environments. 

...

v1.3 Spec

(4)

...

CON-LOG-REQ-10

...

The container and container application MUST log a "status code" in the security audit logs. 

This field indicates the high level status for transactional or sub operational events.  

This field will adhere to the following ENUM ::= "COMPLETE" | "ERROR" | "INPROGRESS"

  • COMPLETE when the request is successful
  • ERROR when there is a failure
  • INPROGRESS for states between the COMPLETE and ERROR.

...

R-15325

v1.3 Spec

(4)

...

The container and container application MUST log the severity level of a processing event.  

This is to be used for error reporting in internal processing in conjunction with the status code field. 

This field will adhere to the following ENUM ::= "NONE" | "WARN" | "ERROR" | "FATAL" 

...

The container and container application MUST log the Container Image Name/Tag.

The image name/tag is as returned by the docker images command.

NOTE:  Images are not required to have tags

...

Container Image Digest

The container and container application MUST log the container image digest.

The digest is a cryptographic digest as returned by the docker images --digests command.

...

The container and container application MUST log the container ID.

The container ID is the same that is returned by the docker ps -q command.

NOTE: The container ID is unique for life time of the the container instance. Once the container is killed, this ID goes away.

...

The container and container application MUST log  the container name.

This is the unique name of the image ( webserver, FW, DCAE01).  This is returned by the docker ps command.

...

The container and container application MUST log the Principal identity of a requestor in the security audit logs. 

This field should contain the identification name of the client application (user agent, client id, user, user id, login ID, non-person entity (NPE), Token,  etc.) of the entity accessing or invoking the service or API (Service / Program Name).

This field should contain the identification of the entity (user agent, client id, user, user id, login ID, non-person entity (NPE), Token,  etc.)  that made the request of the service or API indicated in the Service/Program Name field. For a serving API that is authenticating the request, this should be the authenticated username or equivalent.

There are not a concrete set of values for this field.  The developer should keep the following set of guidelines when determining what value to use or set for this field.

  • Use the short name of your component, e.g. xyzdriver
  • Values should be human-readable. 
  • Values should be fine-grained enough to disambiguate subcomponents where it's likely to matter. This is subjective. 
  • Be consistent: your component should ALWAYS report same value. 

REF: See PartnerName in v1.3 and (4).

R-89474

v1.3 Spec

...

Role / Attribute ID

...

The container and container application MUST log the Role or Attribute ID of the Principal identity of the entity accessing the requested service or API.

Note: The group ID is in reference to a Role or Attribute as part of a RBAC or ABAC scheme.

...

CON-LOG-REQ-8

...

The container and container application MUST log the field “protocol” in the security audit logs.

This refers to the communication mechanism for a request.  The value of this field should be representative of the OSI application layer  protocol. This is represented as a decimal formatted TCP/IP port number.

...

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.

This intention is to capture the service name endpoint or an externally advertised API invoked, e.g., where are you connecting to. This is represented as a URI or URL. 

R-06413

v1.3 Spec

(4)

...

Best Practices and Risk Analysis for an Operator

<TODO>

Best Practices for operators to collect and correlate logs

<TODO>

Tagging

...

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]

...

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.

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?
    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?  

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

...

View file
nameONAP Logs Security Managment1.pptx
height250

ONAP Logs Security Management
fabian rouzaut , FEB-20201

...

View file
nameLogging_ source reference diagrams.pptx
height250

Logging Source Reference Diagrams
Muddasar Ahmed , JUL-2021

...

View file
name2021-02-22_LoggingRequirementEvents_v9.pptx
height250

Proposed Container Logging Requirements
Amy Zwaricofabian rouzaut, FEB-2021

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.



Image Added

View file
nameLogging - ATTACK to SECCOM_v3.pptx
height250

...