Jim Collins wrote a great little book called Turning the Flywheel to further develop an idea introduced in his book Good to Great to describe how various parts of a business model can be mutually reinforcing.
Most businesses from start-ups to major corporations have built or attempted to kick start their own flywheels. These flywheels operate for their business overall or individual products, to propel growth, cross-sell or otherwise amplify the economies of scale of their operations. Let’s explore the flywheel concept and how we might use it to amplify the effects of our security programs.
Getting a physical flywheel going requires a huge effort at first, but once going you can make it go progressively faster and faster aided by its own momentum using the same amount of force. Applied to business situations this is about putting in place a chain of complementary activities that feedforward on each other, mutually reinforcing, to increase the desired outcomes. Once going it becomes hard to stop - as long as you keep all the forces aligned. The classic example, from the book, is the Amazon.com flywheel where having lower prices attracts customers, which in turn attracts sellers, which drives economies of scale meaning they can expand revenue while keeping fixed costs low and thus deliver lower prices on more offerings. This quickly gets its own momentum.
You see similar effects in other industries, like what Vanguard did for low cost mutual funds.
The key insight is that, like a real flywheel, each step needs to propel the next. In the example above, having lower cost funds means customer returns are higher (assuming Vanguard are competent index trackers, as they are) because more of their investment can compound without being eaten by fees. This in turn means more loyal (and additionally new) clients which leads to the growth of assets under management, which leads to economies of scale which keeps or further lowers fees. And so on.
So what might be some security program flywheels? (Note: each one of these examples is just illustrative of the flywheel concept and not a full development of the topic, which could be their own blog posts entirely).
1.Raise the Baseline by Reducing the Cost of Control
Make the deployment of, even advanced, controls more pervasive. Not by sheer will or ever-increasing budgets but by effective control (re-)engineering to reduce the total unit cost of ownership of controls so more controls can be implemented per fixed budget. Expressed another way: grow control deployment super-linearly for sub-linear budget growth.
Design Controls. Use your budget to build / design controls for your current risk mitigation goals. Some, perhaps at first many, of these controls might be expensive, hard to maintain or otherwise operationally costly, but are still necessary even if their deployment can only be on the most critical systems.
Implement Controls on Next (then Broader) Prioritized Systems. Implement the controls on the systems in scope according to criticality or other ordering means e.g. sometimes the most prevalent/connected systems are appropriate for initial broad deployment to kick-start onboarding in other areas that might be most difficult/costly.
Reduce the Cost of Controls. For every control, constantly look at the total cost of ownership of that control. This needs a very broad lens to include software, hardware, licenses, operational costs, end user / IT costs, opportunity costs, performance or productivity impacts and so on. Then look for (using 80/20 analysis typically) the means to reduce the cost of that control. This might mean buying a different product or service, re-engineering your deployment approach, tuning or even reconceptualizing the underlying policy the control is seeking to enforce.
Capture / Recycle Cost Savings. Then redeploy or otherwise upgrade the control and capture the cost savings. This might be easier said than done depending on your IT or other funding / cost allocation processes. Even if you can’t directly capture the savings then keeping a record of your ever increasing efficient use of budget - that enables broader control deployment with less toil or unintended impact - evidence that you are a good custodian of resources. As a result you are more likely to receive budget increases even if notional cost savings remain more “accounting” than truly crystalized.
Industrialize / Embed Controls. Embed the optimized controls into your default IT, business or mission systems architecture so that they are intrinsically intertwined with how everything is delivered at scale. Once sufficiently embedded many of the controls can move out of the security team’s portfolio and then can further free up costs to recycle into further control efficiency improvements. And so the flywheel turns.
2.Threat Intelligence
Create a threat-led approach across the enterprise by kick-starting the use of threat intelligence and then shift to demand-pull for intelligence from internal consumers vs. a constant push from the security team.
Produce Scoped Threat Intelligence. Develop threat intelligence according to initial scoping decided by the security team, and then as the flywheel progresses expand scope according to demand drivers. The initial focus, of course, can be best scoped to collect on threats facing the organization’s most critical assets, services, or missions.
Educate the Organization. Educate leaders and other levels of the organization on the likeliest threats their businesses and customers face and how they are positioned against this. This should include additional intelligence around what other organizations are facing and learning from those same threats. Progressively embed the consumption and use of intelligence into the business processes of other teams, not just the security team.
Seed then Respond to Demand. Create, as part of the intelligence processes, hooks for the wider organization to ask questions, request more targeted intelligence or other assessments. This could even be working on other complementary approaches like scenario planning and the development of Indications and Warnings. There will likely be demand for more information and more targeted intelligence, but it is beneficial to explicitly create that demand channel.
Drive Tactical Response and Security Architecture. Partner with other parts of the security team, the business and IT areas and (if they exist) their embedded security or risk teams to re-validate positioning against threats. This could be focused hunts, incident learning, near miss analysis, and proposal of new controls or security architecture that aims to defeat whole classes of current threats/attacks as well as aiming to get ahead of the threat with new security programs.
Industrialize Intelligence Production. Capture positive results from the use of threat intelligence to amplify ideas for increased scope. Invest in better systems, in quick response to increased demand, to expand intelligence collection, development, analysis and production at scale for continuously reduced cost (a variant of the prior flywheel). Use this scaling to increase scope. And so the flywheel turns.
3.From Inventories to Digital Twins
Develop ever more accurate and fine grained inventories of all enterprise assets and configuration. Amplify use, demonstrate value, triangulate different repositories and channel cost savings. Move towards having, in effect, a “digital twin” of your environment that can be policy modeled and enforced and continuously assessed using your controls and control monitoring.
Scan Reality / Build Inventory. Build an inventory (of progressively expanding asset scope e.g. start with hardware and software and then cover all assets over time) through scans and pulls from other repositories.
Set Policy / Reveal Surprise. Develop a set of policies, rules or other rubrics that can be used to reveal potential surprises that people will want to respond to. For example: underutilized infrastructure (internal or cloud), software that is never used, assets for one business deployed in infrastructure reserved for other purposes, stagnant (unmaintained) assets, high asset (re-)turnover.
Capture Value. Take action to free up / release assets or redeploy to save money. Realize savings from asset efficiency improvement and capture at least some of that value back into the inventory program to further build / expand capability to reveal more issues.
Triangulate. Deliberately inter-connect inventories (or more precisely sub-inventories) to reconcile across different domains. Think of this like financial reconciliation across ledgers and subledgers. For example, link a third party services/software inventory with both an application inventory and a data governance catalog (i.e. a data inventory). This link might reveal a vendor service that exists that notionally consumes no data, or a data set consumed by no applications. Such triangulation problems may not reveal real issues but may point to an inventory collection / accuracy problem that when resolved may reveal some other policy violation or other surprise that needs addressing.
Industrialize Intent. Use these discoveries and linkages to create capabilities and rule sets in managed configurations (controls-as-code, policy-as-code, etc.). Then your inventory approach progressively becomes more about specifying what reality should be to then monitor conformance to that expectation (defining and managing a digital twin of your environment). As this develops then inventory scope can be broadened, issues more easily identified from triangulation (network effect of inventory connection) and more value captured. And so the flywheel turns.
Incidentally, this is one area where the “uncanny valley” can be quite harsh. Creating an initial inventory where people didn’t think there was a problem is an example of you appearing to make a problem worse. So, plan to cross the valley quickly and pre-communicate to sponsors that bad stuff will be found - there’s never been an inventory exercise of anything that didn’t bring all sorts of surprises. That’s the point.
4.Detection and Response / Red Teaming
Constantly improve detection and response capability by increasingly intense, threat adjusted, red team testing.
Establish / Expand Sensory Coverage. Establish baseline sensory coverage prioritized according to coverage of critical services/assets.
Threat Intelligence Overlay. Use current strategic threat intelligence assessments to illustrate potential gaps in relation to likeliest threat targeting - either in sensory response or sensory capabilities.
Conduct Red Team Tests. Formalize, as part of Red Team exercises, explicit testing of detection and response ability to detect and possibly interdict Red Team activities.
Assess Shortfalls. Examine shortfalls in current capabilities vs. gaps exposed by threat intelligence assessments and deficiencies highlighted in Red Team exercises.
Identify New Capabilities. From these shortfalls identify / budget for additional sensory capabilities and then from that identify new intelligence collection needs and plan Red Team exercises to further test that. And so the flywheel turns.
5.Adjacent Benefits Risk Assessment Cycle
Create and sustain a security investment cycle by identifying and exploiting adjacent business benefits of controls (re-)engineering. Keep risk posture flat (if in good shape) but still change/improve controls to deliver those adjacent commercial benefits.
Conduct Risk and Control Assessments. Conduct your regular risk and control assessments (automated, systematic or self-assessments). In cases where it’s ok to keep risk at the same level then identify in some prioritized way (scope of control, customer facing controls, etc.) which controls are ripe for improvement - for purposes beyond risk reduction.
Identify Control Re-engineering Opportunities. Identify means to change controls to reduce cost, friction, or to deliver other adjacent commercial benefits while keeping risk flat.
Crystallize Benefits. Capture the commercial results of those control improvements in some way, either literal cost recouping or simply a record of the outcomes. If there are genuine cost reductions then recycle those into further work / or funding to fuel further control re-engineering.
Create Demand. Use the illustrations of the benefits derived, within business units, to create demand for business leader sponsorship of other control reengineering efforts.
Broaden Risk and Control Assessments. Use this as impetus to broaden risk and control assessment scope into other areas, given the new positive perception of control assessments which in turn will increase scope of controls to reengineer. And so the flywheel turns.
6.Continuous Control Monitoring
Create and constantly expand the universe of people and processes that are invested in the sustainment of effective controls.
Increase Continuously Monitored Controls. Expand the universe of controls under continuous monitoring (for completeness and effectiveness).
Respond to Control Incidents. Remediate any control deployment and effectiveness problems identified. Treat such control breaks as first-class incidents alongside actual high priority security incidents. In other words, fix the control incidents before they become actual security incidents.
Apply Lessons Learnt - Broadly. Apply the lessons learnt from the post mortems of such control breaks more broadly to preempt similar issues in other areas - either other control instances or totally different controls that might exhibit similar potential issues. Such “Control Reliability Engineering” approaches can create demand for more control monitoring.
Identify Efficiencies. Use the newly broadened perspective on relative control performance, interaction and deployment scale to identify efficiencies / cost savings opportunities e.g. control rationalization.
Improve Control Performance. Reinvest those savings, or new budget from the demand created by the transparency of finding issues in broader control performance to create an even more expansive view of controls monitored. And so the flywheel turns.
7.Federated Security Teams - Pull not Push
Create an environment where business units / product areas / departments pull help from the security team rather than it solely being the security team pushing activities into those teams.
Seed / Expand Federated Teams. Expand Federated/embedded teams insider business units.
Devolve Risk / Security Assessment and Goals. Devolve risk assessment / security integration and other activities into those embedded teams.
Increase Central Security Team’s Services. Set up services from the central security teams to support those embedded teams. This is to create pull from those teams to supplant the more typical push from central security teams into business units for any needed security upgrades.
Increase Skills / Capabilities of Federated Teams. Partner with embedded teams to increase capabilities e.g. skills, connectedness, resources, team size etc.
Identify and Communicate Results. Capture the improved results, communicate broadly across business units - especially any commercial benefits derived from the work. Use that to create business unit demand for more support and for other business units to replicate activities of each other’s embedded teams. And so the flywheel continues.
_________________________________________________________________
Finally, it’s no big reveal that each of these flywheels can become part of an overall security program flywheel as follows:
Bottom line: there are many useful business / operations concepts that can be applied to security. Of many, I’ve always found flywheel effects particularly useful. Even if it’s not perfectly applicable it can provide some useful impetus to take the load off security teams to have to continuously intervene or otherwise keep security processes and attention at the right level.