O impacto da GRC Engineering na gestão de riscos cibernéticos de terceiros

O manifesto de GRC Engineering propõe uma mudança na forma como abordamos governança, risco e conformidade (GRC), com o objetivo de tornar esses processos mais automatizados e eficazes. Entre os princípios fundamentais, dois se destacam aqui: alinhar os objetivos das diferentes equipes para que trabalhem em direção aos mesmos resultados e garantir que esses resultados sejam consistentes e mensuráveis.

Com metas concretas e quantitativas, uma organização consegue substituir soluções ultrapassadas - tais como questionários de checklist e monitoramentos periódicos - por garantias contínuas e permanentes.

De forma mais direta, o GRC Engineering incentiva a abertura para contribuições externas e a criação de políticas fundamentadas em tecnologia e no entendimento cada vez mais avançado sobre ameaças cibernéticas.

Não por acaso, a gestão do risco cibernético de terceiros (TPCRM) costuma fazer parte do escopo dos processos de GRC. Muitas empresas enxergam seus terceiros como entidades que precisam ser avaliadas por meio de tarefas de garantia trabalhosas e paralelas ao trabalho que esses fornecedores de fato irão entregar. De modo geral, esse é exatamente o tipo de problema que o manifesto de GRC Engineering destaca em várias frentes de GRC.

Mas como essa mudança se aplicaria, na prática, à avaliação de risco de terceiros - especialmente risco cibernético?

Otimização, tecnologia e automação

É intuitivo começar resolvendo um problema através do desenvolvimento de um processo manual. Mas processos manuais não escalam e acabam levando a limitações - como avaliações anuais ou então revisões que são executadas apenas em parte da operação.

Isso compromete claramente a eficácia dos processos, mas é difícil encontrar uma solução quando se está preso às expectativas e ao fluxo de trabalho definidos por procedimentos já estabelecidos.

Até pode ser possível automatizar essas tarefas, mas é bem provável que essa automação fique engessada e limitada. Em vez disso, uma melhor abordagem seria analisar o cenário tecnológico e criar um processo pensado para ser automatizado desde o início. Para ilustrar, seria como recusar a criação de um veículo a não ser que tenha pernas - simplesmente porque foi assim que aprendemos a nos mover do ponto A ao ponto B - apesar da tecnologia já permitir alcançar nosso objetivo real (locomoção) de uma forma muito mais eficaz.

No contexto de GRC Engineering, há guias detalhando como implementar esses princípios em ambientes modernos de nuvem. A ideia central é incorporar GRC à própria estrutura técnica da organização. Como afirmou Michael Rasmussen, especialista em GRC, em um artigo da GRC 20/20: “GRC Engineering é a disciplina de incorporar governança, gestão de risco e conformidade ao tecido técnico da organização por meio de arquitetura de sistemas, automação e engenharia de dados.” Essa visão, combinada às reflexões de Ayoub Fandi, líder de Security Assurance Automation no GitLab e fundador do GRC Engineer Podcast & Newsletter, reforça a mudança do mercado rumo a um GRC operacionalizado -  novamente, centralizado na tecnologia.

As mesmas oportunidades também existem para TPCRM. Em vez de tentar automatizar processos que foram criados para ser manuais, como questionários, precisamos olhar para o ecossistema tecnológico disponível e então criar soluções que já nasçam apoiadas nessa base - ou seja, pensadas para automação desde o início.

Ambientes em nuvem e ecossistemas conectados oferecem diversas possibilidades para automatizar a gestão de risco de terceiros - possibilidades que só ficam claras quando olhamos para a tecnologia e para os objetivos certos. E, em segurança, esses objetivos devem vir do entendimento sobre ameaças e riscos.

‍

Defesa contra ameaças e foco em resultados - não em formalidades

Padrões são diretrizes muito úteis. Mas, às vezes, eles acabam sendo tratados como o objetivo final - o que leva ao que o manifesto de GRC Engineering chama de “comoditização da conformidade”.

Quando um padrão é usado mais como métrica conveniente do que como ponte para resolver um problema real, seu propósito se perde.

No universo de GRC, isso aparece claramente nas auditorias SOC 2 Type II (tema do nosso episódio bônus de podcast sobre SOC 2). E isso afeta diretamente o TPCRM, já que muitas empresas buscam auditorias e certificações como prova de conformidade para escolher terceiros “confiáveis”. O problema é que esses certificados nem sempre se traduzem em segurança real - e as organizações acabam sem a garantia que imaginam ter.

Quando aplicamos essa ideia de priorizar resultados em vez de formalidades diretamente ao TPCRM, surge a pergunta: a avaliação é apenas burocracia ou estamos realmente aprendendo algo valioso sobre o terceiro? Além disso, é essencial entender se o que aprendemos está de fato conectado às ameaças e aos riscos que queremos mitigar.

Essa mudança de mentalidade abre novas perspectivas.

Primeiro, reforça que entender o cenário de ameaças é essencial para um programa de TPCRM - e que esse conhecimento deve orientar requisitos e métodos de avaliação.

Segundo, fica muito claro que o tempo é uma variável importante, porque riscos e ameaças estão ligados a períodos específicos. E não é possível ajustar suas avaliações de forma ágil sem um processo que seja dinâmico, flexível e contínuo.

Se você já utiliza dados de ameaças para orientar suas decisões de GRC, essa mesma abordagem pode se estender de forma natural ao seu programa de TPCRM.

E se o seu terceiro já adotar GRC Engineering?

Mudar a forma como pensamos pode ser difícil, especialmente quando não existe um framework simples e universal para orientar cada etapa. Como consequência, mesmo que um terceiro aplique os princípios de GRC Engineering para melhorar seus resultados, ainda assim pode haver a expectativa de que ele realize o mesmo trabalho manual que todo mundo faz.

Isso é um problema. Se não houver uma forma de fazer melhor sem fazer mais, as empresas simplesmente não conseguem se tornar mais eficientes!

Pode parecer desafiador fazer avaliações sem um playbook. Mas, se você usa dados de ameaças para orientar suas prioridades, você já tem um. E não é preciso imaginar sinais complexos para indicar boas práticas de segurança quando você pode simplesmente consultar diretamente as informações de que precisa.

Por exemplo, você pode fazer várias perguntas para entender as práticas de segurança de identidade dos seus terceiros - ou pode consultar diretamente o ambiente deles para ver quantos usuários têm MFA habilitado e quantos não têm. Hoje, muitas organizações já têm uma infraestrutura de TI que permite esse tipo de consulta, mas muitas ainda não aproveitam esse recurso.

Trabalhar junto com os terceiros por meio de um monitoramento inside-out oferece uma visão real das práticas de segurança deles e foca muito mais nos resultados alcançados. De várias formas, esse modelo recompensa eficiência e entregas - exatamente o que a maioria das empresas busca. Além disso, ele permite uma abordagem de gestão de riscos orientada por dados, sem ignorar o fator tempo como uma variável importante.

Devemos estar sempre atentos a melhorias e a novas formas de abordar GRC e TPCRM. Mas, como primeiro passo, precisamos reconhecer os tipos de elementos que temos hoje - e que não existiam antes - e entender que simplesmente migrar processos antigos para um novo cenário não é a melhor forma de manter os mesmos níveis de garantia e conformidade.