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 @wendynather I just trained ChatGPT on our slacks and now it improvises based on the ironic answers we keep giving in chat, help!
@g @accidentalciso That sounds very efficient if you ask me. Can I borrow it for ours?

@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 Essentially, I just ask application owners to have this stuff in their runbooks, not necessarily separate documents for each section, but should be "findable".
@CDubbs @accidentalciso I would also add to these, who "owns" the support contract with a vendor? Do we have named contacts? What's the phone number to call them and what are response times? If it's still on-prem software, where would we reinstall this from? Do we have any necessary license keys anywhere (these "should" be in the vault). What are the vendor's SLAs, even a hyperlink in their runbook will do.
@NoTheOtherNick @accidentalciso Totally agree. For the sake of brevity I didn't include the descriptions for each of these things, but that's under the data owner bits.
@CDubbs I hope you didnt mind me boosting that post. I'm sure it will be super helpful for others!

@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.

@CDubbs So, in essence, this checklist has been codified into your definition of done for go-live?

@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.

@CDubbs Thanks for sharing this - very timely too as we’re reviewing our application go-live processes at the moment.
@gh Let me know if you have any questions. Not all these fully apply to every internal or SaaS app, but requiring folks to say how each is not applicable is helpful.
@CDubbs @accidentalciso in IBM we had a process for that, called ‚Service Activation‘ - and a similar checklist… 🤓

@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...

@CDubbs @accidentalciso this is brilliant. Thanks heaps for sharing.
@accidentalciso but……uh……that’s how we pass audits.