The cyber consulting world delivers a lot of useful security work. They do workshops, trainings, table top exercises, they write playbooks, red team, provide assessments, and help companies with gap analysis, system configuration and hardening.

Many of these engagements often start with some sort of a questionnaire. The customer is asked about scope of engagement, network architecture, Active Directory configuration, list of crown jewels, number of endpoints, OS/platform coverage, cloud setup, containers usage, *aaS, security controls, software, etc. The answers help consultants to tweak their deliverables to customers’ needs. They assume, rightfully so, that when they are being engaged and paid big bucks for their work, they will work with the company’s senior managements, architects, and SMEs. The company’s best.

Sometimes it is the case.

Most of the time though, there is a chaos on the other side of the fence.

I am definitely biased, but I have seen enough consulting engagements bought on a whim to conclude that many decision makers should not be responsible for spending these budgets :-). Yes, sadly, many ‘cyber leaders’ find themselves in a situation where either they need to quickly demonstrate that they are doing something useful (and hiring a consulting company is an easy OKR!), or they simply have a budget that needs to be spent. Budget either inherited from the previous leadership, or won after long battles – an asset that one cannot and should not let go. Because if you don’t spend all the money in your budget, next year you will see cuts. Not cool.

It may look like a vicious cycle, but doesn’t have to be. There is a value in these consulting gigs, but some planning needs to be done first. The number one is… documentation about your org. If you don’t have a short document that covers (on a high-level) what your company looks like from a perspective of IT/cyber, you may want to write one. This is a perfect document to share with the consulting firm when they send you their questionnaire.

The document should include:

• contact details
• one paragraph about the company, its M&As, possible tech debt and shadow IT
• one paragraph about type of data being processed (employees, customers, medical, etc.)
• list of domain names and IP ranges
• high-level overview of environments: corp network, dev network, test network, guest network, etc.
• high-level overview of regulated markets: US, UK, Germany, Australia, etc.
• estimated number of non-cloud assets, ideally broken down by platform, version, function (DC, web server, email gateways, jumpboxes, windows and linux servers, workstations, laptops, etc.)
• any dependencies on frameworks, platforms, programming languages f.ex. Java, Python
• cloud assets: provider, estimated number of systems, their longevity, security controls present ‘out of the box’, etc.
• high-level network architecture
• high-level overview of the Security function, including Triage, SOC, Forensics, Threat Hunting, Threat Intelligence, Detection Engineering, Compliance, and finally Architects, Senior Management, and CISO
• security controls in place + coverage (laptop/workstations, cloud, etc.) – firewall/WAF/proxy/AV/EDR/SIEM, etc.
• SSO/MFA: type, provider, configuration
• *aaS in use
• Security Vault in use
• Asset Inventory, SBOMs
• List of existing security policies
• etc.

Building such document is NOT easy. It’s a gargantuan task that needs to be sponsored from a CISO level.

And this is why Threat Intel should build it.

They are in the best position to write it and own it, because in the course of doing so, they will get to ‘know the org’. They have a vested interest in knowing all the possible company assets and their value. They will meet CISO, Senior Management, various teams, engineers, SMEs, Project Managers, Vulnerability Managers, SOC, etc.. They wil build important relationships. They will leverage existing asset inventories, and validate them with Threat Hunters. They will use all this data to cross-reference information from many different sources. And once they create document like this, they will be best positioned to contextualize intel gathered from TI vendors, social media, peers.

The way many TI teams are set up today is a set up destined to fail.

So, back to the consulting gigs… If you plan to engage consultants, make your TI team build a ‘know your org.docx’ first, then work with them on how best to spend this extra dollar…