Подарок ФСТЭК к 23-му февраля, перечень объектов КИИ и выборы Президента

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

Речь идет о громком заявлении ФСТЭК, прозвучавшем в среду на конференции "Актуальные вопросы защиты информации" в контексте выполнения требований нового ПП-127 о категорировании объектов КИИ. В заметке, которую я опубликовал как раз в среду, я упомянул, что из финального варианта ПП-127 исчез пункт о том, что на составление перечня объектов КИИ выделяется 6 месяцев, после чего этот перечень согласовывается с отраслевым регулятором и в течение года проводится категорирование объектов КИИ. Так вот ФСТЭК заявила, что перечень объектов надо составить до... 23 февраля 2018-го года. То есть на все осталось 7 дней, включая выходные. 7 дней на составление перечня объектов КИИ!

Почему 23-е февраля и где это написано? Нигде! Этот срок нигде не указан. Он, насколько я понял, вытекает из мнения, что Постановления Правительства вступают в силу через 10 дней после официального опубликования, которое для ПП-127 было 13-го февраля. На самом деле через 10 дней вступают в силу федеральные законы (если срок не оговорен особо), а Постановления Правительства вступают в силу через 7 дней после официального опубликования. Хорошо, что не все знают про 7 дней, а то бы перечень надо было составить не к 23-му, а к 20-му февраля :-)  Раз больше в ПП-127 не говорится о сроке подготовки перечня, то... и вот тут моя логика дает сбой. Я не могу найти ни одного обоснования, почему 23 февраля?

ПП-127 вступает в силу только 20-го февраля (ну, допустим, 23-го, если иметь ввиду срок в 10 дней). До этого момента никаких юридических оснований заниматься категорированием и составлением перечня у субъекта КИИ нет. Он не должен ничего делать раньше установленного срока. К тому же хочу отметить, что составление перечня объектов - это 4-й пункт в процедуре категорирования. До этого надо определить все процессы, выделить из них критические, определить объекты и только потом составить их перечень и утвердить его (а еще и соответствующую комиссию надо создать). Направить утвержденный перечень надо в ФСТЭК в течение 5 рабочих дней после утверждения. То есть если ПП-127 вступает в силу 20 февраля, то "в течение пяти рабочих дней" - это 28 февраля, а не 23-е. Понятно, что в условиях цейтнота можно первыми тремя этапами пожертвовать и сразу составить полный перечень всех ИС и АСУ и отправить его отраслевому регулятору, но все равно срок на составление такого перечня оооочень маленький.

Но есть еще один момент, на который я бы обратил внимание. Согласно п.15 ПП-127 после составления перечня он утверждается субъектом КИИ и только потом согласовывается с отраслевым регулятором. Но... госорганы у нас обычно отвечают на запросы (и это если повезет) в течение 30 дней, а через пять дней после утверждения перечень уже должен быть направлен в ФСТЭК, что невозможно выполнить чисто физически. Даже если бы не было даты 23-го февраля. Тут или не согласовывать с отраслевым регулятором, нарушая одно требование ПП-127, или не успеть за 5 дней направить перечень в ФСТЭК, нарушая другое требование.

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

Однако, закон есть закон. И коль скоро с отраслевым регулятором надо что-то согласовать, то лучше это сделать, так как это будет доказательством того, что вы не бьете баклуши, а реально выполняете требования законодательства. И отправку перечня отраслевому регулятору лучше не затягивать. Причина тому выбору Президента, которые состоятся 18 марта. Потом будет инагурация, потом Правительство по закону должно уйти в отставку, потом будет формирование Правительства, потом его согласование. Если какие-то ФОИВ исчезнут или сменят своего руководителя (а это вполне реально), то начнется неразбериха с подчиненностью исчезнувших ФОИВ, сменой команд в министерствах, выработкой новых/старых правил игры и т.д. Процедура эта небыстрая. Лучше согласование перечня завершить до выборов. Хотя до них уже и осталось меньше 30 дней, выделенных на ответ ФОИВ на запросы.

ЗЫ. Кстати, косяков с законодательством по безопасности КИИ будет еще много. Очень уж оно сырое, что и понятно - в такие сроки нельзя написать что-то достойное и без ошибок. Но тут уж ничего не поделаешь...

ЗЗЫ. Есть мнение, что согласование перечня нужно только подведомственным каким-то ФОИВ предприятиям и коммерческие предприятия сюда не попадают. Это должно вытекать из того же п.15. Но меня в той формулировке смущает фраза не только про госорган, выполняющий функции по разработке, проведению и реализации государственной политики и (или) нормативно-правовому регулированию в установленной сфере, но и про такое же российское юрлицо. Если бы приписки про юрлицо (может это Центробанк?) не было, можно было бы согласиться с этой удобной для коммерческих субъектов версией. В итоге надо внимательно читать полномочия отраслевых регуляторов - на кого распространяется их право по выработке госполитики. Например, тот же Минкомсвязь у нас вырабатывает госполитику в области ПДн, то есть является "главным" для всех операторов ПДн...

Подробнее…

Какая финансовая организация является субъектом КИИ? #ibbank

8-го февраля Правительство утвердило Постановление №127 об утверждении показателей категорирования объектов критической информационной инфраструктуры. Учитывая, что в эти дни под Магнитогорском проходит 10-й юбилейный форум по информационной безопасности организаций финансовой сферы, и в пятницу будет заседание, посвященное как раз обсуждению финансовой организации как субъекта КИИ, я решил пробежаться глазами по установленным критериям и понять, кто из финансовых структур попадет под раздачу. Тут надо сразу оговориться, что субъектами КИИ являются все финансовые организации, а вот значимыми объектами КИИ обладать будут далеко не все из них. Принятое ПП-127 касается как раз вопроса о том, какие объекты КИИ будут признаны значимыми.

Итак, из 5 критериев значимости к финансовым организациям относится только 3-й, "Экономическая значимость". Ни социальной, ни политической, ни экологической значимости, ни тем более значимости для обороноспособности страны, финансовые организации не имеют. Остается только экономическая значимость, в рамках которой выделяется всего 3 показателя:

1. Возникновение ущерба субъекту критической информационной инфраструктуры, который является государственной корпорацией, государственным унитарным предприятием, муниципальным унитарным предприятием, государственной компанией, организацией с участием государства и (или) стратегическим акционерным обществом, стратегическим предприятием, оцениваемого в снижении уровня дохода (с учетом налога на добавленную стоимость, акцизов и иных обязательных платежей) по всем видам деятельности (процентов прогнозируемого объема годового дохода по всем видам деятельности)
2. Возникновение ущерба бюджетам Российской Федерации, оцениваемого:
• в снижении доходов федерального бюджета (процентов прогнозируемого годового дохода бюджета);
• в снижении доходов бюджета субъекта Российской Федерации (процентов прогнозируемого годового дохода бюджета);
• в снижении доходов бюджетов государственных внебюджетных фондов (процентов прогнозируемого годового дохода бюджета)
3. Прекращение или нарушение проведения клиентами операций по банковским счетам и (или) без открытия банковского счета или операций, осуществляемых субъектом критической информационной инфраструктуры, являющимся в соответствии с законодательством Российской Федерации системно значимой кредитной организацией, оператором услуг платежной инфраструктуры системно и (или) социально значимых платежных систем или системно значимой инфраструктурной организацией финансового рынка, оцениваемое среднедневным (по отношению к числу календарных дней в году) количеством осуществляемых операций, (млн. единиц) (расчет осуществляется по итогам года, а для создаваемых объектов - на основе прогнозных значений).

Кто попадает под первый критерий? Финансовых организаций, которые являются ГУПом, МУПом, госкорпорацией или госкомпанией у нас нет. А вот финансовыми структурами с участием государства у нас являются:

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

Предположу, что Бинбанк, Открытие, Рост Банк, Уралприватбанк и Промсвязьбанк тоже можно отнести в этот список, так как ЦБ в рамках санации стал их основным инвестором.

Список стратегических предприятий и стратегических акционерных обществ утвержден Указом Президента от 4 августа 2004-го года №1009 - в нем более 1000 пунктов, большая часть из которых уже удалена. Из финансовых структур там только ВТБ. Но бояться упомянутым организациям не стоит, так как порог входа в список значимых начинается с 5% ущерба от уровня дохода, а это огромная цифра.

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

Остается последний критерий, Системно значимыми кредитными организациями у нас являются, согласно Указанию Банка России от 22.07.2015 3737-У, следующие 11 организаций:

• АО ЮниКредит Банк
• Банк ГПБ
• Банк ВТБ
• АО «АЛЬФА-БАНК»
• ПАО Сбербанк
• ПАО «Московский Кредитный Банк»
• ПАО Банк «ФК Открытие»
• ПАО РОСБАНК
• ПАО «Промсвязьбанк»
• АО «Райффайзенбанк»
• АО «Россельхозбанк».

Системно значимых инфраструктурных организаций финансового рынка у нас всего 4:

• Центральный депозитарий
• Расчетный депозитарий
• Репозитарий
• Центральный контрагент.

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

• Русславбанк и ВТБ (для CONTACT)
• НСПК, Банк России (для Visa)
• Платежный центр, Золотая корона (для Золотой короны)
• Национальный расчетный депозитарий (для НРД)
• Лидер (для ПС Лидер)
• НСПК, Банк России (для MasterCard)
• ВТБ (для ПС ВТБ)
• Сбербанк (для ПС Сбербанка)
• Рапида, ВТБ (для Рапиды).

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

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

Подробнее…

Поправки в ФЗ-149. Чего от них ждать?

Правительство наконец-то внесло в Госдуму долгожданный законопроект с поправками в трехглавый ФЗ-149. Об этом законопроекте впервые упомянул Виталий Лютиков на конференции ФСТЭК в феврале этого года. Основных идей у этого законопроекта было две - распространить его действие не только на ГИС и обязать госорганы информировать ФСТЭК и ФСБ об инцидентах ИБ.

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

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

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

ЗЫ. Кстати, банки, работающие с ГИС ГМП (а их 601) тоже попадают под требования 17-го приказа...

Подробнее…

Кем определяются уровни/классы защищенности в приказах 390/120/190/221 Минкомсвязи?

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

В частности, в п.9 приказа Минкомсвязи от 09.12.2013 №390 «Об утверждении требований к информационным системам организаций, подключаемых к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме» говорится о том, что требования к системе защиты информации информационной системы определяются в зависимости от класса защищенности информационной системы.

Аналогичное требование установлено в п.3 приказа Минкомсвязи от 03.05.2014 №120 «Об утверждении Требований, обеспечивающих технологическую совместимость информационных систем организаций, подключаемых к инфраструктуре, обеспечивающей информационно-технологическое взаимодействие информационных систем, используемых для предоставления государственных и муниципальных услуг в электронной форме с указанной инфраструктурой, к каналу связи и используемым для его защиты средствам криптографической защиты информации, а также особенностей использования стандартов и протоколов при обмене данными в электронной форме между информационными системами указанных организаций и инфраструктурой». 390-й приказ уже отменили, но 120-й продолжает действовать.

В п.66 приказа Минкомсвязи от 27.12.2010 №190 «Об утверждении Технических требований к взаимодействию информационных систем в единой системе межведомственного электронного взаимодействия» говорится о том, что подсистема информационной безопасности каждой информационной системы, подключаемой к системе взаимодействия, должна обеспечивать установленные законодательством Российской Федерации уровни защищенности информации, обрабатываемой в этой системе.

О классах защищенности говорится и в п.22 приказа Минкомсвязи от 02.09.2011 №221 «Об утверждении Требований к информационным системам электронного документооборота федеральных органов исполнительной власти, учитывающих в том числе необходимость обработки посредством данных систем служебной информации ограниченного распространения».

Я сделал запрос в Минкомсвязь и в понедельник получил ответ. Вполне закономерно Минкомсвязь отослала всех к приказу №17 ФСТЭК России.

Подробнее…

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

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

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

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

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

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

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

Подробнее…

Приказ трех по классификации ИСПДн отменен официально

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

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

Акт определения уровня защищенности

ЗЫ. Скачать акт в формате Word можно по ссылке.

Подробнее…

Конференция ФСТЭК. Часть 2. Защита АСУ ТП

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

Тезисы были озвучены следующие:

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

• Документ разработан во исполнение поручения Президента РФ и он должен лечь "под" разрабатываемый ФСБ законопроект по защите критических информационных инфраструктур.
• Классификация АСУ ТП немного отличается от принятой в 17-м приказе - классов защищенности будет 3, а не 4. Это сделано специально - они привязаны к классификации МЧС. Это согласовано с многими критически важными объектами.
• ФСТЭК признает, что в АСУ ТП возможно применение средств защиты информации, прошедших оценку соответствия по ФЗ-184, а не только сертифицированных в ФСТЭК! Именно так - не только подтверждение соответствия в форме обязательной сертификации, но допустимы и другие 6 форм оценки соответствия, упомянутые в законе о техническом регулировании. Это очень важная новация и она была достигнута в результате общения с представителями КВО, участвующих в экспертизе документа.
• Также в документе указано, что для АСУ ТП не требуется аттестации ввиду специфики создания систем управления технологическими процессами и наличия для них достаточно жестких приемочных испытаний, которые и будут подменять собой аттестацию, как форму оценки соответствия всей системы.

• Среди других интересных моментов - согласованность мер по защите и технологической безопасности. Я про это как-то уже писал и вот ФСТЭК в своем документе признает главенство мер по технологической безопасности и их важность.
• Помимо повтора мер из 17-го и 21-го приказа (а они на два блока защитных мер отличаются - управление конфигурацией и управление инцидентами), в документ по АСУ ТП добавлено еще 6 новых блоков защитных мер - безопасная разработка ПО, управление обновлениями, планирование мероприятий, информирование и обучение пользователей, анализ угроз и рисков и обеспечение действий в непредвиденных ситуациях. 

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

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

Подробнее…

Как строится защита государевых информационных систем в США

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

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

 

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

• FIPS 199. Standards for Security Categorization of Federal Information and Information Systems
• NIST SP800-60. Guide for Mapping Types of Information and Information Systems to Security Categories.

Определившись с классами информационных систем, мы должны выбрать защитные меры. Они разбиты на три больших блока - технические, операционные, управленченские, которые затем разбиваются на семейства - контроль доступа, повышение осведомленности и тренинги, аудит, планирование, оценка рисков, защита персонала и т.д. Перечислены эти меры в стандарте NIST SP800-53 Recommended Security Controls for Federal Information Systems and Organizations. Сейчас готовится 4-я редакция этого стандарта, которая будет включать и ранее описанные меры по защите персональных данных. Называться этот стандарт будет Security and Privacy Controls for Federal Information Systems and Organizations (номер тот же).

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

При этом существует минимально необходимый набор защитных мер, описанные в FIPS 200 Minimum Security Requirements for Federal Information and Information Systems. Выбор способа реализации этих мер (из NIST SP800-53), как и дополнительные защитные меры, лежат на операторе/владельце информационной системы. При этом документы NIST учитывают две непростых особенности современной информатизации госорганов. Во-первых, их территориальную распределенность и необходимость защиты двух и более связываемых между собой локальных сетей через недоверенные каналы связи. А во-вторых, массовый переход на облачные вычисления также требует от госорганов, чтобы функции выбора защитных мер могли быть делегированы от владельца защищаемых данных к владельцу информационной системы (облачному провайдеру), в которой эти данные обрабатываются.

Выбрав защитные меры, мы приступаем к их внедрению. Для этого у NIST разработана масса документов по особенностям защиты различных информационных технологий - облаков, мобильных устройств, АСУ ТП, Wi-Fi и WiMAX и т.д. При этом NIST разработал и рекомендации по различным организационным и управленческим процессам - оценка рисков, повышение осведомленности персонала, расследование инцидентов и т.д. Т.е. NIST планомерно закрывает те пару десяткой семейств защитных мер, описанных в SP800-53.

По окончанию внедрения мы должны провести оценку эффективности защитных механизмов. Кто-то это называет аудитом, кто-то аттестацией. Важна суть данного процесса, заключающегося в проверке, желательно независимой, сделанных на предыдущих этапах действий по выбору и внедрению защитных мер технического и организационного плана. Проведение такой оценки описано в SP800-53A Guide for Assessing the Security Controls in Federal Information Systems and Organizations, Building Effective Security Assessment Plans.

И наконец завершается все этапом непрерывного мониторинга уровня защищенности информационной системы, описанного в недавно выпущенном SP800-137 Information Security Continuous Monitoring for Federal Information Systems and Organizations. И дальше по кругу.

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

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

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

Четвертое отличие - в том, что происходит после внедения системы защиты и ее аттестации. У нас хоть потоп (до следующей аттестации). ФСТЭК и ФСБ этот вопрос почти не интересует - главное, чтобы бумажки были и оргмеры были соблюдены. А как на деле происходит поддержание необходимого уровня защищенности? Никто не знает. Поэтому и привыкли у нас жить от аттестации до аттестации, от проверки до проверки. В США ситуация иная - есть рекомендации по выстраиванию процесса мониторинга уровня защищенности, реагирования на инциденты, повышения осведомленности персонала, патч-менеджмента и т.п. Иными словами, госорганы США сопровождаются на всем жизненном цикле существования своих информационных систем. И даже на последнем их этапе, выводе из эксплуатации, NIST предлагает свои рекомендации, например, SP800-88 Guidelines for Media Sanitization (руководство по уничтожение носителей защищаемой информации).

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

Подробнее…

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

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

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

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

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

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

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

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

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

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

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

Подробнее…

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

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

Ответ на этот вопрос очень неплохо описан в книге специалистов компании 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", сводящий различные методы уничтожения  данных для разных типов носителей.

Подробнее…

Моя презентация с DLP Russia 2011

Выкладываю свою презентацию с пятничной DLP Russia 2011. Напоминаю, что это введение в исследование по классификации, которое грядет после ноябрьских праздников.

Information classification

View more presentations from Alexey Lukatsky

Подробнее…

Классификация информации - новое исследование

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

Подробнее…

О классификации информационных активов

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

• быть краткой
• содержать не более 3-4 классификаций
• быть гибкой
• разрешать исключения
• находить баланс между требованиями бизнеса и безопасностью
• позволять отдельным подразделениям создавать собственные политики, базирующиеся на специфических требованиях. Яркий пример - западная компания, работающая в России. Она должна соблюдать и западные правила классификации (например, метки Confidential, Public и т.д.) и учитывать закон "О коммерческой тайне", который подразумевает иные требования к "грифованию" документов.
• не должна быть привязана к конкретным технологиям или подразделениям
• содержать не больше 3-4 уровней классификации.

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

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

Подробнее…

Как идентифицировать активы?

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

Есть и другой аспект, заставляющий нас задумываться о классификации. Речь идет о нормативных и регулятивных требованиях, которые описывают процесс классификации информации и которые являются обязательными де-юре или де-факто - СТО БР ИББС, 98-ФЗ, 149-ФЗ, Р Газпром 4.2-3-001-20хх, СТО Газпром 4.2-3-004-2009, ISO/IEC 27002:2005, ISO/IEC 20000-2, ISO/IEC TR 13569:2005 и т.д.

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

В конце июня NIST вновь порадовал очередным документом - "Specification for Asset Identification 1.1" (NISTIR 7693). В этом документе описывается модель, позволяющая идентифицировать следующие активы:

• персона
• организация
• система
• программное обеспечение
• база данных
• сеть
• сервис
• данные
• вычислительное устройство
• Web-сайт
• линия связи.

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

Подробнее…