What do I need to know about security protocols in the Splunk Community?
The Community exists as a forum for Splunk's technical community to share information and knowledge. To support that exchange, we each need to act on the awareness of our mutual responsibility to consider the information we share.
Use this post as a guide—along with your own judgment and your organization's security and privacy policy—when starting or contributing to discussions in the community. And do also let your fellow members know if they’ve accidentally shared information that could have security or privacy risks.
In this article…
Security Dos | Security Don'ts | Personally Identifiable Information (PII) | Security Don't Examples | Additional Resources
Security Dos
We encourage safe community engagement while making sure everyone is being safe about it. Here are a few security “Dos” to keep in mind and follow.
- Remember! This is a public community; anyone can see what you write even if they are not signed in, even months later.
- Know your organization's security and privacy policies
- Redact any sensitive information in whatever you share
- When in doubt, replace the information with placeholders
- Before you hit “post,” review what you’re about to share. Ask yourself: “Could this information create a risk for any individuals, or for your company?”
Have doubts? Review the Security Don’ts.
- Watch out for each other! If you see a message that seems to have content that could be a security or privacy risk, send the poster a Private Message or reach out to a Community Manager. You can also mark the post or reply as inappropriate content and we’ll take care of it.
Security Don’ts
The Don’ts list is much longer than the Dos, but we promise these are important points! We highly suggest you read and understand them.
We’ve aimed to make it thorough though it can’t cover every possibility — so use your best judgment.
- Don’t share log files. If you need to, make sure they're sanitized, with all sensitive data removed
- Don’t share password-protected code
- Don’t share tokens, passwords, or any authentication details
- Don’t share keys — including, but not limited to the examples below under Example of Security Don’ts
- Don’t share authorization details (e.g., Authorization: Basic; Authorization: Bearer)
- Don’t share server names
- Don't share your Controller username
- Don’t share your Controller account name
- Don’t share IP addresses
- Don’t share anything your company considers proprietary or confidential
Personally Identifiable Information (PII)
PII is any representation of information that permits the identity of an individual to whom the information applies to be reasonably inferred by either direct or indirect means. . Be respectful of others by not sharing anyone's personally identifiable information (PII) in the Community. We recommend not sharing yours either. Please be aware that two or more pieces of information that do not separately identify an individual may, in combination, result in the identification of a specific individual and thus become PII.
Examples of PII may include (but are not limited to):
- Email addresses
- Full Names
- Phone Numbers
- Date of birth
- Government Identifier numbers
- User IDs
- Home/Work address
- IP address
Some information may be sensitive such that sharing this information may cause harm or reputational loss to an individual or organization. Do not share this information, even in private messages. Examples of such information include authentication credentials, government identification numbers, trade secrets, or details about the security operations of an organization. In some cases, this information could even be contained in a Splunk search string.
While not technically PII, it is recommended that the name of the organization you work for not be given. You may see people use variables such as "$WORK" or "$JOB" to denote their organization without naming it.
Be aware that search strings themselves may contain sensitive information. Examples not related to PII include security alert methodology, indicators of compromise (IoCs), alert thresholds, architectural details of key systems, or even key details related to trade secrets.
Examples of Security Don’ts
Description
|
Examples of 'Security Don'ts'
|
AWS Access Keys
|
- AKIAIOSFODNN7EXAMPLE
- AWS_ACCESS_KEY_ID=xxxx
|
AWS Secret Access Key
|
- wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
- AWS_SECRET_ACCESS_KEY=yyyy
|
Authorization
|
- Authorization: Basic
- Authorization: Bearer
|
RSA Private Keys
|
----BEGIN RSA PRIVATE KEY----
(Key data would be here)
----END RSA PRIVATE KEY----
|
SSH (OPENSSH) Keys
|
----BEGIN OPENSSH PRIVATE KEY----
(Key data would be here)
----END OPENSSH PRIVATE KEY----
|
SSH (DSA) Private Keys
|
----BEGIN DSA PRIVATE KEY----
(Key data would be here)
----END DSA PRIVATE KEY----
|
SSH (EC) Private Keys
|
----BEGIN EC PRIVATE KEY----
(Key data would be here)
----END EC PRIVATE KEY----
|
PGP Private Key Block
|
----BEGIN PGP PRIVATE KEY BLOCK----
(Key data would be here)
----END PGP PRIVATE KEY BLOCK----
|
Server Names
|
Named according to your company's schema
|
Controller Username
|
The URL that provides access to your Splunk instance
|
Splunk Stack Name
|
https://<account-name>.splunkcloud.com/
|
IP Addresses or ranges
|
192.0.2.1
198.51.100.0/24
2001:DB8::/32
|
Sensitive search logic (e.g exact thresholds for altering)
|
index=logins action=failure earliest=-20m | stats count BY user,src_ip | where count > 42
|
Additional Resources
