New control set DigiD
Article published in SecurAware October 2017 - Insight - by Bjorn van der Schaaf, Senior IT Auditor
The DigiD assessment scheme was introduced in 2012 by Logius for systems and applications that use the Dutch national authentication mechanism. The assessment scheme contained a number of controls based on the ICT-security guidelines published by the Dutch National Cyber Security Centre (NCSC).
The NCSC has updated their guidelines in the meantime and this has led to the situation that the DigiD controls were not in sync with the NCSC guidelines. Additionally, assessors have been critical about the actual controls selected and the varying level of technical detail, auditability and sensibility of the controls.
Therefore Logius has introduced a new set of controls that has gone into effect on 21 november 2017, and be applicable to all DigiD-connected applications. The professional organisation of IT-auditors in the Netherlands, the NOREA, has issued an updated audit guide for their members who perform such DigiD assessments.
Just as in the first version of the control set, the second version is based on the NCSC guidelines. However the actual selection differs somewhat. Some subjects get a little more attention, others less. This is motivated by a change in risk areas and a wish to lighten the burden of the audits.
The new control set focuses more on themes such as:
- Logging and monitoring
- Secure programming
- Incident detection and response
On the surface, the controls look quite different than previously; this is due to the new numbering scheme that the NCSC has introduced, and the categorizing of controls along so-called ‘domains’:
- Policy (B)
- Execution: Access control (U/TV)
- Execution: Web application (U/WA)
- Execution: Platform & Webserver (U/PW)
- Execution: Network (U/NW)
- Management / 'Control' (C)
What has changed?
The new control set has 20 controls divided over the six domains, while the old set had 28 controls. Some controls have been completely dropped, other have been combined. In general, the abstraction level of the controls has been made more consistent.
Because some controls have been combined, and new ones based on the new NCSC guidelines, the individual controls cover more ground than the old controls. In fact, when relating the new 20 controls, they can be related to 38 old controls from the NCSC guidelines instead of 28!
The owner of the DigiD connection will need more attention for several subjects in order to pass the audit. Where relevant, additional measures must be implemented at vendors (software, hosting, application, SaaS, etc.).
1. Logging and monitoring coupled with incident detection and response
Controls dealing with implementation and use of IDS/IPS systems get more focus in the new situation. Logging and monitoring are connected to this. Questions organisations should ask themselves are: will data traffic anomalies be detected? What if logging patterns start to change? How much time does it take to detect that and what are you going to do? Does logging and monitoring cover the full stack (network, OS, and application)?
Simply sitting back and waiting for the result of the penetration test is not a guarantee for a successful audit
2. Secure Programming
Important controls deal with with input and output validation of the application. Building a secure application will need to have controls in the secure programming realm, and attention is necessary for development, test and production environments. Controls that protect against the OWASP top 10 classes of vulnerabilities must at least be in place. Source code reviews can be used for this but that is not mandatory. By adopting secure software development frameworks and automated testing it can also be assessed by the organisation that they comply. Simply sitting back and waiting for the result of the penetration test is not a guarantee for a successful audit.
So should be throw all documentation from previous years away? Absolutely not! Documents and evidence from previous years can be changed to follow the new numbering with relative ease. However it will be necessary to perform a self-assessment or gapanalysis to find out what documentation is missing with regard to the previous version.
The role of the penetration test
The penetration test in mentioned in several ways in the standard:
- From a process standpoint
- The results of the tests
- Coverage of the controls
From a process standpoint, the management controls state that the DigiD web application, the server, and also other servers in the same DMZ as a the DigiD application, must be tested periodically (at least yearly), AND when there is a specific reason to do so (usually interpreted as a major change being implemented). The NOREA guide also states that the penetration test should take place in the time frame of the audit. Secondly, test results (findings) must lead to actions and these actions must be monitored to ensure progress. The penetration test is mentioned in several controls as a means to (partially) cover these controls.
The new standard v2.0 does not deviate hugely from the previous norm, as a first glance at the numbering system might imply. But it’s also not simply a case of renumbering the old norms. The focus on a number of domains and the rewritten NCSC controls do mean that organisations are advised to:
- Study the formulations of the new controls and the new guidelines from the NOREA.
- Give attention to the domains dealing with secure programming, logging and monitoring and incident detection/response.
- Map existing documents, processes and evidence to the new control set.
- Perform a gap analysis to the new control set well before the actual audit is performed.
- Implement additional measures based on the gap analysis.
- Make sure that penetration tests, TPM-reports, ISAE3402- reports etc. are in line with the new control set.