Segurança de aplicação e as ferramentas de teste

Lendo o post do Eduardo sobre a recente divulgação de um comparativo entre três ferramentas de teste de aplicações web, resolvi falar um pouco sobre o que penso sobre o tema.

Pra mim o problema todo é comparar bananas com laranjas. As ferramentas realmente não irão substituir a análise humana, são coisas distintas e complementares.

Outro ponto é, o tipo de ferramenta, as ferramentas cumprem o seu papel, o problema é o uso, expectativa que, se tem delas. O erro mais comum é comprar uma ferramenta e achar que ela irá cumprir todos os pontos relacionados a segurança de aplicação. Alguns vendedores podem usar este argumento, mas no geral todas deixam claro qual o seu propósito.

Para se garantir a segurança de uma aplicação várias atividades devem ser executadas. Atividades que eu classifico como antes, durante e depois do desenvolvimento da aplicação.

Antes

• Treinamento e capacitação
• Implementação de um processo que garanta que boas práticas de desenvolvimento sejam seguidas

Durante

• Acompanhamento e validação de requisitos de segurança
• Testes específicos durante o desenvolvimento

Depois

• Testes black-box buscando verificar a eficácia dos controles adotados durante o desenvolvimento

Portanto, as ferramentas funcionam, mas tem seu propósito bem claro. Apenas uma ferramenta de source review não resolve todos os problemas, assim como uma ferramenta de testes black-box também não.

E o ponto fundamental nesta comparação é: mesmo as ferramentas precisam de alguém capacitado para tirar o melhor delas e interpretar seus resultados e transformá-los em ações práticas para melhorar a segurança das aplicações.

Comunicação durante uma crise/incidente

Para muitos falar em público já é complicado, imagina durante uma crise grave envolvendo vítimas? Existem alguns guides sobre o tema, mas este link tem um apanhado bem completo: Golden rules for the crisis spokesperson.

Política de Segurança da Informação, como não fazer

Eu assino o feed do efetividade há muito tempo, sempre gostei do conteúdo, agora hoje fiquei surpreso com um post: Política de Segurança de Informação: um modelo de como não fazer.

No post ele comenta sobre falhas comuns em PSI (Políticas de Segurança da Informação), não esperem uma avaliação técnica, mas sim um apanhado de coisas óbvias e simples que muito profissional de segurança sênior não é capaz de evitar quando desenvolve uma PSI. Recomendo a leitura, mas segue alguns pontos.

"Tranque tanto a infra-estrutura, que trabalhar se torne complicado demais. Complemento do comentário acima. E há um risco adicional: os usuários vão encontrar “jeitinhos”, como o uso de cópias locais, versões antigas e mídias não-autorizadas." Isso aqui é comum entre profissionais de segurança que só viram as coisas nos livros.


"Diga “não” sempre que lhe solicitarem alguma aprovação. Assumindo que você tenha força suficiente para sustentar um comportamento deste tipo, aí quem vai encontrar jeitinhos serão departamentos inteiros, filiais, e outros agregados." Esta é hilária, quem nunca viu aquele cara do comercial, executivo, soltando pérolas: "Segurança é o escambal eu quero é vender".

"Imponha requisitos de segurança sem as ferramentas e treinamento adequados. Vira letra morta, e ainda por cima custa caro. Segurança precisa ser praticada por todos, o que pressupõe ferramentas e educação." Exatamente isto, a maioria das PSI são "compliance" e nunca aumentaram em nada a segurança das organizações.

"Espere que o SSL resolva todas as questões de segurança de seus aplicativos web. SSL é só o mínimo necessário, e o “cadeadinho fechado” no rodapé do navegador não protege contra as falhas na programação ou na arquitetura." Cadeadinho é ótimo, engraçado que até hoje eu vejo "especialista" falando do cadeadinho na televisão.

"Proíba o uso de pen drives, sem delimitar o acesso à Internet. Os mesmos arquivos que podem entrar ou sair via pen-drive podem fazê-lo via uma grande variedade de sites na Internet. Pen drives são uma
ferramenta, mas o que deve ser restrito é trazer ou levar os arquivos não autorizados que se queira impedir. Só proibir os pen drives é incômodo e ineficaz." Esta é para aqueles que querem implementar todo tipo de controle de end-point e acham que estão seguros.

"Adote novas tecnologias antes que elas tenham maturidade suficiente. Folders, livretos, exposições e as conversas dos vendedores devem ser tomados em conjunto com doses saudáveis de consideração" Bota dose de consideração nisso.

"Contrate alguém só porque ele tem um monte de certificações." Ah, não esqueça de pedir os certificados impressos.

"Exija que seus usuários troquem de senha com muita frequência. …e eles adotarão esquemas fáceis de lembrar (e quebrar), ou escreverão as senhas em algum lugar de fácil acesso." Falar sobre política de senhas merece um post a parte, mas no geral é só um copy-paste de uma política pra outra, a senha tem que ter no mínimo trocentos caracteres...Hum o mainframe só aceita 4 e numérico, F&^&^*&^$&^%^%.

"Ignore requisitos legais. Não é razoável: proibir o que uma norma superior permite, permitir o que a lei proíbe, atribuir a si mesmo o poder de realizar verificações ou praticar ações que potencialmente
violem direitos alheios. Mesmo assim muita gente tenta, todos os dias, e se dá mal na hora de colocar em prática." Isso, monitora, coloca keylogger, as máquinas são da empresa e está na política que vai ser monitorado.

"Assuma que os usuários irão ler a política de segurança porque você pediu a eles. Eles só o farão se precisarem muito. Publicar pode ser o suficiente para que eles venham a conhecer as linhas gerais, eventualmente distorcidas pela Rádio Corredor. Para que os usuários conheçam uma política
detalhadamente, é preciso recorrer a outros meios de educação. Na prática, você não pode assumir nem mesmo que toda a equipe de TI, ou que a maioria dos executivos, vá ler a norma." Se você não vai fazer nada para implementar a política, nem escreva, salve algumas árvores.

"Crie políticas de segurança que você não poderá fazer cumprir. Uma norma cujo cumprimento não é (ou não pode ser) exigido pode ser até mesmo pior do que a ausência de normatização, e acaba servindo apenas para punir culpados depois que a porta já estiver arrombada e as vacas
tiverem fugido do estábulo." Quanto mais diretrizes melhor, é mais compliance.

"Assuma que as políticas não se aplicam aos executivos. Se houver exceções, elas devem constar na norma, e não podem comprometer sua eficácia. Pouco adianta todo o restante do esforço se um gerente puder trazer um pen drive de casa para instalar um programa ou compartilhar um arquivo em uma máquina da rede local. Uma variante do mesmo erro: “Assuma que as políticas não se aplicam ao pessoal de TI”." Executivos? Geralmente nem a área de segurança cumpre as diretrizes por eles impostas.

"Deixe seu anti-vírus, IDS e outras ferramentas rodando no piloto automático." Ué, paguei uma grana nas ferramentas pra que?

"Tente aplicar o mesmo rigor a todos os ativos de informação, independente do seu perfil de risco. Fica
bem mais caro do que deveria, atrapalha processos sem necessidade, e prejudica bastante a adoção e internalização pelas pessoas envolvidas" Hum, gestão de riscos? Mas eu já tenho uma PSI.

"Dê a alguém o título de Gestor dos Riscos, mas não lhe dê o poder de tomada de decisões correspondente. Ele terá que optar entre se omitir, ou ser o chato que fica apontando
riscos nas atividades alheias podendo ser ignorado, ou ainda saber que está lá só para levar a culpa" Quem está nesta situação deixa um post no blog. Hum melhor não, vai encher meu blog de conteúdo inútil.

"Ignore o quadro geral, e se concentre nas análises quantitativas. É mentalmente desafiante e muito interessante aplicar os modelos matemáticos de quantificação de riscos, mas eles não podem substituir a visão do todo, e sim complementá-la." ROSI, ROS, uhuhu

"Classifique todos os seus dados como “top secret”. Nivelar por cima, nesse caso, tem praticamente o mesmo efeito que nivelar por baixo." É classificação da informação e não "rotulação" da informação.

Recomendo a leitura, você vai dar boas risadas e ainda pode aprender um pouco sobre PSI. Só não vai ficar deprimido caso se enquadre em muitas das coisas listadas.

Analisando código php encriptado

Stefan Esser publicou informações bem interessantes sobre o core do php. Na última 25C3 ele fez uma apresentação demonstrando como é possível fazer análise em códigos encriptados usando bibliotecas de encriptação de Bytecode como: ZendGuard, ionCube PHP Encoder e SourceGuardian.

Segundo o paper mesmo com técnicas de anti-hooking e decryption é possível analisar o código devido as padrões do bytecode que são mantidos. Leitura altamente recomendada.

u-Con 2009

Em Fevereiro vai acontecer em Recife, mais uma edição de uma das principais conferências sobre hacking/security. Estarei lá ministrando um treinamento de Web Hacking Techniques e a Conviso está apoiando o evento.

Mais informações no site da conferência, como diria meu amigo sp0oker: Happy Hacking!