Время размещения статьи в будущем 0_о

Ничего, глюк матрицы... Через 4 минуты 2 реальности состыкуются.

Почему в теле новости не указано, что такое PCIDSS?
В хорошей новости такое написать надо обязательно.

янихренанепонел

http://ru.wikipedia.org/wiki/PCI-DSS

Payment Card Industry Data Security Standard (PCI DSS) - стандарт защиты информации в индустрии платёжных карт, разработанный международными платёжными системами Visa и MasterCard, объединяет в себе требования ряда программ по защите информации.

Думаю, неплохо было бы дописать эти в текст новости, а то не понятно же нифига.

Вендекапец?

Вендевбанкоматахкапец?

Зачем это надо

Да, спасибо за коммент, не все учел :)

Если вкратце - стандарт защиты PCI DSS обязателен для организаций, работающих с пластиковыми картами. Это не только банки, но и ритейл, сотовые операторы, ..., etc. Требования налагаются ко всей инфраструктуре - не только к серверам и рабочим станциям, но и к базам данных, сетевому оборудованию, wifi-точкам и т.д. Отдельные главы посвящены физическому доступу и политикам безопасности, кроме того, много внимания уделяется регламентам и документации.

Сам стандарт довольно «мутный», т.к. он общий и для *NIX, и для Windows, и т.п. Для сравнения можно посмотреть семейство CIS (http://www.cisecurity.com) - чисто технические стандарты, с указанием опций настройки и даже скриптов. CIS must read, это достаточно грамотная (хотя и неполная) подборка настроек, хорошая отправная точка для построения защищенных систем. Как раз для того, чтобы чтение и реализация PCI DSS не вызывали множества вопросов, мы оформили свои наработки в виде статьи - читайте на здоровье, любая конструктивная критика труЪ :)

Информация о стандарте, в том числе его русскоязычная версия, доступна на сайтах: https://www.pcisecuritystandards.org/ http://www.pcisecurity.ru/

локальненько, но для общего развития наверное будет неплохо.

молодцы, парни!

Исправил

Selinux,Grsec,KVM - будут заюзаны?

http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard#Req...

2. Do not use vendor-supplied defaults for system passwords and other security parameters

и далее в том же духе
настоящий ынтерпрайзЪ

и еще:

5. Use and regularly update anti-virus software on all systems commonly affected by malware

эт я к тому, что мне и на wifi точки предлагают антивирус ставить, да?

в педивикии в разделе Requierements вообще мега-вещи. Это любой админ локалхоста выполнить может. А CIS сейчас посмотрим, спасибо за ссылку.

странно, что там не предлагают проверять наклеечки на корпусе системного блока.

Болезненные точки.

эт я к тому, что мне и на wifi точки предлагают антивирус ставить, да?

У вас точки доступа commonly affected by malware? Тогда ставьте.

логично. это его ниша.

> эт я к тому, что мне и на wifi точки предлагают антивирус ставить, да?

Беспроводка в системе передачи данных пластиковых карт? Ну-ну.

> Беспроводка в системе передачи данных пластиковых карт? Ну-ну.

Что «ну-ну»? В PCI DSS беспроводка запрещена? Где-то еще запрещена?

И чем сегмент интернета до банка секурнее, чем беспроводка + порты через ssh/ipsec ?

> У вас точки доступа commonly affected by malware? Тогда ставьте.

где в PCI DSS написано что «у нас»?

а вообще точки доступа commonly affected by malware

>мне и на wifi точки предлагают антивирус ставить, да?

Вчерась аудиторы прислали, что линуксы теперь рассматриваются, как «обычно подвержены вирусам», т.ч. если там линукс - ставить.

>В PCI DSS беспроводка запрещена

Нет. Но это ещё одна банка с червями, проще не открывать.

Частично да

Патчи на ядро (GRSec) не рассматриваем, т.к. они не входят в стандартную поставку дистрибутива, если накладывать их руками - в будущем вполне вероятны проблемы с техподдержкой RedHat.

SELinux рассматривать будем чуть позже, но не детально - у самого RedHat (да и на сайте Федоры тоже) есть вполне адекватные мануалы, нет смысла их пересказывать. Если Вам интересен Selinux, то когда опубликуем главу 7, можете оставить пожелание в комментариях статьи на блогспоте, возможно расширим этот раздел.

KVM не описывается, т.к. стандарт напрямую не налагает требований к виртуальным машинам. Единственное, что было близко - это 2.2.1 («один сервер - одна функция»)

> в педивикии в разделе Requierements вообще мега-вещи. Это любой админ локалхоста выполнить может. А CIS сейчас посмотрим, спасибо за ссылку.

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

В общем, стандарт лучше один раз увидеть самому, чем сто раз услышать :) С течением времени будем публиковать этот материал на русском на securitylab.ru, сразу несколько глав.

>странно, что там не предлагают проверять наклеечки на корпусе системного блока.

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

Не всегда осуществимо

В стандарте есть волшебная фраза в 5й (антивирусной) главе - «нужно ставить АВ, если есть подходящая технология».

Одно дело, если у Вас сервер и туда можно нормально ставить сторонний софт. Другое дело - если это не сервер, а точка доступа со своей прошивкой. Чтобы туда внедрить хотя бы ClamAV, нужно 1. пересобрать его или найти под эту архитектуру 2. сменить прошивку точки доступа.

Вряд ли смена прошивки может рассматриваться как «подходящая технология».

PCI DSS, какая версия? Есть что нибудь по PCI PTS 3.0, или пусть по 2-м версиям(они в следующем апрреле протухают)? А как деривативы от PCI использованы? Просто DSS довольно таки примитивный стандард, без PTS он не полноценен.

> PCI DSS, какая версия? Есть что нибудь по PCI PTS 3.0, или пусть по 2-м версиям(они в следующем апрреле протухают)? А как деривативы от PCI использованы? Просто DSS довольно таки примитивный стандард, без PTS он не полноценен.

1. Версия 1.2.1 от июля 2009г.

2. Стандартов много, все семейство пока не рассматриваем.

3. PCI PTS пока не описываем.

4. Если стандарт примитивен, давным-давно появились бы рекомендации по настройке для него (ОС, сетевые устройства, СУБД и пр.). Но их нет. Вся публично доступная информация по применению стандарта для КОНКРЕТНОЙ операционки/железки/БД создана по принципу менеджера, который графики чертил по стенам (из «Поэмы о честном софте» Леонида Каганова). Типичный пример - «Achieving PCI Compliance with Red Hat Enterprise Linux», слишком высокоуровневый подход, а что делать админу или безопаснику, никто сказать не может. Точнее не мог :)

> Если стандарт примитивен, давным-давно появились бы рекомендации по настройке для него

Да ладно вам :-) Стандарт действительно достаточно примитивен, а «отсутствие рекомендаций» связано скорей с тем, что, во-первых, «поставщики решений» навязывают весь комплект и комплекс своих услуг; во-вторых, сотрудники «поставщиков решений» и «потребителей решений» связаны подписками о неразглашении; в-третьих, рынок решений крайне мал - в основнам, банки-эквайры и эмитенты; и в-четвертых, выдвигаемые требования настолько логичны, что их соблюдение в большинстве случаев производится «на уровне рефлексов» :-)

P.S.: экс-сотрудник ЦБ :-)

> и в-четвертых, выдвигаемые требования настолько логичны, что их соблюдение в большинстве случаев производится «на уровне рефлексов» :-)

Просто не верится, что где-то существует банк, в котором «на уровне рефлексов» решаются вопросы безопасности :)

Рефлексы бывают разные :)

>Просто не верится, что где-то существует банк, в котором «на уровне рефлексов» решаются вопросы безопасности :)

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

в-четвертых, выдвигаемые требования настолько логичны, что их соблюдение в большинстве случаев производится «на уровне рефлексов» :-)

Далеко не все требования PCI DSS настолько логичны (ИМХО самые простые для чтения и понимая - в главах 8 и 10). Взять для примера главу 7. Там всего 2 технически реализуемых требования, но разграничение прав пользователей и доступа к данным - это много подсистем, ни одну из них нельзя упускать из вида.

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

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

гм, всё это делается в нашем банке. мне кажется вышеперечисленное стандартные функции какой-нибудь Active Directory (только пароль начальный для новых юзверей одинаковый). Это при том, что вцелом IT инфраструктура не слишком, эээ, sophisticated. Открытых технологий нет, повседневное управление на плечах эникейщиков, roaming profiles нет, radmin ломаный, бэкапов для юзеров можно сказать нет, централизованных хранилищ рабочих док-ов тоже почти нет, технологии предпочитают покупать готовые (и, нередко, мучиться потом с ними), вместо того чтобы тратить деньги на изучение и доводку свободных. UPSы и те сгорели гыгыгы. Полная винда, полуручное управление всем. Сервер ДБО девачки ДБОшницы админят мышкой по тому же крякнутому эрадмину. Сервак (вездесущий банксофт сис, тудыть его) запущен на вендосерваке в сеансе юзера. Прикрутить выносную админскую консоль никто ниасилил. Т.е. в итоге, что куплено у, грубо говоря мелкософта, то и автоматизировано. Что не куплено или не подходит по дефолту - многое просто в ручную делается. И секурности там не то чтобы очень много.

Подозреваю, что вышеописанная ситуация, с некоторыми отклонениями, существует в (подавляющем) большинстве наших организаций. Интересно, а в этом стандарте, уделяется какое-нибудь внимание терминалам и терминальным серверам? ИМХО, в любой организации численностью свыше полутора землекопов, только терминалы могут обеспечить нормальную инфраструктуру работы юзеров, и, в конце концов, задать здоровую атмосферу в IT-инфраструктуре и оставить больше времени и возможности работе над security-состовляющей. Долой воркстейшны! Sun Ray и LTSP в массы!

В общем, стандарт лучше один раз увидеть самому

а он где? можно (и даже нужно) на английском

о, отлично. годно. вот только сама сертификация стоит совсем нехилых денег :( а PCI DSS compliant != PCI DSS certified.

>а он где? можно (и даже нужно) на английском

Вам нужна версия 1.2.1 PCI DSS от июля 2009 года. По ссылкам оригинал и перевод на русский:

https://www.pcisecuritystandards.org

http://www.pcisecurity.ru/

Интересно, а в этом стандарте, уделяется какое-нибудь внимание терминалам и терминальным серверам?

Да, терминалы форевер, по прошлой работе - строили большую ИС, где операторы сидели на тонких клиентах, ощутили все удобства такого подхода. Четких требований стандарта PCI DSS на терминалы нет, но с другой стороны никто не мешает их использовать. В главе 3 есть требования по тому, чтобы на узлах не хранилась определенная информация по карточкам - как раз в случае использования терминалов это проще обеспечить.

И секурности там не то чтобы очень много.

А у Вас ее «не очень много» в каждом отделе? оО Просто этот стандарт не затрагивает, скажем, секьюрность платежей ЖКХ :) Его область применения - только операции над пластиком.

>о, отлично. годно. вот только сама сертификация стоит совсем нехилых денег :( а PCI DSS compliant != PCI DSS certified.

Спасибо за добром слове :) На вопрос цены сертификации мы можем повлиять только косвенно - описав, что примерно потребуется для выполнения части этих требований. Потому что у многих людей первая (из цензурных) мыслей при прочтении PCIDSS - «его марсиане, что ли, писали?».

Допустим, Ваша компания хочет получить заветный статус. Вызывает консультанта. Он что-то предлагает/делает сам, чтобы система удовлетворяла нужным требованиям. Компания платит ему опр. сумму. Так вот, насчет цены - если сотрудники ИТ- и ИБ-подразделений будут подкованы, как настроить это самим, то консультанту (по крайней мере в теории) можно будет заплатить меньше ;).

К тому же, возможно, будем публиковать работы не только по Linux, но и по другим ОС / БД / сетевому оборудованию. Подходы там будут почти теми же, что и в уже опубликованной работе (и дальнейшем цикле).

> Компания платит ему опр. сумму. Так вот, насчет цены - если сотрудники ИТ- и ИБ-подразделений будут подкованы, как настроить это самим, то консультанту (по крайней мере в теории) можно будет заплатить меньше ;).

основна оплата консультанту/проверяющему (а, как правило, это одно и то же лицо), идет именно за проверку и сертификацию. консультации хоть и стоят денег, но опциональны и не так дороги как сама сертификация.

> но опциональны и не так дороги как сама сертификация.

имеются ввиду консультации вида «а как бы мне сделать так чтобы все было зашибись?» а не замечения и дополнения в процессе сертификации.

>Его область применения - только операции над пластиком.

Да, это так, только система операций над пластиком должна быть изолирована иначе требования должны быть применены ко всей системе.

>Да, это так, только система операций над пластиком должна быть изолирована иначе требования должны быть применены ко всей системе.

Именно, требования изоляции есть по крайней мере в 1й главе.

Про меня чуть морально не убил примел банка с ломаным радмином.

>Вам нужна версия 1.2.1 PCI DSS от июля 2009 года. По ссылкам оригинал и перевод на русский:

https://www.pcisecuritystandards.org

спасибо, поинтересуюсь.

Да, терминалы форевер,

увы, вендо-IT этого не понимает... вернее там никому в голову не приходило строить IT-инфраструктуру как-то кардинально иначе, чем просто «много компов с вендой». а сейчас менять что-то кардинально никто не будет.

А у Вас ее «не очень много» в каждом отделе?

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

Про меня чуть морально не убил примел банка с ломаным радмином.

ну люди-то там простые были очень (которые решения принимали). делали как знали видимо, а знали они в основном свои домашние компы с 98(когда-то еще) виндой. отсюда и такая непосредственность. А вот так настраивалась некая «транспортная машина» - мне, как почетному эникейщику поручалось поставить на неё винду (лицензия, всё чин-чином. оемовская, корпоративную никто купить не решился, и что такое сервак для установки венды по сетке естественно тож никто не знает) а на неё (венду) требовалось поставить ЛОМАНЫЙ THE BAT, который и должен что-то там отсылать в, наверное, ЦБ. Вот такое АЙТИ. Вроде и задумки на ново-открываемых допиках юзать терминалы, да так задумками и остались.

P.S. когда-то читал, что украинский (вроде?) Приват Банк «перешел» на Линукс. Не в курсе как там и что (в т.ч. и с карточками)?

>P.S. когда-то читал, что украинский (вроде?) Приват Банк «перешел» на Линукс. Не в курсе как там и что (в т.ч. и с карточками)?

Сам не сталкивался, но, по их официальному блогу, на Linux они перешли:

http://privatblog.com.ua/?p=214

Судя по описанию рабочего процесса, им под свои же веб-приложения терминалки как раз и подойдут.

Русская версия

Вышла на секлабе:

http://www.securitylab.ru/analytics/395901.php