Ontem iniciei uma discussão na CISSP-BR sobre a confidencialidade e integridade das mídias de backup.
Hoje é comum empresas entregarem suas mídias para empresas especializadas em armazenamento de mídias. Essas empresas possuem infra-estrutura adequada para armazenamento, mais meu questionamento vai um pouco mais longe e o Rafael Hashimoto descreveu bem isso na lista.
Ok, transferimos a responsabilidade de armazenar as mídias para uma empresa com expertise e infra-estrutura adequada para armazena-las, mas, e o processo como fica? Já tive oportunidade de visitar algumas empresas e nenhuma delas tinha nenhum processo definido sobre essa modalidade.
A empresa retira as mídias com equipamentos adequados, recepientes que protegem as mídias de calor excessivo, chuva, humidade, etc... Mas, e as informações? Sei que existem alternativas, um box lacrado, somente a empresa dona da informação abre, a empresa de estore só armazena em local apropriado ou criptografar o backup, mais não vejo isso com frequência, geralmente as empresas entregam seus dados a terceiros sem a preocupação devida, existem contratos firmados entre as partes, mais contrato garante um vazamento de informação? Valores financeiros cobrem esse tipo de impacto na imagem da empresa? Eu acredito que não.
Sem contar outros problemas, como é feito os testes dessas mídias, com qual periodicidade, se é que é feito, são analisados e restaurados os backups?
Se alguém têm uma experiência mais agradável do que a que eu tenho tido nas empresas poderia compartilhar com a gente.
30 de setembro de 2005
Dados a "salvo"
Ontem iniciei uma discussão na CISSP-BR sobre a confidencialidade e integridade das mídias de backup.
Hoje é comum empresas entregarem suas mídias para empresas especializadas em armazenamento de mídias. Essas empresas possuem infra-estrutura adequada para armazenamento, mas meu questionamento vai um pouco mais longe e o Rafael Hashimoto descreveu bem isso na lista.
Ok, transferimos a responsabilidade de armazenar as mídias para uma empresa com expertise e infra-estrutura adequada para armazena-las, mas, e o processo como fica? Já tive oportunidade de visitar algumas empresas e nenhuma delas tinha nenhum processo definido sobre essa modalidade.
A empresa retira as mídias com equipamentos adequados, recepientes que protegem as mídias de calor excessivo, chuva, humidade, etc... Mas, e as informações? Sei que existem alternativas, um box lacrado, somente a empresa dona da informação abre, a empresa de estore só armazena em local apropriado ou criptografar o backup, mas não vejo isso com frequência. Geralmente as empresas entregam seus dados a terceiros sem a preocupação devida, existem contratos firmados entre as partes. Contrato garante um vazamento de informação? Valores financeiros cobrem esse tipo de impacto na imagem da empresa? Eu acredito que não.
Sem contar outros problemas, como é feito os testes dessas mídias, com qual periodicidade, se é que é feito, são analisados e restaurados os backups?
Se alguém têm uma experiência mais agradável do que a que eu tenho tido nas empresas poderia compartilhar com a gente.
Hoje é comum empresas entregarem suas mídias para empresas especializadas em armazenamento de mídias. Essas empresas possuem infra-estrutura adequada para armazenamento, mas meu questionamento vai um pouco mais longe e o Rafael Hashimoto descreveu bem isso na lista.
Ok, transferimos a responsabilidade de armazenar as mídias para uma empresa com expertise e infra-estrutura adequada para armazena-las, mas, e o processo como fica? Já tive oportunidade de visitar algumas empresas e nenhuma delas tinha nenhum processo definido sobre essa modalidade.
A empresa retira as mídias com equipamentos adequados, recepientes que protegem as mídias de calor excessivo, chuva, humidade, etc... Mas, e as informações? Sei que existem alternativas, um box lacrado, somente a empresa dona da informação abre, a empresa de estore só armazena em local apropriado ou criptografar o backup, mas não vejo isso com frequência. Geralmente as empresas entregam seus dados a terceiros sem a preocupação devida, existem contratos firmados entre as partes. Contrato garante um vazamento de informação? Valores financeiros cobrem esse tipo de impacto na imagem da empresa? Eu acredito que não.
Sem contar outros problemas, como é feito os testes dessas mídias, com qual periodicidade, se é que é feito, são analisados e restaurados os backups?
Se alguém têm uma experiência mais agradável do que a que eu tenho tido nas empresas poderia compartilhar com a gente.
23 de setembro de 2005
Hardening
Conversando com o Anchises e o Augusto ontém tocamos no assunto GINA (Graphical Indentification and Authentication DLL) a dll que é responsável pelas telas de logon do Windows.
Viajando um pouco eu pensei em fortalecer um pouco o sistema de autenticação do windows customizando a MsGina.dll, evitando ataques de keyloger e dificultando a quebra de senhas da SAM (Security Account Manager).
Como? substituindo as senhas digitadas pelo usuário por senhas mais fortes geradas por um algoritmo. Dessa forma o usuário continuaria criando as senhas fracas como nome, data de aniverssário sem enfraquecer o sistema de autenticação da maquina.
Ex.:
Portanto apesar de a senha memorizada e usada pelo usuário ser fraca a senha que vai estar na SAM vai ser sempre a senha forte gerada pelo algoritmo. Logicamente esse algoritmo deve ser implementado em todos os processos de criação, alteração de senha e autenticação.
Com essa implementação dificultariamos muito a quebra de senhas da SAM e eliminariamos o problema dos keyloger, o keyloger irá capturar a senha "joão" digitada pelo usuário, essa senha não é a senha gravada na SAM e só será validada quando digitada na GINA adaptada, portanto usuários externos que capturarem a senha não poderão fazer nada com ela.
Vou pensar melhor nessa solução e fazer um protótipo, breve colocarei algo aqui.
Viajando um pouco eu pensei em fortalecer um pouco o sistema de autenticação do windows customizando a MsGina.dll, evitando ataques de keyloger e dificultando a quebra de senhas da SAM (Security Account Manager).
Como? substituindo as senhas digitadas pelo usuário por senhas mais fortes geradas por um algoritmo. Dessa forma o usuário continuaria criando as senhas fracas como nome, data de aniverssário sem enfraquecer o sistema de autenticação da maquina.
Ex.:
Portanto apesar de a senha memorizada e usada pelo usuário ser fraca a senha que vai estar na SAM vai ser sempre a senha forte gerada pelo algoritmo. Logicamente esse algoritmo deve ser implementado em todos os processos de criação, alteração de senha e autenticação.
Com essa implementação dificultariamos muito a quebra de senhas da SAM e eliminariamos o problema dos keyloger, o keyloger irá capturar a senha "joão" digitada pelo usuário, essa senha não é a senha gravada na SAM e só será validada quando digitada na GINA adaptada, portanto usuários externos que capturarem a senha não poderão fazer nada com ela.
Vou pensar melhor nessa solução e fazer um protótipo, breve colocarei algo aqui.
Hardening
Conversando com o Anchises e o Augusto ontém tocamos no assunto GINA (Graphical Indentification and Authentication DLL) a dll que é responsável pelas telas de logon do Windows.
Viajando um pouco eu pensei em fortalecer um pouco o sistema de autenticação do windows customizando a MsGina.dll, evitando ataques de keyloger e dificultando a quebra de senhas da SAM (Security Account Manager).
Como? substituindo as senhas digitadas pelo usuário por senhas mais fortes geradas por um algoritmo. Dessa forma o usuário continuaria criando as senhas fracas como nome, data de aniverssário sem enfraquecer o sistema de autenticação da maquina.
Ex.:
Portanto apesar de a senha memorizada e usada pelo usuário ser fraca a senha que vai estar na SAM vai ser sempre a senha forte gerada pelo algoritmo. Logicamente esse algoritmo deve ser implementado em todos os processos de criação, alteração de senha e autenticação.
Com essa implementação dificultariamos muito a quebra de senhas da SAM e eliminariamos o problema dos keyloger, o keyloger irá capturar a senha "joão" digitada pelo usuário, essa senha não é a senha gravada na SAM e só será validada quando digitada na GINA adaptada, portanto usuários externos que capturarem a senha não poderão fazer nada com ela.
Vou pensar melhor nessa solução e fazer um protótipo, breve colocarei algo aqui.
Viajando um pouco eu pensei em fortalecer um pouco o sistema de autenticação do windows customizando a MsGina.dll, evitando ataques de keyloger e dificultando a quebra de senhas da SAM (Security Account Manager).
Como? substituindo as senhas digitadas pelo usuário por senhas mais fortes geradas por um algoritmo. Dessa forma o usuário continuaria criando as senhas fracas como nome, data de aniverssário sem enfraquecer o sistema de autenticação da maquina.
Ex.:
Portanto apesar de a senha memorizada e usada pelo usuário ser fraca a senha que vai estar na SAM vai ser sempre a senha forte gerada pelo algoritmo. Logicamente esse algoritmo deve ser implementado em todos os processos de criação, alteração de senha e autenticação.
Com essa implementação dificultariamos muito a quebra de senhas da SAM e eliminariamos o problema dos keyloger, o keyloger irá capturar a senha "joão" digitada pelo usuário, essa senha não é a senha gravada na SAM e só será validada quando digitada na GINA adaptada, portanto usuários externos que capturarem a senha não poderão fazer nada com ela.
Vou pensar melhor nessa solução e fazer um protótipo, breve colocarei algo aqui.
14 de setembro de 2005
Least Privilege
Não vou falar na integra o que é least privilege, com um find no google você consegue isso fácil. Vou somente alertar alguns pontos que serão resolvidos com um pouco de vontade e conhecimento do conceito least privilege.
Quando exploramos uma vulnerabilidade em uma aplicação ela irá utilizar os "privilégios" que o usuário que iniciou ela possui, portanto o ideal seria que um usuário que inicia qualquer aplicação tenha privilégio somente para disponibilizar os recursos da aplicação, nada mais que isso.
Mais ai o que encontramos, geralmente as aplicações são iniciadas por usuários com privilégios muito superiores, com o mesmo usuário que iniciou uma aplicação pode ser feito tudo na maquina, é comum as pessoas setarem o Administrador da maquina para iniciar aplicações, isso é um perigo enorme.
Esse problema se estende aos usuários e administradores, é comum o desenvolvedor ou administrador da rede/maquina logar com um usuário administrador, quando falo administrador falo de qualquer usuário que tenha privilégios master na maquina.
Isso não deve acontecer, um desenvolvedor deve possuir um usuário que tenha acesso somente aos recursos que ele irá utilizar, um administrador de rede analista de suporte deve possuir dois usuários, um com privilégio mínimo e outro com privilégio master quando for necessário. Como?
No linux é comum se usar o SU para chamar um usuário com mais privilégio para executar alguma atividade que exija mais privilégio, já é uma cultura nos usuários do linux, agora quando falamos em windows a coisa muda um pouco, mais é perfeitamente possível usar um recurso semelhante para conseguir o mesmo resultado.
Podemos usar o "runas" do windows pra isso.
Quando exploramos uma vulnerabilidade em uma aplicação ela irá utilizar os "privilégios" que o usuário que iniciou ela possui, portanto o ideal seria que um usuário que inicia qualquer aplicação tenha privilégio somente para disponibilizar os recursos da aplicação, nada mais que isso.
Mais ai o que encontramos, geralmente as aplicações são iniciadas por usuários com privilégios muito superiores, com o mesmo usuário que iniciou uma aplicação pode ser feito tudo na maquina, é comum as pessoas setarem o Administrador da maquina para iniciar aplicações, isso é um perigo enorme.
Esse problema se estende aos usuários e administradores, é comum o desenvolvedor ou administrador da rede/maquina logar com um usuário administrador, quando falo administrador falo de qualquer usuário que tenha privilégios master na maquina.
Isso não deve acontecer, um desenvolvedor deve possuir um usuário que tenha acesso somente aos recursos que ele irá utilizar, um administrador de rede analista de suporte deve possuir dois usuários, um com privilégio mínimo e outro com privilégio master quando for necessário. Como?
No linux é comum se usar o SU para chamar um usuário com mais privilégio para executar alguma atividade que exija mais privilégio, já é uma cultura nos usuários do linux, agora quando falamos em windows a coisa muda um pouco, mais é perfeitamente possível usar um recurso semelhante para conseguir o mesmo resultado.
Podemos usar o "runas" do windows pra isso.
Least Privilege
Não vou falar na integra o que é least privilege, com um find no google você consegue isso fácil. Vou somente alertar alguns pontos que serão resolvidos com um pouco de vontade e conhecimento do conceito least privilege.
Quando exploramos uma vulnerabilidade em uma aplicação ela irá utilizar os "privilégios" que o usuário que iniciou ela possui, portanto o ideal seria que um usuário que inicia qualquer aplicação tenha privilégio somente para disponibilizar os recursos da aplicação, nada mais que isso.
Não é o que encontramos por aí. Geralmente as aplicações são iniciadas por usuários com privilégios muito superiores, com o mesmo usuário que iniciou uma aplicação pode ser feito tudo na maquina, é comum as pessoas setarem o Administrador da maquina para iniciar aplicações, isso é um perigo enorme.
Esse problema se estende aos usuários e administradores, é comum o desenvolvedor ou administrador da rede/maquina logar com um usuário administrador, quando falo administrador falo de qualquer usuário que tenha privilégios master na maquina.
Isso não deve acontecer, um desenvolvedor deve possuir um usuário que tenha acesso somente aos recursos que ele irá utilizar, um administrador de rede analista de suporte deve possuir dois usuários, um com privilégio mínimo e outro com privilégio master quando for necessário. Como?
No linux é comum se usar o SU para chamar um usuário com mais privilégio para executar alguma atividade que exija mais privilégio, já é uma cultura nos usuários do linux, agora quando falamos em windows a coisa muda um pouco, mais é perfeitamente possível usar um recurso semelhante para conseguir o mesmo resultado.
Podemos usar o "runas" do windows pra isso.
Quando exploramos uma vulnerabilidade em uma aplicação ela irá utilizar os "privilégios" que o usuário que iniciou ela possui, portanto o ideal seria que um usuário que inicia qualquer aplicação tenha privilégio somente para disponibilizar os recursos da aplicação, nada mais que isso.
Não é o que encontramos por aí. Geralmente as aplicações são iniciadas por usuários com privilégios muito superiores, com o mesmo usuário que iniciou uma aplicação pode ser feito tudo na maquina, é comum as pessoas setarem o Administrador da maquina para iniciar aplicações, isso é um perigo enorme.
Esse problema se estende aos usuários e administradores, é comum o desenvolvedor ou administrador da rede/maquina logar com um usuário administrador, quando falo administrador falo de qualquer usuário que tenha privilégios master na maquina.
Isso não deve acontecer, um desenvolvedor deve possuir um usuário que tenha acesso somente aos recursos que ele irá utilizar, um administrador de rede analista de suporte deve possuir dois usuários, um com privilégio mínimo e outro com privilégio master quando for necessário. Como?
No linux é comum se usar o SU para chamar um usuário com mais privilégio para executar alguma atividade que exija mais privilégio, já é uma cultura nos usuários do linux, agora quando falamos em windows a coisa muda um pouco, mais é perfeitamente possível usar um recurso semelhante para conseguir o mesmo resultado.
Podemos usar o "runas" do windows pra isso.
13 de setembro de 2005
Convergência
Quem ficou "chateado" sobre meus comentarios sobre convergência segue algumas informações.
No site da Blackberry aquele aparelhinho que vai deixar você conectado 26 horas por dia, aquele que se você não responder um e-mail do seu chefe em 5 minutos ele vai ficar muito bravo e que está sendo vendido pela TIM tem um material sobre como implementar ele com um pouco mais de segurança.
BlackBerry Security Overview
BlackBerry® by Research In Motion
E quem não vive mais sem o skype tem novidades por ai, ele não está mais sozinho, existe uma versão opensource chamado Openwengo de origem francesa e a skype foi vendido para o e-Bay.
No site da Blackberry aquele aparelhinho que vai deixar você conectado 26 horas por dia, aquele que se você não responder um e-mail do seu chefe em 5 minutos ele vai ficar muito bravo e que está sendo vendido pela TIM tem um material sobre como implementar ele com um pouco mais de segurança.
BlackBerry Security Overview
BlackBerry® by Research In Motion
E quem não vive mais sem o skype tem novidades por ai, ele não está mais sozinho, existe uma versão opensource chamado Openwengo de origem francesa e a skype foi vendido para o e-Bay.
Convergência
Quem ficou "chateado" sobre meus comentarios sobre convergência segue algumas informações.
No site da Blackberry aquele aparelhinho que vai deixar você conectado 26 horas por dia, aquele que se você não responder um e-mail do seu chefe em 5 minutos ele vai ficar muito bravo e que está sendo vendido pela TIM tem um material sobre como implementar ele com um pouco mais de segurança.
BlackBerry Security Overview
BlackBerry® by Research In Motion
E quem não vive mais sem o skype tem novidades por ai, ele não está mais sozinho, existe uma versão opensource chamado Openwengo de origem francesa e a skype foi vendido para o e-Bay.
No site da Blackberry aquele aparelhinho que vai deixar você conectado 26 horas por dia, aquele que se você não responder um e-mail do seu chefe em 5 minutos ele vai ficar muito bravo e que está sendo vendido pela TIM tem um material sobre como implementar ele com um pouco mais de segurança.
BlackBerry Security Overview
BlackBerry® by Research In Motion
E quem não vive mais sem o skype tem novidades por ai, ele não está mais sozinho, existe uma versão opensource chamado Openwengo de origem francesa e a skype foi vendido para o e-Bay.
Assinar:
Postagens (Atom)