Um amigo recentemente compartilhou um post sobre as observações de Richard Feynman sobre o ensino de física no Brasil dos anos 50 e sobre como os problemas que ele observou ainda são visíveis no Brasil de hoje.
O post me fez pensar um pouco sobre as experiencias da minha família com o ensino de primeiro e segundo graus no Brasil e no exterior. A gente discute bastante as diferenças que temos notado com relação às questões curriculares e também às atividades extra classe.
Primeiro algumas constatações similares às de Feynman: o ensino no Brasil tem um viés mais "conteudista"(odeio essa palavra, mas não achei nenhuma melhor...). Isso vem tanto da nossa observação das atividades desenvolvidas por nossos filhos quanto da comparação dos requisitos curriculares.
Desde que nos mudamos, temos a preocupação em manter o curriculo escolar das crianças compatível com os requisitos da legislação brasileira para facilitar a validação do diploma ao voltarmos ao Brasil. No caso do DF, onde morávamos, a regra é que o curriculo cursado no exterior tem de ser similar às definições das Diretrizes Curriculares Nacionais para o Ensino Médio. Assim, tivemos de estudar as diretrizes curriculares para ver como deixar o currículo daqui o mais "similar" possível.
A primeira diferença é a flexibilidade. A única opção que a legislação brasileira deixa para os alunos de segunda grau é a escolha da língua estrangeira. Já o esquema americano se baseia no ensino de língua materna e matemática como obrigatórios e deixa muitas opções para os alunos montarem o seu currículo. Um exemplo concreto: enquanto a lei brasileira exige o ensino de física, química E biologia, a escola daqui permite que o aluno escolha apenas duas das ciências em cada ano. Nas áreas de humanas a diferença é ainda maior: no Brasil exige-se história, geografia, sociologia E filosofia; o currículo daqui inclui uma disciplina de "humanities", que agrega as diversa áreas de humanas. Em compensação a ênfase em matemática e na língua materna aqui é muito maior.
Ao menos no papel, o currículo brasileiro é muito mais abrangente e completo. Mas aí entra a crítica de Feynman que, já nos anos 50, percebeu que a ênfase brasileira em conteúdo não é acompanhada de uma compreensão mais aprofundada dos princípios básicos. A observação de Feynman sobre a falta de experimentos no ensino de física no Brasil pode ser, pela nossa experiência, extrapolada para o ensino das demais ciências. Se no Brasil as crianças faziam uma ou, no máximo, duas visitas ao laboratório de ciências da escola por ano, aqui as aulas de ciências se dão no próprio laboratório. Enquanto no Brasil o ensino de biologia se dava com o profesor mostrando modelos de plástico dos órgãos, aqui os alunos dissecam corações ou olhos (um para cada dupla ao invés de um único manipulado apenas pelo professor).
Outro ponto que muito nos chamou a atenção é que as escolas e as turmas aqui são bem menores. A escola atual é considerada grande por aqui: tem 1500 alunos do maternal ao segundo grau. A escola brasileira tinha cerca de 5000 alunos, sem contar com o segunda grau, que era em um prédio separado. Nas salas de aula, enquanto no Brasil turmas de 4a série (5o ano) com 40 a 45 alunos eram consideradas "normais" pela escola, aqui as turmas tem no máximo 20 alunos, muitas vezes menos, mesmo no segundo grau. Aulas especializadas podem ter apenas 3 alunos em alguns casos.
O tamanho das turmas afeta a capacidade dos professores no ensino de ciências (e outras matérias, obviamente), em especial a capacidade de promoverem aulas em laboratórios. Alguém consegue imaginar uma aula em laboratório com 40 alunos de 5a série?
O tamanho das turmas e a quantidade de alunos na escola afetam também a capacidade dos professores de ter um acompanhamento mais próximo do desempenho e da evolução de cada aluno. Enquanto no Brasil a escola pedia para os pais levarem os alunos nas "reuniões" periódicas com os professores para facilitar que os professores reconhecessem cada aluno, aqui basta o nome. O acompanhamento é muito mais próximo das dificuldades e facilidades dos alunos.
Até por se tratar de um escola internacional, a ênfase no ensino de línguas que aqui é muito maior. Os alunos do ensino básico tem aulas de duas línguas estrangeiras e os do segundo grau tem três. No Brasil é conhecido o baixo nível do ensino de inglês nas escolas, que obriga os pais a recorrerem a escolas especializadas.
Obviamente nem tudo são flores. A gente tem sentido falta da quantidade de atividades extra curriculares que tinha no Brasil. As atividades esportivas ocorriam mais vezes por semana e sempre tinha alguma competição no final de semana. Aqui teve bastante atividade durante o período de competição e depois acabou. Aulas de teatro são também sazonais e não duram todo o período escolar.
O apoio que a escola dá aos alunos é bem maior, com conselheiros para ajudar desde a montar o currículo até à escolher a universidade. Isso faz com que as crianças fiquem mais dependentes. Como no Brasil a coisa vai mais na base do "se vira", as crianças acabam aprendendo a se virarem mais sozinhas.
E, na questão do conteúdo, temos aqui um modelo que acaba pecando pela falta. Um exemplo que nos deixou preocupados é que a matéria de Geografia no segundo grau é opcional e oferecida aos alunos que tem dificuldades em ciências. Talvez isso explique a famosa falta de conhecimento de geografia pelos norte-americanos.
Voltando às observações de Richard Feynman, a gente concorda com a maioria delas e vê uma abordagem diferente no ensino de ciências por aqui. Mas também não dá pra formar um ser humano completo sem uma base de conteúdo ampla e diversificada. Um meio termo talvez seja possível e, quem sabe, poderia ter os pontos positivos das duas abordagens. Será que é possível formar com um pouco menos de conteúdo do que é exigido no Brasil e com uma quantidade de experimentos e de suporte ao ensino próxima ao que temos por aqui?
Pra encerrar: estamos comparando as experiências que tivemos em escolas particulares em Brasília e Nova York.
domingo, 12 de maio de 2013
segunda-feira, 31 de outubro de 2011
FHR: novidades
Algumas novidades rápidas sobre o FHR (leia mais sobre o projeto no último post):
- o FHR agora é OWASP FHR, o projeto foi aprovado pelo OWASP. A partir de agora, as novidades serão postadas na página do projeto: https://www.owasp.org/index.php/OWASP_File_Hash_Repository
- O servidor DNS do FHR está integrado ao DNS mundial. Ainda restam algumas arestas a aparar com relação à disponibilidade, mas já está funcionando.
Agora, para fazer consultas, basta usar:
dig 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.netou, caso queira o registro completo:
dig TXT 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.netoutros comandos que gerem consultas DNS também podem ser usados, como:
ping 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.netComo detalhe técnico, registro que o servidor do FHR está rodando na núvem da Amazon (AWS EC2).
sexta-feira, 14 de outubro de 2011
Novo projeto: File hash repository
Estive quieto nos últimos tempos, mas estou de volta. :-)
Fora ajudar na organização do AppSec Latam 2011, eu estive também recluso trabalhando em um novo projeto, o File Hash Repository (FHR), que, se tudo der certo, será em breve um novo projeto do OWASP.
Mas o que é o FHR?
Simplificando: o FHR é um repositório de hashes de arquivos. Só que a ideia é ir além de somente guardar uma lista de hashes: pretendo que o repositório possa indicar quando os arquivo em questão for (parte de) um malware ou quando for um arquivo reconhecidamente benigno. Assim, qualquer um poderia consultar o hash de um arquivo para saber se corresponde a um malware ou a um arquivo já conhecido.
Já não existem outras fontes com essa informação?
Sim, e uma das ideias do projeto é agregar informações de diversas fontes. Por exemplo, o NIST tem o NSRL, que provê hashes de arquivo reconhecidamente benignos. O problema é que o NIST fornece essa informação em um arquivo texto cujo download tem mais de 1GB de tamanho. Outras fontes conhecidas são o MHR do Team Cymru, o repositório de hashes do SANS e o Virus Total.
Além de agregar as informações, um dos objetivos do FHR é permitir livre acesso à sua base de dados.
O livre acesso a uma base de dados que contém malware não é perigoso?
Sim, é perigoso, mas o repositório do projeto não vai conter malwares. O repositório só vai ter os hashes dos malwares, o que não apresenta nenhum perigo.
Detectar malwares usando hashes não é boa estratégia.
Certamente, e o projeto não tem o objetivo de substituir os antivírus atuais. No entanto, a criação de hashes é mais eficiente e fácil do que a criação de vacinas genéricas e é uma estratégia que vem sendo usada como complemento para os antivírus tradicionais. Vários produtos comerciais incluem o uso de cloud computing como parte de suas estratégias. Infelizmente, os produtores dessas tecnologias não permitem que façamos consultas a suas bases de dados de hashes. Com o FHR, o objetivo é criar uma base de livre consulta e que possa ser usada por todo mundo.
O FHR vai ser integrado em sistemas de antivírus?
Eu pretendo desenvolver alguns sistemas clientes para o FHR que possam fazer varreduras em estações de trabalho e consultar a base se dados do FHR para tentar identificar malwares. Esses clientes serão criados para uso próprio e como prova de conceito e terão seus códigos abertos. Seria ótimo se tivermos apoio de algum fabricante de antivírus, mas só o tempo dirá.
Tecnicamente, como funciona o FHR?
Como não poderia deixar de ser, o núcleo do sistema é a sua base de dados de hashes. Hoje essa base roda em MySQL (pretendo depois fazer um post sobre a novela da escolha da base de dados).
Em volta dessa base, podemos desenvolver várias interfaces de consulta. Algumas ideias de protocolos para consultas são:
Claro! Entre em contato comigo ou deixe um comentário.
Fora ajudar na organização do AppSec Latam 2011, eu estive também recluso trabalhando em um novo projeto, o File Hash Repository (FHR), que, se tudo der certo, será em breve um novo projeto do OWASP.
Mas o que é o FHR?
Simplificando: o FHR é um repositório de hashes de arquivos. Só que a ideia é ir além de somente guardar uma lista de hashes: pretendo que o repositório possa indicar quando os arquivo em questão for (parte de) um malware ou quando for um arquivo reconhecidamente benigno. Assim, qualquer um poderia consultar o hash de um arquivo para saber se corresponde a um malware ou a um arquivo já conhecido.
Já não existem outras fontes com essa informação?
Sim, e uma das ideias do projeto é agregar informações de diversas fontes. Por exemplo, o NIST tem o NSRL, que provê hashes de arquivo reconhecidamente benignos. O problema é que o NIST fornece essa informação em um arquivo texto cujo download tem mais de 1GB de tamanho. Outras fontes conhecidas são o MHR do Team Cymru, o repositório de hashes do SANS e o Virus Total.
Além de agregar as informações, um dos objetivos do FHR é permitir livre acesso à sua base de dados.
O livre acesso a uma base de dados que contém malware não é perigoso?
Sim, é perigoso, mas o repositório do projeto não vai conter malwares. O repositório só vai ter os hashes dos malwares, o que não apresenta nenhum perigo.
Detectar malwares usando hashes não é boa estratégia.
Certamente, e o projeto não tem o objetivo de substituir os antivírus atuais. No entanto, a criação de hashes é mais eficiente e fácil do que a criação de vacinas genéricas e é uma estratégia que vem sendo usada como complemento para os antivírus tradicionais. Vários produtos comerciais incluem o uso de cloud computing como parte de suas estratégias. Infelizmente, os produtores dessas tecnologias não permitem que façamos consultas a suas bases de dados de hashes. Com o FHR, o objetivo é criar uma base de livre consulta e que possa ser usada por todo mundo.
O FHR vai ser integrado em sistemas de antivírus?
Eu pretendo desenvolver alguns sistemas clientes para o FHR que possam fazer varreduras em estações de trabalho e consultar a base se dados do FHR para tentar identificar malwares. Esses clientes serão criados para uso próprio e como prova de conceito e terão seus códigos abertos. Seria ótimo se tivermos apoio de algum fabricante de antivírus, mas só o tempo dirá.
Tecnicamente, como funciona o FHR?
Como não poderia deixar de ser, o núcleo do sistema é a sua base de dados de hashes. Hoje essa base roda em MySQL (pretendo depois fazer um post sobre a novela da escolha da base de dados).
Em volta dessa base, podemos desenvolver várias interfaces de consulta. Algumas ideias de protocolos para consultas são:
- DNS
- Web
- WebServices
- JSON
No momento, já tenho funcionando a interface para consultas via DNS, que só não está integrada ao DNS global porque meu provedor bloqueia acessos à porta 53 UDP. A medida que o projeto amadurecer, devemos conseguir migrar o servidor para um provedor de hosting a então teremos um DNS 100% funcional.
Quais informações já estão disponíveis?
No momento a base de dados já tem os 20 milhões de registros do FHR. Em breve teremos funcionalidades de consulta a outras bases devidamente implementadas.
Para cada arquivo cadastrado, temos as seguintes informações:
- SHA-1
- MD5
- fonte
- data de quando o sistema viu o hash/arquivo pela primeira vez (não disponível para os arquivos do NIST)
- status (GOOD, MALWARE, UNKNOWN, SUSPICIOUS)
- tamanho
- certeza (percentagem que indica o grau de certeza com relação ao status do arquivo).
É possível testar o sistema?
Claro! A interface DNS está disponível para testes. Mas, como está rodando em casa, nem sempre está no ar. Para ver como funciona, é necessário fazer uma consulta DNS ao servidor do FHR (ns.hash.sapao.net) na porta 1053. O hash deve ser acrescido ao sufixo .hash.sapao.net. A consulta do registro tipo A retorna um endereço da rede 127.0.0.0/8 cujo último octeto indica o status do arquivo. Consultas do tipo TXT retornam uma string com todas as informações disponíveis.
Eu recomendo o uso do dig para fazer as consultas manualmente. Um exemplo de linha de comando seria:
dig @ns.hash.sapao.net -p1053 TXT 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.netÉ possível contribuir com o projeto?
Claro! Entre em contato comigo ou deixe um comentário.
quarta-feira, 29 de junho de 2011
Lei de crimes digitais - 2
Embora eu não concorde com a gritaria geral contra o projeto de crimes digitais, tem um ponto onde eu acho que o projeto poderia ser melhorado: a questão dos códigos maliciosos.
O texto diz o seguinte:
Muitas vezes usamos programas capazes de realizar ataques para testar o estado da segurança de alguma rede ou sistema. Esses programas claramente executam "ações danosas", mas os profissionais os utilizam de forma responsável para que os danos, caso existam, seja limitados. Embora a posse e a construção dessas ferramentas não esteja tipificada, esses programas só são úteis se forem distribuídos, o que poderia ser considerado "difusão".
Ou seja, ferramentas de pentest estariam disponíveis apenas aos criminosos, dando um vantagem indesejada com relação aos verdadeiros profissionais de segurança. Esse artigo e a definição de código malicioso merecem um reescrita cuidadosa. Nesse caso, acho que a intenção é o cerne da questão. A difusão para fins de causar dano deve ser criminalizada, mas a difusão como forma de compartilhamento de conhecimento deve ser permitida.
Edit: uma nova proposta corrige esta distorção: http://edemocracia.camara.gov.br/en/web/seguranca-da-internet/wikiLegis
O texto diz o seguinte:
IV – código malicioso: o conjunto de instruções e tabelas de informações ou qualquer
outro sistema desenvolvido para executar ações danosas ou obter dados ou informações de
forma indevida;
Inserção ou difusão de código maliciosoNesse ponto, podemos ter a criminalização da atividade de desenvolvimento de softwares de segurança, o que seria prejudicial às atividades dos profissionais de segurança da informação.
Art. 163-A. Inserir ou difundir código malicioso em dispositivo de
comunicação, rede de computadores, ou sistema informatizado:
Pena – reclusão, de 1 (um) a 3 (três) anos, e multa.
Muitas vezes usamos programas capazes de realizar ataques para testar o estado da segurança de alguma rede ou sistema. Esses programas claramente executam "ações danosas", mas os profissionais os utilizam de forma responsável para que os danos, caso existam, seja limitados. Embora a posse e a construção dessas ferramentas não esteja tipificada, esses programas só são úteis se forem distribuídos, o que poderia ser considerado "difusão".
Ou seja, ferramentas de pentest estariam disponíveis apenas aos criminosos, dando um vantagem indesejada com relação aos verdadeiros profissionais de segurança. Esse artigo e a definição de código malicioso merecem um reescrita cuidadosa. Nesse caso, acho que a intenção é o cerne da questão. A difusão para fins de causar dano deve ser criminalizada, mas a difusão como forma de compartilhamento de conhecimento deve ser permitida.
Edit: uma nova proposta corrige esta distorção: http://edemocracia.camara.gov.br/en/web/seguranca-da-internet/wikiLegis
Lei de crimes digitais
A proposta de lei é polêmica e tem seus pontos falhos, mas me irrita a quantidade de críticas que o projeto recebe de gente que força a barra só pra poder falar mal. A última que eu li foi que "o projeto vai criminalizar a cultura e pesquisa hacker".
Isso porque o projeto define como crime:
Além disso, chamar as pessoas que invadem sistemas de pesquisadores é um desrespeito com os pesquisadores de verdade. Nenhum pesquisador que seja digno do nome sai por aí invadindo sistemas. E os profissionais de verdade não invadem sistemas de graça, até porque são muito bem pagos para invadirem os sistemas de seus clientes.
Confundir os script kiddies que ficam por aí "testando" sites com profissionais de verdade só demonstra falta de conhecimento ou má fé.
Um paralelo com o mundo físico é possível nesse caso: no jardim em frente à minha casa, tenho um coqueiro. Embora não haja grade ou muro entre a rua e o jardim, há uma pequena cerca viva que deixa claro que o jardim faz parte da minha propriedade. Algumas vezes já aconteceu de eu pegar gente subindo no coqueiro para apanhar cocos. Embora qualquer prejuízo que isso possa me causar seja insignificante, não deixa de ser uma invasão à minha propriedade para pegar algo que me pertence.
Para mim, um invasor de sistemas, mesmo que não altere nada, tem uma atitude parecida com a pessoa que pega os meus cocos: está desrespeitando os direitos do legítimo proprietário do bem, seja ele um coco ou um sistema. Não importa o tamanho do prejuízo ou das defesas instaladas para evitar a invasão: se há uma clara delimitação de onde termina o território público, não há motivo que justifique o desrespeito à propriedade privada.
Continuando o paralelo, se o cara que pegou os cocos tivesse batido na porta e perguntado se podia pegar um coco, eu certamente teria deixado e, mais ainda, teria negociado para que ele pegasse todos os que estivessem bons e lhe daria alguns como "pagamento" pelo trabalho. Por que a atitude correta no mundo virtual seria outra? Eu conheço muitas organizações que gastam bastante dinheiro para testar a segurança de sues sistemas. Um pesquisador de verdade poderia facilmente negociar para fazer esses testes em troca dos conhecimentos adquiridos ou da possibilidade de divulgação dos problemas encontrados (anonimamente, claro).
Enfim, a ética dos grupos com os quais convivo, muitos dos quais poderiam ser claramente definidos como "hackers", é: "nunca entre sem pedir licença". Em outras palavras, testes de segurança só devem ser feitos com a devida autorização e, se alguma vulnerabilidade for descoberta, nunca deve ser usada para acessar sistemas indevidamente. E esse comportamento não será afetado pela lei.
Outra crítica que vejo muito é de que a lei tem definições muito vagas. Isso acontece com outros tipo penais e não vejo tanta reclamação, Por exemplo a definição de dano:
A aplicação das leis não se dá ao pé da letra e exige bom senso e a observância de diversos princípios que o Direito desenvolveu ao longo dos anos. Se não levarmos isso em conta, vamos acabar pedindo a revisão de toda a nossa legislação penal. Por outro lado, se as definições de crimes mais corriqueiros pode ser feita sem tanta precisão, por que os "crimes de informática" precisam ser tipificados nos mínimos detalhes?
Isso porque o projeto define como crime:
Se alguém defende a "cultura hacker", deveria ao menos se dar ao trabalho de ler um pouco a respeito. Mesmo a wikipedia admite que, dentro da "ética hacker", a invasão de sistemas não é unanimamente aceita como um comportamento éticamente aceitável. Ou seja, colocar a invasão de sistemas como algo natural na "cultura hacker" é generalizar um pensamento de alguns, em detrimento do demais.Art. 285-A. Acessar rede de computadores, dispositivo de comunicação ou sistema informatizado, sem autorização do legítimo titular, quando exigida:Pena – reclusão, de 1 (um) a 3 (três) anos, e multa.Parágrafo único. Se o agente se vale de nome falso ou da utilização de identidade de terceiros para a prática do crime, a pena é aumentada de sexta parte.
Além disso, chamar as pessoas que invadem sistemas de pesquisadores é um desrespeito com os pesquisadores de verdade. Nenhum pesquisador que seja digno do nome sai por aí invadindo sistemas. E os profissionais de verdade não invadem sistemas de graça, até porque são muito bem pagos para invadirem os sistemas de seus clientes.
Confundir os script kiddies que ficam por aí "testando" sites com profissionais de verdade só demonstra falta de conhecimento ou má fé.
Um paralelo com o mundo físico é possível nesse caso: no jardim em frente à minha casa, tenho um coqueiro. Embora não haja grade ou muro entre a rua e o jardim, há uma pequena cerca viva que deixa claro que o jardim faz parte da minha propriedade. Algumas vezes já aconteceu de eu pegar gente subindo no coqueiro para apanhar cocos. Embora qualquer prejuízo que isso possa me causar seja insignificante, não deixa de ser uma invasão à minha propriedade para pegar algo que me pertence.
Para mim, um invasor de sistemas, mesmo que não altere nada, tem uma atitude parecida com a pessoa que pega os meus cocos: está desrespeitando os direitos do legítimo proprietário do bem, seja ele um coco ou um sistema. Não importa o tamanho do prejuízo ou das defesas instaladas para evitar a invasão: se há uma clara delimitação de onde termina o território público, não há motivo que justifique o desrespeito à propriedade privada.
Continuando o paralelo, se o cara que pegou os cocos tivesse batido na porta e perguntado se podia pegar um coco, eu certamente teria deixado e, mais ainda, teria negociado para que ele pegasse todos os que estivessem bons e lhe daria alguns como "pagamento" pelo trabalho. Por que a atitude correta no mundo virtual seria outra? Eu conheço muitas organizações que gastam bastante dinheiro para testar a segurança de sues sistemas. Um pesquisador de verdade poderia facilmente negociar para fazer esses testes em troca dos conhecimentos adquiridos ou da possibilidade de divulgação dos problemas encontrados (anonimamente, claro).
Enfim, a ética dos grupos com os quais convivo, muitos dos quais poderiam ser claramente definidos como "hackers", é: "nunca entre sem pedir licença". Em outras palavras, testes de segurança só devem ser feitos com a devida autorização e, se alguma vulnerabilidade for descoberta, nunca deve ser usada para acessar sistemas indevidamente. E esse comportamento não será afetado pela lei.
Outra crítica que vejo muito é de que a lei tem definições muito vagas. Isso acontece com outros tipo penais e não vejo tanta reclamação, Por exemplo a definição de dano:
Pra mim, essa definição permitiria criminalizar muitas condutas que normalmente não vemos como crime. Ou alguém já foi preso por pisar na grama do vizinho? Ou por derramar vinho na toalha da mesa do restaurante?DanoArt. 163 - Destruir, inutilizar ou deteriorar coisa alheia:Pena - detenção, de 1 (um) a 6 (seis) meses, ou multa.
A aplicação das leis não se dá ao pé da letra e exige bom senso e a observância de diversos princípios que o Direito desenvolveu ao longo dos anos. Se não levarmos isso em conta, vamos acabar pedindo a revisão de toda a nossa legislação penal. Por outro lado, se as definições de crimes mais corriqueiros pode ser feita sem tanta precisão, por que os "crimes de informática" precisam ser tipificados nos mínimos detalhes?
sábado, 23 de abril de 2011
Segurança na Web - Uma janela de oportunidades
Já tem algum tempo que eu estou meio sumido, mas tenho um bom motivo para isso: eu estava trabalhando na elaboração de um manifesto com sugestões da comunidade brasileira do OWASP para o governo brasileiro.
A ideia do manifesto é apresentar de forma resumida e didática algumas ideias que são constantemente discutidas dentro do OWASP e fora dele também. Muitas das ideias vem do keynote do Dinis Cruz no IBWAS 2010. Vários dos temas tratados no manifesto refletem o discurso de importante figuras do cenário mundial da segurança de informações, como o Bruce Schneier e o Divid Rice.
O manifesto do OWASP inclui sugestões de ações e políticas que o governo e os gestores de órgãos públicos podem tomar para melhorar as condições de segurança na internet brasileira. São sugestões de possíveis marcos legais e também de ações concretas que poderiam ser adotadas por qualquer órgão público.
O documento está disponível no site do OWASP e, como todos os documentos do OWASP, pode ser livremente distribuídos a todos os possíveis interessados.
A ideia do manifesto é apresentar de forma resumida e didática algumas ideias que são constantemente discutidas dentro do OWASP e fora dele também. Muitas das ideias vem do keynote do Dinis Cruz no IBWAS 2010. Vários dos temas tratados no manifesto refletem o discurso de importante figuras do cenário mundial da segurança de informações, como o Bruce Schneier e o Divid Rice.
O manifesto do OWASP inclui sugestões de ações e políticas que o governo e os gestores de órgãos públicos podem tomar para melhorar as condições de segurança na internet brasileira. São sugestões de possíveis marcos legais e também de ações concretas que poderiam ser adotadas por qualquer órgão público.
O documento está disponível no site do OWASP e, como todos os documentos do OWASP, pode ser livremente distribuídos a todos os possíveis interessados.
quarta-feira, 2 de fevereiro de 2011
Novos livros
Mas estou de volta... Esta semana, meu amigo Kenji anunciou que havia publicado um livro para o Kindle. Fui verificar, comprei o livro, mas não antes de perceber que o Kenji publicou o livro usando o pseudo-pseudônimo de "Leonardo K. Shikida". Pois é: se procurar por Kenji na Amazon, ninguém acha o livro do Kenji. Mas enfim.
Depois de comprar o livro do Kenji, fiquei com inveja. Afinal já tive filhos, plantei árvores, mas nunca havia publicado um livro. Então resolvi publicar um livro sobre desenvolvimento seguro em Java (só pra variar). E o livro já está disponível aqui.
Acabei empolgando e fiz a versão digital do "De Que Cor São Suas Asas?", supostamente meu primeiro livro de ficção, mas que nunca havia sido publicado de verdade. Esse também está disponível na Amazon.
Assinar:
Postagens (Atom)