Case 3 · Organisation with strict security requirements
Improving security incident detection and response
After several significant risks were identified, an organisation wanted to strengthen access, endpoints, logging and procedures, and to have an incident response it could test.
Context
Several significant risks had been identified in the environment. The organisation wanted to strengthen access, endpoints, logging and procedures, with clear responsibilities when an incident occurs.
Constraints
- Strict security requirements specific to the business.
- Several significant risks already identified, to address first.
- Measures to deploy without blocking users' work.
Scope
- Access and configurations
- Multi-factor authentication
- Detection tools on endpoints and servers
- Backups
- Incident response plan
Out of scope : External communication and notification obligations remained the client's responsibility, with support on request.
Method followed
Phases and their acceptance criteria.
Each phase ends with a verifiable criterion, agreed with the client before moving on to the next.
Phase 01
Access and configuration review
Reviewing accounts, permissions and configurations against the identified risks, and prioritising fixes.
Acceptance criterionThe review is delivered and fixes are ranked by priority with the client.
Phase 02
Stronger access
Rolling out multi-factor authentication across in-scope access, prepared by user group.
Acceptance criterionAll relevant access is protected by a second factor; exceptions are listed and justified.
Phase 03
Detection and backups
Deploying or improving detection tools, logging events and securing backups.
Acceptance criterionCritical events reach monitoring; a restore from a secured backup is tested.
Phase 04
Response plan
Formalising the plan: detection, qualification, escalation, authorised actions, reporting. Splitting roles between SKILLSYS and the client.
Acceptance criterionThe plan is approved and rehearsed; gaps found during the exercise are fixed.
Logical architecture
Detection and response chain
Generic diagram: it does not reflect the client's tools or actual architecture.
Points of attention
The risks the method had to cover.
Typical risks in this kind of project, and how the method addresses them.
Measures that get in users' way and are bypassed
Gradual rollout by group, with support and documented exceptions.
Too many alerts to handle
Every alert is qualified and thresholds are tuned so only useful ones are raised.
Backups hit at the same time as production
Secured backups and a tested restore.
Decisions stalled during an incident
Authorised actions listed in advance and a named decision-maker on the client side, with deputies.
Results
Better visibility of security events, clearer responsibilities and a response procedure that can be tested.
Deliverables
- Access and configuration review delivered
- Multi-factor authentication across all in-scope access, with documented exceptions
- Formalised and rehearsed response plan
What we would do again
- Writing down in advance who decides what during an incident saves precious time.
- A response plan only really exists once it has been rehearsed.
- Access comes first: that is where most risks sit.
This case is presented without names, figures or infrastructure details, in line with our confidentiality commitment. An introduction to the client can be arranged, only with their consent.
Go further
Your situation
A similar context?
Tell us about your environment: we will walk you through the right method, without disclosing anything about other clients.