I’ve seen a lot of attempts over the years at technical security assessments (TSAs, as good as any other term to describe them), both more GRC-oriented and technically-focused.
I’ve not yet seen a TSA that fits the bill fully, so in this post I’m setting out some ideas on what makes a good assessment and when it should be used.
In the approach I’m detailing here, I’m trying to set out what I feel is the optimal approach, but specific needs of a team or business unit will inevitably vary.
I’m also sharing my own template that is free to be adapted as you wish, in one of my later blog posts.
Good TSAs are in my experience essential for good security decision making in some (but not all) contexts. Their fundamental purpose is to inform security stakeholders of a significant change in circumstances or a modification to a system.
Done correctly, they become the powerhouse of security management, being carried out by specialists close to the technologies, issues and solutions.
In virtually all contexts, they are and should be written documents. The precise form, whether email or more formal document, can vary.
Some organisations do not use ad-hoc risk assessment and treatment at all. Other organisations may have a strong emphasis on the enterprise-level security documentation, but little else. Yet other organisations are weak on all fronts. Organisations of all kinds can benefit from ad-hoc assessments, regardless of whether the enterprise-level assessment is average or better.
You might ask why should we should use written risk assessments of this kind? Are we not covered by existing strategic risk assessments? The reason for this approach can be summed up in the following points:
- Enterprise or strategic risk assessments will probably not address precise technical changes and issues with adequate detail (too general argument)
- Enterprise or strategic risk assessments are much slower moving than ad-hoc projects or needs, as they require extensive review and verification (too slow argument)
- A new risk or control may be identified that the existing assessments do not cover (out of date argument)
Ad-hoc risk and impact assessment also ensures:
- A documentation trial, containing justifications for decisions and the decisions made
- An opportunity for review and consensus building
- Reduce the likelyhood of a risk materialising
- Reduce costs for the project and business
- Systematic management of risk and treatment, allowing across-the-board evaluation
- Evidence to support audit
- Recognise hazards in a specific work activity
- Enhance product or service quality
- Improve awareness and training in the team or business unit
More systematic or “long lived” risk assessments sit at many levels of a business, compared to TSAs that are usually team and activity specific. They are both related, particularly when an ad-hoc assessment requires updates or modifications to a systematic risk assessment, but TSAs are produced at pace and are detail-oriented. I’ll explore this distinction later in this blog series.
When should an ad-hoc technical risk assessment be used?
You might use one when considering:
- A system-wide change to security functionality in a service or product
- Any medium or high impact change that will affect system security or assurance
- New security components or functions (e.g. replacing a PF firewall with a NGFW)
- New security products or functionality
- Modifications to security configurations that are medium or high impact
- When security stakeholders request it (e.g. to get a good perspective to make a decision)
- When there is debate or disagreement and a consensus is required
- When a new risk is identified and/or new control is likely and it may affect an enterprise risk assessment
In my future blog posts on this series, I’ll be exploring what content we should aim for in a TSA and how we can make best use of them, so stay tuned.