Risco interno: reduzir a oportunidade e melhorar a resposta

O risco interno inclui a utilização indevida deliberada, os erros e a atividade realizada através de uma conta legítima comprometida. Trabalhadores, prestadores externos, fornecedores e antigos colaboradores com acessos residuais podem estar todos envolvidos. O ponto de partida útil não é uma lista de pessoas supostamente de risco: são os acessos e as ações que podem causar danos.

Para um CTO, a tarefa é reduzir as oportunidades de utilização indevida, preservando o trabalho legítimo, e tornar depois a atividade suspeita passível de investigação. Isso exige controlos de identidade, regras de tratamento de dados, telemetria útil e um processo de resposta que distinga um acidente de um comprometimento de conta ou de uma ação deliberada. As consequências potenciais incluem fraude, perda de propriedade intelectual, exposição de dados pessoais e perturbação operacional. Nenhuma delas exige que um atacante explore uma vulnerabilidade de software se as permissões existentes já permitirem a ação.

Identificar os caminhos de elevado impacto

Comece por um processo de negócio importante e mapeie como alguém poderia causar danos materiais utilizando acessos legítimos. Inclua aplicações, interfaces de administração, API, dispositivos e prestadores externos. Um exercício de modelação de ameaças centrado nos acessos pode ajudar a identificar caminhos que atravessam vários sistemas.

Pergunte o que uma pessoa pode ler, alterar, exportar, apagar ou aprovar, e não apenas se tem uma conta.

Para cada caminho, registe o responsável pelo ativo, as funções autorizadas, a finalidade esperada, o controlo preventivo, a fonte de deteção e quem responde. Priorize pelo impacto potencial, pela facilidade de execução e pela capacidade de recuperação. Uma ação sensível que uma única pessoa pode executar sem verificações independentes merece especial atenção.

O resultado é um registo curto de caminhos de acesso. Deve identificar exatamente que ação precisa de segregação de funções, de aprovação adicional ou de uma monitorização mais atenta.

Remover a autoridade desnecessária antes de acrescentar vigilância

O princípio do menor privilégio significa ajustar as permissões ao trabalho atual. Comece pelas permissões efetivas, incluindo grupos aninhados, funções específicas de cada aplicação, acessos delegados, contas de serviço, tokens de API e credenciais partilhadas. Uma lista de funções do diretório arrumada pode esconder permissões excessivas dentro de aplicações individuais.

Peça aos responsáveis de negócio que validem por que razão cada permissão sensível é necessária. Sempre que possível, separe as contas de uso diário das identidades administrativas e substitua os acessos administrativos permanentes por elevação aprovada e limitada no tempo. Utilize autenticação multifator, de preferência com métodos resistentes a phishing quando suportados, para reduzir a exposição ao comprometimento de credenciais. A autenticação não impede que uma pessoa autorizada utilize indevidamente as suas permissões.

A segregação de funções tem de existir no sistema, e não apenas na política. Quem altera os dados de pagamento de um fornecedor não deve também aprovar o pagamento daí resultante. As derrogações de emergência precisam de um motivo registado, de uma data de expiração definida e de uma revisão posterior por alguém independente da ação.

Integre as alterações de acesso nos fluxos de trabalho de pessoal e de fornecedores:

• Entrada: atribua uma função definida, em vez de copiar as permissões acumuladas de um colega.
• Mudança de função: remova os acessos obsoletos, além de acrescentar as novas responsabilidades.
• Saída: coordene a desativação da conta, o encerramento de sessões, a revogação de tokens, o tratamento dos dispositivos e a remoção dos acessos de fornecedores.
• Trabalho temporário: atribua um responsável e uma data de expiração aos acessos elevados ou específicos de projetos.

Reveja as contas de serviço separadamente. Documente a sua finalidade, as dependências, o armazenamento das credenciais e o responsável. Evite a utilização interativa quando não for necessária. Se ainda não for possível eliminar uma credencial partilhada, registe a exceção e os controlos compensatórios; não presuma que os registos identificarão de forma fiável o utilizador individual.

Proteger os dados e o caminho para o exterior

A proteção de dados começa por saber que informação importa e para onde se desloca. Classifique os conjuntos de dados sensíveis, identifique os destinos aprovados e defina quando as exportações ou a partilha externa são legítimas. Dê aos utilizadores um caminho aprovado viável; caso contrário, os controlos podem empurrar a atividade para canais não geridos.

A prevenção de perda de dados (DLP) pode avisar, bloquear ou exigir justificação para determinadas transferências. Teste as políticas em projeto-piloto com fluxos de trabalho representativos antes de as aplicar de forma generalizada. Teste as ligações de partilha na nuvem, os carregamentos através do browser, os clientes de sincronização, os suportes amovíveis e a impressão, quando relevantes para o risco. A cobertura varia consoante a plataforma e o canal; um teste bem-sucedido num dispositivo não demonstra a proteção da API de uma aplicação.

A cifragem em repouso e em trânsito protege caminhos de exposição específicos, mas um utilizador autorizado pode, ainda assim, obter o texto em claro. Combine a cifragem com limites de acesso, restrições à exportação e partilha controlada. Proteja também as cópias de segurança e a administração da recuperação: a utilização indevida destrutiva torna-se mais difícil de recuperar quando a mesma identidade pode alterar a produção e apagar as respetivas cópias de segurança.

Tornar a deteção proporcionada e explicável

Recolha sinais ligados aos caminhos de elevado impacto, em vez de tudo o que uma pessoa faz. Os eventos úteis podem incluir exportações invulgarmente grandes, nova partilha externa, alterações de privilégios, desativação do registo de eventos, acessos negados repetidos ou acesso a repositórios sensíveis fora dos padrões de trabalho estabelecidos.

Utilize os registos de auditoria das aplicações em conjunto com os eventos de identidade, dos dispositivos e da nuvem. Um sistema de gestão de informações e eventos de segurança (SIEM) pode correlacionar estas fontes; a análise do comportamento de utilizadores e entidades (UEBA) pode ajudar a identificar desvios face a uma referência. Nenhum deles demonstra a intenção. Uma migração, uma resposta a incidentes aprovada ou uma mudança de função podem explicar uma atividade invulgar.

Para cada regra de deteção, especifique:

• A ação de risco e os sistemas abrangidos.
• Os campos de registo necessários, como o autor, a data e hora, o objeto, a ação, o resultado e o destino.
• As exceções legítimas esperadas e a forma como quem responde as verifica.
• O responsável pela resposta, o circuito de escalada e as condições para uma contenção urgente.
• A forma como a equipa vai testar a regra e medir a sua utilidade.

Proteja os registos contra alterações não autorizadas, sincronize as marcas temporais e verifique se as falhas de ingestão ficam visíveis. Teste os alertas com atividade aprovada num ambiente seguro. Acompanhe a telemetria em falta e os falsos positivos como defeitos de engenharia, e não apenas como carga de trabalho dos analistas.

Estabelecer primeiro as salvaguardas da monitorização

Antes de recolher dados sobre a atividade dos trabalhadores, determine o fundamento jurídico, a finalidade, as salvaguardas de privacidade, os controlos de acesso e a conservação. Envolva os representantes adequados das áreas de privacidade, jurídica, de recursos humanos e dos trabalhadores; as obrigações de consulta dependem da jurisdição e do contexto.

Quando o RGPD se aplica, os seus artigos 5.º, 6.º, 13.º e 14.º e 32.º tratam dos princípios, da licitude do tratamento, da transparência e da segurança. O artigo 35.º exige uma avaliação de impacto sobre a proteção de dados quando o tratamento for suscetível de implicar um elevado risco. Os objetivos de segurança não afastam esses requisitos.

Como recomendação prática, prefira metadados de eventos com âmbito restrito à recolha intrusiva de conteúdos, quando estes respondam à pergunta da investigação. Restrinja o acesso aos casos, documente as decisões de conservação e não trate circunstâncias pessoais ou desacordos no local de trabalho como prova de má conduta. As pontuações automáticas exigem validação humana.

Ajudar as pessoas a comunicar erros cedo

Disponibilize um canal de comunicação evidente para partilhas acidentais, dispositivos perdidos, pedidos suspeitos e atividade inesperada nas contas. Explique o que comunicar: o sistema, a hora aproximada, a informação envolvida, os destinatários e as ações já tomadas. O pessoal não deve ter de classificar o incidente antes de pedir ajuda.

Torne a formação específica para o trabalho. As equipas financeiras precisam de cenários de verificação de alterações de pagamentos; os programadores precisam de exemplos de tratamento de repositórios e de segredos; o pessoal de apoio ao cliente precisa de orientações sobre exportações de clientes e tentativas de usurpação de identidade. Inclua os prestadores externos e os administradores privilegiados.

Responda de forma construtiva às comunicações feitas com rapidez. Diga a quem comunicou se deve deixar de utilizar um dispositivo, preservar uma mensagem ou evitar contactar um destinatário até a equipa de resposta dar indicações. Instruções claras evitam que uma limpeza bem-intencionada destrua evidências ou alargue a exposição.

Responder a factos, e não a rótulos

Um alerta é uma pista para investigação, e não prova de má conduta. Apure o contexto e proteja a confidencialidade de todos os envolvidos. Uma ação aparentemente válida numa conta pode refletir um erro, uma automatização, uma sessão roubada ou uma utilização indevida deliberada; as necessidades de contenção podem sobrepor-se, enquanto as implicações laborais diferem.

Um playbook de resposta utilizável deve abranger cinco decisões:

1. Triagem: confirme o evento, os ativos afetados, a sensibilidade, a autorização e se o dano continua. Verifique as alterações aprovadas e contacte o responsável pelo processo através de um canal de confiança.
2. Preservação: conserve, quando adequado, os registos relevantes, os eventos de identidade, os registos de partilha e os ficheiros originais. Registe a hora de recolha, a fonte, o investigador e o tratamento. Limite o acesso ao material do caso.
3. Contenção: escolha medidas proporcionadas, como revogar sessões, restringir exportações, desativar a partilha ou remover a elevação de privilégios. Considere as dependências dos serviços antes de desativar uma conta, sem atrasar a proteção urgente.
4. Coordenação: envolva, de acordo com os factos, a segurança, o responsável pelo sistema e as áreas de privacidade, jurídica e de recursos humanos. As ações laborais e as participações às autoridades policiais exigem a autoridade adequada, e não um limiar de alerta automático.
5. Recuperação: reponha os acessos e as configurações aprovados, faça a rotação das credenciais afetadas, valide a integridade dos dados e monitorize a eventual recorrência.

Defina quem pode autorizar uma contenção urgente e um contacto alternativo caso esteja implicado um administrador privilegiado ou o decisor habitual.

Avalie os deveres de notificação separadamente. Nos termos dos artigos 33.º e 34.º do RGPD, os responsáveis pelo tratamento avaliam a notificação à autoridade de controlo sem demora injustificada e, sempre que possível, até 72 horas após terem tido conhecimento da violação, a menos que esta não seja suscetível de resultar num risco para os direitos e liberdades das pessoas. Os subcontratantes notificam os responsáveis pelo tratamento sem demora injustificada. Um risco elevado pode exigir a comunicação às pessoas afetadas, sem prejuízo das exceções do artigo 34.º. Registe a fundamentação de uma decisão de não notificação e verifique outros deveres contratuais ou legais aplicáveis.

Exemplo prático: uma exportação de clientes invulgar

Pressupostos ilustrativos: uma aplicação de apoio ao cliente contém dados de contacto de clientes; os supervisores podem exportar registos limitados para casos aprovados; uma identidade de integração separada executa relatórios agendados.

Um alerta indica que um supervisor exportou substancialmente mais registos do que o seu volume de trabalho habitual. O analista verifica o âmbito da exportação, o destino, os eventos de identidade e a referência do caso aprovado. Um novo contexto de início de sessão aumenta a preocupação, mas não demonstra quem agiu.

A equipa de resposta preserva os registos da aplicação e de identidade, revoga a sessão suspeita e retira temporariamente ao utilizador a permissão de exportação. Verifica se a integração agendada não é afetada antes de alterar acessos mais amplos. Através de um contacto de confiança, o supervisor confirma que não pediu a exportação.

A hipótese de trabalho passa a ser o comprometimento da conta. Os investigadores analisam a exposição das credenciais e das sessões, identificam, sempre que possível, os destinatários ou destinos e avaliam os deveres de notificação de violações. A recuperação inclui proteger a conta e validar as permissões.

A revisão dos controlos conclui que o trabalho de apoio de rotina não exigia direitos de exportação amplos. A ação corretiva consiste numa função mais restrita, na aprovação de exportações maiores e num alerta testado. As evidências incluem registos de configuração, um teste controlado e a aprovação do revisor, e não a afirmação de que todas as exportações futuras serão impedidas.

Conservar evidências que mostrem que os controlos funcionam

Após um caso ou um exercício, registe os factos, a resposta, o impacto e as melhorias. Analise se contribuíram permissões excessivas, aprovações em falta, instruções pouco claras ou telemetria incompleta. Atribua a cada ação corretiva um responsável, uma data-limite e um método de verificação.

As evidências de garantia úteis incluem revisões de permissões com registos de remoção, históricos de elevação de privilégios, testes de saída, testes das regras de deteção, verificações da cobertura de registos e exercícios que demonstrem o circuito de escalada. Meça os resultados dos controlos, como os acessos expirados removidos e os alertas com contexto suficiente, em vez de contar apenas as formações concluídas.

O Secani liga os riscos, a implementação dos controlos e as evidências num contexto governado. Para um caminho de acesso, as equipas podem modelar os sistemas relevantes, anexar exportações de revisões e registos de testes, atribuir tarefas de resolução de lacunas e preservar as decisões da revisão humana. A documentação sobre permissões e acesso à API descreve a função da API OSCAL limitada à validação, um exemplo concreto de dar às credenciais uma capacidade restrita à tarefa a que se destinam. Traga as exportações das revisões de acessos, as constatações da monitorização e as decisões de resposta aprovadas para este registo de controlos ligado.

Comece por testar um caminho de acesso de elevado impacto e o circuito de escalada em caso de utilização indevida. Confirme que a autoridade desnecessária foi removida, que um evento significativo fica visível e que um responsável autorizado consegue agir com evidências e contexto suficientes.