{"id":15390,"date":"2021-03-22T10:00:42","date_gmt":"2021-03-22T09:00:42","guid":{"rendered":"https:\/\/www.riskinsight-wavestone.com\/?p=15390"},"modified":"2021-09-14T11:53:59","modified_gmt":"2021-09-14T10:53:59","slug":"security-accreditation-for-agile-projects-how-to-successfully-do-it","status":"publish","type":"post","link":"https:\/\/www.riskinsight-wavestone.com\/en\/2021\/03\/security-accreditation-for-agile-projects-how-to-successfully-do-it\/","title":{"rendered":"Security accreditation for Agile projects: how to successfully do it !"},"content":{"rendered":"

[nota bene<\/strong>: this article has been translated to English for accessibility reasons. It does not address UK or US regulations, but only French ones regarding Security Accreditation (\u201chomologation\u201d in French). It is nonetheless useful for any organization wanting to implement security accreditation in Agile projects.]<\/em><\/p>\n

\u201cSecurity accreditation is a formal act by which the authority responsible for a system commits its responsibility to risk management.\u201d [1]<\/a>. It is of course mandatory in some cases[2]<\/a>, but beyond that, it is also a way of sending a strong message to users and top management: security is indeed a major topic for the<\/strong> organization<\/strong>. Agile methodology was at first designed for projects, but it can be a real opportunity for security teams to reduce security risks.<\/p>\n

This method disrupted working habits of product teams and ISS teams (Information System Security). The latter have to find a way to go beyond adapting old accreditation method and propose a new relevant solution to still comply with the original goal of the accreditation: \u201cFind a balance between acceptable risk and security costs, then have it formally accepted by a manager\/an authority who has the power to do so[3]<\/a>\u201d.<\/p>\n

 <\/p>\n

One solution: provisional accreditation and long-term accreditation<\/h2>\n

As a famous Agile Security expert from Wavestone once said: \u201cAgile and accreditation, it\u2019s not rocket science\u201d. Without denying the difficulties, explaining it is quite simple. Faced with teams that must deliver faster and provide continuous releases, the risk levels and therefore the security accreditation must be dealt with at the same pace.<\/p>\n

What should the accreditation consider?<\/h3>\n

As always, security accreditation is all about giving thorough information on a project\u2019s security risk level to the Accreditation Authority, for them to decide if it\u2019s acceptable with regard to the organization ISS criteria (e.g. number of EUS still on the backlog, percentage of security baseline rules implemented on a given scope, etc.). Then, they take responsibility for the possible residual risks.<\/p>\n

For example, only a few features are available to a few users at the beginning of a project. This small scope will display a lower level of risk (because of a low level of exposure) despite not being fully secured yet. Provisional accreditation (for a few months for example) may be issued to allow experimentation. It will have to be renewed when renewal criteria (defined in advance) are met.<\/p>\n

\"\"<\/figure>\n

Figure 1 <\/em><\/strong>\u2013 Product exposure to residual risk
\nFrom the ANSSI guide (in French): Digital Agility and Security, October 2018 (<\/em>link to the guide<\/em><\/a>)<\/em><\/p>\n

For a project at cruising speed, accessible to its target audience with all the expected features, a firm accreditation (3 years for example) is pronounced. The criteria for renewal, leading to the issuance of a new accreditation, are also defined in advance.<\/p>\n

When to renew the accreditation?<\/h3>\n

The criteria used to know when to renew the accreditation are closely linked to the project, the context, or the scope, but here are some examples<\/strong> to build these criteria. The provisional accreditation is valid until:<\/p>\n