A004 · PK/CYBER/Vulnerability-Management/Musical-Chairs/Are-We-Secure
The Vulnerability Musical Chairs: IS vs IT vs DevOps vs Vendor vs Management
One email said we had a problem. Then the chairs started moving.
· 10 min read · Originally published on LinkedIn ↗
In 60 seconds (yeh article kya cover karta hai)
• One fine afternoon, a client's information security team emailed us: "You have a problem." Traffic that should have been blocked by the WAF had reached the server.
• Our tech team checked. Their code had an issue, and their DevOps team had asked us to bypass the rule. We had told them so in writing at the time.
• Then came the kicker: a meeting. Twelve of them, two of us. The question was why it happened. The answer kept changing chairs.
• Developers pointed to business pressure. Infra had no staging. IS said only identify the problem. The business is what loses.
• Five habits can stop the game this quarter: Own, Prioritise, Agree, Validate, Measure. Let's discuss.
Ek email, ek screenshot
One fine afternoon, we — the service provider — got an email from a client's information security team.
"You have a problem."
Saath mein ek screenshot tha. A web application firewall, or WAF, sits in front of a server and is supposed to block the wrong kind of traffic before it gets in. This traffic had gone straight through and reached the application. Unka sawal seedha tha: yeh block kyun nahi hua?
Our tech team looked at it and came back with a simple answer. "Sir, your code had a problem. And your DevOps team asked us to bypass this rule."
Theek hai. That can happen. A rule is blocking a release, someone asks for an exception, and the exception is granted. We had it in writing from the time it was done — the date, the time, the request.
OK, fine. But then came the kicker.
"Let's call a meeting."
Phir aaya kicker: meeting
So there we were. From the vendor side, the developers, infra, the CISO and the CIO — sab baith gaye. Poor us: twelve of them, two of us, justifying why it had been done.
Management, and the CIO, opened the way these meetings usually open. "Why did this happen?"
Humne kaha, quietly, because the file was already in front of us. On this date, at this time, you asked us to do this. The WAF was blocking because of the rule. And we told you in writing, at the time.
The table turned to the developers.
"DID you ask for that?"
They didn't dodge it. "Yes sir. At that time Business put too much pressure on us. They needed it live, and we didn't have time to fix the code."
Theek. To ek seedha sawal: is it fixed now?
"No sir."
Why?
"Sir, because Infra said they need to deploy a staging environment. And they don't have the time or the resources."
WHAT.
Infra looked up. "Sir, we need to patch these things before we take these actions. This is a vulnerability, and we need to test it. Isn't that IS's job?"
IS didn't miss a beat. "Yes sir, but we just identify. It's their job to fix it."
And then the internal battle started. We were told they would get back to us.
Sounds familiar?
Many times the fault is not at the vendor's end. Most of the time, it sits with internal teams who cannot agree who will sit on the chair. In some organisations, IS and IT work together. In others, they act like rivals. Either way, jo cheez toot ti hai, woh business hoti hai.
Yeh vulnerability musical chairs hai. The finding gets passed from desk to desk, like a ball nobody wants to hold, and the argument is about who to blame. The fix does not arrive. Some of you may not agree. That's all right. But yeh us din ki reality thi, and I have seen the same game in more than one room.
"MERA 5M ka loss ho gaya!"
Ek aur scene yaad hai.
Once, a CISO blocked something from going live. The business reaction was instant: "MERA 5M ka loss ho gaya!"
The reply, from the other side of the table, was just as quick. "Bhai, abhi tak tu kuch nahi hua tha. Yeh 5 minute mein sab ho gaya?"
That's the other half of the same problem: IT and IS on one side, business on the other, and nobody speaking the same language about risk. One side sees a control. The other side sees a stopwatch. In five minutes, a delay becomes a "5M loss," and the vulnerability, once again, has no owner.
I will come back, in a later article, to how international vendors play their part in this. That's a story of its own. For today, the chairs in the room are closer to home.
Winner kaun hai?
To who is actually responsible?
Kya hota hai jab network wala systems mein aa kar kehta hai, "Sir, yeh tu yoon nahi ho sakta"? Sometimes that is genuine care. Sometimes it is just another chair being pulled away.
Aur kuch log sirf boss ko khush karne wale ban jaate hain — the yes-men in the room, who will nod at whatever the senior person wants to hear. Then the people who actually know how to fix the thing have to get approval at every step, and at every step they face resistance. Kyun? Because everyone wants to be the winner of musical chairs.
Seedhi baat yeh hai: if winning means shifting the blame, nobody wins. The vulnerability stays where it was. The business still carries the risk. And the next email will sound a lot like the last one. "You have a problem."
Paanch aadatein, is quarter
A meeting will not fix this on its own. Five small agreements will.
1. Own — Malik kaun hai?
Every system, and every exception, needs a named owner: a person, not a department. If DevOps asks for a WAF bypass, that request should already have an owner, a reason, and a date on which the bypass will be removed or the code will be fixed.
Karna kya hai: Before the next exception is granted, write down who asked, who approved, and who will close it.
2. Prioritise — Pehle kya fix ho?
A bypass that is already live is not a theoretical finding. It should not wait for a staging environment that may never arrive. For a longer list, use severity and exploitability together: CVSS for how bad it looks, CISA's Known Exploited Vulnerabilities catalog and FIRST's EPSS for whether it is already being used or likely to be, plus how exposed the asset is.
Karna kya hai: Put every live exception at the top of the list, ahead of the general scan report.
3. Agree — Waqt ki deal
"We didn't have time" is not a plan. IS, IT, DevOps, infra and, where needed, the vendor should agree in writing how long a bypass may stay, and what happens if staging, a patch or a vendor change is delayed.
Karna kya hai: One short SLA for exceptions and known fixes, signed before the next release is pushed.
4. Validate — Recheck karo
If someone says the code is not ready, or the staging environment is not there, that is a fact to be checked, not a way to end the meeting. Re-test after the bypass, and again after the fix. No evidence, no close.
Karna kya hai: Keep the original written request in the same folder as the re-test result.
5. Measure — Ek number do
Management asked why it happened. Give them one number each month: how many approved exceptions, or known fixes, are still open past the date everyone agreed. If the number is not zero, name the owner.
Karna kya hai: Put that number at the top of the next steering pack, before the heat maps.
These habits are not just a slide. In parts of the Pakistani market they are already written down. SBP's BPRD Circular No. 05 of 2017 asks financial institutions for risk-based vulnerability identification, a later validation test after assessment, and structured patch procedures. Its PSP&OD Circular No. 04 of 2025 covers payment institutions, with compliance by 31 March 2026. PTA's 7 July 2022 framework asks telecom licensees for a vulnerability-management plan, and for Critical patches to be applied and verified within 72 hours. SECP's Circular 10 of 2025 is a cyber security advisory to companies. The clocks differ by sector. The habit does not: own it, test the fix, and don't leave the chair empty.
Let's discuss
I don't pretend every organisation looks like that meeting room. Some IS and IT teams really do sit on the same side of the table. But if this sounds even a little familiar, I would like to hear it.
So, sawal aap se. Reply in the comments, sach sach:
- When a rule is bypassed "just for now", who in your organisation owns closing it? Ya woh "now" abhi tak chal raha hai?
- Has your team ever lost a fix because the approval took longer than the attack would have?
- In your last post-incident meeting, how many people came to fix, and how many came to defend their chair?
- Honestly: IS and IT in your office, same team ya Lahore Qalandars vs Karachi Kings?
- What is the most creative "it's not our job" you have heard in a meeting? Best answer gets a chai on me.
- Business ka "MERA 5M ka loss" — kabhi asal mein calculate hua, ya sirf 5 minute ki feeling thi?
Why I write like this
I am trying to help people understand the reality behind technical jargon in an easy way, so that everyone, not just the security team, can understand what actually happens. WAF, CVSS, staging, SLA: these are not magic words. They are decisions people make, or don't make, every day.
Sources
- State Bank of Pakistan, BPRD Circular No. 05 of 2017, Enterprise Technology Governance and Risk Management Framework for Financial Institutions. https://www.sbp.org.pk/bprd/2017/C5.htm | Annex: https://www.sbp.org.pk/bprd/2017/C5-Annex.pdf. Verified from the official annex PDF: section 2.3.1 (annual risk-based vulnerabilities identification); section 2.7(b)(i) (vulnerability assessment and subsequent validation test); section 3.4 (patch management procedures, including identification, categorisation, prioritisation and testing in a segregated environment).
- State Bank of Pakistan, PSP&OD Circular No. 04 of 2025, Technology Risk Management Framework for Payment Institutions, 3 October 2025, compliance by 31 March 2026. https://www.sbp.org.pk/psd/2025/C4.htm. Circular page verified; annex patch clauses not quoted.
- SECP, Circular 10 of 2025, Cyber Security Advisory, 16 May 2025. https://www.secp.gov.pk/document/cyber-security-advisory-circular-10-of-2025/. Existence and advisory character noted; exact recommended measures in the circular body not quoted.
- PTA, National Cyber Security Framework for the Telecom Sector, 7 July 2022. https://ntcert.pta.gov.pk/sops/national_cs_framework_for_telecom_07-07-2022.pdf. Verified from the official PDF: control 7.4 CL2 (vulnerability management plan shall be developed and implemented by the licensee); control 9.11 CL3 (patches for Critical vulnerabilities applied and verified within 72 hours; Critical determined in accordance with the CVSS score or internal risk scoring criteria). These controls apply to PTA licensees.
- National CERT Pakistan, Advisory NCA-11.170626, "Critical Vulnerability in Palo Alto Networks GlobalProtect (CVE-2026-0257) Actively Exploited in the Wild." https://pkcert.gov.pk/advisory/26/11.pdf. Verified from the official PDF: in-the-wild exploitation; added to CISA's Known Exploited Vulnerabilities catalog; organisations advised to apply vendor patches, implement available mitigations, and review VPN and authentication logs.
- CISA, Known Exploited Vulnerabilities Catalog. https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Verified wording: "the authoritative source of vulnerabilities that have been exploited in the wild"; "Organizations should use the KEV catalog as an input to their vulnerability management prioritization framework."
- FIRST, Common Vulnerability Scoring System (CVSS). https://www.first.org/cvss/. Verified: CVSS captures the principal characteristics of a vulnerability and produces a numerical score reflecting its severity, which can be translated into qualitative representations (such as low, medium, high and critical) to help organisations properly assess and prioritize their vulnerability management processes.
- FIRST, Exploit Prediction Scoring System (EPSS). https://www.first.org/epss/. Verified: EPSS estimates the probability that a published CVE will be exploited in the wild in the next 30 days.
About the author
I am the Founder & CEO of Server4Sale. My time as Co-Chair of Industry Engagement at P@SHA gave me a view of both the vendor side and the practitioner side. My work as Chair Cyber at FPCCI gave me insight into the concerns of CISOs, security experts and government policymakers. I don't pretend there is one answer for every organisation. I do believe we can close this gap with habits we can start this quarter, not with a project we will start next year. At Server4Sale, we are a managed service provider for website security, working with Cloudflare and many other providers, so we see this game from the vendor's chair almost every week.
This article was written with the help of AI tools for research and drafting. Every word has been reviewed, edited and approved by me. Mohammad Munaf Majeed
Quick answers
Frequently asked questions
What is 'vulnerability musical chairs'?
The finding gets passed from desk to desk, like a ball nobody wants to hold, and the argument is about who to blame. The fix does not arrive, the vulnerability stays where it was, and the business still carries the risk.
Who should own a WAF bypass or other security exception?
A named person, not a department. Every exception needs an owner, a reason, and a date on which the bypass will be removed or the code will be fixed. Before the next exception is granted, write down who asked, who approved, and who will close it.
How should vulnerabilities be prioritised?
Put every live exception at the top, ahead of the general scan report. For a longer list, use severity and exploitability together: CVSS for how bad it looks, CISA's Known Exploited Vulnerabilities catalog and FIRST's EPSS for whether it is already being used or likely to be, plus how exposed the asset is.
What are the five habits?
Own (a named owner for every system and exception), Prioritise (live exceptions first), Agree (a written SLA for how long a bypass may stay), Validate (re-test after the bypass and after the fix; no evidence, no close) and Measure (one monthly number: exceptions still open past the agreed date).
Do Pakistani regulators already expect this?
In parts of the market, yes. SBP's BPRD Circular No. 05 of 2017 asks financial institutions for risk-based vulnerability identification, validation testing and structured patch procedures, and PTA's 7 July 2022 framework asks telecom licensees to apply and verify Critical patches within 72 hours.
From LinkedIn
What people are saying
“Mohammad, since your team had the bypass request in writing, an exceptions register would have settled that meeting quickly. Each bypass gets a named owner and an expiry date, so anyone can open it and see who asked, when, and who was due to put the rule back. Having the rule…”
“One thing I would check is who approved the bypass and whether compensating controls were implemented. That evidence matters during incident reviews. Mohammad Munaf Majeed”
Selected comments from the LinkedIn post, shown as excerpts. Dates are approximate.
Read all 3 comments on LinkedIn ↗