19 de outubro de 2006

Code coverage

Quem nunca se deparou com aquele ambiente legado, com uma maquina antiga, e uma aplicação mais antiga ainda e que eventualmente é necessário dar um boot, pois, o aplicativo travou e ninguém sabe porque?

Situações como essas poderiam ser minimizadas se fosse realizado um teste de cobertura de software ou code coverage em inglês.

O que é o teste de cobertura? Teste de cobertura podemos dizer que é o teste do teste. Como assim? Quando realizamos testes, quem garante que todo código foi testado? Eventualmente determinadas funções, critérios podem não ser testados.

O code coverage tem exatamente essa função, identificar quais partes do código não foram testadas. Então aquele aplicativo que pára e ninguém sabe porque, pode ser exatamente um IF que não foi testado nos testes realizados. Além dos problemas disponibilidade, pode-se identificar falhas de segurança com o code coverage.



Não vou entrar em detalhes de ferramentas sobre ferramentas para code coverage, essas ferramentas geralmente são especificas para cada linguagem. Eu tive há oportunidade de testar esse recurso no Visual Studio 2005, pode dizer que é simplesmente fantástico.

Para aprofundar seus estudos sobre code coverage e não ficar somente com uma visão simplista minha, dê uma olhada no wikipedia, além de uma visão geral, existe algumas referências.
Code coverage por wikipedia

Code coverage

Quem nunca se deparou com aquele ambiente legado, com uma máquina antiga, e uma aplicação mais antiga ainda e que eventualmente é necessário dar um boot, pois, o aplicativo travou e ninguém sabe porque?

Situações como essas poderiam ser minimizadas se fosse realizado um teste de cobertura de software ou code coverage em inglês.

O que é o teste de cobertura? Teste de cobertura podemos dizer que é o teste do teste. Como assim? Quando realizamos testes, quem garante que todo código foi testado? Eventualmente determinadas funções, critérios podem não ser testados.

O code coverage tem exatamente essa função, identificar quais partes do código não foram testadas. Então aquele aplicativo que pára e ninguém sabe porque, pode ser exatamente um IF que não foi testado nos testes realizados. Além dos problemas disponibilidade, pode-se identificar falhas de segurança com o code coverage.



Não vou entrar em detalhes de ferramentas sobre ferramentas para code coverage, essas ferramentas geralmente são especificas para cada linguagem. Eu tive há oportunidade de testar esse recurso no Visual Studio 2005, posso dizer que é simplesmente fantástico.

Para aprofundar seus estudos sobre code coverage e não ficar somente com uma visão simplista minha, dê uma olhada no wikipedia, além de uma visão geral, existe algumas referências.

Code coverage por wikipedia


17 de outubro de 2006

Internet Banking, de quem é a culpa?

A bola da vez na lista de discussão CISSP-BR é a iniciativa brasileira em responsabilizar os clientes por ações de hacker contra usuários que usam o Internet Banking.

Existem argumentos convincentes e corretos de ambas as partes, partes que acreditam que o problema é do banco e outros que acreditam que o problema realmente é do usuário.

Discussões sobre qual o melhor controle a se implementar, se as campanhas de conscientização são úteis ou não, tudo isso é válido e enriquecedor para a comunidade de segurança, mas, acho que o grande mind-set, grande lição que devemos levar é: o usuário deve ter o pensamento orientado a riscos (risk-based thinking).

O usuário deve saber que, assim como atravessar a rua em uma avenida movimentada, o uso do Internet Banking também oferece seus riscos.

Talvez a movimentação toda tenha acontecido porque, os bancos só mostraram as caras pouco antes dessas decisões de responsabilizar o usuário pela fraude aparecer. Apesar de sabermos que existiam campanhas tímidas entre algumas entidades, nenhuma instituição financeira mostrava no horário nobre da televisão campanhas de conscientização.

OWASP and PCI

PCI Security Standard são critérios de segurança que foram definidos pela VISA e Mastercard para implementar segurança em sistema de pagamentos eletrônicos. Estudando o guide encontrei referência a desenvolvimento seguro e ao OWASP. Basicamente implementando o Top10 do OWASP você está compliance com o requerimento 6.5.

Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed via vendor security patches, and all systems should have current software patches to protect against exploitation by employees, external hackers, and viruses. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

6.1 Ensure that all system components and software have the latest vendor-supplied security patches.
6.1.1 Install relevant security patches within one month of release.

6.2 Establish a process to identify newly discovered security vulnerabilities (e.g., subscribe to alert services freely available on the Internet). Update your standards to address new vulnerability issues.

Maintain a Vulnerability Management Program

6.3 Develop software applications based on industry best practices and include information security throughout the software development life cycle. Include the following:

6.3.1 Testing of all security patches and system and software configuration changes beforedeployment
6.3.2 Separate development/test and production environments
6.3.3 Separation of duties between development/test and production environments
6.3.4 Production data (real credit card numbers) are not used for testing or development
6.3.5 Removal of test data and accounts before production systems become active
6.3.6 Removal of custom application accounts, usernames, and passwords before applications become active or are released to customers.
6.3.7 Review of custom code prior to release to production or customers, to identify anypotential coding vulnerability

6.4 Follow change control procedures for all system and software configuration changes. Theprocedures should include:

6.4.1 Documentation of impact
6.4.2 Management sign-off by appropriate parties
6.4.3 Testing that verifies operational functionality
6.4.4 Back-out procedures.

6.5 Develop web software and applications based on secure coding guidelines such as the OpenWeb Application Security Project guidelines. Review custom application code to identify codingvulnerabilities. See http://www.owasp.org/ - “The Ten Most Critical Web Application Security Vulnerabilities.” Cover prevention of common coding vulnerabilities in software developmentprocesses, to include:

6.5.1 Unvalidated input
6.5.2 Broken access control (e.g., malicious use of user IDs)
6.5.3 Broken authentication/session management (use of account credentials and sessioncookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (e.g., SQL injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management.

OWASP
Capítulo Brasil do OWASP
Top10 em Português
PCI por Mastercard
PCI por VISA

Internet Banking, de quem é a culpa?

A bola da vez na lista de discussão CISSP-BR é a iniciativa brasileira em responsabilizar os clientes por ações de hacker contra usuários que usam o Internet Banking.

Existem argumentos convincentes e corretos de ambas as partes, partes que acreditam que o problema é do banco e outros que acreditam que o problema realmente é do usuário.

Discussões sobre qual o melhor controle a se implementar, se as campanhas de conscientização são úteis ou não, tudo isso é válido e enriquecedor para a comunidade de segurança, mas, acho que o grande mind-set, grande lição que devemos levar é: o usuário deve ter o pensamento orientado a riscos (risk-based thinking).

O usuário deve saber que, assim como atravessar a rua em uma avenida movimentada, o uso do Internet Banking também oferece seus riscos.

Talvez a movimentação toda tenha acontecido porque, os bancos só mostraram as caras pouco antes dessas decisões de responsabilizar o usuário pela fraude aparecer. Apesar de sabermos que existiam campanhas tímidas entre algumas entidades, nenhuma instituição financeira mostrava no horário nobre da televisão campanhas de conscientização.

OWASP and PCI

PCI Security Standard são critérios de segurança que foram definidos pela VISA e Mastercard para implementar segurança em sistema de pagamentos eletrônicos. Estudando o guide encontrei referência a desenvolvimento seguro e ao OWASP. Basicamente implementando o Top10 do OWASP você está compliance com o requerimento 6.5.

Requirement 6: Develop and maintain secure systems and applications Unscrupulous individuals use security vulnerabilities to gain privileged access to systems. Many of these vulnerabilities are fixed via vendor security patches, and all systems should have current software patches to protect against exploitation by employees, external hackers, and viruses. For in-house developed applications, numerous vulnerabilities can be avoided by using standard system development processes and secure coding techniques.

6.1 Ensure that all system components and software have the latest vendor-supplied security patches.
6.1.1 Install relevant security patches within one month of release.

6.2 Establish a process to identify newly discovered security vulnerabilities (e.g., subscribe to alert services freely available on the Internet). Update your standards to address new vulnerability issues.

Maintain a Vulnerability Management Program

6.3 Develop software applications based on industry best practices and include information security throughout the software development life cycle. Include the following:

6.3.1 Testing of all security patches and system and software configuration changes beforedeployment
6.3.2 Separate development/test and production environments
6.3.3 Separation of duties between development/test and production environments
6.3.4 Production data (real credit card numbers) are not used for testing or development
6.3.5 Removal of test data and accounts before production systems become active
6.3.6 Removal of custom application accounts, usernames, and passwords before applications become active or are released to customers.
6.3.7 Review of custom code prior to release to production or customers, to identify anypotential coding vulnerability

6.4 Follow change control procedures for all system and software configuration changes. Theprocedures should include:

6.4.1 Documentation of impact
6.4.2 Management sign-off by appropriate parties
6.4.3 Testing that verifies operational functionality
6.4.4 Back-out procedures.

6.5 Develop web software and applications based on secure coding guidelines such as the OpenWeb Application Security Project guidelines. Review custom application code to identify codingvulnerabilities. See http://www.owasp.org/ - “The Ten Most Critical Web Application Security Vulnerabilities.” Cover prevention of common coding vulnerabilities in software developmentprocesses, to include:

6.5.1 Unvalidated input
6.5.2 Broken access control (e.g., malicious use of user IDs)
6.5.3 Broken authentication/session management (use of account credentials and sessioncookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (e.g., SQL injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management.
OWASP
Capítulo Brasil do OWASP
Top10 em Português
PCI por Mastercard
PCI por VISA

16 de outubro de 2006

Blackberry Security Checklists

Recentemente foi discutido na CISSP-BR questões de segurança na implementação de Blackberry, aqui mesmo no blog e no blog do Eduardo Cabral já haviamos comentado sobre os perigos que uma implementação incorreta pode causar.

Já existe bastante material sobre o assunto, agora em Setembro de 2006 a DISA e o DOD lançaram um checklist de segurança para o Blackberry.

O checklist trata de características de autenticação, criptografia e também de segurança em Bluetooth.
Blackberry Security Checklist

Blackberry Security Checklists

Recentemente foi discutido na CISSP-BR questões de segurança na implementação de Blackberry, aqui mesmo no blog e no blog do Eduardo Cabral já haviamos comentado sobre os perigos que uma implementação incorreta pode causar.

Já existe bastante material sobre o assunto, agora em Setembro de 2006 a DISA e o DOD lançaram um checklist de segurança para o Blackberry.

O checklist trata de características de autenticação, criptografia e também de segurança em Bluetooth.

Blackberry Security Checklist



12 de outubro de 2006

Screensaver for Awareness

Recentemente o Secure Team divulgou um screensaver para usar em campanhas de conscientização, ele não é tão completo quanto o visible statement, mas, sem dúvida é uma boa opção freeware e com o código fonte disponivel.

Se você não quer fazer grandes alterações, é possivel mudar somente o conteúdo das mensagens, você pode incluir suas próprias mensagens.

O code.ae.screensavers usa um xml chamado cascrsec.xml para armazenar as mensagens. É só você abrir ele com um bloco de notas e alterar o conteúdo.

Estrutura do xml:



Monte o seu screensaver, com suas mensagens e compartilhe com a comunidade, usando os comentários.
code.ae.screensavers
Visible Statement

Screensaver for Awareness

Recentemente o Secure Team divulgou um screensaver para usar em campanhas de conscientização, ele não é tão completo quanto o visible statement, mas, sem dúvida é uma boa opção freeware e com o código fonte disponivel.

Se você não quer fazer grandes alterações, é possivel mudar somente o conteúdo das mensagens, você pode incluir suas próprias mensagens.

O code.ae.screensavers usa um xml chamado cascrsec.xml para armazenar as mensagens. É só você abrir ele com um bloco de notas e alterar o conteúdo. Estrutura do xml:



Monte o seu screensaver, com suas mensagens e compartilhe com a comunidade, usando os comentários.


code.ae.screensavers


Visible Statement

11 de outubro de 2006

ISO 13335-3 Techniques for the management of it security

Para os profissionais, estudantes que não tiveram contato com a ISO 13335 sobre análise de riscos, o Vanderson C. Siewert fez um bom resumo sobre a norma no site Viva o Linux.

1. Resumo
2. Artigo
3. Anexos
4. Tabela
5. Referência e créditos
Viva o Linux

ISO 13335-3 Techniques for the management of it security

Para os profissionais, estudantes que não tiveram contato com a ISO 13335 sobre análise de riscos, o Vanderson C. Siewert fez um bom resumo sobre a norma no site Viva o Linux.

1. Resumo
2. Artigo
3. Anexos
4. Tabela
5. Referência e créditos
Viva o Linux

4 de outubro de 2006

Programação Orientada a Gambiarras

Soluções técnicas alternativas, ou gambiarra, são técnicas utilizadas por boa parte dos desenvolvedores. Assim como orientação a objetos, existe uma ciência que estuda a Programação Orientada a Gambiarras.

Essa semana postaram na lista código seguro um guia completo para POG (Programação Orientada a Gambiarras), não deixe de ler esse "guide", quem sabe você não emprega um exemplar de programador POG.


Guia completo de POG

Programação Orientada a Gambiarras

Soluções técnicas alternativas, ou gambiarra, são técnicas utilizadas por boa parte dos desenvolvedores. Assim como orientação a objetos, existe uma ciência que estuda a Programação Orientada a Gambiarras.

Essa semana postaram na lista código seguro um guia completo para POG (Programação Orientada a Gambiarras), não deixe de ler esse "guide", quem sabe você não emprega um exemplar de programador POG.



Guia completo de POG