Esta página descreve os requisitos obrigatórios da versão original do Sirtfi, o Sirtfi v1, publicado em 2015. 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/2016/01/Sirtfi-1.0.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]: São implementados mecanismos para detetar possíveis intrusões e proteger os sistemas de informação de ameaças significativas e imediatas.
O que deve ser cumprido: Ter um mecanismo capaz de detetar possíveis intrusões e proteger os sistemas de ameaças imediatas. O esforço deve focar-se nos sistemas que lidam diretamente com transações federadas.
Exemplo prático: Um mecanismo local deteta tentativas de acesso anómalas ao servidor do IdP e bloqueia-as automaticamente, ou gera um alerta para a equipa de segurança.
[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 na estrutura de confiança Sirtfi.
[IR1]: Fornecer informação de contacto de resposta a incidentes de segurança, conforme possa ser solicitada pela federação de Investigação e Ensino (I&E) a que a sua organização pertence.
O que deve ser cumprido: Publicar e manter um contacto de segurança nos metadados da federação a que a instituição pertence.
Exemplo prático: A instituição publica nos metadados da RCTSaai o contacto de segurança da equipa de TI responsável por incidentes.
[IR2]: Responder, de forma atempada, a pedidos de assistência com um incidente de segurança vindos de outras organizações participantes na estrutura de confiança 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]: Estar disposta e capaz de colaborar na gestão de um incidente de segurança com as organizações afetadas que participam na estrutura de confiança 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.
[IR4]: Seguir os procedimentos de resposta a incidentes de segurança estabelecidos para a organização.
O que deve ser cumprido: Ter procedimentos internos de resposta a incidentes documentados (mesmo que informalmente) e segui-los quando ocorre um incidente, em vez de improvisar caso a caso.
Exemplo prático: Perante um incidente, a equipa de segurança segue o procedimento interno que define os passos de contenção, investigação e comunicação.
[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 e utilizar a política de divulgação de informação Traffic Light Protocol (TLP). 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.
Responsabilidade dos Participantes (PR)
Todos os participantes (IdPs e SPs) nas federações têm de poder confiar num comportamento adequado por parte de todos.
[PR1]: O participante tem uma Política de Utilização Aceitável (AUP).
O que deve ser cumprido: Ter uma AUP formalmente definida e documentada. Não precisa de ser exclusiva para a federação, desde que cubra toda a atividade realizada nos serviços de AAI.
Exemplo prático: A instituição publica uma AUP que define regras de uso aceitável do acesso federado, aprovada pela direção de TI.
[PR2]: Existe um processo para garantir que todos os utilizadores têm conhecimento da AUP e aceitam a obrigação de a cumprir, por exemplo durante um processo de registo ou renovação.
O que deve ser cumprido: Garantir que os utilizadores realmente tomam conhecimento e aceitam a AUP, não basta esta estar publicada 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 marcar uma caixa de confirmação a aceitar a AUP antes de poder aceder aos serviços federados.
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.