9 de agosto de 2010

Técnicas de Ataque: SYN Flood

Navegar na internet sem um sistema de segurança pode ser perigoso. Uma dica básica, mas importante, para se obter maior segurança na navegação é melhorar a percepção que se tem sobre quais são os riscos envolvidos. Esse é um dos artigos da série sobre técnicas de ataque pela Internet, que publico hoje no blog MAV.

O ataque SYN Flood é mais um na grande categoria de ataques de negação de serviço, ou DOS (Denial-of-Service). O nome “SYN” representa uma das flags do cabeçalho do protocolo TCP, com o significado de abrir uma nova conexão. Já “Flood” vem do inglês “inundação”. Em um ataque de SYN Flood o atacante envia para o servidor alvo uma grande quantidade de pacotes SYN.

Ao receber um pacote SYN, o sistema operacional sinaliza a conexão ao programa que deverá tratar da mesma. O programa então inicializa threads e uma quantidade de memória para cuidar da conexão. Com o número grande de conexões sendo abertas, todos os recursos de hardware do servidor são consumidos e os usuários reais/autenticos não conseguem acessar o servidor. Daí a negação de acesso ao serviço.

Normalmente nestes ataques a negociação da abertura da conexão não se completa. Ficam faltando a troca de outros dois pacotes da rede. Isso se deve ao fato de que é muito mais eficiente enviar apenas o primeiro pacote, que já isso já faz o servidor aceitar a conexão. Um segundo ponto que acontece normalmente neste ataque é que o IP de origem do pacote é camuflado (spoofed), tornando impossível tanto uma negociação completa quanto a identificação do autor do ataque.

No MAV 5.0 – Internet Gateway existe uma solução específica para o caso de ataques de DOS do tipo SYN Flood. Na ocasião de um ataque como este os usuários da rede não tem o acesso negado ao serviço. A questão é que qualquer proteção no nível do gateway da rede não impede que seu link de internet fique cheio devido ao ataque.

A conclusão, como sempre, é que temos que proteger os usuários da rede da empresa das ameaças da Internet. Não podemos contar com a certeza de que o usuário da rede esteja ciente de todos os tipos de ataques e problemas. Para evitar prejuízos ao patrimônio digital da empresa, devemos ter um sistema de segurança de Internet: instalado e bem configurado.

Um abraço e tenham um bom dia.

9 de junho de 2010

Técnicas de Ataque: Man in the Middle

Navegar na internet sem um sistema de segurança pode ser perigoso. Uma dica básica, mas importante, para se obter maior segurança na navegação é melhorar a percepção que se tem sobre quais são os riscos envolvidos. Esse é um dos artigos da série sobre técnicas de ataque pela Internet, que publico hoje no blog MAV.

A tradução literal do nome desse ataque é "homem no meio". Existem várias formas de sofrer o ataque, mas todas têm o mesmo princípio: o usuário está acessando um sistema semelhante ao autêntico, que na verdade é somente uma camada intermediária entre ele e o sistema autêntico. Esta camada intermediária tem acesso a todas as informações do usuário, que são enviadas ou recebidas do sistema. Normalmente o usuário tem dificuldade de identificar o ataque.

Um exemplo comum seria quando um usuário entra num site da web cujo endereço é semelhante ao do site original devido a um erro de digitação. O site falso pode agir como intermediário, com 100% da funcionalidade preservada, tendo acesso completo a tudo que o usuário enviar ou receber no site.

Outro ataque equivalente acontece quando o usuário é direcionado, por um link, ao site cujo endereço é parecido com o site original; o resultado é o mesmo. Nos dois casos pode acontecer do certificado SSL (o do cadeado no canto da tela) para o site ser válido, porém emitido em nome de outra empresa parecida com a autêntica.

Alguns vírus que roubam senhas de bancos o fazem abrindo uma tela por cima do navegador do usuário quando é solicitada a senha. O mesmo vale para alguns dos vírus que roubam senhas de e-mails, redes sociais e instant messenging.

A conclusão, como sempre, é que temos que proteger os usuários da rede da empresa das ameaças da Internet. Não podemos contar com a certeza de que o usuário da rede esteja ciente de todos os tipos de ataques e problemas. Para evitar prejuízos ao patrimônio digital da empresa, devemos ter um sistema de segurança de Internet: instalado e bem configurado.

Um abraço e tenham um bom dia.

15 de abril de 2010

Técnicas de ataques: Cross-Site Request Forgery

Navegar na internet sem um sistema de segurança pode ser perigoso. Uma dica básica, mas importante, para se obter maior segurança na navegação é melhorar a percepção que se tem sobre quais são os riscos envolvidos. Esse é um dos artigos da série sobre técnicas de ataque pela Internet que publico hoje no blog MAV.

Muito se fala dos riscos de se visitar sites falsos: um problema comum. Porém, mesmo quando o usuário está no site correto ainda corre o risco de ter um prejuízo devido à ação de hackers. Uma das técnicas usadas por eles para atingir esse objetivo é chamada de Cross-Site Request Forgery.

Por exemplo: suponhamos que você esteja acessando o seu webmail, usando endereço correto. Nesse momento, o nível de acesso que o seu browser terá no servidor do webmail lhe permite operações usuais: listar as mensagens da caixa de entrada, ler e-mails, enviar e-mails, criar pastas, listar/gerenciar contatos e etc. Qualquer requisição que o browser enviar será executada.

No ataque em pauta, o usuário é direcionado de alguma forma a um site malicioso: pode ser por um e-mail, que lhe pede para visitar um site interessante, ou qualquer outra técnica de engenharia social. A partir daí o site malicioso, supondo que o usuário esteja acessando o webmail neste momento, envia requsições ao servidor do webmail como se ele fosse a própria página do webmail.

Daí o nome do ataque: em português, "Requisição Falsa Entre Sites". O site falso manda requisições que o usuário não fez para o site que ele está acessando.

Só que, para o servidor do webmail, a requisição tem os parâmetros corretos e vem do browser/ip correto. Pela lógica, ele (o servidor) deve aceitar essa requisição. E, normalmente, é o que ele faz.

Um ataque bem sucessido pode ter diversos efeitos: desde do simples uso do seu webmail para envio de spams, a operações mais sofisticadas, tais como acessar informações confidenciais no seu webmail, realizar alterações no sistema de ERP, via web, ou até mesmo trocar o endereço de entrega de uma compra online.

A solução para esse tipo de ataque não é simples. As requisições autênticas enviadas pelo browser para o servidor precisam conter alguma informação secreta, que permita autenticá-la. Normalmente a ação envolve a construção de um sistema de comunicação sofisticado, no site e no servidor. O problema é que a maioria dos desenvolvedores de aplicações web não implementam esse tipo de segurança em seus sistemas.

A conclusão, como sempre, é que temos que proteger os usuários da rede da empresa das ameaças da Internet. Não podemos contar com a certeza de que o usuário da rede esteja ciente de todos os tipos de ataques e problemas. Para evitar prejuízos ao patrimônio digital da empresa devemos ter um sistema de segurança de Internet: instalado e bem configurado.

Um abraço e tenham um bom dia.

8 de março de 2010

MAV 5.0 - Mail Security bloqueando 99,85% dos spams no MPU

O maior cliente, em volume de e-mails, do MAV 5.0 - Mail Security atualmente é o Ministério Público da União, instituição federal que compreende: o Ministério Público Federal (MPF), o Ministério Público do Trabalho (MPT), o Ministério Público Militar (MPM) e o Ministério Público do Distrito Federal e Territórios (MPDFT). Toda a segurança de e-mails para os Procuradores da República do Brasil é provida pelo MAV 5.0.

Recentemente nós atualizamos o produto instalado nos servidores do MPU com a nova versão de Março/2010 do nosso algoritmo antispam (antes a versão era de Setembro/2009). Para verificar a melhora, e como o MPU é um cliente com volume de e-mails/spam bastante alto, nós fizemos um estudo estatístico para analisar a melhoria do produto em duas questões:

  • Dos e-mails que chegam ao usuário, qual é a proporção de spams?
  • Dos spams que chegam ao servidor, qual proporção é bloqueada?
A primeira pergunta reflete a qualidade percebida pelo usuário no antispam. O usuário não conhece o que ele deixou de receber, vê apenas o que passou. A segunda reflete a eficiência real do produto no bloqueio de spams, mostra o que aconteceria caso o produto fosse desativado/retirado.

Originalmente, 9,80% dos e-mails que chegavam para os usuários eram spams e este foi o fato que gerou a urgência da atualização e a necessidade do estudo em questão.

Resultados

A melhoria foi realmente bacana, caindo de 9,80% para apenas 2,4% do que o usuário final recebe ser spam. Uma redução de 75%!

O que foi fantástico descobrir é que com a nova versão 99,85% dos spams foram bloqueados! Ou seja, a cada 660 spams que foram enviados ao servidor apenas 1 passou. Não há como expressar o nível de satisfação que eu sinto com o resultado do novo produto, ainda mais por ter sido medido em um ambiente real e complexo como o do MPU.

Para os curiosos, com a versão de Setembro/2009 o produto estava bloqueando "apenas" 99,37% dos spams, deixando passar 1 a cada 150.

A equipe de desenvolvimento da MAV Tecnologia tem uma pessoa com dedicadação exclusiva a este modulo e é sensasional observar um resultado tão bacana.

Um abraço e tenham um bom dia.

26 de fevereiro de 2010

Parasoft C++Test: um Salto de Qualidade de Software na MAV Tecnologia

É inegável o efeito que falhas de software têm no dia-a-dia das empresas. E a questão é simples: todo software falha! O que diferencia cada empresa e cada projeto é a frequencia com que as falhas ocorrem e o tempo de respostas a elas.

Na MAV nós temos rotinas de testes de software implantadas que buscam cercar toda a lógica do produto, principalmente nos módulos de baixo nível, que tem maior complexidade. Infelizmente todos os testes de unidade, testes de sistemas e testes de interface do mundo juntos não identificariam todos os erros de um software. A causa disso são os erros de implementação. A lógica estaria correta mas existe uma falha na utilização da memória ou um caso de erro não verificado no código. Por exemplo, há um mês identificamos e corrigimos um bug no MAV 5.0 que só acontecia quando o servidor de DNS da rede estava indisponível.

Para resolver este problema a MAV Tecnologia concluiu nesta semana o processo de compra do software C++Test Server Edition da empresa americana Parasoft. A funcionalidade de interesse, chamada BugDetective, é simplesmente fantástica. O BugDetective do C++Test analisa todo o código fonte de um software procurando por erros de implementação. O software analisa cada possível valor de variável, cada possibildade de resultado para cada if/while/for, cada alocação de memória, cada chamada de função chamada e cada possível retorno. O software trilha todos os caminhos possíveis que a execução do software pode ter procurando por condições que levam o software a falhar.

O resultado foi simplesmente incrível. Nós analisamos o código fonte do MAV 5.0 e foram encontradas um número muito grande de situações raras que levariam horas, se não dias, para depurar e identificar a causa. O software identificou situações que eu, com 13 anos de experiência com programação, fui surpreendido. Identificou casos que dependem de uma análise tão profunda e tão longa que é praticamente impossível que um revisor de código humano visualize.

Para mim esta aquisição representa um marco, um salto na nossa qualidade de software. A união de testes de unidade, testes de sistema e testes de interface com a análise estática de código fonte realizada pelo C++Test garantem o nível de qualidade que nós e nossos clientes esperam dos produtos da MAV.

Um abraço e tenham um bom dia.

24 de maio de 2009

RBLs (SpamCOP, CBL, SpamHaus e Sorbs): uma análise probabilística

Hoje em dia o ponto de partida na luta para bloquear spams são as RBLs. Computadores que são detectados enviando spams na internet são cadastrados pelos sistemas que administram estas listas. Na maioria dos casos todos podem consulta-las para rejeitar o spam antes mesmo que ele seja recebido e analisado pelo servidor, o que geraria um custo computacional e de banda de internet desnecessário.

Agora imagine uma situação onde após a entrada de um novo vendedor na empresa é criada uma conta de e-mail para ele. O novo funcionário divulga seu e-mail, que passa a ser usado normalmente. Um dia depois, ao analisar uma mensagem direcionada a ele, verifica-se que o IP do remetente está bloqueada em uma RBL. Neste ponto eu faço duas perguntas:

  1. Qual a probabilidade deste e-mail ser um spam?
  2. Qual o risco que a empresa correrá de descartar uma mensagem autêntica se descartar este e-mail?
Este exemplo mostra que é necessário fazer uma análise estatística e probabilística em cada RBL disponível na internet para entendermos exatamente os riscos e os ganhos que nós estamos lidando.

Eu analisei o tráfego de e-mails do Supramail durante uma manhã para fazer estas análises. Uma porproção das mensagens que chegaram foram sorteadas para o teste. Eu testei 8 RBLs: SpamCOP, Sorbs DNSBL, Sorbs SPAM, CBL, SpamHaus SBL, SpamHaus PBL, SpamHaus XBL e NjaBL. Para ter certeza dos dados eu solicitei que o Filipe, novo desenvolvedor da MAV com foco exclusivo no antispam, analisasse a lista de e-mails manualmente (pelo assuntos) para não haver erros nos resultados. Vou citar aqui alguns resultados interessantes.

De cara 3 listas foram imediatamente descartadas: a Sorbs SPAM, a SpamHaus SBL, utilizada atualmente pelo MAV 4.4 - Mail Security, e a NjaBL. As três apresentaram uma taxa de detecção de spams baixa tendo um nivel de falsos positivos comparável com o das outras.

A análise mostrou que se as cincos listas tivessem sido utilizadas cegamente nós acabaríamos tendo um falso positivo superior a 2%. Por "cegamente" entenda descartar uma mensagem quando o IP do remetente estiver bloqueado em qualquer uma delas. Por cegamente também entenda "o procedimento normal utilizado por todos os softwares que eu conheço que consultam RBLs", inclusive o MAV 4.4. Se bem que o MAV 4.4 tem diversos recursos que detectam falsos positivos de forma separada. De qualquer forma, 2% de chance de descartar uma mensagem autêntica é um risco extremamente alto na minha opinião.

A RBL que se saiu melhor nos testes foi a Sorbs DNSBL. A probabilidade de que um e-mail recebido de um IP bloqueado na Sorbs DNSBL fosse spam foi de 99,94%. Ou seja, o risco de falsos positivos foi de 0,06% (ou 1 em 1667 mensagens).

Outro resultado super interessante é que combinar as listas obtém resultados completamente confiáveis. Na média, apenas 1 em 32000 mensagens serão bloqueadas incorretamente se a mensagem for descartada quando o IP do remetente estiver bloqueado em 2 as 5 listas. Subindo o número para três a proporção sobe para 1 em 14 milhões. O mais interessante é que ao exigir o bloqueio em pelo menos 2 das 5 listas a taxa de bloqueio de spams cai apenas 9%.

Para mim, qualquer taxa de erro inferior a 1 em 20.000 vale o mesmo que não errar. Neste nível um usuário médio teria cerca de 60% de chance de não ver nenhuma mensagem autêntica descartada incorretamente durante 6 meses.

No final das contas o correto é considerar todas as informações com uma análise probabilística. O antispam do MAV 5.0 é completamente baseado neste direção. Nenhum parâmetro é suficiente para bloquear ou liberar uma mensagem por conta própria. E-mails enviados para usuários que recebem pouco spam são tratados de forma completamente diferente de e-mail enviados para usuários que recebem muito spam. Os 25% dos usuários que recebem menos que 10% de spam não podem ter e-mails analisados com as mesma força dos 25% dos usuários em que mais de 70% dos e-mails que recebem são spams.

Só é uma pena que, devido a característica proprietária da informação, eu não possa discutir as diferenças entre os métodos que são bons para identificar e-mails autênticos que não necessariamente identificam spams bem, comparando-os com os métodos que identificam spams bem mas não são bons para identificar e-mails autênticos. Pessoalmente, eu tive surpresas muito curiosas nos estudos que nós temos desenvolvido há alguns meses nesta área.

Um abraço e tenham um bom dia.

1 de abril de 2009

O Virus Conficker

Este primeiro de Abril está sendo um dia preocupante para os administradores de redes de todo o mundo. Hoje é o dia em que o virus Conficker ativa sua nova formula de atualização dos computadores já infectados. Eu vou explicar por que esse é o virus mais avançado que já se espalhou na internet até hoje, esse sendo o motivo da preocupação que os especialistas estão demonstrando na mídia.

A forma de infecção do virus é séria mas sem muita novidade. As primeiras variantes (A, B e C), exploravam uma falha de segurança do Windows 2000, Windows XP, Windows 2003, Windows Vista e Windows 2008. A Microsoft corrigiu a falha de segurança em outubro passado, mas ainda temos muitas máquinas vulneráveis. A falha é séria pois a instalação do virus é automática, não requer nenhuma ação do usuário ou do administrador da rede. As variantes B e C também se espalham procurando compatilhamentos de rede com senhas fracas e por pendrives USB. A versão D não se reproduz, o que tecnicamente lhe faria perder o status de virus.

A novidade do Conficker no quesito se espalhar é que cada vez que ele se reproduz seu arquivo é recompactado e recriptografado utilizando parâmetros e senhas diferentes. O resultado é simples: nenhum arquivo do virus é igual ao outro. Como a maioria dos antivirus funciona procurando assinaturas de virus nos arquivos apenas eles não conseguem identificar os arquivos do virus . Os produtos Norman e MAV (que utiliza as tecnologias da Norman), procuram assinaturas no padrão de execução do arquivo também. Somos um dos poucos a identificar os arquivos do Conficker.

O sistema de atualização automática do virus também é interessante. Os virus anteriores no máximo tinham uma lista de poucos sites em que eles procuravam suas atualizações. Era relativamente fácil desabilitar dos estes sites e garantir que o virus não se atualizasse. Hoje entrou em funcionamento um novo sistema em que o virus gera uma lista de 50.000 sites por dia (a lista muda todos os dias), cada máquina infectada escolhe 500 para tentar baixar sua nova atualização. Esses 50.000 sites estão espalhados em vários TLDs de vários países. Fica virtualmente impossível desabilitar tantas possibilidades todos os dias para impedir que o virus se atualize nas máquinas infectadas.

Além disso, a variante D do virus também tem um avançado sistema de P2P para espalhar novas versões do virus. Uma vez que alguma máquina é atualizada com sucesso (o método acima atualizaria 1% das máquinas por dia no máximo), essa máquina começa a conversar com outras máquinas infectadas para espalhar a nova variante.

Outro ponto interessante é que a nova versão é assinada digitalmente utilizando a mesma tecnologia que a Microsoft e todas as outras usam para assinar suas atualizações. Isso impede que terceiros tentem sequestrar as máquinas infectadas colocando no ar uma falsa atualização que desabilite o virus, o que já havia sido feito anteriormente com outros virus.

Como desenvolvedor de softwares de segurança não há como não ficar impressionado com a sofisticação do Conficker. Ele realmente foi o que chegou mais perto do que eu imagino ser um "virus perfeito". Não chegou lá, mas chegou perto.

Vale citar também que tamanha sofisticação não parece obra de apenas um programador. Na minha opinião ele foi criado por uma equipe de hackers realmente conhecedora. Não seria simples montar uma equipe como esta.

Vale a preocupação? Sim. Ele realmente tem o potencial de gerar um estrago enorme. Estimativas indicam que exitem entre 4 e 10 milhões de computadores estão infectados e não me parece que serão limpos tão cedo. Controlando essa quantidade de computadores seria possível até mesmo parar a internet. Sem exageiro.

O que fazer?

  1. Mantenham os sistemas operacionais dos computadores sempre atualizados.
  2. Não utilize senhas fracas para nada. Use uma frase com no mínimo quatro palavras ou um conjunto de letras, números de caracteres especiais (@#$%^&*...). No caso das frases seja criativo, "Ordem e progresso", "Quando o sol bater na janela do meu quarto" e outras são conhecidas e não contam.
  3. Mantenha seus servidores atrás de um firewall. Se der para fazer uma DMZ é melhor. O MAV 5.0 - Internet Gateway está para ser lançado e seu firewall é bem avançado (explicarei depois no blog os porquês).
  4. Tenha um antivirus de qualidade nos servidores e nas estações. Em questão de qualidade, ninguém bate a Norman e a Kaspersky para antivirus de estação (as duas detectam o Conficker).
Um abraço e tenham um bom dia.

13 de março de 2009

Três milhões de vírus e a tecnologia Norman DNA Matching

Em outubro de 2007 eu havia postado uma notícia aqui no blog falando que o número de vacinas no banco de dados da Norman havia passado de um milhão. Bem, acabamos de passar de três milhões de vacinas! Para ser exato, a versão liberada hoje cedo tem 3.000.002 vacinas contra vírus.

Há um certo tempo já é publico que identificar vírus baseando-se apenas em vacinas é um trabalho cada vez menos eficiente. Nos últimos 18 meses foram criadas 2 milhões de vacinas contra vírus, ou seja, uma vacina contra vírus a cada 2 minutos.

A razão para tal é que uma vacina de vírus normalmente consegue capturar apenas uma ou poucas variantes do vírus. Vírus modernos laçam variantes na ordem das centenas por vez. O Conficker, por exemplo, está sempre se re-compactando e re-criptografando com parâmetros aleatórios antes de se reenviar, fazendo com que os arquivos que estão se espalhando na internet sejam sempre diferentes.

A MAV sempre contou com a tecnologia Norman Sandbox para detectar vírus anasilando as ações que ele toma quando executado em uma máquina virtual. Conta também com o sistema próprio de Assinatura Dinâmica de Vírus, que identifica novos virus sendo enviados por e-mail automaticamente. Essas barreiras nos garantem um sucesso muito grande na luta contra vírus.

Atualmente estão sendo desenvolvidos na MAV Tecnologia alguns projetos internos para o MAV 5 que objetivam a identificação de computadores infectados na rede interna da empresa sem a necessidade de obter uma vacina para o vírus (dentre outros). A detecção é automática e imediata. Isso possibilitará, por exemplo, retirar o computador da internet ou até mesmo da rede interna para minimizar os problemas causados pelo vírus.

Nesta semana a Norman lançou uma nova tecnologia de detecção de vírus também muito moderna. A tecnologia é chamada Norman DNA Matching. Graças a esta tecnologia produtos que utilizam a engine da Norman (como o MAV) tem conseguido identificar o Conficker com sucesso. O Norman DNA Matching utiliza dados obtidos da execução do vírus na máquina virtual Norman Sandbox para criar um DNA das instruções e códigos executados pelo vírus. Esse DNA, que não muda mesmo quando o vírus é re-compactado ou re-criptografado, é utilizado para identificar o vírus. Esse com certeza é um passo que leva a identificação de vírus por vacinas para um outro nível.

Um abraço e tenham um bom dia.

11 de março de 2009

II Semana da Matemática Computacional UFMG

Hoje a MAV Tecnologia participou da II Semana da Matemática Computacional na UFMG. O objetivo foi mostrar aos calouros do curso como são aplicados no mercado de trabalho os conhecimentos que serão adquiridos.

O desenvolvedor Leandro Nunes, aluno da Matemática Computacional na UFMG, demostrou alguns métodos matemáticos que nós utilizamos no MAV 5.0 para identificação de spams, sites de conteúdo adulto, computadores infectados na rede interna, e etc.

Na minha opinião, na do Leandro e na dos organizadores do evento, a participação atingiu os objetivos de todos. Com certeza foi muito interessante conhecer os futuros possíveis desenvolvedores da equipe.

Um abraço e tenham um bom dia.

2 de março de 2009

MAV 5.0 - Web Security Beta: participe do desenvolvimento.

Cerca de 15 meses de desenvolvimento depois chegou a hora de anunciar a versão Beta do MAV 5.0 - Web Security. Nós convidamos nossos clientes e parceiros para participar mais uma vez do desenvolvimento do MAV 5.0.

Durante todo o desenvolvimento do MAV 5.0 inovação foi sempre uma palavra chave. Nós inovamos para achar a melhor solução para os problemas de segurança de internet enfrentados pelas empresas hoje.

A melhor solução nem sempre ficou próximo do que já existia. Para criar o MAV 5.0 nós primeiro criamos uma linguagem de programação chamada Integral, baseada em Lua, especializada na criação de softwares de segurança de Internet. O Integral é a base sólida de todos os produtos que nós começamos a lançar a partir de agora.

As novidades do MAV 5.0 são muitas. Para falar de todas aqui seria necessário escrever um texto realmente grande de se ler. Uma que nós terminamos recentemente é o NetView do Web Security. NetView significa visualizar o que está acontecendo no sistema em tempo real. No MAV 5.0 - Web Security isso significa visualizar os downloads que estão acontecendo em tempo real (nome do arquivo, usuário, tamanho, velocidade, quando vai acabar, etc...) e também um sumário de todo o tráfego de web como na tela abaixo:


Assim como ficou definido no MAV Developers' Day, em Setembro passado, nós criamos uma lista de discussão cujo tema é o desenvolvimento do MAV 5: discutir formas de implementar algumas funcionalidades, a ordem em que nós vamos entregar novas funcionalidades aos nossos clientes, etc. Participarão da lista os clientes interessados e todos os desenvolvedores do MAV 5. A lista não foi criada antes pois o MAV 5.0 é tão diferente do MAV 4.4 que não faria muito sentido discutir sobre ele sem estar usando, ou pelo menos sem ter uma cópia instalada.

Clientes interessandos em testar o MAV 5.0 - Web Security devem entrar em contato com o Célio Coti no nosso suporte técnico para que seja feito seu cadastro na lista de discussão do MAV 5. Na lista nós falaremos de mais detalhes do beta. A versão beta será liberada na próxima segunda-feira, dia 9 de Março.

A versão beta do MAV 5.0 - Internet Gateway, MAV 5.0 - Mail Security e MAV 5.0 - IM Security, devem sair, respectivamente, em abril, maio e junho próximos. A versão oficial será liberada quando o produto estiver estável.

Meus parabéns para a equipe de desenvolvimento e meu muito obrigado a todos os clientes.

Um abraço e tenham um bom dia.