20.02.2017

Конференция ФСТЭК: сертификация средств защиты

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

  • С 2011-го года ФСТЭК уже утвердила требования к 6-ти типам средств защиты - системам обнаружения вторжений, антивирусам, средствам доверенной загрузки, средствам контроля съемных машинных носителей, межсетевым экранам и операционным системам. По одному средству защиты в год…
  • В 2017-м году планируется принятие требований к СУБД и средствам управления потоками информации (они уже написаны и готовятся к утверждению), а также требования к средствам виртуализации. Больше никаких планов озвучено не было, что и понятно - ФСТЭК их не соблюдает с завидной регулярностью. Находятся более приоритеные задачи (то разработка новой версии СТР, то еще что-то), которые, в условиях нехватки персонала и отсутствии Agile-методологии разработки нормативных актов, не позволяют ФСТЭК выпускать документы с такой же скоростью, что, например, тот же NIST.
  • Также ФСТЭК планирует выпустить методички по поиску НДВ и уязвимостей (при наличии или отсутствии исходных текстов ПО). Заявляется, что методы будут отличаться в зависимости от класса и типа ПО. Это позитивно. Негативно то, что эти документы обещают выпустить уже года два; как и методику моделирования угроз.
  • ФСТЭК стала большее внимание уделять не просто первичной сертификации, а именно поддержке сертифицированного продукта в актуальном и защищенном состоянии. Для этого ФСТЭК регулярно проверяет устранение известных уязвимостей из БДУ ФСТЭК и даже проводит эксперименты по социальному инжинирингу, звоня в службы поддержки производителей и проверяет качество их работы с потребителями. Неудовлетворительная работа производителей/заявителей заканчивается внушением со стороны регулятора, а иногда и более серьезными последствиями. В частности, на конференции прозвучало, что отозвано было 3 сертификата на средства защиты, в которых заявитель отказался устранять уязвимости и повторно проводить инспекционный контроль сертифицированного изделия. На фоне почти 4-х тысяч сертификатов число 3 невелико, но с другой стороны, это первый шаг в усилении контроля со стороны ФСТЭК и обеспечении реальной, а не бумажной защищенности предприятий, использующих сертифицированные реешения.
  • Вопросу качества сертифицированных решений вообще было посвящено много внимания. Например, ФСТЭК сетует на отсутствие у многих российских производителей практики и процедур безопасной разработки (о том, как это сделано у импортных производителей я и рассказывал в своей презентации), что приводит к увеличению сроков устранения уязвимостей (некоторые заявители, особенно сертифицирующие по схеме “партия” и “единичный экземпляр”, и вовсе забивают болт не только на уведомление потребителей о найденных и устраненных уязвимостях, но и на само устранение).
  • Для ФСТЭК, как мне показалось, стало сюрпризом, что отдельные производители сертифицированных решений специально ищут уязвимости в продукции своих конкурентов и “сливают” эту информацию в ФСТЭК в рамках конкурентной борьбы. Регулятор обещал бороться с такими случаями.


Вообще ФСТЭК меняется в лучшую сторону в части изменения и подходов и требований к средствам защиты, которые в условиях импортозамещения должны встать на защиту российских организаций. Правда, самих средств больше не становится (часть 1 и часть 2 про это), а учитывая усиление требований к сертификации, к заявителям, к самим продуктам, и не станет. Тут, увы, либо шашечки, либо ехать. Либо требования усиливать, как того велит Верховный главнокомандующий, либо рынок средств защиты развивать, которому надо дать свободу на первых порах и только потом уже загонять в определенные рамки. Я вернулся вчера из США, с конференции/выставки RSA, где уже не первый раз наблюдаю интересную картину - каждый год пояляется с несколько десятков новых игроков, предлагающих либо новый взгляд на известную проблему, либо совсем новое решение. И никто их не загоняет в прокрустово ложе каких-то там требований. Если стартап, конечно, не хочет идти в госсектор или в Минобороны. Вот тогда от него потребуют по максимуму. На коммерческом же рынке раздолье и всем находится место. Ну да ладно, история рассудит, в правильном ли направлении мы движемся.

15.02.2017

Конференция ФСТЭК: мониторинг ИБ и SOCи

По SOCам на конференции ФСТЭК особо ничего нового не прозвучало, кроме нескольких отдельных моментов:
  • Все опубликованные ФСТЭК требования к SOC (услуге по мониторингу) придуманы не ФСТЭК, а поставщиками услуг ФСТЭК, которые были приглашены в ноябре в ФСТЭК для обсуждения требований к новому виду деятельности. Это прозвучало интересно на фоне того, что во время обсуждения моей заметки в Фейсбуке, участвующие во встрече поставщики услуг SOC, заявили, что они были против того, что появилось в финальной версии документа. Если все были против, а ФСТЭК сама ничего не придумала, то кто все это придумал?
  • Требования к SOC прописаны по максимуму, что было мотивировано тем, что к владельцу SOC может обратиться владелец ГИС 1-го класса защищенности и владелец врядли откажется от денег за мониторинг. Отсюда и максимальные требования. При этом никаких делений по видам деятельности клиентов не предусмотрено, так как закон о лицензировании отдельных видов деятельности, как и 79-е Постановление Правительства также не проводят никакого водораздела. 
  • Позицию ФСТЭК по списку обязательного для получении лицензии ФСТЭК оборудования я не понял. С одной стороны мысль о том, что SOC, имеющий доступ к средствам защиты заказчика, должен и сам быть защищенным, вполне разумна. Но вот дальше не совсем понятно. Почему список используемых средств именно такой? И ЧТО ТАМ ДЕЛАЮТ WAF?  На конференции прозвучало, что WAF должен быть не у SOC, а у заказчика, которого взяли на мониторинг. ЗАЧЕМ??? Если уж SOC должен быть аттестован на соответствие требованиям к ГИС 1-го класса, то зачем отдельно устанавливать еще какие-то требования к номенклатуре средств защиты, применяемых для защиты SOC? 
  • SOC должен быть аттестован по требованиям к ГИС 1-го класса. Эта позиция была уже обоснована выше. Если к владельцу SOC придет владелец ГИС 1-го класса, то два владельца смогут подружиться, только имея системы с одинаковым уровнем защиты. А то, что владелец SOC может быть ориентирован только на малый бизнес и вообще не хотеть работать с госорганами, так это ФСТЭК не особо волнует, так как они исходят из худшего сценария развития событий (worst case).
  • Непрозвучавшая на конференция тема с применением только сертифицированных СКЗИ от SOC до объектов мониторинга особо развернута не была. С одной стороны ФСТЭК утверждает, что это придумали сами владельцы SOC. С другой - в кулуарах была высказана версия, что как раз Национальный координационный центр по компьютерным инцидентам при ФСБ (НКЦКИ), отвечающий за ГосСОПКУ, такие требования даже не планировал устанавливать, понимая, что это малореально. А малореально это потому, что существует большое количество сценариев, где сертифицированных СКЗИ попросту нет. Но владельцы SOC дышат оптимизмом - в запале дискуссий на эту тему они даже заявляют, что у них и сейчас клиенты присоединяются к SOC с помощью сертифицированных VPN.

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

14.02.2017

Конференция ФСТЭК: новые требования к лицензиатам

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

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

Но… допустим занимались вы мониторингом ИБ на работе и могли бы рассчитывать, что ваша квалификация и стаж подойдут ФСТЭК при рассмотрении документов на лицензирование. Но в трудовой книжке у вас написано традиционное - “инженер по технической защите информации”, “техник по защите информации”, “главный специалист по технической защите информации” или “администратор по обеспечению безопасности информации”. А почему нет? Именно так должности звучат в приказе Минздравсоцразвития от 22 апреля 2009 г. № 205 «Об утверждении единого квалификационного справочника должностей руководителей, специалистов и служащих, раздел «квалификационные характеристики должностей руководителей и специалистов по обеспечению безопасности информации в ключевых системах информационной инфраструктуры, противодействию техническим разведкам и технической защите информации».


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

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

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

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

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

ЗЫ. А еще меня удивило число лицензиатов ФСТЭК в России. Я никогда не думал, что у нас столько разработчиков средств защиты информации.


13.02.2017

Конференция ФСТЭК: общие впечатления

На прошлой неделе прошла конференция “Актуальные вопросы защиты информации”, традиционно проводимая ФСТЭК России. У меня будет еще несколько фокусных заметок по отдельным темам, озвученным на мероприятии, а сейчас я бы хотел тезисно осветить то, что мне запомнилось из общих тем:
  • Уже традиционно могу отметить готовность регулятора к диалогу, умение вести дискуссию, навыки чтения презентаций. Это позитивно и улучшается каждый раз, что я вижу публичные выступления ФСТЭК.
  • Некоторые коллеги обвиняют ФСТЭК в картельном сговоре с крупными разработчиками и интеграторами, которые диктуют свои условия и пытаются монополизировать рынок. Я с этим не могу согласиться, считая взаимодействие ФСТЭК с бизнесом примером государственно-частного партнерства, пусть и не без косяков.
  • Проект нового 17-й приказа появится к концу этого года, когда будут приняты поправки в ФЗ-149 и доработаны в связи с этим требования по защите информации. ФСТЭК обещает выложить проект приказа для всеобщего обсуждения.
  • Из под действия поправок в ФЗ-149 выведены госкорпорации - остались только организации, которые обрабатывают информацию, обладателем которой является государство. На них, а точнее на куски информационной системы, которые обрабатывают такую информацию. Это может быть и госкорпорация, выполняющая работы по госзаказу, и банки, подключившиеся к ГИС ГМП, и многие другие организации. Но на эти куски ИС будет распространяться новый 17-й приказ.
  • Учитывая предыдущий пункт, встает вопрос о способе подтверждения соответствия ИС требования 17-го приказа. Для госорганов (и, возможно, муниципалов) аттестация останется обязательной. Для остальных организаций вопрос с оценкой соответствия будет решаться. Хочу обратить внимание, что в случае принятия законопроекта (а сомневаться в этом не стоит - он разработан во исполнение распоряжения Президента), спектр ИС в госорганах, попадающих под аттестацию расширится. Если раньше это требование многие заказчики распространяли только на ГИС, а вопрос с классификацией ГИС всегда вызывал вопросы, то сейчас совершенно неважно, есть у вас ГИС или нет; достаточно наличия информации, обладателем которой является государство, а у госов - это почти любая система.
  • В новом ФЗ-149 будет установлена обязанность уведомлять ФСТЭК и ФСБ об инцидентах. На эту тему будет принят отдельный НПА, согласованный с двумя регуляторами. Но опять хочу обратить внимание, что данное требование об уведомлении распространяться будет не на организации различных видов собственности, а на вид информации, которая обрабатывается в информационной системе. Произошел, например, у банка инцидент в месте сопряжения с ГИС ГМП, и все, надо уведомлять. На мероприятии была упомянута ГосСОПКА, как тот инструмент, который будет принимать такие уведомления, но прозвучало не очень конкретно - думаю, ясности еще по этому вопросу нет.
  • Когда я описывал промежуточный проект 17-го приказа, я уже упоминал, что пентесты включили в список аттестационных мероприятий со всеми вытекающими отсюда последствиями. На конференции прозвучало, что ФСТЭК решила исключить пентесты из этого вида деятельности. По крайней мере на текущий момент, пока не разработаны соответствующие методические и нормативные документы. Однако по-прежнему пентесты относятся к такому виду деятельности как контроль защищенности.
  • ФСТЭК переходит на новую классификацию сертифицированных средств защиты (6-4 классы для конфиденциалки и 3-1 - для гостайны). Отсюда изменения и в соотнесении этих классов защиты с классами защищенности ГИС и АСУ ТП и уровнями защищенности ИСПДн. В 17-й приказ такие изменения будут внесены в самое ближайшее время, а в 21/31 приказы такие изменения не за горами. Соответственно средства защиты 6-го класса можно будет применять в ГИС и АСУ ТП 3-го класса и в ИСПДн 3-4-го уровней защищенности; средства защиты 5-го класса - в ГИС, АСУ ТП и ИСПДн 2-го класса/уровня, а средства защиты 4-го класса - в ГИС, АСУ ТП и ИСПДн 1-го класса/уровня.

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

ЗЫ. Выступал я с презентацией по CSDL.

10.02.2017

Применение концепции "Окна Джохари" в ИБ (видео)

3 месяца назад я написал заметку про "Окно Джохари" и применение этой концепции в области информационной безопасности. Спустя месяц была презентация на эту тему, а в предваряющей ее заметку я написал, что мы планировали в Cisco провести мероприятие, посвященное этой теме, более полно раскрывающей вопросы обнаружения как простых и известных атак, так и сложных и неизвестных. Мы провели эту конференцию в Москве 26-го января (материалы можно посмотреть тут - чуть выше на странице), на которой, благодаря BIS-TV, было записано на видео два больших обзорных доклада (без рекламы). Один был посвящен тактикам, техникам и процедурам, применяемым злоумышленниками, а второй как раз рассказывал о концепции "Окна Джохари" в ИБ. Ниже вы и увидите эту презентацию:


09.02.2017

Cyber Security Forum: КИИ и ПДн в моем фокусе

Если вы ждали сегодня обзора вчерашней конференции ФСТЭК, то вы ошиблись - сегодня будет обзор позавчерашнего Cyber Security Forum, на котором мне довелось выступить в секции про "Эпоху 4.0", а также помодерировать секцию по персональным данным. Вообще это мероприятие у меня всегда вызывает определенный диссонанс. В его названии встречается слово "кибербезопасность", но вот про классическую кибербезопасность на мероприятии практически ничего нет (за редкими вкраплениями). CSF посвящен тому, что на Западе вкладывают в термины "Governance" и "Policy", то есть обсуждению государственных, окологосударственных, юридических вопросов. Большое внимание уделяется вопросам защиты детей, контентной безопасности и блокировкам в сети Интернет, культуре и т.п. Отсюда совершенно иная аудитория, отсутствующая на "наших" привычных поибшных тусовках.


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



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

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

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

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

08.02.2017

Моя презентация с конференции ФСТЭК по CSDL

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


Проблемы безопасной разработки и поддержки импортных средств защиты информации from Aleksey Lukatskiy

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

03.02.2017

ФСТЭК установила требования к SOCам и пентестерами. Нет слов :-(

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

Чтобы мне хотелось отметить и на что обратить внимание:
  1. Теперь я не понимаю, куда относятся пентесты. Я считал, что это контроль защищенности информации от несанкционированного доступа. Но последние поправки в 17-й приказ отнесли пентесты к одному из виду аттестационных испытаний, что коренным образом меняет требования к тем, кто занимается таким видом деятельности (в сторону усиления требований). По утвержденному перечню это минимум пункт "г.1", а в случае применения Red Team - "г.2" или "г.3". Вперед, к получению селективных вольтметров, вибродатчиков, осциллографов и рефлектометров. Хорошо, если это будет просто пункт "б", но упоминание в пп.18-22 пункта "г.1" говорит, что пентест может вполне рассматриваться одним из видов аттестаций со всеми вытекающими отсюда последствиями, упомянутыми выше.
  2. От SOC зачем-то требуется наличие сертифицированных WAF, МСЭ, антивируса и IDS. Сертификат не ниже 4-го класса, то есть максимально возможный не для гостайны. Честно говоря я не понимаю этого требования. Зачем SOCу эти средства защиты? Для предоставления услуг? Ну так обычно SOC мониторит средства защиты заказчика. Для собственной защиты? И в этом случае это странный набор. 
  3. SOCу требуется обязательно "песочница" и платформа Threat Intelligence. Требований к ним пока нет и по каким критериям орган лицензирования будет оценивать выполнение этого требования не совсем понятно. Стоит учесть, что в России число своих песочниц можно пересчитать по пальцам одной руки и они рынку практически неизвестны, а уж опыта работы с ними нет ни у кого. По моему опыту почти все отечественные SOC используют "песочницы" зарубежные, а это в свою очередь заставляет задуматься над соотнесением новых требований с требованиями о локализации техсредств ГИС и ПДн россиян на территории России.
  4. SIEM должна быть и должна иметь сертификат ФСТЭК. Требований пока еще нет, но ТУ никто не отменял. Но НДВ4 вынь да положь. А вы много помните таких SIEM? Я вот в последнем списке сертифицированных СрЗИ ФСТЭК нашел только ArcSight  и все. Даже "КОМРАД"а там нет. Предоставит ли тот же Splunk свои исходники - большой вопрос. И о какой конкуренции тут может идти речь? Скорее о ее искусственном ограничении.
  5. Каналы передачи данных от SOC до контролируемой системы должны быть защищены средствами шифрования, имеющими сертификат ФСБ. Требование вполне реализуемое, но денег потребуется дофига. Особенно в тех случаях, когда у разных заказчиков SOC разные VPN-решения используются - SOCу тогда придется строить шлюз из стека шифраторов разных производителей. Либо заставить всех заказчиков ставить на связь с SOC одно и тоже VPN-решение. Второй вариант менее вероятен, а первый сложен с практической точки зрения (да и с финансовой). Например, многие организации не используют сертифицированные в ФСБ СКЗИ. И как им быть, если они хотят подключиться к SOC? Покупать еще и VPN?
  6. Информационная система SOC не только должна располагаться по адресу, указанному в лицензии (что сильно осложняет жизнь компаниям, использующим концепцию виртуальных SOCов), но и выполнять требования к ГИС 1-го класса. Это еще одно требование, которое непонятно зачем установлено. С одной стороны, если мы мониторим ГИС 1-го класса, то в SOC может попадать информация соответствующего уровня и SOC должен быть того же уровня защищенности. Но что делать, если SOC хочет мониторить только ГИС 2-го класса? Или ИСПДн 3-го класса? Или вообще не планирует мониторить классифицированные ИС? Зачем тогда выполнять требования, максимально возможные в современной России? А тут еще и непонятная ситуация с аттестацией SOC. Если он должен выполнять требования к ГИС, то может быть нужна и аттестация? Или SOC, не являющийся ГИС, не должен получать аттестат? Одни вопросы.
Коллеги пишут, что требования адекватные и были согласованы со всеми основными поставщиками услуг SOC в России во время совещания в ФСТЭК. Ну что сказать? Либо поставщики согласились со всем, не вдумываясь, либо надеются все это выполнить, либо... А фиг его знает. Я не знаю, как можно было соглашаться на такое?..

ЗЫ. Про западных поставщиков услуг SOC, которые в России уже предоставляют свои услуги, видимо все забыли (возможно, сознательно). Но выполнить указанные требования они будут не в состоянии, что закроет им еще и этот сегмент рынка.

31.01.2017

Чего не хватает 17-му приказу?

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

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


Во-вторых, сейчас активно, внедряется Интернет вещей, который подразумевает обмен информацией между устройствами, преимущественно консьюмерскими, – интеллектуальные часы, очки, кофеварки и т.п. Они и к офисной беспроводной сети могут подключаться, включаясь тем самым в контролируемую зону. Запретить это сложно, значит нужно контролировать и регламентировать. И если в традиционных ГИС таких устройств может быть и немного, учитывая неразвитость Wi-Fi в ГИС, то в коммерческих структурах, которые после принятия поправок в ФЗ-149 могут попасть под действие 17-го приказа, таких устройств немало и их число будет расти.

В-третьих, в сети могут быть и мобильные устройства, к которым, по крайней мере на текущем этапе, необходимо применять немного отличные требования по защите. Например, многие мобильные устройства подразумевает всего лишь 4-хзначный PIN-код, а не 6-ти-8мисимвольный пароль.

Идем дальше. Сейчас документ статичен – он прописывает набор защитных мер, которые государственное или муниципальное учреждение обязано применить при построении системы защиты. Однако такая статичность в современном динамичном окружении уже не позволяет решать многие задачи ИБ. Например, возьмем пользователя Иванова, который получает доступ к защищаемым ресурсам с ноутбука. Казалось бы сценарий один… но нет, сценариев такого доступа может быть очень много:
  • Пользователь Иванов подключился к защищаемым ресурсам с личного ноутбука
  • Пользователь Иванов подключился к защищаемым ресурсам со служебного ноутбука
  • Пользователь Иванов подключился к защищаемым ресурсам изнутри ведомства
  • Пользователь Иванов подключился к защищаемым ресурсам удаленно, через Интернет
  • Пользователь Иванов подключился к защищаемым ресурсам по Wi-Fi
  • Пользователь Иванов подключился к защищаемым ресурсам по проводному соединению
  • Пользователь Иванов подключился к защищаемым ресурсам в рабочее время
  • Пользователь Иванов подключился к защищаемым ресурсам в нерабочее время.
И в каждом из этих случаев (а они могут еще и комбинироваться между собой) меры защиты могут и должны быть разными. Например, подключение извне и подключение изнутри требуют разных мер, подключение с личного и служебного ноутбука требуют разных мер, подключение в рабочее и нерабочее время требуют разных мер. Иными словами, реализация защитных мер должна зависеть от контекста. Под контекстом я понимаю не только ответ на вопрос «ЧТО можно», т.е. анализ трафика на сетевом и прикладном уровне, но и ответы на вопрос «КОГДА можно» (привязка ко времени попытки доступа), «КУДА и ОТКУДА можно» (куда и откуда осуществляется доступ), «КОМУ можно» (привязка не только к IP-адресу, но и к учетной записи пользователя), «КАК можно» (с какого устройства можно осуществлять доступ – с личного или с корпоративного, со стационарного или с мобильного). Все это позволяет более гибко выстраивать политики доступа и учитывать постоянно изменяющиеся потребности современного предприятия с точки зрения информационной безопасности. И если еще несколько лет назад такая тема была не столь актуальна для госорганов, то сегодня многим государевым структурам без этого не обойтись.


Ввиду активного перехода на облачные среды и аутсорсинг по тексту лучше заменить упоминаемого «оператора» на «оператора и уполномоченное лицо, которое может обеспечивать защиту ИС». Также как и лучше заменить заменить по тексту упоминаемого «пользователя» на «субъекта доступа», т.к. контролировать надо в современных информационных системах не только пользователя, но и приложения, процессы, узлы, компоненты ИС, т.е. всех субъектов доступа.

Еще в новый 17-й приказ я бы добавил ряд защитных мер из проекта новой версии NIST Cyber Security Framework v1.1, которая как раз сейчас рассматривается в NIST. 17-й приказ и с первой версией не целиком коррелировался, а уж с новой тем более. Например, в условиях постоянных новостей о закладках со стороны китайских производителей и роста рисков вмешательства в оборудование в процессе его доставки потребителю, в CSF v1.1 был добавлен большой раздел по управлению ИБ в рамках управления цепочками поставок - требования к взаимоотношению с вендорамами, требования к процессу закупки ПО и железа и т.п. В условиях импортозапрещения в России эта тема даже гораздо более важная, чем в других странах мира. Ее стоило бы очертить хотя бы крупными мазками в новой версии 17-го приказа.

Перечень блоков защитных мер по CSF v.1.1 (красным показаны обновления в v1.1)
В новую версию CSF добавили абсолютно новый раздел по измерению ИБ, демонстрирующий важность ИБ для руководство организации, а также текущий уровень ИБ и его динамику. Я уже писал (а также тут, тут и тут) в прошлом году про то, как можно было бы улучшить 17-й приказ в этой части - повторять не имеет смысла. Если с точки зрения использования этого подхода самим регулятором или органом по аттестации может быть говорить еще и рано, то дать такой инструмент потребителю для самооценки было бы полезно. Когда-то же надо внедрять мысль о том, что измерять уровень своей защищенности можно и нужно (и это не так уж и сложно). Если уж ФСТЭК постепенно переходит на концепцию непрерывного мониторинга защищенности, то почему бы не пойти в сторону измерения этой защищенности?..

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

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

30.01.2017

Законопроект по штрафам в области ПДн. Что нас ждет в скором будущем?

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

Я попробую сформулировать тезисно ключевые моменты, связанные с новыми правилами:

  • Этот законопроект был внесен в Госдуму еще в декабре 2014-го года, а в феврале 2015-го года он был принят в первом чтении. С тех пор этот законопроект был забыт депутатами и с него сдули пыль только сейчас. За это время ситуация в законодательстве изменилась, но... законопроект почти не трогали. Например, 7-я часть статьи 13.11 наказывает за невыполнение госорганом или муниципальным учреждением обязанности по обезличиванию ПДн. Все бы ничего, но норма по обязательному обезличиванию была в прошлой версии ПП-211 - в сентябре 2014-го года ее отменили, определив, что обязанность обезличивания устанавливается какими-либо НПА. Но за прошедшие пару лет таких актов, насколько мне известно, так и не было принято. Получается, что депутаты вводят наказание за то, что делать уже не требуется, то есть данная часть статьи 13.11 работать не будет.
  • Также мне не совсем понятно, почему было убрано наказание за обработку без согласия спецкатегорий ПДн (за нее следовал максимальный штраф в 300 тысяч рублей); депутаты оставили наказание за обработку без согласия любых ПДн (и обычных и спецкатегорий)? Это совсем нелогично. В Европе, например, и дух и буква Евроконвенции и Евродирективы гласят, что к обработке спецкатегорий ПДн надо относиться с большим пиететом, чем к обработке обычных ПДн. И наказание за незаконную обработку таких ПДн существенно серьезнее. Но не в России. У нас и уровни защищенности, установленные ПП-1119, почти никак не зависят от типа ПДн (в отличие от прежнего "приказа трех" по классификации ИСПДн), и наказание за незаконную обработку спецкатегорий ПДн убрали. С другой стороны это лишний раз доказывает давно известный факт, что регулятор давно уже не интересуется защитой прав субъектов ПДн, занимаясь совсем другими задачами.
  • Законопроект устанавливает 7 вполне конкретных составов правонарушений, за которые воспоследует административное наказание. В отличие от прошлой и пока еще действующей редакции ст.13.11, теперь четко установлены случаи, за которые можно наказать оператора ПДн - никакой отсебятины и никакого размытого "нарушения правил обработки ПДн". Все предельно понятно. Например, раньше по ст.13.11 можно было наказать за нарушение ФЗ-242; сейчас уже этого сделать будет нельзя. За отсутствие уведомления РКН тоже можно было наказать - сейчас проблематично. Ну и т.д.
  • Многие комментаторы радостно говорят, что законопроект ничего не поменяет в деле защиты прав субъектов, так как сумма штрафов выросла незначительно и она не будет стимулировать операторов ПДн. Не соглашусь. Сумма штрафов не выросла, но вот схема их назначения изменилась кардинально. Раньше (еще пока в действующей редакции) наказание могло быть одно и за "нарушение установленного законом порядка...". То есть сколько бы нарушений найдено не было, наказать можно было только один раз. Сейчас формулировка статьи поменялась и она просто перечисляет 7 составов правонарушений. Вспоминая практику применения ст.5.27 (нарушение законодательства о труде), когда за каждое нарушение инспекторы трудовых инспекций назначали отдельный штраф, можно предположить, что схожая практика может быть применена и к новой статье 13.11. Именно может быть. С другой стороны ст.4.4 КоАП определяет, что может быть и другой вариант, когда в рамках одного дела, ведомого одним судьей, наказание по совокупности правонарушений рассчитывается не за каждое нарушение, а как одно. Анализ правоприменительной практики показывает, что такие случаи происходят нередко. Поэтому стоит подождать принятия закона и начала надзорной деятельности.
  • За ущерб субъекту по-прежнему не наказывают - только 6-я часть новой редакции ст.13.11 (неавтоматизированная обработка ПДн) предусматривает такой состав. В свое время в экспертном совете при Минкомсвязи мы рассматривали такой законопроект (о наказании именно за ущерб субъекту), но РКН был против и его "похоронили".
  • Права наказывать по статье 13.11 перешло от прокуратуры к РКН.
27-го января должны были рассматривать и второй законопроект - по надзору в области ПДн, но, видимо, депутаты не успели этого сделать. В нем тоже произошло немало интересного, о чем уже писал Михаил Емельянников.

24.01.2017

Новые требования по ИБ для финансовых организаций

А продолжу-ка я обзор последних изменений нормативных актов по ИБ, но в этот раз коснусь финансовой сферы. Она, наряду с госорганами, у нас наиболее заурегулирована и все равно на месте не стоит. Собственно, как и во всем мире. В конце прошлого года требования по ИБ разработала SWIFT, а "Минфин" штата Нью-Йорк разработал проект своих требований по безопасности финансовых организаций (вступят в силу с 1-го марта 2017-го года). Что же у нас появилось или появится в обозримом будущем и о чем можно будет поговорить/узнать на Магнитогорском форуме, до которого осталось меньше месяца. Вкратце (я все еще надеюсь посвятить каждому из НПА по отдельной заметке) у нас появилось вот что:
  • Положение Банка России от 24 августа 2016-го года №552-П "О требованиях к защите информации в платежной системе Банка России" (или как его еще называют требования по защите АРМ КБР). Нельзя сказать, что раньше защита АРМ КБР не осуществлялась, - ведь об угрозах для этой системы ЦБ предупреждал давно. Например, в письме ЦБ №51-Т "О форме договора об обмене электронными сообщениями при переводе денежных средств в рамках платежной системы Банка России, заключаемого между Банком России и клиентом Банка России" было целое приложение по защите информации. Но за 4 года ситуация немного поменялась, да и сила такого договора межжду банком и ЦБ не сравнима с Положением Банка России. За его нарушение наказывать легче :-) Кстати, требование хранить 3 года видео - это, на самом деле, не так уж и серьезно. Стоимость такого решения не слишком высока и измеряется несколькими тысячами долларов.
  • А вот рекомендация Банка России перенести формирование кодов аутентификации и защитных кодов в АБС может иметь более серьезные последствия. Такое встраивание СКЗИ на мой взгляд потребует от разработчиков не только соответствующей лицензии ФСБ, но и, возможно, согласования ТЗ на данную работу, что в текущих условиях 8-го Центра может быть не очень простой задачей.
  • В конце прошлого года ЦБ принял новый СТО 1.3, посвященный сбору доказательств в рамках процесса реагирования на инциденты. Это, пожалуй, один из первых документов в комплексе стандартизации по ИБ Банка России, который опускается на такой уровень детализации, влоть до указания конкретных программных продуктов, облегчающих сбор доказательств в оперативной памяти, на ПК или в сетевом трафике.
  • В декабре также был согласован проект ГОСТа "Базовый состав организационных и технических мер защиты информации", который в скором времени станет обязательным для финансовых организаций и именно на наего будут ссылаться иные документы ЦБ. Правда, по этому стандарту у меня сейчас возникают вопросы. Планировалось, что все технические меры защиты уйдут из 382-П и других Положений Банка России и они просто будут ссылаться на новый ГОСТ. Но новый стандарт содержит далеко не все (от слова "совсем") технические требования из 382-П. Поэтому я пока не могу для себя понять, что же появится в итоге. То ли положения ЦБ оставят за собой набор защитных мероприятий, то ли помимо упомянутого проекта ГОСТа будут и другие национальные стандарты.
  • Поскольку в России ЦБ запустил аналог SWIFT - систему передачи финансовых сообщений, то логично было бы узнать, какие защитные меры приняты для СПФС. ЦБ считает, что риски для СПФС и для платежной системы Банка России идентичны и поэтому для обеспечения их безопасности применяется схожая идеология. Защитные меры перечислены в договоре об оказании услуг по передаче финансовых сообщений, утвержденном письмом ЦБ от 10 декабря 2015 г. № 017-45-4/10550. Думаю, что через какое-то время можно ожидать и отдельного положения Банка России под эту тему (по аналогии с 552-П).
  • А еще ЦБ подготовил проект своего нового Указания “О требованиях к операторам услуг платежной инфраструктуры, привлекаемым Банком России, о порядке привлечения Банком России операторов услуг платежной инфраструктуры и ведения перечня операторов услуг платежной инфраструктуры, привлеченных Банком России”. В главе 4, целиком посвященной защите информации, всего 3 пункта, но они важны. Согласно им ОУПИ, являющийся резидентом РФ, должен иметь оценку соответствия 382-П на уровне "хорошая" (4-й уровень), а ОУПИ - не резидент РФ должен соответствовать уровню Level 1 стандарта PCI DSS или быть сертифицированным на соответствие ISO 27001.
Но это еще не все. Не стоит думать, что это все хаотические попытки понавыпускать какие-то документы по ИБ, имитирующую бурную деятельность, но не имеющие никакой конкретной цели. Это совершенно не так. Есть План мероприятий (дорожная карта) на 2016 год по реализации Основных направлений развития финансового рынка Российской Федерации на период 2016–2018 годов, которые описывают видение ЦБ отечественной финансовой отрасли на 3 года. Согласно этому плану по нашему направлению ЦБ должен:
  • провести анализ возможности и целесообразности использования финансовыми организациями аутсорсинга отдельных элементов деятельности и подготовить соответствующих предложений - 2-е полугодие 2017-го года
  • подготовить предложения по совершенствованию законодательства Российской Федерации в части наделения Банка России полномочиями по регулированию и контролю обеспечения информационной безопасности в финансовых организациях - 2-е полугодие 2017-го года
  • участвовать в разработке проекта федерального закона, направленного на формирование правовой основы противодействия мошенничеству на финансовом рынке - 2-е полугодие 2017-го года
  • разработать проекты национальных стандартов информационной безопасности - 2-е полугодие 2017-го года
  • провести консультации с ФСТЭК России о создании системы сертификации и аттестации для цели контроля исполнения финансовыми организациями требований национальных стандартов информационной безопасности и технических требований к защите информации, установленных в правилах платежной системы Банка России для участников платежной системы - 2-е полугодие 2017-го года
  • подготовить необходимые материалы и проекты документов для создания системы сертификации и аттестации для контроля исполнения финансовыми организациями требований национальных стандартов информационной безопасности и технических требований к защите информации, установленных в правилах платежной системы Банка России для участников платежной системы - 2-е полугодие 2017-го года
  • провести консультации с представителями финансовых организаций для определения состава и содержания дополнительных организационных и технических механизмов защиты автоматизированного рабочего места «Клиент Банка России», применяемого для взаимодействия финансовых организаций – участников платежной системы с платежной системой Банка России - 2-е полугодие 2017-го года
  • разработать регламенты взаимодействия по вопросам противодействия киберпреступности между Банком России и не являющимися поднадзорными и под- контрольными Банку России организациями и заинтересованными в повышении уровня информационной безопасности финансовой системы и национальной платежной системы Российской Федерации - 2-е полугодие 2017-го года
  • разработать функционально-технические требования на автоматизированную систему противодействия мошенническим платежам в платежной системе Банка России - 2-е полугодие 2017-го года
  • подготовить предложения по созданию и совершенствованию направлений подготовки специалистов внутреннего аудита, стратегического планирования, управления активами и финансового консультирования, обеспечения кибербезопасности и корпоративного управления - 4 квартал 2018 года. Я про это уже писал в июне прошлого года.
  • разработать Указание Банка России «О внесении изменений в Положение Банка России от 9 июня 2012 года No 382-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств» - 2 квартал 2017-го года
  • разработать Положение Банка России о правилах обеспечения безопасности и требованиях к защите информации в платеж- ной системе Банка России (для участников платежной системы Банка России). И это не 552-П - этот документ нужен для перспективной платежной системы ЦБ.
Вот такая картина вырисовывается. Этот год будет насыщенным, да и последующие тоже не дадут почивать на лаврах и спокойно заниматься борьбой с киберпреступниками. Регулятор не дремлет и будет радовать (а кого-то и огорчать) своими нормативными документами.

ЗЫ. У кого данный план регулятора вызывает вопросы, рекомендую посетить Магнитогорский форум - в этом году там будет высажен целый десант от Банка России - около 30 человек, причем самого высокого уровня. Кто, как не они, знают, что скрывается за краткими формулировками дорожной карты?..

ЗЗЫ. Хочу заметить, что утвержденные планы подготовки в России принято соблюдать, так как в противном случае чиновников не поглалят по головке. Поэтому все, что написано выше будет сделано в указанные сроки, но... хочу обратить внимание, что обычно в планах наших ведомств указывают не срок окончания работ по задаче, а срок ее начала. Например, написано, что во втором полугодии будут ГОСТы. Это не значит, что их до июля примут. Это значит, что их до июля разработают и прелставят общественности или утвердят. Потом начнется процедура согласований (если надо), общественных обсуждений, регистрации в Минюсте или в Ростехрегулировании. Поэтому не стоит питать иллюзий относительно скорого выхода указанных выше документов; обычно к этим срокам надо добавлять от 3 до 12 месяцев (а для законопроектов и того больше).

23.01.2017

Промежуточная версия нового 17-го приказа

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

Надо сразу отметить, что это не тот документ, которого ждали многие. Это промежуточная версия, задача которой закрыть ряд стоящих перед ФСТЭК вопросов, которые не касаются непосредственно состава и содержания защитных мер. Вот именно последнего многие ждут и именно последнее отложено на неопределенный срок, связанный с принятием поправок в ФЗ-149. Как только эти поправки примут, тогда, спустя некоторое время, и выйдет серьезно обновленная редакция 17-го приказа. А пока посмотрим, что нам подготовил регулятор в текущем проекте помимо косметических и терминологических правок:
  • Перешли на давно обещанные 3 класса защищенности ГИС. 4-й класс, который и раньше был достаточно вырожденным, убран совсем. В приложении 2 также убран столбец с мерами для соответствующего класса. Насколько я обратил внимание, никаких изменений в составе базовых мер для 1-3-х классов не произошло.
  • Переход на 3 класса автоматически облегчил их соотнесение с классами защиты средств защиты, на которые переходит ФСТЭК в своих документах по системам обнаружения вторжений, МСЭ, антивирусам, ОС, СУБД и т.п. Теперь логика простая - 6-й класс защиты применяется в ГИС 3-го класса, 5-й класс - в ГИС 2-го класса и 4-й класс в ГИС 1-го класса (средства защиты 1-3 классов применяются для защиты гостайны). Что делать со старыми, но еще действующими сертификатами, и как они будут соотноситься с новыми классами ГИС не совсем понятно. А ведь старых сертификатов немало - некоторые вендора аккурат перед 1-м декабря продлили сертификаты на свои МСЭ до 2019-го года. И как быть потребителю? В принципе в проекте есть решение в виде фразы "При этом функции безопасности таких средств должны обеспечивать выполнение настоящих Требований" (это касается сертификации по ТУ/ЗБ). Но это и в прошлые разы вызывало вопросы - как определить соответствие функций безопасности требованиям класса защищенности ГИС? Писать в ФСТЭК?
  • Появились новые виды аттестационных испытаний, что не может не радовать. Что огорчает - по ним нет никаких методических документов ФСТЭК или ГОСТов. А ведь в 17-м приказе написано, что при проведении аттестации надо ими руководствоваться, а их нет :-( Пентесты теперь обязательны для ГИС 1-го и 2-го классов защищенности - проводить их можно своими силами или с привлечением лицензиатов ФСТЭК (с июня, как я уже писал, для лицензиатов вступают новые правила игры).
  • Усилили связь требований по защите с банком данных угроз и уязвимостей ФСТЭК (при моделировании угроз и анализе уязвимостей).
  • Запретили проведение аттестации тем же лицом, что и проектирует/внедряет систему защиты. С одной стороны это логично, а с другой - заказчикам, которые привыкли заключать один договор с генподрядчиком, который уже сам искал исполнителей на проектирование, внедрение и аттестацию, придется пересмотреть свою практику. Или писать письма в ФСТЭК с просьбой разрешить такие договора.
  • Зачем-то включили пункт, что срок действия аттестата не может превышать 5 лет. Ну так вроде он по требованиям ФСТЭК выдается сроком на 3 года, то есть и так меньше 5-ти лет. Непонятно.
  • Учли переход на общую систему ЦОДов и "Гособлако" в части аттестации.
  • Синхронизировали требования по защите информации ГИС, включаемой в ТЗ на ее создание, с требованиями ПП-676, упомянутого выше.
  • Убрали ссылку на ГОСТ 27001. Применительно к госорганам я бы это поддержал - не готовы они еще к процессному подходу в области ИБ; особенно в условиях не самого лучшего бюджетирования.
Вот так выглядят изменения в 17-й приказ, которые должны будут приняты в самое ближайшее время. В целом же можно говорить об усилении контроля за деятельностью по защите информации в госорганах и организациях, обрабатывающих информацию, обладателем которой  являются госорганы. Я попробовал набросать картинку тех изменений, которые происходят сейчас, происходили в самом недалеком будущем или будут происходить в самое ближайшее время. И вот что получилось:


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

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

20.01.2017

Чего не хватает российской нормативке или почему одна картинка говорит больше тысячи слов?

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

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

Приведу несколько фактов:
  • Изображения обрабатываются в 60 000 раз быстрее текста
  • 80% людей охотнее читают текст, который сопровождается изображениями
  • В тексте читается всего 28% слов и всего 20% прочитанного остается в памяти
  • Согласно теории Саноки-Сульмана люди лучше запоминают палитры, содержащие сочетание только трех или менее цветов, чем те, в которых четыре и более цвета, а также цветовое различие между контекстом и фоном может повысить нашу способность концентрироваться на контексте. То есть черный текст на белом фоне воспринимается гораздо лучше такого же текста еще и с красным заголовком. А еще эта теория объясняют, почему большинство презентаций регуляторов такое унылое гуано - их авторы почему-то считают, что если использовать для заголовков, текста, подписей на  слайде разные кислотные цвета, то так лучше будет восприниматься.
  • Феномен бинокулярного соперничества глаз требует от нас для нормального восприятия не перегружать страницу/слайд (именно поэтому "стена текста" не читается), выделять ключевые моменты, а также использовать тематические иконки.
  • Используемый шрифт влияет на восприятие контента и на принятие решений по результатам его чтения. Поэтому рекомендуется использовать удобочитаемые шрифты, отделять текст от изображений, не накладывать изображения на текст и оставлять достаточно свободного пространства между абзацами.
  • Согласно теории Кастелано-Хендерсона восприятие контента улучшают подходящие иконки или картинки для представления данных, расположенный в правильной последовательности контент (списки и таблицы), а также использование привычных цветов для важных объектов.
Ну а дальше будет несколько примеров, по которым вы, сами для себя, может судить о том, насколько легко или тяжело воспринимать представленную информацию (возможно у меня глаз уже замылен и я привык к нашим НПА по ИБ, но российские документы бросаются в глаза мгновенно):
PCI DSS v3.0
ITU-T E.409 по реагированию на инциденты для организаций электросвязи 
Финнский стандарт по критериям аудита ИБ (KATAKRI)
Канадский "ФЗ-152" (PIPEDA) 
Французский стандарт по анализу рисков  (MEHARI)
ISF SoGP
NIST SP800-53

Указание Банка России по угрозам ПДн
FFIEC IT Examination Handbook
Приказ №17 ФСТЭК
Приказ №470 Минэкономразвития 
Приказ ФСТЭК по КСИИ
СТО БР ИББС 1.3 по сбору доказательств
Проект ГОСТ с базовым набором защитных мер для финансовых организаций
Концепция по ГосСОПКЕ
Приказ №378 ФСБ
NIST CSF v1.0
Стандарт Катара по безопасности критических инфраструктур
Понятно, что рекомендация будет простой - учитывать особенности восприятия информации при оформлении документов. Для этого можно либо ориентироваться на мировой опыт (благо его полно) и попробовать сделать самостоятельно, не забыв проверимость на "читаемость" на коллегах, либо нанять дизайнера в штат (или найти любителя дизайнов и макетов среди сотрудников), либо заплатить (что, конечно, врядли) агентствам, специализирующимся на таких вопросах.

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

19.01.2017

Новые требования по кибербезопасности SWIFT

В собственный Топ 5 международных событий по ИБ прошлого года на последнее место я включил атаки на SWIFT, систему, которая раньше не часто попадала в прицел злоумышленников. И вот в конце прошлого года, в рамках программы Customer Security Programme (CSP), SWIFT выпустила документ под названием "SWIFT Customer Security Framework. Supplementary Guide", который устанавливает набор обязательных и рекомендательных защитных мер для клиентов SWIFT. Первые (обязательные) меры являются основой для защиты информации, передаваемой в рамках SWIFT (это некий аналог базового набора мер в 17-м приказе или набора защитных мероприятий в проекте нового ГОСТа Банка России), а вторые описывают лучшие практики, повышающие уровень защищенности.

Новые требования распространяются на 4 компонента:

  • уровень обмена данными
  • локальную инфраструктуру SWIFT заказчика
  • пользовательские ПК
  • пользователей.

Соединение с SWIFT, ИТ-инфраструктура и бэкофис заказчика в область действия SWIFT CSF не попадают:


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



Для каждой из 4-х архитектур описаны требования по безопасности, которые, как я уже написал выше, делятся на обязательные и рекомендательные. Документ получился достаточно объемным - 52 страницы, содержание которого показано ниже. Приставка A после номера требования (например, 7.3А - пентесты, 6.5А - обнаружение атак, 2.7А - сканирование уязвимостей) означает рекомендательность требования (от слова "Advisory").


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


Несмотря на объем, все требования нового документа можно увязать с всего тремя целями:

  • защити свое окружение
  • знай и ограничь доступ
  • обнаруживай и реагируй.


Во втором квартале 2017-го года заказчики SWIFT начнут сообщать в SWIFT о своем соответствии данным требованиям (в обязательной их части), а с января 2018-го года это станет обязательной нормой - все заказчики должны будут проводить собственную оценку соответствия (SWIFT называет это знакомым словом "аттестация") и направлять ее результаты на ежегодной основе. Дополнительно SWIFT планирует случайным образом ежегодно выбирать некоторых заказчиков для проведения более глубокого их аудита внутренними или внешними аудиторами. Данное требование напоминает шаги нашего Банка России, который требует отправлять результаты оценки соответствия 202-й формы, а при необходимости проводит дополнительные надзорные мероприятия в отношении выбранных банков.

Статус соответствия требованиям будет размещаться в публичном реестре (SWIFT KYC Registry), чтобы каждый смог убедиться в надежности своих партнеров и контрагентов. По сути, это идея, которую не довел до финального завершения Банк России, который собирал результаты оценки соответствия СТО БР ИББС и хотел их публиковать на сайте. Сейчас же все ограничилось тем, что ЦБ публикует список тех, кто присоединился к СТО, без указания их уровня соответствия. Я не знаю, насколько это повышает стимулирует заказчиков выбирать более защищенные финансовые организации, но инициатива SWIFT интересная - посмотрим, что из нее получится.

Могу отметить, что документ не содержит каких-то новых требований, неизвестных заказчикам SWIFT, и ранее им невстречавшихся в других нормативных документах (том же PCI DSS или NIST CSF). Поэтому для облегчения внедрения SWIFT Customer Security Framework в конце документа содержит таблицу соответствия своих требований наиболее известным лучшим мировым практикам:


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

18.01.2017

Корпоративные тренинги по ИБ набирают популярность

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

Мне в прошлом году довелось участвовать в целом ряде таких тренингов, посвященных следующим темам:
  • Законодательство по ИБ для банков
  • Управление ИБ
  • Как выстроить внутренний маркетинг ИБ?
  • Безопасность ГИС
  • Бизнес-модели в деятельности служб ИБ
  • Человеческий фактор в деятельности служб ИБ
  • Обзор подходов к Threat Intelligence
  • Персональные данные
  • Построение программы повышения осведомленности персонала
  • Разработка бизнес-кейса по ИБ
  • Как понять бизнес-приоритеты компании?
  • Как обосновать ИБ для руководства компании?
  • Управление инцидентами
  • Архитектура и стратегия ИБ
  • Теория организации в ИБ
  • Измерение ИБ
  • Моделирование угроз
  • Геймификация в ИБ
  • Выстраивание процесса борьбы с фишингом на предприятии.
От коллег я слышал про участие в тренингах по финансовой оценке ИБ, борьбе с утечками, моделированию угроз по методике Microsoft, анализу прикладного ПО с точки зрения ИБ, сбору цифровых доказательств и т.п.

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

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

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