Abuso da Gestão de Exceções

O programa de governança de segurança de uma empresa de tecnologia incluía um processo formal de gestão de exceções: um fluxo estruturado para solicitar, revisar e aprovar exceções aos requisitos da linha de base de segurança. O processo havia sido desenhado com o rigor adequado: as exceções exigiam uma justificativa de negócio documentada, uma avaliação de risco que confirmasse que o risco residual era aceitável, um prazo com revisão obrigatória e uma autoridade aprovadora no nível do CISO. Durante uma revisão do programa de segurança, um analista examinou o registro de exceções e encontrou quarenta e uma exceções ativas, das quais trinta e sete eram de MFA em contas de acesso administrativo. A justificativa de negócio de todas as trinta e sete era uma variação de “a implementação de MFA neste sistema exige trabalho de engenharia que não foi agendado”. Os prazos das exceções variavam de três a doze meses, mas quatro haviam sido aprovadas, expirado, sido reaprovadas e estavam agora em seu segundo ou terceiro ciclo anual. O processo de exceções funcionava corretamente: cada exceção tinha uma justificativa de negócio, uma avaliação de risco, um prazo e a aprovação do CISO. As exceções não estavam sendo usadas para restrições operacionais genuínas. Estavam sendo usadas para adiar trabalho de engenharia inconveniente de agendar. O processo de exceções havia se tornado o caminho de menor resistência para evitar a linha de base de segurança.

O que é, de fato, o abuso da gestão de exceções?

A gestão de exceções é o mecanismo de governança para reconhecer que circunstâncias operacionais específicas criam restrições genuínas que impedem a implementação de um requisito da linha de base de segurança e para gerenciar formalmente essas situações com controles compensatórios, aceitação documentada do risco residual e prazos definidos para resolver a restrição ou aceitá-la formalmente como uma limitação permanente. Ela existe para lidar com a complexidade real da implementação de segurança: sistemas legados com limitações de autenticação, ferramentas gerenciadas por fornecedores que não podem ser configuradas para atender a todos os requisitos da linha de base e cenários operacionais em que a imposição estrita da linha de base criaria um risco operacional inaceitável.

O abuso ocorre quando o processo de exceções é usado não para lidar com restrições genuínas, mas para adiar implementações tecnicamente viáveis, porém inconvenientes para a organização, ou seja, quando o verdadeiro motivo da exceção são prioridades de engenharia concorrentes, escassez de recursos ou relutância da gestão em priorizar o trabalho de implementação, e não uma restrição técnica ou operacional genuína. Uma exceção de MFA em um sistema de autenticação legado que, por sua arquitetura, não suporta métodos modernos de autenticação é uma exceção por restrição genuína. Uma exceção de MFA em um sistema moderno, cuja implementação exige uma sprint de trabalho de engenharia que não foi agendada, é uma exceção de adiamento: usa o processo de exceções para contornar um requisito da linha de base que é difícil de cumprir, e não genuinamente impossível de cumprir.

O problema da normalização é o que transforma o abuso de exceções individuais em erosão sistemática da linha de base. Quando várias equipes observam que o processo de exceções produz adiamentos aprovados para implementações tecnicamente viáveis, porém inconvenientes, a exceção se torna o caminho esperado para requisitos difíceis de cumprir no prazo. As equipes de engenharia aprendem que solicitar uma exceção é mais rápido do que implementar o controle. O registro de exceções se enche de adiamentos. A linha de base existe como padrão documentado. A taxa de implementação reflete os requisitos que eram fáceis de cumprir sem exceções. O processo de exceções não falhou: ele foi aprendido e explorado.

Exceções de adiamento: implementações tecnicamente viáveis adiadas por meio do processo de exceções
Registro de exceções preenchido com adiamentos de engenharia: padrão da mesma justificativa em várias exceções
Exceções recorrentes: as mesmas exceções reaprovadas em vários ciclos sem correção
Erosão da linha de base: queda no percentual de sistemas no escopo que de fato atendem aos requisitos da linha de base
Processo de exceções normalizado como alternativa à implementação de requisitos inconvenientes

Por que isso importa

O abuso da gestão de exceções é importante para TPRM porque as linhas de base de segurança dos fornecedores confirmadas por questionários podem ter registros de exceções extensos que excluem sistematicamente partes significativas do ambiente dos requisitos da linha de base. Um fornecedor cuja linha de base de segurança exige MFA para todo acesso administrativo e que tem trinta e sete exceções ativas de adiamento de MFA tem uma linha de base que se aplica a algumas contas administrativas. A confirmação no questionário de que a MFA é exigida pela política é precisa. A realidade operacional de quantas contas administrativas estão de fato protegidas por MFA pode ser significativamente mais restrita.

O padrão de exceções recorrentes é o sinal específico que o abuso de exceções produz. Uma exceção concedida com prazo de seis meses, renovada, concedida novamente e agora em seu terceiro ciclo de aprovação tornou-se, na prática, uma exceção permanente por repetição processual, e não por aceitação formal. Cada renovação foi aprovada com a expectativa de que a implementação ocorreria no ciclo seguinte. Dois ou três ciclos depois, a implementação não ocorreu e a exceção tornou-se uma exclusão permanente de fato da linha de base. Identificar exceções recorrentes no registro de exceções de um fornecedor revela as implementações que foram sistematicamente adiadas por meio do mecanismo de exceções.

Onde a maioria das equipes erra

A falha mais recorrente é aceitar a contagem do registro de exceções e a qualidade formal do processo como evidência de uma governança de exceções sólida, sem revisar as justificativas e os padrões de recorrência das exceções. Um processo de exceções bem governado que sofre abuso produz a mesma documentação de governança que um processo de exceções bem governado usado de forma adequada: a diferença está nos padrões de justificativa e de recorrência.

Aceitar a documentação do registro de exceções como governança sólida sem revisar os padrões de justificativa
Exceções recorrentes não identificadas: as mesmas exceções aprovadas em vários ciclos não são sinalizadas
Justificativas de adiamento não distinguidas das justificativas por restrição genuína
Taxa de cobertura da linha de base não calculada: percentual de sistemas no escopo que atendem à linha de base sem exceções
Acompanhamento da correção de exceções ausente: se as exceções levam à implementação ou à renovação perpétua

Como é uma boa prática

Programas maduros de gestão de exceções distinguem, já em seu desenho, as exceções por restrição genuína das exceções de adiamento, exigindo padrões de justificativa e tratamentos diferentes para cada uma. As restrições genuínas recebem uma gestão de longo prazo adequada. As exceções de adiamento recebem escrutínio crescente e escalonamento obrigatório a cada ciclo de renovação.

Distinção por tipo de justificativa: exceções por restrição genuína e exceções de adiamento tratadas de forma diferente
Requisitos de aprovação progressivos para exceções recorrentes: a segunda renovação exige aprovação da alta liderança
Taxa de cobertura da linha de base acompanhada: percentual de sistemas no escopo que atendem à linha de base sem exceção
Relatório de idade das exceções: comitê de exceções revisando as exceções ordenadas por idade
Nenhuma renovação sem evidência de progresso na implementação: a reaprovação exige evidência de que a implementação está avançando ativamente

Ferramentas

GRC com fluxo de exceções: ServiceNow GRC, Archer

As plataformas de GRC com fluxos de gestão de exceções suportam requisitos de aprovação progressivos para exceções recorrentes e relatórios de idade das exceções para revisão pelo comitê de governança. Para profissionais de TPRM, perguntar se a plataforma de gestão de exceções do fornecedor acompanha a recorrência das exceções e escalona a aprovação das renovações é uma pergunta específica sobre a prevenção de abusos.

Conformidade com a linha de base de segurança: Qualys, Tenable

As ferramentas de conformidade com a linha de base de segurança informam o percentual de sistemas no escopo que atendem a cada requisito da linha de base, revelando a taxa de cobertura real que os registros de exceções reduzem. Para profissionais de TPRM, solicitar a taxa de conformidade com a linha de base para requisitos de segurança críticos (MFA, criptografia, aplicação de patches) em vez do registro de exceções fornece a métrica de cobertura da implementação que as contagens do registro de exceções ocultam.

Desafios de governança

O desafio de governança da gestão de exceções é o incentivo à aprovação. A aprovação no nível do CISO cria uma decisão de alto impacto para cada exceção. Quando a decisão é entre aprovar uma exceção de adiamento e bloquear um processo de negócio à espera da implementação, o caminho da aprovação produz adiamentos aprovados. Uma governança que cria pressão pela implementação em vez do adiamento, exigindo roadmaps de implementação com acompanhamento trimestral de marcos como condição para a aprovação da exceção, converte o processo de exceções de um mecanismo de adiamento em um mecanismo de compromisso com a implementação.

Solicite a taxa de conformidade com a linha de base, não o registro de exceções: percentual de sistemas que atendem à linha de base sem exceção
Pergunte sobre a idade e a recorrência das exceções: quantas exceções ativas estão no segundo ou terceiro ciclo de aprovação
Exija roadmaps de implementação como condição para aprovar exceções de adiamento
Revise os padrões de justificativa das exceções: se o mesmo tipo de justificativa se repete em várias exceções
Pergunte que percentual das exceções acaba levando à implementação versus à renovação perpétua

Se você faz parte de uma equipe pequena

Faça duas perguntas ao seu fornecedor de maior risco sobre o registro de exceções. Primeira: das exceções ativas atualmente, quantas foram renovadas pelo menos uma vez, ou seja, estão no segundo ciclo de aprovação ou em um posterior? Segunda: especificamente para as exceções relacionadas a MFA, criptografia ou controle de acesso, qual é a idade média, e que percentual tem uma data-alvo de implementação definida com trabalho de engenharia ativo em andamento? Essas duas perguntas distinguirão um registro de exceções bem gerenciado de um que se tornou um mecanismo sistemático para contornar a linha de base.

Pergunte quantas exceções ativas estão no segundo ciclo de aprovação ou em um posterior
Solicite a idade e as datas-alvo de implementação das exceções a controles de segurança críticos
Solicite a taxa de conformidade com a linha de base para os requisitos de maior risco, não a contagem do registro de exceções
Pergunte se roadmaps de implementação são exigidos para exceções de adiamento

O que exigir

Pergunte diretamente:

“Para as exceções ativas à sua linha de base de segurança, especificamente aos requisitos de MFA, criptografia ou controle de acesso, qual é a idade média das exceções e quantas estão no segundo ciclo de renovação ou em um posterior? E que percentual dos sistemas no escopo desses requisitos atende ao requisito sem exceção?”

O que esperar como evidência

Distribuição de idade das exceções e contagem de recorrências
Taxa de conformidade com a linha de base para requisitos críticos
Roadmaps de implementação para exceções de adiamento
Distribuição das exceções por tipo de justificativa: restrição genuína versus adiamento

Um fornecedor cujo processo de exceções é formalmente governado deve ser solicitado a informar a taxa de conformidade com a linha de base que as exceções reduzem e a contagem de recorrência das exceções em vários ciclos de aprovação. O processo é governado. Os padrões revelam se ele está sendo usado de forma adequada.

Como comprovar

Registros da revisão dos padrões de justificativa das exceções
Acompanhamento da taxa de conformidade com a linha de base
Identificação de exceções recorrentes
Exigência de roadmap de implementação para exceções de adiamento

Principal conclusão

O processo de exceções é governado. Cada exceção tem documentação, avaliação de risco, aprovação do CISO e um prazo. Trinta e sete das quarenta e uma exceções ativas são para implementações de MFA que exigem trabalho de engenharia que não foi priorizado. Quatro estão no segundo ou terceiro ciclo de aprovação. O processo está funcionando como projetado. A linha de base de segurança está sendo sistematicamente evitada por meio dele. A gestão de exceções existe para lidar com restrições genuínas. Quando é usada para adiar implementações difíceis, o registro de exceções cresce e a taxa de cobertura da linha de base diminui. Acompanhe a taxa de conformidade com a linha de base, não a qualidade do registro de exceções. Identifique as exceções recorrentes. Exija roadmaps de implementação como condição para aprovar adiamentos. A exceção é o mecanismo de governança para restrições. A implementação é a obrigação. O processo deve criar pressão em direção à obrigação, e não um caminho para longe dela.