Aceitação de Critérios de Segurança

Ao final do desenvolvimento e da implementação da aplicação ocorrerá uma fase de testes de aceitação funcional pelo usuário.

O nível de segurança da aplicação agora em fase de entrega deve ser verificada por um processo de testes de avaliação dos controles de segurança que foram adotados, obtendo-se um registro formal de evidências de que os controles funcionarão em caso de ataques.

Os testes de avaliação da segurança podem incluir desde a análise manual de especialistas em segurança, que podem inclusive executar testes de penetração em variados níveis, até passar pela automação de testes de vulnerabilidades pelo uso de mecanismos de testes estáticos e dinâmicos, como o Sistema RedeSegura.

Com certa freqüência aplicações web são construídas a partir de um conjunto complexo de tecnologias adotadas na integração de objetos e módulos diversos, especialmente para criar a interface com o usuário orientando o fluxo do negócio e manuseio dos dados.

Mesmo que a segurança tenha sido considerada desde o inicio do desenvolvimento erros podem ser introduzidos no seu curso de entrega e implementação, o que acaba produzindo brechas na segurança. Verificar o nível de segurança da aplicação web em todo seu ciclo de vida é, portanto, essencial como recomendação de melhor prática.

Para mitigar riscos de ataque recomendamos que o monitoramento de vulnerabilidades seja implementado em todo o ciclo de vida da aplicação web, iniciando com o ciclo de entrega e homologação do desenvolvimento, e seguindo enquanto perdurar o período de sua utilização em produção.

Etapas de Design e Implementação

uml-diagram-development_1Uma vez que as necessidades de segurança e os riscos tenham sido identificados, a segurança da aplicação web pode definir precisamente quais mecanismos assegurarão que as metas de segurança serão alcançadas em resposta às ameaças, como autenticação, controles de acesso, proteção contra ataques de injeção de comandos, etc.

Um documento deve descrever em detalhes estes mecanismos de proteção, que devem ser desenhados de acordo com o princípio de “defesa em profundidade”, em que a primeira linha de defesa que falhar ou for atacada é substituída por uma segunda linha, ou mesmo por uma terceira.

Passando pelo desenho da aplicação e mapeamento de necessidades de segurança e de riscos, chegamos então à fase de implementação, em que os desenvolvedores geram os códigos de interface e integram objetos que a compõem.

É imperativo que todos aqueles envolvidos na fase de implementação sejam treinados ou ao menos devidamente suportados por especialistas em desenvolvimento de aplicações seguras. Adicionalmente, algumas ferramentas devem ser dadas a equipe de trabalho:

  • Documento de referência contendo as melhores práticas para desenvolvimento de aplicações seguras.
  • Um check-list para assegurar que nada foi negligenciado ou esquecido durante o ciclo de desenvolvimento;
  • Um framework de segurança para evitar que a recriação de mecanismos básicos de segurança internos ou externos acabem produzindo vulnerabilidades ou códigos maliciosos.

Também durante esta fase, a equipe de desenvolvimento pode consultar especialistas para validar os mecanismos de segurança que foram desenvolvidos. Podem também consultar as referências do OWASP Guide Project para orientar-se sobre a construção segura de aplicações e web services.

Muitas destas referências se fazem constar nos relatórios de avaliação de segurança obtidos após a execução dos testes de vulnerabilidades do Sistema RedeSegura.

Requerimentos do Negócio e Avaliação de Risco

diagrama-design-de-website-seguroÉ essencial que o desenvolvedor procure identificar aspectos que possam causar impacto de segurança para o negócio, considerando a operação através do ambiente em que se insere a aplicação web, como a presença e exposição pela internet, a sensibilidade dos dados e a acessibilidade 24 horas, a capacidade de rastreamento do fluxo de navegação, a responsabilidade legal, e perfil do grupo de usuários, etc.

A ajuda de especialistas da área da segurança é útil neste momento para identificar os riscos e orientar as ações de melhorias necessárias.

A Open Web Application Security Project (OWASP) fala da importância de se adotar uma metodologia para modelagem de risco (Threat Risc Modeling) desde a fase de desenho da aplicação web, evitando assim desperdício de tempo, dinheiro, recursos e de controles inúteis, para que haja foco no mapeamento dos riscos reais.

Um levantamento de custos também deve ser considerado usando algum método semelhante ao que é sugerido pelo framework da OpenSAMM (Software Assurance Maturity Model), que fornecerá uma estimativa de custos durante os diferentes estágios do ciclo de desenvolvimento da aplicação web.

Os riscos podem ser então avaliados para antecipar ameaças relacionadas com o contexto e as funcionalidades da aplicação web. A partir desta prática pode-se assegurar que todos os riscos sejam levados em conta desde a definição dos requisitos, o que torna possível encontrar soluções e medidas de segurança baseadas na viabilidade e na identificação de riscos potenciais.

A modelagem de ricos e ameaças é considerada por alguns especialistas como sendo tão ou mais importante que o uso de ferramentas de monitoramento de riscos, mas isso não dispensa seu uso.

Treinamento e Certificação da GSI

Alcançar o nível necessário de entendimento e de especialização em segurança dos profissionais envolvidos num projeto de desenvolvimento é o primeiro passo para a adoção de um programa eficiente de melhoria da segurança das aplicações web. O desenvolvimento destas competências nos agentes do projeto reduzirá significativamente os riscos na entrega.

Cada membro do processo deve ser treinado nas medidas básicas de segurança em conformidade com os requisitos da política de Gestão da Segurança da Informação da empresa.

Cada participante envolvido num projeto de desenvolvimento de aplicações web é importante, mas vamos citar pelo menos três que consideramos os mais críticos:


» Os Contratantes divlar

Os responsáveis pela especificação e contratação do projeto geralmente negligenciam a segurança em nome de seu foco nos requerimentos funcionais do negócio, nos custos e no curto prazo de entrega.

Eles deveriam ser capazes de endereçar os requisitos mínimos de segurança que serão exigidos dos desenvolvedores, e poder medi-los na fase de aceitação da entrega.


» Os Desenvolvedoresdivlar

Estes normalmente orientam seu trabalho para atender aqueles requisitos funcionais e contratuais, enquanto consideram a Segurança como uma responsabilidade posterior da área da segurança da informação, ao invés de ser um aspecto importante do “Software Development Life Cycle” (SDLC). Isso é um erro grave.

Muitas vulnerabilidades exploráveis resultam da falta de adoção de critérios de segurança pelos desenvolvedores desde a especificação de requisitos, passando pelo desenho da aplicação, até sua implementação ou integração com outros sistemas. Muito disso se deve a uma lacuna generalizada nesta área de conhecimento do desenvolvedor.


» Os Profissionais da Segurançadivlar

Na maioria das vezes são profissionais com formação e experiência em administração de sistemas e em arquitetura da infraestrutura, e a falta de conhecimento na área de segurança de software os leva a acreditar que administração de acesso de usuários e demais controles de segurança de rede e infraestrutura serão suficientes.

Isso pode levá-los a adotar medidas que até podem identificar falhas, mas, por falta de conhecimento específico, não conduzirá a uma correta avaliação do problema, como ocorre com um alarme que é considerado um falso positivo, e daí, o processo de segurança falha na orientação da ação corretiva que eliminaria os riscos de um eventual ataque.


Cada um destes profissionais deve ser treinado para conhecer as práticas de segurança exigidas de um projeto de desenvolvimento de aplicações web, cada um em seu nível de exigência de atuação.

É importante também monitorar a capacidade do desenvolvedor em produzir aplicações mais seguras, e de manter-se informado de novas formas de ataque sobre as aplicações web.

Uso de Sistema para Gerenciar um Processo

Em muitos casos será importante monitorar o risco das operações de negócio a partir de aplicações web de modo preventivo, centralizado e continuado. Pode então ser necessário contratar competências especializadas complementares às existentes na empresa, visando antecipar-se ao risco de ataques de agentes maliciosos.

Estes casos se confirmam quando as seguintes considerações se tornam relevantes:

  • A empresa tem aplicações web cuja seguraça precisa ser avaliada com alguma regularidade;
  • As aplicações têm relativa complexidade, e certa freqüência de manutenção, atualização e/ou melhorias de software e servidores web;
  • As aplicações são desenvolvidas e mantidas por diferentes equipes, internas ou terceirizadas;
  • A empresa precisa atender a regulamentações como PCI-DSS, SOX, ISO, ou HIPPA;
  • A empresa quer manter um processo de Gerenciamento de Segurança sobre as Aplicações e os seus Servidores;
  • A empresa não dispõe de competências internas especializadas em segurança de software;
  • A empresa deseja avançar em seu Grau de Maturidade em Gestão da Segurança de TI;

A figura a seguir ilustra como é o cenário de uso do Sistema RedeSegura, para satisfazer as questões anteriores:

sistema de gestao de processo - metodologias sastdast 

Por se tratar de um processo, há a definição prévia de agentes com papéis definidos, e cada um em sua área de competência (Grupo de Segurança de Software – SSG).

O Gestor responsável pela Segurança da Informação deve notar que agora se trata de uma Sistema para Gerenciar um Processo de melhoria contínua da segurança, em que a tarefa de “webscanning” de vulnerabilidades é apenas uma das etapas, executada agora de forma centralizada, automatizada, suportada por especialistas em segurança de software, com medição e acompanhamento de indicadores, e registro histórico dos testes.

Este processo de gestão baseia-se na metodologia Dynamic Application Security Test (DAST), que com o uso do Sistema RedeSegura oferece muito mais benefícios ao Gestor da Segurança, se comparado à prática ocasional da metodologia Static Application Security Test (SAST).

Por outro lado, a prática de uso conjunto das duas metodologias (SAST e DAST) tem trazido comprovadamente resultados muito positivos e consistentes para as empresas que as tem adotado. Como o Sistema RedeSegura está preparado para suportar as duas metodologias simultaneamente em qualquer ambiente, recomendamos fortemente seu uso aos Gestores que buscam esta oferta de valor. 

Se este cenário parece ser o mais indicado para sua empresa, consulte nossa área comercial para obter mais informações sobre como contratar o Sistema RedeSegura e implantar seu processo de Gerenciamento de Vulnerabilidades sobre Aplicações e Servidores Web.

Uso de Ferramentas para Webscanning

Esta opção tem sido escolhida por muitas empresas por ser mais tradicional, mas com o aumento da demanda por aplicações web e dos riscos de ataques a partir de suas falhas de segurança, a eficiência desta alternativa tem se reduzido a alguns poucos cenários. Veja se este é o seu caso, considerando:

  • A empresa tem uma pequena quantidade de aplicações web?
  • O ambiente de servidores é de baixa complexidade (próprio ou terceiro)?;
  • A freqüência em que ocorrem mudanças na aplicação web e seus servidores é baixa?
  • Temos competências (profissionais certificados) na área de segurança de software?
  • Os testes de segurança serão reativos, por incidente, ou há um plano para uso preventivo?
  • A segurança da aplicação será avaliada apenas no ambiente de homologação?

A figura a seguir ilustra este cenário com outras questões relevantes quedevem ser consideradas pelos Gestores responsáveis pela Segurança:

ferramentas_para_webscanning_1

O uso de uma ferramenta de “webscanning” de modo estático fica restrito normalmente a execução de uma tarefa de avaliação pontual, que dependerá da disponibilidade de seu executor, da sua capacidade de analisar resultados e conduzir ações de melhorias, e posteriormente avaliar novamente os resultados finais.

Esta metodologia é também conhecida como Static Application Security Test (SAST), e pode funcionar relativamente bem no ambiente de homologação das entregas da equipe de desenvolvimento (QA).

Quando a infraestrutura tornar-se mais complexa com mais servidores, e em ambientes distintos de homologação e produção, ou um número maior de aplicações web, a eficiência dos testes estáticos de segurança é questionável.

O primeiro impulso do Gestor pode ser adquirir mais ferramentas de “webscanning”, e mais profissionais capacitados para o trabalho, mas aí surgem outros fatores relevantes:

ferramentas_para_webscanning_2

A eficiência e o desempenho dos testes dependerão diretamente da disponibilidade de competências individuais, e, além disso, pode não prevenir riscos de forma eficaz, na medida em que, ao atuar reativamente sobre incidentes, estes já podem ter causado impacto significativo ao negócio.

Conlui-se que o método opracional conhecido como Static Application Security Test (SAST) aplicado com uma ferramenta de “webscanning” oferece capacidade limitada de gestão sobre as tarefas recorrentes de avaliação da segurança, mas atenderá relativamente bem os casos de testes de QA de Segurança no desenvolvimento, assim como recurso complementar para uma análise ocasional de incidentes.

Para os casos de testes estáticos a partir de uma ferramenta de webscanning, recomendaremos o uso do Software N-Stalker WAS, mas nunca sem também recomendar que seja avaliado o uso do Sistema RedeSegura, que atenderá também a metodologias de testes dinamicamente, o que permite a implantação de um processo gerenciável de vulnerabilidades.

Qual produto N-Stalker devo escolher?

Faremos aqui algumas considerações importantes para orientar a sua escolha pela solução mais adequada para o projeto de segurança do ambiente das aplicações web de sua empresa.

Em primeiro lugar, esteja certo que em qualquer dos casos sua empresa adotará soluções N-Stalker, atualmente a melhor tecnologia disponível para avaliar a segurança em todo o ciclo de vida do desenvolvimento das aplicações web.

A sua escolha dependerá apenas de fatores relacionados com a estrutura da sua empresa, a complexidade do seu ambiente, grau de criticidade, e a quantidade de aplicações a serem avaliadas, e, evidentemente, com o grau de maturidade em Gestão da Segurança de Software que se deseja manter ou alcançar com este projeto. Vejamos as questões seguintes:

  • Qual a importância do uso das aplicações web para o resultado do negócio?
  • Pode-se mensurar o impacto que um ataque virtual causaria ao negócio?
  • Como garantir que não há o risco de ataque pela aplicação web hoje? E no futuro?

Também é importante qualificar o tipo de serviço atendido pela aplicação web, tanto aquelas acessadas a partir da internet, como pela rede corporativa (intranet):

  • Site institucional da corporação;
  • Aplicação financeira, home banking, ou home broker;
  • Website com tecnologia de e-Commerce;
  • Serviços públicos diversos;
  • Sistemas de apoio a decisão, ou de fluxo de negócio com parceiros;
  • Sistemas corporativos: ERP, Sistemas de RH, Consultas a base de dados, etc.

Qualificar as aplicações web ajuda a definir o grau de sua importância para o seu negócio, e a seguir uma sábia recomendação: “para mitigar o risco esteja um passo à frente das ameaças”… (Gartner)

As Melhores Práticas internacionais recomendarão, entre outras iniciativas para obter e manter aplicações web mais seguras, o uso de ferramentas de teste “Black Box” como o N-Stalker ou o Sistema RedeSegura, como sendo a melhor solução para obter resultados imediatas sobre a avaliação dos niveis de risco apresentado pelas aplicações.

A escolha entre as duas ofertas com tecnologia N-Stalker dependerá de outros fatores que abordamos a seguir, considerando o cenário do ambiente web, e a metodologia mais adequada ao seu projeto:

  • Opção 1: Uso de uma Ferramenta para “webscanning” de vulnerabilidades, ou;

  • Opção 2: Uso de um Sistema para Gerenciar um Processo de Melhoria da Segurança.

Se preferir, você pode também assistir ao nosso vídeo-4 no menu de vídeo-apresentações, e saberá mais rapidamente como abordamos este comparativo.

 

Recomendações de Segurança ISO/IEC

iso-common-criteriaO grau de segurança de uma aplicação está intimamente ligado à sua capacidade de resistir aos ataques promovidos por agentes maliciosos sobre seu ambiente de produção.

Para obter um alto grau de segurança, é necessário adotar critérios robustos de segurança em todo o ciclo de vida do desenvolvimento da aplicação. Tal feito se alcança apenas com a adoção integrada de ferramentas e de processos igualmente robustos para sustentar o grau de segurança que se pretende atingir, e manter.

O Gerenciamento de Vulnerabilidades em Aplicações Web é úm processo preventivo de melhoria contínua que oferece suporte para sustentar suas melhores práticas de Gestão da Segurança da Informação, que podem ser baseadas nas práticas internacionais ISO/IEC (International Organization for Standardization/International Electrotechnical Commission):

  • ISO/IEC-27001:  Norma que trata de técnicas para implantação de um SGSI (Sistema de Gestão da Segurança da Informação)
  • ISO/IEC-27002:  Complementa a ISO 27001. Lista os objetivos de controle para o SGSI e recomenda um conjunto de especificações e melhores práticas para iniciar, implementar e manter o SGSI. Trata-se da nova denominação da ISO/IEC 17799:2000, lançada em 2005 e renomeada oficialmente como sua substituta em 2007.
  • ISO/IEC 27005: Information Security Risk Management. O propósito da ISO/IEC 27005:2008 é prover diretrizes para orientar e assistir a implantação de processos de Segurança da Informação baseados numa abordagem de Gerenciamento de Risco, suportando os conceitos gerais especificados na ISO/IEC 27001 e 27002.
  • ISO/IEC-17799: Foi substituída pela ISO/IEC-27002 após a revisão de 2007.
  • ISO/IEC-15408:  Common Criteria, é uma referência internacional para desenvolvedores, administradores e auditores de segurança para sistemas de informação. A Common Criteria simplesmente atesta que o produto de software (aplicação web) implementa um determinado conjunto de funcionalidades de segurança, mas não garante que o mesmo seja seguro apenas por conta disso.

A segurança de fato estará ligada à capacidade da aplicação web em resistir à tentativas de ataques a partir da interação com os usuários, logo, não basta apenas prever critérios e funcionalidades de segurança nas etapas de seu desenvolvimento.

É preciso avaliar a segurança das aplicações web depois de sua implementação no ambiente de produção, a partir do fluxo de interação com o seu usuário final, testando sua capacidade de resistir à simulação de ataques conhecidos. É exatamente isso que a metodologia de uso do Sistema RedeSegura propõe para manter seguras as aplicações web, como o Gerenciamento de Vulnerabilidades.

O Security Development Lifecycle (SDL) adotado pela Microsoft, para citar uma empresa mundialmente conhecida, é um ótimo exemplo de processo em que se inclui o Gerenciamento de Vulnerabilidades, com registro e documentação de evidências de falhas de segurança, e de ações de melhoria para remediar as falhas, além da salvaguarda necessária para evitar a introdução de novas falhas pelo desenvolvimento durante as ações de melhoria.  

É com Gerenciando  de Vulnerabilidades em um ciclo de melhoria contínua que a Microsoft garante que seus produtos tenham atualmente um significativo sucesso na redução de problemas de segurança.

Recomendações do PCI-DSS *Cópia

pci-dss-imageO Payment Card Industry Security Standards Council (PCI-SSC) foi fundado pela American Express, Discover Financial Services, JCB International, MasterCard Worldwide e Visa Inc., como um fórum global para a disseminação de padrões de segurança na proteção de dados de pagamento.

O PCI Data Secutity Standart (PCI-DSS) especifica 12 recomendações mínimas de segurança obrigatórias para todas as empresas que participam da rede de captura de pagamento com cartões, o comércio, e prestadores de serviços que processam, armazenam e/ou transmitem eletronicamente dados do portador do cartão de crédito.

» Os 12 Requerimentos do PCI-DSS
divlar

As 12 recomendações do PCI-DSS são divididas em 6 seções que visam de modo geral proteger a integridade dos dados de pagamento do usuário do cartão de crédito, e o uso do Sistema RedeSegura atende a pelo menos três delas:

» Seção: Manter um Programa de Gerenciamento de Vulnerabilidades

Recomendação 6: Desenvolver e manter sistemas e aplicativos seguros.

O Sistema RedeSegura permite introduzir critérios de segurança em todo o ciclo de vida do desenvolvimento das aplicações web, desde a fase de homologação das entregas do desenvolvedor (Quality Assurance), incluindo os ciclos de melhoria e de atualização, e ainda no monitoramento dos niveis de segurança durante todo o tempo de uso em produção.

» Seção: Monitorar e Testar as Redes Regularmente

Recomendação 11: Testar regularmente os sistemas e processos de segurança.

O Sistema RedeSegura permite testar dinamicamente todas as recomendações de segurança correspondentes à  aplicação web a partir de testes de vulnerabilidades no ambiente de produção, que simulam 39.000 diferentes formas de ataque a partir de uma base de dados de assinaturas mantida pela tecnologia N-Stalker. Este método de uso permite avaliar continuamente a eficiência dos processos de segurança adotados desde o desenvolvimento.

» Seção: Manter uma Política de Segurança das Informações

Recomendação 12: Manter uma política que aborde a segurança das informações.

O Sistema RedeSegura é orientado ao gerenciamento de um processo continuado de monitoramento de indicadores de vulnerabilidades nas aplicações web, permitindo assim a manutenção de um processo de melhoria contínua (PDCA) que manterá viva nas equipes técnicas a política de segurança em todo o ciclo de vida do desenvolvimento de software.

End

{accordionfaq faqid=accordion1 faqclass=”plus”}

A metodologia de uso do Sistema RedeSegura para o Gerenciamento de Vulnerabilidades permitr manter o nível da segurança da aplicação web em conformidade com os patamares exigidos, mantendo evidências dos testes e indicadores de resultados auditáveis, o que garante o atendimento à estas 3 recomendações do PCI-DSS.

12-requerimentos-pci-dss-redesegura 

» Auditoria e Formalidades do PCI Compliance
divlar

O processo de certificação do PCI-DSS para empresas que movimentam volumes acima de 1 milhão de transações exige um relatório de auditoria feito por uma empresa credenciada como Entidade Certificadora, definida como Qualified Security Assessor (QSA):

  • Auditoria independente que avalia a aderência da empresa a todos os requerimentos de segurança do PCI-DSS
  • Emite um relatório formal após a avaliação “on-site” (annual report)

Empresas que movimentam até 1 milhão de transações por ano podem simplesmente responder um questionário Self-Assessment Questionnaire (SAQ):

  • Instrumento de validação para empresas que não precisam se certificar através de um QSA (pequenas e médias)
  • SAQs diferentes são definidos para cada situação do negócio

Independentemente do volume de transações é recomendável que a empresa realize trimestralmente pelo menos um teste de avaliação externo para identificar vulnerabilidades no seu ambiente de infra-estrutura, assim como sobre a aplicação web.

Para os testes trimestrais a empresa pode contratar o serviço de um Approved Scanning Vendor (ASV):

  • O ASV utiliza um conjunto de ferramentas e de pessoal Certificado PCI para realizar os testes definidos no requerimento 11.2 do PCI-DSS
  • Realiza externamente o scanning de vulnerabilidade via acesso internet ao menos uma vez a cada trimestre
  • Os testes não podem causar impacto, não incluem penetração, e geram um relatório com evidências (ASV Scan Report Attestation of Scan Compliance cover sheet).

O Sistema RedeSegura, assim como o software N-Stalker WAS, podem ser parte do conjunto de recursos de avaliação adotados pelas empresas credenciadas como ASV e QSA pelo PCI, pois produzem os relatórios de vulnerabilidades exigidos como documentação.

Recomendações do PCI-DSS

pci-dss-imageO Payment Card Industry Security Standards Council (PCI-SSC) foi fundado pela American Express, Discover Financial Services, JCB International, MasterCard Worldwide e Visa Inc., como um fórum global para a disseminação de padrões de segurança na proteção de dados de pagamento, e define o PCI Data Secutity Standart (PCI-DSS).

O PCI Data Secutity Standart (PCI-DSS) especifica recomendações mínimas de segurança obrigatórias para todas as empresas que participam da rede de captura de pagamento com cartões, o comércio, e prestadores de serviços que processam, armazenam e/ou transmitem eletronicamente dados do portador do cartão de crédito.


» Os 12 Requerimentos do PCI-DSSdivlar

Os 12 requerimentos do PCI-DSS são divididos em 6 seções que visam de modo geral proteger a integridade dos dados de pagamento do usuário do cartão de crédito.

A Metodologia de Segurança recomendada com o uso do Sistema RedeSegura atenderá à vários requerimentos de pelo menos três seções do PCI-DSS. Clique nos títulos a seguir e saiba mais:

» Seção: Manter um Programa de Gerenciamento de Vulnerabilidades

Requisito 6: Desenvolver e manter sistemas e aplicativos seguros.

O Sistema RedeSegura permite introduzir critérios de avaliação segurança no ciclo de vida do desenvolvimento das aplicações web, a partir da fase de testes de homologação que avaliam a qualidade da segurança nas entregas do desenvolvedor (Quality Assurance), incluindo os ciclos de melhoria e de atualização dos níveis de segurança.

Os critérios de segurança avaliados pelo Sistema RedeSegura atendem aos requisitos de “scanning” do PCI-DSS para a camada da aplicação web.

O Monitoramento do Risco de ataques pelo ambiente de produção da aplicação web cobre a outra fase do seu ciclo de vida, e mantém atualizado um indicador dos níveis de risco à segurança.

Requerimentos atendidos: 6.6 e 6.5 (6.5.1 até 6.5.9). A Metodologia de uso do Sistema RedeSegura e seus recursos também suportam os demais requerimentos 6.1, 6.2, 6.3, 6.4 e seus subitens.

» Seção: Monitorar e Testar as Redes Regularmente

Requisito 11: Testar regularmente os sistemas e processos de segurança.

O Sistema RedeSegura testa estática e dinamicamente todas as recomendações de segurança correspondentes à  aplicação web exigidas pelo PCI-DSS, incluindo alguns testes sobre o Sistema Operacional e o Servidor Web (patches de segurança, SSL, e outros). Os testes de vulnerabilidades podem ser feitos externamente ou internamente, tanto no ambiente de desenvolvimento como no de produção, e simulam 39.000 diferentes formas de ataque HTTP a partir de uma base de dados de assinaturas mantida pela tecnologia N-Stalker.

Nossa metodologia de uso permite avaliar continuamente a eficiência dos processos de segurança adotados desde o desenvolvimento. Consulte-nos para saber mais sobre os a cobertura dos testes PCI-DSS do RedeSegura.

Requerimentos atendidos: 11.2 (11.2.1, 11.2.2 como ferramenta do ASV, e 11.2.3). Os recursos do Sistema RedeSegura orientam o processo de “pen test” do requerimento 11.3 (11.3.2). 

» Seção: Manter uma Política de Segurança das Informações

Recomendação 12: Manter uma política que aborde a segurança das informações.

O Sistema RedeSegura é orientado ao gerenciamento de um processo que monitora os indicadores de vulnerabilidades nas aplicações web, permitindo assim a manutenção de um processo de melhoria contínua da segurança (PDCA).

Este processo estende para a camada da aplicação web o alcance da Política de Segurança da Informação definida pela sua empresa. O processo implementado com a Metodologia de Segurança RedeSegura integrará as equipes técnicas multidisciplinares de segurança da informação, de desenvolvimento, de infraestrutura, de Risco e Compliance, e até a de qualidade, em uma política de segurança mais abrangente e orientada ao PCI-DSS em todo o ciclo de vida das aplicações web.

Requerimentos atendidos: Vários subitens do requisito 12 encontram suporte e documentação na Metodologia de uso do Sistema RedeSegura e seus recursos.

End

{accordionfaq faqid=accordion1 faqclass=”plus”}

A metodologia de uso do Sistema RedeSegura para o Gerenciamento de Vulnerabilidades permitr manter o nível da segurança da aplicação web em conformidade com os patamares exigidos, mantendo evidências dos testes e indicadores de resultados auditáveis, o que garante o atendimento à estas 3 recomendações do PCI-DSS.

12-requerimentos-pci-dss-redesegura 

» Auditorias e Formalidades do PCI Compliancedivlar

(QSA) O processo de certificação do PCI-DSS (versão 2.0) para empresas (merchants) que movimentam volumes acima de 6 milhões de transações exige um relatório de auditoria “on site” feito por uma empresa credenciada como Entidade Certificadora, definida como Qualified Security Assessor (QSA):

  • Auditoria independente que avalia a aderência da empresa a todos os requerimentos de segurança do PCI-DSS
  • Analisa a documentação de segurança, relatórios anteriores de “scanning” internos e externos (ASV Report) 
  • Emite um relatório formal após a avaliação “on-site” (annual report)

(SAQ) As demais empresas que movimentam menos de 6 milhões de transações por ano devem responder um questionário Self-Assessment Questionnaire (SAQ), além de contratar trimestralmente um scanning externo:

  • Instrumento de validação para empresas que não precisam se certificar através de um QSA (pequenas e médias)
  • SAQs diferentes são definidos para cada situação do negócio

Independentemente do volume de transações anuais, é recomendado que a empresa realize trimestralmente pelo menos um teste de avaliação externo para identificar vulnerabilidades no seu ambiente de infra-estrutura, assim como sobre a aplicação web, além de testes internos regurares que avaliam a segurança de seu ambiente preventivamente.

(ASV) Para os testes externos trimestrais a empresa deve contratar o serviço de um Approved Scanning Vendor (ASV), e para os testes internos pode utilizar-se de recursos e ferramentas próprias, de terceiros, ou de um ASV:

  • O ASV utiliza um conjunto de ferramentas de teste, uma metodologia padrão, e uma equipe técnica com pessoal Certificado pelo PCI para realizar os testes definidos no requerimento 11.2 do PCI-DSS;
  • O “scanning” de vulnerabilidade será realizado externamente, via acesso internet ao menos uma vez a cada trimestre. A sua empresa (Scan Customer) deve realizar periodicamente “scans” internos com o mesmo alcance dos testes do ASV.
  • Os testes não podem causar impacto, não incluem penetração, e geram um relatório com evidências (ASV Scan Report Attestation of Scan Compliance cover sheet).

O Sistema RedeSegura “powered by” N-Stalker pode integrar a Solução Técnica adotada pelo ASV e/ou QSA como parte de seus recursos de avaliação para o “scanning” externo e certificação, pois produz as evidências e os relatórios de vulnerabilidades que são exigidos como documentação pelo PCI-DSS.

Adicionalmente, o Sistema RedeSegura pode ser adotado como uma ferramenta poderosa para os testes de “scanning” internos da sua empresa, enquanto mantém seu processo de Gerenciamento de Vulnerabilidades.