Description


Manter um programa de gerenciamento de vulnerabilidades



Baixar 1.08 Mb.
Página7/12
Encontro18.09.2019
Tamanho1.08 Mb.
1   2   3   4   5   6   7   8   9   ...   12

Manter um programa de gerenciamento de vulnerabilidades

Requisito 5: Usar e atualizar regularmente o software ou programas antivírus





Pergunta do PCI DSS Resposta:

Sim

Não

Especial*

5.1


Os softwares antivírus estão implementados em todos os sistemas normalmente afetados por softwares mal-intencionados?





     

5.1.1

Todos os programas antivírus podem detectar, remover e proteger contra todos os tipos conhecidos de softwares mal-intencionados (como vírus, trojans, worms, spywares, adwares e rootkits)?





     




5.2

Todos os software antivírus estão atualizados, funcionando ativamente e gerando logs de auditoria da seguinte forma:










  1. A política de antivírus requer a atualização do software e das definições do antivírus?





     

  1. A instalação principal do software está ativada para atualizações automáticas e varreduras periódicas?





     

  1. As atualizações automáticas e as varreduras periódicas estão ativadas?





     

  1. Todos os mecanismos de antivírus geram logs de auditoria e os logs são mantidos de acordo com o Requisito 10.7 do PCI DSS?





     



Requisito 6: Desenvolver e manter sistemas e aplicativos seguros





Pergunta do PCI DSS Resposta:

Sim

Não

Especial*

6.1

(a) Todos os componentes e softwares do sistema estão protegidos de vulnerabilidades conhecidas pois têm os patches de segurança mais recentes disponibilizados pelos fornecedores instalados?





     

(b) Os patches de segurança críticos são instalados no prazo de um mês após o lançamento?

Observação: Uma empresa talvez considere utilizar uma abordagem baseada nos riscos para priorizar suas instalações de patches. Por exemplo, ao priorizar mais a infra-estrutura crítica (como dispositivos e sistemas disponibilizados ao público e bancos de dados) em vez de dispositivos internos menos críticos, para assegurar que sistemas e dispositivos de prioridade elevada sejam resolvidos em um mês e dispositivos e sistemas menos críticos em três meses.





     

6.2

(a) Existe algum processo para identificar novas vulnerabilidades de segurança descobertas, incluindo a atribuição de uma classificação de risco para tal vulnerabilidade? (No mínimo, as vulnerabilidades críticas de alto risco devem ser classificadas como "Alto".)

Observação: As classificações de risco devem ser baseadas nas melhores práticas do setor. Por exemplo: os critérios para classificação de vulnerabilidades como "Alto" risco podem incluir uma pontuação base no CVSS igual ou superior a 4.0, um patch fornecido pelo fornecedor classificado por ele como "crítico" ou uma vulnerabilidade que afete um componente crucial do aplicativo.

A classificação de vulnerabilidades será considerada uma melhor prática até 30 de junho de 2012, quando passará a ser um requisito.





     

(b) Os processos de identificação de novas vulnerabilidades de segurança incluem o uso de fontes externas para obtenção de informações sobre vulnerabilidades de segurança?





     

6.3

  1. Os processos de desenvolvimento de software são baseados nos padrões e/ou melhores práticas do setor?





     

  1. A segurança das informações está incluída no ciclo de vida de desenvolvimento de softwares?





     

  1. Os aplicativos de software são desenvolvidos de acordo com o PCI DSS (com autenticação e logs seguros, por exemplo)?





     

  1. Os processos de desenvolvimento de softwares garantem os itens a seguir?










6.3.1

As contas, os IDs dos usuários e/ou as senhas dos aplicativos personalizados são removidos antes da ativação e distribuição dos aplicativos para os clientes?





     




6.3.2

Todas as alterações dos códigos do aplicativo personalizado são analisadas (usando processos manuais ou automatizados) antes da liberação para produção ou da distribuição para o cliente para identificar qualquer possível vulnerabilidade no código, conforme os itens a seguir?

  • As alterações dos códigos são analisadas por outras pessoas além do autor do código e por pessoas que estão cientes das técnicas de análise dos códigos e das práticas de codificação seguras?

  • As análises dos códigos asseguram que o código foi desenvolvido de acordo com as diretrizes de codificação seguras (em conformidade com o Requisito 6.5 do PCI DSS)?

  • As correções adequadas são implementadas antes da distribuição?

  • Os resultados das análises dos códigos são revisados e aprovados pela gerência antes da distribuição?

Observação: Este requisito referente às análises dos códigos se aplica a todos os códigos personalizados (internos e voltados para o público), como parte integrante do ciclo de vida de desenvolvimento do sistema. As análises dos códigos podem ser realizadas por equipes internas instruídas ou terceiros. Os aplicativos da Web também estão sujeitos a controles adicionais, se forem voltados ao público, para abordar ameaças e vulnerabilidades contínuas após a implementação, conforme definido no Requisito 6.6 do PCI DSS.





     




6.4

Os processos e procedimentos de controle de alterações foram seguidos para todas as alterações nos componentes do sistema para incluir os itens a seguir?










6.4.1

Os ambientes de desenvolvimento/teste são separados do ambiente de produção, com controle de acesso implementado para obrigar a separação?





     




6.4.2

Existe uma separação das tarefas entre a equipe atribuída aos ambientes de desenvolvimento/teste e a equipe atribuída ao ambiente de produção?





     




6.4.3

Os dados de produção (PANs ativos) não são usados para testes ou desenvolvimento?





     




6.4.4

As contas e os dados de teste são removidos antes da ativação dos sistemas de produção?





     




6.4.5

Os procedimentos de controle de alterações para implementação de patches de segurança e modificações de software estão documentados e exigem os itens 6.4.5.1 a 6.4.5.4 abaixo?





     







(b) Os itens a seguir são executados em todas as alterações?













6.4.5.1

Documentação de impacto





     




6.4.5.2

Aprovação documentada pelas partes autorizadas





     




6.4.5.3

(a) Testes de funcionalidade para verificar se a alteração não tem impacto adverso sobre a segurança do sistema





     




(b) Para alterações do código personalizado, todas as atualizações foram testadas para conformidade com o Requisito 6.5 do PCI DSS antes de serem implantadas na produção?





     




6.4.5.4

Os procedimentos de reversão estão estão preparados para cada alteração?





     




6.5

  1. Os aplicativos são desenvolvidos com base nas diretrizes de codificação seguras?

(Como o Open Web Application Security Project (OWASP) Guide, SANS CWE Top 25, CERT Secure Coding, etc.)?





     

  1. Os desenvolvedores estão bem-informados sobre as técnicas de codificação seguras?





     

  1. A prevenção contra vulnerabilidades de codificação comuns faz parte dos processos de desenvolvimento de softwares para garantir que os aplicativos não estejam vulneráveis, com a aplicação mínima dos itens a seguir?

Observação: As vulnerabilidades listadas nos itens 6.5.1 a 6.5.9 estavam atualizadas de acordo com as melhores práticas do setor, quando esta versão do PCI DSS foi publicada. No entanto, conforme as melhores práticas do setor para o gerenciamento de vulnerabilidades são atualizadas, as melhores práticas atuais precisam ser usadas para estes requisitos.










6.5.1

Falhas na injeção, particularmente na injeção SQL? (Validar a entrada para verificar se os dados do usuário não podem modificar o significado dos comandos e das queries, usar queries parametrizadas, etc.)

Também considere as falhas de injeção OS Command Injection, LDAP e Xpath, assim como outras falhas.





     




6.5.2

Estouro de buffer? (Validar os limites do buffer e truncar as strings de entrada.)





     




6.5.3

Armazenamento criptográfico não seguro? (Evitar falhas criptográficas.)





     




6.5.4

Comunicações não seguras? (Criptografar corretamente todas as comunicações autenticadas e confidenciais.)





     




6.5.5

Manuseio incorreto de erros? (Não divulgar informações através de mensagens de erro.)





     




6.5.6

Todas as vulnerabilidades classificadas como "Alto" identificadas no processo de identificação de vulnerabilidade (conforme definido no Requisito 6.2 do PCI DSS)?

Observação: Este requisito será considerado uma das melhores praticas até 30 de junho de 2012 quando passará a ser um requisito.





     




Nos aplicativos da Web e nas interfaces dos aplicativos (externos ou internos), as seguintes vulnerabilidades adicionais também são abordadas?













6.5.7

Scripting de site cruzado (XSS). (Validar todos os parâmetros antes da inclusão, utilizar uma saída de contexto confidencial, etc.)





     




6.5.8

Controle de acesso inapropriado, como referências diretas inseguras a objetos, falhas na restrição do acesso a URLs e diretórios transversais. (Autenticar os usuários e corrigir a entrada adequadamente. Não expor referências a objetos internos aos usuários.)





     




6.5.9

Falsificação de solicitações de site cruzado (CSRF). (Não responder para credenciais de autorização e tokens enviados automaticamente pelos navegadores.)





     




6.6

Para aplicativos da Web voltados para o público, as novas ameaças e vulnerabilidades são abordadas continuamente e esses aplicativos estão protegidos contra ataques conhecidos por qualquer um dos métodos a seguir?

  • Analisando os aplicativos da Web voltados para o público através de ferramentas ou métodos manuais ou automáticos de avaliação de segurança das vulnerabilidades dos aplicativos, conforme os itens a seguir:

    • Pelo menos anualmente

    • Após quaisquer alterações

    • Por meio de uma empresa especializada na segurança de aplicativos

    • Se todas as vulnerabilidades forem corrigidas

    • Se o aplicativo for reavaliado após as correções

ou

  • Instalando um firewall na camada de aplicativo da Web em todos os aplicativos da Web voltados para o público para detectar e impedir ataques baseados na Web.

Observação: "Uma empresa especializada na segurança de aplicativos" pode ser uma empresa terceirizada ou uma empresa interna, desde que os analisadores sejam especializados na segurança de aplicativos e possam demonstrar que não dependem da equipe de desenvolvimento.





     



1   2   3   4   5   6   7   8   9   ...   12


©aneste.org 2017
enviar mensagem

    Página principal