Windows Server "Longhorn" - Network Access Protection
Trust, but verify - Ronald Reagan
"Conformidade" parece ser a palavra de ordem hoje em dia em SI. Finalmente boa parte das organizações acordou para o fato de que é um exercício inútil analisar riscos, e estabelecer políticas e normas, se ninguém verifica se elas estão sendo cumpridas. Dentro das quatro grandes atividades de uma área de Segurança da Informação (Análise de Riscos, Políticas e Normas, Conformidade e Resposta a Incidentes) Conformidade é na minha opinião a mais importante, mas também a mais difícil de se fazer bem feita.
Primeiro vamos tirar um pouco da carga do termo "conformidade". Não estou aqui falando de adequação a padrões externos como SOX, HIPAA ou PCI, mas sim de adequação às políticas e normas da própria organização. Por exemplo, vamos supor que a organização tenha como norma que toda a estação deve ter um antivirus instalado, atualizado e rodando. Conformidade é basicamente verificar se esta norma está sendo cumprida, e tratar os casos de descumprimento. Se isso não for feito então a norma é morta, nada mais é do que teatro de segurança.
Antes de começar qualquer processo de conformidade uma organização tem que primeiro conhecer quais são os seus riscos (e o seu limite de tolerância), e estabelecer políticas e padrões para mitigar estes riscos. Sem normas por definição não existe conformidade, e muitas vezes ao iniciar o processo de conformidade a organização se dá conta que as normas foram escritas para nunca serem cumpridas. Por exemplo, uma vez estive em um cliente que tinha por norma aplicar patches críticos "o quanto antes". OK, mas quanto tempo é isso - um dia? uma semana? um mês? Como é que eu sei se a norma está sendo cumprida? Em um outro cliente a norma mandava aplicar o patch "imediatamente". OK, mas sem nenhum teste? Sem prazo nenhum? O trabalho de estabelecer um processo de conformidade normalmente começa por revisar todas as políticas e norma da empresa, sabendo que agora elas são para valer.
Tendo políticas e normas realistas, um processo de gerência de conformidade consiste nos seguintes passos:
1. Identificar e Classificar Ativos - A organização tem que saber quais ativos ela deve proteger, e como eles se classificam dentro de critérios de conformidade. Por exemplo, um notebook pode ter requisitos de conformidade diferentes de um desktop (por exemplo, ter que usar um software de encriptação), e um desktop por sua vez tem requisitos de conformidade diferentes de um servidor. Desktops de uma mesa de operações obedecem a normas de segurança diferentes de ATMs. O processo começa entendendo o que existe e separando os ativos nas diversas classes de conformidade.
2. Estabelecer Responsabilidade por Ativo - Se uma sistema está fora de conformidade, quem é o responsável por remediá-lo? É o usuário? Ou é o gestor da área? Em resumo, você tem que saber quem vai ser cobrado em caso de não-conformidade. Não subestime esse passo, normalmente definir responsabilidades é muito mais complicado do que parece.
3. Definir Requisitos de Conformidade - Conhecendo os ativos e os responsáveis, é necessário agora transformar as políticas e normas em itens que vão ser verificados em cada classe de ativo. Por exemplo, vamos supor que as normas digam que todos os patches críticos tem 7 dias para ser instalado em um servidor e 10 dias em notebooks. Com base nisso pode ser definido um item de verificação que checa se todos os patches críticos lançados antes deste prazo estão efetivamente instalados.
4. Medir Conformidade - Neste ponto do processo é possível ir regularmente em cada sistema e verificar se ele está de acordo com os requisitos de conformidade. Aqui é fundamental ter uma ferramenta que automatize esse passo e possa identificar a classe do ativo, fazer as verificações necessárias e reportar o resultado para o gestor.
5. Forçar Conformidade - Se um sistema não está cumprindo algum requisito, o processo de gerência de conformidade pode "remediar" este sistema corrigindo a não-conformidade, ou dependendo do nível de tolerância a risco pode excluir o sistema da rede corporativa ("quarentena"). Note que aqui entra um outro componente do processo, que é o tratamento de exceções. Por exemplo, um sistema pode ter um conflito com um patch crítico que impede que ele seja instalado dentro do prazo das normas, e é necessário ter um processo para conceder e gerenciar exceções aos requisitos.
Network Access Protection
Este é um longo preâmbulo para poder falar do Network Access Protection (NAP), outro recurso do Windows Server "Longhorn". O NAP é uma ferramenta que apóia o processo de gerência de conformidade de uma organizaçao, medindo a conformidadede todos os sistemas que entram na rede corporativa e forçando a conformidadedaqueles que não estão de acordo com algum requisito. No nosso diagrama acima, o NAP ajuda a executar os passos 4 e 5.
O NAP é composto de um lado servidor, que basicamente é um servidor RADIUS modificado chamado de Network Protection Server (NPS) que roda no Windows Server "Longhorn", e de um lado cliente que pode rodar tanto Windows XP quanto Windows Vista. Ao entrar na rede corporativa o cliente tem que enviar um "atestado de saúde" (Statement of Health ou SoH) que indica a conformidade do cliente com os requisitos de segurança da organização. O servidor NPS recebe este atestado e aprova ou não a entrada do cliente na rede. Se não for aprovado o cliente é colocado em uma "quarentena" e o próprio cliente NAP tenta fazer a remediação, instalando patches ou atualizando o antivirus por exemplo. Quando o cliente for remediado ele envia um novo atestado e pode entrar (ou voltar) à rede.
Para detectar a entrada na rede do cliente e implementar uma quarentena o NAP pode trabalhar tanto com DHCP, 802.1x ou IPsec. O DHCP é a forma mais simples mas ao mesmo tempo a menos segura - o servidor DHCP envia para o cliente fora de conformidade um endereço IP com máscara 255.255.255.255 e sem default gateway, e apenas as rotas de rede necessárias para a remediação. Com 802.1x e IPsec o sistema fica efetivamente isolado e só entra na rede se provar conformidade com os requisitos definidos pela organização. A organização pode configurar o lease do DHCP ou a reautenticação no 802.1x ou IPsec para periodicamente rechecar a conformidade dos sistemas.
Quais são os critérios de conformidade possíveis no NAP? Não existe limite aqui. O NAP está aberto a agentes de parceiros que podem implementar quaisquer verificações desejadas: fabricantes de antivirus estão fornecendo agentes para verificar se o mesmo está rodando e atualizado, empresas de consultoria oferecem agentes para conformidade com SOX, etc. O próprio agente implementa também o mecanismo de remediação, que pode ser desde uma atualização no caso do antivirus a por exemplo mudanças na registry para SOX.
Para organizações que não tem ainda um nível alto de maturidade no processo de conformidade, o NAP pode ser usado somente em modo de logging, onde a conformidade é verificada e reportada para a organização mas nenhum sistema é removido da rede. Dessa forma o NAP pode dar para a organização um retrato fiel da eficiência dos seus processos e permitir que ela se prepare para poder começar a cortar o acesso de sistemas em não-conformidade.
O NAP é um recurso extremamente poderoso, e por isso mesmo potencialmente perigoso. Uma implementação incorreta do NAP pode inadvertidamente tornar indisponível todos os sistemas de uma organização, como eu pessoalmente já vi acontecer com outras soluções similares. Por isso é fundamental entender que o NAP não é uma panacéia, mas somente uma ferramenta que automatiza parte de um processo de conformidade. Uma ferramenta extremamente útil, sem dúvida, mas que não irá agregar nada se não vier acompanhada de um processo de conformidade.
O lado servidor do NAP faz parte do Windows Server "Longhorn", que vai ser lançado no segundo semestre deste ano, junto com clientes para o sistema Windows Vista e Windows XP. Este recurso faz parte do sistema operacional e nenhuma licença adicional é necessária. Mais informações sobre o NAP estão disponíveis no nosso site.