Baixe Guia Definitivo para o Gerenciamento de Segurança e outras Notas de estudo em PDF para Administração Empresarial, somente na Docsity!
Índice
- Capítulo 3: Medidas Proativas – Gestão e Reparação de Vulnerabilidade.......................................... i
- Tipos de vulnerabilidade......................................................................................................................
- Vulnerabilidades de software...................................................................................................
- Vulnerabilidades de configuração............................................................................................
- Respondendo às vulnerabilidades ........................................................................................................
- Respostas ad hoc ......................................................................................................................
- Patching não é gestão de vulnerabilidade....................................................................
- Ativos omitidos............................................................................................................
- Vulnerabilidades de configuração omitidas.................................................................
- Mau teste de impacto ...................................................................................................
- Documentação inadequada de gestão de alteração ......................................................
- Má gestão de processo .................................................................................................
- Má priorização .............................................................................................................
- Respostas geridas .....................................................................................................................
- Panorama geral para entender a gestão da vulnerabilidade .........................................
- Que ativos existem na organização? ............................................................................
- Que vulnerabilidades ameaçam a organização? ..........................................................
- Quais são os riscos das vulnerabilidades? ...................................................................
- Qual é o custo para compensar as vulnerabilidades?...................................................
- Melhores práticas na gestão da vulnerabilidade ..................................................................................
- Ciclo de vida da gestão da vulnerabilidade..............................................................................
- Monitorar .....................................................................................................................
- Como analisar ativos e vulnerabilidades......................................................................
- Notificar .......................................................................................................................
- Priorizar........................................................................................................................
- Planejar ........................................................................................................................
- Testar............................................................................................................................
- Remediar ......................................................................................................................
- Reportar........................................................................................................................
- Cenário de gestão da vulnerabilidade ..................................................................................................
- Monitorando ameaças emergentes...........................................................................................
- Analisando e notificando .........................................................................................................
- Priorizando e planejando..........................................................................................................
Índice
ii
Testes, reparação e relatórios...................................................................................................
Resumo ................................................................................................................................................
Capítulo 3: Medidas Proativas – Gestão e Reparação de
Vulnerabilidade
As vulnerabilidades da segurança foram outrora o foco da discussão somente entre administradores de sistemas e profissionais de segurança, mas agora elas estão criando manchetes em publicações de negócios e de notícias mundiais. Os jornalistas advogam o abandono de um popular navegador Web bem conhecido por suas vulnerabilidades. Os bloggers cismam com a relativa vulnerabilidade de diferentes sistemas operacionais (OSs). Esta crescente conscientização destaca a importância e o impacto das vulnerabilidades da segurança da informação. O pessoal técnico não é mais o único grupo interessado na gestão da segurança. A questão da conformidade com a segurança está ganhando proeminência através das organizações até e inclusive a diretoria.
Este capítulo começa com uma discussão dos tipos de vulnerabilidades e duas abordagens amplas para responder a elas, gestão ad hoc , e então apresenta a evolução das abordagens geridas. A seguir, o ciclo de vida da gestão da vulnerabilidade é discutido, e cada etapa é explorada em detalhe. O capítulo termina com um cenário exemplificativo demonstrando a necessidade e uma gestão eficaz da vulnerabilidade.
Para um exemplo sobre as frustrações de um blogger com as vulnerabilidades de sistema operacional, consulte Is Windows inherently more vulnerable to malware attacks than OS X?” em http://weblog.infoworld.com/enterprisemac/archives/2006/08/is_windows_inhe.html.
Tipos de vulnerabilidade
As vulnerabilidades surgem de erros em aplicativos de software ou de ativos mal-configurados; eles são imperfeições inerentes do software ou más configurações de sistema permitindo que código malicioso comprometa o sistema. Se exploradas, as vulnerabilidades podem causar impacto sobre as organizações em miríades de modos – desde afetar a continuidade dos negócios até influenciar a confiança dos clientes.
Vulnerabilidades de software
Há vários tipos de vulnerabilidades de software. Alguns resultam de erros não intencionais em código; Por exemplo, práticas de programação ruins, tais como deixar de verificar o comprimento de séries antes de armazená-las em arranjos de caracteres de comprimento fixo, cria avenidas para executar código malicioso dentro do contexto de programas legítimos. (Quando uma série mais longa do que o comprimento projetado é armazenada num arranjo, ocorre uma sobrecarga do buffer , e código de programa legítimo pode ser substituído por código malicioso). Uma outra fonte de vulnerabilidades de software é o uso intencional de uma rotina de backdoor ou de um gancho de manutenção, que é um código adicionado a um programa por seu desenvolvedor para permitir acesso posterior contornando os mecanismos de controle de acesso. Outras vulnerabilidades são inerentes no projeto de um aplicativo.
A facilidade com a qual spammers e phishers podem forjar endereços de retorno de e-mail resulta do projeto do Protocolo Simples de Transferência de Correio (SMTP). Este tipo de vulnerabilidade não pe divido a um erro, mas a uma escolha de projeto. Em alguns casos as escolhas de projeto são descuidos; em outros casos a vulnerabilidade é o resultado de um uso
utilizarem todas estas melhores práticas, ainda assim as vulnerabilidades continuarão a existir e a proliferar. Assim, onde repousa a responsabilidade?
As organizações podem dedicar muitos recursos para prevenir vulnerabilidades. Programadores, projetistas e administradores de sistemas devem disponibilizar aplicativos funcionais que operem de acordo com os requisitos de negócio. Eles estão sob limitações para fazer isso. Prevenir vulnerabilidades é um aspecto importante de qualquer projeto de desenvolvimento ou instalação e configuração, mas não é o único. Se a escolha chegar a ponto de disponibilizar um sistema de geração de receita dentro do prazo e do orçamento ou atrasá-lo por 2 meses para checar vulnerabilidades, quantas vezes uma empresa escolheria a última opção?
Não é prático esperar que todas as vulnerabilidades sejam eliminadas durante o desenvolvimento e instalação. As organizações precisam assumir que os aplicativos de produção, não importa o quanto sejam bem testados, têm vulnerabilidades. O problema então se torna uma questão de como responder a estas vulnerabilidades.
Respostas ad hoc
Uma abordagem para gerir vulnerabilidades é simplesmente tratar cada uma conforme ela se torna conhecida. Este tipo de abordagem ad hoc não tem um método formal mas segue um padrão geral que inclui:
1. Ouvir falar da vulnerabilidade 2. Procurar um patch (remendo) 3. Baixar o patch 4. Aplicar o patch 5. Possivelmente, entrar em contato com outros administradores quanto à vulnerabilidade e patch 6. Assumir que a vulnerabilidade está mitigada
Além do fato que patchning não é gestão de vulnerabilidade, há vários problemas com esta abordagem:
Probabilidade aumentada de ativos omitidos Probabilidade aumentada de vulnerabilidades de configuração negligenciadas Falta de efetuar teste de impacto completo Produção inadequada de documentação de alteração de gestão Má gestão de processo Má priorização
Cada um destes itens é uma deficiência importante para a gestão da vulnerabilidade.
Patching não é gestão de vulnerabilidade
Primeiro, e mais importante, patching não trata todas as vulnerabilidades. Sem um procedimento metódico para monitorar vulnerabilidades, uma organização não pode rastrear se todas as vulnerabilidades conhecidas na ampla comunidade de TI foram mitigadas dentro de seu ambiente. Algumas vulnerabilidades são causadas por erros de configuração; assim, não pode haver um patch para corrigir a vulnerabilidade. De fato, há diversas vulnerabilidades que não são
Escopo do patch
Sistemas operacionais amplamente utilizados, como os da família Microsoft Windows, têm uma ampla gama de recursos que são utilizados somente por uma fração do número total de usuários do sistema operacional. Por exemplo, o Microsoft NetMeeting Remote Desktop Sharing é incluído como parte do sistema operacional Windows. Esta ferramenta permite que usuários autorizados acessem a área de trabalho de uma outra máquina durante uma sessão de NetMeeting. Organizações que utilizam o NetMeeting deverão manter patches atualizados para este serviço porque ele é uma rota óbvia para comprometer serviços e áreas de trabalho. Se o NetMeeting não for utilizado, o serviço deverá ser desabilitado de modo que não haja necessidade de remendá-lo.
Idealmente, remendar um serviço não utilizado não teria efeito líquido sobre o perfil de segurança de um sistema. Porém, há um risco de que um patch poderia introduzir novas e ainda desconhecidas vulnerabilidades. Do mesmo modo que receitar medicamentos, aplicar patches envolve benefícios e riscos.
Pré-requisitos de patch
Os patches são projetados para versões de software em particular; o projeto destes patches poderá incluir hipóteses sobre o sistema alvo ao qual eles são aplicados. Do mesmo modo que entender o escopo de um patch , os administradores de sistema deverão entender os pré-requisitos para instalar um patch. Se os pré-requisitos não forem atendidos, o patch poderá não mitigar a vulnerabilidade alvo, poderá introduzir outras vulnerabilidades, ou poderia introduzir bugs no sistema remendado. Os programas de instalação de patch poderão testar para assegurar que os pré-requisitos são atendidos, mas os administradores de sistema não deverão confiar unicamente nos procedimentos de teste que são efetuados fora de seu próprio ambiente.
Efeitos de um Patch sobre outros aplicativos
Quando uma vulnerabilidade é descoberta num aplicativo, a melhor maneira de consertá-la é solicitar uma alteração no código compartilhado por vários aplicativos. Uma vulnerabilidade num navegador Web, por exemplo, poderá requerer uma alteração num módulo de biblioteca compartilhado que também é utilizado por clientes de e-mail. Um patch para uma vulnerabilidade ftp poderá alterar um módulo também utilizado por um pacote de emulação de terminal de terceiro.
Não há praticamente nenhuma maneira de saber, antes de instalar um patch em código compartilhado, como ele irá afetar todos os outros aplicativos. Mesmo em organizações com gestão de alteração madura e processos para rastrear dependência, existem dependências desconhecidas. Os fornecedores não estão ansiosos por revelar detalhes sobre seu software proprietário, inclusive sobre os serviços de sistema operacional utilizados. Mesmo quando for possível rastrear dependências de nível baixo (por exemplo, com aplicativos de fonte aberta), as limitações praticas de tempo e recursos tornam isso improvável. Testar patches num ambiente controlado que espelha a infra-estrutura de produção contrabalança a necessidade de entender o impacto de um patch sem incorrer nos custos extraordinários de rastrear detalhes finos de dependência.
Como restaurar depois de um patch falho
Os patches nem sempre instalam corretamente: Como outros softwares, eles podem conter bugs , ou os patches poderão não funcionar com configurações particulares. No processo d descobrir uma falha, o processo de instalação do patch poderá ter configurações de registros substituídos ( overwritten ), configurações de aplicativo alteradas, e bibliotecas compartilhadas substituídas, assim deixando o sistema em um estado instável.
Alguns sistemas de gestão de patch provêm procedimentos de recuperação que podem recuperar ( roll back ) os efeitos de um patch. Se estes procedimentos não estiverem disponíveis ou não funcionarem, o sistema remendado poderá precisar ser restaurado a partir de backup. Em ocasiões como esta, os administradores de sistema não querem depender de uma combinação de procedimentos ad hoc e pensamento positivo para terem seus sistemas de volta.
Testar patches num ambiente controlado pode identificar problemas imprevistos e evitar conseqüências adversas. Infelizmente, a gestão de vulnerabilidade ad hoc não provê para esses testes.
Documentação inadequada de gestão de alteração
Algumas vulnerabilidades são severas o bastante para demandar ação imediata. O verme SQL Slammer, por exemplo, se espalha em poucos minutos sobre grandes partes da Internet. Quando os administradores de sistemas de defrontam com ataques do SQL Slammer em grande escala, sua primeira prioridade é proteger sua estrutura de TI. Os servidores poderão ser tirados da linha e segmentos da rede desconectados do resto da rede empresarial. Tais ações são somente uma solução parcial
Se os servidores de produção caírem, a primeira prioridade é remendá-los ou re-configurá-los e trazê-los de volta à linha. Se muitos servidores tiverem de ser remendados ou re-configurados, poderá haver ligeiras variações no processo através dos servidores. Diferentes revisões do sistema operacional ou dos aplicativos poderão requerer diferentes versões do patch ou diferentes ajustes de configuração. O modo de " fire drill " induzido pela gestão de vulnerabilidade ad hoc deixa pouco espaço para documentar os diversos procedimentos de patch.
Infelizmente, a falta de documentação adequada perpetua os problemas da abordagem ad hoc. Sem documentação adequada sobre as alterações, na próxima vez que uma vulnerabilidade ameaçar, os responsáveis por responder deverão inventariar os sistemas quanto ao histórico de patch ou arriscar aplicar patches com informação insuficiente. Estas são más opções para deixar com um administrador de sistemas.
Má gestão de processo
Os processos ad hoc são difíceis de monitorar, melhorar e duplicar. A documentação, quando é mantida, provavelmente é inconsistente. Em algumas instâncias, um administrador poderá documentar os detalhes técnicos da vulnerabilidade, mas escrever pouco sobre as configurações do sistema individual; em outros casos, as alterações nos parâmetros de sistema poderão ser documentadas, mas a informação da versão do software fica faltando; Documentação abrangente e consistente é uma ajuda à gestão de vulnerabilidade que muito facilmente é deixada sem fazer.
Documentação sólida descrevendo o que deverá ser feito e o que foi feito para mitigar vulnerabilidades é essencial para melhorara resposta de uma organização às vulnerabilidades.
Blindagem e Defesas Perimetrais
Blindagem é o processo de proteger ativos contra ameaças em potencial sem objetivar uma ameaça específica. As técnicas de blindagem variam de acordo com o ativo protegido, como por exemplo:
Fechar portas de firewall
Negar direito de acesso a diretórios de servidores
Varrer o conteúdo de código malicioso
Assegurar que um PC ou laptop tenha patches e software antivírus atualizados e que também cumpra com as políticas de segurança antes que o sistema tenha pleno acesso concedido a uma rede corporativa.
O princípio por trás da blindagem é assumir que vulnerabilidades desconhecidas existem e bloquear os pontos potenciais de entrada. Este processo não elimina a necessidade de mitigar vulnerabilidades; sua meta é reduzir as ameaças potenciais e contê-las o máximo possível
Panorama geral para entender a gestão da vulnerabilidade
Quatro questões-chave confrontam as organizações com respeito às vulnerabilidades:
Que ativos existem na organização? Que vulnerabilidades ameaçam a organização? Quais são os riscos destas vulnerabilidades? Quais são os custos para compensar estas vulnerabilidades?
Estas questões formam a estrutura em torno da qual um processo de gestão da vulnerabilidade maduro, proativo e eficiente é construído.
Que ativos existem na organização?
A gestão da vulnerabilidade depende de um inventário de ativos preciso. Este inventário inclui hardware, software, arquivos de configuração, arquiteturas de sistemas, processos de integração de aplicativos, processos de fluxo de trabalho e outros ativos de informação tangíveis e intangíveis. É importante notar que a informação sobre como o ativo é utilizado é importante para a gestão da vulnerabilidade. Por exemplo, um servidor Linux poderá ser usado como um servidor ftp para transferências de arquivo dentro da empresa. Este tipo de uso seria normalmente considerado uma operação de baixa prioridade ao determinar a ordem de patching. Esse mesmo servidor ftp, no entanto, poderá ser utilizado para armazenar temporariamente extratos noturnos de um mainframe que são destinados ao armazenamento de dados. Neste caso, o servidor ftp funciona como uma parte crítica de um processo de inteligência de negócio que deve executar todas as noites. Os responsáveis por patching e reconfiguração de servidores precisarão levar esta informação em conta ao priorizar reparos de vulnerabilidades.
De forma semelhante, entender como os ativos não são utilizados pode ajudar a gestão da vulnerabilidade. Por exemplo, considere um aplicativo de e-mail que tenha uma vulnerabilidade criada pela executar JavaScript dentro de um cliente de e-mail. Se uma política exigida pela companhia ditar que o scripting seja desabilitado em todos os clientes de e-mail, a ameaça representada pela vulnerabilidade é substancialmente reduzida. Os administradores de sistemas
poderão ainda aplicar patches para corrigir o defeito, mas fazer isso não exigiria a mesma urgência como se o scripting estivesse habilitado.
Que vulnerabilidades ameaçam a organização?
Manter-se atualizado quanto às vulnerabilidades é um importante desafio. Conhecer os ativos específicos dentro de uma organização limita o escopo do que precisas ser rastreado, mas a amplitude e a quantidade de vulnerabilidades pode ainda ser assustadora. As vulnerabilidades não estão limitadas a uns poucos tipos de aplicativos ou a um pequeno número de fornecedores. Todos os softwares complexos não estarão livres de vulnerabilidades no futuro próximo.
Recursos de Informações de Vulnerabilidade
Para se manterem atualizados quanto às vulnerabilidades, os administradores de sistemas e profissionais afins precisam pesquisar o assunto constantemente. Para fazer isso, verifique o sistema operacional e os websites de fornecedores de aplicativo, websites de soluções de segurança da informação, grupos de correspondência de segurança, e publicações profissionais. A lista a seguir destaca alguns desses recursos:
Computer Associates CA Security Advisor: http://www3.ca.com/securityadvisor/
The SANS Institute: http://www.sans.org
SecurityFocus BugTraq: http://www.securityfocus.com
Open Source Vulnerability Database: http://www.osvdb.org/
Secunia: em http://www.secunia.com
Mitre CVE: http://www.cve.mitre.org/
US-CERT: em http://www.us-cert.gov/
Crypto-Gram: em http://www.counterpane.com/crypto-gram.html
Network World: http://www.networkworld.com
Information Week: em http://www.informationweek.com
Information Security: em http:///www.infosecuritymag.com
SC Magazine: em http://www.scmagazine.com/home/index.cfm
Journal of Computer Security: em http://www.csl.sri.com/programs/security/jcs/
Infelizmente, rastrear vulnerabilidades consome tempo e os resultados podem ser inconsistentes. Um administrador novato poderá não saber como pesquisar sobre vulnerabilidades ou poderá classificar erroneamente uma vulnerabilidade grave como sendo uma pequena. Além disso, um administrador novato poderá se inscrever para receber inúmeros alertas de e-mail e gastar muitas horas peneirando através de informações que não são relevantes para as tecnologias da organização. As informações públicas sobre vulnerabilidades poderão ser inexatas (seja intencionalmente ou não intencionalmente), assim isso precisa ser verificado. A Web provê uma riqueza de informações, mas encontrar informações objetivas quando você precisa é difícil.
Quais são os riscos das vulnerabilidades?
Os riscos associados com uma vulnerabilidade variam desde estreitamente focalizados e prontamente reparados até amplamente disseminados e difíceis de mitigar. Os riscos técnicos são, de muitas maneiras, os mais fáceis de entender e controlar. Se um servidor Web tiver uma
Os riscos de negócios são mais difíceis de avaliar. Se um aplicativo de base de dados for vulnerável a um ataque de injeção de SQL, e as informações de cliente forem furtadas, com isto afetará os negócios? Os clientes se tornarão vítimas de furto de identidade? Quanto tempo levará para os clientes resolverem as reclamações de fraude relativas ao furto? Qual é o impacto sobre a marca da companhia na mente dos clientes? Quanto custará para a empresa investigar e processar o crime?
É claro que não há regras precisas para avaliar os riscos das vulnerabilidades. Ainda, os riscos precisam ser categorizados. Um esquema baseado em categorização de risco em baixo, médio e alto é uma ferramenta eficaz de gestão (veja Figura 3.1). Com um entendimento do risco relativo, a questão seguinte enfrentada pelas organizações refere-se ao custo.
Figura 3.1: Combinando informações de inventário e de utilização de ativos, uma organização pode gerar listas priorizadas baseadas no risco.
Qual é o custo para compensar as vulnerabilidades?
O custo total para compensar vulnerabilidades é composto por vários custos constituintes:
Taxas de manutenção de software ou outros custos relativos à compra de patches Tempo do pessoal requerido para pesquisar, testar, categorizar, analisar o impacto potencial, validar a vulnerabilidade, e correlacionar com os ativos afetados Tempo do pessoal requerido para testar um patch ou nova configuração Custo de oportunidade para realocar o pessoal de operações ou desenvolvimento para aplicar patches ou reconfigurar sistemas Produtividade perdida, enquanto os aplicativos são remendados e configurados
O custo de manutenção do software é geralmente estabelecido numa base anual como uma porcentagem dos custos originais do software Os contratos de manutenção normalmente incluem suporte técnico, upgrades para novas versões, bem como patches. A manutenção é um serviço que os sistemas de produção "precisam ter", assim, de uma perspectiva de gestão da vulnerabilidade, ele pode ser gerido como um custo fixo.
Os outros custos constituintes das vulnerabilidades são variáveis e sujeitos a mais controle de gestão. Como já observado, pesquisar vulnerabilidades consome tempo e está sujeito a resultados inconsistentes. Os serviços de pesquisa de vulnerabilidade de segurança podem reduzir custos e prover informação de melhor qualidade.
O tempo requerido para remendar e configurar sistemas está diretamente correlacionado com o nível de esforço manual requerido. Os pacotes de distribuição de software podem automatizar uma parte desse processo e reduzir o tempo do pessoal dedicado a instalar patches.
Reduzindo o tempo requerido para pesquisar vulnerabilidades, melhorar a qualidade da informação sobre vulnerabilidades, e reduzir o tempo requerido para instalar patches , uma organização pode minimizar os outros custos varáveis: custos de oportunidade para o pessoal de TI e produtividade perdida para o pessoal de operações.
Melhores práticas na gestão da vulnerabilidade
A gestão da vulnerabilidade é construída sobre a integração de pessoal, processos e tecnologia. Nós vimos que as respostas ad hoc , com ênfase nos aspectos técnicos da gestão de patch , carecem de processos formais que possam ser monitorados num esforço para melhorá-las ao longo do tempo. A seção anterior deste capítulo descreveu as características das respostas geridas. Agora voltamos nossa atenção para a formalização do ciclo de vida da gestão da vulnerabilidade.
Ciclo de vida da gestão da vulnerabilidade
O ciclo de vida da gestão da vulnerabilidade é um processo que começa antes que uma vulnerabilidade específica seja conhecida e termina depois que as vulnerabilidades tiverem sido mitigadas. O modelo abrangente compreende oito fases:
Monitorar Analisar Notificar Priorizar Planejar Testar Remediar Reportar
Num mundo ideal, as políticas de ECM são bem definidas e completamente fiscalizadas. Na prática, alterações "não oficiais" na infra-estrutura de TI podem introduzir vulnerabilidades que não são refletidas nos processos e documentação de ECM. Programadores poderão introduzir um servidor de aplicativo e um portal de software para suportar seus projetos de desenvolvimento. Um grupo de consultores trabalhando numa sala de reuniões por uma semana poderá decidir que instalar um ponto de acesso sem fio é uma opção melhor do que ter cabos de rede atravancando a sala de reuniões. Os gestores da vulnerabilidade não podem depender da precisão e integralidade de documentação de ECM. Um método mais dinâmico é requerido.
Dispositivo automático de descoberta é utilizado para identificar ativos numa rede e para coletar informações sobre versão de software e nível de patch. as ferramentas de descoberta de rede podem varrer intervalos de endereços de IP, identificar sistemas operacionais, detectar dispositivos de Protocolo Simples de Gestão de Redes (SNMP), e detectar dispositivos sem fio enganosos e outros ativos numa rede. Estas ferramentas sondam ativamente sobre dispositivos na rede em vez de depender de uma base de dados sobre ativos conhecidos, assim elas são essenciais para monitorar ativos eficazmente.
A etapa de monitoramento também envolve o rastreamento de versão de novos patches e alterações de configuração. Os fornecedores são a fonte principal de patches , assim as organizações deverão monitorar os sites de suporte de seus fornecedores ou assinar um serviço de notificação. É claro que a não existência de um patch não garante que um sistema esteja livre de vulnerabilidades. Os administradores de sistemas devem monitorar regularmente as vulnerabilidades e o impacto que estas vulnerabilidades podem ter sobre a sua organização.
O monitoramento da vulnerabilidade consiste de inúmeros processos:
Pesquisa ad hoc – Como observado anteriormente, novas vulnerabilidades estão constantemente sendo descobertas. Embora as vulnerabilidades de programas populares tais como o Microsoft IE e o Linux recebam atenção na mídia, qualquer aplicativo pode conter vulnerabilidades. Vulnerabilidades têm sido encontradas em ferramentas empresariais menos amplamente utilizadas, tais como ferramentas de relatórios de inteligência de negócios, portais empresariais e servidores de aplicativo, Quaisquer ferramentas ou aplicativos utilizados dentro de uma organização deverão ser considerados suscetíveis a vulnerabilidades e monitorados em conformidade.
A base de dados de vulnerabilidades CA Security Advisor contém uma lista extensiva de vulnerabilidades. Consulte http://www.ca.com/securityadvisor para verificar as mais recentes vulnerabilidades.
Testes de rede, varredura e penetração – As organizações conscientes da segurança também testam sua infra-estrutura quanto a vulnerabilidades. Técnicas tais como varredura ( scanning ) e testes de penetração podem descobrir fraquezas nos ativos e dispositivos de segurança que protegem o perímetro da rede. Estes testes podem prover informações detalhadas, específicas para o site não disponíveis nos serviços de informações de segurança de terceiros – porém eles têm um custo. Esteja ciente de que testes de penetração e os métodos a eles relacionados são invasivos e podem interromper operações normais. Se um sistema tal como um roteador for vulnerável a uma Negação de Serviço (DoS), os testes para esta vulnerabilidade infligirão um ataque de DoS.
Monitoramento baseado em agente – Os fornecedores estão respondendo aos limites da varredura de rede e testes de penetração desenvolvendo mecanismos de monitoramento menos invasivos. Os monitores baseados em agente instalam agentes de software em ativos que podem inventariar com precisão software, patches e configurações. Esta informação é então comparada com uma base conhecida de vulnerabilidades e patches conhecidos. Este tipo de monitoramento pode identificar imediatamente as vulnerabilidades de um ativo sem interromper o serviço.
O monitoramento de vulnerabilidades demanda atenção a múltiplas fontes de informação tanto dentro como fora da organização.
Como analisar ativos e vulnerabilidades
Analisar ativos e vulnerabilidades é o segundo estágio do ciclo de vida da gestão da vulnerabilidade. Ele consiste de duas etapas:
Validar novas vulnerabilidades Correlacionar vulnerabilidades com ativos
O mundo das vulnerabilidades se espalha de muitas maneiras. Com a crescente atenção da mídia de massa para com as vulnerabilidades e ameaças, fontes gerais de notícias online podem ser a primeira informação de um profissional de TI sobre uma vulnerabilidade. Embora esta informação seja geralmente crível, as vulnerabilidades deverão ser confirmadas com especialistas em segurança, tais como Mitre CVE, US-CERT, ou fornecedores de aplicativos de segurança.
Uma vez confirmada, a vulnerabilidade deverá ser cruzada com referência a ativos conhecidos. A questão crítica é: Quais ativos são afetados? O tempo poderá ser limitado, assim a referência cruzada deverá ser gerada a partir de um repositório de ativos; este relatório não deverá ser compilado manualmente depois que a vulnerabilidade for validada.
Vulnerabilidades do Dia Zero
Conforme as vulnerabilidades são descobertas, os fornecedores se movimentam rapidamente para remendar ou prover formas de contornar, mas esta ação rápida poderá não ser suficiente. Uma preocupação significativa entre os profissionais de segurança é que uma ameaça emergirá logo após a descoberta de uma vulnerabilidade - antes que um patch esteja disponível. As vulnerabilidades que são exploradas no dia em que se tornam conhecidas têm "vulnerabilidades do dia zero dubladas".
Considere o fato de que os fornecedores precisam estudar uma vulnerabilidade, desenvolver opções para compensar o defeito, avaliar o impacto de cada opção, escolher uma estratégia de compensação, implementar e testar a solução, e então liberar o patch ou alteração da configuração. Nesse meio tempo, os atacantes podem compartilhar informações sobre a vulnerabilidade e aplicar suítes de ferramentas de malware para desenvolver vírus, vermes e outras ameaças que exploram a vulnerabilidade. Uma vez que uma vulnerabilidade se torna conhecida, a corrida entre explorar e reparar começa.
Em algum ponto durante a fase de análise, uma organização poderá determinar que a vulnerabilidade é suficientemente ameaçadora para continuar o processo. Alternativamente, os administradores de sistemas poderão determinar que a vulnerabilidade foi corrigida num patch anterior, que ela não se aplica à versão de um programa em uso, ou que o problema reportado não era, afinal, uma vulnerabilidade verdadeira.
