secrets - Demisto SDK Guide - Cortex - Security Operations

• demsito-sdk secrets

  Runs the secrets validator on your uncommitted files.

• demisto-sdk secrets -i ./Packs/FeedAzure/Integrations/FeedAzure/FeedAzure.yml

  Runs the secrets validator on the file located in ./Packs/FeedAzure/Integrations/FeedAzure/FeedAzure.yml.

• demisto-sdk secrets --post-commit

  Runs the secrets validator on your files after you committed them.

• demisto-sdk secrets -wl ./secrets_white_list.json

  Runs the secrets validator on your files with your own allow list file located in ./secrets_white_list.json.

• Customer identifying data, anything that can identify an organization as our customer

• Customer environment information

• Passwords

• IPs

• URLs/domains

• Email addresses not for testing

• PII (personal identifying information)

• Screenshots of third party products

• Screenshots that may contain any of the above data

• Temporary allow lists occur automatically for .yml files with context paths configured.

• The main allow list file is secrets_white_list.json. This file is divided into three main parts: IOCs, Generic Strings, and Integration specific strings.

• IOCs are divided further into types such as IPV4, IPV6, EMAILS, and URLS.

• Secrets found via regex will only be tested against the IOCs allow list. If you add an indicator to an allow list, you must add it to the IOCs dictionary.

• Generic strings are common words that appear in integrations and scripts.

• If your integration requires a specific key word you can add it to the dictionary with a key that is similar to the relevant integration. This is only relevant for the uncommon situation that the string does not fit logically anywhere else.

  For example, a lot of false positives with the term CookieMonster are found. The term CookieMonster is not relevant to the generic words, so it is relevant to create a new key in the file named "sesame street" with the value a list with "cookiemonster".

• Once you update the allow list file with a string, it will be globally allowed for all integrations, even if it's integration-specific.

• Only words with five or more characters will be considered in the allow list.

• Secrets found in content packs are checked against both the allow list file provided in the -wl or --whitelist argument and in and the pack secrets file (.secrets-ignore).

• All words in an allow list must be lowercase. To make strings lower case, use command+shift+u.

Ignore lines instead of allow listing them when:

• The lines have dynamic secret/false positives (like a hash).

• There are very long, random strings (like a regex).

• It does not make sense for the lines to be on a shared allow list.

• The more random and longer a string is, the higher its entropy. The average string has entropy of between 2 to 3.4, but some longer strings of variable names can have entropy of 3.6 and greater.

• uses regex to detect mostly IOCs with typically low entropy. For example, IPV4 can have a lot of repeating characters, reducing it's randomness.

• Secrets detection is done on the file level, on the line level, and then on the string level.

• Files that are currently scanned are added/modified files of formats: .yml, .py, .json, .md, .txt, .sh, .ini, .eml, .csv, .js, .pdf, and .html.

• Eml and playbook files are only tested for indicators using regex.

• Long base 64 strings are automatically ignored.

• If PDF file parsing fails, a warning is issued under the commit message and file is skipped.

• If a Python file is detected, a related YAML file is automatically pulled and its context paths are used in a temporary allow list.

• Currently, regex is used to identify strings that are likely to be high entropy strings and are regarded as false positives, for example, dates and UUID. Regex is also used to catch and remove patterns that have high probability of being false positives.