Please review your ONAP CII badging responses

Krzysztof Opasiak

Dear PTLs and committers,

In connection to today presentation@PTLcall I'd like to kindly ask you
to review your projects answer to below CII badging questions (* badge
level, + question). I'd like also to ask you to revise your answers and
be more conservative with issuing N/A answers. It would be very helpful
if you could provide some rationale why you think this question is not
applicable to your project.

* Passing

+ No Leaked Credentials

The public repositories MUST NOT leak a valid private credential (e.g.,
a working password or private key) that is intended to limit public access.

A project MAY leak "sample" credentials for testing and unimportant
databases, as long as they are not intended to limit public access.

My Comment:
ONAP currently leaks almost all credentials in OOM Charts. It's OK to
leak credentials for test account etc as long as they are well
documented and not deployed by default. Taking into account that ONAP
may be deployed on public cloud almost all passwords as important (yes,
even for services that are not exposed outside of the cluster as this is
a second tier of protection).

+ Crypto password storage

If the software produced by the project causes the storing of passwords
for authentication of external users, the passwords MUST be stored as
iterated hashes with a per-user salt by using a key stretching
(iterated) algorithm (e.g., PBKDF2, Bcrypt or Scrypt). (N/A allowed.)

This criterion applies only when the software is enforcing
authentication of users using passwords, such as server-side web
applications. It does not apply in cases where the software stores
passwords for authenticating into other systems (e.g., the software
implements a client for some other system), since at least parts of that
software must have often access to the unhashed password.

My Comment:
User password should never be stored in plain text or any reversible
form. Encryption is a reversible form of protection and it should not be
used for passwords. If your service stores passwords as plain text or
encrypted you should answer No to this question.

+ Crypto Working

The default security mechanisms within the software produced by the
project MUST NOT depend on broken cryptographic algorithms (e.g., MD4,
MD5, single DES, RC4, Dual_EC_DRBG), or use cipher modes that are
inappropriate to the context, unless they are necessary to implement an
interoperable protocol (where the protocol implemented is the most
recent version of that standard broadly supported by the network
ecosystem, that ecosystem requires the use of such an algorithm or mode,
and that ecosystem does not offer any more secure alternative). The
documentation MUST describe any relevant security risks and any known
mitigations if these broken algorithms or modes are necessary for an
interoperable protocol. (N/A allowed.)

ECB mode is almost never appropriate because it reveals identical blocks
within the ciphertext as demonstrated by the ECB penguin, and CTR mode
is often inappropriate because it does not perform authentication and
causes duplicates if the input state is repeated. In many cases it's
best to choose a block cipher algorithm mode designed to combine secrecy
and authentication, e.g., Galois/Counter Mode (GCM) and EAX. Projects
MAY allow users to enable broken mechanisms (e.g., during configuration)
where necessary for compatibility, but then users know they're doing it.

My comment:
This question is about using cryptography in a correct way. If you
encrypt password instead of hashing them you say no. If you encrypt user
cookie instead of just signing them, most likely you should also say no.

* Silver

+ Input Validation

The project results MUST check all inputs from potentially untrusted
sources to ensure they are valid (a *whitelist*), and reject invalid
inputs, if there are any restrictions on the data at all

My Comment:
If you don't escape all fields for SQL Injections or XSS then you don't
meet this criteria.

+ Crypto Used Network (Suggested in Silver, Mandatory in Gold)

The software produced by the project SHOULD support secure protocols for
all of its network communications, such as SSHv2 or later, TLS1.2 or
later (HTTPS), IPsec, SFTP, and SNMPv3. Insecure protocols such as FTP,
HTTP, telnet, SSLv3 or earlier, and SSHv1 SHOULD be disabled by default,
and only enabled if the user specifically configures it. If the software
produced by the project does not support network communications, select
"not applicable" (N/A)

My comment:
If you expose any HTTP endpoint or communicate with other service using
http instead of https you don't meet this criteria.

Best regards,
Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

Join to automatically receive all group messages.