Um estudo do NIST (National Institute of Standarts Technology) aponta que 43% das vulnerabilidades em aplicações na WEB estão associadas ao PHP, O NIST atribui isso à utilização por profissionais amadores.
Eu classificaria como alienados, e não amadores. Porque alienados e não amadores? Porque muitos profissionais são profissionais de desenvolvimento e não dão a mínima para o resto.
Costumo dizer que para deixar um desenvolvedor feliz basta um acesso com perfil de administrador e um fone de ouvido para ele se isolar do mundo. Exatamente, se isolar, pois, muitos não sabem o funcionamento básico de um PC, muito menos conceitos de arquitetura e segurança.
A grande maioria dos desenvolvedores só se preocupam em codificar, criar código funcional e cumprir prazos. Basta pegar códigos em sites especializados como: www.phpclasses.org, www.planet-source-code.com entre outros, pode-se encontrar códigos fantásticos, mas, com erros básicos de segurança.
Tudo porque a maioria dos desenvolvedores ainda não se deu conta da necessidade de desenvolver código seguro ou não estamos conseguindo aplicar controles para mitigar isso.
8 de janeiro de 2007
7 de janeiro de 2007
Security Developer
Um estudo do NIST (National Institute of Standarts Technology) aponta que 43% das vulnerabilidades em aplicações na WEB estão associadas ao PHP, O NIST atribui isso à utilização por profissionais amadores.
Eu classificaria como alienados, e não amadores. Porque alienados e não amadores? Porque muitos profissionais são profissionais de desenvolvimento e não dão a mínima para o resto.
Costumo dizer que para deixar um desenvolvedor feliz basta um acesso com perfil de administrador e um fone de ouvido para ele se isolar do mundo. Exatamente, se isolar, pois, muitos não sabem o funcionamento básico de um PC, muito menos conceitos de arquitetura e segurança.
A grande maioria dos desenvolvedores só se preocupam em codificar, criar código funcional e cumprir prazos. Basta pegar códigos em sites especializados como: www.phpclasses.org, www.planet-source-code.com entre outros, pode-se encontrar códigos fantásticos, mas, com erros básicos de segurança.
Tudo porque a maioria dos desenvolvedores ainda não se deu conta da necessidade de desenvolver código seguro ou não estamos conseguindo aplicar controles para mitigar isso.
Eu classificaria como alienados, e não amadores. Porque alienados e não amadores? Porque muitos profissionais são profissionais de desenvolvimento e não dão a mínima para o resto.
Costumo dizer que para deixar um desenvolvedor feliz basta um acesso com perfil de administrador e um fone de ouvido para ele se isolar do mundo. Exatamente, se isolar, pois, muitos não sabem o funcionamento básico de um PC, muito menos conceitos de arquitetura e segurança.
A grande maioria dos desenvolvedores só se preocupam em codificar, criar código funcional e cumprir prazos. Basta pegar códigos em sites especializados como: www.phpclasses.org, www.planet-source-code.com entre outros, pode-se encontrar códigos fantásticos, mas, com erros básicos de segurança.
Tudo porque a maioria dos desenvolvedores ainda não se deu conta da necessidade de desenvolver código seguro ou não estamos conseguindo aplicar controles para mitigar isso.
16 de novembro de 2006
[Livro] Software Security - Building Security In
Estava dando uma olhada no livro Software Security - Building Security In do Gary McGraw e gostei muito do que vi.
Seguindo o chavão: uma imagem vale mais do que mil palavras, eu separei uma imagem que mostra pontos chaves no desenvolvimento seguro de software.
Seguindo o chavão: uma imagem vale mais do que mil palavras, eu separei uma imagem que mostra pontos chaves no desenvolvimento seguro de software.
Software Security - Building Security In
Gary McGraw
[Livro] Software Security - Building Security In
Estava dando uma olhada no livro Software Security - Building Security In do Gary McGraw e gostei muito do que vi.
Seguindo o chavão: uma imagem vale mais do que mil palavras, eu separei uma imagem que mostra pontos chaves no desenvolvimento seguro de software.
Seguindo o chavão: uma imagem vale mais do que mil palavras, eu separei uma imagem que mostra pontos chaves no desenvolvimento seguro de software.
Software Security - Building Security In
Gary McGraw
14 de novembro de 2006
Microsoft Software License for DRP
Recentemente a microsoft disponibilizou uma licença que permite que seja instalada uma versão em um Cold Site, ou seja, a segunda licença deve ser usada somente na ativação do Cold Site.
Mais detalhes sobre a licença "Cold Server Backup for Disaster Recovery a Microsoft Software Assurance Benefit" pode ser encontrada no site da microsoft.
Mais detalhes sobre a licença "Cold Server Backup for Disaster Recovery a Microsoft Software Assurance Benefit" pode ser encontrada no site da microsoft.
Volume Licensing Briefs
Backup Sites by Wikipedia
Microsoft Software License for DRP
Recentemente a microsoft disponibilizou uma licença que permite que seja instalada uma versão em um Cold Site, ou seja, a segunda licença deve ser usada somente na ativação do Cold Site.
Mais detalhes sobre a licença "Cold Server Backup for Disaster Recovery a Microsoft Software Assurance Benefit" pode ser encontrada no site da microsoft.
Mais detalhes sobre a licença "Cold Server Backup for Disaster Recovery a Microsoft Software Assurance Benefit" pode ser encontrada no site da microsoft.
Volume Licensing Briefs
Backup Sites by Wikipedia
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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.
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
Assinar:
Postagens (Atom)