Да поможет нам 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 покажется вам тоже полезным.

Продать Безопасность

Условия задачи.
Есть крупный холдинг Х. Услуги ИТ он покупает у безальтернативного поставщика Т на основе сервисной модели - т.е. набор продаваемых Т услуг по поддержке ИТ инфраструктуры и прикладных приложений определен, имеются известные параметры, определяющие качество оказываемых услуг.

Т имеет в своем составе подразделения ИБ, которые должны отвечать за "свою часть", причем "своя часть" тоже формально детерминирована как набор сервисов ИБ, определены метрики по этим сервисам.

Х представляет собой набор отдельных предприятий. Предприятия разбросаны по разным частям мира - регионам. Каждое предприятие контрактуется с Т отдельно на определенный перечень ИТ-услуг.

Корпоративная безопасность представлена либо в виде представителя на предприятии, либо представителем в регионе. В его обязанности, помимо всего прочего, входит обеспечение соблюдения корпоративных стандартов уровня холдинга, в том числе и в области ИБ.

Найти.
Необходимо найти эффективный способ продажи услуг безопасности.

Проблема.
Сложность заключается в том, что продать услуги ИБ предприятию в "чистом виде" (с использованием прямых договоров на обеспечение ИБ между Т и Х, как это делается в случае сервисов ИТ) достаточно проблематично по ряду причин:

1. Сложно объяснить руководству предприятия необходимость обеспечения "заданного уровня" ИБ. ИБ - это затраты, как и ИТ. Логично желание любого предприятия сократить непрофильные затраты. Но с ИТ еще более или менее понятно: надо чтобы компьютер работал, rbc.ru открывался, телефон дозванивался... А вот необходимость ИБ надо объяснять, рассказывая о том, как ИБ предотвращает утечки данных и т.п. Согласитесь, такой ликбез - не функция подрядчика Т, но, вместе с тем, логично, что это - функция регионального представителя.

1'. "Заданный уровень ИБ" приходит из корпоративного центра Х, но объяснить это из подрядной организации практически невозможно. Тут аналогия такая, - например, вы приходите к парикмахеру и заказываете стрижку в Н рублей, а парикмахер вам отвечает, что вам, уважаемый, нужна стрижка за К рублей (К > Н) и прибавляет: "Мне ваше начальство сказало". Разумно возмущение с вашей стороны, мол, почему ваше руководство не сказало это вам, но сказало парикмахеру?!

2. Очень часто услуги ИБ и ИТ оказываются в рамках одного и того же сервиса, и ,как следствие, тяжело разделимы. Ну, например, возьмем сервис "Поддержка рабочей стации пользователя". Вполне возможно, что наряду с типовыми офисными приложениями и ОС, которые традиционно поддерживает ИТ, на рабочих станциях развернуты еще какие-либо системы безопасности, централизованно управляемые со специализированных консолей. Вот эти системы безопасности уже поддерживаются командой ИБ из состава Т. Причем, вполне возможно, что администратор ИБ - администратор приложения, а ОС и другое системное ПО поддерживается службами ИТ. Как отмечалось в условиях, внутри Т нет конфликта управления, и кто что делает по поддержке рабочей станции известно командам ИТ и ИБ. В итоге, как мне кажется, продать отдельно составляющие безопасности здесь более чем нелогично.

3. Безопасность сама по себе не имеет смысла. Это - сугубо прикладная деятельность. Т.е. она всегда предполагает, что есть некий бизнес-процесс, безопасность которого обеспечивается. Бизнес-процсс можно рассматривать как некий множитель безопасности. Если множитель - 0, то и эффект от безопасности - тоже нулевой. Безопасность ради безопасности - пустая трата денег.

Решение.
Учитывая все вышесказанное, разумным представляется продажа услуг/компонент ИБ внутри услуг ИТ. Это, на мой взгляд, абсолютно логично, так как каждый процесс ИТ имеет составляющую ИБ, и не надо пытаться ее вырезать и продавать отдельно. В итоге Т будет продавать услуги ИТ, обеспечивая "заданный уровень ИБ", спущенный из корпоративного центра Х.

На "Информационная безопасность и бизнес-стратегия фирмы"

Я никогда бы и не узнал о статьях господина Сачкова, если бы он раньше не работал в компании, где я сам тружусь.

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

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

1. "Без эффективного менеджмента и понимания бизнес-стратегии компании на подразделения ИБ будут смотреть как на подразделения, не приносящие доход. Управление ИБ на среднем уровне позволяет окупать расходы, а при хорошем менеджменте -приносить доход и делать бизнес еще эффективнее."
Классная красивая фраза, но, беря во внимание реалии жизни, я с трудом понимаю, как подразделение ИБ может приносить доход для компании, где ИБ - непрофильное подразделение. Бесспорно ИБ может повышать эффективность, снижать расходы, но вряд ли приносить доход. ИБ - это сервис бизнеса, который стоит денег. Можно говорить о ROI и TCO, но это TCO не может быть отрицательным числом. Ну а с тем, что менеджмент должен быть эффективным я, конечно, согласен.

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

Далее к статье идет комментарий Николая Ионова, эксперта Группы компаний "Антивирусный центр", который меня еще больше не порадовал.
1. "Информационная безопасность имеет развитую техническую компоненту, и именно поэтому многие не видят ее второй составляющей: организации управления. Соответственно вопросы защиты корпоративных данных зачастую пытаются переложить исключительно на плечи ИТ-службы."
Тут надо немного разобраться - вопрос уходит корнями в долгие бесконечные дебаты относительно того где разделяются полномочия ИТ и ИБ. Лично я для себя определился, что рутинные работы по обеспечению ИБ, связанные с поддержанием заданного уровня безопасности, обслуживанием систем безопасности - функция ИТ, тогда как планирование и развитие этих систем - задача ИБ. Попробую объяснить все одной фразой. Если безопасность - это процесс, то поддержание должного заданного качества этого процесса - функция ИТ, а управление этим процессом и его контроль - функция ИБ. В этой связи я считаю абсолютно нормальным, что ИТ обеспечивает защиту корпоративных данных. Можно рассматривать ИБ, как компоненту каждого процесса ИТ. Выделить эту компоненту сложно и, скорее всего, неправильно. Замечу также, что производители ИТ-систем в последнее время все плотнее интегрируют в свои системы и решения по ИБ. Если администраторы ИТ и ИБ - разные люди, кто обслуживает, например, межсетевой экран, который с т.з. ИТ - маршрутизатор, а с т.з. ИБ - пакетный фильтр?
2. "Поэтому ни в коем случае нельзя смешивать функции ИТ-отдела и отдела безопасности, более того, эти отделы не должны находиться в дружественных отношениях. У них изначально должны быть разные задачи и разные подходы к организации информационной безопасности."
Вообще бред. Я вспомнил басню Крылова: "Однажды Лебедь, Рак да Щука...". А как же общие задача по соответствию общей стратегии бизнеса? У меня нет слов, чтобы это прокомментировать, скажу лишь несколько фраз:
а) нельзя защититься от админа;
б) сервисы ИБ по-любому базируются на базовых сервисах ИТ, таких как сетевая инфраструктура, служба каталога, пр.

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

Частичная компрометация WPA - новая эра беспроводной безопасности

Вот мы и дожили до того момента, когда появились публикации о взломе, хоть и ограниченном, WPA. Лично мне, в тот момент, когда появился TKIP казалось, что это невозможно, но нет я ошибся...

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

Самой разумной контрмерой, как мне кажется является отказ от использования WPA (TKIP) и планировать переход на WPA2 (AES-CCMP).

Если нет возможности за короткое время мигрировать на WPA2, можно обезопаситься следующими временными контрмерами, могущими, по крайней мере противостоять данной атаке:

• сократить время жизни ключа TKIP; в документе говорится о 120 секундах или меньше,
• отключить оповещение клиента о неправильной сумме Michael MIC (MIC failure report frame).
• начать планировать миграцию на WPA2/802.11i, ибо данный взлом показывает, что TKIP невольно наследует проблемы WEP и стоит ожидать что горячие головы будут развивать эту тему.

Дополнительная информация:

• http://www.securityfocus.com/news/11537
• http://dl.aircrack-ng.org/breakingwepandwpa.pdf
• http://radajo.blogspot.com/2008/11/wpatkip-chopchop-attack.html
• http://www.securityfocus.com/infocus/1824
  

Верить нельзя доверять

Когда проводишь работы по аудиту, никогда не уверен в том, как выполнишь работу, оценивают которую обычно, увы, не по качеству отчета и полноте охвата анализа ИС заказчика, а по результатам теста на проникновение (когда его купил клиент).
Но речь ниже пойдет не о полезности тех или иных видов аудита, а о повышении вероятности проникновения в сеть заказчика.
Итак, выезжаем к клиенту, сеть которого является неприступной. Бьемся о бесчисленные системы блокировок и ограничений и ничего не можем сделать - объем мозга недостаточен. Самое время заняться социальной инженерией. Разного рода забавы в стиле "инженер техподдержки" и "новый администратор" оставим на совсем черный день. Попробуем что-нибудь околотехническое.
Давайте не будем возить на аудиты свою флешку. Многие люди будут недоумевать, когда узнают об ее отсутствии и... начнут приносить материалы на своих носителях. Естественно, в 99% случаев это usb-брелоки и еще в 80%, носители принадлежащие техническому персоналу.
Работы будем выполнять под Linux с работающим udev.
Немного подкорректируем файл настроек подсистемы:
/etc/udev/local.rules
-----------
KERNEL=="sd*", BUS=="usb", ACTION=="add", SYMLINK="usbdevices/usbflash"
KERNEL=="sd*", BUS=="usb", ACTION=="add", RUN+="/bin/sh -c '/bin/dd if=/dev/usbdevices/usbflash of=/tmp/`date +%F_%R`_dump'"
-----------
Перезагрузим демон.
#/etc/init.d/udev restart

Благдаря этому нехитрому файлику, носители, которые клиенты доверчиво "суют" в компьютер чужаку, в бакграунде побитно копируются на ноутбук в директорию /tmp в формате год-месяц-день_час:минута_dump. Пока аудитор из под кривой ОС руками смонтирует флешку, пока скопирует файл в жутком mc, на диске сохраняется образ флешки, включающий в себя, в том числе, удаленные ранее файлы, среди которых могут оказаться так нужные для проведния пентеста данные.

Вывод:
Будьте аккуратны со своими носителями, "не суйте их куда попало" не только во время проведения у Вас аудита, но и в обычной жизни.

Социальная инженерия? Гослотерея!

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

Я обратил внимание на огромное количество рекламы новой Государственной лотереи. В принципе, ничего необычного, государство решило подзаработать, если бы не экономический кризис....

Король Франции Франциск I еще в 16-м веке (в 1539 году, если быть точным), переняв идею лотерей у итальянцев, использовал государственные лотереи всякий раз, когда казна нуждалась в пополнении....

Не хочется думать, что у России аналогичная причина, а запуск проекта "Гослото" просто совпал с кризисом. С другой стороны вполне нормально проявить патриторизм и помочь Государству средствами, - ведь кто если не мы? Только хочется, все-таки, чтобы истинные причины тоже доводились до населения, - как-никак Гласность.

Где разместить IDS/IPS, в аналогиях

Я принимаю участие в проекте по построению безопасного шлюза в Интернет. Шлюз состоит из межсетевого экрана (МЭ), системы фильтрации Web-трафика с функцией кеширования (прокси-сервер) и системы IPS или IDS. Что касается того, где разместить прокси-сервер, то здесь вопросов не возникало: всем интуитивно понятно, что проси надо размещать за межсетевым экраном со стороны внутренней сети, а вот местоположение IDS/IPS почему-то не для всех является так очевидным. Вообще, вещи, о которых тут пойдет речь кажутся более чем понятными интуитивно, поэтому, для кого нет секретов в местоположении точки включения IDS/IPS в схеме безопасного шлюза в Интернет, – не тратьте время на чтение этого поста.

Традиционный МЭ, как правило, не «заглядывает» в сетевые пакеты выше уровня 4 модели OSI: он выполняет пакетную фильтрацию с контролем состояний (stateful) по IP-адресам и портам TCP/UDP. Да, последнее время популярны МЭ с тонкой фильтрацией до уровня приложения и встроенным IPS, – так называемые, UTM, но это – совсем другая история, не наш случай (да и вообще, мне кажется, неразумным хранить все яйца в одной корзине). Прокси–сервер уровня приложения, обычно, знает несколько протоколов, которые он проксирует. Он, как правило, не знает о существовании сетевых атак, не проводит анализ поведения, не выявляет отклонения от RFC (хотя, иногда можно, настроить прокси так, чтобы он проксил только соответствующий RFC трафик) и прочие аномалии.

IPS. Если очень поверхностно, то IPS – система прецизионной фильтрации сетевого трафика. Она анализирует не только все уровни модели OSI – до уровня приложения включительно, но еще, как минимум, может смотреть отклонения от RFC (или прочих стандартов) известных ей протоколов, блокировать известные сетевые атаки на основании сигнатурного анализа, вести статистический учет сетевого трафика на основании разнообразных метрик, проводить анализ поведения объектов в сети и на его основе различным образом реагировать. В этой связи IPS можно сравнить с системой тончайшей очистки… Представьте себе водоочистную станцию, состоящую из ряда фильтров: фильтр грубой механической очистки, фильтр тонкой очистки и фильтр тончайшей очистки. Разумное расположение этих фильтров таково, что из водозабора грязная вода сначала проходит фильтр грубой механической очистки, где очищается все то, что не стоит пить: камни, песок, крупные примеси. Затем логично поставить фильтр тонкой очистки, который превратит воду в практически питьевую, но только, скажем, после кипячения. Непосредственно перед потребителем имеет смысл поставить фильтр тончайшей очистки, который сделает из «практически» питьевой воды, просто питьевую, которую не надо будет дополнительно для этого обрабатывать, удалив все известные на сегодня бактерии и прочие отклонения от нормы. Если «подставить слагаемые»: МЭ – грубая очистка, Прокси – тонкая, IPS – тончайшая, то логично, на мой взгляд, IPS ставить ближе к защищаемому объекту, потребителю, следовательно, схема подключения будет такая Пользовательские рабочие станции – IPS – прокси – МЭ – Интернет.

IDS может определять все то же самое, что и IPS, но отличается возможностями по реагированию. IDS, в случае обнаружения чего-либо будет ругаться, но активно что-то предпринять не сможет, тогда как IPS, включенная в разрыв (Inline) может сразу и заблокировать обнаруженное Зло. Здесь IDS можно сравнить с неким индикатором состояния, термометром…. Представьте себе тело человека, зима. На человеке одета куртка, защищающая его, скажем от осадков, свитер, не пропускающий холод. Где мы будем мерить температуру тела человека? Между курткой и улицей? Наверно нет. А может, между курткой и свитером? Скорее всего, тоже нет. Логично располагать градусник ближе к телу, мы же его состояние хотим проанализировать. Следовательно, ситуация с IDS ровно такая же как и с IPS – точку съема трафика располагаем между рабочими станциями пользователей и Прокси.

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

Надеюсь, что это чтиво не было для Вас утомительным, и, также как у меня, у Вас на лице была улыбка.