Key Points for Security Recommendations for Log Generation
- There are many different types of logging formats that have been proposed and informally adopted across ONAP
- 2017 OpenECOMP Logging Specifications; ONAP Logging Specifications v1,1, v1,2 and v1.3. These are the ones that we know about. There may be others.
- Many different types of logging libraries EELF, PyLog, Log4J, logback, FLog, dropwizard-logging, log4js, logkit, clojure logging, jboss-logging, UnderscoreLog. Probably others. (See Nexus Report Here).
- 10 of 16 proposed security requirements for log fields exist with existing logging specifications. This means that projects that are logging and following one of these then these requirements should not be a heavy lift. So my recommendation is that we just define the the requirement and refer back to the existing specifications for field definitions.
- The remaining proposed security requirements mostly deal with container identification. Project most likely are not logging this info. These we need to specify a format and a field description as well as the requirement. In addition, we may need to prototype something by adding something to an MDC that most loggers use.
Results from comparison of existing logging
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
Field Name | Description | Reference |
---|
CON-SEC-LOG-01
CON-LOG-REQ-7
Timestamp | 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”. |
Log Type Name | 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" | (4) |
Log Level | 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? | (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. | (4) |
CON-LOG-REQ-10
Status Code | 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"
| (4) |
Severity | 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" | (4) |
Container Image Name / Tag | 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. | T1036, T1525 |
Container ID | 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. |
Container Name | 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. |
Principal ID | 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.
REF: See PartnerName in v1.3 and (4). |
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. | N/A |
Protocol | 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. |
CON-LOG-REQ-9
Service / Program Name | 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. | (4) |
Log Message | The free text payload of a log event. | (6) |