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 will 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…

I have read Ali‘s question with a great interest, because it’s the questions like this that make you pause and think.

In my reply I suggested that the context is very important, and that we can leverage the triplet of Confidentiality, Integrity and Availability as a point of reference. If there is an intent to harm, or if the CIA triad is affected then we are dealing with malware…

Now, I don’t think it is enough.

Malware is literally short for… “malicious software”. Oxford dictionary says:
software that is specifically designed to disrupt, damage, or gain unauthorized access to a computer system.

What makes the software “malicious”? And hey… is the “software” that is a part of the definition even the same thing today as what it was few decades ago when the term was coined?

Is an exploit a piece of malware? If it is, is it at the time of writing, successful completion (when it’s available locally only, and to the author), or is it when it’s made public? Or only when used in active malicious campaigns? Is changing a configuration to enable verbose/debugging logging allowing for unauthorized data access a case of malware? Is a tool used for web mirroring of a badly configured web site allowing to download files that were not intended for public view, a malware? Is ransomware written for teaching purposes a malware? Is psexec a malware? Can an empty file be a malware? Can an antivirus file/program be a malware? Is BYOVD a malware? Is AI prompt injection a type of malware? Is Windows Explorer used to delete all files on a hard drive, a malware? Is an AI software generator that relies on code of others, and is trained on a wrong data set or its data set gets poisoned, and as a result – unintentionally producing a backdoored code, a malware?

Motive, Means and Opportunity form the so-called crime triangle. Lots of modern malware authors are criminals, because they tick these boxes. BUT while this affects the general opinion about malware authors, it does not make everyone writing a ‘questionable’ software a criminal. It also doesn’t make every ‘bad’ software – malware.

There is an argument that as long as you don’t harm others, you can do to your system whatever you want. You can change anything on the system provided you are its legitimate owner. The OS and Software EULAs may be a bit more complicated than that, but let’s put them aside here. There is simply an argument that you can write, code and produce the most destructive and malicious code ever, but as long as it stays on your system, it’s harmless to others. And then, is it even a malware at that stage? And yes, the moment you take it publicly, you have to own it. There is a responsibility associated with sharing that information.

I think the safest definition of malware is quite simple – it’s a child of malicious state transition:
any meatware, hardware, or software action that changes the state to the one that is undesirable.

It embraces context, motives, means, and opportunity, it may leverage CIA to define what that undesirable state is, and keeps the doors open for novelty and new developments…

And despite all that, I still don’t know what malware is anymore…