Turn cybersecurity plans into working protection

Four kinds of work, and they are not versions of each other. Deploying a security platform end to end — standing it up in your own tenant, connecting the log sources, writing the detection rules and the response playbooks, testing it, and handing it over running. Configuration assessment and hardening — measuring servers, clients and network devices against a benchmark and producing a prioritised list of what to change. Firewall and network work — reviewing a rule base, redesigning the zoning model underneath it, and building the change process that stops it degrading again. And the operating model around all of it: who runs the thing afterwards, with what responsibilities, measured how. Which of the four you need depends entirely on what you already have, which is why the first step is a survey rather than a quote.

The depth is IBM and Microsoft — QRadar and Sentinel, including the parts that get skipped: custom connectors and parsers for sources with no native integration, detection content written for your environment rather than shipped defaults, automation playbooks, and keeping ingestion cost under control. Beyond that we work with Palo Alto, Fortinet and Sophos, general firewall work including rule-base consolidation, and hardening of Windows and Linux servers against CIS benchmarks. Tell us what you actually run and we will tell you plainly whether we have done it before. Sometimes the answer is no, and it is cheaper for both of us to find that out in the first meeting than in the third week.

Both, and the line is drawn in writing before anything starts, because the two are different purchases. We build and configure inside the platform being deployed, working remotely in your own subscription. What we do not do is make changes inside your other production systems: installing agents on servers, standing up log forwarders, enabling logging on third-party systems and opening the firewall rules the collection needs are your team’s to execute, with our instructions and our support alongside. Some steps we cannot take at all — the ones requiring Global Administrator or equivalent — and those are flagged in advance so somebody of yours with that right can perform them. On hardening and firewall work the separation is sharper still: the deliverable is the assessment and the proposal, your specialists execute, and we join the remediation only if you ask us to.

Three shapes. A single platform deployed into a tenant you already have is a fixed price for roughly three weeks: a week of survey and planning, a week of building and integrating, a week of testing, tuning and handover. A full SIEM and security operations build is effort-based rather than fixed, estimated by expert level, and runs to months — with your own people’s hours estimated alongside ours, because that is the number that usually surprises. Anything involving hardware runs longer again, because device lead times dominate the plan. Consistently outside the price: cloud consumption and ingestion charges, third-party licences, and operating the result after handover.

For a deployment, a running system declared ready for production use, its documentation, and a handover session for the people who will operate it. For a hardening engagement, documents by design: an assessment report, a scored table covering every device against every control group, the benchmark detail behind each finding, a proposed baseline configuration, and a short checklist you can use to assess the rest of your estate yourselves without repeating the full exercise. Turning those findings into changed configuration is a separate decision, and we would rather you took it deliberately than found it quietly bundled into a project.

Yes — and the honest version of that job treats the rule base as the symptom rather than the disease. Reviewing and consolidating the rules is the visible part. Underneath it sits the zoning model the rules are meant to express, and the change process that decides what gets added next week. We have done all three together: moving from a flat model to layered zones with a documented, approved traffic matrix, so that a rule can be judged against a model instead of against nobody’s memory. Consolidate without that and in a few years you have a tidier rule base that nobody understands, which is where you started.

Measuring what a device is actually configured to do against a published benchmark, device by device, and scoring the gaps. Three yardsticks are used together: the CIS benchmark for that exact product and version, whatever regulation applies to you, and vendor and our own recommendations — cross-referenced, so you can see which requirement each finding serves rather than taking it on trust. Control groups come back red, amber or green, with a table showing which devices sit where; red is the first round and amber is a conversation. We report percentage scores but do not let them drive the rating, because a percentage in one control group does not mean the same thing as one in another. And the goal of a first pass is not to harden everything to the maximum: it is to make configurations uniform, because uniform is what makes every change after it fast and safe.

The right question, and here is what actually happens. A finding that appears on many devices at once is treated as a possible false positive or a mass misconfiguration and checked before anyone acts on it. Changes with real breakage risk are deferred rather than recommended — restricting outbound traffic on host firewalls, for example, is worth doing only where the traffic is genuinely understood, and we will say so rather than leave it on a list for you to discover. Platform work is built and tested in a test environment before go-live, with a stabilisation period afterwards where attention stays high for tuning and faults. On firewall changes the requester tests the change, and a rule still carrying live traffic is not deleted — even with approval — until that traffic has been moved or stopped. What we will not promise on a web page is universal rollback: what makes a change reversible differs by device and by system, and it belongs in the plan for your engagement rather than in a marketing sentence.

Handover is a real end point, and continuing is a separate purchase — we would rather say that than let you assume otherwise. A deployment ends at go-live with the documentation and with training for the people who will run it; they are the reason the training exists. Larger programmes add a stabilisation period of a couple of weeks before that line, where rules and playbooks are tuned against real traffic and faults are cleared. If what you want is the running rather than the building, that is managed detection and response, and it is a separate contract on purpose rather than by accident.

Because a vendor’s team is excellent at their own product and structurally uninterested in whether it fits the rest of your estate. We have written the side-by-side comparison that argued against a product we could have sold, which is not a document a vendor writes. And the work around the tool gets the same weight as the tool: the operating model, who is responsible for what, the change process, the zoning policy, the integration with your ticketing. A security platform that ends up an island rather than part of your architecture has not really been implemented, whatever the project status says. Much of our team spent two decades on the client side of this work, which is where the preference for handing something over working rather than impressive comes from.