Carding 4 Carders
Professional
В этом месяце (март 2021 г.) PCI опубликовала на своем веб-сайте давно работающие стандарты безопасности программного обеспечения. Я говорю «долго в разработке», так как обновление стандарта оценки программного обеспечения PCI готовится в течение некоторого времени ... первоначально оно обсуждалось в 2017 году до собраний сообщества, поэтому его прибытие не должно удивлять никого в платежной индустрии. Однако то, что может быть интересно (как для платежного сообщества, так и для сообщества разработчиков программного обеспечения в целом), так это то, что на самом деле было выпущено два документа - Требования к безопасному жизненному циклу программного обеспечения (Secure SLC) и Требования к безопасному программному обеспечению и процедуры оценки как часть общей структуры оценки программного обеспечения и понимание того, как эти документы взаимодействуют и работают вместе, чтобы обеспечить безопасную разработку программного обеспечения в будущем.
Ученик исходных кодов
Так как же один стандарт программного обеспечения превратился в два? Оба эти стандарта написаны для создания того, что называется PCI Software Security Framework (то есть по отдельности они являются стандартами, а вместе они являются частью структуры), и они касаются двух очень разных аспектов безопасности программного обеспечения.
Требования Secure SLC (SSLC) предназначены для обеспечения оценки процессов разработки программного обеспечения поставщика, чтобы гарантировать, что безопасность «встроена» на протяжении всего процесса от проектирования до текущего обслуживания. Это всеобъемлющий стандарт, предназначенный не для оценки по отдельным программным продуктам, а по сравнению с политикой, процедурами и процессами, которые используются для разработки всего (входящего в объем) программного обеспечения в этой компании.
Secure Требования к программному обеспечению и процедура оценки (SSRAP) документ, с другой стороны, делает выдвинутые требования для оценки безопасности отдельных программных продуктов. Этот стандарт рассматривает отдельные аспекты безопасности программного обеспечения для таких продуктов и описывает процедуры тестирования для проверки этих аспектов.
Оба эти стандарта также касаются специфики риска; почему важно включать оценку рисков в разработку программного обеспечения, что включать при этом и как можно оценить используемую методологию. Ожидается, что "подход, основанный на оценке риска'', станет новой популярностью для PCI в 2021 году.
Во-первых, познайте себя
К сожалению, безопасное программное обеспечение не создается случайно - оно требует усердия и опыта, чтобы убедиться, что риски поняты и учтены. Это цель требований Secure SLC - дать четкое определение того, какие процессы должна иметь компания, чтобы гарантировать, что она может производить безопасное программное обеспечение. Стандарт рассматривает четыре аспекта высокого уровня с дополнительными подчиненными целями контроля:
Управление безопасностью программного обеспечения
Безопасная разработка программного обеспечения
Безопасное программное обеспечение и управление данными
Безопасность связи
Этот SSRAP!
Когда мы начинаем рассматривать отдельные программные продукты, нам нужны различные требования для определения конкретных мер безопасности и соображений, которые должны быть включены; это цель требований к безопасному программному обеспечению и процедур оценки. Однако, учитывая разнообразную природу программного обеспечения, которое может быть охвачено этим стандартом, как один документ обеспечивает полную широту и глубину требуемой безопасности? Простой ответ - нет! Текущий документ SSRAP считается началом более широкого набора требований, которые могут быть созданы для охвата нового программного обеспечения в соответствии с этим стандартом - в нем излагаются «основные» требования платежного программного обеспечения, но со временем они могут быть добавлены в качестве конкретных аспектов или функций. программного обеспечения необходимо учитывать.
В настоящее время документ SSRAP предусматривает четыре аспекта высокого уровня, опять же с подчиненными целями контроля (и на этот раз также Приложение!):
Сведение к минимуму поверхности атаки
Механизмы защиты программного обеспечения
Безопасные операции с программным обеспечением
Безопасное управление жизненным циклом программного обеспечения
Модуль A - Защита данных учетной записи
A.1) Конфиденциальные данные аутентификации
A.2) Защита данных держателя карты
Глядя на вышеизложенное, вы можете представить себе методологию, которую использует стандарт; выявить активы и потенциальные проблемы безопасности, подтвердить, что каждый из этих элементов каким-либо образом смягчен или защищен посредством разработки программного обеспечения, а затем убедиться, что существует постоянная программа для поддержки программного обеспечения в течение долгого времени, а также информирование пользователей о программное обеспечение о том, как его безопасно использовать.
Интересно, что, глядя на краткое описание выше и на тот факт, что существует отдельный модуль, определяющий особенности «Защиты данных учетной записи», который определяет базовые активы в платежном программном обеспечении, вы можете заметить, что этот стандарт на самом деле является довольно общим - в том смысле, что что требования и тесты могут быть применены к любому программному обеспечению, а не «только» платежному программному обеспечению.
Платите вперед
Это отделение фактического аспекта «оплаты» от самого стандарта оценки является вполне преднамеренным и гарантирует, что этот стандарт может быть разделен на модули и применен к различным типам программного обеспечения в будущем. Означает ли это, что PCI пробивается в области, не связанные с платежами? Нет, цель состоит в том, что мы действительно не знаем, какими будут «платежи» через 5 или 10 лет, а уязвимости, существующие в платежном программном обеспечении, часто могут быть точно такими же уязвимостями, которые существуют в неплатежном программном обеспечении. Таким образом, имеет смысл создать эти родовые, главнейшие оценки рамки, которые могут быть согнуты волей конкретных областей по мере необходимости.
Это имеет два основных значения:
Получить с программой
Итак, чего ожидать в будущем от стандартов безопасности программного обеспечения PCI? Те из вас, кто знаком с PCI, могут заметить, что из трех выпущенных в настоящее время документов по-прежнему отсутствует «Руководство по программе», которое обычно используется для описания аспектов управления и обработки любого нового стандарта PCI. Можно ожидать, что это появится со временем, но некоторые признаки того, что это может быть внутри, уже существуют. В FAQ документе, который был был освобожден, состояние PCI:
Q6 Кто будет иметь право выполнять оценку по стандарту безопасного программного обеспечения?
Сертифицированный PCI Secure Software Assessor Компании и их сотрудники. PCI Secure Software Assessor (SSA) Компании - это независимые организации в области безопасности, прошедшие квалификацию PCI SSC для проверки соответствия платежного программного обеспечения Стандарту безопасного программного обеспечения. Специалисты по оценке защищенного программного обеспечения - это сотрудники компаний SSA, которые выполнили и продолжают выполнять все требования программы SSA.
Таким образом, будет разработана еще одна программа PCI с соответствующими аккредитациями и требованиями к оценщикам. В FAQ также отмечается, что оценка организации на соответствие требованиям SSLC может использоваться для снижения требований к текущим дельта-оценкам, когда в программный продукт со временем неизбежно вносятся изменения - это отличный шаг, ИМХО, и что-то в этом роде. это было предметом обсуждения и разногласий во многих других программах безопасности, с которыми я работал на протяжении многих лет. Полная честь PCI за движение в этом направлении (хотя впервые это произошло в стандарте PCI HSM… но это на другой день).
Что все это означает, если прямо сейчас у вас есть одобренное PA-DSS программное обеспечение? Что ж, сейчас это не так много значит - программа еще не выпущена, как уже отмечалось. Тем не менее, PCI говорит о постепенном отказе от программы PA DSS в будущем, как также отмечено в часто задаваемых вопросах:
Новые проверки PA-DSS будут приниматься до середины 2021 года и будут действительны до конца 2022 года. Ожидается, что оценки на соответствие PCI Software Security Framework начнутся в третьем квартале 2021 года и будут иметь трехлетний период действия с указанием даты истечения срока действия этих проверок. примерно с тем же сроком годности, что и у сертификатов PA-DSS.
Так что поводов для паники пока нет. Но, учитывая общее время разработки программного обеспечения, PCI PA-DSS или PCI Software Security - это то, что вы должны предпринять прямо сейчас, если у вас есть что-то, над чем вы работаете, но еще не выпущено. Кроме того, на этом этапе стоит рассмотреть планы перехода для существующего программного обеспечения.
Излишне говорить, что как один из разработчиков стандарта и член Круглого стола глобальных исполнительных оценщиков PCI (GEAR), UL может помочь вам как в понимании этого нового стандарта, так и в ваших планах по адаптации к нему в вашей среде. дорожные карты развития.
Ученик исходных кодов
Так как же один стандарт программного обеспечения превратился в два? Оба эти стандарта написаны для создания того, что называется PCI Software Security Framework (то есть по отдельности они являются стандартами, а вместе они являются частью структуры), и они касаются двух очень разных аспектов безопасности программного обеспечения.
Требования Secure SLC (SSLC) предназначены для обеспечения оценки процессов разработки программного обеспечения поставщика, чтобы гарантировать, что безопасность «встроена» на протяжении всего процесса от проектирования до текущего обслуживания. Это всеобъемлющий стандарт, предназначенный не для оценки по отдельным программным продуктам, а по сравнению с политикой, процедурами и процессами, которые используются для разработки всего (входящего в объем) программного обеспечения в этой компании.
Secure Требования к программному обеспечению и процедура оценки (SSRAP) документ, с другой стороны, делает выдвинутые требования для оценки безопасности отдельных программных продуктов. Этот стандарт рассматривает отдельные аспекты безопасности программного обеспечения для таких продуктов и описывает процедуры тестирования для проверки этих аспектов.
Оба эти стандарта также касаются специфики риска; почему важно включать оценку рисков в разработку программного обеспечения, что включать при этом и как можно оценить используемую методологию. Ожидается, что "подход, основанный на оценке риска'', станет новой популярностью для PCI в 2021 году.
Во-первых, познайте себя
К сожалению, безопасное программное обеспечение не создается случайно - оно требует усердия и опыта, чтобы убедиться, что риски поняты и учтены. Это цель требований Secure SLC - дать четкое определение того, какие процессы должна иметь компания, чтобы гарантировать, что она может производить безопасное программное обеспечение. Стандарт рассматривает четыре аспекта высокого уровня с дополнительными подчиненными целями контроля:
Управление безопасностью программного обеспечения
- Ответственность за безопасность и ресурсы
- Политика и стратегия безопасности программного обеспечения
Безопасная разработка программного обеспечения
- Выявление и устранение угроз
- Обнаружение и устранение уязвимостей
Безопасное программное обеспечение и управление данными
- Управление изменениями
- Защита целостности программного обеспечения
- Защита конфиденциальных данных
Безопасность связи
- Руководство по безопасности поставщика
- Связь с заинтересованными сторонами
- Информация об обновлении программного обеспечения
Этот SSRAP!
Когда мы начинаем рассматривать отдельные программные продукты, нам нужны различные требования для определения конкретных мер безопасности и соображений, которые должны быть включены; это цель требований к безопасному программному обеспечению и процедур оценки. Однако, учитывая разнообразную природу программного обеспечения, которое может быть охвачено этим стандартом, как один документ обеспечивает полную широту и глубину требуемой безопасности? Простой ответ - нет! Текущий документ SSRAP считается началом более широкого набора требований, которые могут быть созданы для охвата нового программного обеспечения в соответствии с этим стандартом - в нем излагаются «основные» требования платежного программного обеспечения, но со временем они могут быть добавлены в качестве конкретных аспектов или функций. программного обеспечения необходимо учитывать.
В настоящее время документ SSRAP предусматривает четыре аспекта высокого уровня, опять же с подчиненными целями контроля (и на этот раз также Приложение!):
Сведение к минимуму поверхности атаки
- Идентификация критических активов
- Безопасные настройки по умолчанию
- Хранение конфиденциальных данных
Механизмы защиты программного обеспечения
- Защита критических активов
- Аутентификация и контроль доступа
- Защита конфиденциальных данных
- Использование криптографии
Безопасные операции с программным обеспечением
- Отслеживание активности
- Обнаружение атак
Безопасное управление жизненным циклом программного обеспечения
- Управление угрозами и уязвимостями
- Безопасные обновления программного обеспечения
- Руководство по безопасности поставщика
Модуль A - Защита данных учетной записи
A.1) Конфиденциальные данные аутентификации
A.2) Защита данных держателя карты
Глядя на вышеизложенное, вы можете представить себе методологию, которую использует стандарт; выявить активы и потенциальные проблемы безопасности, подтвердить, что каждый из этих элементов каким-либо образом смягчен или защищен посредством разработки программного обеспечения, а затем убедиться, что существует постоянная программа для поддержки программного обеспечения в течение долгого времени, а также информирование пользователей о программное обеспечение о том, как его безопасно использовать.
Интересно, что, глядя на краткое описание выше и на тот факт, что существует отдельный модуль, определяющий особенности «Защиты данных учетной записи», который определяет базовые активы в платежном программном обеспечении, вы можете заметить, что этот стандарт на самом деле является довольно общим - в том смысле, что что требования и тесты могут быть применены к любому программному обеспечению, а не «только» платежному программному обеспечению.
Платите вперед
Это отделение фактического аспекта «оплаты» от самого стандарта оценки является вполне преднамеренным и гарантирует, что этот стандарт может быть разделен на модули и применен к различным типам программного обеспечения в будущем. Означает ли это, что PCI пробивается в области, не связанные с платежами? Нет, цель состоит в том, что мы действительно не знаем, какими будут «платежи» через 5 или 10 лет, а уязвимости, существующие в платежном программном обеспечении, часто могут быть точно такими же уязвимостями, которые существуют в неплатежном программном обеспечении. Таким образом, имеет смысл создать эти родовые, главнейшие оценки рамки, которые могут быть согнуты волей конкретных областей по мере необходимости.
Это имеет два основных значения:
- Можно ожидать, что со временем к этому стандарту будут добавляться новые модули и контексты, или что сам стандарт будет использоваться другими стандартами PCI в будущем.
- Если вы занимаетесь разработкой (или оценкой) программного обеспечения, это остается отличным инструментом для проверки правильности ваших действий с точки зрения безопасности, даже если разрабатываемое вами программное обеспечение не специально ( или вообще) связанные с оплатой.
Получить с программой
Итак, чего ожидать в будущем от стандартов безопасности программного обеспечения PCI? Те из вас, кто знаком с PCI, могут заметить, что из трех выпущенных в настоящее время документов по-прежнему отсутствует «Руководство по программе», которое обычно используется для описания аспектов управления и обработки любого нового стандарта PCI. Можно ожидать, что это появится со временем, но некоторые признаки того, что это может быть внутри, уже существуют. В FAQ документе, который был был освобожден, состояние PCI:
Q6 Кто будет иметь право выполнять оценку по стандарту безопасного программного обеспечения?
Сертифицированный PCI Secure Software Assessor Компании и их сотрудники. PCI Secure Software Assessor (SSA) Компании - это независимые организации в области безопасности, прошедшие квалификацию PCI SSC для проверки соответствия платежного программного обеспечения Стандарту безопасного программного обеспечения. Специалисты по оценке защищенного программного обеспечения - это сотрудники компаний SSA, которые выполнили и продолжают выполнять все требования программы SSA.
Таким образом, будет разработана еще одна программа PCI с соответствующими аккредитациями и требованиями к оценщикам. В FAQ также отмечается, что оценка организации на соответствие требованиям SSLC может использоваться для снижения требований к текущим дельта-оценкам, когда в программный продукт со временем неизбежно вносятся изменения - это отличный шаг, ИМХО, и что-то в этом роде. это было предметом обсуждения и разногласий во многих других программах безопасности, с которыми я работал на протяжении многих лет. Полная честь PCI за движение в этом направлении (хотя впервые это произошло в стандарте PCI HSM… но это на другой день).
Что все это означает, если прямо сейчас у вас есть одобренное PA-DSS программное обеспечение? Что ж, сейчас это не так много значит - программа еще не выпущена, как уже отмечалось. Тем не менее, PCI говорит о постепенном отказе от программы PA DSS в будущем, как также отмечено в часто задаваемых вопросах:
Новые проверки PA-DSS будут приниматься до середины 2021 года и будут действительны до конца 2022 года. Ожидается, что оценки на соответствие PCI Software Security Framework начнутся в третьем квартале 2021 года и будут иметь трехлетний период действия с указанием даты истечения срока действия этих проверок. примерно с тем же сроком годности, что и у сертификатов PA-DSS.
Так что поводов для паники пока нет. Но, учитывая общее время разработки программного обеспечения, PCI PA-DSS или PCI Software Security - это то, что вы должны предпринять прямо сейчас, если у вас есть что-то, над чем вы работаете, но еще не выпущено. Кроме того, на этом этапе стоит рассмотреть планы перехода для существующего программного обеспечения.
Излишне говорить, что как один из разработчиков стандарта и член Круглого стола глобальных исполнительных оценщиков PCI (GEAR), UL может помочь вам как в понимании этого нового стандарта, так и в ваших планах по адаптации к нему в вашей среде. дорожные карты развития.
