Profissionais TI - Pra quem respira informação

Um dos aspectos da inteligência humana que me fascina é o aprendizado. O ser humano é capaz de criar conceitos e concepções a partir de suas experiências e reflexões; e com isso passa a saber coisas que, momentos antes, não sabia. O ser humano cria conhecimento! Entretanto, a mente opera em diversos níveis, com maior ou menor grau de consciência sobre seus pensamentos e o saber também ocorre em diversos níveis de consciência.

Há um saber racional, intelectual e consciente, que conseguimos repetir e explicar, mas que curiosamente não é muito efetivo. Neste campo estão aquelas posturas que sabemos que são corretas mas que na prática temos muita dificuldade de realizar, pois, no fundo, não acreditamos nelas de verdade.

Por outro lado, existe um saber emocional, um tanto ilógico e inconsciente, mas muito efetivo porque reside em um nível muito mais profundo da mente. Este é o saber internalizado, onde estão gravados os conceitos em que acreditamos de verdade. O aprendizado real começa com a aquisição de um saber no nível consciente mas só se completa quando este saber é internalizado.

Pois um destes saberes, que está em pleno processo de internalização em minha mente, é algo que venho ouvindo e repetindo por toda minha carreira:

A Segurança da Informação tem que ficar próxima ao negócio, pois o que importa é proteger o negócio e não a tecnologia que o suporta.

Sinto que só recentemente estou começando a acreditar nisso de verdade e quero mostrar aqui uma aplicação prática desse conceito em um dos assuntos mais áridos em Segurança da Informação para quem não é da área: Análise de Vulnerabilidades.

A típica Análise de Vulnerabilidades começa com a escolha do escopo: uma coleção de ativos tecnológicos importantes, que normalmente compõem o ambiente produtivo da empresa, separando o que está exposto à internet do que não está.

Em seguida, com auxílio de alguma ferramenta, é feita uma varredura nesses ativos para identificar elementos desatualizados dos sistemas e configurações permissivas que de alguma maneira abram brechas para um acesso não-autorizado ou para uma paralisação de serviço não-autorizada.

O próximo passo, usualmente automatizado, é classificar todas as falhas de segurança encontradas em uma escala que varia entre três e cinco níveis de criticidade. No caso de uma análise mais elaborada, identifica-se ainda quais são vulnerabilidades comprovadamente exploráveis por ferramentas disponíveis na internet e quais são vulnerabilidades sem evidência de explorabilidade – Vale lembrar que ausência de evidência não significa evidência de ausência!

O último passo é priorizar a correção das vulnerabilidades, começando pelas exploráveis a partir da internet, gerar números para tudo isso, juntamente com uma série de gráficos com apontamentos de prioridade e metas de correção, para finalmente levar para o nível executivo e caprichar na retórica para ganhar patrocínio para o processo de remediação.

Esse método até funciona, mas funciona muito mal por que o que descrevi acima não protege o negócio e sim a tecnologia. Já na partida, escolhemos o escopo pensando em ativos tecnológicos importantes, sem sequer pensar em que processos de negócio rodam lá.

O nível executivo está preocupado com o negócio e não com a tecnologia; e não tem condições de conectar o risco tecnológico ao risco de negócio. Sem essa conexão, toda a retórica fica sem importância e o patrocínio para o projeto sucumbe diante da primeira disputa por recursos com um incidente em produção ou com um projeto de negócio que dê retorno financeiro à empresa.

O que apresento a seguir uma uma abordagem de fato centrada no negócio desde a definição de escopo. Os passos sugeridos são:

1. Aproximar-se de alguns stakeholders do negócio. Esta é a pedra fundamental por que, assim como falta ao executivo conhecimento sobre a tecnologia, falta a você conhecimento sobre o negócio. Humildade é fundamental para construir pontes!
2. Identificar, junto a estes stakeholders, os macroprocessos de negócio que são críticos e que rodam em sistemas ou em infraestrutura de tecnologia.
3. Elencar, ainda com eles, riscos de negócio provenientes de desvios nestes processos críticos que poderiam ocorrer dentro dos sistemas. Exemplos seriam: “Fraudar pagamento para desviar dinheiro da empresa” ou “Paralisar uma planta produtiva por quarenta e oito horas” ou ainda “Disponibilizar para um concorrente o blueprint dos novos produtos que ainda estão sendo desenvolvidos”.
4. Mapear em quais sistemas, bancos de dados, servidores e equipamentos de rede rodam os macroprocessos críticos identificados no passo [2] e com isso definir o escopo de sua análise de vulnerabilidades.
5. Realizar a análise técnica e gerar a lista de vulnerabilidades tecnológicas classificadas e priorizadas.
6. Construir a ligação entre os conceitos, isto é, conectar cada vulnerabilidade grave e/ou explorável com um dos riscos de negócio mapeados no passo [3], cruzando o ativo da vulnerabilidade com o ativo em que o macroprocesso de negócio roda e conciliando o tipo de exploração da vulnerabilidade com o risco de negócio do respectivo macroprocesso.
7. Apresentar ao nível executivo os mesmos gráficos, metas e apontamentos de prioridade, trocando a descrição das vulnerabilidades pela descrição do risco de negócio que a exploração das vulnerabilidades poderia gerar.

Com isso, você estará substituindo um discurso do tipo:

“Encontramos 3 vulnerabilidades graves que permitem adulterar o banco de dados do sistema de reembolso de despesas”

por algo como:

“Encontramos 3 maneiras diferentes de desviar dinheiro da empresa através de reembolsos de despesas fraudulentos que podem ser gerados e efetivados sem aprovação do gerente, explorando fragilidades no sistema”.

Parece ser uma mera mudança de discurso, mas não é. Trata-se de uma mudança de paradigma, que provoca uma mudança de linguagem. Nela, se abandona a linguagem técnica e se adota a linguagem de negócio, que afinal de contas, é a única que o nível executivo fala e entende.

Quando vivemos a experiência de pensar Segurança da Informação como Negócio e de falar de Segurança da Informação como Negócio, presenciamos um resultado tão fantasticamente diferente, que o sentimento de realização impulsiona a internalização desse conceito que é tão importante: Vulnerabilidades só importam quando são Vulnerabilidades de Negócio, porque Segurança da Informação só é relevante quando estabelece Segurança para o Negócio.

Publicado originalmente em Blog Ticiano Benetti