Gerência de Riscos Não É Dizer "Não"

"Não, eu não vou abrir a porta 445 para a sua aplicação! Essa porta é inseguuuuraa!"

A recente série de tiras do Dilbert sobre segurança da informação (essa sobre biometria é espetacular) retrata como os profissionais de segurança são vistos em muitas organizações: como um chato que impede as pessoas de trabalhar. Adam Shostack fala sobre o mesmo assunto aqui, mencionando um colega que era conhecido como "Dr. No" porque dizia "não" para todas as iniciativas.

Gerenciar riscos consiste em tomar decisões levando em conta tanto os benefícios quanto os potenciais problemas. Ao agir como um "Dr. No", o profissional de segurança não está gerenciando ricos, está evitando riscos. "Opa, e isso não é bom?" Não. A função da Segurança é viabilizar o negócio mantendo os riscos em nível tolerável, e não evitar riscos. Especialmente se no processo de evitar os riscos você inviabiliza o negócio.

Uma visão errada de risco não é a no entanto única causa do surgimento dos "Drs. No" nas organizações. Os incentivos também têm um papel primordial - se o profissional de segurança não tem nada a ganhar diretamente com a empresa viabilizando uma nova linha de negócio, e tudo a perder se houver um incidente de segurança nela, é óbvio que ele vai tomar a posição mais aversa ao risco possível. E, por fim, dizer "não" significa exercer poder, e isso também tem uma enorme atração para o ego.

Mas ninguém se torna um "empata-negócio" impunemente. Subitamente a área de Segurança não é mais envolvida nos novos projetos, e só é convidada a participar no último momento quando a situação já foi tornada irreversível. O chamado "apoio executivo" também desaparece rapidamente, porque altos executivos sabem exatamente onde estão as prioridades do negócio e não dão apoio a quem está jogando contra. O resultado do comportamento do "Dr. No" é uma área de Segurança fraca e frustrada.

Há cura para isso? Talvez não totalmente, porque os incentivos vão continuar a ser conflitantes. Mas existem algumas ações que a área de Segurança pode tomar para diminuir esta distância e deixarem de ser  "Drs. No" marginalizados dentro da empresa.

A primeira é saber comunicar o riscopara as áreas de negócio. Vamos deixar claro uma coisa: uma porta de rede aberta não é um risco. Uma pessoa externa ter acesso a um documento confidencial é um risco. Só existe risco quando ele afeta o negócio. Além de facilitar o entendimento, traduzir os riscos em termos de impacto no negócio funciona também como um teste: se você não conseguir fazer isso, é porque provavelmente não existe risco nenhum.

A segunda é ser previsível. Ninguém gosta de fazer um projeto e depois ter ele bloqueado por uma regra desconhecida que às vezes sequer está escrita. Uma obrigação da área de Segurança é traduza o perfil e o nível de tolerância a risco da organização em políticas e normas de segurança, e principalmente construir um consenso com todas as áreas em torno dessas políticas e normas (explicar os riscos em termos de negócio ajuda bastante aqui). Ter um critério claro não só vai ajudar a sua argumentação como também ajudar as áreas de negócio a planejar as suas ações, sabendo de antemão o que é tolerável em termos de risco e o que não é.

Como diz Adam Shostack no seu post, ter um critério claro e previamente aceito do que é permitido ou não foi essencial para que o processo de desenvolvimento seguro fosse aceito na Microsoft, e isso vale para qualquer outra iniciativa de segurança.

Por fim, forneça alternativas quando você identificar que determinado projeto ou recurso está intolerável em termos de risco. O papel da área de Segurança não é só dizer o quê fazer, mas como fazer. Ao tomar uma atitude passiva e dizer simplesmente "não", a área de Segurança se torna parte do problema ao invés de ser parte da solução.

UPDATE: O Gartner Group criou um quadro que faz uma excelente comparação entre uma área de Segurança "tradicional" - repleta dos "Drs. No" - com uma área de Segurança "adaptativa" e alinhada ao negócio.

Fonte: Articulating the Business Value of Information Security , Tom Scholtz, Gartner IT Security Summit 2006.