Date: Tue, 19 Mar 2024 11:44:02 +0000 (UTC) Message-ID: <1954440566.5735.1710848642869@fra-prod-wiki03.geant.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_5734_131282371.1710848642860" ------=_Part_5734_131282371.1710848642860 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
AARC2 work can be found at AAR= C2 NA3 Task 3.1 - Operational Security and Incident Response
Sirtfi is ready for adoption! The list of Sirtfi compliant Federation Pa= rticipants can be seen on the eduGAIN Technical site by selecting "asserted= " in the Sirtfi dropdown: https://technical.edugain.o= rg/entities
Need Incident Response Now?
Ongoing Security Incident or a nasty suspicion?
Follow the Generic security incident response procedure for federati= ons, and remember to also involve your local federation. Read up at = https://aarc-project.eu/wp-content/uploads/2017/02/DNA3.2-Security-Incident= -Response-Procedure-v1.0.pdf and remember that the eduGAIN technical si= te has all the site contacts.
Although computer security incident response procedures often exist at t= he national level, they are rarely formally specified for federations and t= here is no best practice guidance for security incidents involving several = federations spreading across multiple administrative domains. Whilst R&= E federations and their underlying IdPs have a long-standing operational tr= adition, and while the organisation operating federations and IdP have deve= loped a computer security incident response capability to deal with both ac= cidental and deliberate violations of system and network security, there ar= e several challenges remaining. One is a 'lack of expressibility': there is= no common way to express to service providers and relying parties what lev= el of incident response capability is available, not its maturity level. Se= condly, there is not even a standard way defined how to contact the inciden= t response teams within a federation, IdP, or service provider. The meta-da= ta specifications - whilst providing administrative, billing, and helpdesk = contact, did not even suggest previously that a security contact would be u= seful.
This task, specifically by supporting and by worki= ng through the global group defining the Security Incident Response Trust F= ramework for federated Identity (Sirtfi), addresses these key area. Through= the works of AARC, in close collaboration with the global community and wi= th REFEDS, there is now a range of accepted practices and standards:
The Sirtfi category is registered according to RFC 6711 with the IANA LoA Profile Registry at http://www.iana.org/assignments/loa-profiles/ with URI = https://refeds.org/sirtfi
Security incident response is also an element of t= he self-assessment process started for the Assurance Profile task (TNA3.1),= and an integral part of the GEANT Data Protection Code of Conduct version = 2 draft specification. This AARC task also supports the work towards a glob= ally recognised securi= ty contact in federation meta-data as part of the Sirtfi v1.0 implementatio= n plan, which is co-supported by the GEANT Project's 'SIRTFI' task (GN4= -2-JRA3-T1), where - in collaboration with AARC - additional Sirtfi process= es and tooling are developed.
The current state of Sirtfi process implementation= , and how it works out in (simulated) security challenges, is periodically = probed through the AARC project. The first challenge was conducted i= n March 2018 (described in AARC2's 'MNA3.3'), and the report and lesson= s learned are available in the first challenge report.