Кто все-таки будет отвечать за ИБ КВО - ФСТЭК или ФСБ?

Чуть больше недели назад в Москве прошла отличная конференция - "Безопасность КВО ТЭК", на которой обсуждались различные вопросы в такой горячей теме, как критически важные объекты. Не обошлось и без упоминания законопроекта "О безопасности критической информационной инфраструктуры", который я уже не раз упоминал в блоге и который сейчас находится на финальной стадии согласования перед внесением в Госдуму (в апреле должно состояться это знаменательное событие).

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

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

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

Как защищается China UnionPay?

Президент сегодня заявил, что Россия создаст свою национальную платежную систему, взяв пример с Китая (China UnionPay) и Японии (JCB), которые создав сначала чисто локальные платежные сервисы, затем расширили их до уровня международных. Собственно в данной заметке я хотел посмотреть на опыт JCB и CUP в контексте информационной безопасноти.

С JCB никаких особенностей нет - на эту платежную систему распространяются требования PCI DSS. Более того, несмотря на не очень большой размер доли рынка, представитель JCB входит в исполнительный комитет PCI SSC наряду с представителями других 4-х международных платежных систем - Visa, MasterCard, American Express и Discover.

А вот с China UnionPay ситуация немного иная. На эту платежную систему требования PCI DSS  не распространяются. Представителей CUP нет в исполнительном комитете PCI SSC, хотя как рядовой член PCI SSC они на сайте упомянуты. Будучи сугубо локальным китайским продуктом CUP развивалась по своему и с точки зрения информационной безопасности. Все, что мне удалось найти по данной теме - это 4-й раздел руководства по электронным платежам и его 23-я статья, которая отделывается общими словами о необходимости наличия стандартов по ИБ. 24-я статья говорит об управлении рисками, 25-я - об установке лимитов на перевод денежных средств. 26-я статья устанавливает требования неотказуемости транзакций, 27-я защищает банковскую тайну. В последующих 10-ти статьях руководства говорится об авторизации персонала, разделении ответственности, возможности аутсорсинга. Глубокой детализации, схожей с PCI DSS, 382-П или СТО БО ИББС нет и в помине. С 2013-го года в UnionPay внедряется стандарт EMV для чиповых карт. Вот и вся их безопасность.

К чему такой экскурс? Просто рассчитывая на лучшее, всегда надо готовиться к худшему, и банки, являющиеся участниками платежных систем Visa и MasterCard должны быть готовы к тому, что против упомянутых систем могут быть введены санкции. И хотя главы ЦБ и Минфина высказали мысль, что отказываться от Visa и MC не надо, нет никакой гарантии, что наши власти не начнут работать на опережение и не начнут "читать мысли" Президента, ставя палки в колеса компаниям, которые решили пойти супротив России. Понятно, что и Visa, и MasterCard исполняли волю американского государства и по своей инициативе врядли отказались бы от такого лакомого куска, как Россия (хотя доля карточных платежей этих МПС в общем объеме пока ничтожно мала). Но самим США санкции сложно организовать, а вот их "проводникам" вполне - примеров наша история знает немало. Именно поэтому на прошлой неделе в Госдуму был внесен законопроект о запрете работы в России платежных систем, неимеющих у нас своего операционного центра. Пока никто из международных платежных систем его не имеет, а многие и не планируют даже. Если законопроект примут, то работа МПС в России будет блокирована, статус оператора платежной системы отозван и выданные у нас карточки превратятся в красивый пластик.

Возможно у нас возродится УЭК/ПРО100 - об этом говорят сейчас много. Возможно на переходный период у нас оставят все МПС. Возможно оставят только "дружественные" нам МПС (JCB/CUP). Возможно не оставят ничего. Возможно все скоро утихнет и чиновники по-прежнему будут ездить заграницу не с наличными, а с карточками Visa или MC. Возможно МПС построят в РФ свои операционные центры. Говорить пока рано, как и строить какие-то прогнозы. В любом случае риск этот уже ненулевой и стоит искать альтернативы. Поэтому и знание того, как защищаются не столь популярные в РФ (за исключением дальневосточных регионов) платежные системы будет не лишним.

Побуду рупором 8-го Центра :-)

Учитывая определенную закрытость ФСБ в целом и 8-го Центра в частности, решил на один день стать рупором этого регулятора, который вчера на РусКрипто озвучил ряд планов развития своих нормативно-правовых актов в области криптографии. Планов ровно 3:

• Новые требования к СКЗИ& Это, пожалуй, самое интересное для потребителей изменение. Тезисно:
• КВ1 - класс явно невостребованный. За последние 5 лет сертифицирована на КВ1 была всего одна СКЗИ. Поэтому этот класс, скорее всего, уберут из проекта новых требований к СКЗИ.
• 8-й Центр хочет наконец-то сделать требования к СКЗИ открытыми. Делается это для потребителей, которые хотят знать, что же скрывается за каждым из классов. Если все пойдет хорошо, то к концу года документ опубликуют.
• Планируется также изменить ряд числовых показателей, учитывающих последние тенденции в области ИТ, криптографии и криптоанализа.
• ФСБ положительно оценивает документ ФСТЭК по обновлению сертифицированных СЗИ. Они планируют выпустить такой же. Дима Гусев из Инфотекс об этой замечательной идее уже говорил на конференции ФСТЭК в феврале.
• Одно из революционных изменений касается необходимости упорядочивания ситуации с сертификацией СКЗИ или информационные системы, использующих сертифицированные криптобиблиотеки. По мнению 8-го Центра разработчики совершенно не думают о безопасности среды функционирования СКЗИ и совершенно наплевательски относятся к управлению ключами и интерфейсам между прикладными системами и криптобиблиотеками. С этой целью вводится понятие (неформально - в документе его не будет) законченного средства криптографической защиты, которое будет включать в себя весь комплекс криптографических примитивов - от зашифрования/расшифрования или генерации/проверки/визуализации электронной подписи до управления ключами, включая их защищенное хранение. Общая идея понятна, но вот ее реализация пока абсолютно невнятна и к лету планируется выйти уже на более менее сформированный подход. Последствия для потребителей и разработчиков информационных и прикладных систем пока сложно предсказуемы. 
• Учитывая изменения по части функционально законченных СКЗИ была высказана мысль, что классы КВ и КА теперь будут жестко зафиксированы в своей аппаратной среде/конфигурации и программно их реализовать без привязки к "железу" будет почти невозможно. Предвижу сложности с облачной реализацией криптографии и с реализацией высокоуровневой криптографией на виртуализированных платформах. На мобильных устройствах ждать КВ тоже не придется (если это не специализированные планшетники или телефоны). Вообще тема мобильных СКЗИ в условиях функциональной законченности у меня вызывает большие вопросы... 
• Переход к ГОСТ 34.10-2012 активно идет. Начался он официально совсем недавно (с 01.01.2013), а с 01.01.2019 применение ГОСТ 34.10-2001 уже не допускается. С 01.01.2014 ФСБ уже не принимает к рассмотрению ТЗ, в которых не учтен новый ГОСТ. Аккурат к этому времени сертификаты на действующие реализации ГОСТ 34.10-2001 закончат свое действие. Правда, у меня все эти потуги с заменой одного ГОСТа на другой вызывают банальный практический вопрос - что будет с признанием документов, подписанных "старым" ГОСТом после 2019-го года? Соответствующих СКЗИ уже не будет, а долгосрочное хранение юридически значимых документов как-то надо обеспечивать. Но, видимо, этот вопрос ввиду вакханалии с ФЗ-63 мало кто задает или просто не знает, как на него ответить.
• Долгожданное обновление ГОСТ 28147-89 включает в себя утверждение в этом году новой редакции ГОСТа с 128-битным блоком (сейчас 64), а также с набором фиксированных узлов замены. Еще один разрабатываемый ГОСТ будет описывать  режимы работы блочных шифров. Какие конкретно режимы сказано не было, но судя по ссылке на американский опыт, речь идет о серии NIST SP800-38, включающей сейчас 12 различных режимов работы блочных шифров.

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

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

О риск-ориентированном подходе и статистике инцидентов ИБ в АСУ ТП

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

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

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

Статистика реальных инцидентов ИБ в индустриальных системах

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

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

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

Статистика инцидентов по отраслям

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

Время простоя от инцидента ИБ

Наиболее популярные последствия от инцидентов предсказуемы - снижение объема производства / операций (как в случае со Stuxnet), потеря управления устройствами, снижение продуктивности персонала.

Последствия от инцидента ИБ

С финансовой точки зрения статистика RISI объем потерь в более половине случаев не превышает 100 тысяч долларов США.

Масштаб финансового ущерба

Чаще всего в инцидентах бывает замешаны контроллеры (PLC), распределенная система управления (DCS), Master SCADA, индустриальный ПК и HMI.

Замешанное в инциденте оборудование

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

Метод обнаружения инцидента

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

Протоколы, в рамках которых произошел инцидент

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

Тип инцидента

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

Тип нарушителя

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

Точка входа в АСУ ТП

Есть еще две диаграммы, которые интересны с точки зрения статистики. Это данные американской компании Red Tiger, занимающейся аудитом и тестами на проникновение в индустриальных сетях. За время своей работы они проанализировали немало сетей и собрали статистику об уязвимостях в различных сегментах АСУ ТП и типах встречаемых в них эксплойтах.

11 новых поглощений на рынке ИБ

Как-то упустил я из ввиду сделки по поглощению игроков рынка ИБ за последнее время. Наверстываю упущенное :-)

Вчера частная калифорнийская компания Palo Alto объявила о подписании соглашения о приобретении другой частной израильской компании Cyvera. Детали сделки не разглашаются. Однако хочу заметить, что Palo Alto повторяет путь других игроков рынка сетевой безопасности, решивших расширить свое портфолио продуктами по защите оконечных устройств. В частности Cisco в прошлом году купила Sourcefire и получила в свое распоряжение систему защиты мобильных, стационарных и виртуальных устройств FireAMP.

24-го февраля Google купил английский стартап Spider.io, занимающийся средствами защиты рекламных баннеров от вредоносного ПО и мошенников. Детали сделки вновь не разглашаются.

19-го февраля Synopsis подписал соглашение о приобретении Coverity, компании, известной на рынке анализа качества и безопасности ПО. Сумма сделки - около 350-375 миллионов долларов.

17-го февраля Google купил израильскую компанию SlickLogin, которая занималась звуковыми паролями. Детали сделки опять не разглашаются.

13-го февраля Bit9, известная своими решениями по защите оконечных устройств, объявила о слиянии с Black Carbon, которая занималась решениями по реагированию на инциденты. Детали сделки не разглашаются. Обе компании небольшие (оборот Bit9 в 2013-м году составлял чуть менее 50 миллионов долларов по всему миру) и почти неизвестны в России; вторая так уж точно.

12 февраля российская компания Infowatch объявила о приобретении бизнес-направления FinallySecure у немецкой ИБ-компании SECUDE AG. Детали сделки неразглашаются. Это событие интересно тем, что речь идет о российской компании, которые не так часто радуют нас сделками по поглощению кого-либо. Для Infowatch же это не первый опыт - в 2010-м году она уже приобрела питерскую Cezurity, годом спустя - немецкую EgoSecure, а еще спустя год - Appercut Security.

21-го января HID Global объявила о приобретении IdenTrust, компании, занимающейся средствами аутентификации, шифрования и управления электронными подписями. Детали сделки не разглашаются.

15 января абсолютно незамеченной прошла сделка по приобретению американской CipherCloud другой американской компании CloudUp Networks. Детали сделки не разглашаются, но сама она касается облачных сервисов по ИБ.

6 января Orange приобрел крупнейшую французскую компанию в области кибербезопасности - Atheos, усилив свое портфолио решениями MSS по управлению Identity и ИБ.

17 декабря Datacard Group объявила о приобретении у фонда Thoma Bravo известной в области цифровой идентификации и шифрования компании Entrust. Про Thoma Bravo я уже писал неоднократно - этот фонд специализируется на ИБ-компаниях, скупая их, а затем продавая другим покупателям, немало навариваясь на этом.

Совершенно пропустил прошлогоднюю сделку по покупке IBM'ом Trusteer'а, борющегося с финансовым мошенничеством и целенаправленными угрозами, за, примерно, 1 миллиард долларов (детали сделки не разглашаются). Произошло это в августе.

Кратко об очередных изменениях законодательства

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

• Проект Постановления Правительства Российской Федерации "О международно-правовой защите присвоения (назначения) радиочастот или радиочастотных каналов и о порядке использования на территории Российской Федерации спутниковых сетей связи, находящихся под юрисдикцией иностранных государств". Движение в сторону цифрового суверенитета продолжается. Про передачу информации ограниченного доступа через иностранные спутники тоже пару слов сказано.
• Проект Постановления Правительства Российской Федерации «О правилах технологического функционирования электроэнергетических систем». В этих 182 страницах меня удивил тот факт, что ни слова не сказано про информационную безопасность. А ведь про движение в сторону Smart Grid (а они без ИБ никуда) у нас так много говорили :-(
• Федеральный государственный образовательный стандарт "Безопасность информационных технологий в правоохранительной сфере".
• Профессиональный стандарт специалиста по информационной безопасности. Обсуждали его много. Критиковали еще больше. Даже конференции проводили.
• Письмо ЦБ от 14.03.2014 №42-Т "Об усилении контроля за рисками, возникающими у кредитных организаций при использовании информации, содержащей персональные данные граждан". Ничего сверхестественного - просят усилить контроль :-)
• Ответы Банка России на вопросы по применению 9-й статьи ФЗ-161. Мне кажется, что это новое разъяснение. По крайней мере я его не видел раньше, хотя оно и датировано февралем этого года.

Мировой рынок средств ИБ индустриальных решений

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

За основу презентации были взяты три отчета:

• Industrial Control Systems (ICS) Security Market - Global Advancements, Market Forecast & Analysis (2013 - 2018) от Markets and markets
• ICS Cyber Security Solutions от ARC Advisory Group
• Industrial Control Systems Security (SCADA Security, Industrial Control Networks, Human-Machine Interfaces, Device Controllers, and SCADA Telecommunications: Market Issues, Best Practices, and Global Forecasts) от Pike Research (была куплена Navigant Research). 

Так как на доклад было выделено не так уж и много времени - всего 20-25 минут, то в глубину не вдавался. Рассмотрел только ключевые особенности этого рынка, основные типы используемых решений, перечислил основных игроков. Кстати, в отчете Markets and Markets говорится о Positive Technologies, единственной российской компании, упомянутой в связи с защитой индустриальных решений.

Мировой рынок ИБ индустриальных решений from Alexey Lukatsky

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

ЗЗЫ. В АИС появился еще один курс, длящийся 5 дней и имеющий бОльшую практическую направленность в части защиты АСУ ТП.

Lockheed Martin покупает Industrial Defender

12 марта известная мировая компания Lockheed Martin (аэрокосмическая отрасль) объявила о подписании соглашения о приобретении известного игрока рынка ИБ АСУ ТП, компании Industrial Defender, решения которой особенно популярны в нефтегазовой и химической отраслях, а также отрасли коммунальных услуг. Детали сделки не разглашаются.

Что такое целенаправленная атака - демонстрация с цифрами в руках

В свое время я публиковал эту картину с целью продемонстрировать рост числа целенаправленных (APT) атак. Картинка интересна тем, что показывает серьезный рост того, чем сейчас активно пугают заказчиков все - журналисты, производители, интеграторы и другие ("Маска", "Красный октябрь" и т.п.). И это не просто страшилка, а данность, с которой кто-то уже сталкивается или столкнулся в недавнем прошлом.

Но у данной картинки есть недостаток. Она не дает ответа на вопрос - "Что же такое APT и чем она отличается от обычных атак, к которым мы все привыкли". Т.е. на пальцах все все понимают, но вот с цифрами в руках объяснить, что это такое, сложно. И вот на днях я набрел на красивую иллюстрацию этого отличия. Эта инфографика по отчету Verizon, в котором проанализированы временные разрывы между различными этапами жизненного цикла угрозы - атака, компрометация, утечка данных, обнаружение угрозы, устранение угрозы.

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

А как бороться с такими угрозами мы рассмотрим завтра :-)

Как читать заблокированные сайты?

Сегодня РКН выдал предписание операторам связи на блокирование ряда сайтов, содержащих якобы вредоносный контент. Комментировать политическое решение РКН не буду, хочу поднять тему, вынесенную в заголовок заметки - как читать заблокированные сайты? Так уж сложилось, что несмотря на наличие рекомендаций РКН по блокированию сайтов, многие операторы по-прежнему тупо рубят по IP-адресам, на которых могут находится сотни и тысячи доменов. Почему-то провайдеры не могут применить блокирование по DNS или URL, а также не применяют DPI... В итоге страдают не только владельцы заблокированных сайтов (часто виновных только в своей оппозиционной позиции), но и владельцы ресурсов, находящихся на одном IP с первыми.

Я не исключаю, что в какой-то момент "под раздачу" может попасть и мой блог. Не потому, что я весь из себя такой оппозиционный, а потому, что на Blogger может находиться блог с "вредным" контентом. И тогда операторы, неспособные заблокировать доменное имя и не имеющие финансов на приобретение нормальных средств фильтрации, тупо прикроют доступ и к моему блогу. А это потеря 85% аудитории, которая ходит из России.

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

• прописать в настройках браузера адреса прокси-серверов (HTTP/SOCKS/анонимайзеры)
• использовать браузер Tor
• использовать специальные плагины к браузерам (или встроенные функции Chrome/Яндекс.Браузер)
• использовать VPN (аккурат сегодня на лайфхаке статья про это)
• использовать I2P
• арендовать выделенный сервер и ходить через него.

Из полезных ссылок по теме:

- статья на sputnikipogrom

- обзор на Хабре из 4-х частей

- еще обзор на Хабре

Какой метод лучше сказать не могу - я использую VPN, который устраивает меня на все 100%, но кому-то может подойти и что-то другое.

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

Размышления о взломе SearchInform

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

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

Первым делом я бы хотел охладить пыл тех, кто начнет активно глумиться над SearchInform. Вы уверены, что с вами такого не произойдет или не произошло? Сейчас настало то время, когда 100%-й гарантии защищенности нет ни у кого - ни у потребителей, ни у разработчиков средств защиты. Как показывает ежегодный отчет Cisco по информационной безопасности, целенаправленных атак становится все больше. А если посмотреть на статистику за последние 10 с лишним лет, то ситуация и вовсе пугающая.

Такие угрозы могут попасть в корпоративную сеть (даже разработчика по безопасности) кучей разных способов - через периметр, через "левую" точку доступа, установленную для облегчения работы, через 3G/4G-модем, через мобильное устройство, обновляемое через ActiveSync... Да мало ли еще как. И гарантировать, что угроза не попадет или не попала в сеть сегодня невозможно.

Поэтому с точки зрения защиты так важно не просто пытаться построить "стену" вокруг защищаемого актива (для этого нужны МСЭ, VPN, сканеры уязвимостей, системы управления патчами, NAC и другие технологии контроля доступа); это необходимо, но уже недостаточно. Необходимо быть готовым обнаруживать атаку во время ее проникновения в сеть (с помощью IPS, антивирусов и систем контентной фильтрации). Но и этого мало. Нельзя полностью исключать компрометацию сети или отдельных узлов. Поэтому нужны средства и технологии обнаружение уже взломанных устройств, локализация угрозы с целью недопущения ее распространения по сети и выхода за ее пределы, "лечения" и устранения последствий. Только при такой трехзвенной архитектуре (ДО, ВО ВРЕМЯ и ПОСЛЕ атаки) можно быть уверенным, что вероятность нанесения ущерба будет сведена к минимуму. Мы в Cisco, например, именно под влиянием этих тенденций анонсировали изменение своей стратегии защиты и обновление продуктовой линейки.

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

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

9 лет назад я уже делал презентацию на эту тему. Могу заметить, что она не потеряла актуальности. Поэтому выложу ее еще раз - может кому-то будет полезным. Также напомню, что этот аспект управления инцидентами рассматривается и в моем одноименном курсе.

You are hacked? How contact with press? from Alexey Lukatsky

ЗЫ. А пока все с нетерпением ждут, как себя поведет SearchInform в этой ситуации? Зароет голову в песок или обратит это событие в свою пользу.

Об обязательности обезличивания

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

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

Примерно также я рассуждал и в отношении ПП-211, в котором говорится, что государственный или муниципальный оператор ПДн может использовать обезличивание и в этом случае он должен руководствоваться руководящими документами Роскомнадзора. Но относительно недавно ко мне обратились с вопросом - якобы обезличивание является обязательным для госов и муниципалов и отказаться от него нельзя. "Ну нет", - подумал я, - "Быть такого не может". И обратился в РКН за разъяснением.

И вот на днях я такое разъяснение в устной форме получил. Обезличивание действительно является обязательным - отказаться от его невыполнения нельзя! Вот так! Делайте выводы! При проверках эту тему будут спрашивать!

ЗЫ. У прокуратуры такое же мнение - обезличивание для госов и муниципалов обязательно!

О лицензировании деятельности по защите информации и криптографии

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

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

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

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

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

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

ЗЗЫ. Совсем отказаться от лицензирования не предлагать :-)

Законопроект о запрете хостинга госсайтов за пределами РФ

В четверг в Госдуму был внесен законопроект о запрете размещения сайтов государственных органов за пределами Российской Федерации. Если тезисно, то в нем интересны следующие моменты:

• распространяется на государственные и муниципальные сайты
• средства защиты таких сайтов должны соответствовать законодательству о техническом регулировании (про сертификацию ни слова)
• наконец-то дан ответ про ФГУПы, государственные и муниципальные учреждения (ради одного этого можно было бы принять этот законопроект) и кто им устанавливает требования
• все сведения и документы, находящиеся в распоряжении госоргана считаются государственным информационным ресурсом
• за несоблюдение требований устанавливается административная ответственность
• оператором государственного сайта может быть либо орган государственной власти или местного самоуправления, а также уполномоченное ими российское юрлицо
• в КоАП вносится новая статья о нарушении требований о размещений госсайтов - штраф на должностных лиц до 5 тысяч рублей
• про запрет использования e-mail на зарубежных хостингах ни слова не сказано.

Презентация по проекту приказа ФСТЭК по защите информации в АСУ ТП

Вчера выступал с рассказом о проекте приказа ФСТЭК по защите информации в АСУ ТП и готовил к выступлению презентацию, которую и выкладываю ( в конце будет немного информации о Cisco).

Проект приказа ФСТЭК по защите информации в АСУ ТП from Alexey Lukatsky

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

Что такое государственная информационная система или на кого рассчитан 17-й приказ ФСТЭК?

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

• Артем Агеев считает, что ГИСами по сути можно считать только те ИС, которые находятся в реестре Минкомсвязи. 
• Андрей Прозоров считает, что не каждая ИС в госоргане является государственной и попадает под действие 17-го приказа.
• Михаил Новокрещенов считает аналогично, но при этом, если ИС вводится в действие приказом и вводится в госоргане, то это уже ГИС.

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

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

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

Что мы имеем в сухом остатке? Есть несколько позиций по этому вопросу. Если следовать логике "нет регистрации в реестре - нет ГИС", то получается, что госорган или орган местного самоуправления должен следовать сразу нескольким наборам требований по защите - 17-й приказ, 21-й приказ, СТР-К. Это очень неудобно и возникнет несогласованность между различными требованиями; особенно СТР-Кшными, которые пока никто формально не отменял. Если же следовать логике Минкомсвязи (оно формальнее и нравится мне больше, чем та же позиция РАНХиГС), то невзирая на наличие регистрации в реестре любая ИС, созданная в любом госоргане или органе местного самоуправления будет считаться государственной (или муниципальной соответственно), если есть приказ о ее создании или, что более вероятно, о вводе ее в эксплуатацию. А значит, что сфера действия 17-го приказа гораздо шире, чем считалось раньше, и под его действие попадают почти все госорганы и муниципалитеты.

Впечатления от RSA Conference от того, кто на ней не был :-)

В прошлом году я проанализировал встречаемость различных слов в программе RSA Conference за шесть лет - с 2008-го по 2013-й год. Решил повторить :-) Если взять темы 310 докладов и без обработки загнать их в соответствующий сервис, то получится такая картинка.

Слово "security" предсказуемо выбивается на общем фоне и не позволяет адекватно оценить направления развития отрасли (если считать, что RSAC задает тон всей индустрии). Я убрал слово "security" и получилось уже иная картинка.

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

• Технология "песочницы" (sandbox). Представлено было 10+ компаний, которые что-то предлагали в этой области (Cisco тоже предлагало решение :-)
• Автоматизация процессов ИБ и по возможности максимальное исключение человека из процесса принятия решений об угрозах и т.п.
• Отражение DDoS по-прежнему горячая тема.
• Всеобъемлющий интернет и "Интернет вещей", как его подмножество. Пока никто не ожидает большого спроса на эти решения, но народ готовится к всплеску и поглощениям :-)
• Тема безопасности облаков и SDN была не столь активной, как в прошлые годы, но все равно была представлена. А вот тема ИБ виртуализации была вполне на волне...
• Big Data и ИБ в различных комбинациях.

И еще 2 проекта документов ФСТЭК

И в заключение еще пара документов, которые так и не увидели свет :-( Первый должен был дополнить набор документов по "Общим критериям", который в середине 2000-х годов был принят в России, но так и не получил адекватного распространения. Сейчас ФСТЭК к нему вернулась, выпуская новые РД с требованиями к средствам защиты в виде адаптированных "Общих критериев".

Второй документ более интересен. Он определяет основные направления совершенствования нормативно-методической базы и организационных основ проведения оценки соответствия автоматизированных систем требованиям безопасности.

Иными словами, ФСТЭК в 2004-м году хотела уйти от устаревших подходов к аттестации АС, которые в документе и были перечислены:

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

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

Концепция аудита ИБ от ФСТЭК

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

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

В этом документе рассматривался целый ряд интересных вопросов - от основных видов аудита ИБ и критериев аудита до выстраивания программы аудита (security program) и вопросов взаимоотношений аудитора и проверяемых. Напомню, что это 2004-й год!

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

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

Проект концепции активно использовал подходы, изложенные в 27-й серии (на тот момент 17799) и документах BSI по аудиту безопасности. При этом сфера документа была сознательно сужена тремя типами проверяемых организаций:

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

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

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

Документ ФСТЭК по жизненному циклу, так и не увидевший свет

09.09.09 я написал заметку о том, как 10 лет назад должна была развиваться система нормативно-методических документов ФСТЭК России. На тот момент не получилось :-( Хотя часть документов была разработана, но не принята. И вот вчера, в очередной раз разбирая свою библиотеку я наткнулся на ряд документов, которые так и остались в статусе проектов.

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

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

Опираясь на ГОСТ Р ИСО/МЭК 15408 данный проект выделял 5 этапов жизненного цикла, для каждого из которых предлагались свои мероприятия по защите информации:

• задание требований к изделию ИТ
• разработка изделия ИТ
• ввод в действие
• эксплуатация
• снятие с эксплуатации.

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

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

Отдельным приложением к этому РД шла 35-тистраничная базовая модель обеспечения ИБ в жизненном циуде ИТ, визуализирующая и детализирующая отдельные характеристики процесса обеспечения ИБ.

В целом, документ, даже спустя 10 лет, остается очень неплохим. И если бы его можно было реанимировать, то он мог бы составить неплохую пару с разрабатываемым ГОСТом по SDLC, который сейчас создается при ТК362.