Skip to content ↓ | Skip to navigation ↓

This week at the CSO Confab, I was listening to a presentation by Phil Agcaoili (@HackSec), the CISO for Cox Communications.  During his talk, Phil asked a thought-provoking question: “What does your business do that can affect or impact other businesses?”

That question got me thinking about relationships in our information security world, and the potential, (mostly negative) unexpected consequences if we don’t understand those relationships.

Ripples in a Pond

If you’ve been reading my articles here on The State of Security, you know I talk a lot about “connecting security to the business,” which I’ve been describing as establishing and communicating how your actions, policies, and the corporate resources you protect are related to the Goal of your organization.  This is still valid, as it helps us prioritize our investments to enable the business, and gives us the tools to map the shape of our security investment so that it matches the shape of our risk.

The “a-ha!” I got from Phil’s question is that we need to take this one step further, and connect security to the businesses we depend on and those who depend on us.

For example, if you tighten up your security policies, will it have a negative impact on your outside business partners’ ability to do business?  Will it disrupt a workflow or supply chain, or violate a contractual commitment?  Every change we make in our policies, actions, etc. radiate out to all the entities we interact with like ripples in a pond when you toss a rock into the water.

Loosening our policies or discontinuing security projects can have unexpected consequences, as well.  What if your loosened policy causes one of your business partners or upstream providers to become non-compliant, either with their own policies, or regulatory requirements?

Map it Out and Understand the Impact

My recommendation is to build on what we’ve already been doing to connect security to the business:  The asset relationship maps we build for things like application diagrams, workflows, service diagrams, and architectural diagrams.  Start with those, and extend it to include the systems and processes you hook into so you can begin to understand the larger ecosystem.

In other words, when you’re trying to connect security, make sure you zoom out and understand your impact on others’ businesses.

For many of you, this may be old hat.  If so, and you have a good approach to share to ensure you have a useful view of these dependencies, I’d love to hear how you are doing that – please drop me a line or leave a comment here and share your learnings.  In particular, if you have a good model that enables you to engage with your business partners and move in sync with them, I really want to hear your story.

 

Image courtesy of ShutterStock