#!/intro
A aceitação de risco é frequentemente tratada como uma formalidade administrativa. Um formulário preenchido, uma aprovação por correio eletrónico ou uma assinatura necessária para encerrar uma recomendação de segurança.
Na prática, representa uma decisão de gestão: manter uma fragilidade conhecida porque a sua correção exige dinheiro, tempo, indisponibilidade ou alterações que a organização não está disposta a aceitar naquele momento.
Não existe orçamento para substituir o sistema. A aplicação não pode ser interrompida. O projeto não pode atrasar. O fornecedor ainda não apresentou uma solução. A alteração pode afetar a operação.
Estes argumentos podem ser legítimos. Nenhuma organização dispõe de recursos ilimitados e nem todas as correções podem ser executadas de imediato. O problema começa quando estas restrições são apresentadas como circunstâncias inevitáveis, em vez de decisões sobre prioridades e risco.
A equipa de segurança identifica a fragilidade, avalia a exposição e recomenda uma intervenção. A gestão decide não financiar, não interromper, não substituir ou não alterar. O risco permanece porque a organização considerou outras prioridades mais importantes.
Quando nada acontece, essa decisão parece razoável. Quando ocorre um incidente, as limitações impostas antes dele tendem a desaparecer da narrativa. A correção que não recebeu orçamento transforma-se numa vulnerabilidade que a segurança não resolveu. A interrupção que não foi autorizada passa a ser uma medida que deveria ter sido aplicada. O risco que a gestão decidiu manter é apresentado como falha da equipa que o identificou.
A aceitação formal de risco é necessária para impedir esta reconstrução conveniente dos acontecimentos.
> decisao
A tensão entre segurança e negócio não é uma anomalia. Faz parte da gestão de risco.
A segurança procura reduzir a probabilidade de compromisso e limitar o impacto de uma eventual falha. As áreas operacionais procuram manter os serviços disponíveis, cumprir prazos e evitar alterações com impacto na atividade. A gestão decide onde aplicar os recursos disponíveis e que perturbações considera aceitáveis.
Estas perspetivas correspondem a responsabilidades diferentes.
A equipa de segurança pode identificar uma vulnerabilidade, determinar os ativos expostos, avaliar cenários de ataque e estimar as possíveis consequências. Pode recomendar medidas de correção, propor controlos compensatórios e explicar o risco de adiar a intervenção.
Não controla, porém, o orçamento da organização. Não decide que serviço pode ser interrompido. Não define as prioridades comerciais nem determina que projeto deve ser adiado para permitir uma correção.
Quando a gestão afirma que não existe orçamento, está a decidir aplicar os recursos noutras prioridades. Quando determina que o negócio não pode ser perturbado, está a atribuir maior importância à continuidade imediata do que à redução da exposição. Quando recusa uma janela de manutenção, está a escolher manter o risco durante mais tempo.
Estas decisões podem ser justificadas. Não deixam de ser decisões de gestão.
A falta de orçamento não reduz a probabilidade de exploração. A importância operacional de um sistema não elimina as suas vulnerabilidades. A urgência de um projeto não modifica o impacto de um compromisso. Estas circunstâncias podem influenciar o tratamento do risco, mas não alteram o risco propriamente dito.
É precisamente nos sistemas que não podem parar que a fragilidade pode ter consequências mais graves. A indisponibilidade necessária para uma intervenção planeada pode ser inconveniente, mas a indisponibilidade provocada por um incidente não respeita calendários, períodos de menor atividade ou compromissos assumidos com clientes.
Ainda assim, a pressão sobre a segurança é frequentemente contraditória.
Antes do incidente, a equipa não deve perturbar o negócio. Depois do incidente, deveria ter sido mais firme.
Antes do incidente, não existe orçamento para corrigir. Depois do incidente, pergunta-se por que razão o problema permanecia por resolver.
Antes do incidente, uma intervenção é considerada demasiado arriscada para a operação. Depois do incidente, a ausência dessa intervenção é apresentada como negligência técnica.
Esta contradição permite à gestão conservar a autoridade antes do incidente e afastar-se da responsabilidade depois dele.
A segurança não pode garantir que nada acontecerá quando a organização recusa as medidas necessárias para reduzir a exposição. Também não pode ser responsabilizada por não executar alterações que não estava autorizada a realizar.
A decisão de adiar uma correção deve, por isso, ser expressa de forma clara. Deve identificar o risco conhecido, a razão do adiamento, as alternativas apresentadas e a pessoa que possui autoridade para aceitar as possíveis consequências.
Sem esse registo, a aceitação existe na prática, mas a responsabilidade permanece deliberadamente indefinida.
> formalizacao
Quando a correção estrutural não é possível, devem ser aplicados controlos compensatórios.
Uma aplicação que não pode ser corrigida pode ser isolada numa zona de rede mais restrita. Um serviço pode ser limitado aos fluxos estritamente necessários. Um acesso excessivo pode ser sujeito a autenticação reforçada e monitorização. Um sistema sem suporte pode receber medidas adicionais de filtragem e restrições de administração.
Estes controlos podem reduzir a probabilidade de exploração, limitar o impacto ou aumentar a capacidade de deteção e resposta. Não eliminam necessariamente a fragilidade.
Um controlo compensatório também não transforma uma decisão orçamental numa solução técnica.
A segmentação não atualiza um sistema vulnerável. A monitorização não impede todos os ataques. Uma regra de filtragem pode reduzir a superfície exposta, mas depende da configuração, da manutenção e do conhecimento dos fluxos existentes. Um procedimento manual pode falhar quando a organização está sob pressão.
A existência destes controlos não deve ser utilizada para manter indefinidamente uma situação que deveria ser temporária.
A aceitação deve considerar o risco residual, isto é, o risco que permanece depois de aplicadas as medidas existentes. Esse risco deve ser descrito em termos compreensíveis para quem toma a decisão.
Não basta registar que existe uma vulnerabilidade ou uma não conformidade. É necessário indicar os sistemas afetados, os cenários previsíveis e as possíveis consequências para a organização.
O impacto pode incluir interrupção de serviços, perda de informação, divulgação indevida de dados, alteração não autorizada, incumprimento de obrigações ou incapacidade de executar funções essenciais.
A aceitação deve também registar as opções apresentadas pela equipa de segurança. Se a correção foi rejeitada por falta de orçamento, essa razão deve ficar explícita. Se a intervenção foi adiada para não perturbar a operação, deve ser identificado quem tomou essa decisão. Se a organização preferiu manter um sistema antigo para evitar custos de substituição, essa opção não deve ser disfarçada de impossibilidade técnica.
Dizer que não é possível corrigir não é o mesmo que dizer que não se pretende suportar o custo da correção.
Dizer que um serviço não pode ser interrompido não é o mesmo que demonstrar que não existe qualquer forma de realizar a intervenção.
Dizer que o negócio tem prioridade não elimina a obrigação de reconhecer o risco criado por essa prioridade.
A aceitação deve identificar um responsável nominal, uma justificação, uma data de validade e uma data de revisão. Uma referência genérica à direção, a uma comissão ou a uma área funcional dilui a responsabilidade e permite que a decisão deixe de ter autor.
Uma exceção sem prazo também não é temporária. É uma alteração permanente ao nível de risco da organização.
A revisão não deve consistir apenas na substituição de uma data por outra. Deve verificar se a fragilidade permanece, se os controlos continuam eficazes, se o contexto mudou e se a correção passou a ser possível.
Caso contrário, a aceitação deixa de ser um instrumento de gestão. Passa a ser um mecanismo administrativo para prolongar a inação.
> responsabilidade
A equipa de segurança deve responder pela qualidade da sua avaliação.
Deve identificar corretamente a fragilidade, explicar os cenários relevantes, propor medidas proporcionais e comunicar o risco de forma clara. Deve acompanhar os controlos que administra e contestar decisões que considere incompatíveis com os critérios definidos pela organização.
Também deve evitar avaliações alarmistas ou recomendações desligadas da realidade operacional. A segurança não pode limitar-se a exigir correções sem compreender o serviço, as dependências e o impacto da intervenção.
Esta responsabilidade técnica não significa, contudo, que deva assumir decisões que pertencem à gestão.
A equipa de segurança não pode aprovar, em nome da organização, a ausência de investimento decidida pela direção. Não pode aceitar isoladamente o risco criado por uma área que recusa uma interrupção. Não pode responder pelas consequências de prioridades comerciais ou operacionais que não controla.
A segurança emite parecer, caracteriza o risco e propõe medidas de tratamento. A aceitação compete a quem detém autoridade sobre os recursos, a operação e as prioridades que impedem a correção. A intervenção da segurança valida a avaliação técnica e os controlos propostos. Não equivale a aceitar a exposição em nome da organização. A decisão deve ser formalizada por quem possui autoridade efetiva para manter o ativo nessas condições.
Caso contrário, cria-se uma distribuição profundamente desequilibrada.
A gestão decide que não há orçamento. A área operacional impede a interrupção. O negócio exige que o projeto avance. A segurança fica responsável por assegurar que o risco nunca se concretiza.
Essa expectativa é impossível de cumprir.
Quando ocorre um incidente, é fácil concentrar a análise no último controlo que falhou. É mais difícil reconhecer as decisões acumuladas que impediram a correção, limitaram a arquitetura ou mantiveram sistemas vulneráveis em produção.
A análise posterior tende então a perguntar por que razão a segurança não impediu o incidente. Raramente começa por perguntar quem recusou o investimento, quem rejeitou a indisponibilidade necessária ou quem decidiu prolongar a exceção.
Formalizar a aceitação de risco não serve para proteger a equipa de segurança de qualquer responsabilidade. Serve para preservar os factos.
Se a avaliação foi incompleta, se uma recomendação não foi comunicada ou se um controlo não foi corretamente administrado, a segurança deve responder por essa falha.
Mas, se o risco foi identificado, a correção foi proposta e a organização decidiu não investir ou não perturbar o negócio, a responsabilidade por essa decisão não pode ser transferida depois do incidente.
A autoridade e a responsabilidade devem permanecer juntas.
Quem controla o orçamento deve assumir a decisão de não financiar. Quem controla a operação deve assumir a decisão de não interromper. Quem define as prioridades deve aceitar os riscos resultantes dessas prioridades.
A equipa de segurança não deve funcionar como destinatário final de todos os riscos que a organização escolhe não tratar.
> conclusao
Nem todos os riscos podem ser eliminados e nem todas as correções podem ser executadas imediatamente.
A organização pode decidir que não existe orçamento, que uma interrupção não é aceitável ou que determinada alteração deve ser adiada. Essas decisões podem ser necessárias.
Não podem é deixar de ter responsável.
Quando a gestão impede uma intervenção para proteger a continuidade imediata do negócio, está a aceitar a exposição que permanece. Quando recusa o investimento necessário, está a decidir que outros objetivos têm prioridade. Quando prolonga uma exceção, está a aceitar que o risco continue presente.
A equipa de segurança deve avaliar, documentar, alertar e propor alternativas. Deve responder pela qualidade do seu trabalho e pelos controlos que administra.
Não deve responder por decisões que não tomou, por recursos que não controla ou por intervenções que não foi autorizada a executar.
Não é aceitável limitar a segurança antes do incidente e culpá-la depois dele.
Quem impede a correção antes do incidente não pode culpar a segurança depois dele.
> status: accepted> exit 0