А вы декларируете мобильный телефон при пересечении границы?

А вы помните, как год назад российский офис Cisco проводил семинар по импорту шифровальных средств? Если не помните, то посмотрите презентацию еще раз или прослушайте запись с онлайн-версии. Зачем я прошу вас это сделать? Я хочу, чтобы вы вспомнили, что такое шифровальные средства с точки зрения российской таможни. Согласно нормативным документам ФТС к ним относятся:

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

Нехиленький такой список ;-) Но дело не в нем, а в том, что в декабре прошлого года Федеральная Таможенная Служба осчастливила российских граждан письмом от 12 декабря 2011 г. N 04-30/60671 "О направлении памятки" (в Консультанте+ и просто), в котором приводился актуализированный с учетом увеличения стоимостной нормы беспошлинного ввоза физическими лицами на таможенную территорию Таможенного союза товаров для личного пользования в сопровождаемом и несопровождаемом багаже воздушным транспортом до 10 000 евро порядок перемещения физическими лицами товаров для личного пользования через таможенную границу Таможенного союза (а в него, напомню, входит Россия, Белоруссия и Казахстан). Иными словами в этой памятке, которая висит на каждом стенде, щите, табло и других устройствах с информационными материалами в информационной зоне таможенного органа, говорится о том, что вы можете провозить без декларирования, а что с декларированием в пассажирской таможенной декларации. Мы обычно в нее не смотрим, ориентируясь просто на сумму в 10000 евро, свыше которой товары надо декларировать. На самом же деле в этой памятке есть и относящиеся к ИБ вопросы ;-)

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

Мне можно возразить, что товари для личного пользования не декларируются. Все так, если бы в памятке не было явно указано, что есть "товары для личного пользования, перемещение которых физическими лицами через границу Российской Федерации допускается с разрешения государственных органов". И к этим товарам относятся и "технические средства, имеющие функции шифрования - нотификация (уведомление), зарегистрированное Центром ФСБ России по лицензированию, сертификации и защите государственной тайны (г. Москва, ул. Б. Лубянка, 1/3). С перечнем зарегистрированных нотификаций (уведомлений), заполненных изготовителем продукции или лицом, уполномоченным изготовителем продукции, можно ознакомиться на интернет-сайте www.tsouz.ru". А вы в курсе, ваш смартфон или лэптоп нотифицирован производителем?

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

Ну какая там может быть ответственность за ошибку в декларировании мобильного телефона? Пожурят и все. Смотрим ст.16.2 КоАП "Недекларирование или недостоверное декларирование". Вам повезет, если вас привлекут по 1-й части этой статьи (недекларирование) - до 20-ти тысяч рублей или конфискация или двукратная стоимость контрабанды. А вот если вас обвинят в недостоверном декларировании с целью обхода ограничений на ввоз (ч.3). Тут не только конфискация, но и штраф в 15 раз выше - до 300 тысяч рублей.
 

Ну что? Все под статьей ходим?

Подробнее…

Как налоговая может оспорить сделки с ИБ-интеграторами

Надысь, на семинаре зашла речь о лицензировании деятельности по ТЗКИ и использованию шифрования. Аудитория была разношерстная - от безопасников и айтишников до бухгалтеров и юристов. Как обычно, я рассказал о всех позициях, связанных с лицензированием - ФСТЭК и ФСБ, Банка России, судов и прокуратуры. Рассказал о том, что в ПП-584 говорится о том, что участник НПС может привлекать для контроля соответствия только лицензиатов ФСТЭК, а по 382-П это совершенно необязательно. Думал повести рассказ дальше, но тут меня прервали...

Был задан вопрос о том, как относится налоговая к ситуации с лицензированием деятельности по защите информации. Я сначала не понял, о чем идет речь, и мне рассказали интересную историю о том, что нередко налоговые органы при оценке обоснованности отнесения на себестоимость банковских услуг (и думаю не только банковских) тех или иных затрат требуют подтверждения того, что соответствующие услуги оказаны налогоплательщику лицом, имеющим соответствующую лицензию. А если налогоплательщик не может представить фискалам доказательства наличия у контрагентов лицензий на оказание соответствующих услуг (если оказание таких услуг является обязательным, что, как мы знаем, по части ТЗКИ и шифрования до сих пор вызывает вопросы), то налоговики признают отнесение на себестоимость соответствующих затрат неправомерным. А могут и вовсе признать сделку между заказчиком и поставщиком услуг по защите признать недействительной, базируя свое решение на ст.173 ГК РФ. Вот такой поворот событий...

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

Подробнее…

Анализировать код на предмет его безопасности выгодно?!

После появления на pastebin сообщения о взломе одного российского VPN-продукта у нас Женей Родыгиным завязалась дискуссия на тему недостатков отечественной системы сертификации средств защиты. Но поскольку опыт у нас разный, то и к выводам мы пришли разным. Я сторонник мысли о том, что система сертификации, которая не проверяет работоспособность продукта и его защищенность, а при проверке НДВ не находит 0-Day, убога и ее надо менять. Женя отстаивал другую позицию. Ну да ладно.

А тут на DLP Russia 2012 зашла с коллегами речь о том, что не хватает в России аналога PA DSS - стандарта с требованиям к платежным приложениям. Но можно посмотреть и шире - не хватает информации по тому, как писать защищенные программы (SDLC). Microsoft иногда проводит такие мероприятия, но их явно не хватает на всю Россию. Да и требований таких нет; не говоря уже об отсутствии ответственности.

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

К разработке софта эти цифры имеют также прямое отношение. Хотя могут отличаться константы. Например, Fortify приводит такие расчеты (правда, не говорит откуда они взяты). Устранение 200 ошибок/уязвимостей на поздних этапах жизненного цикла ПО (тестирование и поддержка) обходится в 2 с половиной миллиона.

А устранение того же количества дыр на этапе кодирования и тестирования - всего в 500 тысяч.

У Fortify соотношение не 1 к 30, а 1 к 100. Но как говорится, выгода от внедрения SDLC и software assurance все равно налицо. Это если не оценивать ущерб от реализации данных уязвимостей, например, в КВО, то все равно экономическая целесообразность от этого есть. Еще бы посчитать такой эффект в рублях, исходя из наших реалей. Может Appercut посчитает?..

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

Подробнее…

Презентация с DLP Russia 2012

На прошедшей в пятницу DLP Russia 2012 делал доклад "Новые технологии и новые тенденции ИБ". Так получилось, что доклад был на тему, которую я не особо хотел читать (очень уж абстрактная она). Да и времени было всего 20 минут. Поэтому я решил сконцентрироваться только на тех вопросах, которые возникают у большинства российских компаний именно сейчас или могут возникнуть в самом ближайшем будущем.

Новые тенденции и новые технологии на рынке ИБ from Alexey Lukatsky

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

Первое - STC Voice Monitor от "Центра речевых технологий" (на базе известной специалистам "Незабудки"). Это система контроля утечек в голосовом трафике. Причем не тупая запись Skype с последующим привлечением оператора, который слушает весь трафик в поиске ключевых слов. Речь идет о полной автоматизации этого процесса. STM Voice Monitor получает трафик с IP-телефонии, Skype, аналоговой телефонии и даже видеоконференцсвязи (только голосовой поток), автоматически распознает голос в текст и дальше либо сам использует базовый поиск по ключевым словам, либо передает распознанный текст в Infowatch. На мой взгляд, очень интересное и давно ожидаемое решение для тех компаний, которые хотят контролировать не только e-mail или ICQ, но и голосовой трафик.

О втором решении я уже упоминал в Twitter, когда был на ИнфоБЕРЕГе в Сочи. Это Safe-Phone от НИИ СОКБ. Причем это не просто MDM, а продукт, который очень тесно интегрирован с СКУД, системами аналитики, геолокации и может быть использован не только и не столько службами ИБ, сколько службами экономической и просто физической безопасности. Для окологосударственных предприятий и ВПК решение может быть очень и очень востребованным.

ЗЫ. Кстати, наступает время, когда писать обзоры о мероприятиях по ИБ становится уже не так интересно. Их качество за последние год-полтора очень сильно поднялось. И выделять кого-то становится сложно - каждое выделяет что-то свое. Хотя PHD для меня пока на первом месте ;-)

Подробнее…

Новые проекты Постановлений Правительства по персданным. Твердая четверка!

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

По сравнению с предыдущим вариантом проекта Постановления текст документа по уровням защищенности претерпел серьезные изменения. Во-первых, он ввел 5 классов ИСПДн, до боли напоминающих классификацию СТО БР ИББС - ИСПДн-И, ИСПДн-С, ИСПДн-Б, ИСПДн-О и ИСПДн, обрабатывающие ПДн только собственных сотрудников оператора ПДн. Правда, деление на специальные и типовые системы отсутствует (и это облегчает классификацию).

Тут хочу обратить внимание на ряд нюансов:

• Если ПДн сделаны общедоступными самим субъектом, то они попадут не в ИСПДн-О, как это было бы логичным, а в ИСПДн-И, т.к. в проекте Постановления определение общедоступности отличается от того, что есть в ФЗ-152.
• Если обрабатываются ПДн сотрудников не юрлица, а ИП, то они не могут быть отнесены к ИСПДн 5-го класса. Как, собственно, и ПДн лиц на аутстаффинге.
• Если обрабатываются данные о судимости, то они попадут не в ИСПДн-С, как это было бы логичным, а в ИСПДн-И. Иными словами, уровень защищенности сведений о судимости будет гораздо ниже, чем уровень защищенности иных специальных категорий ПДн.

Дальше оператор должен самостоятельно осуществить определение актуальных угроз. Никаких методик ФСТЭК или ФСБ, как это предполагалось раньше. А это уже серьезная подвижка и возможность создать хорошую модель угроз (у меня и курс есть ;-). У Алексея опасения вызвала привязка к НДВ. Но для тех случаев, когда закладок в ПО нет и существует третий тип угроз. И таких угроз будет большинство, т.к. я с трудом могу себе представить, что кому-то захочется узнать ПДн через специально внесенные закладки? Мы говорим не гостайне и не о КВО. Поэтому можно спокойно закрыть глаза на угрозы 1-го и 2-го типов и ограничиться только 3-м.

Ну а дальше все просто. Исходя из класса ИСПДн и типа актуальных угроз определяется уровень защищенности. У Сергея Борисова приведена хорошая сводная табличка по ним. Могу предсказать, что у большинства операторов ПДн будут либо 4-й, либо 3-й уровни защищенности. 2-й возможен только в случае обработки ПДн спецкатегорий по свыше 100000 субъектов (кстати, а что если субъектов ровно 100000?). Не буду опять поднимать вопрос о том, почему водораздел проходит по этому числу, с этим уже ничего не поделаешь. Иными словами, на 2-й уровень попадут, в-основном, страховые компании, обрабатывающие сведения о здоровье. А больше не смог никого найти, кто бы обрабатывал такое количество ПДн спецкатегорий. Ну если только банки, "злоупотребляющие" ипотечными кредитами.

Теперь обратимся к документу по требованиям. Во-первых, убрали ПЭМИНовский раздел. Во-вторых, текст сделали более логичным и все требования связали с конкретными уровнями защищенности. Убрали и ряд иных одиозных или непонятных требований, присутствовавших как в предыдущем проекте, так и в 781-м Постановлении Правительства. Правда, появились и новые далеко не самые умные требования. Например, контролируемая зона начиная с 4-го уровня защищенности. Эта зона исключает возможность неконтролируемого проникновения или пребывания посторонних лиц. А теперь попробуйте транслировать это требование на работу с мобильными устройствами за пределами офиса (офисов) оператора ПДн? Не получится, как бы вы не старались. Вообще, мобильный доступ, о котором так часто говорят руководители государства будут вне закона. Например, не так давно прошла новость об оснащении отечественных полицейских планшетниками. А по проекту Постановления это будет сделать уже невозможно - ну какая на улице контролируемая зона?

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

Ну и последний пункт - про контроль выполнения требований. Тут, как и в ПП-584 по НПС, контроль осуществляет либо оператор ПДн самостоятельно, либо привлекаемый им лицензиат ФСТЭК.

В целом я хочу отметить, что оба проекта мне нравятся гораздо больше предыдущего варианта. Они не только более стройны и логичны, но и менее обременительны для операторов ПДн. Недовольство Алексея Волкова я разделить не могу. Те, шероховатости, которые есть, легко устранимы. Единственное, что пока вызывает вопрос - контролируемая зона для 4-го уровня защищенности. Учитывая современные технологии, я бы вообще убрал этот пункт и вынес бы его на уровень нормативных документов ФСТЭК и ФСБ. Ну а если так уж хочется оставить его в Постановлении Правительства, то я бы эту зону требовал, начиная со второго уровня защищенности, не раньше, а то и с 1-го.

Подробнее…

Какова логика наших регуляторов при разработке нормативных актов?!

Вчера было опубликовано новое Постановление Правительства от 18 сентября 2012 года № 940 "Об утверждении Правил согласования проектов решений ассоциаций, союзов и иных объединений операторов об определении дополнительных угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении определенных видов деятельности членами таких ассоциаций, союзов и иных объединений операторов, с Федеральной службой безопасности Российской Федерации и Федеральной службой по техническому и экспортному контролю".

Те, кто его читал, задались вопросом - а на кой оно вообще нужно? Ну какой здравомыслящий оператор будет делать что-то еще, сверх того, что нам приготовят регуляторы? Ведь врядли они пойдут на встречу и разработают некий базовый минимум методов и способов защиты персональных данных. Вспоминая и приказ №58 и проекты Постановлений Правительство по требованиям в области безопасности ПДн надеяться на это не приходится. Да и регуляторы не могут не понимать этого. Но зачем оно тогда вообще появилось?

С другой стороны, я уже писал про ФЗ "О безопасности ТЭК", в котором есть 11-я статья про информационную безопасность объектов ТЭК. 5 мая 2012 года Правительство выпускает аж целых 3 постановления по безопасности:

• № 458 "Об утверждении Правил по обеспечению безопасности и антитеррористической защищенности объектов топливно-энергетического комплекса"
• № 459 "Об утверждении Положения об исходных данных для проведения категорирования объекта топливно-энергетического комплекса, порядке его проведения и критериях категорирования"
• № 460 "Об утверждении Правил актуализации паспорта безопасности объекта топливно-энергетического комплекса".

Но там ни слова про информационную безопасность - она явно выведена из под их действия. На ИнфоБЕРЕГе этот вопрос был задан представителю МинЭнерго. Он ответил прямо - мол, не было задания разрабатывать соответствующие Постановления и вообще нормативную базу по ИБ объектов ТЭК. А как же 11-я статья? - спросили его. Он ничтоже сумняшеся ответил, что раз в 11-й статье не говорится, что защита объектов ТЭК должна строится по требованиям, разрабатываемым Правительством, то и разрабатывать эти требования никто не будет. А на вопрос, как тогда защищать АСУ ТП, представитель МинЭнерго ответил, что по требованиям ФСТЭК и ФСБ.

Тут надо, к слову, отметить, что никто в России не хочет брать на себя ответственность за регулирование безопасности ТЭК. Представитель МинЭнерго рассказал, что за паспортизацию объектов ТЭК отвечает МинЭнерго. При паспортизации применения классификации чрезвычайных ситуаций МЧС. Требования по безопасности для тех же линейных объектов ТЭК будет разрабатывать МЧС, а вот контроль за выполнением требований никто на себя из трех брать не захотел и по последней договоренности эту задачу повесят на МВД. Правда, тут вообще анекдот. Когда МинЭнерго хотело эту задачу взять на себя (в самом начале обсуждения темы), оно запросило увеличение численности на 140 человек, но им отказали. Зато когда эта тема повисла на МВД, то тем оказалось нужно 20000 человек для надзора... и им, похоже, дадут нанять этих 20000 полицейских (вот куда пойдут не прошедшие переаттестацию ;-).

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

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

Подробнее…

Триада "конфиденциальность, целостность, доступность": откуда она?

Все специалисты по безопасности знают классическую триаду "конфиденциальность, целостность и доступность" (КЦД) или "confidentiality, integrity, availability" (CIA). Ее применяют к месту и не очень, но мало кто знает, откуда она вообще появилась? Этому в ВУЗах не учат, а стоило бы. Тогда стало бы понятно, что эта концепция уже немного устарела и не является догмой.

Напомню, что впервые этот принцип был изложен в статье "Защита информации в компьютерных системах", написанной Зальцером и Шредером в 1974-м году и опубликованной в "Communications of the ACM". В этой статье безопасность определялась как "техники, которые контролируют, кто может использовать или модифицировать компьютер или содержащуюся в нем информацию". При этом авторы ссылались на других авторов, которые считали, что все нарушения безопасности могут быть разбиты всего на 3 группы - неавторизованное использование (unauthorized information release), неавторизованное изменение и неавторизованное блокирование использования (unauthorized denial of use). С тех пор и началось победное шествие этой триады по миру. У нас она как-то подзадержалась и зависла во многих нормативных документах.

Однако, чтобы понимать всю ограниченность этой концепции в современном мире надо вспомнить окружение, в котором эта триада появилась. Мейнфреймы, язык COBOL, операционная система MVS, Multics, UNIX и т.д. Что поменялось с тех пор? Все. Появился Интернет, черви навроде Stuxnet, Java и C++, облачные вычисления и много чего... Все это уже очень трудно уложить в традиционную триаду. Стали появляться расширения триады. Например, ФСБ в своей методичке по персональным данным, указав триаду как основные характеристики безопасности, добавила еще: "в дополнение к перечисленным выше основным характеристикам безопасности могут рассматриваться также и другие характеристики безопасности. В частности, к таким характеристикам относятся неотказуемость, учетность (иногда в качестве синонима используется термин «подконтрольность»), аутентичность (иногда в качестве синонима используется термин «достоверность») и адекватность".А в 91-м Джон МакКамбер предложил свою модель на базе триады, названную им моделью информационной безопасности МакКамбера (я о ней писал 3 года назад).

ОЭСР в 1992-м году предложила свои 9 принципов безопасности - Awareness, Responsibility, Response, Ethics, Democracy, Risk Assessment, Security Design and Implementation, Security Management и Reassessment. ОСЭР всегда смотрела на безопасность с философски-культурологической позиции ;-)

В 2002-м году Дон Паркер предложил свой "Паркеровский гексагон", котрый к триаде добавлял еще 3 характеристики - владение или контроль (possession или control), аутентичность (достоверность) и полезность (utility).

По поводу владения/контроля Паркер приводил такой пример. Представьте, что вор украл у вас запечатанный конверт с банковскими картами и PIN-кодами к ним. Даже если вор не открыл этот конверт и не нарушил тем самым его конфиденциальность, это все равно должно вызывать беспокойство владельца конверта, который потерял над ним контроль. Аналогичная ситуация с тестами на проникновение, например, в системы АСУ ТП. Во время таких тестов не страдает ни один из элементов классической триады, но успешное проникновение показывает потерю контроля.

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

NIST в 2004-м году пошел еще дальше и предложил свою модель из 33 (!) элементов или, как написано в SP800-27 "Engineering Principles for Information Technology Security (A Baseline for Achieving Security)", принципов. Но и это тоже не конец. Многие организации пытались придумать что-то свое, подменяя понятие "информационной безопасности" другими - "управление рисками", "security governance" и т.д. И у каждого из них был свой набор характеристик или принципов, реализация которых позволяла надеяться на создание действительно защищенной системы или процесса.

Подробнее…

Как ФСБ дураком меня назвала или опять опять про персданные?!

Начну я с краткого экскурса в законодательство о персональных данных. В соответствие с частью 1 статьи 19 Федерального закона от 27 июня 2006 года «О персональных данных» оператор персональных данных обязан принимать технические меры для защиты персональных данных от несанкционированного доступа.

В соответствие с пунктом 7 положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных, утвержденного Постановлением Правительства РФ от 17 ноября 2007 г. N 781 «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных» обмен персональными данными при их обработке в информационных системах осуществляется по каналам связи, защита которых обеспечивается путем реализации соответствующих организационных мер и (или) путем применения технических средств. В соответствие с 3-м пунктом данного Положения методы и способы защиты информации в информационных системах устанавливаются Федеральной службой по техническому и экспортному контролю и Федеральной службой безопасности Российской Федерации в пределах их полномочий.

В соответствие с пунктом 2.8 приказа Федеральной службы по техническому и экспортному контролю от 5 февраля 2010 г. N 58 «Об утверждении Положения о методах и способах защиты информации в информационных системах персональных данных» для обеспечения безопасности персональных данных при межсетевом взаимодействии отдельных информационных систем через информационно-телекоммуникационную сеть международного информационного обмена (сеть связи общего пользования) применяется наряду с другими обязательными защитными мерами создание канала связи, обеспечивающего защиту передаваемой информации.

В соответствие с «Методическими рекомендациями по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации», утвержденными ФСБ России 21 февраля 2008 г. N 149/54-144 и являющихся обязательными к применению при обработке персональных данных в государственных информационных системах, защита персональных данных в каналах связи обеспечивается с помощью средств криптографической защиты информации.

В соответствие с частью 2 статьи 19 Федерального закона от 27 июня 2006 года «О персональных данных» и пунктом 5 положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных, утвержденного Постановлением Правительства РФ от 17 ноября 2007 г. N 781 «Об утверждении Положения об обеспечении безопасности персональных данных при их обработке в информационных системах персональных данных» средства защиты информации, применяемые в информационных системах, в установленном порядке проходят процедуру оценки соответствия. А согласно «Методическим рекомендациям по обеспечению с помощью криптосредств безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств автоматизации», утвержденным ФСБ России 21 февраля 2008 г. N 149/54-144, оценка соответствия проводится в форме обязательной сертификации в системе сертификации средств криптографической защиты информации, разработанной и утвержденной ФСБ России.

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

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

На сайте Правительства России меня встретила бойкая фраза о том, что мои персональные данные обрабатываются с полным соблюдением требований российского законодательства. Все! Больше ничего.  Никакого disclaimer об отказе от конфиденциальности. Эта же фраза присутствует на сайте Президента России и на сайте головного органа в области защиты ПДн - Минкомсвязи.

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

Больше всего меня поразила ФСБ. Она не только не имеет disclaimer, но и вообще про персональные данные не упоминает. Мол, заполняй форму, и все! Еще и дураком обозвали (если внимательно посмотреть на CAPTCHA).

Куда мои персональные данные пойдут? Вспоминая нередкую практику использования почтовых ящиков наших чиновников на публичных почтовых серверах (mail.ru, gmail.com и т.д.), не хочется думать, что ПДн также попадают на такие сервера и там складируются.

А что ФСТЭК? А ФСТЭК вообще не имеет формы для работы с обращениями граждан - они с ними только по обычной почте работают. Зато и претензий к ним по поводу нарушения требований конфиденциальности нет ;-) Правда на новой версии сайта ФСТЭК, работающей пока в тестовом режиме, приводится та же фраза - "Персональные данные пользователей информации хранятся и обрабатываются с соблюдением требований российского законодательства". Но Web-формы нет и там. Зато есть адреса e-mail, по которым можно общаться с разными региональными управлениями ФСТЭК. Но e-mail-то у нас ходит тоже по каналам связи через сетя связи общего пользования. Т.е. к e-mail должны применятся те же принципы обеспечения конфиденциальности (только для другого протокола) на базе сертифицированных СКЗИ. Но если с Web-взаимодействием по принципу "клиент-сервер" еще можно что-то придумать (например, разрешить SSL на AES), то что делать с электронной почтой; как ее шифровать?

На прошлой неделе был я на конференции ИнфоБЕРЕГ в Сочи. Замечательное мероприятие, замечательное место. Но больше всего меня поразил Баранов Александр Павлович, бывший первый замначальника 8-го Центра ФСБ, а ныне служащий ГНИВЦ ФНС России. Он говорил потрясающие вещи, полностью противоречающие тому, что он же говорил еще год назад, будучи основным регулятором в области криптографии. Он говорил, что ФСБ медленно работает, что система сертификации СКЗИ устарела и не поспевает за тенденциями, что ФСБ надо менять парадигму в отношении защиты конфиденциальной информации и т.д. Среди прочего он рассказал о том, как клиенты ФНС используют для взаимодействия с налоговой SSL на базе американского стандарта шифрования AES! Это делается на страх и риск клиента, которому предоставляется альтернатива в виде сертифицированных СКЗИ, но все равно - делается открыто и официально. Более того, по словам Баранова они получили на это разрешение ФСБ.

Может пора нашим регуляторам задуматься об этом же и разрешить использование встроенной в ОС и браузеры криптографии для ряда случаев? Фактически это и так происходит. Тот же Баранов на ИнфоБЕРЕГе заявил, что "SSL на AES лучше чем вообще без криптографии". И я разделяю эту позицию. Может стоит уже зафиксировать эту позицию официально?

ЗЫ. У коллеги обсуждается аналогичная тема, но немного в другом контексте.

Подробнее…

Хватит ругать наши ГОСТы по безопасности. Пора действовать!

6 сентября я писал про новые ГОСТы, которые должны появится в России в следующем годы. Но работа уже ведется и она не такая закрытая, как иногда кажется. В частности, Ассоциация RISSPA, представляющая Cloud Security Alliance в России, достигла договоренности с представителями ФСТЭК России о проведении публичного обсуждения терминологии облачных вычислений, которая в дальнейшем станет основной для использования в документах ФСТЭК по облачной тематике. RISSPA и ФСТЭК приглашают всех заинтересованных экспертов воспользоваться уникальным шансом и принять активное участие в формировании терминологии с учетом уже устоявшейся российской практики.

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

Второй разрабатываемый ГОСТ я также упоминал - "Уязвимости информационных систем. Классификация уязвимостей информационных систем". Пояснительная записка и первая редакция проекта стандарта размещена на портале Ростехрегулирования.

По обоим документам вы можете проявить активность и поучаствовать в обсуждении этих документов. Я не раз уже призывал перейти от критики к реальной работе и это одна из таких возможностей. Не упустите ее. Потом винить можно будет только себя ;-(

Подробнее…

Презентация по безопасности облаков

Ну вот и вторая презентация по безопасности облаков. Как обычно делал "на будущее", т.к. заранее знал, что в 20 минут 80 слайдов не уложу. Но зато будет заготовка для расширения.

Безопасность различных архитектур облачных вычислений from Alexey Lukatsky

ЗЫ. Кстати, Cisco сама использует 432 внешних провайдера 505 различных услуг. Так что у нас богатый опыт защиты облачных вычислений, которые мы не только сами предлагаем (Webex и ScanSafe), но и активно используем.

Подробнее…

Безопасность АСУ ТП: от слов к делу

Вчера на ИнфоБЕРЕГЕ делал презентацию по безопасности АСУ ТП. Учитывая нехватку времени, пришлось сильно сократиться, но сама преза от этого не страдает - она включает почти все, что я хотел сказать. В ней я попытался уйти от банальщины в виде рассказа об угрозах или стандартах и дать конкретные рекомендации "Что делать для защиту АСУ ТП прямо сейчас?". Как мне кажется, удалось. При этом вторая задача была - указать решения, которые, во-первых, преимущественно не требуют капитальных затрат на приобретение, а во-вторых, не должны иметь (в массе своей) проблем с точки зрения национальной безопасности. Речь идет о open source или freeware-решениях, которые можно легко проанализировать на предмет НДВ и т.п.

Подробнее…

Как уничтожать данные в электронном виде?

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

Ответ на этот вопрос очень неплохо описан в книге специалистов компании Cicada Security Technologies "Best Practices for the Destruction of Digital Data". Авторы начинают с того, что описывают в какой форме могут существовать данные в компании/ведомстве, чтобы учесть это в политике уничтожения. По их мнению данные могут быть "живые" (на хранении, в процессе передачи по защищенной и незащищенной сети) и устаревшие (достигшие срока своей жизни, сохранившиеся на вышедшей из строя технике или на носителях, которые подлежат апгрейду).

Затем авторы рассматривают 3 уровня уничтожения электронных данных (обычно уровень уничтожения зависит от уровня классификации информации):

• Очистка (clear), ярким примером которой является перезапись данных на носителях, содержащих уничтожаемую информацию. В лабораторных условиях такие данные можно восстановить.
• Очищение (purge), ярким примеров котором является Secure Erase из спецификации жестких дисков ATA или размагничивание. В лабораторных условиях восстановление уничтоженных таким образом данных считается невозможным.
• Разрушение (destroy), т.е. физическое уничтожение носителей путем сжигания, измельчения, плавления, расщепления, распыления и т.п.

Поскольку уничтожение данных - это непростой процесс, требующий не только регулярности, но и затрат, то вопрос, который надо задать первым: "Зачем надо уничтожать данные?" И на него авторы тоже дают ответ, рассматривая различные нормативные акты, требующие уничтожения данных - канадский PIPEDA, американский HIPAA и GLBA, международный PCI DSS, Евроконвенция по ПДн и т.д. Вообще обзор нормативных актов в книге неплохой; правда, американизированный донельзя. Но это и понятно. Авторы американцы, компания их американская и аудитория тоже.

Затем делается обзор стандартов уничтожения данных. Например, стандарт NISTа SP 800-88 "Guidelines for Media Sanitation" или документ американского МинОбороны DoD 5220.22-M. Среди других рассмотренных стандартов - канадские B2-001, G2-003 "Hard Drive Secure Information Removal and Destruction Guide" и ITSG-06 "Clearing and Declassifying Electronic Data Storage Devices". Вообще, книга очень часто ссылается на документ NIST. Например, из него взято очень неплохое дерево принятия решения о выборе метода уничтожения данных.

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

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

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

Когда эта заметка уже была написана и я проставлял ссылки на упомянутые в ней документы, оказалось, что NIST 6-го сентября выложил на обсуждение проект новой версии SP 800-88 по уничтожению данных, который коснудся вопрос уничтожения на сетевом оборудовании, мобильных устройствах, флешках, картах памяти, CD и т.п. Вообще SP 800-88 очень неплохо описывает, что и как надо делать по уничтожению данных, кто за это отвечает и какими документами этот процесс должен регламентироваться в компании.

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

ЗЗЫ. Кстати, в книге нет ссылки на очень неплохой документ "DSS Clearing and Sanitization Matrix", сводящий различные методы уничтожения  данных для разных типов носителей.

Подробнее…

BYOD в органах власти. Как это делают в США?!

Тема применения мобильных устройств в органах власти стоит достаточно давно. То она стопорится регуляторами в области информационной безопасности (ведь наша нормативная база по ИБ уже устарела и не учитывает особенностей мобильных устройств; тем более собственных). То сами руководители страны показывают обратный пример, используя вместо планшетных компьютеров обычный бумажный блокнот. Хотя лед постепенно сдвигается с мертвой точки. В частности на одном из заседаний Правительства была поставлена задача сделать пилотный проект по применению мобильных устройств в системе электронного докуменооборота Правительства России. Пока только для публичной информации, но и это уже немало.

Но пока Минкомсвязь с ФСО (где, кстати ФСБ и ФСТЭК в этом поручении) готовят пилот, я коснусь того, как аналогичный вопрос решается в американских органах власти. Правда, там пошли чуть дальше и не просто рассматривают возможность применения мобильных устройств в работе госорганов, а разрешают использовать собственные устройства чиновников, реализую концепцию BYOD (Bring Your Own Device).

Такой подход был зафиксирован в документе "Bring Your Own Device. A Toolkit to Support Federal Agencies Implementing Bring Your Own Device (BYOD) Programs", опубликованном в августе этого года федеральным CIO США. Это докумен не сам в себе - он является частью стратегии электронного правительства (Digital Government Strategy), опубликованной Белым Домом в мае 2012-го года, и в многих своих разделах опирающихся на мобильные технологии. Аналогом такой стратегии в России можно было бы назвать Федеральную Программу "Информационное общество 2012-2020", утвержденную Путиным и Медведевым, но читать наш документ сложно - слишком уж много страниц он занимает. Да и понять ответственных за реализацию каждого пункта ФП очень непросто. Но вернемся к документу по BYOD.

Этот документ отличается от многих аналогичных по сути документов, выпущенных в России. Во-первых, он носит рекомендательный характер, о чем прямо сказано в преамбуле. Во-вторых, он построен на удачном опыте реализованных BYOD-проектов в разных американских ведомствах, а не просто постулирует неопробированные идеи и тезисы. Документ изобилует реальными кейсами и примерами, облегчающими восприятие документа (это то, чего так не хватает отечественной нормативной базе - примеров). В-третьих, документ не пытается вместить в себя все темы, связанные с мобильностью. Он явно отсылает читателя к другим разработанным (например, документам NIST по управлению и безопасности мобильных устройств или по защите персональных данных) или планируемым к разработке (например, Mobile Security Reference Architecture) документам.

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

Затем в документе приводится список вопросов, которые требуют решения при внедрении BYOD:

• технические подходы (виртуализация, разграничение контуров с информацией различных "грифов")
• роли и ответственность (пользователи, ведомства, служба поддержки ведомства и оператора связи)
• программы стимулирования использования мобильных устройств
• опросы пользователей о преимуществах и проблемах при использовании мобильных устройств
• добровольное или обязательное участие в программе BYOD
• безопасность
• privacy
• вопросы этики и юридического характера (как конфисковывать мобильные устройства или что такое "разрешенное использование"?)
• операторы связи
• устройства и приложения (допустимые платформы, MDM, владелец данных, хранение данных в облаке или на устройстве)
• управление активами (кража или потеря устройства, стоимость поддержки и приложений).

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

В целом документ достаточно интересный. И хотя он не отвечает на выявленные им же вопросы (показанные выше), он является хорошей отправной точкой для тех, кто планирует внедрять у себя в ведомствах не только BYOD, но и вообще мобильные устройства. Он заставляет задуматься над ключевыми вопросами ДО ТОГО, как они возникнут.

Подробнее…

Какой была безопасность в России в 90-х годах

И вновь потянуло меня разбирать архивы... И вновь я наткнулся на антикрвариат; погрузился в него; стал вспоминать. Так случилось, что аккурат с 92-го года, как я стал заниматься ИБ, я стал коллекционировать библиотеку литературы по ИБ. И накопилось за это время много всего. И книг штук 200, а уж статей и вовсе не счесть. Первые статьи по нашей теме появились в 91-м году. До этого тема была табу и тайной за семью печатями, доступной только сотрудникам КГБ (а потом ФАПСИ) да ФСТЭК. Даже литература по криптографии считалась шифровальным средством и ее распространение контролировалось очень серьезно. Это сейчас сложно представить, что литература по ИБ была под запретом. А в начале 90-х я многое мог читать только в спецбиблиотеке при ящике, к которому я был приписан. Но 91-й год запомнился не только распадом СССР, но и годом рождения коммерческого рынка ИБ. И в этом же году появились первые статьи по нашей теме.

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

 

И в том же 91-м в Компьютер-Пресс подняли тему анализа рисков, описав что это такое и зачем он нужен.

  

 Кстати, в статьях уже тогда приводилось более менее нормальное определение термина "безопасность".

 

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

Не обошлось без рассказа о том, как строится система защиты в США, с описанием ее нормативных документов и т.д. Других-то тогда не было. Первые РД ФСТЭК появились в 92-м году и были калькой с "Радужной серии". Причем не очень удачной, т.к. в серию входило 1-2 десятка разных книг, из которых мы взяли только одну - по СВТ (средствам вычислительной техники), читай "автономные персоналки". Все остальное переводить по какой-то причине не стали и мы до сих пор так и живем по документам 92-го года.

Криптография тоже пыталась развиваться достаточно активно. Был такой журнал для программеров "Монитор", который в начале 90-х стал публиковать описание различных алгоритмов шифрования (преимущественно зарубежных), погружаясь и в математику и в программирование (причем на Ассемблере). Вот так выглядела, например, 3-я часть статьи про рюкзачные криптоалгоритмы (до этого Монитор рассмотрел симметричные DES и ряд других алгоритмов).

Ну и про асимметричную криптрографию тоже не забывали.

Спустя всего пар лет появились первые серьезные продукты в области сетевой безопасности, а точнее в области VPN. Вот вы можете видеть одну из первых статей по сетевой криптографии на базе международных протоколов. Еще до появления протокола обмена ключами IKE для IPSec в 98-м году весь мир пользовался SKIPом. И его и реализовали Александр Галицкий, Сергей Рябко и другие в компании Элвис+. А ведь это было в своем роде революцией - вся Россия тогда работала на проприетарных протоколах обмена криптографическими ключами, согласуемыми сначала с ФАПСИ, а потом и с ФСБ (а то и получаемых от них). Раньше считалось, что IPSec - это зло, которое разработано американцами, чтобы вывести из строя российскую экономику (та же мотивация была в СовБезе, когда в России не смогли ратифицировать "Общие критерии"). Отечественные криптосредства перешли на IPSec год-два назад и то не все - многие до сих пор работают на закрытых протоколах, что зачастую приводит к проблемам при работе в сетях связи общего пользования.

И уже в тоже время начались активные искания в области правового регулирования вопросов ИБ. И хотя многие сотрудники спецслужб покинули родные пенаты и основали собственные "бизнеса", сама "контора" не желала расставаться с монополией на защиту информации. Вот так выглядела заметка в "Московском комсомольце" о факте выхода пресловутого 334-го Указа Президента Ельцина, вводящего запрет на любую криптографию, которая не была "освящена" ФАПСИ. Именно с тех времен тянется известный конфликт ЛАН Крипто и ФАПСИ, в котором так и оказалось победителей.

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

Вообще, по зрелому размышелнию за кружкой кефира (и это не метафора) понимаешь, что российский рынок ИБ не сильно отличается от того, что было в начале 90-х. Разрабатываются продукты одного класса - СЗИ от НСД, т.е. те, которые можно сертифицировать. Если раньше были "Редуты", "Кометы", "Кобры", "QP DOSы", то сейчас "Щиты", "Брони", "Панцири". Крипта тоже не сильно меняется. Меня поражает ФПСУ-IP, который до сих пор под управление MS DOS работает. Последняя версия 6.22 была выпущена в 94-м году; про версии 7.0 и 7.1 не говорю, т.к. они были частью Windows, а не самостоятельным продуктом (да и они в 2000-м прекратили разрабатываться). Нормативные документы регуляторов не сильно поменялись (небольшие правки я не беру в расчет). Отношение регуляторов к вопросам лицензирования и сертификации... ну не мне рассказывать. Что поменялось? Интерфейс продуктов. Тут изменения налицо - была псевдографика MS DOS, а стала нормальная графика Windows. Дизайн "железячных" продуктов изменился. Ну и рекламные листовки тоже претерпели сильные изменения. Вот только сами продукты такого разительного скачка не сделали.

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

Подробнее…

Как мне приснился PHD и к каким размышлениям это привело

Когда 5 лет назад я затевал этот блог, я лелеял надежду, что писать я буду о том, как поднять ИБ на уровень бизнеса, об измерениях в ИБ, метриках, психологии ИБ, теории организации в контексте ИБ и многим другим темам, которым место в программе MBA. Но мечте не суждено было сбыться - скатился в банальщину, которая отъедает у российских безопасников излишне много времени. Неоправданно много. Речь идет о compliance - о ФЗ-152, о ФЗ-149, о документах ФСТЭК, ФСБ, РКН, ЦБ и т.д. Слишком уж их много стало появляться в последнее время. А так как я уже начал эту тему вести, то было бы неправильно прекращать ее освещать - очень многие рассматривают этот блог как источник новостей по изменению нашего законодательства в области ИБ.

Не скажу, что в других странах такого нет. Compliance - это один из драйверов ИБ, но именно что "один из". Помимо него безопасники в других государствах активно занимаются реальной безопасностью, направленной на решение реальных, а не мнимых проблем ИБ. В этом плане мне вспомнился на днях PHD, лозунг которого был "Реальная безопасность". И действительно - взломы АСУ ТП, банкоматов, браузеров, обход защитных механизмов, мошенничества с ДБО - вот то, чем должны заниматься службы ИБ. А у них банально на это времени не хватает, т.к. они вынуждены заниматься выполнением многостраничных манускриптов, построенных на уже устаревшей парадигме защищенного периметра, защите гостайны и противодействии иностранным техническим разведкам.

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

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

К чему я это все?.. Просто поток сознания ;-) Очередную англоязычную книжку по ИБ читаю и понимаю, что интересы специалистов по ИБ ТАМ и ТУТ совершенно разные. Хотя слова и знакомые, но трактуются они по разному. И там гораздо дальше ушли в решении многих именно практических вопросов, о которых у нас просто не говорят или не знают. С точки зрения compliance мы можем дать фору всем странам, в отличии от бизнес-направленности и практической реализуемости этого compliance.

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

Подробнее…

Новые ГОСТы по ИБ или как ФСТЭК меняет методологическую базу

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

• ГОСТ Р 53110-2008. Система обеспечения информационной безопасности сети связи общего пользования. Общие положения
• ГОСТ Р 53111-2008. Устойчивость функционирования сети связи общего пользования. Требования и методы проверки
• ГОСТ Р 53109-2008. Система обеспечения информационной безопасности сети связи общего пользования. Паспорт организации связи по информационной безопасности 
• ГОСТ Р 53114-2008. Защита информации. Обеспечение информационной безопасности в организации. Основные термины и определения 
• ГОСТ Р 53113.1-2008. Информационная технология. Защита информационных технологий и автоматизированных систем от угроз информационной безопасности, реализуемых с использованием скрытых каналов. Часть 1. Общие положения 
• ГОСТ Р 53112-2008. Защита информации. Комплексы для измерений параметров побочных электромагнитных излучений и наводок. Технические требования и методы испытаний 
• ГОСТ Р 53115-2008. Защита информации. Испытание технических средств обработки информации на соответствие требованиям защищенности от несанкционированного доступа. Методы и средства 
• ГОСТ Р 53113.2-2009. Информационная технология. Защита информационных технологий и автоматизированных систем от угроз информационной безопасности, реализуемых с использованием скрытых каналов. Часть 2. Рекомендации по организации защиты информации, информационных технологий и автоматизированных систем от атак с использованием скрытых каналов 
• ГОСТ Р ИСО/МЭК ТО 19791-2008. Информационная технология. Методы и средства обеспечения безопасности. Оценка безопасности автоматизированных систем 
• ГОСТ Р ИСО/МЭК 21827-2010. Информационная технология. Методы и средства обеспечения безопасности. Проектирование систем безопасности. Модель зрелости процесса 
• ГОСТ Р 53131-2008. Защита информации. Рекомендации по услугам восстановления после чрезвычайных ситуаций функций и механизмов безопасности информационных и телекоммуникационных технологий. Общие положения.
• ГОСТ Р 54581-2011 Информационная технология. Методы и средства обеспечения безопасности. Основы доверия к безопасности ИТ. Часть 1. Обзор и основы 
• ГОСТ Р 54583-2011. Информационная технология. Методы и средства обеспечения безопасности. Основы доверия к безопасности информационных технологий. Часть 3. Анализ методов доверия 
• ГОСТ Р 54582-2011. Информационная технология. Методы и средства обеспечения безопасности. Основы доверия к безопасности информационных технологий. Часть 2. Методы доверия.

Почти все эти ГОСТы доступны на сайте Ростехрегулирования в открытом доступе.

Также были разработано и принято несколько стандартов по биометрии (часть еще в разработке), а также ранее упоминаемые (тут и тут) мной ГОСТы 18028 по менеджменту сетевой безопасности, 27006 по требованиям к аудиторам СМИБ, 27004 по измерениям СМИБ, 27005 по оценке рисков ИБ и 27033-1 по сетевой безопасности.

Из планов на 2013-й год можно назвать разработку очень интересных и достойных ГОСТов (часть работ уже начата):

• "Уязвимости информационных систем. Классификация уязвимостей информационных систем",
  "Уязвимости информационных систем. Правила описания уязвимостей",
• "Уязвимости информационных систем. Содержание и порядок выполнения работ по выявлению и оценке уязвимостей информационных систем",
• "Порядок создания автоматизированных систем в защищенном исполнении. Общие положения" (взамен текущей версии ГОСТ 51583-2000),
• "Документация по технической защите информации на объекте информатизации. Общие положения",
• "Информационные системы и объекты информатизации. Угрозы безопасности информации. Общие положения",
• "Техника защиты информации. Номенклатура показателей качества" (взамен текущего ГОСТ Р 52447-2005)",
• "Основные термины и определения" (взамен текущей версии ГОСТ Р 50922-2006), 
• "Требования по защите информации в информационных системах, построенных с использованием технологии виртуализации. Общие положения",
• "Требования по защите информации, обрабатываемой с использованием технологий "облачных вычислений". Общие положения",
• "Требования по защите информации в информационных системах, построенных с использованием суперкомпьютерных и грид - технологий"
• ну и ряд стандартов по информационным войнам.

Также планируется разработка/адаптация/гармонизация ГОСТ Р ИСО/МЭК 27007 "Информационная технология. Методы и средства обеспечения безопасности. Руководство по аудиту системы менеджмента информационной безопасности".

Планы очень амбициозные и достойные. ФСТЭК немного переориентируется - от разработки сугубо внутренних нормативных документов в сторону общегосударственной методической базы. Можно только приветствовать такой подход.

Подробнее…

Российские интеграторы не понимают специфики защиты АСУ ТП

Решил сделать краткий пост на тему, вынесенную в заголовок, ну и немного порекламировать свой доклад про безопасность АСУ ТП на сочинском ИнфоБЕРЕГе. В последнее время, особенно после выхода документа СовБеза, тема защиты АСУ ТП и вообще КВО стала достаточно актуальной и многие интеграторы стали развивать это направление как отдельное и самостоятельное.

Не споря с его важностью, хотелось бы показать неверность выбранного многими интеграторами пути. Что они обычно делают и предлагают с точки зрения своего портфолио? Пентесты и иные анологичные продукты и услуги, связанные с сетевой составляющей АСУ ТП. Это безусловно важно; особенно учитывая, что многие вендоры предлагают решения по защите АСУ ТП (например, Cisco предлагает систему предотвращения вторжений для SCADA), но достаточно ли? И немаловажный вопрос - нужно ли это заказчикам?

Для этого надо ответить себе на вопрос, что такое современная система, обслуживающая критически важный объект? Есть неплохая обзорная иллюстрация, показывающая взаимосвязь элементов современной АСУ ТП. По вертикали их 3:

• Сетевой уровень, представленный протоколом IP, который сейчас повсеместно используется в решениях АСУ ТП большинства зарубежных и отечественных вендоров.
• Уровень Middleware, как я его называю. Это то, что касается "родных" АСУ ТПшных вопросов - контроллеры, сенсоры, управляющее ПО и т.д. Сюда же можно отнести и общесистемное ПО, которое используется на компонентах АСУ ТП.
• Бизнес-уровень, отвечающий как за формирование различной отчетности по различным срезам работы АСУ ТП, так и управление ею (отгрузить столько-то руды, заполнить цистерну на столько-то и т.д.).

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

А теперь, собственно, о том, что и как делают интеграторы в России. Они концентрируются только на сетевом уровне. Это очевидно - защита на сетевом уровне более проста и понятна. Протокол IP знаком многим; средства его защиты в лице межсетевых экранов и IPS тоже известны. Что может быть проще, чем взять уже известный продукт и выдать его за средство защиты АСУ ТП? Хорошо, если он поддерживает специфические для АСУ ТП протоколы (например, DNP3, Modbus и т.д.). Но если нет, то тоже ничего ;-)  Правда, тут возникает задача правильного внедрения решений для защиты АСУ ТП. Ведь между ними существует очень серьезная разница. Можно воспользоваться рекомендациями вендоров по дизайну системы защиты для АСУ ТП (например, от Cisco), но про такие дизайны еще надо знать.

Но очевидно, что только защитой сетевого уровня дело не ограничивается. Пример с Stuxnet показал, что защиты только на уровне сети не достаточно. Но адекватных решений на этом уровне почти нет ;-( Касперский давно пытается создать свою ОС для решения таких задач, но пока до готового и тиражируемого продукта дело не дошло. А ведь им еще надо заинтересовать производителей решений для АСУ ТП.

С уровнем взаимодействия более менее все понятно - технологии обеспечения конфиденциальности и целостности существуют давно. А вопрос их соответствия требованиям ФСБ к СКЗИ я поднимать не буду преднамеренно ;-)

Но самое интересное заключается в другом - в России защита этих уровней не так востребована, как это кажется интеграторам, предлагающим защиту именно их. Многих заказчиков волнует совершенно другой вопрос. А как мне предотвратить кражу пары составов с рудой, которую может провернуть привилегированный пользователь системы управления цепочками поставок? А вы можете отследить на каком звене цепочки доставки нефтепродукта от нефтехранилища по нефтепроводу до нефтеперерабатывающего завода (принадлежащих зачастую разным юрлицам) произошла кража нефтепродукта? Или еще один из вопросов, который могут задать, когда возникнет тема "защиты АСУ ТП" (под которой понимают очень много различных задач, не всегда впрямую связанных с самой АСУ ТП). А вы можете нам помочь отследить операторов-мошенников, которые несанкционированно изменяют маршруты транспортировки бензина в системе контроля передвижения опасных грузов через ГЛОНАСС/GPS? Или вот еще. Как можно обнаружить модификацию ПО, отвечающее за сигнализацию о падении давления в магистральном трубопроводе (по снижению давления можно определить наличие и примерное местоположение незаконной врезки в трубу).И как защищаться от таких инцидентов?

Решить такие задачи очень непросто, т.к. требуется досконально знать, как работает та или иная система на уровне ее бизнес-логики. Инструментов для обнаружения инцидентов на бизнес-уровне немного и можно пересчитать по пальцам одной руки. Например, Appercut Security (и то с оговорками и доработками). Но это именно то, что нужно потребителю и то, на чем он теряет деньги, несопоставимые с ущербом от других видов инцидентов. Точнее это реальные деньги, которых недополучает владелец критически важного объекта. В отличие от вирусных эпедимей, простоев от DoS-атак, утечек информации, ущерб от которых еще надо посчитать и обосновать.

Возможно ситуация со временем поменяется. Если документ СовБеза начнут претворять в жизнь, то акценты могут и сместиться в сторону первых двух описанный мной уровней. Ведь Совету Безопасности по сути все равно - сколько денег не досчитается конкретный владелец критически важного объекта. А вот инцидент, который может повлиять на национальную безопасность, привести к чрезвычайной ситуации, сделать невозможным оказание какой-либо услуги в час Х и т.п. их волнует гораздо больше и поэтому их документы, скорее всего, будут описывать то, что описывают почти все современные стандарты безопасности АСУ ТП - традиционные вопросы защиты - обеспечение доступности, конфиденциальности, целостности компонентов АСУ ТП на нижних уровнях; закрывая глаза на верхний. И потребитель задумается о решении и этой задачи только тогда, когда число инцидентов применения кибероружия увеличится многократно (и именно в России) или когда за невыполнение требований нормативных документов будут выставляться реальные и значительные штрафы.

Пока же потребитель подходит к вопросу защиты АСУ ТП с точки зрения риск-ориентированного подхода (за что было бы глупо его ругать) и требует совершенно не тех средств и услуг защиты АСУ ТП, которые ему пытаются предлагать интеграторы и вендоры. А может я ошибаюсь и есть интеграторы, которые учитывают то, что я написал?

PS. Помимо ИнфоБЕРЕГа на тему АСУ ТП буду также выступать 3-го октября на круглом столе в рамках "Инфобезопасности".

Подробнее…

2% от дохода за нарушение ФЗ-152 - это хорошо или плохо?

Ну и я тоже выскажусь по новому законопроекту об увеличении суммы штрафов до 2% от совокупного дохода компании-нарушителя ФЗ-152. Так уж сложилось, что с этим законопроектом я был ознакомлен еще в июле, о чем писал ранее. Правда, тогда в нем не было этого подхода "в % от дохода". Были зафиксированы миллионные штрафы и сделана дифференциация по составам правонарушений.

Коллеги (Алексей Волков и Евгения Царев) уже прошлись по этому законопроекту и я не буду повторяться; тем более, что свое мнение о составах правонарушений и самом законопроекте я уже отправлял в РКН (в тексте они, к сожалению, не нашли своего отражения). Вкратце они таковы (без конкретных формулировок, отправленных в РКН):

• Наказывать надо за нанесение вреда жизни и здоровью субъекта, а не за нарушение требований, которые зачастую либо двойственны либо невыполнимы. На данный момент наказание за невыполнение требований при почти полном отсутствии официальных разъяснений со стороны Роскомнадзора как выполнять то или иное требование равнозначно вводу карательных мер. Я готов поддержать введение наказаний за неисполнение закона (даже без нанесения вреда), но только при условии опубликования и доведения до операторов ПДн (а не только терорганов) различной информации о том, как правильно выполнять ФЗ-152. Именно так сделано в Европе. Там у многих уполномоченных органов выложены шаблоны документов, разъяснения, чеклисты, опросники и рекомендации, которые показывают "как правильно". А уж если оператор не предпринимает никаких усилий, то его не грех и наказать (но примерно через полгода-год после опубликования официальных рекомендаций по защите). Т.е. помимо кнута должен быть и пряник. В противном случае формирование позитивного общественного мнения о РКН и его деятельности находится под вопросом.
• Из предлагаемой ст.13.11.1 необходимо убрать фразу «а равно обработка ПДн с нарушением установленной законом формы согласия субъекта ПДн». Вопросов к форме согласия тоже немало и то, как правильно получать согласие, вызывает множество споров у юристов. В условиях отсутствия однозначной и официальной позиции РКН по этому вопросу, предлагаю убрать этот фрагмент, оставив просто «обработку без согласия, если согласие обязательно»
• Ст.13.11.2 необходимо перенести в 13.11.1, т.к. по сути речь идет об обработке специальных категорий ПДн без согласия.
• Ст.13.11.3 необходимо убрать вовсе, т.к. порядок трансграничной передачи сегодня нигде не установлен (кроме общих формулировок ФЗ). У нас даже нет до сих пор списка стран с адекватной защитой прав субъектов. Без этого списка, а также без официальной позиции по тому, как защищать ПДн при облачных вычислениях, взаимодействии с иностранными госорганами и правоохранительными органами, при работе в социальных сетях, шум поднимется очень большой. Ведь в нынешней формулировке она приводит к постоянным штрафам многие Интернет-компании и социальные сети. Повторится ситуация с законопроектом по «черным спискам». Но если в случае с законопроектом Мизулиной можно было уйти под «защиту детей от негативной информации», то в случае с 13.11.3 такого повода нет и правозащитники поднимут большую волну возмущения и протеста в российской и зарубежной части Интернет, не говоря уже об очередных наездах со стороны Евросоюза и Госдепартамента, направленных уже в сторону конкретного федерального органа исполнительной власти.

Что касается 2%, то несмотря на то, что активно обсуждается именно "процентный" подход, сам по себе он не является криминальным. Да, он непривычен для российского законодательства. Но именно эта норма и именно эти 2% прописаны в реформе европейского законодательства. Так что Роскомнадзор (хотя еще на Консультативном Совете в конце июля о таком подходе и речь не шло) не открыл Америки, а всего лишь работает на опережение. Рано или поздно, как страна, ратифицировавшая Конвенцию, мы должны были перейти к тому же подходу. Вопрос только в процедуре этого перехода.

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

Это основной тезис. Непонятно, что и как проверяют инспекции РКН? Непонятно как трактовать те или иные требования закона? Непонятно, какие документы все-таки должны быть у оператора ПДн? Непонятно, почему не выложить на сайте РКН шаблоны таких документов (как это сделано у европейских уполномоченных органов)? Непонятно, почему нет рекомендаций (по аналогии с ЦБшными) по выполнению требований закона (в Европе они есть и их много и в разных формах – шаблоны, чеклисты и т.д.)? Непонятны некоторые требования, которые РКН проверяет в рамках инспекций. И т.д. Такая непрозрачность и отсутствие ОФИЦИАЛЬНЫХ, ПУБЛИЧНЫХ и ориентированных на массы операторов ПДн (например, на сайте РКН) комментариев и разъяснений и является отличительной особенностью России в части защиты прав субъектов. Именно она и вызывает основной негатив. Заранее нельзя предсказать, чем закончится проверка, даже если оператор ПДн вложился в эту тему и выполнил очень много каких задач, перестроил процессы, выпустил документы и т.д.

Само по себе ужесточение наказания должно быть более жестким чем 10000 рублей по 13.11 и 5000 по 19.7 КоАП. Это нормально (да и Европа движется в сторону роста штрафов). Но в совокупностью с непрозрачностью и невыполнимостью организационных, юридических и технических требований, увеличение штрафов и переход полномочий прокуратуры к РКН воспринимается всеми как усиление именно карающих полномочий у РКН. Мнение о том, что задача РКН – найти и наказать, только усиливается. А ведь в Европе уполномоченные органы исходят из немного иной парадигмы – они там помогают выполнять требования. И именно поэтому такую реакцию вызвал законопроект на сайте Роскомнадзора.

Алексей Волков у себя дал некоторые рекомендации оператору ПДн, РКН и субъектам ПДн. Я могу к ним только присоединиться. Как можно скорее необходимо публиковать официальные разъяснения на сайте РКН. Иначе стоит ждать очередной волны возмущения... Она уже зреет. Достаточно будет опубликовать новые Постановления Правительства, которые готовятся ФСБ, и все необходимые для взрыва компоненты будут собраны воедино.

Подробнее…