Análise de Riscos de TI: Metodologia para PMEs

Por Que Análise de Riscos Deixou de Ser Assunto Apenas de Grande Empresa

Durante muito tempo, a gestão de riscos de TI foi tratada como uma disciplina restrita a bancos, seguradoras e multinacionais com departamentos inteiros dedicados a compliance. Empresas de médio e pequeno porte olhavam para normas como a ISO 27005 ou o framework do NIST e concluíam, com alguma razão, que aquilo era grande demais para sua realidade. O resultado foi uma geração inteira de PMEs operando sem qualquer mapeamento formal do que poderia dar errado em sua infraestrutura — até o dia em que deu.

O que mudou nos últimos anos não foi a complexidade das normas, mas o perfil do atacante e o custo da paralisação. Ransomware deixou de ser um ataque direcionado a alvos ricos e passou a operar em escala industrial, varrendo faixas de IP inteiras em busca de qualquer porta RDP exposta, qualquer VPN sem MFA, qualquer servidor sem patch. Para o operador do ataque, uma empresa de 40 funcionários com faturamento modesto continua sendo um alvo economicamente viável, porque o custo marginal de atacá-la é praticamente zero. Some-se a isso a LGPD, que estabelece responsabilidade objetiva sobre dados pessoais independentemente do porte da organização, e o cenário fica claro: a PME herdou o risco das grandes sem herdar sua estrutura de defesa.

A boa notícia é que análise de riscos não exige software caro nem consultoria de seis dígitos. Exige método. Uma planilha bem construída, revisada trimestralmente por alguém que entenda tanto do negócio quanto da infraestrutura, entrega mais valor do que uma ferramenta de GRC comprada e abandonada no terceiro mês. O que este artigo apresenta é exatamente essa metodologia enxuta: quatro etapas que cabem no calendário de uma empresa que não tem um CISO dedicado.

Etapa 1 — Inventário de Ativos: Você Não Protege o Que Não Conhece

Toda análise de riscos começa com uma pergunta desconfortável: o que exatamente existe na sua rede? Na maioria das PMEs que auditamos, a resposta inicial diverge da realidade em 20% a 40%. Aparecem servidores virtuais criados para um projeto que terminou há dois anos, notebooks de ex-funcionários ainda com credenciais válidas, instâncias de nuvem contratadas por uma área de negócio sem passar pela TI, e aquele NAS embaixo da mesa do financeiro que ninguém sabia que guardava cópia da folha de pagamento.

O inventário precisa cobrir quatro categorias e, para cada item, registrar quem é o responsável e qual processo de negócio depende dele:

• Ativos de informação — bancos de dados, arquivos financeiros, contratos, base de clientes, prontuários, propriedade intelectual. Classifique cada um por sensibilidade: público, interno, confidencial ou restrito.
• Ativos de hardware — servidores físicos e virtuais, estações, notebooks, firewalls, switches, dispositivos móveis corporativos, storages e appliances de backup.
• Ativos de software e serviços — ERP, sistema de gestão, Microsoft 365, ferramentas SaaS contratadas por cartão corporativo, sistemas legados sem suporte do fabricante.
• Ativos humanos e de processo — quem tem acesso privilegiado, quais fornecedores acessam sua rede remotamente, qual conhecimento crítico está concentrado em uma única pessoa.

Vale um alerta específico sobre a quarta categoria. Risco de TI raramente é apenas técnico. Um administrador que detém a única senha do firewall e sai da empresa em condições ruins representa um risco tão concreto quanto uma vulnerabilidade crítica sem patch — e costuma ficar de fora dos inventários porque não aparece em nenhum scanner.

Etapa 2 — Mapeamento de Ameaças e Vulnerabilidades

Com o inventário em mãos, o passo seguinte é cruzar cada ativo relevante com as ameaças que podem afetá-lo. A distinção conceitual importa e evita muita confusão nas reuniões: ameaça é o evento externo ou interno capaz de causar dano (um ataque de ransomware, uma falha de disco, um erro humano, um alagamento na sala de servidores). Vulnerabilidade é a fraqueza que permite que a ameaça se concretize (ausência de backup offline, servidor sem redundância, falta de treinamento, sala sem detecção de umidade). Risco é a combinação dos dois, ponderada pelo impacto no negócio.

Para PMEs brasileiras, um conjunto recorrente de cenários cobre a maior parte da exposição real:

1. Ransomware com criptografia de backups — o atacante permanece semanas na rede antes de disparar, tempo suficiente para localizar e destruir cópias acessíveis pela mesma credencial.
2. Comprometimento de conta de e-mail corporativo — normalmente via phishing ou credencial vazada, resultando em fraude de boleto ou desvio de pagamento a fornecedor.
3. Indisponibilidade prolongada de sistema crítico — falha de hardware sem contrato de suporte vigente, ou aplicação legada rodando em servidor único sem plano de recuperação.
4. Vazamento de dados pessoais — exposição de base de clientes por compartilhamento indevido, acesso excessivo ou descarte incorreto de equipamento.
5. Dependência crítica de fornecedor único — desenvolvedor do sistema que não entrega código-fonte, ou provedor de nuvem sem cláusula de portabilidade de dados.
6. Erro operacional interno — exclusão acidental, alteração de configuração sem janela de mudança, restauração testada pela primeira vez durante o desastre.

Nas ocorrências de ransomware que atendemos, o fator decisivo entre parar seis horas e parar duas semanas quase nunca foi a sofisticação do ataque. Foi a existência de uma cópia de backup imutável, isolada do domínio, e de um procedimento de restauração que alguém já havia executado em simulação.

Não busque exaustividade nesta etapa. Vinte cenários bem descritos e priorizados valem mais do que duzentos itens genéricos copiados de um catálogo. O critério de inclusão deve ser simples: se este cenário acontecesse na segunda-feira de manhã, teríamos um problema relevante para o negócio?

Etapa 3 — A Matriz de Riscos: Quantificando Sem Complicar

A matriz de riscos é a ferramenta que transforma uma lista de preocupações em uma fila de prioridades defensável. Sua lógica é direta: cada cenário recebe uma nota de probabilidade e uma nota de impacto, ambas numa escala de 1 a 5, e o produto das duas define o nível de risco.

Para a probabilidade, ancore a escala em frequência observável, não em sensação: 1 = raro (menos de uma vez a cada dez anos), 2 = improvável (uma vez a cada cinco anos), 3 = possível (uma vez ao ano), 4 = provável (algumas vezes ao ano), 5 = quase certo (mensal ou mais frequente). Para o impacto, ancore em consequência de negócio: 1 = desprezível (resolvido em minutos, sem efeito externo), 3 = moderado (paralisação de algumas horas, retrabalho, cliente percebe), 5 = crítico (paralisação de dias, perda de dados irrecuperável, multa da ANPD, dano de reputação ou risco de continuidade da empresa).

O produto gera uma pontuação de 1 a 25, que se traduz em faixas de tratamento:

• 1 a 4 — Baixo: aceitar o risco formalmente e registrar. Nenhuma ação adicional necessária.
• 5 a 9 — Moderado: monitorar e tratar quando houver orçamento ou janela. Reavaliar a cada revisão trimestral.
• 10 a 15 — Alto: tratamento planejado com prazo definido, responsável nomeado e verba aprovada no ciclo corrente.
• 16 a 25 — Crítico: tratamento imediato. Se não houver solução rápida, implementar controle compensatório provisório enquanto a definitiva é executada.

Para cada risco acima da faixa de aceitação, escolha uma das quatro respostas clássicas. Mitigar é reduzir probabilidade ou impacto com controles — MFA, backup imutável, segmentação de rede, patching disciplinado. Transferir é repassar a consequência financeira a terceiros, via seguro cibernético ou cláusula contratual de SLA com penalidade. Evitar é eliminar a atividade que gera o risco — desativar o RDP exposto, descontinuar o sistema sem suporte, encerrar a integração insegura. Aceitar é uma decisão legítima, desde que consciente, documentada e assinada por quem tem autoridade para assumi-la. Risco aceito por omissão não é aceitação, é negligência — e essa distinção pesa em uma eventual fiscalização.

Um cuidado prático: a matriz precisa registrar tanto o risco inerente (antes dos controles) quanto o risco residual (depois deles). É o residual que orienta a decisão de investir mais, e é a diferença entre os dois que demonstra ao conselho ou ao sócio o valor concreto do que já foi gasto em segurança.

Etapa 4 — Governança: Transformar o Documento em Rotina

A maior causa de fracasso em gestão de riscos não é metodologia ruim, é abandono. A planilha é construída com entusiasmo em janeiro, apresentada à diretoria em fevereiro e nunca mais aberta. Seis meses depois, metade dos controles descritos não existe mais e o inventário está desatualizado, o que é pior do que não ter documento algum — porque cria uma falsa sensação de cobertura.

O que sustenta o processo é uma cadência simples e realista. Revisão trimestral da matriz, com reunião de no máximo uma hora, revisando apenas os riscos alto e crítico e o andamento dos planos de ação. Revisão completa anual, incluindo reinventário de ativos e recalibração das escalas. Revisão extraordinária sempre que houver mudança material: novo sistema crítico entrando em produção, aquisição ou fusão, incidente de segurança, mudança de provedor de nuvem, ou nova exigência regulatória do setor.

Defina também os indicadores que você vai acompanhar entre as revisões. Alguns poucos, mensuráveis e honestos, funcionam melhor do que um painel cheio: percentual de estações com patches críticos em dia, número de contas privilegiadas ativas, data do último teste de restauração de backup bem-sucedido, tempo médio para revogar acesso de desligado, e cobertura de MFA sobre contas com acesso externo. Se algum desses números não puder ser levantado hoje, isso já é, por si só, um achado da análise.

Como a Duk Apoia a Análise de Riscos na Prática

Ao longo de mais de 18 anos atendendo empresas brasileiras, a Duk Informática & Cloud construiu sua metodologia de análise de riscos a partir de um universo hoje superior a 550 clientes — o que significa que os cenários descritos aqui não vêm de manual, mas de incidentes reais atendidos, restaurações executadas sob pressão e auditorias conduzidas em ambientes de produção com todas as suas imperfeições.

Na prática, o trabalho começa por um levantamento técnico do ambiente, que costuma revelar a distância entre o inventário informado e a infraestrutura efetivamente ativa: contas órfãs, servidores fora do ciclo de atualização, backups que nunca foram testados, exposições de perímetro esquecidas. A partir desse retrato, montamos a matriz junto com o cliente, traduzindo cada achado técnico em linguagem de impacto no negócio, para que a decisão de investir ou aceitar o risco seja tomada por quem responde pelo resultado — e não delegada por omissão à TI.

A condição de Microsoft Gold Partner acrescenta profundidade específica no ecossistema onde a maioria das PMEs concentra seus dados críticos: Microsoft 365, Entra ID, Defender e Azure. Boa parte dos riscos mais bem pontuados em uma matriz típica — comprometimento de e-mail, ausência de MFA, políticas de acesso condicional inexistentes, retenção mal configurada — é tratável com recursos que a empresa já licenciou e não ativou. Somado a monitoramento contínuo, backup gerenciado e suporte 24/7 com SLA, o resultado é um ciclo de gestão de riscos que permanece vivo entre uma revisão e outra, em vez de virar mais um documento na pasta de compliance.