quarta-feira, 28 de março de 2007
O que vem por aí?
Estarei um tempo fora do blog, por que estou de mudança de endereço e também com provas nas disciplinas que curso. No dia 26 de abril de 2007 estará no ar minhas considerações sobre o artigo: "The Weakest Link: The Human Factor - Lessons Learned from the German WWII Enigma Cryptosystem". Esse artigo foi uma publicação do SANS Institute 2001, como parte do Information Security Reading Room.
Falhas de Segurança Acidentais X Propositais – A necessidade de uma base de conhecimento comum.
Artigo da semana: A Taxonomy of Computer Program Security Flaws, with Examples - CARL E. LANDWEHR, ALAN R. BULL, JOHN P. MCDERMOTT, AND WILLIAM S. CHOI
No artigo selecionado da semana, veremos uma publicação do ano de 1994 que catalogou e caracterizou as diversas falhas de segurança existentes. Fazendo uma leitura do artigo referido, podemos identificar algumas passagens e conceitos bastante interessantes.
As falhas em softwares, em geral, não são documentadas e quando são possuem natureza descritiva muito pobre que não esclarece completamente quais pontos de falha ocorreram. Esse fato possui inúmeras vertentes de explicações. Exemplificando, baseado na hipótese que expor as falhas pode ferir a confiança por parte de clientes e investidores de uma instituição financeira, evitar tais falhas deveria ser um ponto de extrema preocupação de engenheiros e programadores que, em geral, não dedicam esforço suficiente em documentar as falhas e principalmente evitá-las criando requisitos específicos de segurança lógica ainda no período de concepção dos produtos de software que produzem.
Ao se conhecer, classificar e documentar falhas encontradas em produtos de software, certamente despertaria interesse de seus desenvolvedores em criar e gerenciar como parte da concepção de requisitos de segurança, gerando sistemas mais robustos sobre a ótica de segurança lógica e menos vulneráveis às falhas já existentes. O próprio artigo define claramente que fazendo uma análise quantitativa, percebe-se que em geral a natureza das falhas são normalmente as mesmas.
A criação de um repositório dedicado onde todas as falhas de produtos de software de uma determinada empresa fossem cadastradas, certamente geraria uma base de conteúdo e conhecimento relevante que auxiliaria certamente os desenvolvedores de produtos de software. Uma falha, ao ocorrer, seria cadastrada nesse repositório, que inclusive poderia ser aberto, possibilitando que demais empresas pudessem se atualizar com essas informações e se prevenir. Dados históricos comprovam que uma falha normalmente é explorada inúmeras vezes, em diversas instituições de mesmo gênero ou até da mesma empresa. Com certeza a falta de documentação é incentivo claro para que esse cenário se repita. Um repositório comum com certeza é fator primordial na taxonomia de falhas de segurança em software registrando e classificando as falhas de modo a que elas possa ser facilmente pesquisada, evitando assim sua propagação e aumentando a segurança dos softwares como um todo.
Uma falha de segurança, em geral conhecida como “bug de software”, normalmente aparece de maneira acidental, ou seja, sem objetivo específico do desenvolvedor do produto de software em gerar tal falha. Mas não se pode descartar a possibilidade de falhas maliciosas, onde os próprios desenvolvedores deixam lacunas de segurança em seus produtos de software visando futuramente uma exploração indevida. Uma falha, de maior ou menor impacto deve ser combatida e corrigida. Ignorar falhas que inicialmente não representam uma ameaça forte pode significar uma oportunidade a ser explorada.
A fase de verificação, testes e validação dos produtos de software, em geral eliminam grande parte das falhas não propositais. As falhas com características propositais, em geral possuem uma estrutura mais rebuscada, visto que essa falha não foi só simplesmente introduzida, foi também planejada, arquitetada e muitas vezes testada para ver se proporciona o resultado malicioso esperado.
A mensagem final é que uma boa segurança lógica de software só pode ser obtida com dois segmentos bem sedimentados:
- Uma preocupação com a criação de requisitos específicos de segurança: Os desenvolvedores dos produtos de software se preocuparem com esse aspecto.
- Um trabalho de aproximação forte com os recursos humanos envolvidos na concepção de produtos de software: Confiança nos programadores e desenvolvedores dos produtos de software, eliminando suas insatisfações, que podem acarretar na maliciosa ação de inserção de falhas propositais.
O autor enriquece bastante seu trabalho com os anexos, pois trazem diversos exemplos, que mostram as categorias catalogadas em seu artigo.Vale a pena explorar o artigo como um todo, pois uma série de exemplos de falhas de segurança selecionados.
quinta-feira, 22 de março de 2007
O que vem por aí?
No dia 28 de março de 2007 estará no ar minhas considerações sobre o artigo: "A Taxonomy of Computer Program Security Flaw". Esse artigo foi uma publicação ACM de 1994, com autoria de Carl E. Landwehr, Alan R. Bull, John P. McDermott e William S. Choi.
quinta-feira, 8 de março de 2007
Fraude no Sumitomo Bank alerta para fraudes em transações bancárias
O banco Sumitomo, importante instituição do mercado financeiro japonês, foi vítima de uma tentativa de fraude, felizmente sem sucesso, a partir do roubo de senhas de funcionários que trabalham diretamente com transações bancárias de importantes quantias. A investida só foi possível através do uso de uma ferramenta específica, que guarda as senhas utilizadas e digitadas por funcionários. Porém aplicativos de software e até hardware também são comuns e podem facilmente ser baixados da Internet ou adquiridos como produtos de software completos para uso pessoal. Tal acometimento, por si só, já é uma notícia relevante para a comunidade financeira, porém a grande evolução desse acontecimento não se deu no forte esquema implementado para inibir a ação e sim ao fato do Sumitomo Bank divulgar amplamente o ocorrido, algo inesperado, pois normalmente os bancos gostam de passar segurança para seus clientes e investidores, não evidenciando publicamente tais iniciativas, visando proteção direta da boa imagem do estabelecimento bancário.
Se por um lado o Sumitomo Bank resolveu se sensibilizar e divulgando e colocando em risco sua personalidade empresarial, de outro, essa ação sensibilizou e trouxe para toda a comunidade um alerta para melhoria em seus processos para evitar que outras ações semelhantes resultem em uma fraude eficaz. Algo a se repensar no futuro, caso outras instituições também divulguem seus incidente, embora seja bastante improvável que alguma instituição divulgue e confirme alguma fraude de sucesso, limitando-se ao máximo em apresentar os casos onde as ações foram neutralizadas.
Nem sempre se perde dinheiro sendo vítima de um furto ou desvio. As empresas de tecnologia, por exemplo, possuem uma série de informações sensíveis de projetos em andamento ou planos de expansão que são tão ou mais valiosos do que somas diretas que possam ser desviadas.
As medidas de segurança de informações em uma instituição financeira ou qualquer outra devem ser assuntos prioritários, porém não adianta nada criar um robusto processo para combater tais investidas, sem a participação consciente e também com treinamento e sensibilização de seus funcionários.
Ações de segurança de informação devem contemplar três naturezas distintas: processo, pessoas e ferramentas. Mesmo atacando essas três frentes, ainda sim, o problema não é eliminado, mas torna-se provavelmente minimizado.
(Texto publicado em 8 de março de 2007 e revisado no dia 22 de março de 2007)
Veja +:
Assinar:
Postagens (Atom)
