Да поможет нам PA-DSS!

Часто бывает знания из одной предметной области помогают что-то понять из другой. Я люблю это называть "ассоциативное мышление". Именно по этой причине, когда я учился в школе, а затем в университете, я не фильтровал предметы по "ненужности" и с удовольствием слушал как лекции по Культурологии и Истории, которые были необходимы скорее для комплексности университетского образования, чем для развития меня, как специалиста в области ИБ, так и лекции по специальным и необходимым для меня предметам: Криптографические средства защиты информации, Сетевые операционные системы и пр. Я считал ( и уверен в этом до сих пор ), что знания из различных областей позволяют более комплексно понимать проблему, а разные области знаний имеют множество сходств и аналогий, которые можно использовать....

Многим известно о существовании стандарта PCI DSS. О нем много пишут, производители различного оборудования и ПО проводят семинары о том, как их оборудование помогает соответствовать этому стандарту и т.п. От себя хочу заметить, что лично мое отношение к данному стандарту более чем положительное, поскольку я люблю конкретность. В данном стандарте весьма четко прописано, вплоть до указания конкретных технологий, что надо сделать, чтобы ему соответствовать, что делает его сильно отличимым от прочих, например ISO. Подобная конкретность может быть использована в случае, когда перед специалистом по ИБ стоит задача "сделать безопасность" в чистом поле, и, понятное дело, разумный вопрос: "Что делать-то?". Ну да, сначала надо определить бизнес-процессы, оценить риски, определить контрмеры, написать политику по ИБ.... в общем, это бумагомарательство займет продолжительное время, прежде чем приведет к тому же, что предписано сделать в PCI DSS. В общем, мое мнение заключается в том, что можно сразу взять PCI DSS и начать "делать безопасность" как там требуют, а обращивать эти системы соответствующими документальными обоснованиями можно по ходу дела.

Но тема наша - PA-DSS, и я не ошибся, написав "PA" вместо "PCI". Как мне кажется он незаслуженно пребывает в тени своего собрата с префиксом "PCI" и тоже может быть использован специалистом по ИБ в своей работе.

Подразделение ИБ в нашей компании участвует в ИТ-проектах в качестве экспертов по вопросам ИБ. Одной из задач этих экспертов является анализ рисков и рекомендация контрмер по снижению обозначенных рисков. Фактически - это написание требований ИБ к той или иной системе. Понятно, что эти контроли я стараюсь не придумывать каждый раз заново из головы, а откуда-нибудь выписывать. Действительно, должны же мы использовать "плечи гигантов", а не изобретать велосипед каждый раз заново! В этой связи я высоко ценю "хорошие" источники контрмер, которые могут быть использованы мной в качестве справочников. После прочтения PA-DSS я пришел к выводу, что его тоже можно отнести к "хорошим" справочникам. В частности, указанные в PA-DSS требования можно легко перефразировать применительно к системам, обрабатывающим конфиденциальную для Компании информацию (коммерческую тайну). Еще выше степень применимости, в случае, если система обработки конфиденциальной информации разрабатывается под заказ.

Чтобы не быть голословным, приведу ряд требований, которые мне показались наиболее интересными (т.е. если бы я писал требования из головы или из имеющихся у меня на сейчас справочников, я бы вряд ли догадался их указать, а они важны), в [квадратных скобках] я буду указывать соответствующий раздел PA-DSS.
1. В рамках требований - только приложение, не ОС, не СУБД [Scope of PA-DSS]. Это важно, поскольку в конкретном проекте нельзя решить проблемы безопасности ОС или СУБД, поскольку это - "коробочные" продукты, но можно решить проблемы приложения и это надо указать.
2. Разработчик вместе с приложением разрабатывает документ "Implementation Guide", который показывает, как надо настроить и использовать его ПО, чтобы выполнялись требования ИБ [Roles and Responsibilities. Software vendors].
3. Даны условия, когда не стоит натягивать требования ИБ на аппаратные терминалы [PA-DSS Applicability to Hardware Terminals].
4. Указано важное обстоятельство, что недостаточно, чтобы только приложение удовлетворяло требованиям ИБ, но важно чтобы еще и окружение соответствовало этим требованиям [Roles and Responsibilities. Customers].
5. Дано необходимое содержание запроса на подтверждение соответствия (Report on Validation, RV) [Instructions and Content for Report on Validation]. Многие из вопросов освещенных в RV нужно требовать в документах на систему: сетевая диаграмма, требования к ОС и СУБД, схема потоков данных (dataflow), пр.
6. Использование шифрования информации не отменяет использование логических механизмов контроля доступа [PA-DSS Requirements and Security Assessment Procedures, 2.4].
7. Журналлированию подлежат все доступы к данным [PA-DSS Requirements and Security Assessment Procedures, 4].
8. Актуальные данные продуктивных систем не используются в системах тестирования и разработки [PA-DSS Requirements and Security Assessment Procedures, 5.1.4].
9. Все Web-приложения должны разрабатываться с использованием руководств по безопасному программированию Open Web Application Security Project Guide [PA-DSS Requirements and Security Assessment Procedures, 5.2]
10. Приложение должно быть совместимо с используемыми в Компании системами безопасности [PA-DSS Requirements and Security Assessment Procedures, 8.1]
11. Сервер БД должен быть разделен с Web-сервером, причем сервер баз данных не должен располагаться в ДМЗ [PA-DSS Requirements and Security Assessment Procedures, 9.1]
12. Приложение должно быть совместимо с системами многофакторной аутентификации [PA-DSS Requirements and Security Assessment Procedures, 11.1]

Надеюсь, уважаемые читатели, стандарт PA-DSS покажется вам тоже полезным.