1. You have a well-defined catalogue of the data your service holds. You know why the data is held. You understand the impact of theft or loss of integrity.
To make intelligent decisions about the design and operation of your service you need an accurate understanding of what would happen if data were lost or compromised. This knowledge will also guide your actions in the event of a breach.
Reputational damage and loss of public confidence are obvious repercussions of any incident, but more subtle second-order implications are often encountered. These could include the possibility for future attacks against your system, so it’s important to take the time to develop a full understanding of potential impact.
As your system’s requirements change, you should evaluate the necessity of the data you hold. If, in addition to knowing whatdata you hold you are clear exactly why you hold it, this process will be greatly simplified.
|
Any of the following statements are true |
All of the following statements are true |
All of the following statements are true |
|---|---|---|
|
You have limited or incomplete knowledge of the data schema You are not able to justify why all of the fields in a data set are collected You are not able to clearly articulate the impact of loss or compromise of the data |
Your data holdings are fully understood and catalogued Each field in the data set can be traced back to a strong business need You have well-articulated and communicated statements detailing the impact of loss or compromise to all or part of the data set |
Your data holdings are fully understood and catalogued Each field in the data set can be traced back to a strong business need You have well-articulated and communicated statements detailing the impact of loss or compromise to all or part of the data set You have validated these impact statements within the last 12 months |
2. You know that only necessary data is captured and held by the service. You regularly check this remains the case. Records which are no longer required are removed.
Breaches are worse than they otherwise would be when superfluous information is collected.
Sometimes the problem is simple: You’re just not removing old records when they’re no longer required. Sometimes it’s more complicated.
Here are some example scenarios to be avoided:
- Not removing partially completed applications
- Collecting unnecessary metadata relating to users
- Repeatedly collecting the same data at different stages of an interaction
- Inadvertently caching information in temporary data stores
- Recording personal data in debug logs
|
Any of the following statements are true |
All of the following statements are true |
All of the following statements are true |
|---|---|---|
|
You are unsure whether records which are no longer required are automatically purged from the system. You are unsure whether data is duplicated in caches, debug logs, backups or elsewhere. You are unsure whether partially completed records are removed routinely You have ascertained that one of the above scenarios is indeed the case. |
In the last 12 months you have audited your data holdings and processes to verify that no unnecessary data is being collected or held. |
In the last 12 months you have audited your data holdings and processes to verify that no unnecessary data is being collected or held. You have a regular review process in place to ensure that unexpected data has not been collected and that no new unmanaged copies of data have been created. Records no longer required are removed. |
3. You have an accurate understanding of unmitigated vulnerabilities present in the service and are actively managing them.
Vulnerabilities could exist in any of the technologies underpinning your service. Operating systems, networking equipment, development frameworks and software packages, all are at risk.
Tracking the versions of these, how they are configured, and cross-referencing with vulnerability notifications will help you understand your exposure to publicly known attacks. You will then need to classify and prioritise remediation according to the potential impact to your service.
Failure to mitigate these vulnerabilities will make your system easier to compromise and exacerbate the impact of any successful attack.
|
Any of the following statements are true |
All of the following statements are true |
All of the following statements are true |
|---|---|---|
|
The versions of operating systems, software packages, development frameworks and networking equipment used by your service are not known. Your level of exposure to publicly known vulnerabilities in any of these technologies is not known. Penetration tests by external testers report the same vulnerabilities year on year and no apparent action is taken. |
You have a good understanding of unmitigated vulnerabilities in your system but are unable to mitigate the majority of them within reasonable timescales. |
You understand the level of exposure of your service to publicly known vulnerabilities. Announced vulnerabilities for software packages, network equipment and operating systems used within the service are tracked, prioritised and mitigated in acceptable timescales that you have defined. You regularly use third party testing to confirm your expectations about the vulnerabilities of your system. |
PENETRATION TESTING
Penetration testing by third parties can be used to help validate the security of your service, but we advise against using it as the sole means of validation.
Penetration tests only validate that you are not vulnerable to known issues on the day of the test. And it is not uncommon for a year or more to elapse between penetration tests. If this were your only means of validation, you could be oblivious to vulnerabilities for long periods of time.
To avoid this, we recommend you establish operational management practices which keep you well-informed of vulnerabilities present in your systems. This includes subscribing to vulnerability notification feeds on the technologies you use, and by performing your own internal vulnerability scanning and testing.
You should know what the penetration testers are going to find, before they find it. Armed with a good understanding of the vulnerabilities present in your system, you can use third-party tests to verify your own expectations. Highly skilled penetration testers can then focus on finding more subtle issues within your system.
Source: NCSC
