Update security best practices document #100814
Conversation
I've reformatted the document, adding references and additional info on attacks and Kibana's built-in security controls. TODO: update `best_practices.mdx` accordingly.
jportner
added
v8.0.0
release_note:skip
jportner
requested review from
kobelb,
stacey-gammon and
a team
and removed request for
kobelb
There was a problem hiding this comment.
Self-review. I structured this so each section has the following information:
- Reference to authoritative information and additional resources, wherever possible
- A short description of the attack
- A short description on Kibana's platform-wide defenses, if applicable
- Best practices that developers should follow
In addition to the comments below, a couple of high-level thoughts:
- I debated adding a section on Denial of Service. We have one other section on generic threats (Information Disclosure). DoS is typically introduced by third-party dependencies though, not by developers directly.
- I debated adding a section on authorization. We have a separate Security development page that describes RBAC and authorization. Would it be useful to add a section here with a blurb that developers should make sure users are authorized, and a link to the aforementioned page?
| Application Security Project (OWASP) references to learn more about these types of attacks. |
There was a problem hiding this comment.
I thought about including a section on threats here at the top (such as this), but it felt like that might be a bit too much info for our audience, who are mostly not security experts.
| * Allowing users to input markdown is a common culprit. If using a non-EUI markdown renderer, use a custom link renderer for rendered links. | ||
|
|
||
| === Information Disclosure === |
There was a problem hiding this comment.
Everything else here is a class of attacks, but Information Disclosure is a generic threat. I opted to leave this here as I think it's a good concern for folks to keep top-of-mind.
|
I defer to Brandon's LGTM. Thanks for doing this Joe, and for reviewing Brandon! (just don't forget to fill back the mdx file before merging) |
Co-authored-by: Thomas Watson <w@tson.dk>
There was a problem hiding this comment.
This is great, thanks for making these changes, Joe!
I debated adding a section on authorization. We have a separate Security development page that describes RBAC and authorization. Would it be useful to add a section here with a blurb that developers should make sure users are authorized, and a link to the aforementioned page?
I think this would be worthwhile, but I also think the Security development page could use a rewrite. I think it could benefit from a restructuring so that we can provide actionable "do this"/"don't do this" for our solution teams, rather than describing "how the sausage is made". I think the existing content is still valuable, but it's not very actionable in urs current form.
All that to say: perhaps we can add a link to the "new" Security development page once we take the time to write it?
| === Remote Code Execution (RCE) === | ||
|
|
||
| https://owasp.org/www-community/attacks/Command_Injection[_OWASP reference for Command Injection_], |
There was a problem hiding this comment.
I don't see the text "RCE" is the linked pages.
There was a problem hiding this comment.
Yeah this one is a bit confusing. Colloquially we lump "Command injection" and "Code injection" together, referring to these types of attacks as "RCE". But OWASP doesn't have an RCE page.
I tried to imply this equivalency below where I stated:
RCE is a class of attacks where an attacker executes malicious code or commands on a vulnerable server.
Do you think there's a better / more clear way I could word this?
|
OK, I think I addressed everyone's feedback! I'll leave this open for another few days and if nobody else has anything to add, I'll update the MDX file to match and merge 😄 |
jportner
added
the
auto-backport
|
jenkins, test this (restarting due to jenkins upgrade) |
💚 Build Succeeded
Metrics [docs]
To update your PR or re-run it, just comment with: |
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…egrations-to-global-search * 'master' of github.com:elastic/kibana: (46 commits) [Lens] Add some more documentation for dynamic coloring (elastic#101369) hide not searchable results when no term (elastic#102401) [Lens] Fix Formula functional test with multiple suggestions (elastic#102378) Fix trusted apps modified by field displayed as a date field (elastic#102377) [Lens] Docs for time shift (elastic#102048) update readme of logs-metrics-ui (elastic#101968) Refactor observability plugin breadcrumbs (elastic#102290) [Index Patterns] Move rollup config to index pattern management v2 (elastic#102285) [Security Solution][Endpoint] Isolate Action should only be available to Platinum+ licenses (elastic#102374) [build] Updates Ironbank templates (elastic#102407) Update security best practices document (elastic#100814) [Enterprise Search] Set up initial KibanaPageTemplate (elastic#102170) [Reporting/Docs] Add section to troubleshooting guide to explain the StatusCodeError logs (elastic#102278) [DOCS] Updating Elastic Security Overview topic (elastic#101922) [Uptime] refactor Synthetics Integration package UI (elastic#102080) [Task Manager] Log at different levels based on the state (elastic#101751) [APM] Fixing time comparison types (elastic#101423) [RAC] Update alert documents in lifecycle rule type helper (elastic#101598) [ML] Functional tests - fix and re-activate alerting flyout test (elastic#102368) [Reporting] remove unused reference to path.data config (elastic#102267) ... # Conflicts: # x-pack/plugins/fleet/kibana.json
I've reformatted the "Security best practices" page (
security.asciidoc), adding references and additional info on attacks and Kibana's built-in security controls.best_practices.mdxwas derived from this; I will update it accordingly when the review is complete and the content is agreed upon.Docs preview link