A espinha dorsal de um bom trabalho de segurança com certeza é a análise de
risco. Sem ela, corremos o risco de tratar aquilo que é menos importante.
Porém, não é sempre que podemos começar por ela. O mundo não para, esperando
que tenhamos nossa análise pronta dizendo "o crítico é isso!". Além
disso, há outros pontos, como imagem, política, etc,
que contam no momento de escolher as primeiras ações. Eu pessoalmente vejo um
misto de ações "p/ a torcida", com o intuito
de ajudar na imagem da área de segurança (é importante!) e de ações
emergenciais, como instalação de patches críticos ou
até mesmo alteração de uma senha aqui ou acolá.
Depois, ou melhor, em paralelo, inicia-se um trabalho de entendimento da
empresa. O que ela faz? P/ onde ela quer ir? O que a
ameaça, em termos de negócio? Quais seus principais processos (por cima!)? Como
é a tecnologia que apóia tudo isso? Quem são as pessoas e funções chave? Com isso
é possível, para o bom consultor de segurança, identificar os pontos mais
perigosos. O trabalho pode usar como base alguma norma de
cálculo de risco, como a NIST 800-30. Sendo simplista:
RISCO = VULN x IMPACTO
Aonde o VULN seria a probabilidade de uma ameaça se concretizar através da
exploração de uma vulnerabilidade. Vejam que falamos de ameaça, e um bom pedaço
de dessa informação vêm do negócio.
Tomemos bancos como exemplo. Se estivermos pensando na ameaça de fraude por
parte de desenvolvedores internos, por exemplo. O quanto que isso é comum? Há
casos aonde isso acontece no mercado financeiro? Em termos de fraude
financeira, qual a facilidade do cara fazer isso? Acho que são informações que
só sairão de uma conversa com pessoas de negócio (estou incluindo operações),
habilmente conduzida por um bom consultor
de segurança.
O IMPACTO é outro componente simples se não houvesse o problema de processos e
sistemas interligados. Há também as diversas variantes quanto ao aspecto de
segurança atingido (C, I, A). A pessoa de negócio pode enxergar o impacto do
comprometimento da confidencialidade (é o que mais simples de ver), mas será
que ele consegue pensar nos
impactos referentes à integridade e disponibilidade sem a ajuda de um
profissional? Tentar simplificar isso com classificações acaba levando a
classificações demasiadamente complexas, o que sabemos que não funciona.
E quanto aos controles de COBIT, COSO, ISO17799, etc?
Por que não devo simplesmente aplicá-los, se é isso que todas as palestras por
aí dizem??
Por que não é só isso! Aquilo tudo são processos e ferramentas para trabalhar a
maturidade da segurança, mas não é o principal, e principalmente, não é começo,
como muita gente está pensando. Eu sou do time que não acredita em checklists mágicos. Se eles existissem, com certeza
teríamos a super-norma que resolveria os problemas de
segurança de todo mundo. Que pena (ou que sorte p/ nós!) que não é assim.
Em TI existe o papel do Analista de Sistemas, ou Business Analyst
ou sei-lá-que-nome, aquele cara que entende os
requisitos do negócio e passa p/ a fábrica de software desenvolver em uma
linguagem já uniforme e padronizada. Se uma tarefa como construção de software
ainda requer uma pessoa com essa inteligência, por que não seria
necessário ter o mesmo papel quando o assunto é segurança? O que torna os
requisitos de segurança tão diferentes a ponto de que podem ser entendidos de
maneira mais simples que um requisito de software?
A abordagem atual em construção de software é que o analista saiba a linguagem
do negócio, pois ele vai captar melhor os requisitos. A pessoa que vai usar o
software não precisa fazer se o que ele quer é um combo
box ou um text box, o analista entende a
necessidade. Já tentaram simplificar bastante esse processo, há várias
ferramentas,
mas ninguém tentou retirar a inteligência (como vivem tentando fazer em
segurança!).
A segurança não pode ser tão pretensiosa a ponto de acreditar que vai
"pasteurizar" todos os negócios para receber os requisitos sempre da
mesma forma e bem definidos. O negócio não faz isso com outras disciplinas, e
não vai fazer conosco. Ele existe por si próprio. Nós não. Nós existimos por
causa dele. Aí está a resposta de porque devemos ir
até ele, e não o contrário.