O baixo acoplamento entre tecnologias é algo necessário e comum nas tecnologias atuais, no entanto, nos negócios e processos empresariais essa abordagem vem sendo adotada, principalmente por empresas que se estendem em nível global. Diferentemente dos modelos de processos conhecidos e em uso na maioria das empresas que prevêem o forte acoplamento e dependência entre as partes.
Os processos em uso são suportados por tecnologias amarradas fisicamente e, por isso, acabam também sendo processos amarrados fisicamente. As novas companhias que utilizam tecnologias com baixo acoplamento tendem a agregar maior valor aos produtos e clientes mobilizando um alto número de parceiros de negócio especializados. Nesse cenário, os CIO’s são aliados dos executivos seniores no entendimento e implementação das mudanças resultantes da transição entre o baixo e o forte acoplamento.
O baixo acoplamento começa com uma abordagem modular do processo a ser modelado. Esse aspecto modular deve garantir baixo acoplamento em todos os níveis de aplicação da tecnologia e a garantia para se atingir isso é a capacidade de acoplar os módulos em níveis locais, regionais e globais. Uma abordagem modular para ser implementada com sucesso deve passar pela padronização de suas interfaces e nesse contexto a criação da linguagem descritiva de web services cumpre papel importante e viabiliza a divulgação das características dos serviços criados facilitando a sua utilização e combinação para gerar novos serviços agregados.
Um exemplo de empresa que atingiu baixo índice de acoplamento é a Li & Fung Co. Essa empresa é especializada em desenvolver produtos de escala global e para isso orquestra uma rede de 7.500 fornecedores ao redor do globo. A implementação desse processo de integração é possível por meio de padrões estabelecidos pela empresa e adotados pelos fornecedores. Os padrões mostram o que deve ser feito, mas cabe a cada fornecedor escolher o como fazer. Com o sucesso dessa implementação, a empresa tornou-se lucrativa e apresenta um cenário promissor para os investidores.
Nesse novo cenário de baixo acoplamento deve nascer uma relação mais forte e duradoura de confiança entre as corporações. CIO’s podem exercer naturalmente uma função de líder em ajudar as empresas na adoção e implementação das tecnologias que levam ao baixo acoplamento. Ainda participando do processo de transição, os CIO’s podem colaborar com os executivos que não são de TI a compreender os benefícios desse modelo de inovação.
quarta-feira, 5 de dezembro de 2007
segunda-feira, 3 de dezembro de 2007
Análise comparativa entre ferramentas CRM
Este blog apresenta uma análise comparativa entre as ferramentas de Customer Relationship Management (CRM) “Exact e-Synergy” e “SAP Business One”. Estes dois produtos foram escolhidos dentre diversos outros por apresentarem maior número de características avaliadas pela mídia especializada. Este blog é uma síntese da análise realizada pelo grupo “180 Systems” e publicada no relatório CRM Survey – CRM Vendor Analysis. A avaliação considerou características importantes de cada produto como também do fabricante do software. São considerados aspectos importantes como custos de instalação, recursos oferecidos e pontos fortes de cada produto.
Caracterização dos produtos:
Produto: Exact e-Synergy
Fabricante: Exact Software
Data do Release: 07/2006
Produto: SAP Business One
Fabricante: SAP AG
Data do Release: 12/2005
Custos de Licenciamento:
Exact e-Synergy
Custo médio por usuário: $1.500
Número médio de usuários: 20
Custo Médio: $30.000
Custo médio de implementação/Custo da Licença: 0,75
Custo Médio de Implementação: $22.500
Custo Total: $52.500
SAP AG
Custo médio por usuário: $2.380
Número médio de usuários: 10
Custo Médio: $23.800
Custo médio de implementação/Custo da Licença: 1,00
Custo Médio de Implementação: $23.800
Custo Total: $47.600
Aplicações Disponíveis:
Gerenciamento de Contatos: ambos
Automatização da força de venda: ambos
Automatização do marketing: ambos
Gerenciamento de serviços: ambos
Centro de Atendimento: sim (s-Synergy) e software de terceiro (SAP)
Gerenciamento do Conhecimento: ambos
Business Intelligence: ambos
Sistema Financeiro: ambos
Sistema de Distribuição: ambos
Sistema de Manufatura: ambos
Perfil da Receita:
e-Synergy
Clientes pelo mundo em todos os produtos: 34.600
Clientes pelo mundo nesse produto: 10.000
Receita 2005 com todos os produtos: $319,1 Milhões
Receita 2005 com este produto: $25,6 Milhões
Receita 2004 com todos os produtos: $301,9 Milhões
SAP AG
Clientes pelo mundo em todos os produtos: 600
Clientes pelo mundo nesse produto: 45
Receita 2005 com todos os produtos: $10,4 Bilhões
Receita 2004 com todos os produtos: $9,5 Bilhões
Mercado Alvo:
e-Synergy
Receita Média/Cliente: $10M - $100M
Número de Clientes/Cliente: 30 - 300
SAP AG
Receita Média/Cliente: $5M - $100M
Número de Clientes/Cliente: 10 - 300
Os gráficos abaixo mostram a distribuição das instalações dos produtos conforme a área de negócio dos clientes. O gráfico 1 é referente ao produto e-Synergy e o gráfico 2 ao produto SAP AG.
Tabela 1: Lista de funcionalidades por produto
Tabela 2: Lista de funcionalidades por produto
Tabela 3: Lista de funcionalidades por produto
Tabela 4: Lista de funcionalidades por produto
Caracterização dos produtos:
Produto: Exact e-Synergy
Fabricante: Exact Software
Data do Release: 07/2006
Produto: SAP Business One
Fabricante: SAP AG
Data do Release: 12/2005
Custos de Licenciamento:
Exact e-Synergy
Custo médio por usuário: $1.500
Número médio de usuários: 20
Custo Médio: $30.000
Custo médio de implementação/Custo da Licença: 0,75
Custo Médio de Implementação: $22.500
Custo Total: $52.500
SAP AG
Custo médio por usuário: $2.380
Número médio de usuários: 10
Custo Médio: $23.800
Custo médio de implementação/Custo da Licença: 1,00
Custo Médio de Implementação: $23.800
Custo Total: $47.600
Aplicações Disponíveis:
Gerenciamento de Contatos: ambos
Automatização da força de venda: ambos
Automatização do marketing: ambos
Gerenciamento de serviços: ambos
Centro de Atendimento: sim (s-Synergy) e software de terceiro (SAP)
Gerenciamento do Conhecimento: ambos
Business Intelligence: ambos
Sistema Financeiro: ambos
Sistema de Distribuição: ambos
Sistema de Manufatura: ambos
Perfil da Receita:
e-Synergy
Clientes pelo mundo em todos os produtos: 34.600
Clientes pelo mundo nesse produto: 10.000
Receita 2005 com todos os produtos: $319,1 Milhões
Receita 2005 com este produto: $25,6 Milhões
Receita 2004 com todos os produtos: $301,9 Milhões
SAP AG
Clientes pelo mundo em todos os produtos: 600
Clientes pelo mundo nesse produto: 45
Receita 2005 com todos os produtos: $10,4 Bilhões
Receita 2004 com todos os produtos: $9,5 Bilhões
Mercado Alvo:
e-Synergy
Receita Média/Cliente: $10M - $100M
Número de Clientes/Cliente: 30 - 300
SAP AG
Receita Média/Cliente: $5M - $100M
Número de Clientes/Cliente: 10 - 300
Os gráficos abaixo mostram a distribuição das instalações dos produtos conforme a área de negócio dos clientes. O gráfico 1 é referente ao produto e-Synergy e o gráfico 2 ao produto SAP AG.
Gráfico 1: Distribuição de instalações do e-Synergy por área de negócio
Gráfico 1: Distribuição de instalações do e-Synergy por área de negócio
Gráfico 1: Distribuição de instalações do e-Synergy por área de negócioCaracterísticas de Construção do Produto:
Banco de Dados utilizado: MS SQLServer (ambos)
Linguagem de desenvolvimento:
e-Synergy: Visual Basic, ASP, .Net
(SAP AG): .Net, Java, C#
Baseado na web: ambos
% de funcionalidades via browser: 100% (ambos)
Lista de Funcionalidades Oferecidas:
As tabelas 1, 2, 3 e 4 mostram a lista de funcionalidades oferecidas por cada produto.
Banco de Dados utilizado: MS SQLServer (ambos)
Linguagem de desenvolvimento:
e-Synergy: Visual Basic, ASP, .Net
(SAP AG): .Net, Java, C#
Baseado na web: ambos
% de funcionalidades via browser: 100% (ambos)
Lista de Funcionalidades Oferecidas:
As tabelas 1, 2, 3 e 4 mostram a lista de funcionalidades oferecidas por cada produto.
Tabela 1: Lista de funcionalidades por produto
Tabela 2: Lista de funcionalidades por produto
Tabela 3: Lista de funcionalidades por produto
Tabela 4: Lista de funcionalidades por produtoLista de Funcionalidades de Destaque:
e-Synergy:
Característica 1:
-Centrado em Recursos Humanos, e
-Acompanha CRM, Documentos, Workflow e Projetos.
Característica 2:
-Permite implementação com ferramenta de CRM de tempo real.
Característica 3:
-Contabilidade baseada em projetos para empresas baseadas em serviços, lançamentos temporais e cobranças.
SAP AG:
Característica 1:
-CRM completamente integrado com ERP.
Característica 2:
-Alertas comerciais e notificações.
Característica 3:
-Integração pré-configurada com o suíte mySAP Business.
e-Synergy:
Característica 1:
-Centrado em Recursos Humanos, e
-Acompanha CRM, Documentos, Workflow e Projetos.
Característica 2:
-Permite implementação com ferramenta de CRM de tempo real.
Característica 3:
-Contabilidade baseada em projetos para empresas baseadas em serviços, lançamentos temporais e cobranças.
SAP AG:
Característica 1:
-CRM completamente integrado com ERP.
Característica 2:
-Alertas comerciais e notificações.
Característica 3:
-Integração pré-configurada com o suíte mySAP Business.
Seven-Eleven Japan, um caso de sucesso
Em 1974 foi inaugurada a primeira loja da rede Seven-Elevn Japan (SEJ) na cidade de Tókio, Japão. A loja foi a precursora de uma grande rede de lojas de conveniências espalhada pelo Japão e pelo mundo que hoje ocupa posição de destaque no mercado japonês e global de franquias. A rede é composta por aproximadamente 25.000 lojas espalhadas em 18 países e desde sua fundação nunca experimentou queda nas vendas.
O grupo ITO-YOKADO foi quem negociou a vinda da rede para o Japão e, apesar do ceticismo da época quanto ao sucesso da rede, conseguiu viabilizar o negócio e gerar uma receita da ordem de 12 bilhões de dólares e empregar cerca de 5.000 pessoas.
O principal defensor e responsável pela negociação com a matriz norte-americana foi Toshifumi Suzuki, um jovem empresário obstinado pela idéia de atender às necessidades dos clientes e proporcionar a sua satisfação. Segundo ele, os empresários da época ignoravam dois pontos importantes: 1) a importância da conveniência para o cliente, e 2) a qualidade dos produtos e serviços. Essa visão de negócio conduziu o crescimento da SEJ baseado em alguns princípios-chaves que definem uma loja de conveniência de qualidade: Redução da oportunidade de perda; Controle efetivo dos itens e um gerenciamento de fornecimento de produto bem planejado; Comprometimento com a satisfação do cliente com desenvolvimento de produtos originais e serviço amigável.
As lojas apesar de terem tamanho bastante limitado, cerca de 110 m2, conseguem por meio de pesquisas das preferências dos clientes atender às necessidades diárias conforme o horário e o clima. As informações são alimentadas num sistema central que controla as entregas e as vendas. As preferências dos clientes são captadas pelos gerentes e transmitidas ao sistema central. Os gerentes das lojas também são responsáveis por solicitar a reposição dos itens e garantir que o cliente sempre encontrará aquilo que procura. Os itens são solicitados de maneira variada conforme a o tipo: comida fresca é solicitada três vezes ao dia; itens congelados três a sete vezes por semana, e guloseimas e itens secos são solicitados três vezes por semana.
A rede da SEJ instalou 10.000 lojas no Japão e acredita que ainda há espaço para expansão. Os pontos positivos da estratégia de liderança do mercado são: privilegiar marcas conceituadas; aumento da visita dos clientes às lojas; impulsionar a eficiência da distribuição; aprimorar a produtividade dos serviços de suporte às franquias, e aprimorar a eficácia das divulgações. Para inaugurar uma nova loja, 135 fatores são analisados baseados em dados relacionados com a localização e as vendas das outras 10.000 lojas da rede. Essa análise juntamente com uma forte ênfase em ROI, garante as lojas uma venda aproximada de 5.000 dólares diariamente, excedendo a expectativa da indústria em 35%.
A estratégia de criação das lojas de franquia foi aproveitar pequenas lojas já existentes de pequenos vendedores, isso fez com que 60% das lojas fossem modificadas ao invés de serem construídas do zero. Os franqueados é um negociante independente que dá à SEJ os direitos mais um compromisso de longo termo e se concentra na venda e no controle efetivo do estoque. Os direitos que o franqueado paga é 43% do lucro bruto que serve para pagar todos os encargos e despesas daquela loja na rede. SEJ também garante um lucro bruto mínimo para as lojas com baixa performance em vendas para suportar os proprietários. A política de contratação de fornecedores também foi a base para o crescimento da SEJ e, durante toda a sua existência, a rede nunca foi proprietária direta das operações de manufatura ou de logística.
Para suportar a rede da SEJ, foi criada uma rede infra-estrutura tecnológica capaz de processar as vendas de 9,5 milhões de clientes ao dia, 5 milhões de transações de pedidos e 35 milhões de transações de vendas. Tudo isso enviado ao sistema central de informações, onde as informações são analisadas cautelosamente. Para se manter a frente, a rede busca utilizar o estado da arte em tecnologia, o que inclui a criação em 1996 de um sistema de previsão do tempo para gerar subsídios aos franqueados no momento dos pedidos de mercadoria. A infra estrutura da rede foi renovada através de um projeto grandioso que envolveu 14 empresas de tecnologia e consumiu 500 milhões de dólares. O sistema possui 4 funcionalidades principais: Alta eficiência, manutenabilidade e confiabilidade no sistema de rede; O sistema de armazenamento, o qual encoraja todos os membros das lojas a participar na entrada dos pedidos; O compartilhamento do sistema com os parceiros comerciais, e Sofisticado sistema de análise que elimina a tomada de decisão intuitiva.
É com base na evolução tecnológica e em princípios baseados na satisfação do cliente que a rede SEJ enfrentará os desafios mercadológicos que virão. Espera-se com isso a sobrevivência da rede.
O problema com softwares corporativos
A tecnologia vem a duas décadas promovendo mudanças e inovações na vida humana e gerando a expectativa de atingir mercados maiores e níveis de lucratividade extraordinários. Nos dias de hoje encontramos sistemas responsáveis por prover cadeias de fornecimento completamente coordenadas e sincronizadas, linhas de produção e serviços, como se fosse uma grande orquestra. Tudo isso acontece de maneira invisível como se fosse mágica.
No entanto, não parece ser essa a condição vivenciada pela maioria das empresas. Empresas essas que possuem sistemas antigos e processados arcaicos mal documentados. Sistemas que utilizam até 50 bancos de dados e centenas de softwares para executar seus processos gerando alto custo de manutenção e adaptação. Os custos ou investimentos em TI subiram de 2.6% em 1970 para 22% em 1999. Atualmente, pode-se dizer que talvez 70% a 80% do orçamento geral é investimento em TI para manter rodando os sistemas existentes.
A complexidade dos softwares em uso vem aumentando com o tempo e o conjunto de instruções que o compõem são cada vez mais numerosas. É certo que não há limites para a flexibilidade do software e nem para o volume de instruções executadas. Sabe-se também que a ação executada por um software é fruto das pequenas partes que compõem o processo envolvido. Essa divisão é algo comparável à divisão de trabalho proposta por Adam Smith e ao gerenciamento científico de Frederick Taylor. Essa complexidade do software e o grande volume de instruções fazem com que o conhecimento do software seja disperso entre os membros da equipe e que o efeito de uma manutenção ou correção seja quase imprevisível em certos casos. Estima-se que 25% de acréscimo na complexidade das tarefas equivalem a 100% de acréscimo na complexidade da solução do software.
Essa mesma análise de complexidade está presente nos sistemas corporativos de planejamento de recursos criados em 1990. No entanto, o apelo de se substituir os diversos softwares existentes (legados) por um único e monolítico sistema, levou as empresas a comprar essa solução ignorando as dificuldades de implantação. Esse erro levou as empresas a não ter os softwares antigos substituídos e ainda passaram a ter que custear o ERP e resolver a sua integração com os demais sistemas.
Além da dificuldade técnica de instalação, observou-se um enorme custo de licenciamento e consultoria de implantação. Enquanto uma instalação média custa cerca de US$ 15 milhões, as grandes empresas acabaram o processo gastando centenas de milhões de dólares. De fato, 75% das instalações de ERP foram consideradas mal-sucedidas.
Como próxima fronteira tecnológica, surgiu a arquitetura orientada a serviço. Essa tecnologia prevê a criação de pequenos pacotes de serviços dedicados e centralizados na rede mundial, que utilizados de maneira apropriada pelos sistemas corporativos locais, poderão reduzir a complexidade dos softwares tornando as adaptações dos processos mais simplificadas e menos custosas. Por outro lado, existe um grande ceticismo por parte de vários pesquisadores que afirmam haver grande dificuldade de integração e questões não resolvidas como protocolos adequados e tempo de resposta satisfatório.
Comentários Gerais
O artigo apresenta uma visão realista das dificuldades de se implementar, instalar e manter sistemas ERP. Também apresenta a técnica que busca solucionar os problemas relacionados a esse tipo de sistemas, chamada de arquitetura orientada a serviços.
As evidências e estudos apresentados são contundentes e fala por si só, dando aos sistemas ERP a imagem de custosos e ineficazes.
No entanto, não parece ser essa a condição vivenciada pela maioria das empresas. Empresas essas que possuem sistemas antigos e processados arcaicos mal documentados. Sistemas que utilizam até 50 bancos de dados e centenas de softwares para executar seus processos gerando alto custo de manutenção e adaptação. Os custos ou investimentos em TI subiram de 2.6% em 1970 para 22% em 1999. Atualmente, pode-se dizer que talvez 70% a 80% do orçamento geral é investimento em TI para manter rodando os sistemas existentes.
A complexidade dos softwares em uso vem aumentando com o tempo e o conjunto de instruções que o compõem são cada vez mais numerosas. É certo que não há limites para a flexibilidade do software e nem para o volume de instruções executadas. Sabe-se também que a ação executada por um software é fruto das pequenas partes que compõem o processo envolvido. Essa divisão é algo comparável à divisão de trabalho proposta por Adam Smith e ao gerenciamento científico de Frederick Taylor. Essa complexidade do software e o grande volume de instruções fazem com que o conhecimento do software seja disperso entre os membros da equipe e que o efeito de uma manutenção ou correção seja quase imprevisível em certos casos. Estima-se que 25% de acréscimo na complexidade das tarefas equivalem a 100% de acréscimo na complexidade da solução do software.
Essa mesma análise de complexidade está presente nos sistemas corporativos de planejamento de recursos criados em 1990. No entanto, o apelo de se substituir os diversos softwares existentes (legados) por um único e monolítico sistema, levou as empresas a comprar essa solução ignorando as dificuldades de implantação. Esse erro levou as empresas a não ter os softwares antigos substituídos e ainda passaram a ter que custear o ERP e resolver a sua integração com os demais sistemas.
Além da dificuldade técnica de instalação, observou-se um enorme custo de licenciamento e consultoria de implantação. Enquanto uma instalação média custa cerca de US$ 15 milhões, as grandes empresas acabaram o processo gastando centenas de milhões de dólares. De fato, 75% das instalações de ERP foram consideradas mal-sucedidas.
Como próxima fronteira tecnológica, surgiu a arquitetura orientada a serviço. Essa tecnologia prevê a criação de pequenos pacotes de serviços dedicados e centralizados na rede mundial, que utilizados de maneira apropriada pelos sistemas corporativos locais, poderão reduzir a complexidade dos softwares tornando as adaptações dos processos mais simplificadas e menos custosas. Por outro lado, existe um grande ceticismo por parte de vários pesquisadores que afirmam haver grande dificuldade de integração e questões não resolvidas como protocolos adequados e tempo de resposta satisfatório.
Comentários Gerais
O artigo apresenta uma visão realista das dificuldades de se implementar, instalar e manter sistemas ERP. Também apresenta a técnica que busca solucionar os problemas relacionados a esse tipo de sistemas, chamada de arquitetura orientada a serviços.
As evidências e estudos apresentados são contundentes e fala por si só, dando aos sistemas ERP a imagem de custosos e ineficazes.
quinta-feira, 4 de outubro de 2007
A Business-Oriented Foundation for Service Orientation
No blog da semana veremos o artigo escrito por Ulrich Homann da Microsoft, que trata sobre a fundamentação orientada a negócios para orientação de serviços. O autor mostra que esta fundamentação é uma peça importante que falta no quebra-cabeça da implementação de serviços na web, um modo de derivar os requisitos de negócio e relacioná-los com as construções orientadas a serviços de um modo formalizado, repetitível e inovador.
Em geral não há uma relação bem definida entre os métodos usados para descrever ou modelar requisitos de negócios e sua eventual implementação técnica. Nesse contexto o autor propõe que um modelo adequado deve, em adição à representação de atividades, suportar tanto a interdependência dos negócios como a autonomia dos serviços que os suportam. Para isso, propõe-se a concepção de negócio como sendo um conjunto de capacidades que irão descrever o que o negócio faz e o nível de performance esperado.
As técnicas existentes de aprimoramento de negócios focadas em melhoria de processos têm obtido progresso em atender as necessidades atuais dos desafios de negócios. Entretanto, focando primeiramente na visão de “Como” o trabalho é feito gera premissas sobr o “O que” é realizado. As soluções então são limitadas a aprimorar os mecanismos e não desafiando as premissas fundamentais do trabalho. Esse é o modo que a maioria das pessoas utilizam na tentativa de resolver problemas atualmente. Para aprimorar isso, serão necessárias premissas e perguntas diferentes.
Um modelo de capacidades consegue extrair da análise dos problemas aquilo que é mais estável e consequentemente oferecer soluções duradouras e de maior longividade, pois estão mapeando aquilo que o negócio faz e não como ele é feito atualmente. Essa perspectiva oferece um maior ROI para as empresas, pois soluções duradouras eliminam novos investimentos em buscar novas soluções.
A proposta é modelar os negócios como uma rede estruturada de capacidades, diferente das redes fisicamente integradas da atualidade. Isso endereça a rica interconexão entre os diferentes aspectos que podem ser intercalados desde o começo ao invés de serem adicionados como algo custoso após tudo feito.
A importância da proposta está em localizar os elementos estáveis do negócio para modelar a sua arquitetura ao redor e prover uma camada crítica que esteja alinhada com a orientação a serviço. Desta forma, a orientação por serviço fornece a estrutura compartimentalizada, mas conectada, para implementar as capacidades de modo que a TI alcança os requisitos atuais do negócio e provê negócios verdadeiramente ágeis.
Fonte: http://msdn2.microsoft.com/en-us/architecture/aa479368.aspx
Em geral não há uma relação bem definida entre os métodos usados para descrever ou modelar requisitos de negócios e sua eventual implementação técnica. Nesse contexto o autor propõe que um modelo adequado deve, em adição à representação de atividades, suportar tanto a interdependência dos negócios como a autonomia dos serviços que os suportam. Para isso, propõe-se a concepção de negócio como sendo um conjunto de capacidades que irão descrever o que o negócio faz e o nível de performance esperado.
As técnicas existentes de aprimoramento de negócios focadas em melhoria de processos têm obtido progresso em atender as necessidades atuais dos desafios de negócios. Entretanto, focando primeiramente na visão de “Como” o trabalho é feito gera premissas sobr o “O que” é realizado. As soluções então são limitadas a aprimorar os mecanismos e não desafiando as premissas fundamentais do trabalho. Esse é o modo que a maioria das pessoas utilizam na tentativa de resolver problemas atualmente. Para aprimorar isso, serão necessárias premissas e perguntas diferentes.
Um modelo de capacidades consegue extrair da análise dos problemas aquilo que é mais estável e consequentemente oferecer soluções duradouras e de maior longividade, pois estão mapeando aquilo que o negócio faz e não como ele é feito atualmente. Essa perspectiva oferece um maior ROI para as empresas, pois soluções duradouras eliminam novos investimentos em buscar novas soluções.
A proposta é modelar os negócios como uma rede estruturada de capacidades, diferente das redes fisicamente integradas da atualidade. Isso endereça a rica interconexão entre os diferentes aspectos que podem ser intercalados desde o começo ao invés de serem adicionados como algo custoso após tudo feito.
A importância da proposta está em localizar os elementos estáveis do negócio para modelar a sua arquitetura ao redor e prover uma camada crítica que esteja alinhada com a orientação a serviço. Desta forma, a orientação por serviço fornece a estrutura compartimentalizada, mas conectada, para implementar as capacidades de modo que a TI alcança os requisitos atuais do negócio e provê negócios verdadeiramente ágeis.
Fonte: http://msdn2.microsoft.com/en-us/architecture/aa479368.aspx
segunda-feira, 9 de julho de 2007
Como confiar?
Este blog apresenta um breve resumo e meus comentários sobre o discurso de Ken Thompson durante a entrega do prêmio Turing Award de 1983 (Turing_Award) recebido por ele juntamente com Dennis Ritchie pelo desenvolvimento da teoria dos sistemas operacionais genéricos e pela implementação do sistema operacional UNIX.
Ken Thompson abre o seu discurso saudando a todos os inúmeros colaboradores do sistema operacional UNIX e diz que ele sendo um programador, irá utilizar o programa mais curto que ele já fez para embasar a sua mensagem.
O programa é apresentado em três estágios e tem o objetivo de introduzir um Trojan em um compilador. No estágio 1 ele mostra um programa inofensivo capaz de gerar uma cópia do seu próprio código fonte quando for executado. No estágio 2, Thompson apresenta o compilador C sofrendo uma modificação para reconhecer o caractere barra vertical como parte da sua sintaxe. No estágio 3, é apresentado um trecho hipotético do compilador C capaz de introduzir código malicioso no programa que está sendo compilado e adverte que o código binário gerado dificilmente será descoberto por alguém. Ainda acrescenta que o código malicioso tem a capacidade de se reproduzir, gerando assim programas compilados com código malicioso sem que o código fonte seja alterado.
Ken Thompson conclui seu discurso dizendo categoricamente que não se deve confiar em programas que você não tenha escrito totalmente e caracteriza os técnicos que promovem esse tipo de fraude como vândalos, perigosos e merecedores de permanecerem presos por muitos anos. Chega a comparar a atividade de forjar programas com a de dirigir embriagado e lança um alerta para impressa e a comunidade em geral de que esse tipo de atividade deixe de ser enaltecida e seja encarada como prejudicial e criminosa.
Comentários
As colocações de Ken Thompson feitas em 1983 são extremamente atuais em 2007. Pode-se dizer que o apelo dele ainda não foi ouvido mesmo depois de tantas vítimas. Existe uma forte tendência na comunidade em geral em confiar prontamente naquilo que é dito a respeito dos benefícios de um programa e rapidamente ser adotado em ambientes empresariais. Poucas são as vezes em que se aplica uma política rígida de homologação e verificação das funcionalidades desse programa, quem dirá uma revisão minuciosa do seu código-fonte. Uma prova da atualidade do discurso de Ken Thompson está no pessoal do fórum voto-seguro (http://www.mail-archive.com/voto-eletronico@pipeline.iron.com.br/index.html#01214) que acusa o governo brasileiro de ser leviano na avaliação e verificação do sistema computacional de votação eletrônica. A opinião dos participantes do fórum indica que foi feita uma inspeção parcial do código e num tempo incompatível com o tamanho do sistema.
Foi registrado no começo de 2007, o primeiro período consecutivo de 12 meses sem fraude em sites brasileiros de internet banking. Isso demonstra uma forte tendência e uma melhora considerável nos sistemas de controle, no entanto, o número de ataques e de variações de ameaças continua crescendo o que demonstra que os sujeitos envolvidos em criar tais ameaças não desistiram e continuam buscando novos meios de quebrar os sistemas de segurança.
Diante de tamanha insegurança, devemos optar pela utilização de programas auditáveis, ou seja, programas que sigam implementem padrões abertos, que utilizem algoritmos públicos e reconhecidos pela comunidade em geral ou ainda programas de código aberto. Fazendo assim, estaremos criando programas auditáveis e dignos de maior confiança por quem os utilizam.
Análise de Risco de Segurança de um Sistema ATM
Este blog mostra a análise de risco de segurança para um sistema ATM genérico proposto por Russell C. Bjork como material de apoio no curso de orientação a objetos do Gordon College. O material está disponível em http://www.mathcs.gordon.edu/local/courses/cs211/ATMExample/. A análise tem início com a determinação das vulnerabilidades, ameaças e fontes de ameaça do sistema. Em seguida foi realizada a avaliação do nível de risco das ameaças e por fim foram elaborados os casos de mau uso e os casos de controle para conter as ameaças.
A seguir tem-se a lista de ameaças e o nível de risco associado:
1 - Causar diferenças no montante existente nos caixas durante a rotina de inicialização (Risco: Baixo)
2 - Obter as informações de acesso às contas do cliente e manipulá-las (Risco: Médio)
3 - Introdução de leitores dissimulados no ATM (Risco: Alto)
4 - O envelope ser substituído por outro com montante a menos. O depósito é confirmado conforme o envelope. (Risco: Baixo)
Os controles de segurança a serem implementados são listados a seguir. A lista está indexada pelo número da ameaça:
1.1 - Solicitação de PIN ou mesmo utilização de cartões de identificação com chip de segurança.
2.1 - Inclusão de criptografia na comunicação com o banco e nas operações de acesso aos dados do cartão e teclado durante as transações.
3.1 - Adoção de cartões com chip de segurança que só responde mediante senha do banco emissor.
4.1 - Impressão no envelope dos dados da transação.
A figura abaixo mostra o diagrama de casos de uso do sistema alterado para refletir os casos de mau-uso identificados:
A seguir tem-se a lista de ameaças e o nível de risco associado:
1 - Causar diferenças no montante existente nos caixas durante a rotina de inicialização (Risco: Baixo)
2 - Obter as informações de acesso às contas do cliente e manipulá-las (Risco: Médio)
3 - Introdução de leitores dissimulados no ATM (Risco: Alto)
4 - O envelope ser substituído por outro com montante a menos. O depósito é confirmado conforme o envelope. (Risco: Baixo)
Os controles de segurança a serem implementados são listados a seguir. A lista está indexada pelo número da ameaça:
1.1 - Solicitação de PIN ou mesmo utilização de cartões de identificação com chip de segurança.
2.1 - Inclusão de criptografia na comunicação com o banco e nas operações de acesso aos dados do cartão e teclado durante as transações.
3.1 - Adoção de cartões com chip de segurança que só responde mediante senha do banco emissor.
4.1 - Impressão no envelope dos dados da transação.
A figura abaixo mostra o diagrama de casos de uso do sistema alterado para refletir os casos de mau-uso identificados:
A figura abaixo mostra o diagrama de casos de uso do sistema alterado para refletir os casos de controle necessários para mitigar os riscos identificados:
O Algoritmo RSA
Em 1977 os criptógrafos Rivest, Shamir e Adleman do Massassuchets Institute of Technology (MIT) definiram a primeira técnica de criptografia assimétrica divulgada na literatura aberta, o algoritmo RSA. Este é o principal algoritmo assimétrico em uso (ANSI X9.31) na atualidade. Para operar, cada pessoa que for trocar correspondência deve fabricar uma chave pública e uma chave privada. A chave pública será utilizada para cifrar as mensagens para um certo destinatário enquanto a chave privada será utilizada pelo destinatário para decifrar a mensagem recebida. A relação entre as chaves pública e privada é a proteção do destinatário. Um indivíduo prepara suas chaves do seguinte modo:
Escolhe adequadamente dois números primos p e q
Calcula n = p*q
Escolhe aleatoriamente um número x e calcula y tal que:
mdc(x, fi(n))=1, onde fi(n)=(p-1)(q-1), tal que x esteja entre 1 e fi(n)
Escolhe adequadamente dois números primos p e q
Calcula n = p*q
Escolhe aleatoriamente um número x e calcula y tal que:
mdc(x, fi(n))=1, onde fi(n)=(p-1)(q-1), tal que x esteja entre 1 e fi(n)
y=(x mod fi(n))^(-1)
No fim do cálculo é obtida a chave pública (n, x) e a chave privada (n, y). A chave pública é divulgada abertamente para que qualquer interessado possa trocar mensagens com o criador das chaves.
A partir de uma mensagem de entrada M, gera-se sua representação numérica m substituindo os caracteres por números. As chaves criptográficas são então utilizadas para cifrar e decifrar a mensagem m conforme as seguintes fórmulas:
Cifrar: c=m^x mod n
Decifrar: m=c^y mod n
A segurança do RSA está na dificuldade de obter p e q a partir da fatoração de n, esse problema torna-se complexo quando n é muito grande. O teorema dos números primos afirma que existem 4,3 X 1097 números primos de 100 dígitos. É maior que o total de partículas do universo.
Na prática, devido ao tempo de processamento do RSA, utiliza-se uma combinação de criptografia simétrica com assimétrica. Desta forma, uma chave simétrica de sessão aleatória é gerada para cifrar o texto utilizando-se um algoritmo simétrico, por exemplo: AES. Com a chave pública disponível a chave simétrica é cifrada e em seguida enviada ao destinatário juntamente com a mensagem cifrada. Para decifrar, o destinatário decifra a chave privada de sessão com a sua chave privada para depois decifrar a mensagem com a chave simétrica obtida.
quarta-feira, 2 de maio de 2007
SHA-1: Algoritmo de resumo seguro
No blog desta semana, apresentamos o algoritmo de resumo SHA-1 (Secure Hash Algoritm), uma lista de possíveis aplicações e o tipo de ataque ao qual ele está sujeito. O algoritmo foi adotado como padrão dentro do governo norte-americano em 1995 através da FIPS PUB 180-1 (http://www.itl.nist.gov/fipspubs/fip180-1.htm).
Esse algoritmo visa a geração de uma representação numérica, a qual chamamos de hash, de uma dada mensagem de forma segura. É seguro por dois motivos: a. computacionalmente é improvável encontrar uma mensagem a partir de um hash conhecido, b. é improvável encontrar duas mensagens que produzam o mesmo hash.
A utilidade para o hash de uma mensagem está principalmente no teste de integridade da mesma, após uma transmissão ou armazenamento. Os algoritmos de assinatura digital utilizam o hash para otimizar o processo de assinatura. Nesse caso, o hash é assinado e não a mensagem toda, que provavelmente tem um tamanho bem maior. Caso a mensagem seja alterada durante a transmissão ela irá produzir um hash diferente do original e a existência do erro será percebida.
Funcionamento do algoritmo SHA-1
O algoritmo é composto de um conjunto de operações lógicas com a mensagem de entrada resultando num número de 160 bits escrito na base hexadecimal e a mensagem de entrada pode ser de até 2^64 bits.
Etapa 1:
A mensagem de entrada é preenchida com zeros para tornar o seu tamanho mútliplo de 512. Nesse processo, a mensagem é quebrada em blocos de 512 bits. O último bloco, sendo menor que 512, recebe um bit 1 e depois uma quantidade variável de bits 0 até completar 448 bits. Nos últimos 64 bits, será armazenado o tamanho original da mensagem. Na figura abaixo, tem-se a representação de um bloco após o processo de padding.
61626364 65800000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000028
Onde:
9 : Mensagem original
9 : é obtido com a inserção do 1 no fim da cadeia de entrada
9 : número de zeros para completar 448 bits
9 : palavras de 32 bits com o tamanho original da mensagem
A mensagem original será então representada no algoritmo SHA-1 por uma quantidade n de blocos de 512 bits chamados de M1, M2,...,Mn.
Etapa 2:
A mensagem é organizada em buffers de 512 bits organizados em 16 palavras Mxi, onde: x é cada bloco de 512 bits e i é cada uma das 16 palavras do bloco.
Etapa 3:
Nessa etapa é calculado o hash propriamente dito, onde cada bloco é processado t=80 vezes.
O algoritmo utiliza o seguinte conjunto de variáveis em memória:
Constante K para cada uma das 80 vezes:
K = 5A827999 ( 0 <= t <= 19)
Kt= 6ED9EBA1 (20 <= t <= 39)
Kt= 8F1BBCDC (40 <= t <= 59)
Kt= CA62C1D6 (60 <= t <= 79).
Buffer de saída, inicializado antes de processar o primeiro bloco com os valores abaixo e sobreposto a cada novo bloco com os valores de hash calculados:
H0= 67452301
H1= EFCDAB89
H2= 98BADCFE
H3= 10325476
H4= C3D2E1F0
Buffer auxiliar inicializado a cada bloco:
A = H0
B = H1
C = H2
D = H3
E = H4
Buffer temporário: TEMP
Buffer para cada iteração: Wt, 0 <= t <= 79
O algoritmo utiliza o seguinte conjunto de expressões lógicas sobre as variáveis auxiliares, conforme a iteração t processada:
ft(B,C,D) = (B AND C) OR ((NOT B) AND D) para 0 <= t <= 19
ft(B,C,D) = B XOR C XOR D para 20 <= t <= 39
ft(B,C,D) = (B AND C) OR (B AND D) OR (C AND D) para 40 <= t <= 59
ft(B,C,D) = B XOR C XOR D para 60 <= t <= 79.
O processamento começa com a preparação dos 80 buffers que serão utilizadas a cada iteração. A preparação segue a seguinte regra:
Wt = Mxt para 0 <= t <= 15
Wt = Rotacionado 1 para esquerda do resultado da expressão: W(t-3) XOR W(t-8) XOR W(t-14) XOR W(t-16)
Inicializa os buffers auxiliares:
A = H0; B = H1; C = H2; D = H3; E = H4
Repete 80 vezes:
TEMP = Rotaciona 5 para esquerda(A) + ft(B,C,D) + E + Wt + Kt;
E = D;
D = C;
C = Rotaciona 30 para esquerda(B);
B = A;
A = TEMP;
O hash intermediário é calculado da seguinte maneira:
H0 = H0 + A;
H1 = H1 + B;
H2 = H2 + C;
H3 = H3 + D;
Após processar os N blocos da mensagem, o hash final é: H0H1H2H3
Aplicações para o algoritmo de hash
Os algoritmos de hash são bastante úteis pela sua característica de gerar um identificador único tendo um dado conjunto de caracteres como entrada. Abaixo tem-se uma lista das possíveis aplicações desse algoritmo:
-Validação de senha de autenticação
-Criação de assinatura digital para documentos
-Verificação de integridade de pacotes em protocolos de comunicação
-Autenticação de mensagens através dos hashes com chave criptográfica
Prováveis ataques ao algoritmo SHA-1
Esse algoritmo visa a geração de uma representação numérica, a qual chamamos de hash, de uma dada mensagem de forma segura. É seguro por dois motivos: a. computacionalmente é improvável encontrar uma mensagem a partir de um hash conhecido, b. é improvável encontrar duas mensagens que produzam o mesmo hash.
A utilidade para o hash de uma mensagem está principalmente no teste de integridade da mesma, após uma transmissão ou armazenamento. Os algoritmos de assinatura digital utilizam o hash para otimizar o processo de assinatura. Nesse caso, o hash é assinado e não a mensagem toda, que provavelmente tem um tamanho bem maior. Caso a mensagem seja alterada durante a transmissão ela irá produzir um hash diferente do original e a existência do erro será percebida.
Funcionamento do algoritmo SHA-1
O algoritmo é composto de um conjunto de operações lógicas com a mensagem de entrada resultando num número de 160 bits escrito na base hexadecimal e a mensagem de entrada pode ser de até 2^64 bits.
Etapa 1:
A mensagem de entrada é preenchida com zeros para tornar o seu tamanho mútliplo de 512. Nesse processo, a mensagem é quebrada em blocos de 512 bits. O último bloco, sendo menor que 512, recebe um bit 1 e depois uma quantidade variável de bits 0 até completar 448 bits. Nos últimos 64 bits, será armazenado o tamanho original da mensagem. Na figura abaixo, tem-se a representação de um bloco após o processo de padding.
61626364 65800000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000028
Onde:
9 : Mensagem original
9 : é obtido com a inserção do 1 no fim da cadeia de entrada
9 : número de zeros para completar 448 bits
9 : palavras de 32 bits com o tamanho original da mensagem
A mensagem original será então representada no algoritmo SHA-1 por uma quantidade n de blocos de 512 bits chamados de M1, M2,...,Mn.
Etapa 2:
A mensagem é organizada em buffers de 512 bits organizados em 16 palavras Mxi, onde: x é cada bloco de 512 bits e i é cada uma das 16 palavras do bloco.
Etapa 3:
Nessa etapa é calculado o hash propriamente dito, onde cada bloco é processado t=80 vezes.
O algoritmo utiliza o seguinte conjunto de variáveis em memória:
Constante K para cada uma das 80 vezes:
K = 5A827999 ( 0 <= t <= 19)
Kt= 6ED9EBA1 (20 <= t <= 39)
Kt= 8F1BBCDC (40 <= t <= 59)
Kt= CA62C1D6 (60 <= t <= 79).
Buffer de saída, inicializado antes de processar o primeiro bloco com os valores abaixo e sobreposto a cada novo bloco com os valores de hash calculados:
H0= 67452301
H1= EFCDAB89
H2= 98BADCFE
H3= 10325476
H4= C3D2E1F0
Buffer auxiliar inicializado a cada bloco:
A = H0
B = H1
C = H2
D = H3
E = H4
Buffer temporário: TEMP
Buffer para cada iteração: Wt, 0 <= t <= 79
O algoritmo utiliza o seguinte conjunto de expressões lógicas sobre as variáveis auxiliares, conforme a iteração t processada:
ft(B,C,D) = (B AND C) OR ((NOT B) AND D) para 0 <= t <= 19
ft(B,C,D) = B XOR C XOR D para 20 <= t <= 39
ft(B,C,D) = (B AND C) OR (B AND D) OR (C AND D) para 40 <= t <= 59
ft(B,C,D) = B XOR C XOR D para 60 <= t <= 79.
O processamento começa com a preparação dos 80 buffers que serão utilizadas a cada iteração. A preparação segue a seguinte regra:
Wt = Mxt para 0 <= t <= 15
Wt = Rotacionado 1 para esquerda do resultado da expressão: W(t-3) XOR W(t-8) XOR W(t-14) XOR W(t-16)
Inicializa os buffers auxiliares:
A = H0; B = H1; C = H2; D = H3; E = H4
Repete 80 vezes:
TEMP = Rotaciona 5 para esquerda(A) + ft(B,C,D) + E + Wt + Kt;
E = D;
D = C;
C = Rotaciona 30 para esquerda(B);
B = A;
A = TEMP;
O hash intermediário é calculado da seguinte maneira:
H0 = H0 + A;
H1 = H1 + B;
H2 = H2 + C;
H3 = H3 + D;
Após processar os N blocos da mensagem, o hash final é: H0H1H2H3
Aplicações para o algoritmo de hash
Os algoritmos de hash são bastante úteis pela sua característica de gerar um identificador único tendo um dado conjunto de caracteres como entrada. Abaixo tem-se uma lista das possíveis aplicações desse algoritmo:
-Validação de senha de autenticação
-Criação de assinatura digital para documentos
-Verificação de integridade de pacotes em protocolos de comunicação
-Autenticação de mensagens através dos hashes com chave criptográfica
Prováveis ataques ao algoritmo SHA-1
Alguns dos ataques aos quais o algoritmo SHA-1 está sujeito são:
- força bruta
- colisão
No entanto, nenhum desses dois ataques eram considerados factíveis até pouco tempo. Em 2005, um grupo de criptoanalista chineses conseguiram quebrar o SHA-1 utilizando o método da colisão, que utiliza técnicas matemáticas para quebrar o algoritmo.
Isso ainda não oferece alto risco para as aplicações que utilizam SHA-1, mas deve-se deixar de usá-lo e optar por algoritmos mais robustos como o SHA-256 ou SHA-512.
quinta-feira, 5 de abril de 2007
A importância do fator humano nos sistemas de segurança de TI
Mesmo possuindo milhões de possibilidades de cifragem para cada mensagem, os alemães perderam a guerra devido à quebra da criptografia do Enigma por parte dos aliados, mais precisamente os ingleses com a ajuda dos poloneses. Esse fato dificilmente aconteceria se não fosse o fator humano, ou seja, os alemães confiaram demais no sistema a ponto de acontecer brechas na segurança durante o do Enigma a cada mensagem cifrada.
Os alemães conseguiram um domínio rápido sobre os demais países e o avanço desse domínio era consistente. Utilizando a máquina Enigma para cifrar as mensagens, eles sabiam que os inimigos não poderiam facilmente ler essas mensagens. A rotina de segurança deles incluía troca de chaves a cada dia e novas chaves eram geradas e enviadas para as unidades mensalmente por um portador.
A quebra do código era mesmo algo quase que impraticável, mas explorando os descuidos e a preguiça dos soldados alemães, os aliados conseguiram identificar padrões que permitiu a quebra do código. Esse comportamento dos soldados alemães deu-se devido ao excesso de confiança no sistema.
Como o Enigma foi quebrado
O principal responsável pela quebra foi o matemático polonês Marian Rejewski. O trabalho contou com uma máquina Enigma adquirida na época em era vendida comercialmente, com as informações de um traidor alemão que forneceu um guia de setup do Enigma e um conjunto de mensagens em texto cifrado e seu correspondente em texto claro, bem como o conjunto de chaves utilizadas para cifrá-las.
Com essas informações, foi possível identificar as conexões elétricas da máquina Enigma dos alemães. Essas conexões eram mantidas em segredo, pois são a base da geração da cifragem. No entanto, para decifrar as mensagens atuais, os aliados precisariam das chaves utilizadas diariamente e foi nesse aspecto que os alemães criaram as brechas no sistema.
Alguns exemplos de brechas criadas:
- os operadores estavam autorizados a utilizar uma chave randômica e escolhiam com freqüência chaves pequenas e fáceis de serem decifradas, como AAA, ou as letras de uma diagonal ou nome de pessoas ligadas a eles.
- um operador constantemente reportava a mensagem ‘nada para reportar’ usando a chave do dia.
- outros operadores esqueciam de trocar a chave e enviavam a mesma mensagem novamente.
- os alemães incluíam as expressões ‘De’ e ‘Para’ em suas mensagens para identificar as unidades militares.
- os livros de chaves não eram corretamente destruídos pela tripulação em caso de serem capturados.
- os líderes não treinavam adequadamente os operadores.
O conjunto de brechas geradas foi dando aos aliados padrões de comparação até que as chaves eram obtidas e as mensagens decifradas. Isso culminou no desenvolvimento de um sistema de quebra de código do Enigma capaz de operar mesmo se os rotores da máquina fossem modificados pelos alemães.
A história da quebra do código da máquina Enigma traz uma mensagem bastante clara para os profissionais de segurança da atualidade: não sejam surpreendidos pelo elo mais fraco, o ser humano. Após as rotinas de segurança serem definidas, garanta que os operadores do sistema, aqueles que têm acesso aos dados, sejam adequadamente treinados nas rotinas de proteção do sistema, tais como: utilização de senha forte, destruição de documentos confidenciais, antivírus atualizados, rotinas de backup, entre outras.
Fonte: The Weakest Link: The Human Factor - Lessons Learned from the German WWII Enigma Cryptosystem - SANS Institute 2001.
Os alemães conseguiram um domínio rápido sobre os demais países e o avanço desse domínio era consistente. Utilizando a máquina Enigma para cifrar as mensagens, eles sabiam que os inimigos não poderiam facilmente ler essas mensagens. A rotina de segurança deles incluía troca de chaves a cada dia e novas chaves eram geradas e enviadas para as unidades mensalmente por um portador.
A quebra do código era mesmo algo quase que impraticável, mas explorando os descuidos e a preguiça dos soldados alemães, os aliados conseguiram identificar padrões que permitiu a quebra do código. Esse comportamento dos soldados alemães deu-se devido ao excesso de confiança no sistema.
Como o Enigma foi quebrado
O principal responsável pela quebra foi o matemático polonês Marian Rejewski. O trabalho contou com uma máquina Enigma adquirida na época em era vendida comercialmente, com as informações de um traidor alemão que forneceu um guia de setup do Enigma e um conjunto de mensagens em texto cifrado e seu correspondente em texto claro, bem como o conjunto de chaves utilizadas para cifrá-las.
Com essas informações, foi possível identificar as conexões elétricas da máquina Enigma dos alemães. Essas conexões eram mantidas em segredo, pois são a base da geração da cifragem. No entanto, para decifrar as mensagens atuais, os aliados precisariam das chaves utilizadas diariamente e foi nesse aspecto que os alemães criaram as brechas no sistema.
Alguns exemplos de brechas criadas:
- os operadores estavam autorizados a utilizar uma chave randômica e escolhiam com freqüência chaves pequenas e fáceis de serem decifradas, como AAA, ou as letras de uma diagonal ou nome de pessoas ligadas a eles.
- um operador constantemente reportava a mensagem ‘nada para reportar’ usando a chave do dia.
- outros operadores esqueciam de trocar a chave e enviavam a mesma mensagem novamente.
- os alemães incluíam as expressões ‘De’ e ‘Para’ em suas mensagens para identificar as unidades militares.
- os livros de chaves não eram corretamente destruídos pela tripulação em caso de serem capturados.
- os líderes não treinavam adequadamente os operadores.
O conjunto de brechas geradas foi dando aos aliados padrões de comparação até que as chaves eram obtidas e as mensagens decifradas. Isso culminou no desenvolvimento de um sistema de quebra de código do Enigma capaz de operar mesmo se os rotores da máquina fossem modificados pelos alemães.
A história da quebra do código da máquina Enigma traz uma mensagem bastante clara para os profissionais de segurança da atualidade: não sejam surpreendidos pelo elo mais fraco, o ser humano. Após as rotinas de segurança serem definidas, garanta que os operadores do sistema, aqueles que têm acesso aos dados, sejam adequadamente treinados nas rotinas de proteção do sistema, tais como: utilização de senha forte, destruição de documentos confidenciais, antivírus atualizados, rotinas de backup, entre outras.
Fonte: The Weakest Link: The Human Factor - Lessons Learned from the German WWII Enigma Cryptosystem - SANS Institute 2001.
quinta-feira, 29 de março de 2007
Taxonomia das brechas de segurança em sistemas computacionais
Taxonomia das brechas de segurança em sistemas de computador
O artigo apresenta uma sistemática que organiza as informações sobre brechas de segurança nos sistemas computacionais de modo que elas possam ser utilizadas por projetistas, analistas, programadores e consultores para entender novas brechas e também identificar pontos mais susceptíveis do sistema. A sistemática é bastante útil para aqueles profissionais encarregados de repelir os ataques e corrigir as falhas.
No entanto, esse tipo de estudo oferece o risco de ser utilizado pelas pessoas mal intencionadas, por isso, foram documentadas as brechas já publicadas anteriormente e mais antigas.
Geralmente uma brecha de segurança é um bug que pela definição da IEEE inclui os erros e faltas. O estudo considera tanto as brechas acidentais quanto aquelas inseridas de maneira proposital.
Algumas das iniciativas passadas para identificar falhas nos sistemas computacionais:
- Flaw Hypothesis Methodology (1970): estuda a documentação e a construção do sistema para gerar hipóteses sobre onde as falhas poderão estar. Em seguida, utiliza a documentação do sistema e os testes para confirmar a presença das falhas. Por fim, generaliza as brechas confirmadas para guiar os esforços futuros.
- RISOS: categorizou as brechas em sistemas operacionais em sete categorias.
- USC/ISI: categorizou os erros de seis sistemas operacionais em categorias que após o término do trabalho foram agrupadas em quatro categorias globais.
O estudo buscou responder a três perguntas básicas sobre as brechas de segurança:
- Como ela entrou no sistema?
- Quando ela entrou no sistema?
- Onde no sistema ela se manifestar?
Essas três perguntas serviram para organizar a taxonomia em: gênesis (como), tempo de introdução (quando) e localização (onde).
Os casos avaliados pelo estudo foram selecionados segundo o critério a seguir:
- o caso deve apresentar um tipo particular de vulnerabilidade claro o suficiente que o cenário ou programa que ameaça a segurança do sistema possa ser entendido pelo classificador, e
- o dano potencial resultante da vulnerabilidade descrita deve ser mais que superficial.
As brechas quanto ao gênesis
Essas brechas de segurança são criadas acidentalmente ou intencionalmente. No entanto, os esforços para evitar as brechas acidentais são diferentes daqueles para evitar as intencionais. Geralmente as acidentais são evitadas com maior dedicação aos testes e revisão do código. Já as intencionais são evitadas contratando-se programadores mais confiáveis, aplicando-se testes de penetração e investindo em pacotes de detecção de vírus.
Alguns exemplos definidos na taxonomia por gênesis são:
Intencional – maliciosa – bomba lógica
Intencional – não maliciosa – covert channel – temporizado
Inadvertida – erro de validação
Inadvertida – identificação / autenticação inadequada
O estudo alerta para o fato de que algumas brechas são introduzidas nas tentativas de consertar outras brechas.
As brechas quanto ao tempo de introdução
Considerando diversos processos de desenvolvimento e diferentes ciclos de vida de sistemas desenvolvidos, identificou-se três diferentes fases em que as brechas de segurança possam ser introduzidas nos sistemas:
- na fase de desenvolvimento, que inclui até a liberação da primeira versão.
- na fase de manutenção, que contempla a fase pós liberação da primeira versão.
- na fase operacional, que inclui as atividades de correção do software ao longo da sua utilização.
Exemplos da taxonomia por tempo de introdução:
Durante o desenvolvimento – elaboração do código fonte
Durante a manutenção – não há subdivisão
As brechas quanto ao local em que são introduzidas ou encontradas
A grande maioria das brechas de segurança são introduzidas ou encontradas no software e não no hardware. No entanto, visto que o software pode explorar falha do hardware estas também são consideradas na taxonomia.
Devido ao papel fundamental dos sistemas operacionais dentro dos sistemas computacionais, é ali que o maior número de ataques acontecerão. Por exempo, no caso dos vírus, a intenção é que eles consigam aderir ao código de inicialização do sistema operacional de modo que possam assumir o controle do sistema.
Já os danos por ataques aos softwares de aplicação podem não ser tão extensos quanto aos de sistema operacional, mas colocam em risco as informações e arquivos do usuário que estiver usando o software.
Exemplos da taxonomia por local em que as brechas são introduzidas ou encontradas:
Software – Sistema operacional – Inicialização do sistema
Software – Sistema operacional – Gerenciamento de memória
Software – Software básico – Utilitários autorizados
Software – Aplicações – não há subdivisão
Das diversas brechas estudadas, as brechas de sistema operacional são as que oferecem maiores danos ao sistema.
Fonte:
A Taxonomy of Computer Program Security Flaws, with Examples - Landwehr, Bull, McDermott, and Choi
O artigo apresenta uma sistemática que organiza as informações sobre brechas de segurança nos sistemas computacionais de modo que elas possam ser utilizadas por projetistas, analistas, programadores e consultores para entender novas brechas e também identificar pontos mais susceptíveis do sistema. A sistemática é bastante útil para aqueles profissionais encarregados de repelir os ataques e corrigir as falhas.
No entanto, esse tipo de estudo oferece o risco de ser utilizado pelas pessoas mal intencionadas, por isso, foram documentadas as brechas já publicadas anteriormente e mais antigas.
Geralmente uma brecha de segurança é um bug que pela definição da IEEE inclui os erros e faltas. O estudo considera tanto as brechas acidentais quanto aquelas inseridas de maneira proposital.
Algumas das iniciativas passadas para identificar falhas nos sistemas computacionais:
- Flaw Hypothesis Methodology (1970): estuda a documentação e a construção do sistema para gerar hipóteses sobre onde as falhas poderão estar. Em seguida, utiliza a documentação do sistema e os testes para confirmar a presença das falhas. Por fim, generaliza as brechas confirmadas para guiar os esforços futuros.
- RISOS: categorizou as brechas em sistemas operacionais em sete categorias.
- USC/ISI: categorizou os erros de seis sistemas operacionais em categorias que após o término do trabalho foram agrupadas em quatro categorias globais.
O estudo buscou responder a três perguntas básicas sobre as brechas de segurança:
- Como ela entrou no sistema?
- Quando ela entrou no sistema?
- Onde no sistema ela se manifestar?
Essas três perguntas serviram para organizar a taxonomia em: gênesis (como), tempo de introdução (quando) e localização (onde).
Os casos avaliados pelo estudo foram selecionados segundo o critério a seguir:
- o caso deve apresentar um tipo particular de vulnerabilidade claro o suficiente que o cenário ou programa que ameaça a segurança do sistema possa ser entendido pelo classificador, e
- o dano potencial resultante da vulnerabilidade descrita deve ser mais que superficial.
As brechas quanto ao gênesis
Essas brechas de segurança são criadas acidentalmente ou intencionalmente. No entanto, os esforços para evitar as brechas acidentais são diferentes daqueles para evitar as intencionais. Geralmente as acidentais são evitadas com maior dedicação aos testes e revisão do código. Já as intencionais são evitadas contratando-se programadores mais confiáveis, aplicando-se testes de penetração e investindo em pacotes de detecção de vírus.
Alguns exemplos definidos na taxonomia por gênesis são:
Intencional – maliciosa – bomba lógica
Intencional – não maliciosa – covert channel – temporizado
Inadvertida – erro de validação
Inadvertida – identificação / autenticação inadequada
O estudo alerta para o fato de que algumas brechas são introduzidas nas tentativas de consertar outras brechas.
As brechas quanto ao tempo de introdução
Considerando diversos processos de desenvolvimento e diferentes ciclos de vida de sistemas desenvolvidos, identificou-se três diferentes fases em que as brechas de segurança possam ser introduzidas nos sistemas:
- na fase de desenvolvimento, que inclui até a liberação da primeira versão.
- na fase de manutenção, que contempla a fase pós liberação da primeira versão.
- na fase operacional, que inclui as atividades de correção do software ao longo da sua utilização.
Exemplos da taxonomia por tempo de introdução:
Durante o desenvolvimento – elaboração do código fonte
Durante a manutenção – não há subdivisão
As brechas quanto ao local em que são introduzidas ou encontradas
A grande maioria das brechas de segurança são introduzidas ou encontradas no software e não no hardware. No entanto, visto que o software pode explorar falha do hardware estas também são consideradas na taxonomia.
Devido ao papel fundamental dos sistemas operacionais dentro dos sistemas computacionais, é ali que o maior número de ataques acontecerão. Por exempo, no caso dos vírus, a intenção é que eles consigam aderir ao código de inicialização do sistema operacional de modo que possam assumir o controle do sistema.
Já os danos por ataques aos softwares de aplicação podem não ser tão extensos quanto aos de sistema operacional, mas colocam em risco as informações e arquivos do usuário que estiver usando o software.
Exemplos da taxonomia por local em que as brechas são introduzidas ou encontradas:
Software – Sistema operacional – Inicialização do sistema
Software – Sistema operacional – Gerenciamento de memória
Software – Software básico – Utilitários autorizados
Software – Aplicações – não há subdivisão
Das diversas brechas estudadas, as brechas de sistema operacional são as que oferecem maiores danos ao sistema.
Fonte:
A Taxonomy of Computer Program Security Flaws, with Examples - Landwehr, Bull, McDermott, and Choi
sexta-feira, 9 de março de 2007
Keylogger encontrado em banco japonês
Em 2005 foi divulgada a tentativa frustrada de roubar US$ 440 milhões do Banco Sumitomo a partir da sua filial em Londres.Foi encontrado instalado em um dos computadores do banco um dispositivo conhecido como keylogger (capturador de teclas). Esse dispositivo tem a função de capturar os sinais elétricos das teclas pressionadas pelo usuário do computador e armazená-los para serem analisados posteriormente e assim conduzirem um ataque ao sistema utilizando as informações digitadas. É claro que não é uma tarefa fácil, mas o interesse dos ladrões é organizar os dados de modo a identificar as informações importantes, como: senhas, nomes de usuários, números de contas, etc.
O dispositivo encontrado no Banco Sumitomo parece ter sido instalado por um funcionário da limpeza durante suas tarefas diárias.
O banco foi vítima de um ataque do tipo Interceptação, no qual um elemento não autorizado ganha acesso a um recurso. Nesse tipo de ataque e em outros, a principal fonte de ameaça é o ser humano infiltrado na instituição.
Com certeza a instituição atacada possuía rotinas e sistemas de segurança, mas algo precisa ser melhorado. Uma avaliação precisa ser conduzida para identificar as funções de segurança que precisam estar disponíveis e qual o índice de garantia de eficácia dessas funcionalidades.
Os ataques digitais estão cada vez mais sofisticados e disseminados a ponto de pessoas comuns poderem ser facilmente treinadas para aplicar os golpes. A técnica básica utilizada para atacar o Banco Sumitomo é chamada de scan (varredura) e está em uso desde 1997. Ou seja, é quase uma década de desenvolvimento e aprimoramento. Será que as nossas rotinas de segurança estão sendo aprimoradas no ritmo apropriado para fazer frente a esses ataques?
O banco foi vítima de um ataque do tipo Interceptação, no qual um elemento não autorizado ganha acesso a um recurso. Nesse tipo de ataque e em outros, a principal fonte de ameaça é o ser humano infiltrado na instituição.
Com certeza a instituição atacada possuía rotinas e sistemas de segurança, mas algo precisa ser melhorado. Uma avaliação precisa ser conduzida para identificar as funções de segurança que precisam estar disponíveis e qual o índice de garantia de eficácia dessas funcionalidades.
Os ataques digitais estão cada vez mais sofisticados e disseminados a ponto de pessoas comuns poderem ser facilmente treinadas para aplicar os golpes. A técnica básica utilizada para atacar o Banco Sumitomo é chamada de scan (varredura) e está em uso desde 1997. Ou seja, é quase uma década de desenvolvimento e aprimoramento. Será que as nossas rotinas de segurança estão sendo aprimoradas no ritmo apropriado para fazer frente a esses ataques?
Fontes:
Assinar:
Comentários (Atom)