“We bend so that we don’t break.” – A Yoga saying
I came across this saying earlier this week, and I thought it was very timely and appropriate when applied to cyber resilience.
During these particularly unsettling times, given adversaries are more determined than ever to breach our fortresses, careful thought and application should be given to your company’s resilience within cybersecurity.
Once entirely localized (and on-premises), most companies’ business processes now span across an ever-widening selection of components. These can include the inexorable move to public cloud for so many basic yet critical operations (e.g., email, file sharing), increasing reliance on hand-held or personal devices, third-party tooling builds a complex web of interaction (e.g., finance, sales funnel, investor relations).
The tighter the integration among these parts, the more chance that unforeseen edge cases may occur: one small failure can lead to a cascading situation of high severity.
Though the business might need tightly coupled processes, it’s essential to prepare for eventual outages. This will require many things including a deep understanding of how data flows throughout the organization, dependencies therein, and signalling available to be interpreted when a problem arises.
Much of cybersecurity analysis at its core is based on the capture and interpretation of signals generated as part of business process: metadata (“data about data”). When assessing your company’s resilience, it’s important to have both insight into the data itself and that there is sufficient signaling around the use of the data so that deviation from a healthy environment can be detected.
So much of effective incident response planning for the eventual data breach is encapsulated in the preparation stage: do we have sufficient capabilities and/or coverage (insight, defense, investigation) if some inappropriate activity occurs?
I would suggest that instead of merely using stock scenarios during cybersecurity incident response tabletops, your organization also identify critical processes within your environment and spend time assessing:
- “What are the most tightly-coupled critical processes within my organization?”
- “What would happen if <critical system> went down?”
- “What would happen if <critical component> of <critical system> was unavailable?”
- “How would we know that it wasn’t available or was malfunctioning?”
- “Who would we contact during escalation if needed?”
- “How much time would it take to move into a disaster recovery/backup situation if required?”
- “What would be the impact to the broader company if this component was unavailable?”
- “What data could be corrupted and/or lost during this outage?”
- “What would need to be reviewed upon the restoration of service?”
If you formalize this questioning and thought process, it can be detailed into the incident response playbook so that you’re better prepared if the problem arises.
It’s also important to review the key components of the security infrastructure: if you’re depending on the strength of these products you need to review their efficacy to ensure that the instrumentation and capabilities upon which you rely are operating properly (and as expected).
Netflix popularized the use of the “Chaos Monkey” – an entity that randomly terminates instances in production in order to ensure that engineers have sufficiently built and implemented their services to be resilient to instance failures.
It’s a pretty bold strategy, and I wouldn’t necessarily recommend its use within mission-critical operations. But during incident response planning and tabletops, you can mimic the mindset of the Chaos Monkey to get better instrumentation and insight into how small failures that cascade into outages can be mitigated. This in turn increases the resilience of the entire organization.
As such, we can modify the yoga saying as such: “Cyber resilience: we bend now so we don’t break later.”
