вторник, 25 сентября 2018 г.

PDCA для менеджмента уязвимостей

В прошлый раз я уже отметил появление в нормативных документах ФСТЭК итерационного подхода PDCA к совершенствованию мер защиты. Раздел приказа 235, посвященный этому вопросу (п. 28-37) сформулирован довольно общими словами: например, из текста неочевидно, о планировании, реализации, контроле и совершенствовании каких именно мероприятий идет речь. Такая неопределенность позволяет оператору информационной системы самостоятельно решать, как именно реализовывать такой подход. Например, если бы мне понадобилось выстраивать процесс менеджмента уязвимостей на значимом объекте КИИ, получилось бы примерно следующее.

P = Планирование

Задача менеджмента уязвимостей сформулирована в приказах ФСТЭК довольно жестко: к моменту приемки (для ГИС - аттестации) по результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, как минимум содержащиеся в банке данных угроз безопасности информации ФСТЭК России, или выявленные уязвимости не приводят к возникновению угроз безопасности информации (п. 12.6 приказа 239, п. 16.2 приказа 17). Очевидно, что регулятор считает это одним из необходимых условий безопасного состояния информационной системы.

Для буквального выполнения этого требования достаточно выявлять и устранять уязвимости, публикуемые в БДУ ФСТЭК, что соответствует мере защиты АУД.2. Содержание этой меры еще не раскрыто в методических документах, но она соответствует мере защиты АНЗ.1, описанной в методическом документе "Меры защиты информации в ГИС", так что можно ожидать, что и ее содержание будет очень похожим, Та, в свою очередь требует проводить сканирование компонентов информационной системы с помощью средства анализа защищенности (обязательное усиление 1) и делать это с периодичностью, которую определяет само оператор. Таким образом, в рамках реализации меры защиты АУД.2 нам нужно предусмотреть мероприятие "Сканирование информационных систем и устранение выявленных уязвимостей", которое мы будем выполнять периодически.

В действительности, если мы всерьез занимаемся вопросами безопасности своих информационных систем, в процессе менеджмента уязвимостей нам нужны и другие мероприятия, например:

  • проверка настроек, значимых с точки зрения безопасности (например. на основе чеклистов);
  • отслеживание публикаций о появлении уязвимостей нулевого/первого дня;
  • анализ уязвимостей внедряемых или модернизируемых информационных систем (black-box анализ, анализ исходных текстов и т.п.).

Каждое из них тоже проводится или с заданной периодичностью (проверка настроек, просмотр фидов), или в соответствии с заранее известным план-графиком (анализ уязвимостей при приемке). Так или иначе, мы действительно можем заранее запланировать, как часто в течение года нам нужно будет все это проделывать, какие инструменты нам для этого нужны и в какие трудозатраты это выльется.

Упростим себе задачу и и ограничим процесс менеджмента уязвимостей только уязвимостями, которые обнаруживают сканеры. Организационно наше мероприятие будет выглядеть примерно так:

Ответственное подразделение (назовем их SOC) с заданной периодичностью сканирует информационную систему. По результатам сканирования могут обнаружиться уязвимости, требующие устранения. Заявку на устранение этих уязвимостей со своими рекомендациями по устранению SOC передает в IT. IT ищет способ устранить уязвимость - спектр возможных решений может варьироваться от установки обновления до модернизации системы (например. если уязвимое ПО больше не поддерживается разработчиком). В случае успешного оперативного устранения IT сообщает об этом в SOC, и при следующем сканировании устранение будет подтверждено. Устранение уязвимостей, требующих длительной работы, будет подтверждено на последующих итерациях сканирования, когда изменения наконец будут внесены в систему.

На стадии планирования мы можем формализовать цели процесса:

  1. Все уязвимости, пригодные для реализации угроз (экплуатабельные), должны устраняться. При этом понятие "эксплуатабельность" можно формализовать в виде конкретных элементов вектора CVSS.
  2. Эксплуатабельные уязвимости должны устраняться своевременно. При этом понятие "своевременно" можно тоже формализовать как "среднее время присутствия уязвимости в ИС не должно превышать К дней".

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

  1. Предельно допустимое время обнаружения уязвимости (в данном примере - с момента начала очередной итерации до момента выдачи подразделению IT заявки на устранение уязвимостей).
  2. Предельно допустимое время устранения уязвимости (с момента получения заявки до того момента, как устранение уязвимости будет подтверждено).

Первый показатель говорит нам, с какой периодичностью нам нужно повторять итерации процесса. При этом:

  1. Зная количество серверов и рабочих мест в информационной системе, а также среднее время сканирования одного узла, мы можем оценить, сколько сканеров нужно нашему SOC.
  2. Зная, сколько времени в среднем тратится одним специалистом на обработку результатов сканирования, мы модем оценить, сколько специалистов нам нужно, чтобы уложиться в норматив.

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

D = Реализация

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

C = Контроль

По смыслу требований приказа 235, контроль процесса (в терминах приказа - "контроль состояния безопасности") включает в себя две составляющие:

  1. Проверка того, что требования по выявлению и устранению уязвимостей (требования к реализации мер АНЗ.1 приказа 17 или АУД.2 приказа 239) действительно выполнятся.
  2. Оценка эффективности этих мер

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

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

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

A = Совершенствование

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

  1. Точность измерения (т.е. как часто мы сканируем систему)
  2. Время, затрачиваемое на основные операции (опять же, как часто мы сканируем систему плюс время, затрачиваемое на анализ результатов, плюс время, в течение которого уязвимость реально устраняется).

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

Анализ результатов сканирования - занятие чуть более сложное. Когда человек первый раз сканирует отдельный компьютер - результаты ужасают: в моей практике встречались рабочие места, на которых обнаруживалось 600-800 непропатченных уязвимостей. Даже просто просмотреть результаты такого сканирования - колоссальная работа. Но если начинать работу не с такого запущенного случая, а сперва принять волевое решение накатить на наиболее распространенные компоненты информационной системы все рекомендованные разработчиками обновления, сложность анализа дальнейших результатов сканирования снизится на порядок. При этом в каждом следующем сканировании нам придется анализировать только новые уязвимости, которые попали в базу знаний сканера вместе с очередным обновлением сканера - и таких уязвимостей в нашей системе будет всего пара десятков. Т.е., когда процесс стабилизируется, анализ сканирования одной информационной системы будет занимать не больше одного рабочего дня - при условии, что сканирование и анализ результатов проводится достаточно часто, например - еженедельно.

При большом количестве информационных систем трудозатраты на анализ масштабируются отнюдь не линейно. Состав программного обеспечения двух раных информационных систем, построенных на основе общей платформы (например, на одной серверной операционной системе Microsoft Windows или на одном дистрибутиве Linux) может совпадать на 60-80%.  Сканируя все эти информационные системы и консолидируя результаты, мы переходим от анализа уязвимостей отдельных информационных систем к анализу уязвимостей определенного перечня программ. Эта задача хорошо распараллеливается, и при этом можно выполнять одновременный анализ уязвимостей большого количества информационных систем небольшим количеством специалистов. И чем выше степень унификации ПО в нашей инфраструктуре, тем ниже удельные трудозатраты на анализ уязвимостей.

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

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

Что в результате?

А в результате мы получаем одновременно и формальное выполнение требований регулятора, и постепенное, эволюционное развитие мер защиты. В самом начале, создавая систему защиты "с нуля", мы можем установить себе "щадящие" нормативы и целевые значения. Оценка покажет, что своей цели мы не достигли, и на следующей итерации мы постараемся процесс улучшить. Оценим результат, увидим, что у нас ничего не получилось - и на следующей итерации попробуем другое решение. И так далее, пока результат не начнет нас устраивать.

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

вторник, 11 сентября 2018 г.

Эволюция нормативных требований к менеджменту уязвимостей


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


Темные века (1992-1999 г.)

В начальный период истории российской ИБ нормативные требования по защите информации (требования по защите государственной тайны в этой и остальных публикациях не рассматриваю принципиально) предъявлялись только к государственным информационным системам, и основным нормативным документом являлись «Специальные требования и рекомендации по технической защите конфиденциальной информации». Если опустить организационные меры, защиту речевой информации и защиту от утечек по ПЭМИН, то в сухом остатке имеем:

  1. Информационная система в целом должна соответствовать требованиям руководящего документа «Классификация автоматизированных систем и требования по защите информации» (РД АС).
  2. Операционные системы должны соответствовать требованиям руководящего документа «Средства вычислительной техники. Показатели защищенности от несанкционированного доступа к информации» (РД СВТ). А поскольку таких в тот момент не было, приходилось устанавливать на обычные ОС специализированные средства защиты информации от несанкционированного доступа, “доводящие” ОС до соответствия требованиям этого документа.
  3. На сетевом периметре должны применяться межсетевые экраны, соответствующий требованиям «Средства вычислительной техники. Межсетевые экраны. Показатели защищенности от несанкционированного доступа к информации» (РД МЭ).
  4. Должны применяться антивирусы. Как применяться и что они должны уметь – не определено.

Во-первых, почитав упомянутые документы, можно заметить, что они предъявляют требования к функциям, которые должны выполнять механизмы безопасности, но ничего не говорят о качестве реализации этих функций. Например, тот факт, что известная ERP при аутентификации пользователя использовала только первые восемь символов пароля и игнорировала регистр, не мешал ей соответствовать требованиям РД. Во-вторых, в нормативных документах того времени понятие “уязвимость” отсутствовало, а сама возможность взлома информационной системы с использованием уязвимостей рассматривалась как нечто гипотетически возможное.

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

Есть у описанного подхода и другая проблема: проектировщики информационных систем иногда буквально исполняли требования РД, не заботясь о смысле этих требований. Документ требует, чтобы в информационной системе были определенные функции безопасности? Хорошо, мы установим в операционную систему средства защиты, которые эти функции выполняют. Что говорите, пользователи работают через веб-интерфейс и эти функции нужно реализовать в веб-интерфейсе? А в документе об этом прямо не сказано, так что “к пуговицам претензий нет”. Да, это вопрос добросовестности проектировщиков и тех, кто подписывает для таких информационных систем аттестаты соответствия. Но с подобным приходится встречаться и сегодня.

Средние века (1999–2010 г.)

В июне 1999 г. комплект РД был дополнен четвертым документом – «Программное обеспечение средств защиты информации. Классификация по уровню контроля отсутствия недекларированных возможностей». Сертификация на соответствие требованиям этого документа требует предоставления испытательной лаборатории исходного кода программ, а в самом документе упоминается статический и динамический анализ этого кода. До сих пор многие считают, что сертификация на уровень контроля отсутствия НДВ означает проверку отсутствия уязвимостей, – и это глубокое заблуждение.

Действительно, среди выполняемых проверок есть “синтаксический контроль наличия заданных конструкций в исходных текстах ПО из списка (базы) потенциально опасных программных конструкций” - и на этом все. На момент принятия документа перечня “потенциально опасных конструкций” еще не было, и первые серьезные работы по классификации уязвимостей и систематизации ошибок, которые приводят к их появлению, начались более, чем через десять лет после принятия документа. В остальном контроль отсутствия НДВ, и в том числе – динамический анализ кода, заключается в выявлении фрагментов кода, которые “непонятно, что делают”, в том числе – программных закладок.

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

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

Эпоха Возрождения (2010-2013 г.)

Первой ласточкой будущих изменений стало принятие в качестве руководящих документов семейства международных стандартов Common Criteria (ISO 15408 и ISO 18045). Документы предусматривают, в частности, в зависимости от уровня доверия к результатам оценки, проведение проверки того, что установлены все необходимые обновления безопасности, а также проведение самостоятельного поиска уязвимостей разработчиком и независимого поиска уязвимостей оценщиком. К сожалению, стандарт, который изначально позиционировался как методика покомпонентной оценки защищенности сложных информационных систем, и в России, и за рубежом применяется только для сертификации отдельных средств защиты, и в этом смысле ничего полезного с точки зрения борьбы с уязвимостями в информационных системах он так и не добавил.

Зато в 2010 году был принят принципиально новый по своей сути приказ №58 о методах и способах защиты информации в информационных системах персональных данных. Документ официально признавал опасность использования программных уязвимостей нарушителем и требовал:

  • применять средства обнаружения вторжений;
  • проводить поиск и устранение уязвимостей с помощью средств анализа защищенности.

Добросовестное выполнение этих требований уже могло заметно изменить картину: новые меры защиты требовали устранять известные уязвимости “серийного” программного обеспечения и одновременно отслеживать попытки применения известных эксплойтов. Методы, которые позволили бы обнаруживать уязвимости в заказных компонентах, в документе отсутствовали. На даже в таком урезанном виде новые меры защиты в нашем примере способны сильно усложнить жизни атакующим. Применение WAF в качестве средства обнаружения вторжений отсечет скрипт-кидди и заставит более продвинутых нарушителей пытаться искать способы обхода фильтрации контента WAFом, а это - очень нетривиальная задача.

Да, документ был обязателен только для информационных систем персональных данных. Да, этих мер недостаточно для защиты от APT. Но уж такой примитив, как WannaCry и Petya, эти меры остановить способны. Жаль только, что “еж – птица гордая, пока не пнешь – не полетит”, и даже такие очевидные меры защиты полноценно реализуются далеко не во всех информационных системах.

Новейшая история (2013 г. – н.в.)

Кардинально изменил ситуацию в подходе к регулированию приказ ФСТЭК №17, принятый в 2013 году, и дополняющий его методический документ “Меры защиты информации в государственных информационных системах”.

Во-первых, документ предписывает формировать требования безопасности, основываясь на анализе уязвимостей (на стадии проектирования – потенциальных, на стадии внедрения – реальных, свойственных выбранным компонентам, на стадии приемки – фактических, присутствующих в системе здесь и сейчас). Причем в ходе приемки требуется доказать, что в системе нет уязвимостей или что имеющиеся уязвимости невозможно использовать. В редакции 2017 года в документ была добавлена обязанность проводить тестирование на проникновение при приемке системы – и это отчасти решает проблему “отсутствия претензий к пуговицам”. Пентестеров не интересует, что именно написано в требованиях к системе, они ищут способы реализовать какие-либо угрозы. И если угрозу реализовать удается, это – недоработка, требующая безусловного устранения независимо от того, что написано в требованиях к системе. Правда, по-прежнему остается открытым вопрос добросовестности и квалификации специалистов, проводящих приемку.

Во-вторых, в базовые требования безопасности включен целый ряд мер, направленных на противодействие использованию уязвимостей:

  • анализ и устранение уязвимостей (АНЗ.1) и контроль установки обновлений (АНЗ.2);
  • защита от брутфорса паролей (ИАФ.3);
  • анализ событий безопасности, свидетельствующих о возможном инциденте (все семейство РСБ);
  • анализ уязвимостей и обнаружение вторжений (семейства АНЗ и СОВ) и т.п.

Отдельное направление регулирования – это требования к SDLC, обязательные для разработчиков, планирующих сертифицировать свои решения в системе сертификации ФСТЭК, и рекомендательные для остальных. Стандарт предписывает проводить анализ угроз для создаваемого приложения и определять фичи продукта, необходимые для противодействия этим угроззам. Стандарт определяет целый ряд мер контроля качества кода: стандарты оформления кода (фактически coding standards), экспертизу кода, статический и динамический анализ для поиска уязвимостей и т.п. Взамен третьей части ГОСТ 15408 (требования доверия при оценке защищенности информационных систем) принят новый документ, определяющий уровни доверия и соответствующие им меры контроля в рамках SDLC. В частности, для всех программных компонентов, реализующих функции безопасности государственных информационных систем (кроме низшего класса защищенности), становится обязательным проведение анализа исходного кода.

Второе интересное направление – это работа с уязвимостями нулевого дня, заслуживающая отдельной публикации. Если коротко, то в соответствии с новым регламентом ведения Банка данных угроз и уязвимостей, ФСТЭК получает функции по координации взаимодействия между исследователем, обнаружившим уязвимость нулевого дня, и разработчиком, в решении которого уязвимость найдена. Эту же функцию выполняют и зарубежные CERT/CSIRT, но в случае БДУ ФСТЭК есть интересный нюанс: в силу требований все того же приказа №17 попытка разработчика проигнорировать сообщение об уязвимости фактически закрывает для него весь государственный сектор. Не знаю, как это повлияет на зарубежных производителей, но по опыту взаимодействовать с отечественными разработчиками порой даже сложнее, чем с зарубежными.

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

пятница, 31 августа 2018 г.

Процесс управления уязвимостями в контексте нормативных документов ФСТЭК

"Я не злопамятный, я записываю" (с) Бывает, подискутируешь в комментах у кого-нибудь, возьмешь паузу на подумать – и опаньки: и дискуссия, и инфоповод скрылись бесследно. И что, зря старался, думал? Придется, видимо, реанимировать блог на такой случай.


Алексей Лукацкий как-то задал разумный вопрос:

А действительно, надо ли устранять их все? И требует ли этого регулятор?

Для начала стоит разобраться, к кому именно в нормативных документах ФСТЭК предъявляются требования об анализе и устранении уязвимостей. Дело в том, что эти требования разделяются на три группы:

  1. Требования, которые предъявляются к информационной системе в процессе ее эксплуатации и которые должны выполнняться оператором этой системы.
  2. Требования, которые предъявляются к информационной системе в процессе ее создания/приемки и которые должны выполняться разработчиками этой системы.
  3. Требования, которые предъявляются к программному обеспечению, претендующим на звание "безопасное" (в том числе - к сертифицируемым средствам защиты) и которые должны выполняться вендорами (разработчиками или заявителями)

Требования, предъявляемые к средствам защиты и прочему безопасному ПО, - предмет отдельного обсуждения, их мы рассмотрим в другой раз. К слову: Алексей имел в виду именно этот случай, хотя участники дискуссии, судя по комментариям, восприняли это как обсуждение установки обновлений безопасности.

Требования к информационной системе в процессе ее создания определяются в трех из четырех приказов ФСТЭК для трех разных случаев (ГИС, АСУ ТП и значимые объекты КИИ) совершенно одинаково:
16. Внедрение системы защиты информации информационной системы организуется обладателем информации (заказчиком). Внедрение системы защиты информации информационной системы осуществляется в соответствии с проектной и эксплуатационной документацией на систему защиты информации информационной системы и в том числе включает:
  • ...
  • анализ уязвимостей информационной системы и принятие мер защиты информации по их устранению;
  • приемочные испытания системы защиты информации информационной системы.

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

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

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

По результатам анализа уязвимостей должно быть подтверждено, что в информационной системе отсутствуют уязвимости, содержащиеся в банке данных угроз безопасности информации ФСТЭК России, а также в иных источниках, или их использование (эксплуатация) нарушителем невозможно.

Как видим, в процессе создания системы нужно проанализировать имеющиеся в ней уязвимости, а вот устранять их или нет - вопрос их эксплуатабельности. Не обязательно устранять все уязвимости, но нужно добиться того, чтобы оставшимися невозможно было воспользоваться. Приказы 31 и 239 содержат аналогичные требования, в приказ 21 этот вопрос вообще не рассматривает.

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

Менеджмент уязвимостей входит в меры защиты, которые должны быть реализованы во всех классах информационных систем:

  • для приказов 17 и 21 (и пока еще действующей редакции приказа 31) - меры защиты "АНЗ.1 Выявление, анализ уязвимостей информационной системы и оперативное устранение вновь выявленных уязвимостей" и "АНЗ.2 Контроль установки обновлений программного обеспечения, включая обновление программного обеспечения средств защиты информации";
  • для приказа 239 и новой редакции приказа 31 - мера защиты "АУД.2 Анализ уязвимостей и их устранение".

Для приказов 17 и 21 требования к мере защиты приведены в методическом документе "Меры защиты информации в ГИС". При этом отмечается:

Требования к реализации АНЗ.1: Оператором должны осуществляться выявление (поиск), анализ и устранение уязвимостей в информационной системе.

...

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

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

...

Требования к реализации АНЗ.2: Оператором должен осуществляться контроль установки обновлений программного обеспечения, включая программное обеспечение средств защиты информации и программное обеспечение базовой системы ввода-вывода.

...

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

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

Мы видим, что а) документ не требует безусловного устранения всех уязвимостей (нужно обеспечить невозможность их использования тем или иным способом) и б) оператор сам определяет порядок устранения уязвимостей и контроля установки обновлений.

Для приказов 31 и 239 подобного документа пока нет (его принятие ожидается в этом году), зато для критической информационной инфраструктуры есть интересный приказ №235, и интересен он своим последним разделом.

28. В рамках функционирования системы безопасности субъектом критической информационной инфраструктуры должны быть внедрены следующие процессы:
  • планирование и разработка мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры;
  • реализация (внедрение) мероприятий по обеспечению безопасности значимых объектов критической информационной инфраструктуры;
  • контроль состояния безопасности значимых объектов критической информационной инфраструктуры;
  • совершенствование безопасности значимых объектов критической информационной инфраструктуры.

Фактически документ вводит цикл PDCA применительно к реализации мер защиты. Оператор планирует, что именно он сделает в течение года для реализации или совершенствования меры защиты, а в конце года оценивает эффективность этой меры и принимает решение о ее совершенствовании. И вот тут прям напрашивается целый набор характеристик, которыми можно параметризовать процесс менеджмента уязвимостей и контроля его эффективности на основе KPI - благо, мы такое не раз уже делали.

Но об этом в другой раз.

вторник, 13 октября 2009 г.

О кардерах и хакерах или "героев" нужно знать в лицо

Попался мне на сайте МинЮста США один любопытный документ: “Data Breaches: What The Underground World Of Carding Reveals”. Если в двух словах – это анализ судебной практики по делам о кардинге. А поскольку в тот момент я как раз готовил доклад для круглого стола на InfoSecurity, пришелся он как раз в тему.

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

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

Возможно ли такое? Увы, более чем. Вот лишь несколько эпизодов из жизни Альберта Гонзалеса - хакера, который недавно предстал перед судом, признал свою вину и которому грозит до 20 лет тюремного заключения.

В 2007 г. Гонзалес, Максим Ястремский (Украина)  и Александр Суворов (Эстония) организовали атаку на сеть ресторанов Dave & Buster's. Система кассовых терминалов сети ресторанов образовывали своеобразную "звезду": сами терминалы передавали считанные с магнитной полосы данные на сервер ресторана, тот - на сервер головного офиса и, наконец, оттуда данные поступали на авторизацию платежа в процессинг. В апреле 2007 хакеры умудрились получить удаленный доступ к серверу одного из ресторанов и установили на него снифер. Как именно им это удалось, американская Фемида умалчивает (точнее, использует казенное "the defendants made materially false representations indicating that they were authorized to gain such access", то бишь "обошли механизмы аутентификации"). Позже они по той же схеме установили сниферы на серверы еще 11 ресторанов D&B. Перехваченные дампы просто продавались через один из кардерских форумов.

Сниферы работали до сентября 2007 года. Что характерно, прописать их автозапуск, видимо, не удалось, и при каждом перезапуске сервера ребяткам приходилось снова коннектиться к нему и запускать снифер вручную. Только в одном из ресторанов (ресторан №32, который фигурирует в обвинительном заключении) они проделали это трижды.

К слову, из 12 заявленных в преамбуле обвинительного заключения ресторанов в деле фигурирует только этот злосчастный "ресторан №32". Почему только он - загадка. Еще одна странность - относительно небольшое количестов украденных дампов (вего-то 5000). Скорее всего, речь идет именно о тех 5000 дампах, которые были обнаружены на изъятом у Ястремского при аресте нотбуке. Этот момент и стал "началом конца" для Гонзалеса и его сообщников: проведя несколько дней в турецкой тюрьме (а методы ведения допросов у турков жестоки даже по меркам российских следователей), Ястремский начал рассказывать все, что знал о своих знакомых.

Обвинительное заключение:


А впервые эта гоп-компания попала в поле зрения ФБР и Секретной Службы США еще в 2003 г., когда Гонзалес, Ястремский, Деймон Патрик Тои, Кристофер Скотт и другие организовали грандиозный вардрайвинг вокруг магазинов нескольких крупных американских торговых сетей. Гонзалес и Скотт парковались возле магазина и взламывали ее точку доступа (про то, что WEP - это одна большая ошибка, известно давно). Первое время хакеры использовали для доступа к даным различного рода уязвимости, но летом 2005 года, взломав аналогичным образом две точки доступа торговой сети TJX, они поставили свое дело на поток. Им удалось пробиться в процессинговый центр TJX, настроить VPN между процессингом и арендованным сервером и установить на сервер процессинга написанный Ястремским снифер. Отлаженный "пылесос" проработал с мая 2006 г. по март 2008 г. О количестве скопированных дампов можно только догадываться: в новостях фигурирует число 40 000 000, но это всего лишь один аплоад, который Гонзалес сделал, уже находясь под присмотром Секретной Службы, за месяц до своего ареста.

Обвинительное заключение:


Финалом карьеры Гонзалеса стала нашумевшая этой зимой атака на Heartlend Payment Systems. Если верить представителям Heartland, осенью 2008 г.  VISA предупредила их о возможной компрометации. Компания провела внутренний аудит, который не выявил ничего подозрительного. Тогда, на всякий случай, компания обратилась в Секретную Службу, специалисты которой смогли-таки найти хорошо замаскированного "троянца". Ну что ж, поздравляю вас, граждане соврамши.


Все началось с того. что Гонзалесу и его приятелю попался на глаза журнал "Fortune" с рейтингом крупнейших процессинговых компаний. Идея созрела быстро, и к делу сразу же были привлечены два "русских хакера" (в обвинительном заключении фигурирует странный регион "somewhere near Russia", хотя речь, судя по материалам дела, идет о "молодых демократиях" - Латвии и Украине). Кроме того, были арендованы 6 серверов в разных регионах для залива на них украденных дампов.

Ребятки прямо по списку двинулись изучать Web-порталы этих компаний, на трех из них были обнаружены уязвимости SQL injection, и в ноябре 2007 г. началась активная работа. Через полтора месяца (к концу декабря 2007) они уже контролировали процессинг Heartland'а, установив снифер на один из ключевых серверов. Второй процессинговый центр продержался еще месяц, а с третьим пришлось повозиться аж до марта 2008 г.

К этому моменту, опираясь на показания Ястремского, Секретная Cлужба уже практически закончила расследование атаки на TJX и вела активную работу против Гонзалеса. После своего ареста, к концу 2008 г., он уже прекрасно осознавал, во что влип, и начал давать признательные показания, в обмен на отказ от преследования по мелким делам вроде атаки на D&B. Собственно, тогда-то Секретная Служба и заявилась в Heartlend. И тем не менее, официальное уведомление об утечке компания подала только 30 января 2009 г.

Обвинительное заключение



А мораль всей этой истории очень проста. Хакер, использующий типичные ошибки, сплошь и рядом совершаемые администраторами и Web-программистами, - более чем серьезная угроза для любой компании. Насколько серьезна? По-моему, биржевой индекс Heartlend'а показывает это весьма наглядно.





  © Blogger template 'Solitude' by Ourblogtemplates.com 2008

Back to TOP