Versions Compared

Old Version 1

changes.mady.by.user Adheli Tavares

Saved on

compared with

New Version Current

changes.mady.by.user Adheli Tavares

Saved on

Key

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

...

Jira Legacy
serverSystem Jira
columnIdsissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolution
columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyPOLICY-4681


Follow up Jira for documentation -

Jira Legacy
serverSystem Jira
serverId4733707d-2057-3a0f-ae5e-4fd8aff50176
keyPOLICY-4817

Security Knowledge

Know Secure Design

Do the committers and PTL know how to design secure software? Do the reviewers of OJSI tickets know secure design?

...

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Yes - the PF team follows the best common practices regarding security and possible vulnerabilities✅

Implement Secure Design

Do the committers and PTL apply secure design principles when reviewing software for merging?

...

Cloak

The project must implement secure design principles (from 'know secure design').

For example, the project results should have fail-safe defaults (access decisions should deny by default, and projects' installation should be secure by default). They should also have complete mediation (every access that might be limited must be checked for authority and be non-bypassable). Note that in some cases principles will conflict, in which case a choice must be made (e.g., many mechanisms can make things more complex, contravening 'economy of mechanism' / keep it simple).

Implement secure design builds on the question above of "know secure design". For ONAP, the committers must all know the secure design principles and reviewing the code must always includes looking at it from the point of review of the security principles.

It's crucial to document the secure design practices and software design/coding standards and code review. This NIST SSDF document provides additional details: 

[implement_secure_design S]


Your Answer-Please ExplainSECCOM Feedback / Recommendations
Yes - the PF team/PTL/committers review and look for security issues and recommend fixes before merging.

Know Common Errors

...

?

  • does the team fix the findings identified by SonarCloud and NexusIQ? 
    • depends on how the fix needs to be implemented. some of the current issues require dependency updates that would break code and are part of the java-17 upgrade.

Know Common Errors

Do the committers and PTL understand commonly found errors (and how to counter or mitigate them)? Do they apply these principles when reviewing software for merging?

...

Your Answers-Please ExplainSECCOM Feedback / Recommendations
Yes - the PF team & PTL are aware of common security risks and how to mitigate them✅

No Leaked Credentials

Do the committers and PTL verify that there are no non-test credentials and no non-test private keys in code to be merged?

...

Your Answer-Please ExplainSECCOM Feedback / Recommendations

We have public user/password in configuration files, including test files. It's recommended to change it and most of the non-test usage is done with helm charts, which generate secrets.

✅

Security Documentation

Documentation Architecture

Does your project have an architecture or high level design documented?

If so, please provide a URL to the pages on wiki.onap.org or onap.readthedocs.io that have the architecture or high level design. If not, please describe the high level design here using one or more paragraphs.

...

Your Answer-Please DescribeSECCOM Feedback / Recommendations

ONAP documentation - https://docs.onap.org/projects/onap-policy-parent/en/latest/index.html

✅

Documentation Security

pDoes your project have a description of what a user of user of your roject project can and cannot expect in terms of security from the software produced by the project, (In other words, what are its 'security requirements'?)

If so, please provide a URL to the page(s) on wiki.onap.org or onap.readthedocs.io. If not, please describe the security requirements here using one or more paragraphs.

...

Your Answer-Please DescribeSECCOM Feedback / Recommendations

Security documentation?

Assurance Case

Does your project actually meet its documented security requirements?

...

All the resources that can be accessed in PF require authentication

❌

  • Please submit link with your security documentation + information about what capabilities authentication provides.
  • Do you require authorization? No
  • Can PF restrict access to resources based on identity? if so what mechanisms are used? No
  • Are there different levels of authorization once you've authenticated? No
  • Is there authentication and authorization on the events being acted? Authentication only
  • What kind of security is used to control access to the network elements being controlled? PF is using service mesh
  • 2023/8/22: PF will create Montreal Jira ticket to document security architecture and assurance.

Assurance Case

Does your project actually meet its documented security requirements?

If so, please provide a URL to the page(s) on wiki.onap.org or onap.readthedocs.io that describe how the project meets its security goals. If not, please describe here (using one or more paragraphs) how the project meets its security goals.

...

Security documentation?

Tests cases for any security measurements? 

Your Answer-Please DescribeSECCOM Feedback / Recommendations

Vulnerability Mitigation

Vulnerabilities Critical Fixed

Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?

...

All critical vulnerabilities should be fixed rapidly after they are reported.

...

Test cases are found at https://github.com/onap/policy-docker/tree/master/csit/resources/tests showing that authentication must be done before interacting with any resource.

ONAP docs describring how to run test cases https://docs.onap.org/projects/onap-policy-parent/en/latest/development/devtools/testing/csit.html

?

Good start

  • answer questions above under documentation security,
  • create Wiki page for your Assurance Case (or a section on the Documentation Security page)
  • provide answers there.
  • In particular describe how your security goals are being met by your implementation, or not
  • provide here a link to that Wiki page/section
  • 2023/8/22: PF will create Montreal Jira ticket to document security architecture and assurance.

Vulnerability Mitigation

Vulnerabilities Critical Fixed

Have you closed all issues filed against your project in sonarcloud that are CRITICAL or BLOCKERs?

Toggle cloak
 Cloak
All critical vulnerabilities should be fixed rapidly after they are reported.
[vulnerabilities_critical_fixed P]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Sonarcloud reports can be found at:
https://sonarcloud.io/project/overview?id=onap_policy-apex-pdp
https://sonarcloud.io/project/overview?id=onap_policy-api
https://sonarcloud.io/project/overview?id=onap_policy-clamp
https://sonarcloud.io/project/overview?id=onap_policy-common
https://sonarcloud.io/project/overview?id=onap_policy-distribution
https://sonarcloud.io/project/overview?id=onap_policy-drools-applications
https://sonarcloud.io/project/overview?id=onap_policy-drools-pdp
https://sonarcloud.io/project/overview?id=onap_policy-gui
https://sonarcloud.io/project/overview?id=onap_policy-models
https://sonarcloud.io/project/overview?id=onap_policy-pap
https://sonarcloud.io/project/overview?id=onap_policy-xacml-pdp
❌
The following have security hotspots
policy-common, policy-pap
The latter is a high priority item that is >1 year old.
  • they mentioned security hotspot is a piece of code necessary for ingestion in another private service - it would change both implementations for token exchange, which is not in question.
  • 2023/8/22: PF review the hotspot in policy-common and policy-pap to determine if they are false positives.
  • 2023/8/22: SECCOM will investigate disabling false positives in sonarcloud.


Vulnerabilities Fixed 60 Days
Are all vulnerabilities that are reported against your project, either through an OJSI ticket or publicly from CVE reports, fixed within two months of being reported?
 Toggle cloak
 Cloak
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.
The vulnerability must be patched and released by the project itself (patches may be developed elsewhere). A vulnerability becomes publicly known (for this purpose) once it has a CVE with publicly released non-paywalled information (reported, for example, in the National Vulnerability Database) or when the project has been informed and the information has been released to the public (possibly by the project). A vulnerability is considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known. Note: this means that users might be left vulnerable to all attackers worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in Rebooting responsible disclosure, because Google recommends that the 60-day period start when the project is notified even if the report is not public. Also note that this applies to each individual project in ONAP. Once a patch is available from each individual project, others can determine how to deal with the patch (e.g., they can update to the newer version or they can apply just the patch as a cherry-picked solution).
[vulnerabilities_fixed_60_days P]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Sonarcloud reports can be found @
Vulnerabilities Fixed 60 Days
Are all vulnerabilities that are reported against your project, either through an OJSI ticket or publicly from CVE reports, fixed within two months of being reported?
...
 Cloak
There MUST be no unpatched vulnerabilities of medium or higher severity that have been publicly known for more than 60 days.
The vulnerability must be patched and released by the project itself (patches may be developed elsewhere). A vulnerability becomes publicly known (for this purpose) once it has a CVE with publicly released non-paywalled information (reported, for example, in the National Vulnerability Database) or when the project has been informed and the information has been released to the public (possibly by the project). A vulnerability is considered medium or higher severity if its Common Vulnerability Scoring System (CVSS) base qualitative score is medium or higher. In CVSS versions 2.0 through 3.1, this is equivalent to a CVSS score of 4.0 or higher. Projects may use the CVSS score as published in a widely-used vulnerability database (such as the National Vulnerability Database) using the most-recent version of CVSS reported in that database. Projects may instead calculate the severity themselves using the latest version of CVSS at the time of the vulnerability disclosure, if the calculation inputs are publicly revealed once the vulnerability is publicly known. Note: this means that users might be left vulnerable to all attackers worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in Rebooting responsible disclosure, because Google recommends that the 60-day period start when the project is notified even if the report is not public. Also note that this applies to each individual project in ONAP. Once a patch is available from each individual project, others can determine how to deal with the patch (e.g., they can update to the newer version or they can apply just the patch as a cherry-picked solution).
[vulnerabilities_fixed_60_days P]
...
Non-Cryptographic Software Questions
The following are a few issues regarding your project's software as delivered that are not cryptographic-related.
Input Validation
Does your application accept input from potentially untrusted sources? If so, do you ensure that the input is valid before processing it?
...
 Cloak
The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all.
Note that comparing input against a list of 'bad formats' (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be 'anything at all' (e.g., a file uploader), but these would typically be rare.
[input_validation S]
...
BeanValidation?
Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
...
 Cloak
If you compile code into binary executables, do you use
  • compiler flags to mitigate attacks (such as -fstack-protector)?
  • compiler flags to eliminate undefined behavior?
  • special build features like Address Sanitizer (ASAN) (if available)?
If your project provides a web user interface:
  • Does it require the hardening headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as 'nosniff'), and X-Frame-Options?
  • If your web site were to be passed to a website such as <securityheaders.com>, would you get a grade of A or B?
  • Are administrative web pages shown or listed only if the logged in user is an administrator?
  • Are your JavaScript and CSS served from separate files?
  • Do you use HTTP to HTTPS redirects?
  • Do you use HSTS?
  • If appropriated, do you do rate limiting to prevent DOS attacks?
  • Do you employ measures to resist Cross Site Request Forgeries (CSRFs)?
  • Do your cookies use settings to counter Javascript-based attacks, set secure=true, and counter CSRF using a SameSite value?
  • Do you protect use of target='_blank' with rel="noopener noreferrer"?
If your project generates email:
  • Do you take measures for rate limiting?
  • Do you encrypt the email addresses that might be stored in a database?
If your project uses a database:
  • Do you encrypt values that are sensitive?
[hardening SG]
No UI
Data sensitive? No encryption.
The application uses Swagger for RESTful API, wherein it is set that Authorization headers are required for accessing API documentation.
When PF runs with docker, the services use usernames and passwords that are stored as environment variables.
For helm deployments PF uses K8s secrets which are generated and stored as the application is deployed
Your Answer-Please ExplainSECCOM Feedback / Recommendations
We try to keep up to date on fixing vulnerabilities reported on IQ Nexus, except when dependency updates break the current code and a study is necessary to mitigate functionalities not working.
?
And sonar cloud?
  • sonar cloud is also checked, the team has sonar cloud configured with IDEs.
policy-pap has a high severity security item reported in sonarcloud for >1 year
  • see answer above.

How are OJSIs dealt with?
  • 2023/8/22: PF will document response process for unplanned security issues that have to be fixed outside of the normal release cycle.

Non-Cryptographic Software Questions
The following are a few issues regarding your project's software as delivered that are not cryptographic-related.
Input Validation
Does your application accept input from potentially untrusted sources? If so, do you ensure that the input is valid before processing it?
 Toggle cloak
 Cloak
The project results MUST check all inputs from potentially untrusted sources to ensure they are valid (an *allowlist*), and reject invalid inputs, if there are any restrictions on the data at all.
Note that comparing input against a list of 'bad formats' (aka a *denylist*) is normally not enough, because attackers can often work around a denylist. In particular, numbers are converted into internal formats and then checked if they are between their minimum and maximum (inclusive), and text strings are checked to ensure that they are valid text patterns (e.g., valid UTF-8, length, syntax, etc.). Some data may need to be 'anything at all' (e.g., a file uploader), but these would typically be rare.
[input_validation S]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
BeanValidation is used for any request coming in, checking if format and type rules are matched.

✅
Hardening
Does your project apply hardening mechanisms so that software defects are less likely to result in security vulnerabilities?
 Toggle cloak
 Cloak
If you compile code into binary executables, do you use
  • compiler flags to mitigate attacks (such as -fstack-protector)?
  • compiler flags to eliminate undefined behavior?
  • special build features like Address Sanitizer (ASAN) (if available)?
If your project provides a web user interface:
  • Does it require the hardening headers: Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Content-Type-Options (as 'nosniff'), and X-Frame-Options?
  • If your web site were to be passed to a website such as <securityheaders.com>, would you get a grade of A or B?
  • Are administrative web pages shown or listed only if the logged in user is an administrator?
  • Are your JavaScript and CSS served from separate files?
  • Do you use HTTP to HTTPS redirects?
  • Do you use HSTS?
  • If appropriated, do you do rate limiting to prevent DOS attacks?
  • Do you employ measures to resist Cross Site Request Forgeries (CSRFs)?
  • Do your cookies use settings to counter Javascript-based attacks, set secure=true, and counter CSRF using a SameSite value?
  • Do you protect use of target='_blank' with rel="noopener noreferrer"?
If your project generates email:
  • Do you take measures for rate limiting?
  • Do you encrypt the email addresses that might be stored in a database?
If your project uses a database:
  • Do you encrypt values that are sensitive?
[hardening SG]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
No UI
No encryption, as data processed by PF hasn't been tagged as sensitive.
The application uses Swagger for RESTful API, wherein it is set that Authorization headers are required for accessing API documentation.
When PF runs with docker, the services use usernames and passwords that are stored as environment variables.
For helm deployments PF uses K8s secrets which are generated and stored as the application is deployed.
The user has the option to provide a username/password to the helm chart - in this case a kubernetes secret
will be generated by the chart and used for authentication. Alternatively, the user can provide a secret to the chart values - in this case, no secret
will be generated - the chart will just use the k8s secret provided by the user/deployer
?
  • Is https used? - no
  • Has the project migrated to the service mesh which provides https and RBAC - yes
  • 2023/8/22: document security controls provided by service mesh and K8S: encryption in transit, authentication (policy enforcement, policy decision, and policy information point). PF designed to run in K8S with a service mesh providing security controls.

Cryptographic-specific Software Questions
The following questions all deal with cryptographic issues.
Crypto Call – Generic
Does your software implement any cryptographic functions, such as hash functions, instead of calling on software specifically designed to implement cryptographic functions?
...
Your Answer-Please ExplainSECCOM Feedback / Recommendations
N/A✅
Crypto Random - Generic
Does your software use random information? If so, does it use a cryptographically secure random number generator?
...
 Cloak
The security mechanisms within the software produced by the project MUST generate all cryptographic keys and nonces using a cryptographically secure random number generator, and MUST NOT do so using generators that are cryptographically insecure.
A cryptographically secure random number generator may be a hardware random number generator (/dev/random), or it may be a cryptographically secure pseudo-random number generator (CSPRNG) using an algorithm such as Hash_DRBG, HMAC_DRBG, CTR_DRBG, Yarrow, or Fortuna. Examples of calls to secure random number generators include Java's java.security.SecureRandom and JavaScript's window.crypto.getRandomValues. Examples of calls to insecure random number generators include Java's java.util.Random and JavaScript's Math.random.
For additional guidance and examples about what kind of specifications to rate a random bit generator (RBG) please review: 
[crypto_random P]

SECCOM Feedback / Recommendations
Your Answers-Please ExplainAnswers-Please ExplainSECCOM Feedback / Recommendations
UUID random keys
  • using java native way of generation java.util.UUID
✅
Crypto Weaknesses
Does your software depend on any cryptographic algorithms or modes that have known serious weaknesses?
...
 Cloak
The default security mechanisms within the software produced by the project SHOULD NOT depend on cryptographic algorithms or modes with known serious weaknesses (e.g., the SHA-1 cryptographic hash algorithms, or the CBC mode in SSH).
Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.
[crypto_weaknesses PS]
...
Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
When PF runs with docker, the services use usernames and passwords that are stored as environment variables.
...
CBC mode in SSH).
Concerns about CBC mode in SSH are discussed in CERT: SSH CBC vulnerability.
[crypto_weaknesses PS]

Your Answer-Please ExplainSECCOM Feedback / Recommendations
Depends of user managing crypto their own passwords - passwords are configurable in application.yaml for Spring applications (api, pap and acm) and .json configuration files for others. The credentials provided in these files are used for authentication (no authorization dealt in any of PF components) to use any of the REST APIs provided by PF.
All of the authorization/authentication is being managed by service mesh - using the authorizationPolicy implemented into SM.
? 2023/8/22: move information in "Your Answer" to the security documentation.
Please expand on the use of configurable usernames+passwords and what they allow.
2023/8/22: add password use and protection to security documentation. Determine if spring is doing authentication, authorization or both. If PF is storing passwords in order to call APIs, document the secure storage and access of the passwords.
2023/8/22: cryptography provided by K8S using secure algorithms and ciphers.
Crypto Working
Does your software depend on any cryptographic algorithms that are known to be broken?
...
Your Answer-Please ExplainSECCOM Feedback / Recommendations
Usernames and passwords are configurable by the clients via passing the environment variables for use in application.yml file.
When PF runs with docker, the services use username and passwords that are stored as environment variables.
For helm deployments, PF uses K8s secrets which are generated and stored as the application is deployed
UUID generator is being used, but for IDs, not for security concerns.
No crypto being used.
❌
Doesn't answer the question
2023/8/22: PF to document all uses of cryptographic algorithms within the PF application. UUID generation is not part of cryptography.
Crypto Keylength
Does your software generate any keys? If so, do they use any default key-lengths that are considered insecure?
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
No keys being generated for us in OOM, PF is part of service mesh to connect to other services.
UUID generated (using java native way) are for identifiers.
✅
Doesn't answer the question
Crypto Algorithm Agility
Does your software use cryptographic algorithms? If so, can a user of ONAP switch the algorithm if one is found to be broken?
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
K8s secrets that are generated and stored as apps are deployed.
ACM-Runtime use java.UUID mechanism for generating unique identifiers.No crypto is being used, aside from UUID generated (using java native way), which are used for identifiers.
❌
Doesn't answer the question
Crypto Certificate Verification
Does your software use HTTPS? If so, does it do certificate verification of the host certificates by default?
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
PF is compliant and compatible with the ongoing service mesh implementation (https://gerrit.onap.org/r/c/oom/+/128543) for ONAP. 
✅
Crypto Credential Agility
Does your software save or process authentication credentials or private cryptographic keys? If so, is that information stored separately from other information?
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
Usernames and passwords 
Credentials are 
 configurable by the clients via passing the environment variables for use in application.yml file.
When CPS is run with docker, the services use username and passwords that are stored as environment variables.
For deployments, CPS uses K8s secrets which are generated and stored as the application is deployed.managed by k8s secrets.
❌
Doesn't answer the question
Crypto TLS1.2
Does your software support HTTPS? If so, is the minimum version allowed TLS1.2?
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
PF is compliant and compatible with the ongoing service mesh implementation (https://gerrit.onap.org/r/c/oom/+/128543) for ONAP. 
✅
Crypto Used Network
Does your software have network communications inbound or outbound? If so, do you support secure protocols for all such network communications?
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
PF only communicates with  components within ONAP.
PF's primary communication is through HTTP.
PF uses Kafka or REST api interfaces between PF components and service mesh for other communications.components within ONAP.
PF's primary communication is through HTTP.
PF uses Kafka or REST api interfaces between PF components and service mesh for other communications.
As mentioned above, we need to add to documentation that PF is supposed to run within OOM deployment. That said, SM is managing all communication.

?
is HTTP protected by mesh and HTTPS?
  • yes
Crypto Verification Private
Does your software use outbound HTTPS connections? If so, does it perform certificate verification before sending HTTP headers with private information (such as secure cookies)
...
Your Answers-Please ExplainSECCOM Feedback / Recommendations
PF is compliant and compatible with the ongoing service mesh implementation (https://gerrit.onap.org/r/c/oom/+/128543) for ONAP. 
As mentioned above, we need to add to documentation that PF is supposed to run within OOM deployment. That said, SM is managing all communication.
❌
Doesn't answer the question