Take five minutes and list every security tool you sell. Next to each one, write one of two labels:<\/p>\n
Most lists come back lopsided, and the weight sits on the \u201cstops problems\u201d side.<\/p>\n
The \u201cfinds problems\u201d side is what the NIST Cybersecurity Framework<\/a> calls Identify. It covers understanding your cybersecurity risk to systems, people, assets and data, and it’s the function most MSP security stacks cover least well. Here\u2019s why that happens, and what closing the gap looks like in practice.<\/p>\n The imbalance starts as a commercial problem before it becomes a security issue.<\/p>\n \u201cProtect\u201d<\/strong> tools produce tangible results. Block counts. Quarantined attachments. Patch compliance percentages that move in the right direction month over month. All of it demos well in a sales conversation and fills a slide in a quarterly review.<\/p>\n \u201cIdentify\u201d<\/strong> work produces a document. An asset inventory is a spreadsheet. A risk assessment is a report. Neither gives a client the feeling that something was stopped on their behalf, so neither gets approved as easily.<\/p>\n The same pressure shows up inside your own operation. When a technician’s week fills up, discovery work is the first thing to slide, because nothing breaks when it slips. No ticket gets opened. No alert fires. The inventory just quietly ages.<\/p>\n The result is an MSP running a well-defended client environment that still can\u2019t answer two questions with confidence: what exactly are we protecting, and how much of it is exposed right now.<\/p>\n The NIST Cybersecurity Framework splits security work into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Identify comes second, and it asks for three things:<\/p>\n Most MSPs do the first two partially. Asset management happens once during onboarding, then decays as the environment changes. Risk assessment often means running a scan and forwarding the output. Improvement, the part that makes the other two continuous, rarely gets scheduled at all.<\/p>\n In the NIST Framework, Identify is listed before Protect. When looking at another framework, the CIS Critical Security Controls<\/a>, it makes the same point more bluntly.<\/p>\n CIS Controls organizes security into 18 controls, ordered by priority. Four of them carry most of the Identify work:<\/p>\n IG1 is the baseline implementation group that CIS says every organization should meet, regardless of its size or budget. IG3 is the tier built for organizations that employ dedicated security specialists.<\/p>\n Controls 1 and 2 sit ahead of secure configuration, account management, access control, malware defenses and every other protective measure in the set. The people who wrote the list put counting before defending, and they put it first for a reason.<\/p>\n Control 7 is the one most MSPs already satisfy. Almost everybody scans. So if inventory is covered and scanning is covered, why does the Identify side still come up thin?<\/p>\n The answer is in what a scan actually produces. A scanner gives you a list, and every item on it carries a severity score.<\/p>\n That score rates one thing: how damaging the flaw would be if somebody exploited it, judged against the software itself. It says nothing about the environment the software sits in.<\/p>\n So, two clients can carry the same finding at the same score while one is genuinely exposed and the other is not, because of network position, configuration or controls already in place that the score never sees. Same number, different risk.<\/p>\n The size of that gap is measurable. FIRST, the organization behind the Exploit Prediction Scoring System, estimates that only 2-7% of published vulnerabilities<\/a> are ever exploited in the wild.<\/p>\n For a technician, that means a severity-ranked list is a rough priority order at best, and a morning spent at the top of it may mean time spent on something nobody will ever use.<\/p>\nProtect sells, Identify doesn’t<\/h2>\n
What the Identify function actually asks for<\/h2>\n
\n
CIS puts inventory first for a reason<\/h2>\n
\n\n
\n Control<\/strong><\/td>\n What it covers<\/strong><\/td>\n Implementation group<\/strong><\/td>\n<\/tr>\n \n Control 1<\/strong><\/td>\n Inventory and control of enterprise assets<\/td>\n IG1<\/td>\n<\/tr>\n \n Control 2<\/strong><\/td>\n Inventory and control of software assets<\/td>\n IG1<\/td>\n<\/tr>\n \n Control 7<\/strong><\/td>\n Continuous vulnerability management<\/td>\n Begins at IG1<\/td>\n<\/tr>\n \n Control 18<\/strong><\/td>\n Penetration testing<\/td>\n IG3<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Scanning tells you what could be wrong, not what is<\/h2>\n
\nOur team of experts works with MSPs on building out security services, from which gaps to close first to how to package the result for clients.
\nSchedule a call with the Sherweb team \u2192<\/a><\/div>\n