You're absolutely right. You don't need documentation for documentation's sake.
You need documentation so that your people aren't just making stuff up at exactly the time when you don't want them to be just making stuff up.
You're absolutely right. You don't need documentation for documentation's sake.
You need documentation so that your people aren't just making stuff up at exactly the time when you don't want them to be just making stuff up.
@accidentalciso Not sure if it helps anyone, but this is my current readiness checklist for applications.
Privileged Access Management
☐ Privileged access approvers list (group or individuals)
☐ Data access approvers list (group or individuals)
☐ Roles identified for PAM
☐ Targets identified for PAM
☐ Service accounts identified
☐ Secret inventory completed
☐ Secret rotation procedures written
☐ Access review strategy and schedule written
☐ MFA implemented
☐ Break-glass accounts created
Secure Configuration Management
☐ Unnecessary features/ports/services disabled
☐ Patch/update strategy defined
☐ Inventory added to CMDB with owners
☐ Baseline Configurations documented/exported
Detection Engineering
☐ Authentication logs sent to SIEM
☐ Administrative activity logs sent to SIEM
☐ Logging levels configured to capture security events
☐ Special IOC development
☐ Special rule development
Incident Response
☐ Determine SOAR necessity
☐ Endpoint isolation strategy
☐ Identity isolation strategy
☐ Downtime procedures documented
Incident Recovery
☐ Application operational/functional check procedure
☐ Service/system restart dependencies document
☐ Backup & Recovery test schedule
@accidentalciso Was wondering why the phone blew up. You've got reach!
Since several folks were looking at this, here's a little extra context:
When implementing a project and the vendor risk management stuff is done, this checklist is used in an early meeting with a solution owner.
We review any high-level design they have (napkins o.k.) and try to identify any planned policy violations to avoid re-work later.
We then walk through the checklist and explain what all the things are and why we are asking, so they can set space or sections aside in their documentation to build this out as they go.
Immediately prior to go-live, we validate that they have everything covered, so they can get the endorsement from the security team to close the project.
@accidentalciso That's correct. For anyone looking to implement something similar, making sure it's part of a project workflow is the important bit. Stop the bleed by ensuring new stuff is supportable.
The bit where you meet with them early and make sure they aren't making design assumptions at odds with your technical controls (like internal authentication for an app, no MFA requirement, failure to export cloud configs, etc.) is the part that saves the most wasted labor.
When you want to circle back to tech that's already in production, prioritize just as you would for BC/DR planning. Start with the critical applications for the day to day, and move on to any applications or services with SLAs or SLOs.
@nobrainnopain @accidentalciso Yeah, the consulting session is a great opportunity for a few tertiary benefits.
- 1:1 or small group environment where other tech folks can ask questions they may be embarrassed about
- Identifies issues with legacy things they own
- Boosts partnership and self-reporting...