В ноябре 2013-го года официально анонсирована новая версия Payment Application Data Security Standard 3.0, сменив действующую в течение последних трех лет вторую версию.
Алексей Бабенко, руководитель направления, ЗАО НИП «Информзащита»
С 2008-го года, момента своего появления, стандарт опирался на «старшего брата» PCI DSS. С выходом новой версии стандарта изменения можно расценивать не только как подстраивание под нововведения PCI DSS, но и как самостоятельные требования.
Для того, чтобы рассмотреть основные нововведения, можно условно поделить стандарт на три основные группы: требования к ПО, процессам и документированию Руководства по применению.
В части требований к ПО изменения в новой версии стандарта наименее значительны. Так, согласно букве стандарта, приложение должно обеспечивать защиту паролей хешированием с уникальным значением «соли» для каждого значения, а встроенные учетные записи приложения должны по умолчанию обладать минимальным уровнем доступа и привилегиями.
Требования к составу Руководства по применению также подверглись небольшим изменениям, но для компаний, проходивших сертификацию, данные нововведения неожиданностью не будут. Добавленные изменения в большей своей части привели к соответствию требований по составу проверок, предъявляемых к аудиторам, и процедуры аудита.
Как и прежде PA-DSS Implementation Guide должен давать клиентам всеобъемлющую информацию по мерам, принятым в ПО для выполнения всех требований стандарта, и параметрам, которые могут влиять на выполнение требований.
Наиболее существенные изменения коснулись процессов обеспечения безопасности при разработке и распространении ПО.
Instant Үшінші Көз ынталандыру — M1 (Ескерту: өте қуатты!)
Процесс создания ПО должен включать в себя:
- Обеспечение контроля целостности исходного кода в течение процесса разработки и тестирования ПО, выпуска релиза;
- Использование методов программирования, направленных на минимизацию возможного уровня привилегий, для выполнения задач в среде выполнения, защиту от сбоев (любые сценарии выполнения, кроме явно определенных дизайном продукта, запрещены по умолчанию), учет всех возможных точек и способов ввода пользовательских данных;
- Описание процесса обработки данных (ДПК и критичных данных авторизации) в памяти приложения;
- Проведение и периодическое обновление материалов обучения методам безопасного программирования по различным тематикам. При этом тренинги могут проводиться в рамках внешнего, внутреннего, либо самостоятельного обучения сотрудников.
Вынесена в отдельную группу требований необходимость создания и поддержания политики контроля версий. При этом версионность ПО должна соответствовать типам изменений, определенных PCI SSC.
К тому же теперь данная политика должна быть доведена до клиентов включением ее в состав Руководства по применению стандарта.
Одним из серьезных нововведений новой версии стандарта стало введение необходимости проведения оценки рисков (построения модели угроз) сертифицируемого программного обеспечения и внесение корректирующих мер, снижающих выявленные риски.
Процесс утверждения выпуска новых релизов ПО теперь должен быть формализован, включая контроль выполнения всех этапов процесса безопасной разработки с визированием решения о выпуске ответственным лицом. Вместе с выпуском новой версии должна выпускаться информация о релизе (Release Notes) с описанием деталей изменений и актуальной версией ПО.
Если вендор или интегратор имеет удаленный доступ к сертифицируемому ПО, установленному на стороне клиента, согласно стандарту необходимо использовать уникальные учетные данные для каждого клиента.
Отдельное внимание уделено вопросам повышения осведомленности. Согласно третьей версии ежегодно все сотрудники вендора должны проходить обучение, направленное на изучение требований стандарта.
Кроме того, должны быть официально назначены лица, ответственные за критичные процессы, в том числе за:
- повышение осведомленности и обучение для сотрудников и третьих лиц,
- выполнение требований стандарта в целом,
- применение практик безопасного программирования.
