Баннер
  • Безопасность

  • Тесты и Аудит

  • ПО

  • PCI DSS

  • ISO27001

  • Планирование безопасности

    Наш подход к планированию и разработке стратегии безопасности ERP основан на оценке рисков, которым подвергается бизнес и принимает во внимание: Корпоративные требования...
    Читать дальше...
  • Корпоративная Безопасность

  • CODEFEND

    Технология CODEFEND позволяет проводить автоматизированную проверку исходного кода приложений с привязкой к используемой технологии и с возможностью написания кастомизируемых...
    Читать дальше...
  • Тест на проникновение

  • Анализ кода

  • Ping Identity

    Решение для идентификации и SSO c низкой стоимостью владения. Это инновационное решение может поставляться как облачный сервис (on-Demand) и как решение для интеграции в...
    Читать дальше...
  • Сервис Panaya для SAP ERP

  • Retalix

  • Требования PCI DSS

  • ISO 27001

    Информация зачастую является ключевым активом компании, а ее защита - приоритетной задачей. Получение сертификации по стандарту ISO 27001 позволит сохранить и защитить...
    Читать дальше...
Developed by JoomVision.com

Требования PCI DSS

PDFПечатьE-mail

Written by John Markh, QSA, Information Security Consultant

One of the major changes in the Payment Card Industry Data Security Standard (PCI:DSS) version 1.1 is requirement 6.6. This objective of this requirement is to protect web applications which are exposed to the public network (such as the Internet) from the most common types of attacks.

There are a number of possible implementation options which differ in cost, operational complexity, deployment methods and procedures, relevant skills and implementation timeframe. Before deciding on a specific alternative, one should understand the intent of the requirement and the available options.

As stated above, objective of requirement 6.6 is to ensure that web applications which are exposed to the public network are protected from most attacks. PCI:DSS provides two options:

  • Application Firewall
  • Application Code Review

This article will examine both options and will provide consideration points one can use before deciding on the best matching solutions.

Application Firewall

It is a well known fact that network firewalls are not designed to inspect, evaluate and react to web application traffic (HTTP, WSDL, SOAP, etc.). This fact is shown in the increased number of attacks against web applications and services using methods such as XSS, XML bombing and SQL Injections.

Web Application Firewalls (WAF) are security policy enforcers positioned between the web application and the client. They are designed to inspect the content of the application layer as well as the content of any other layer that could be used to attack web applications. In addition to matching the content with a set of Regular Expressions to identify malicious input (usually referred to as security rules), many solutions include dynamic profiling of the application with the ability to alert or block any traffic that does not match the created profile.

The necessary functionality could be implemented in software or hardware, and could be running either as an appliance or typical server using common operation system. There are numerous solutions which can cater to specific operational, administrational and security requirements determined by the organization. The organization should set the requirements based on the cost factors, existing infrastructure, technologies in use, established knowledge base and required support prior to choosing a favorite solution to ensure it will provide sufficient protection for all the application data flows.

It is important to emphasize that it is not enough to merely plug the product in with all the required functionalities. Proper architectural decisions should be made which include positioning, configuration, administration and monitoring the solution.

Given the dynamic and complex nature of web applications, this option is not always possible to implement. For example, when an application is using a proprietary protocol to exchange data, a firewall cannot inspect the content of specific message flow. In this case, implementing the code review option could be a better choice.

Application Code Review

One of the common mistakes is that application code review does not have to be a manual review of the source code. It is important to keep in mind that the intention of requirement 6.6 is to prevent exploitation of common vulnerabilities rather than the costly and complex solution. In the supplement document release by the PCI council, there are four alternatives that could meet the intents of requirement 6.6:

  • Manual review of application source code
  • Use of automated source code analyzing tools
  • Manual web application security vulnerability assessment
  • Use of automated web application security vulnerability assessment tools.

It is important to note, that code review and/or assessments could be conducted by internal resources as well as specialized 3rd parties. In either case, the individual(s) must have the proper skills and experience to understand the vulnerabilities associated within the web application. In addition, if internal resources are used, they should be organizationally separated (for example, internal audit department or separated development department) from the development and management of the assessed application.

This option may not be possible in some situations (for example, no access to the source code).

Conclusion

For those who are not merely looking to comply with the standard with minimum investment but to increase the level of Information Security in the organization, there are several ways to perform the code review or application assessment that will provide better protection than an application firewall.

One of the ways is to incorporate a secure code review process in the organizational software development life cycle (SDLC). The code review could be either a manual or automated process and should be performed before a major release or update. Furthermore, a change control processes must ensure that the application undergoes a security assessment before it is released into the production environment.

In addition to the final sign-off, it is recommended to use security reviews (manual or automatic) as early as possible in the development process. The output from those processes can provide important feedbacks such as conformance to architectural best practices and known security defects in code.

Joomla! Template design and develop by JoomVision

Случайная новость

Мы открыли свой Блог!

Мы создали свой блог и теперь будем радовать Вас периодическим появлением полезных статей по информационной безопасности, которые сделают наш ресурс еще более полезным и интересным.

Надеемся, что это поможет лучше разобраться в вопросах информационной безопасности более широкому кругу заинтересованных людей, не являющихся специалистами в этой области.

Заходите на наш Блог прямо сейчас!