You are currently browsing the monthly archive for Janeiro, 2007.
Uma solução para os assaltos do futuro:
As habilidades técnicas permitem ao profissional de SI agir em diversas frentes, de acordo com suas respectivas especializações, no entanto, existe uma habilidade que pode ser empregada tanto na forma de especialização, quanto como um importante complemento para outras áreas de atuação: Gestão de processos.
Quando falo em gestão de processos, não me refiro a uma posição hierárquica, com responsabilidades por processos, mas sim a capacidade de transformar as atividades profissionais, em uma seqüência de atividades, que atinge um resultado esperado. Muitas vezes eu bejo profissionais de SI atuando de formas que tornam as demais áreas “dependentes” deles.
Um exemplo claro é a execução de um hardening do sistemas operacional. Tipicamente o profissional vem, executa uma série de scirpts, ou muda as configurações manualmente, vai embora e se der algum problema a área de sistemas operacionais deve correr atrás de sua ajuda para resolver o problema.
Não seria melhor trabalhar em conjunto com a área que está sendo afetada, buscar em parceria a confecção de um conjunto de controles que mitiguem os riscos identificados e que a área entenda as razões e seus impactos? Não poderiamos complementar este trabalho criando um sistema de gestão que possibilite o mapeamento dos controles implementados em cada ativo e as exceções que tiveram de ser aplicadas para sanar problemas que poderiam impactar o negócio?
Este tipo de ação é a base de processos que todo profissional de segurança deve ter. Uma das razões disso, é assegurar que os procedimentos executados sejam conhecidos e com eficácia comprovada. Isso também possibilita que as áreas envolvidas sejam capazes de elas próprias executar os processos, reduzindo a carga sobre a área de SI, que tipicamente está sobrecarregada, e mantendo um controle constante mesmo quando SI não está presente.
Processos do negócio
Outra capacidade importante para o profissional de SI, é a habilidade de entender os processos do negócio e criar controles que interajam com eles de forma simbiótica, semelhante ao que qualidade faz com métodos Poka Yoke (Mistaken Proof). No Poka Yoke, um máquinário pode ser desenhado de maneira que ele somente possa ser acionado se o operário utilizar as duas mãos, evitando que ele sofra algum acidente e perca um dedo, por exemplo.
Similamente, o profissional de SI, que atua ligado diretamente ao negócio, deve buscar formas de proteger os ativos de informação de um modo que seja intuitivo e que não seja impeditivo para os negócios. Na definição destes controles, o entendimento dos negócios é fundamental, pois sem isso não é possível priorizar e proteger o que é realmente importante. Por isso ele deve empregar seus conhecimentos para guiar os gestores das áreas envolvidas, ou outras pessoas com grandes conhecimentos no processo avaliado, para direcionar adequadamente as atividades sendo desenvolvidas. Sua experiência, em conjunto com as dos demais envolvidos, possibilitarão a implementação dos controles mais adequados para o processo sendo protegido.
Duas das principais características deste profissional é a habilidade de relacionamento interpessoal e a organização e método na execução de suas atividades.
Um base técnica também é importante, para que este profissional seja capaz de interagir com TI, e buscar formas de implementar nos sistemas parte dos controles identificados e também interagir com os demais controles existentes, evitando um emaranhado de proteções que ninguém entende ou sabe se tem alguma serventia.
A medição da eficácia dos controles é outra atividade importante que estes profissionais podem desempenhar. Nesta atividade, um dos objetivos é identificar quais proteções tem se mostrado mais ou menos eficientes e buscar uma variação da curva da vitalidade, do Jack Welch, nos controles de segurança. As proteção que tem pouca efitividade devem ser substituídas por novos controles, que busquem os mesmos objetivos, mas de formas mais eficazes. Os controles de grande valia, devem ser aprimorados e empregados em mais processos. Com isso além de evitar o desperdício de tempo com atividades de pouco valor agregado, existe uma evolução na cultura e no conhecimento corporativo, que pode tornar as atividades cada vez mais intuitivas e menos intrusivas, pois cada vez mais áreas da organização estarão capacitadas na execução de controles de alto desempenho.
Outro dia ouvi um argumento de que um produto era seguro por que era feito por uma empresa séria, com N anos no mercado. Depois da Segurança por Obscuridade, vem a Segurança por Reputação? Qual será a próxima, Segurança por Boa Vontade?
Assino em baixo na excelente análise do Aylton sobre certificações. Num tema polêmico como este, é raro ver uma argumentação tão bem elaborada. Nem defendendo, nem atacando cegamente, como muitos fazem, simplesmente mostrando os prós e contras e permitindo a cada que tire suas próprias conclusões com base nas informações recebidas.
Aylton, espero ver muitos outros posts e artigos teus.
Segundo o site do Senado Federal:
“11/01/2007 CCJ – Comissão de Constituição, Justiça e Cidadania
Encaminhado à Secretaria-Geral da Mesa, para atender ao disposto no art. 332, do Regimento Interno do Senado Federal (Final da 52ª Legislatura). (Tramita em conjunto com o o PLS nº 137, de 2000, e com o PLC nº 89, de 2003 ) À SSCLSF. “
O referido artigo 332 diz:
“Art. 332. Ao final da legislatura serão arquivadas todas as proposições em tramitação no Senado, exceto:(*)
I – as originárias da Câmara ou por ela revisadas;(*)
II – as de autoria de Senadores que permaneçam no exercício de mandato ou que tenham sido reeleitos;(*)
III – as apresentadas por Senadores no último ano de mandato;(*)
IV – as comparecer favorável das comissões; (*)
V – as que tratem de matéria de competência exclusivado Congresso Nacional (Const., art. 49);(*)
VI – as que tratem de matéria de competência privativa do Senado Federal (Const., art. 52);(*)
VII – pedido de sustação de processo contra Senador em andamento do Supremo Tribunal Federal (Const., art. 53, §§ 3o e 4o, EC no 35/2001).(*)
§ 1o Em qualquer das hipóteses dos incisos do caput, será automaticamente arquivada a proposição que se encontre em tramitação há duas legislaturas, salvo se requerida a continuida de de sua tramitação por 1/3 (um terço) dos Senadores, até 60 (sessenta) dias após o início da primeira sessão legislativa da legislatura seguinte ao arquivamento, e aprovado o seu desarquivamento pelo Plenário do Senado.(*)
§ 2o Na hipótese do § 1o, se a proposição desarquivada não tiver a sua tramitação concluída, nessa legislatura, será, ao final dela, arquivada definitivamente. (NR)(*)
(*) Resolução no 17/02″
Antes de continuar a falar sobre o assunto, gostaria de elucidar alguns pontos que o Paulo levantou em seu comentário para o meu post anterior. Quando falei sobre Generalista x Especialistas, eu estava complementando o que ele havia dito na entrevista ao falar sobre profissionais de “Network/Computer Security”. Eu só abro uma ressalva, que eu entendo que havendo recursos para tanto, pode haver segregação mesmo nesta função. A pessoa com grandes conhecimentos de redes, roteadores, etc, não é necessariamente um especialista na plataforma Microsoft, ou Unix, ou AS/400 ou Mainframe. O mesmo vale para qualquer caso similar (ex.: o especialista de Microsoft pode ter parcos conhecimentos de Unix ou redes).
Isso é principalmente válido quando começamos a falar sobre segurança em aplicações, e sobre linguagens e tecnologias específicas, existe um limite para a capacidade de prover segurança por um profissional genérico. Um profissional de segurança de redes pode ajudar a previnir casos de XSS, SQL Injection e outros mais óbvios quando vistos do lado de fora, mas pode deixar passar muitos outros casos, como um Covert Channel.
Quanto a análise do resultado das ferramentas de varredura, concordo em gênero, número e grau com o Paulo. Ele apontou um ponto que eu esqueci de mensionar: Ferramentas ajudam na produtividade, mas é preciso avaliar o que elas produzem antes de iniciar uma ação corretiva.
Uma coisa que sempre gostei de fazer é correlacionar o resultado das falhas encontradas e repriorizar as vulnerabilidades com base neste correlacionamento. Algumas vezes a ferramenta indica N falhas críticas, para as quais já existem contra-medidas aplicadas, como um firewall que não deixa aquele serviço específico disponível, mas sem esta análise seria dispendido tempo no tratamento urgente de falhas com baixa probabilidade de efetivação. Outras vezes, as ferramentas mostram brechas que são classificadas como de baixa ou média criticidade, mas que em conjunto podem significar um grande risco para o sistema. Certa vez uma ferramenta me mostrou que havia uma falha, classificada como média, que possibilitava a obtenção de um shell remoto desde que o atacante tivesse acesso a uma série de informações. No entanto, haviam outras no sistema, que tornavam quase todas aquelas informações disponíveis, exceto a listagem de usuários, para usar uma identificação no ataque. Mas havia um outro sistema que permitia listar seus usuários, como os userids eram identicos todas as informações disponíveis estavam acessíveis e assim, uma falha média e algumas baixas, como classificado pela ferramenta, na verdade representavam um alto risco para a organização.
Outra razão para isso, é que muitas ferramentas, talvez tentando mostrar trabalho, são extremamente prolixas, porém fornecendo informações de pouco qualidade ou relevância, como avisos de presença de banners, que as vezes sequer verifica se é um banner padrão ou algo personalizado.
PS.: Paulo, meu post não foi resposta a sua entrevista ou as sua opniões, apenas entrei no embalo e apresentei as minhas visão do assunto, coisa que a muito tempo eu queria fazer.
