Software Seguro

Evento SECURITY_AUDIT da ESAPI

2011-12-08T11:41:00.002-02:00

Assim como publicado no Javadoc da ESAPI (aqui), o seu logging permite usarmos a dimensão segurança para categorizar os eventos. Estão disponíveis as seguintes categorias:

EVENT_FAILURE – eventos não relacionados a segurança que apresentaram falhas.
EVENT_SUCCESS – eventos bem sucedidos não relacionados a segurança.
EVENT_UNSPECIFIED – eventos não relacionados a segurança sem determinação do seu sucesso/falha.
SECURITY_AUDIT – eventos associados a uma trilha de auditoria, cujo resultado pode ser de sucesso ou falha ou ser irrelevante.
SECURITY_FAILURE – eventos relacionados a segurança que apresentaram falhas.
SECURITY_SUCCESS – eventos bem sucedidos não relacionados a segurança.

A classificação de registros de log pela segurança repercute muito positivamente no trabalho de resposta e prevenção de incidentes. Caso essa lista não atenda as suas necessidades, ela pode ser facilmente extendida.

Eu particularmente acredito que ela seja mais do que suficiente. De fato, não faria nenhuma adição de categoria. Ao contrário, faria apenas a subtração de SECURITY_AUDIT, pois no meu entendimento, todas as outras categorias podem, eventualmente, compor a trilha de auditoria. A reprensentação mais adequada delas, considerando esse entendimento, seria o diagrama de venn abaixo:

FindBugs Gerenciado pelo Sonar

2011-09-15T08:36:00.000-03:00

O FindBugs é uma ferramenta de revisão estática de código fonte que analisa código Java. A efetividade de uma ferramenta de análise estática é consequência principalmente do conjunto de regras ou assinaturas que ela possui. Para o caso do Findbugs, existem duas categorias de regras que merecem maior atenção da segurança. São elas : malicious code e security. As regras que estes dois conjuntos englobam podem ser observadas na tabela a seguir:

Categoria	Regra
MALICIOUS CODE	DP_CREATE_CLASSLOADER_INSIDE_DO_PRIVILEGED
MALICIOUS CODE	DP_DO_INSIDE_DO_PRIVILEGED
MALICIOUS CODE	EI_EXPOSE_REP
MALICIOUS CODE	EI_EXPOSE_REP2
MALICIOUS CODE	FI_PUBLIC_SHOULD_BE_PROTECTED
MALICIOUS CODE	EI_EXPOSE_STATIC_REP2
MALICIOUS CODE	MS_CANNOT_BE_FINAL
MALICIOUS CODE	MS_EXPOSE_REP
MALICIOUS CODE	MS_FINAL_PKGPROTECT
MALICIOUS CODE	MS_MUTABLE_ARRAY
MALICIOUS CODE	MS_MUTABLE_HASHTABLE
MALICIOUS CODE	MS_OOI_PKGPROTECT
SECURITY	DMI_CONSTANT_DB_PASSWORD
SECURITY	DMI_EMPTY_DB_PASSWORD
SECURITY	HRS_REQUEST_PARAMETER_TO_COOKIE
SECURITY	HRS_REQUEST_PARAMETER_TO_HTTP_HEADER
SECURITY	SQL_NONCONSTANT_STRING_PASSED_TO_EXECUTE
SECURITY	XSS_REQUEST_PARAMETER_TO_JSP_WRITER
SECURITY	XSS_REQUEST_PARAMETER_TO_SEND_ERROR
SECURITY	XSS_REQUEST_PARAMETER_TO_SERVLET_WRITER

O baixo número de regras, nem a limitação para avaliação de outras linguagens, como JSP ou o framework JSF, não são justificativas para descartar o uso dessa ferramenta, uma vez que a sua varredura pode revelar alguns dos riscos de segurança mais críticos como, por exemplo, SQLInjection e XSS. Outro ponto forte do Findbugs é a sua gratuidade.

A execução de varredura pelo Findbugs é tão simples, quanto o entendimento de seus parâmetros de linha de comando. Segue o exemplo de comando:

<caminho máquina para o findbugs>/findbugs/lib/findbugs.jar -textui -effort:max -sortByClass -low -html -output <caminho destino do relatório>/findbugs.html <caminho onde se encontra  jar>/teste.jar

Os detalhes sobre os parâmetros podem ser observados aqui.

Entretanto, na maioria dos casos, existe a necessidade de revisar o resultado da varredura, eliminando os falsos positivo. Além disso, é desejável que se tenha um histórico do bugs revelados e de suas correções. Esses recursos não são nativos do Findbugs. Uma das alternativas, além de escrever seu próprio aplicativo bugtracker é o uso do Sonar.

O Sonar é uma plataforma para gestão de qualidade de código que já possui instalada em sua versão de instalação o plugin do Findbugs. Por ela, é possível gerenciar dentre diversos bugs, aqueles revelados pelo Findbugs.

Como a documentação do Sonar é muito completa, registro alguns pontos relevantes para colocá-lo em uso.

Download

http://www.sonarsource.org/downloads

Instalação

http://docs.codehaus.org/display/SONAR/Install+Sonar

http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task

Configuração

Como nosso enfoque é segurança, vamos configurá-lo para que use somente as regras de segurança do Findbugs. Para as configurações relacionadas a seguir considere a instalação padrão do Sonar.

1. Acesse o link http://127.0.0.1:9000/profiles

2. Copie o profile Sonar way with Findbugs e dê o nome Findbugs-Sec

3 - Clique no botão Set as default.

4 - Entre no profile Findbugs - Sec e desative todas as regras.

5 - Ative todas as regras da categoria Security:

6 - Ative todas as regras da categoria Malicious Code.

A partir deste ponto o Sonar está preparado para usar apenas as regras das categorias Security e Malicious Code.

Varredura

Para realizar a varredura existem três possibilidades (Maven, Ant e Java Runner), mas optamos pelo uso do Ant.

No arquivo build.xml de sua aplicação, introduza o conteúdo a seguir:

Agora, basta rodar o Ant direcionando para a tarefa sonar (ex.: .\ant sonar). No exemplo da imagem a seguir, foi realizada a varredura do Webgoat 5.2.

Arremate

Com o Sonar em operação pode-se monitorar a evolução dos bugs de segurança com maior facilidade. O exemplo abaixo mostra o resultado de duas varreduras no Webgoat 5.2, sendo que uma mudança no código gerou uma vulnerabilidade Blocker e eliminou outra Critical.

É importante ressaltar que os resultados são provenientes do Findbugs, consequência do seu conjunto de regras, mostradas anteriormente.

O uso dos recursos apresentados aqui são mais apropriados para casos em que a organização esteja pensando em adotar uma ferramenta de análise estática de segurança de código fonte. Considero a sua operação, como um primeiro passo antes da aquisição de ferramentas de mercado.

A OWASP, você e a segurança de software

2011-08-17T10:41:00.003-03:00

Na última semana concluímos uma maratona de treinamento introdutório em segurança de software. Foram 9 turmas, alcançando 183 profissionais, envolvendo programadores, analistas de teste, analista de infraestrutura, arquitetos e outros. A experiência foi parte de um programa de segurança de software orientado pelas práticas do Build Security In Maturity Model (BSIMM). Neste caso, atendendo as seguintes atividades da prática Treinamento:

T1.1 - Forneça treinamento de conscientização.
T2.2 - Crie/use material específico da história da empresa.
T3.2 - Forneça treinamento para fornecedores e profissionais terceirizados.

Ao longo do treinamento procurei registrar o estado da turma acerca da segurança de software observando as seguintes questões:

Quem já vivenciou algum treinamento em segurança de software? Ressaltando que treinamento em segurança da informação, apesar de muito oportuno, não é a mesma coisa.
Quem conhecia Injeção de SQL?
Quem conhecia Cross Site Scripting (XSS)?
Quem conhecia a OWASP?

Dos 183 alunos, 14(7,65%) já haviam participado de treinamento em segurança de software, 32 (17,5%) conheciam Injeção de SQL, 1(0,5%) conhecia XSS e nenhum aluno conhecia o termo OWASP.

Os dados em si, não são muito reveladores, uma vez que é amplamente difundida a defasagem dos profissionais do mercado em segurança de software (aqui). Mesmo tendo isso em mente, surpreende o fato de nenhuma pessoa ter sequer ouvido falar no termo OWASP.

É preocupante, pois a OWASP está ai fora há quase 10 anos e isso (desconhecimento) pode impedir que ela alcance o seu propósito: “Be the thriving global community that drives visibility and evolution in the safety and security of the world’s software.” (aqui).

Talvez seja esse o principal desafio para o próximo board (aqui) da OWASP. Eu, particularmente, tenho plena convicção que os desenvolvedores podem promover mudanças sensíveis na segurança do seu software, a partir de simples sensibilização e instrução de técnicas de defesa. Não há, no meu entendimento, outro movimento/canal no momento, com maior concentração e organização de conteúdo sobre a segurança de software. O maior problema é que a mensagem de segurança não chega até o desenvolvedor.

Uma vez que o problema está exposto, o que podemos fazer para mudar esse cenário? Seguem duas sugestões, pra começar:

Sustente - Você que consome o conteúdo OWASP, qual foi a última vez que você divulgou o projeto? Por que não falar para o desenvolvedor que se encontra do seu lado, ou aquele colega de universidade sobre a segurança de software e a OWASP para sua pesquisa? Estabeleça sua meta de disseminação. Obviamente, você pode contribuir, produzir conteúdo, traduzir, etc.

Fiscalize - Você que está associado a algum capítulo da OWASP, conhece o board? Você sabia que a OWASP recomenda fortemente que haja pelo menos dois líderes para que as atividades sejam distribuídas (aqui)? Qual foi o último evento promovido pelo seu capítulo? O board do seu capítulo está comprometido com a OWASP ou somente com a sua autopromoção? Qual a disponibilidade do board para as atividades do capítulo? Seu capítulo é considerado ativo (>5 eventos ano)? Cobre!

E você, o que tem a sugerir? Escreva ai embaixo!

Um ataque man-in-the-middle ao SSL via SSLStrip

2011-07-11T09:55:00.024-03:00

No ataque man-in-the-middle (MITM) o atacante intercepta a conexão entre a vítima e o servidor de maneira a analisar todos os dados da comunicação, conforme representado pela Figura 1. Além disso, o atacante “finge” ser a vítima na comunicação com o servidor. Uma condição para execução do man-in-the-middle é que a vítima e o atacante estejam na mesma subrede.

Para este teste aconselha-se a utilização da distribuição linux BackTrack, que apresenta na sua versão 5 várias ferramentas para teste de penetração. Dentre elas existem 6 para análise do SSL: ssldump, sslh, sslsniff, sslstrip, testssl.sh e thcsslcheck.

Figura 1 – Ataque man-in-the-middle, fonte OWASP.

SSLStrip

O SSLStrip é uma ferramenta desenvolvida por Moxie Marlinspike, apresentada pela primeira vez na black hat 2009 na palestra “New Tricks For Defeating SSL In Practice”. Pode-se descrever brevemente o funcionamento do SSLStrip da seguinte maneira:

A partir de um ataque de arp spoofing é possível modificar o cache arp da máquina da vítima de maneira que o endereço MAC do atacante se passe pelo endereço MAC do roteador, assim o alvo começa a enviar para o atacante todo o seu tráfego. O kernel da máquina do atacante redireciona o tráfego que não é destinado a porta 80 (http) ou 443 (https) para o roteador autêntico. O tráfego destinado para a porta 80 (http) ou 443 (https) é redirecionado para uma porta de escuta $listenPort, que por padrão é a 10000. Neste ponto, o SSLStrip recebe o tráfego http e realiza o ataque.

Portanto podemos dividir o ataque em 4 passos realizados a partir da máquina do atacante:

Ativar o modo de redirecionamento de todo tráfego que passa pela máquina pelo comando:
echo "1" > /proc/sys/net/ipv4/ip_forward

Configurar a tabela de roteamento (iptables) para redirecionar o tráfego HTTP para o SSLStrip pelo comando:
iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port "listenport"

Rodar o SSLStrip especificando a porta de escuta, caso não seja passada nenhuma porta como argumento será considerada a 10000:
sslstrip.py -l "listenport"

Rodar o arpspoof com o intuito de configurar todas as máquinas da subrede a enviarem seus respectivos tráfegos:
arpspoof -i "interface" -t "targetip" "gatewayip"

Exemplo de execução dos passos

echo "1" > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000

sslstrip.py -l 10000

Em outro terminal: arpspoof -i eth0 -t 10.0.0.15 10.0.0.254

Sessão

O SSLStrip pode possibilitar um ataque de sequestro de sessão. Este ataque consiste em explorar o mecanismo de controle de sessão, o qual é normalmente gerenciado através de um token de sessão. Após decifrar a conexão através do SSLStrip o atacante consegue visualizar toda a requisição HTTP, portanto também terá acesso ao token de sessão. De posse do token de sessão o atacante pode forjar requisições como se fossem originadas pelo usuário legítimo.Exemplo de uso do SSLStrip para realizar um sequestro de sessão:

Logging de Aplicação

2011-06-10T15:40:00.001-03:00

O logging é uma dimensão muito importante de uma aplicação, mas que é amplamente negligenciada durante o seu processo de design, assim como a segurança de software. Não é a toa que uma das práticas iniciais recomendadas pelo BSIMMv2 (AA1.1) dê enfoque aos mecanismos de segurança, conteúdo no qual o logging se enquadra.

Talvez seja o fato dos principais interessados: auditor, desenvolvedor e administrador do sistema, não estarem tão interessados assim, desde o princípio (abordagem build security outside in). O administrador do sistema normalmente não é estimulado a pensar nos sinais que a aplicação deva lhe fornecer para atuar diante de questões de produção. O auditor só chega em cena, depois que o circo começa a pegar fogo, ou por imposição regulatória. Já o desenvolvedor, se vale das ferramentas de debug para resolver os problemas de código, desdenhando do log.

Mas considere que você esteja numa situação privilegiada, na qual pode pensar em logging antes que necessite de fato do log. Que caminho seguir? De forma bem objetiva e resumida recomendaria as seguintes etapas para o sucesso da sua iniciativa de logging.

Reconheça a aplicabilidade do log
Para reconhecer a aplicabilidade é fundamental levantar que cenários serão tratados pela sua organização. Isso pode partir das atividades comuns dos papéis citados anteriormente. Por exemplo, o auditor precisará atuar diante de cenários que envolvam ataques, uso inadequado e falhas. Já o desenvolvedor e o administrador se interessariam mais por cenários de falhas, erros e desempenho. Inclua as seguintes questões durante a sua análise:

A que servirá o log? Essa questão lhe ajudará a se afastar da tecnologia e perceber que o log possui um objetivo e que este deve ser o foco. Temos alguns exemplos:

Garantir não repúdio de ações executadas por usuários autênticos.
Reconhecer fluxos de execução ou entradas para a aplicação reconhecidamente suspeitas.
Identificar a linha do código fonte que comprometeu a execução da aplicação.
Mostrar a pilha de execução relacionada a determinado falha da aplicação.
Recuperar os dados que eram processados no momento de alguma falha.
Reconhecer quando determinados eventos são iniciados e concluídos.
Reconhecer o tempo de processamento de determinadas ações da aplicação.
Reconhecer o estado de recursos, como espaço disponível em disco.

Como o log será consumido? Essa questão vai influenciar diretamente no conteúdo do log, que deverá ser elaborado para que as diferentes formas de consumo sejam possíveis.

Manualmente com/sem apoio de ferramentas automatizadas ou automaticamente.

Qual a origem dos registros do log? Definição que lhe orientará quanto a dinâmica para consolidar os registros, além de dar um tratamento homogêneo independente da origem.

Aplicação, WAF, servidor de aplicação, etc.

Como o log será armazenado? Sua infraestrutura terá que estar preparada para receber os registros, garantir a sua segurança, oferecer acesso concorrente, etc.

Arquivo, banco de dados e/ou console.
Dimensão máxima da base.
Segmentação do arquivo.

Defina o conteúdo do log
Uma vez que se tem a noção do que se espera do log e do ambiente em que ele estará inserido, chega o momento da definição do seu conteúdo. Uma abordagem bastante interessante é o reconhecimento dos eventos que devem ser encontrados no log. Como nosso interesse está muito voltado para segurança, nada mais natural que tratar de tais eventos. Anton Chuvakin e Gunnar Peterson sugerem os seguintes eventos:

Autenticação, autorização e acesso:

Decisões com falha ou sucesso relacionadas a autorização e autenticação.
Acesso a sistema, a dados e componentes; e
Acesso remoto, incluindo aqueles entre componentes de uma mesma aplicação em ambientes distribuídos.

Mudanças:

Mudanças em sistema ou aplicação (especialmente quando envolva alteração de privilégios).
Mudanças de dados (incluindo a criação e destruição), e
Instalação e mudanças em componentes e aplicações.

Problemas de disponibilidade:

Inicio e encerramento de sistemas, aplicações e módulos ou componentes de aplicações, e
Sucesso e falhas de backup que afete disponibilidade.

Problemas com recursos:

Recursos excedendo suas capacidades.

Problemas com conectividade.
Limites estourados.

Indicação de ameaças:

Entradas inválidas ou outros abusos da aplicação.
Outros problemas com a aplicação que comprometa a sua operação.

É praticamente impossível levantar todos os eventos de uma aplicação, mas quanto mais ampla for a lista, mais condições se tem de conduzir a forma de elaboração do registro. Definidos os eventos, você pode estabelecer uma convenção de dados do registro relacionado a cada evento. Essa é uma forma de reduzir o poder discricionário do desenvolvedor em definir o conteúdo do log, fonte patente de problemas.

Definidos os eventos, é recomendável usar uma forma de categorização dos registros do log. Tal categorização lhe permite priorizar sua atenção diante dos eventos produzidos pela aplicação. A maneira amplamente difundida é pela sua prioridade ou criticidade, que na maioria dos casos varia de trace, nível menos crítico, até fatal, nível mais crítico. A justificativa para cada categoria segue abaixo:

FATAL – apropriado para eventos que indiquem uma falha crítica de serviço. Se um serviço emitir um erro FATAL, ele está completamente incapaz de responder. Ex. Indisponibilidade total de um dos componentes-chave da aplicação.
ERRO – apropriado para eventos que indiquem uma descontinuidade em uma requisição ou habilidade do serviço em responder. Um serviço deve ter alguma capacidade de continuar a responder a requisições mesmo na presença de ERROs. Os ERROs não podem ser tolerados pela aplicação e devem ser investigados imediatamente.
AVISO – apropriado para eventos que indiquem um erro não crítico em determinado serviço. Erros resumidos ou brechas menores em requisições recaem sobre essa categoria. A distinção entre AVISO e ERRO é muito tênue. Um critério simples é se a falha resulta em chamada de suporte pelo usuário. Caso a resposta seja positiva, escolha ERRO, caso contrário use AVISO. Os AVISOs podem ser tolerados pela aplicação, mas devem sempre ser justificados e examinados. Ex. Aplicação operando em modo debug. O console da aplicação não impõe controle de acesso.
INFO – apropriado para eventos do ciclo de vida de serviços e outras informações cruciais relacionadas. Mensagens INFO para uma determinada categoria de serviço devem revelar qual o estado corrente do serviço. Outra definição de mensagens INFO, registram ações que alteram significativamente o estado da aplicação. Ex. Atualização do banco de dados, requisição.
DEBUG – apropriado para mensagens que incorporam informações extras aos eventos de ciclo de vida. Informação de desenvolvimento ou mais aprofundada necessária para o suporte é a base para esta prioridade. Pode-se considerar a pilha de execução e mensagens trocadas com sistemas externos a aplicação.
TRACE – informação muito detalhada de interesse de desenvolvedores. Tais mensagens são mantidas por um período de tempo muito pequeno quando a aplicação entra em produção e devem ser consideradas temporárias. A dificuldade em se distinguir mensagens DEBUG e TRACE é a mais elevada. Uma vez que se considere um bloco de instruções de logging desprezível após o desenvolvimento e teste da aplicação, provavelmente ele deve ser classificado como TRACE. Estas mensagens podem conter, por exemplo, além dos métodos de classes no fluxo de execução, os argumentos que cada método recebe e devolve.

As categorias citadas anteriormente servem apenas como um exemplo a ser considerado para definir as categorias que fizerem sentido para os objetivos do logging .

Outra dimensão recomendada para categorizar os registros é a segurança. Todos os eventos considerados por Anton Chuvakin e Gunnar Peterson recaem sobre essa categoria.

Disponibilize o mecanismo de logging
A maneira mais recomendada para conceber um mecanismo de logging é adaptar uma das diversas bibliotecas disponíveis de acordo com suas necessidades.
Dentre as funcionalidades oferecidas por uma biblioteca de logging, as seguintes se destacam:

Administração da saída (dimensão, backup, divisão, gravação, etc.)
Classificação dos registros (criticidade/prioridade/segurança).
Gerenciamento de concorrência.

Tais funcionalidades estão presentes em várias bibliotecas como, por exemplo: Enterprise Library, SLF4J e ESAPI. A ESAPI merece um destaque especial por este post, pois foi concebida com pretensões muito ousadas no que se refere a segurança. Decorre daí a possibilidade de instrumentar de forma bastante simples a aplicação, para que ela se adapte automaticamente diante de cenários de ataque, a partir do uso do AppSensor.

Instrua os desenvolvedores
Uma vez que se defina o que e como logar, para que se obtenha sucesso nessa iniciativa, o desenvolvedor deve ser “bombardeado” de treinamento, orientação e acompanhamento para garantir o uso adequado do mecanismo e, principalmente, que o conteúdo dos registros seja completo e compreensível para o fim a que ele se destina.

Considerações Finais
Apresentamos algumas etapas fundamentais no processo de estruturação do logging de aplicações. Cada fase mereceria diversos posts para contemplar assuntos tão extensos, mas por limitações de tempo tivemos que nos limitar a elas.

São ainda questões interessantes a serem discutidas:

Como ajustar o logging de uma aplicação que usa um WAF?
Como garantir que o conteúdo do log não seja subvertido pelo desenvolvedor?
Como orquestrar o mecanismo de validação de entrada e saída e o mecanismo de logging para que a aplicação trabalhe segundo uma abordagem de segurança positiva?

Links Relacionados
http://tinyurl.com/3hv6mgv

Hackademic OWASP

2011-05-05T14:24:00.005-03:00

O OWASP lançou uma série de desafios chamado OWASP Hackademic Challenges Project , um projeto de código-livre, cujo objetivo é ajudar o testador a ganhar conhecimento em testes de segurança em aplicações web.

A Sr. Nimbus através desse post disponibiliza a solução dos 8 primeiros desafios:

Solução do Desafio 1:

Solução do Desafio 2:

Solução do Desafio 3:

Solução do Desafio 4:

Solução do Desafio 5:

Solução do Desafio 6:

Solução do Desafio 7:

Solução do Desafio 8:

Building Security In Manturity Model em Português

2010-09-28T09:01:00.001-03:00

Como temos trabalhado bastante com o Building Security In Manturity Model (BSIMM) e pelo reconhecimento de que, infelizmente, o idioma ainda se apresenta como uma barreira para assimilação de conteúdo pelos nossos técnicos/analistas, resolvemos empreender a tradução do modelo.

Você poderá encontrá-lo clicando aqui.

Aproveite!

Google Lança Web Application Security Scanner

2010-03-22T17:32:00.004-03:00

A Google lançou seu Web Application Security Scanner. Espero ter condições de testá-lo em breve!

Mais detalhes no link http://code.google.com/p/skipfish/wiki/SkipfishDoc.

Hack this!

2008-11-11T10:51:00.002-02:00

Fiquei sabendo à pouco de um novo site com propósitos didáticos para hacking ético. Ao que tudo indica, ele se parece com uma versão on-line do WebGoat da Owasp.

Confira no link:

http://www.hackthis.co.uk/

Privacidade - Scientific American

2008-08-29T15:28:00.006-03:00

A edição de setembro da revista Scientific American (aqui) veio toda dedicada à privacidade que, segundo Esther Dyson, vai além de questões de segurança, saúde e intimidade. São considerados os seguintes assuntos:

Definição e uso do termo privacidade.
Legislação para escuta no âmbito do governo.
Melhoria da saúde a partir do prontuário eletrônico e registros genéticos.
Proteção contra roubo de identidade via autorização biométrica.
Aparato para monitoramento.
Chips de radiofreqüência (RFID).
Vírus e outras pestes na Internet.

Aproveitem!

Análise do Mercado de Software Seguro

2008-08-13T14:55:00.004-03:00

Para os que se interessam pelos números do mercado de segurança diretamente associados à questão do software, vale a pena apreciar a análise sobre os resultados de 2007, consolidados por McGraw (aqui).

Um breve resumo:

Ferramentas

O mercado de ferramentas quase se dobrou, chegando a $150 – 180 milhões. No que tange à ferramentas de black box ocorreu uma estabilização. Neste segmento pequenas empresas tiveram um crescimento mais acentuado (Cenzic 16% e WhiteHat 52%). Já o mercado de análise de código chegou a $91,9 Milhões. Nesta lista encontram-se Fortify (83% - $29.2 Milhões), Klocwork (60% - $26 Milhões), Coverity (50% - $27.2 Milhões) e Ounce Labs (300% $9.5 Milhões).

Serviços

Quanto a services, o crescimento foi mais modesto, apenas 20%. Treinamento (cerca de $7 Milhões), avaliação de riscos ($45-60 Milhões) e teste de penetração ($50-75 Milhões).

Microsoft Patch Tuesday Antecipada

2008-08-05T16:37:00.004-03:00

A Microsoft começará a divulgar antecipadamente à parceiros da área de segurança, como fornecedores de anti-vírus, detalhes técnicos sobre a vulnerabilidade corrigida por ela.

Desde modo, a corrida para levantar tais informações diminuirá a dependência da engenharia reversa, iniciada logo após a divulgação dos patches de segurança na segunda terça-feira do mês, e permitirá que os fornecedores consigam provêr as atualizações de suas ferramentas de proteção com maior agilidade.

Detalhes no blog do Brian Krebs (aqui).

WebGoat versão 5.2

2008-07-15T22:00:00.007-03:00

Acaba de ser lançada a nova versão 5.2 do WebGoat. Os interessados podem encontrar mais detalhes aqui.

A versão 5.1 traduzida para pt-br continua disponível aqui.

Quem se anima a traduzir mais esta versão para o português?

Entendendo XSS, XSRF e outros

2008-07-15T15:25:00.005-03:00

Para alguns a compreensão sobre como um determinado ataque funciona se mostra como um reflexo, tamanha a intimidade deles com o conhecimento técnico associado. Para outros, a grande maioria, tal entendimento fica muito prejudicado pela defasagem técnica e, principalmente, pela maneira como tal informação é apresentada. Para este último, o designer gráfico exerce um papel determinante, articulando entre formas, cores e ações encadeadas de maneira a transformar uma informação que textualmente mostra se complicada, em algo de compreensão bastante facilitada. Com esta percepção o pesquisador Michael Schumacher da Virtual Forge criou um conjunto de animações para auxiliá-lo no treinamento de segurança de software. Aprecie o resultado e até compreenda problemas como XSS, XSRF e navegação forçada no blog da Justice League (aqui).

Google Libera Código Fonte do RatProxy

2008-07-03T13:37:00.005-03:00

Acaba de ser liberado pela Google o código fonte da ferramenta RatProxy. Esta é uma das ferramentas usadas pela Google para teste de suas aplicações Web. Fica aí mais uma alternativa ao WebScarab da OWASP.

Mais detalhes sobre a ferramenta:

http://googleonlinesecurity.blogspot.com/2008/07/meet-ratproxy-our-passive-web-security.html

http://code.google.com/p/ratproxy/

Microsoft Source Code Analyzer for SQL Injection

2008-06-25T09:54:00.004-03:00

Acaba de ser lançada pelo time de segurança do Microsoft SQL Server uma ferramenta de análise de código fonte especializada em encontrar falhas de injeção SQL em código ASP. Mais detalhes no SQL Server Security blog.

Utilidade Pública - Furo no Flash Player

2008-05-28T16:14:00.008-03:00

Várias organizações de segurança de TI (aqui, aqui, aqui) têm divulgado advertências sobre a grave ameaça provocada pelo furo de segurança (estouro de buffer) encontrado no Flash em abril passado. Já existe registro de sites que usam essa vulnerabilidade para instalar software de captura de senhas nas máquinas com navegadores que usam a versão com o furo (aqui).

Antes de duvidar, proteja-se! É simples. Verifique a versão do Flash Player (aqui) e caso seja diferente de 9.0.124.0, faça a atualização (aqui).

WebGoat 5.1 em Português

2008-05-12T23:10:00.009-03:00

No último final de semana consegui finalmente terminar a tradução do WebGoat 5.1 (Versão em Inglês). Foram 4 meses aproveitando o tempo de saguão de aeroporto, o próprio vôo, além daquelas situações onde a cabeça só aceita uma atividade mecânica. Foram cerca de 14o arquivos (vide imagem) distribuídos dentre plano da lição, dicas e soluções.

Para quem não conhece, o WebGoat é um site que coleciona um conjunto de páginas com vulnerabilidades divididas por algumas categorias, cujo intuito é de ensinar na prática qual o risco de desenvolver aplicações sem o compromisso com a segurança. Cada página possui um objetivo de ataque específico, descrito pelo plano da lição. Outros elementos, como por exemplo, as dicas permitem que o público adquira gradativamente os conhecimentos necessários para a efetivação de ataque a aplicações web.

Essa iniciativa vem a somar ao trabalho empenhado pela OWASP no sentido de divulgar informações sobre o desenvolvimento de aplicações com segurança. No que tange ao capítulo Brasil, soma-se as ações de tradução dos documentos para o português brasileiro. Tenho observado por onde passo, que ainda é muito grande a ignorância sobre a questão da segurança no desenvolvimento, e essa iniciativa procura diminuir uma das barreiras, o idioma.

Faça o download da versão de instalação aqui. Em breve tudo estará consolidado na página do WebGoat mantida pelo coordenador desse projeto, Bruce Mayhew.

O Impacto do PCI no Mercado

2008-05-09T15:37:00.008-03:00

Para quem não conhece o PCI (Payment Card Industry) Standard, como o nome sugere é um padrão que a indústria que processa informações de cartões de crédito é obrigada a seguir. O padrão está organizado em 12 seções em um documento de 16 páginas (aqui). Para efeito da segurança de software, os itens seguintes são os mais relevantes:

6.5 Desenvolva todos os aplicativos de web baseados em diretrizes de codificação seguras tais como as diretrizes do Open Web Application Security Project. Revise o código dos aplicativos customizados para identificar as vulnerabilidades do código. Verifique a prevenção das vulnerabilidades mais comuns no processo de desenvolvimento dos códigos dos softwares para
incluir o seguinte:

6.5.1 Input não validado
6.5.2 Quebra do controle de acesso (por exemplo, uso desonesto dos IDs dos usuários)
6.5.3 Quebra da administração de autenticação/sessão (uso das credenciais da conta e
cookies da sessão)
6.5.4 Ataques ao cross-site scripting (XSS)
6.5.5 Overflow do buffer
6.5.6 Defeitos de injection (por exemplo, structured query language injection (SQL)
6.5.7 Administração incorreta dos erros
6.5.8 Armazenagem insegura
6.5.9 Recusa de serviço
6.5.10 Administração de configuração insegura.

6.6 Assegurar-se de que todos os aplicativos que funcionam por meio da web estejam protegidos
contra ataques conhecidos através dos seguintes métodos:
• Ter todos os códigos de aplicativos customizados revisados para vulnerabilidades comuns através de uma organização que se especialize em segurança de aplicativo
• Instalar uma camada de aplicativos (application layer) de firewall na frente dos aplicativos voltados para a web
Nota: Este método é considerado uma melhor prática até 30 de junho de 2008, e depois dessa data se tornará uma exigência.

Apesar da gama de preocupações abordada pelo modelo, o ponto de maior impacto neste momento vem na nota de duas linhas no final da seção 6.6. Pois a partir de junho próximo, toda entidade que ofereça software que trabalhe com informação de cartões será obrigada a utilizar as ferramentas especificadas por essa seção. Até agora o resultado mais evidente é a luta dos fornecedores para colocar seu produto no mercado (A Cicso é a última), ou se aliar com diferentes fornecedores para tentar oferecer a melhor solução (aqui). É provável que o resultado que mais nos interessa (software seguro) seja uma consequência natural disso e que outros negócios sejam influenciados pelos resultados dessa obrigação imposta pelo PCI. Veremos!

Terceirização de Software Seguro

2008-05-06T10:55:00.005-03:00

É comum encontrar o cenário onde o contratante e o contratado em uma relação de terceirização nunca ouviram falar em software seguro e isso reflete diretamente nos aspectos legais entre as partes. Porém, algumas organizações já se encontram preocupadas sobre como estabelecer parâmetros legais que façam com que o negócio considere oficialmente a segurança no desenvolvimento, e permita às partes se comprometerem de fato.
Navegando pelo site da OWASP encontrei uma sugestão de minuta de contrato (aqui) que pode ser fonte de inspiração para as empresas que desejarem incorporar em seus contratos esse tipo de obrigação.

(In)Secure Magazine - Abril - 2008

2008-05-02T12:31:00.006-03:00

A revista eletrônica, (In)Secure magazine de Abril traz um artigo que muito interessante sobre o desenvolvimento seguro "Producing Secure Software With Software Security Enhanced Processes" elaborado por Marco Morana. O artigo, além de discorrer sobre a abordagem mais defendida hoje para tratar do desenvolvimento de software seguro (segurança desde o princípio, faz ainda uma comparação muito rica sobre as propostas de segurança em processo mais difundidas hoje: MS-SDL, CLASP, Pontos de controle da Cigital.
Vale observar que a revista possui vários outros artigos relacionados a segurança. Vale a pena conferir.

O Que Esperar Fortify Souce Code Analyzer?

2008-03-28T10:28:00.017-03:00

No final de março, tive a oportunidade de fazer o curso de auditor de código fonte com o Fortify Source Code Analyzer oferecido pela própria Fortify. O curso foi realizado em Denver no Colorado. A cidade, além de ser muito charmosa, fica bem próximo de Aspen. Foi uma pena não ter tido mais tempo para aproveitar esse outro lado.

Voltando ao curso em si, a turma era formada por oito pessoas. Todos inexperientes com a ferramenta. A maioria com experiência em desenvolvimento e em segurança no geral. Vale ressaltar que a Systest foi a empresa com mais participantes, quatro pessoas. O curso foi ministrado por Su Gaustad, cujo conhecimento acerca de desenvolvimento seguro e do uso do Fortify SCA impressiona, sua habilidade para lidar com o público também.

O Fortify SCA é um analisador estático de código fonte, cuja inteligência se resume nas regras desenvolvidas pela Fortify para encontrar furos de codificação, distribuídas dentre as seguintes abordagens de análise:

Estrutural - Detecta uso de funções e APIs potencialmente perigosas.
Semântica - Detecta furos potencialmente danosos na estrutura ou definição do programa. Por exemplo, uma atribuição de variáveis em Servlets, uso de loggers que não são declarados como static final.
Fluxo de Controle - Detecta sequência de operações potencialmente perigosas. Isso remete à visualização análise de sequência de execução das operações, para verificar se alguma delas a aplicação é exposta a vulnerabilidades. Ex. Abrir uma conexão com banco de dados e não fechá-la, pode expor a aplicação à uma sobrecarga por não alocação de recursos.
Fluxo de Dados - Detecta potenciais vulnerabilidades relacionadas a dados de entrada em processamento no software. Isso pressupõe uma análise inter-procedural, o que significa que suas regras são capazes reconhecem falhas de um dado recebido por um método, que é passado para outro método e lá sim, que ele oferece risco de se tornar uma vulnerabilidade explorável. Ex. Parâmetro de nome de arquivo recebido por um método é passado como parâmetro para outro método, que faz uso de strcopy para copiar o conteúdo de tal parâmetro para um buffer.
Configuração - Localiza erros, pontos frágeis e violação de políticas nos arquivos de implantação da aplicação. Por exemplo, a connectionstring com parâmetros de usuário e senha no Web.Config em aplicações ASP.NET.
Agrega a análise do FindBugs.

Seu processo de análise é organizado em três fases complementares:

Tradução - onde o código fonte é recolhido segundo uma série de comandos e traduzido em um formato intermediário, que é associado à um BuildID (identificador do projeto em análise).
Análise - compreende a busca por vulnerabilidades e análise de acordo com as regras descritas anteriormente.
Verificação - garantia de que a análise foi realizada de acordo com as regras e seu resultado informa erros significativos.

Suporta as linguagens comercialmente mais utilizadas (Java, .NET, PHP, ColdFusion, JavaScript, PL-SQL), integra-se com as principais IDEs (Eclipse, Visual Studio 2003/05), como foi desenvolvido em Java, funciona em toda plataforma que suporte a JVM. É facilmente integrada com o ANT também.

Suas regras de análise (rulepack) são propriedade intelectual da Fortify e estão debaixo de forte critptografia. Seu acesso é dependente da manutenção da assinatura anual pelo seu uso. O que significa que, além da licença, é necessária a assinatura para usar o rulepack. Apesar de altamente não recomendado, a ferramenta permite ainda que sejam elaboradas regras próprias para as análises. Prepare-se pois a tarefa é de alta complexidade. Daí a razão da Fortify se disponibilizar a customizá-las, tão logo a necessidade seja indentificada pelos seus clientes, e devolver no rulepack.

Pela consistência dos resultados apresentados pelas análises (falso positivo/negativo) usando o SCA ao longo do curso, pela forma didática como ela os apresenta, bem como as facilidades proporcionadas para o auditor, percebo que essa ferramenta tem espaço garantido quando se tratar de ciclo de desenvolvimento seguro. Infelizmente, não conheço os detalhes do principal concorrente Ounce 5, para poder compará-las e desconheço também qualquer detalhe sobre os custos associados à sua arquisição/manuteção (pergunte à LeadComm), mas tenho a impressão que seu mercado é bem restrito.

Software Seguro sob a Perspectiva de Negócio

2008-03-27T10:57:00.010-03:00

Desenvolver software seguro pressupõe um investimento adicional ao já oneroso ciclo de desenvolvimento de software. Essa realidade faz com que os executivos tradicionais tentem ignorar esse assunto o quanto podem. Esse "até quando podem" se traduz em perdas econômicas causadas por processos judiciais relativos à quebra de confidencialidade e outras violações, degradação da imagem, perda de mercado, etc.

O investimento em segurança no desenvolvimento é uma viagem obrigatória, com apenas estação partida, que toda organização, cujo negócio é software, se ainda não entrou, terá que entrar. Essa obrigatoriedade está diretamente ligada à curva crescente de perdas causadas por exploração de falhas de segurança.

Essa viagem está obviamente muito mais avançada nos EUA e países, cujo rigor com questões de segurança é maior. No Brasil, por exemplo, a onda de busca de soluções de segurança para atenter o padrão PCI (Payment Card Industry), mais especificamente o item 6, parece ainda nem ter começado. E veja você, que o uso de algumas alternativas para segurança no ciclo de desenvolvimento, como análise estática de código, firewall de aplicação sairão do status de recomendação no PCI para obrigatório em julho/08.

O mercado americano mostra boas perpectivas acerca dessa mudança de mentalidade, basta observar os movimentos das empresas, como por exemplo, a integração entre Sentinel (scan) da WhiteHat com o Ounce 5 (source code analyzer) da Ounce Labs e outros. Obviamente, eles estão prevendo alta demanda à caminho.

Voltando à questão do negócio em si, hoje as organizações (pelo menos as grandes) já reconhecem a importância de desenvolver software com segurança desde o princípio, e que o custo dessa alternativa é, sem dúvida, menor que os custos associdos à incerteza sobre o nível de segurança do produto final. Essa percepção sobre o nível de segurança é diretamente influenciada pelas evidências de ações de segurança recolhidas ao longo do desenvolvimento. Cita-se, como exemplo, os touch points da Cigital.

Não há outro elemento mais importante na segurança do que o recurso humano, quer seja no desenvolvimento ou na operação. Acontece, que as instituições de ensino em geral, continuam a não dar tanta importância ao assunto de software seguro. Quem paga a conta está começando a agir para mitigar esse problema. Como? Solicitando oficialmente às universidades para que ensinem seus alunos como desenvolver com segurança.

Para finalizar, fica destacado que a segurança no desenvolvimento não deve ser o objetivo de negócio de nenhuma organização (exceto àquelas onde esse é o negócio em si), mas que seu resultado pode suportar ou não os objetivos de negócio dela. Com essa mentalidade, a resistência a embarcar dessa viagem passa a ser dirigida pela análise de risco e custo da oportunidade.

--

Vale a pena assistir o podcast do McGraw com Mary Ann Davidson, CSO da Oracle.

RUP + Ounce 5. Será que emplaca?

2008-03-11T18:16:00.008-03:00

Como era de se esperar as empresas já começam a se mobilizar para oferecer soluções de segurança para o desenvolvimento de software seguro. Quando digo soluções, me refiro ao uso integrado do ferramental disponível para habilitar de fato o desenvolvimento de software seguro.
A IBM e a Ounce Labs estão trabalhando em conjunto para que o RUP incorpore a abordagem de desenvolvimento de código seguro amparado por ferramenta de análise estática, o Ounce 5.

Particularmente, vejo duas alternativas para que as organizações comecem de fato a investir na segurança de software ao longo de seu ciclo de desenvovimento. A primeira via decreto (PCI, HIPAA), ou se enquadra ou "pede pra sair". A segunda é a partir do surgimento de propostas que facilitem a absorção da mudança causada por um ciclo de desenvolvimento que pressupõe segurança. Porque isso é determinante na análise de risco (de negócio) na hora de considerar tal alternativa.

Jogada de mestre. O processo mais usado se integrar com umas das ferramentas de análise estática mais usadas. Vamos ver se emplaca!

Como farei o curso de auditor pela Forify na semana do dia 23 de março, acredito ter mais informações sobre como ela se coloca diante desse cenário.

Para mais informação sobre análise estática para segurança sugiro o livro do Brian Chess: Secure Programming with Static Analysis.

Estratégia de Segurança que Funciona para a Web

2008-03-11T10:57:00.007-03:00

Fiz a tradução do interessante post do Jeremiah Grossman, no qual ele dá uma visão geral da segurança em aplicações web e as alterativas corrente para lidar com esse problema.

Dentro de uma empresa vive um profissional de segurança de TI responsável pela segurança de sites web. Ele precisa levar seu trabalho muito à sério, sob a pena de receber uma ligação tarde da noite de seu chefe, caso o site de sua empresa seja atacado. Uma boa parte do trabalho requer educação dos desenvolvedores acerca da importância de codificação segura e reporte aos proprietários do negócio sobre os riscos relativos à segurança Web. Ele precisa fazer isso, pois nenhuma quantidade de patching ou firewalling conseguirá frear um atacante com um browser. Mesmo que use tudo que esteja em seu poder, ainda existe uma total falta de controle na proteção dos sites sob sua responsabilidade. Ele não pode corrigir as vulnerabilidades em website(s) quando elas são identificadas sem o envolvimento do desenvolvedor.

Essa situação lhe soa familiar? Eu ouço essa frustração à todo momento. O problema é que quando uma vulnerabilidade é identificada, quer seja pelo pen-tester, desenvolvedor, outsider ou quem quer que seja essas são as sofridas opções:

Parar o site.
Reverter para uma versão anterior do site/código (caso seja segura).
Continuar a funcionar apesar da exposição.
Nada é melhor que não ter um problema, mas vulnerabilidades aparecerão independente do ciclo de desenvolvimento de software. A opção #1 é tipicamente reservada para ocasiões onde um incidente tenha ocorrido e a opção 2# quando uma atualização do produto não possa ser devolvida para o desenvolvimento, que futuramente venha a ser sobrescrita. Até agora a história mostra que a grande maioria escolhe a opção #3 e assume o risco, ao invés de parar o negócio com atualizações.

É claro que são necessárias mais opções – algo que permita a mitigação de vulnerabilidades sem provocar impacto na operação do negócio.

Isto é importante, pois 9 entre 10 (ou mais) sites web possuem vulnerabilidades como resultado de serem produzidos por aqueles que não sabiam ou experimentaram a severidade dos ataques de hoje. Adicionalmente, eu poderia dizer que a maioria dos sites de comércio eletrônico populares foram desenvolvidos ou antes do descobrimento de vulnerabilidades prevalentes como o XSS, injeção SQL, CSRF, etc. ou antes deles se tornarem conhecidos. Consequentemente, estamos vulneráveis por 15 anos de códigos inseguro de sites em circulação e é pouco provável que esse código seja reescrito somente por “razões de segurança”. Ao longo da próxima década sua substituição acontecerá naturalmente de forma a atender os objetivos de negócio enquanto se aproveitando das tecnologias emergentes e frameworks mais seguros.

O que significa que quando você realiza uma análise honesta acerca da segurança do website, você terá duas estratégias de segurança possíveis:

Segurança ao longo do SDLC (ciclo de vida de desenvolvimento de software)
Avaliação de vulnerabilidade + WAF (Firewall de Aplicação Web)

A estratégia #1 se aplica mais à sites a serem construídos ou que estejam em fase de redefinição. Um programa de segurança Web combinando patrocínio executivo, frameworks modernos de desenvolvimento, treinamento de conscientização e segurança considerada no design e QA (garantia de qualidade) funciona. Por outro lado, esta estratégia é sempre difícil e cara para se implementar em sites existentes onde nenhuma atividade semelhante foi realizada anteriormente. Mesmo depois das vulnerabilidades identificadas é consome-se tempo a alocação de pessoal, QA / testes de regressão da correção e agendamento de versões de produção. Independente da maturidade do SDLC, isto demanda pelo menos dias, em alguns casos meses e mesmo meses para as falhas serem corrigidas. Este é o cenário mais comum hoje. O que tornará a conformidade com o PCI 6.6 (Payment Card Industry) um grande desafio, quando ela entrar em vigor.

Está é a razão pela qual a estratégia #2 é mais apropriada para websites existentes. A integração tecnológica demandada pela avaliação de vulnerabilidades é imediatamente importada para um WAF, criando uma “atualização virtual”. A integração fecha o ciclo entre identificação e mitigação de vulnerabilidade habilitando a oportunidade de endereçar as causa raízes assim que o tempo e o orçamento permitir. O desafio aqui é caso a fonte de dados seja imprecisa, de forma que a atualização virtual possa causar o WAF rejeitar trafego válido, permitir tráfego malicioso ou interromper inteiramente. Com dados verificados, a empresa é capaz de realizar por completo seu investimento de avaliação de vulnerabilidade em tempo real, confiando no modo de bloqueio do WAF e fornecendo aos profissionais de TI o controle até agora ausente. E isto é relativo ao tempo também!
Caso essa solução lhe soar familiar, pode ser pelo fato dessa idéia ter sido usado no passado, nunca em segurança de aplicações web. Kavado tentou na era 2002-2003, em 2003-2004 muitos outros fornecedores tentaram usar o AVDL e estou certo que tiveram outros, mas ultimamente todas as tentativas se comprovaram falíveis, devido às razões mencionadas anteriormente. Só recentemente que a tecnologia de scanneamento de vulnerabilidades e WAP está se materializando e decisões de negócio necessitam ser realizadas, possuir uma variedade de opções disponíveis é algo muito muito bom.

A pescaria já não é mais a mesma de antigamente

2008-02-13T17:15:00.007-02:00

Pescaria é uma tradição no Brasil. Quem nunca participou, certamente tem algum parente, amigo, vizinho que já foi e não vê a hora de repetir a experiência. A autêntica pescaria brasileira sugere s seguinte combinação: uma turma de amigos, sendo pelo menos um violeiro, muita bebida (vale qualquer tipo, mas a cerveja e a cachaça são fundamentais), a tralha de pesca (barco, vara, etc.) e um maço de dinheiro para, na falta da "sorte", não chegar em casa de mão abanando.

Apesar de ser esta a mais famosa para nós brasileiros, é outra pescaria que tem ganhado destaque na área de segurança mundo afora. Essa pescaria apesar de ser análoga à tradicional, não preserva seus elementos fundamentais. Aquele clima amistoso de diversão e confraternização já era! Até a bebida foi abandonada! O rio agora nem água tem mais, o que se vê é bit. O peixe agora corresponde à informação sigilosa espalhada nesse rio de bit, que vira dinheiro tão logo o "pescador" resolva apropriar-se de recuros financeiros espalhados pelos bancos que usam essa via, a partir do "peixe".

E nessa nova pescaria, referida amplamente como fishing, o Brasil vem recebendo internacionalmente mais reconhecimento que na tradicional! Duvida? Confira aqui.

SecBuemba! Nova técnica de medir qualidade de código revisado

2008-02-06T13:34:00.001-02:00

Acaba de ser lançada uma nova técnica de medição da qualidade de código revisado, cuja efetividade nunca havia sido alcançada. Confira em detalhes a aplicação da WFT aqui.

A contribuição do Fuzzing para o Software Seguro

2008-02-05T19:52:00.000-02:00

Já foi mencionado aqui técnicas para localizar vulnerabilidades, com uma rápida menção à técnica conhecida como Fuzzing. Tudo bem que o objetivo não era explicá-la em detalhes, mas considerar várias delas. Mas pelo papel determinante que vem ocupando no chão de fábrica do desenvolvimento de código seguro, ela merece mais destaque. Com essa mesma opinião, a revista eletrônica DarkReading nos fez o favor de publicar recentemente um artigo com detalhes sobre a técnica, com comparação entre ferramentas, além de apontar para outras fontes de pesquisa, como o blog Scott Lambert, do Microsoft’s Security Engineering Tools Team, e o livro que será lançado em maio "Fuzzing for Software Security: Robustness Testing for Quality Assurance and Vulnerability".
Para os mais anciosos, já existe um livro sobre o assunto, chamado "Fuzzing: Brute Force Vulnerability Discovery".

Acesso grátis aos livros da OWASP

2008-01-31T16:52:00.001-02:00

A OWASP está disponibilizando alguns de seus livros para download sem custo (de graça). Duvida? Acesse aqui e aproveite. Para aqueles que resistem ao ebook, podem adquirir as versões impressas por um valor simbólico, que varia de 5 a 18 dólares.

Top 10 Vulnerabilities traduzido para o português

2008-01-10T16:46:00.000-02:00

Com o intuito de facilitar o acesso à documentação sobre segurança no desenvolvimento fizemos a tradução do documento conhecido como Top 10 Vulnerabilities da OWASP. Ele concentra informações sobre as dez vulnerabilidades mais relevantes para as aplicações web, bem como alternativas combatê-las.

Aproveitem!

Lições aprendidas em segurança pela Microsoft

2007-10-18T08:39:00.000-02:00

A revista MSDS Magazine de novembro 2007 traz um artigo elaborado pelo Michael Howard, onde são compartilhadas 10 lições aprendidas pela Microsoft ao longo dos cinco anos de investimento em desenvolvimento de código seguro. Vale a pena conferir!

Lessons Learned from Five Years of Building More Secure Software

Microsoft Guidance Explorer

2007-09-28T09:28:00.000-03:00

Para os desenvolvedores .NET que não conhecem o Microsoft Guidance Explorer (versão Web) ainda, vale a pena analisá-lo. Ele aborda as recomendações de Patterns&Practices de uma perspectiva mais aplicada ainda.

Segue apenas algumas orientações de segurança tiradas dele para o desenho de software seguro, na plataforma .NET.

A versão local pode ser encontrada em Guidance Explorer.

Sugestão de Leitura "State of the Art of Software Security Assurance"

2007-09-15T11:22:00.000-03:00

Copio o post do Cima, onde ele divulga o lançamento pelo DoD (US - Department of Defense) do relatório sobre o estado a arte em desenvolvimento de software seguro.

Segue o post - Dica: Relatório "State of the Art of Software Security Assurance".

Adicionalmente, sugiro outro relatório, este do DHS (Department of Homeland Security) produzido em agosto de 2006, mais conciso, mas tão denso quanto o do DoD, chamado Security in the Software LifeCycle.

Core Grasp for PHP

2007-08-24T10:35:00.000-03:00

Foi lançada a ferramenta Core Grasp para PHP, cujo objetivo é detectar e bloquear a injeção de vulnerabilidades e violação de privacidade.

Quem desenvolve em PHP sabe das dificuldades de construir uma aplicação segura a partir desse framework. Vale a pena considerar....

Mais informações: CORE GRASP.

Afinal de contas, qual a melhor forma de encontrar vulnerabilidades?

2007-08-14T15:22:00.000-03:00

Existem três abordagens básicas para descobrir vulnerabilidades: testes white box, black box e gray box. A diferença entre os três pode ser analisada pelo prisma dos recursos disponíveis para o testador. Em um extremo, temos o teste white box, cuja abordagem requer acesso completo a todos os recursos. Incluindo código fonte, desenho e até um conversa com o programador. No outro extremo encontra-se o teste black box, onde os recursos internos do sistema são indisponíveis. O teste de penetração é um exemplo dessa abordagem. Já os testes gray box não possuem uma definição bem estabelecida. Mas vamos combinar que para esse tipo, o testador tem acesso as bibliotecas compiladas e, em alguns casos, documentação básica.

Teste white box
Essa abordagem explora em profundidade o código fonte na tentativa de localizar falhas de segurança. A análise de código fonte pode ser realizada manualmente, impraticável em grande escala, e automatizada pelo uso de ferramentas de análise de código fonte.

Vantagens

Cobertura - pelo fato do código fonte estar disponível, uma revisão de código permite sua cobertura total. Todos os fluxos de código podem ser auditados na busca de vulnerabilidades. Isto pode levar a falsos positvos, à medida que nem todos os fluxos sejam verificados.

Desvantagens

Complexidade - a análise dos resultados gerados pelas ferramentas é de muita complexidade, pois exigem uma revisão criteriosa de cada registro para verificar se realmente corresponde a uma vulnerabilidade.
Disponibilidade - o código fonte nem sempre é um recurso disponível.

Teste black box
Essa abordagem implica que seu conhecimento corresponde apenas aquilo que pode ser observável, assim como um usuário final. Assim como para o teste caixa branca, esta abordagem é realizada de maneira manual e automatizada, sendo esta conhecida como Fuzzing.

Vantagens

Disponibilidade - aplicáveis sempre, inclusive nas situações onde o código fonte esteja disponível.
Reproducibiliade - pelo fato deste teste não levar em conta pressupostos sobre o alvo, a ação pode ser reproduzida para diversos sistemas.
Simplicidade - mesmo que abordagens que usem engenharia reversa requeiram habiliades especializadas, o teste black box em seu nível básico pode ser conduzido sem um conhecimento interno denso da aplicação.

Desvantagens

Cobertura - um dos maiores desafios é saber quando parar os testes quão efetivo ele tem sido.
Inteligência - o teste black box é mais indicado para cenários onde a vulnerabilidade é causada por vetor de ataque individual. Ataques complexos podem, entretanto, exigir múltiplos vetores de ataque e nesses casos é necessário um entendimento profundo da aplicação, possibilitado pelo acesos ao código fonte.

Teste gray box
Este teste uso como recurso determinante o acesso ao binário da aplicação, sendo sua avaliação de segurança também conhecida como auditorida de binário. Assim como para as outras abordagens, esta é realizada manualmente ou com o uso de ferramenta. Vale ressaltar que o que pode não ser automatizado é a análise e não o desassembly.

Vantagens

Disponibilidade - com exceção de aplicações web remotas, o binário está sempre disponível.
Cobertura - informação obtida com esta análise pode ser utilizada na melhora da técnica black box.

Desvantagens

Complexidade - A engenharia reversa é uma habilidade especializada e consequentemente recursos podem não estar disponíveis para sua realização.

Infelizmente, quando se trata de segurança, não existem soluções simples isoladas, que transformem seu software em algo seguro. Isso se aplica também para a localização de vulnerabilidades. Se nem a combinação das abordagens anteriores assegura que todas as vulnerabilidades sejam encontradas, individualmente é que elas não resolvem mesmo.

The Securty Development Lifecycle book...

2007-08-09T09:40:00.000-03:00

Para aqueles que tiverem interesse em um resumo breve do livro SDL, podem conferir a apresentação elaborada por mim durante a sua leitura.
Reforço, que vale a pena a leitura do livro, cujo conteúdo é bastante denso e sua leitura não é tão árida. O que o torna acessível a qualquer um com conhecimentos básicos da área de computação.

Ferramentas de Análise Código Fonte

2007-07-05T15:23:00.002-03:00

A análise de código para fins de segurança é uma das alternativas bastante utilizadas pelo mercado para o desenvolvimento de software seguro. Sua difusão se deve primeiro aos resultados, em termos de localização de bugs de segurança em código e, segundo, pelaa facilidade de incorporação ao ciclo de desenvolvimento, uma vez que as principais ferramentas se integram às IDEs mais usadas hoje, como o Eclipse e o Visual Studio da Microsoft.

Todas as ferramentas comerciais existentes se fundamentam no mesmo princípio, regras e padrões de codificação suspeitos. Isso as tornam muito dependentes da ação humana. Num primeiro momento, para desenhar essas regras a partir de muita pesquisa e depois, para avaliar o resultado de uma análise de código.

As ferramentas de análise de código fundamentam a an Teorema de Rice, que coloca que qualquer questão não trivial endereçada a um programa pode ser reduzido ao Problema de Halting, isso implica que os problemas de análise de código são insolúveis no pior caso e, por consequência, que essas ferramentas são obrigadas a fazer aproximação, cujo resultado é algo não perfeito.

Os principais problemas das ferramentas de análise de código fonte para segurança estão concentradas em:

Falso negativo - o programa contém bugs não endereçados pela ferramenta. Isso dá a falsa sensasão de que não existe bugs, que na verdade significa que a ferramenta não foi capaz de encotrar mais exemplares.
Falso positivo - a ferramenta endereça bugs não existentes. Isso se refere a duas possibilidades: um erro propriamente dito, onde a ferramenta localizou um bug que não existe fisicamente; ou há uma classificação da ferramenta incoerente com as variáveis do ambiente. Por exemplo, a ferramenta poderia encontrar um bug de SQL Injection, que na realidade, não interessa para o software investigado pelas suas características de operação.

Vale ressaltar que as ferramentas comerciais procuram reduzir o falso positivo, assumindo o custo de deixar passar falsos negativos.

As análises de código fonte podem ser divididas de acordo com as seguinteas abordagens:

Análise estática: a análise estática pode compreender as técnicas de busca direta a partir de lista de strings (grep); a análise léxica, onde os tokens do código fonte são comparados com àqueles contidos numa biblioteca de vulnerabilidades e análise semântica, onde se prevê como o programa se comportará em tempo de execução, usando a tecnologia de compiladores (árvore sintática abstrata)
Análise de fluxo de controle: usada para caminhar através das condições lógicas do código. O processo funciona como a seguir:
1. Observe uma função e determine cada condição de desvio. Essas incluem loops, switchs, if's e blocos try/catch.
2. Entenda as condições sobre como cada bloco será executado.
3. Vá para a próxima função e repita.
Análise de fluxo de dados: usada para seguir fluxos de dados dos pontos de entrada aos pontos de saída. O processo funciona como descrito a seguir:
1. Para cada entrada , determine o quanto você acredita na fonte de entrada. Quando em dúvida você não deve acreditar.
2. Siga o fluxo de dados para cada saída possível, registrando ao longo do percurso qualquer tentativa de validação de dados.
3. Vá para a próxima entrada e continue.

A ferramenta mais eficiente é a que consegue fazer uso dessas abordagens combinadas para reduzir tanto o falso negativo, como o falso positivo. Alguns fornecedores estão na busca por ferrnamentas efetivas em temos de análise de código para segurança. Dentre eles, vale destacar:

Vale reforçar, que para conseguir tirar o melhor proveito das ferramentas de análise de código fonte para segurança, seu uso deve estar amparado por um ciclo de desenvolvimento seguro, como o CLASP ou SDL.

Informações adicionais :
Software Security Building Security In
Secure Programming with Static Analysis
Security Engineering Explained - Versão em português.

Software Seguro....Por onde começar?

2007-07-04T15:40:00.001-03:00

O tema software seguro tem recebido mais atenção dia-a-dia, impulsionado pela necessidade de atacar de todas as maneiras a segurança em TI, com ações para estabelecer segurança no nível de rede, de estação e de aplicação, para inverter ou suavizar a curva de evolução de incidentes de segurança, como mostrado pelo CERT-CC.

Nosso foco será em ações, práticas, procedimentos, ferramentas, etc. que apóiem a melhoria da segurança no nível de aplicação, ou seja, para que o elo aplicação na cadeia aplicação-rede-estação seja fortalecido.

Uma coisa vale ressaltar, se alguém deseja evoluir no tema de desenvolvimento de software seguro, vai ter que arregaçar as mangas e digerir uma quantidade infinita de informações, que hoje pode ser encontradas em diversas fontes de pesquisa. Isso acontecer por duas razões principais, primeira é a dificuldade em se encontrar programas de treinamento que considerem esse tipo de assunto e segunda, pela dinamicidade associada, a cada dia surgem novas vulnerabilidades e contramedidas.

Para quem desejar se ingressar no problema de desenvolvimento de software seguro, que remete ao uso de um ciclo de desenvolvimento de software que considera segurança desde seu início, segue a relação de alguns links:

Security Engineering Explained - relatório da Microsoft que considera preocupações elementares no desenvolvimento de software seguro (50pag.).
Build Security In - portal desenvolvido pelo Software Engineering Institute, com orientação de Gary McGraw, patrocinado pelo Department of Homeland Security. Existem muitos artigos sobre a temática de segurança em software.
OWASP - Open Web Application Security Project - Portal de segurança em aplicações web. Este é o projeto de segurança em desenvolvimento mais ativo hoje, com grande contribuição da comunidade. Qualquer um pode se envolver e contribuir. Pode encontrar ferramentas com WebScarab e o Processo CLASP

Abertura

2007-07-04T15:27:00.000-03:00

Resolvi inaugurar esse canal para discutirmos vários temas relacionados ao desenvolvimento de software seguro.