Suplemento de Informações: Esclarecimento de Firewalls de Aplicativos e Revisões do Código do Requisito 6.6

Transcrição

1 Padrão: Padrão de Segurança de Dados (DSS) Requisito: 6.6 Data: Fevereiro de 2008 Suplemento de Informações: Esclarecimento de Firewalls de Aplicativos e Revisões do Código do Requisito 6.6 Data de liberação: 15/04/2008

2 Geral O Requisito DSS PCI 6.6 proporciona duas opções voltadas para resolver ameaças comuns aos dados do portador do cartão e garantir que o acesso a aplicativos da Web a partir de ambientes não confiáveis seja inspecionado de cima a baixo. Os detalhes de como atender a esse requisito dependem da implementação específica de suporte de determinado aplicativo. Análises forenses do comprometimento dos dados do portador do cartão demonstraram que aplicativos da Web são freqüentemente o ponto inicial de ataque aos dados do portador do cartão, por meio de injeção de SQL em particular. A finalidade do Requisito 6.6 é garantir que aplicativos da Web expostos na Internet pública sejam protegidos contra os tipos mais comuns de entradas maliciosas. Existe uma grande quantidade de informações públicas disponíveis em relação a vulnerabilidades de aplicativos na Web. As vulnerabilidades mínimas a considerar estão descritas no Requisito 6.5. (Consulte a seção de Referências de outras fontes de informações sobre testes de aplicativos na Web.) A implementação correta das duas opções proporcionará a melhor defesa em várias camadas. O SSC PCI reconhece que o custo e complexidade operacional da implementação das duas opções pode não ser praticável. Além disso, uma das opções poderá não ser possível em algumas situações (se não houver acesso ao código-fonte, por exemplo). Mas deve ser possível aplicar ao menos uma das alternativas descritas neste artigo, e a implementação correta poderá atender à intenção do requisito. Este documento orienta como auxiliar a determinar a melhor opção, o que pode variar dependendo dos produtos em uso, como uma organização terceiriza ou desenvolve seus aplicativos para Web, e outros fatores no ambiente. Requisito Opção 1 Revisões do Código do Aplicativo A opção de revisão do código do aplicativo não exige necessariamente uma revisão manual do código-fonte. Lembrando que o objetivo do Requisito 6.6 é impedir a exploração de vulnerabilidades comuns (como as listadas no Requisito 6.5), várias soluções possíveis poderão ser consideradas. Elas são dinâmicas e proativas, exigindo a iniciação específica de um processo manual ou automatizado. Corretamente implementadas, uma ou mais dessas quatro alternativas podem atender à intenção da Opção 1 e proporcionar o nível mínimo de proteção contra ameaças comuns a aplicativos na Web: 1. Revisão manual do código-fonte do aplicativo 2. Uso adequado de ferramentas de análise automática (varredura) do código-fonte do aplicativo 3. Avaliação manual de vulnerabilidade de segurança de aplicativo na Web 4. Uso adequado de ferramentas de avaliação automática (varredura) de vulnerabilidade de segurança de aplicativo na Web 2

3 Todas elas devem ser criadas para testar a presença de vulnerabilidades de aplicativo na Web conforme indicado na seção Geral acima. Observe que uma avaliação de vulnerabilidade simplesmente identifica e informa as vulnerabilidades, sempre que um teste de penetração tente explorar as vulnerabilidades, para determinar se é possível um acesso não autorizado ou outra atividade maliciosa. As revisões/avaliações manuais podem ser realizadas por um recurso interno qualificado, ou por um terceiro qualificado. Em todos os casos, o(s) indivíduo(s) deve(m) ter as habilidades e a experiência adequadas para compreender o código-fonte e/ou aplicativo da Web, saber como avaliar cada um por suas vulnerabilidades, e compreender as descobertas. De forma semelhante, os indivíduos que usam ferramentas automáticas deverão ter as habilidades e o conhecimento para configurar corretamente a ferramenta e o ambiente de teste, utilizar a ferramenta e avaliar os resultados. Se forem utilizados recursos internos, eles deverão estar organizacionalmente separados da gerência do aplicativo sendo testado. Por exemplo, a equipe que escreveu o software não deve realizar a revisão ou avaliação final nem verificar se o código está protegido. Existem várias maneiras de realizar uma revisão de código ou avaliação do aplicativo que forneça a mesma (ou melhor) proteção fornecida por um firewall de aplicativos (discutida abaixo como a Opção 2). Dois exemplos que podem atender à intenção da primeira opção são: 1. Uma organização tem implementado, como parte de seu ciclo de vida de desenvolvimento de software (SDLC), um processo onde o código-fonte do aplicativo da Web sofre uma revisão independente de segurança. A revisão de segurança deverá consistir do exame dos aplicativos para controles que tratem de vulnerabilidades comuns de aplicativos da Web. Essas revisões de código poderão ser implementadas como processos manuais ou automáticos. 2. O uso de um processo manual ou de ferramentas especializadas para testar a presença de vulnerabilidades e defeitos expostos ao executar um aplicativo da Web. Essa abordagem envolve a criação e envio ao aplicativo de entradas maliciosas ou fora do padrão, simulando um ataque. As respostas a essa entrada serão examinadas em busca de indicações de que o aplicativo possa ser vulnerável a determinados ataques. As revisões ou avaliações deverão ser incorporadas no SDLC e realizadas antes do aplicativo ser implementado no ambiente de produção. O SDLC deverá incorporar a segurança de informações em todo o ambiente, conforme o Requisito 6.3. Os processos de controle de alterações deverão garantir que os desenvolvedores de software não consigam ignorar a etapa de revisão/avaliação de código e implementar o novo software diretamente no ambiente de produção. Os processos de controle de alterações também deverão reforçar a correção e novos testes de vulnerabilidades antes da implementação. Embora o endosso/aprovação final dos resultados da revisão/varredura devam ser dados por uma organização independente, recomenda-se que revisões e varreduras também sejam realizadas o mais cedo possível no processo de desenvolvimento. Deve- 3

4 se disponibilizar ferramentas aos desenvolvedores de software e elas devem ser integradas em seu conjunto de desenvolvimento na medida do possível. Os fornecedores poderão incorporar recursos de varredura de código ou avaliação de vulnerabilidade nos produtos com outros objetivos, como validar a conformidade com as melhores práticas de arquitetura relativa a determinado idioma. Ao avaliar essas ferramentas é importante confirmar a capacidade da ferramenta de testar por vulnerabilidades de aplicativos comuns da Web antes de supor que possa ser usada para atender ao previsto no Requisito 6.6. Além disso, para enfrentar novas ameaças que surgem, as ferramentas devem ser capazes de incorporar novas regras de análise. Quem realizar revisões ou avaliações manuais deve estar atualizado com as tendências no setor para garantir que suas habilidades de avaliação ou teste continuem capazes de enfrentar as novas vulnerabilidades. Requisito Opção 2 Firewalls de Aplicativos No contexto do Requisito 6.6, um firewall de aplicativo é um firewall de aplicativo da Web (WAF), que é um ponto de aplicação da política de segurança posicionado entre um aplicativo da Web e o ponto final do cliente. Esse recurso pode ser implementado em software ou hardware, ser executado em um dispositivo de um equipamento ou em um servidor típico executando um sistema operacional comum. Ele pode ser um dispositivo independente ou estar integrado a outros componentes na rede. Os firewalls típicos de rede são implementados no perímetro da rede ou entre segmentos (zonas) da rede e são a primeira linha de defesa contra muitos tipos de ataques. Mas eles devem permitir que as mensagens alcancem os aplicativos da Web que uma organização decidir expor na Internet pública. Os firewalls de rede geralmente não são projetados para inspecionar, avaliar ou reagir com as partes de um (pacote) de mensagem do Protocolo Internet (IP) consumido por aplicativos da Web, e assim os aplicativos públicos freqüentemente recebem uma entrada insuspeita. Como resultado, é criado um novo perímetro de segurança lógica o próprio aplicativo da Web e as melhores práticas de segurança exigem que as mensagens sejam inspecionadas quando cruzam de um ambiente não confiável para um ambiente confiável. Existem muitos ataques conhecidos contra aplicativos da Web e, como todos sabemos, os aplicativos da Web nem sempre são projetados e escritos para defender-se contra esses ataques. Adicionada ao risco está a disponibilidade desses aplicativos para praticamente qualquer um em uma conexão na Internet. Os WAFs são projetados para inspecionar o conteúdo da camada de aplicativos de um pacote IP, além do conteúdo de qualquer outra camada que possa ser usada para atacar um aplicativo da Web. Mas deve-se observar que o Requisito 6.6 não pretende introduzir controles redundantes. Se o conteúdo de um pacote IP é inspecionado adequadamente (ou seja, fornecendo uma proteção equivalente) por firewalls de rede, proxies ou outros componentes não necessitam ser inspecionados novamente por um WAF. 4

5 A estrutura dos pacotes IP segue um modelo em camadas, no qual cada camada contém informações definidas nas quais atuam nós ou componentes da rede específicos (físicos ou baseados em software) suportando o fluxo de informações na Internet ou intranet. A camada com o conteúdo processado pelo aplicativo é chamada de camada de aplicativos. Cada vez mais, a tecnologia WAF está integrada em soluções que incluem outras funções como a filtragem de pacotes, proxy, terminação SSL, equilíbrio de carga, cache de objetos etc. Esses dispositivos são comercializados diversificadamente, como firewalls, gateways de aplicativos, sistema de envio de aplicativos, proxy seguro ou outras descrições. É importante compreender plenamente os recursos de inspeção de dados de cada produto para determinar se o produto pode satisfazer o objetivo do Requisito 6.6. Observe que a conformidade não é garantida pela simples implementação de um produto com os recursos descritos neste artigo. O posicionamento, configuração, administração e monitoramento corretos também são aspectos importantes de uma solução conforme. Implementar um WAF é uma opção para atender ao Requisito 6.6 e não elimina a necessidade de um processo protegido de desenvolvimento de software (Requisito 6.3). Recursos recomendados Um firewall de aplicativo da Web deve ser capaz de: Atender a todos os requisitos aplicáveis do DSS PCI pertinentes a componentes do sistema no ambiente de dados do portador do cartão. Reagir apropriadamente (definida por regras ou políticas ativas) a ameaças contra vulnerabilidades relevantes assim que forem identificadas, no mínimo, nos OWASP Top Ten e/ou Requisito 6.5 do DSS PCI. Inspecionar a entrada do aplicativo da Web e responder (permitir, bloquear e/ou alertar) com base na política ou regras ativas, e registrar as ações tomadas. Impedir o vazamento de dados, ou seja, ter a capacidade de inspecionar a saída do aplicativo da Web e responder (permitir, bloquear, mascarar e/ou alertar) com base na política ou regras ativas, e registrar as ações tomadas. Reforçar os modelos de segurança positivos e negativos. O modelo positivo ( lista branca ) define o comportamento, entrada, intervalos de dados etc. que sejam aceitáveis, permitidos, e impedir os que não sejam. O modelo negativo ( lista negra ) define o que NÃO é permitido; as mensagens correspondentes a essas assinaturas bloqueadas e o tráfego não correspondente às assinaturas (fora da lista negra ) é permitido. Inspecionar tanto o conteúdo da página da Web, como a Linguagem de Marcação de Hipertexto (HTML), HTML Dinâmico (DHTML) e Folhas de Estilo em Cascata (CSS), e os protocolos subjacentes que fornecem conteúdo, como o Protocolo de Transporte de Hipertexto (HTTP) e o Protocolo de Transporte de Hipertexto sobre SSL (HTTPS). (Além do SSL, o HTTPS inclui o Protocolo de Transporte de Hipertexto sobre TLS.) 5

6 Inspecionar as mensagens dos serviços da Web, se esses serviços são expostos na Internet pública. Geralmente isso inclui o Protocolo de Acesso a Objetos Simples (SOAP) e a Linguagem de Marcação Extensível (XML), tanto modelos orientados para documentos quanto para RPC, além do HTTP. Inspecionar qualquer protocolo (proprietário ou padronizado) ou construto de dados (proprietário ou padronizado) usado para transmitir dados para ou de um aplicativo da Web, quando tais protocolos ou dados não sejam inspecionados de outra forma em outro ponto no fluxo da mensagem. Observação: Os protocolos proprietários apresentam desafios aos produtos atuais de firewall de aplicativo, e poderão ser necessárias alterações personalizadas. Se as mensagens de um aplicativo não seguirem protocolos e construtos de dados padronizados, poderá não ser razoável solicitar que um firewall de aplicativo inspecione esse fluxo de mensagem específico. Nesses casos, implementar a opção de avaliação de vulnerabilidade/revisão de código do Requisito 6.6 será provavelmente a melhor opção. Defender contra ameaças que atingem o WAF. Suporte a SSL e/ou a terminação TLS, ou estar posicionado e modo que tais transmissões criptografadas sejam decodificadas antes de serem inspecionadas pelo WAF. Os fluxos de dados criptografados não podem ser inspecionados a menos que o SSL seja encerrado antes do mecanismo de inspeção. Recursos adicionais recomendados para determinados ambientes Evitar e/ou detectar adulteração de token de sessão, por exemplo, criptografando cookies de sessão, campos de formulário ocultos ou outros elementos de dados usados para manutenção do estado da sessão. Receber e aplicar automaticamente atualizações de assinatura dinâmica de um fornecedor ou outra fonte. Na ausência desse recurso, devem existir procedimentos implantados para garantir a atualização freqüente das assinaturas do WAF ou outras configurações. Aberto na falha (um dispositivo que falhou permite que o tráfego passe sem ser inspecionado) ou fechado na falha (um dispositivo que falhou bloqueia todo o tráfego), dependendo da política ativa. Observação: Permitir que um WAF abra na falha deve ser avaliado cuidadosamente quanto ao risco de expor aplicativo(s) desprotegidos na Web à Internet pública. Um modo de bypass, no qual absolutamente nenhuma modificação é feita no tráfego que passa por ele, poderá ser aplicado em algumas circunstâncias. (Mesmo no modo de falha na abertura, alguns WAFs adicionam cabeçalhos de rastreamento, apagam o código HTML que consideram que viole os padrões, ou realizam outras ações. Isso pode ter impacto negativo nos esforços de solução de problemas.) Em determinados ambientes, o WAF deverá ser compatível com certificados cliente da Camada de Soquetes Protegidos (SSL) e com a autenticação de clientes proxying via certificados. Muitos aplicativos Web modernos usam 6

7 certificados SSL clientes para identificar os usuários finais. Sem essa compatibilidade, esses aplicativos não podem residir por trás de um firewall de aplicativos. Muitos firewalls de aplicativo modernos irão integrar-se com o Lightweight Directory Access Protocol ou outros diretórios de usuário e podem até realizar a autenticação inicial em nome do aplicativo subjacente. Alguns aplicativos de comércio eletrônico podem exigir suporte ao armazenamento de chaves de hardware FIPS. Se essa for uma consideração em seu ambiente, verifique se o fornecedor do WAF suporta esse requisito em um de seus sistemas e saiba que esse recurso poderá aumentar drasticamente o custo da solução. Considerações adicionais o Embora os WAFs possam proteger contra muitas ameaças à segurança, eles também podem expor problemas técnicos em uma infra-estrutura. Verifique as seguintes questões que poderão impedir uma implementação bem-sucedida: Sites que dependem de URLs, cookies ou cabeçalhos incomuns podem exigir um ajuste especial. Os WAFs freqüentemente limitam o tamanho máximo desses componentes. Além disso, as assinaturas que buscam poderão excluir strings específicas percebidas como exploradoras que de fato podem ser perfeitamente válidas para determinado aplicativo. O conteúdo não conforme com o padrão dos RFCs HTML/HTTP ou que seja incomum de outra forma, também poderá ser bloqueado sem ajuste dos filtros padrão. Isso poderá incluir qualquer coisa, desde uploads de arquivos extremamente grandes até conteúdo enviado com idiomas ou conjuntos de caracteres estrangeiros. DHTML, JavaScript assíncrono e XML (AJAX), e outras tecnologias dinâmicas poderão exigir considerações, testes e ajustes especiais. Esses aplicativos às vezes supõem que têm acesso a um site na Web de uma forma que é considerada maliciosa por um WAF. Os aplicativos que exigem informações sobre a sessão de rede subjacente, como endereço IP do cliente, poderão exigir modificação se o WAF atuar como um proxy reverso. Geralmente esses WAFs inserem informações do lado do cliente em um cabeçalho HTTP, que os aplicativos existentes podem não esperar. Considerações importantes As revisões de código e as avaliações de vulnerabilidade de aplicativos descritas neste documento deverão ser realizadas antes de implementar o aplicativo em produção. Se for considerado um WAF aberto em falha ou em modo bypass, deve-se estabelecer procedimentos e critérios específicos definindo ouso desses modos de alto risco, antes da implementação. Os aplicativos da Web não estão protegidos nesses enquanto esses modos estão ativos, e longos períodos de uso não são recomendados. 7

8 O impacto de alterações no firewall do aplicativo da Web deve ser avaliado quanto ao impacto em potencial para aplicativos da Web relevantes, e viceversa. Informar o período e o escopo da produção de alterações do firewall de aplicativos da Web a todas as partes afetadas na organização. Respeitar todas as políticas e procedimentos, incluindo controle de alterações, continuidade dos negócios e recuperação de desastres. Alterações no ambiente de produção deverão ocorrer durante uma janela de manutenção monitorada. Fontes adicionais de informação Essa lista é fornecida como ponto de partida para mais informações sobre a segurança de aplicativos da Web. Top Ten do OWASP Referência de contramedidas OWASP FAQ de Segurança de Aplicativos OWASP Build Security In (Deptº de Sgg Nacional dos EUA, Divisão Nacional de Sgg Cibernética) Scanners de Vulnerabilidade de Aplicativos da Web (Instituto nacional de Padrões e Tecnologia) Critérios de Avaliação de Firewall de Aplicativos da Web (Consórcio de Segurança de Aplicativos da Web) Sobre o PCI Security Standards Council A missão do PCI Security Standards Council é aprimorar a segurança das contas de pagamento estimulando a educação e a conscientização do Padrão de Segurança de Dados PCI e de outros padrões que aumentem a segurança dos dados de pagamento. O PCI Security Standards Council foi formado pelas principais empresas de cartão de crédito, American Express, Discover Financial Services, JCB International, MasterCard Worldwide e Visa Inc. para proporcionar um fórum transparente no qual todos os interessados possam participar do contínuo desenvolvimento, aprimoramento e disseminação do Padrão de Segurança de Dados PCI (DSS), Requisitos do sistema do dispositivo de entrada PIN (PED) e o Padrão de Segurança de Dados de Aplicativos de Pagamento (PA-DSS). O comércio, bancos, financeiras e pontos de venda de varejo são estimulados a associar-se como Organizações Participantes. 8