Esta página descreve os requisitos obrigatórios da versão mais recente do Sirtfi, o Sirtfi v2, publicado em julho de 2022. Para cada requisito indicamos o texto do requisito, o que deve ser cumprido na prática, e um exemplo. Para uma visão geral do que é o Sirtfi, a relação entre as versões v1 e v2, e como aderir, consulta a página Security Incident Response Trust Framework for Federated Identity.
Documento oficial: https://refeds.org/wp-content/uploads/2022/08/Sirtfi-v2.pdf Para dúvidas sobre a interpretação de cada requisito, consulta também o FAQ técnico oficial do Sirtfi (REFEDS).
Segurança Operacional (OS)
O objetivo da segurança operacional é gerir o acesso a recursos de informação, mantendo a sua disponibilidade e integridade, e preservando a confidencialidade de informação sensível.
[OS1]: As atualizações de segurança no sistema operativo e nas aplicações são instaladas em tempo útil.
O que deve ser cumprido: Ter um processo (mesmo informal) para aplicar atualizações de segurança dentro de um prazo razoável após o lançamento. Os patches podem vir de qualquer fonte qualificada (fabricante, comunidade open source, ou a própria organização).
Exemplo prático: A instituição aplica os patches críticos ao servidor do IdP assim que são disponibilizados.
[OS2]: Existe um procedimento para a gestão de vulnerabilidades no software utilizado pela organização.
O que deve ser cumprido: Ter um processo de gestão de vulnerabilidades que cubra tanto software de terceiros como aplicações desenvolvidas ou personalizadas internamente, incluindo deteção, priorização e correção. Este requisito existe em separado do [OS1] porque nem todas as vulnerabilidades são corrigidas por patches, e porque também cobre software mantido pela própria organização.
Exemplo prático: Além dos patches de sistemas de terceiros, a instituição mantém um registo de vulnerabilidades das suas próprias personalizações do IdP, com prazos de correção definidos consoante a gravidade.
[OS3]: Existem mecanismos na instituição para detetar e atuar sobre possíveis intrusões, utilizando informação de threat intelligence, em tempo útil.
O que deve ser cumprido: Ter um mecanismo de deteção e reação a possíveis intrusões (ex.: uma ferramenta como o CrowdSec), complementado por uma fonte externa de threat intelligence que pode ser o próprio blocklist colaborativo da ferramenta, ou uma lista de ameaças partilhada pela federação ou por um CSIRT. O esforço deve focar-se nos sistemas que lidam diretamente com transações federadas.
Exemplo prático: A instituição usa o CrowdSec no servidor do IdP, que deteta e bloqueia automaticamente tentativas de acesso suspeitas (ex.: várias tentativas de login falhadas) e complementa essa deteção local com o blocklist colaborativo de threat intelligence, partilhado entre instalações de outras organizações.
[OS4]: Os direitos de acesso de um utilizador podem ser suspensos, modificados ou encerrados em tempo útil.
O que deve ser cumprido: Ter um processo para suspender, modificar ou terminar o acesso de um utilizador; o tempo de resposta deve ser proporcional à gravidade da situação, já que o Sirtfi não define um prazo fixo.
Exemplo prático: Perante a deteção de uma conta comprometida, a equipa de segurança suspende o acesso de imediato, sem depender de aprovações prévias demoradas. O mesmo processo é usado quando um utilizador deixa de ter vínculo com a instituição.
[OS5]: Os utilizadores e os Gestores de Serviço (conforme definido pela ITIL) dentro da organização podem ser contactados.
O que deve ser cumprido: Manter dados de contacto válidos e atualizados de utilizadores e dos responsáveis por cada serviço.
Exemplo prático: O diretório institucional mantém emails válidos de todos os utilizadores, e existe uma lista atualizada de quem é responsável por cada serviço crítico.
[OS6]: Existe, dentro da organização, uma capacidade de resposta a incidentes de segurança com autoridade suficiente para mitigar, conter a propagação e remediar os efeitos de um incidente de segurança.
O que deve ser cumprido: Ter uma equipa ou função com poder real para agir, por exemplo, desligar um sistema comprometido sem esperar semanas por aprovação de gestão. O Sirtfi não exige documentação formal desta capacidade, mas é recomendável documentá-la em políticas e procedimentos.
Exemplo prático: A equipa de segurança da informação pode isolar um servidor da rede imediatamente perante suspeita de compromisso, reportando a decisão à gestão depois de agir.
Capacidade de Resposta a Incidentes (IR)
A afirmação [OS6] acima pressupõe que existe, dentro da organização, uma capacidade de resposta a incidentes de segurança. As afirmações desta secção descrevem as suas interações com outras organizações participantes no Sirtfi, e destinam-se a complementar, e não substituir, os procedimentos internos de resposta a incidentes já existentes na organização.
[IR1]: Fornecer informação de contacto de resposta a incidentes de segurança, conforme possa ser solicitada por qualquer federação a que a organização pertença.
O que deve ser cumprido: Publicar e manter um contacto de segurança nos metadados, preparado para responder a pedidos de todas as federações a que a organização pertença.
Exemplo prático: A organização participa na RCTS e no eduGAIN; o contacto de segurança nos metadados é válido para pedidos vindos de qualquer uma delas.
[IR2]: Responder, de forma atempada, a pedidos de assistência com um incidente de segurança vindos de outras organizações participantes no Sirtfi.
O que deve ser cumprido: Ter um compromisso interno de resposta a pedidos externos, num prazo proporcional à gravidade do incidente (o Sirtfi não define um prazo fixo).
Exemplo prático: Um serviço federado de outra instituição relata uso indevido por parte de um utilizador que se autenticou através da nossa instituição; a equipa confirma a receção do pedido e investiga a conta em causa.
[IR3]: Notificar os contactos de segurança de entidades participantes no Sirtfi sempre que uma investigação de um incidente sugerir que essas entidades estão envolvidas. Esta notificação deve também seguir os procedimentos de segurança de quaisquer federações a que a organização pertença.
O que deve ser cumprido: Ser proativo: se a investigação sugerir que outra organização está implicada, é obrigatório avisá-la, mesmo que ela não tenha pedido nada.
Exemplo prático: Ao investigar um posto de trabalho infetado com malware, a equipa descobre que o mesmo dispositivo foi usado para aceder a um serviço federado de outra instituição, e notifica essa instituição de imediato, mesmo sem esta ter detetado o problema.
[IR4]: Estar disposta e capaz de colaborar na gestão de um incidente de segurança com as organizações afetadas que participam no Sirtfi.
O que deve ser cumprido: Participar ativamente em esforços conjuntos de investigação (partilha de informação relevante, reuniões de coordenação), não apenas responder de forma passiva.
Exemplo prático: Perante um incidente que afeta várias instituições, a organização participa numa reunião de coordenação e partilha as evidências técnicas que identificou, como endereços IP maliciosos, hashes de ficheiros ou domínios suspeitos.
[IR5]: Respeitar a privacidade do utilizador, conforme determinado pelas políticas da organização ou pelo aconselhamento jurídico.
O que deve ser cumprido: Ao partilhar informação durante um incidente, não expor dados pessoais além do estritamente necessário.
Exemplo prático: Ao reportar um incidente a outra instituição, a equipa partilha apenas os dados técnicos estritamente necessários (ex.: endereço IP e horário da atividade suspeita), sem identificar o utilizador pelo nome.
[IR6]: Respeitar a política de divulgação de informação Traffic Light Protocol (TLP) e utilizá-la durante as comunicações de resposta a incidentes com participantes da federação. Para mais informação sobre o TLP, visita https://www.first.org/tlp/
O que deve ser cumprido: Classificar a informação partilhada com etiquetas TLP e respeitar as regras de cada uma ao reencaminhar essa informação.
Exemplo prático: A organização recebe um alerta marcado "TLP:AMBER" de outra instituição e partilha-o apenas internamente com a equipa de segurança, sem o publicar.
Rastreabilidade (TR)
Para poder responder às perguntas básicas "quem, o quê, onde e quando" relativamente a um incidente de segurança, é necessário reter informação gerada pelos sistemas durante um período de tempo, incluindo timestamps precisos e identificadores de componentes do sistema e de intervenientes.
[TR1]: Informação relevante gerada pelo sistema, incluindo timestamps precisos e identificadores de componentes do sistema e de intervenientes, é retida e disponibilizada para uso nos procedimentos de resposta a incidentes de segurança.
O que deve ser cumprido: Manter logs de autenticação e acesso (quem, quando, de onde) com timestamps fiáveis, garantindo que só o pessoal relevante tem acesso a esses logs durante uma investigação. Se a instituição usar identificadores opacos (ex.: eduPersonTargetID, Subject-ID, Pairwise-ID), deve conseguir associar esse identificador a um utilizador concreto através dos seus logs internos ou de outros repositórios, para efeitos de investigação de um incidente.
Exemplo prático: Os logs de autenticação do IdP registam o endereço IP do cliente remoto e ficam disponíveis apenas à equipa de segurança durante uma investigação.
Exemplo prático (identificadores opacos): Quando um serviço reporta atividade suspeita associada a um Pairwise-ID, a equipa consegue localizar, através dos logs internos do IdP, a que conta de utilizador esse identificador corresponde.
logback.xml para um IdP Shibboleth com syslog central) em wiki.refeds.org/display/SIRTFI/FAQs.[TR2]: A informação referida em [TR1] é retida em conformidade com a política ou práticas de resposta a incidentes de segurança da organização.
O que deve ser cumprido: Ter uma política escrita, mesmo curta, que defina prazos de retenção de logs, e cumpri-la de forma consistente.
Exemplo prático: A política interna define retenção de logs de autenticação por um ano, alinhada com o procedimento de resposta a incidentes da instituição.
Regras e Condições de Utilização (UR)
Os Fornecedores de Identidade e os Fornecedores de Serviços (participantes) têm a responsabilidade de notificar os utilizadores de que o seu acesso pode ser controlado na sequência de um uso não autorizado, nomeadamente durante um incidente de segurança. Isto pode ser feito diretamente pelo participante ou por um terceiro, no caso de a operação de um sistema ter sido delegada.
[UR1]: O participante tem regras e condições de utilização definidas para os serviços relevantes de AAI (por exemplo, uma Política de Utilização Aceitável, termos de serviço, ou outro acordo).
O que deve ser cumprido: Ter documentado, nalgum formato, o que é considerado uso aceitável dos sistemas e serviços. Não precisam de ser regras específicas para a federação, desde que cubram toda a atividade realizada nos serviços de AAI.
Exemplo prático: A instituição tem um "Regulamento de Uso dos Sistemas de Informação" publicado, que define claramente o que os utilizadores podem e não podem fazer.
[UR2]: Existe um processo na organização que garante que todos os utilizadores têm conhecimento destas regras e condições de utilização, e que aceitam os respetivos termos (ex.: durante o processo de registo ou renovação).
O que deve ser cumprido: Garantir que os utilizadores realmente tomam conhecimento e aceitam essas regras, não basta estarem publicadas nalgum sítio pouco visível. Esta aceitação não precisa de ser feita através de um mecanismo específico do IdP: pode ser feita diretamente com o utilizador ou através de um terceiro, caso a operação do sistema tenha sido delegada.
Exemplo prático: No registo de uma nova conta institucional, o utilizador tem de aceitar explicitamente o regulamento (ex.: marcar uma caixa de confirmação) antes de poder aceder aos serviços; a aceitação é reforçada em renovações anuais.
Exemplo prático (alternativo): Para funcionários, a aceitação das regras de uso é feita através do contrato de trabalho, que cobre o uso aceitável dos sistemas de informação da instituição, incluindo os serviços federados; para outros utilizadores (ex.: estudantes), a aceitação é feita no registo da conta.
Certificação e Metadados
A adesão ao Sirtfi v2 é registada nos metadados da entidade através do atributo https://refeds.org/sirtfi2, que deve estar sempre acompanhado do atributo https://refeds.org/sirtfi (Sirtfi v1), já que a conformidade com o v2 implica a conformidade com o v1.
É também obrigatório publicar nos metadados um contacto de segurança, de acordo com as regras definidas em Choosing a Sirtfi Contact.