Esclarecimento de Firewalls de Aplicativos e Revisões do Código

 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
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
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 6.6 - 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
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
2
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
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-
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
3
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
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 6.6 - 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.
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
4
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
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.)
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
5
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
•
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
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
6
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
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.
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
7
Suplemento de Informações: Padrão de Segurança de Dados do Setor de Cartões de Pagamento - Firewalls de Aplicativos e Revisões do
Código do Requisito 6.6 (PCI DSS)
•
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.
A finalidade deste documento é fornecer informações complementares. As informações aqui fornecidas não substituem o Requisito 6,6 do Padrão de
Segurança de Dados PCI (DSS).
8