Известная ассоциация ISACA объявила 3 марта о приобретении института CMMI, известного своим авторством и поддержкой модели зрелости CMMI (Capability Maturity Model Integration). Размер сделки не сообщается.
9.3.16
RSA Conference: развенчание мифа
Посетив на прошлой неделе RSA Conference я лишний раз убедился, что миф "за контент никто не будет платить" является ложным. В этом году было много людей; очень много людей. Я бы назвал это большой толпой. Цифр по количеству участников у меня нет, но по скромным моим оценкам участников было несколько тысяч. Да, это была юбилейная конференция. Да, это крупнейшее в мире мероприятие по ИБ. Да, США - крупнейший регион с точки зрения рынка ИБ и специалистов там больше любой другой страны (исключая, быть может, Китай). Но, извините, 2000 долларов за 5-тидневную конференцию, - это все равно много. Не месячная, конечно зарплата, но за 7-10 так уж точно. И при этом толпы народа.
Но я это объясняю очень просто - совершенно иная модель бизнеса организаторов. У нас (если не рассматривать InfoSecurity Russia, в которой конференция является приложением к выставке), конференции преследуют одну цель - получить деньги от спонсоров. Именно спонсоры платят за все и именно они являются целевой аудиторией организаторов. Слушатели вторичны и ни на что не влияют. На RSA Conference, да и на других мероприятиях (Gartner, BlackHat и т.п.) целевой аудиторией является слушатель - именно он платит за свое участие и именно он определяет, что он хочет услышать. И поэтому организатор подстраивается именно под слушателя, а не под спонсора.
На российских конференциях обычно выступления идут в один, максимум, в два, потока. Отчасти это сделано потому, что докладчиков от спонсоров ограниченное количество. Если включать в программу некоммерческих докладчиков, то либо это всплывет (и коммерческие докладчики начнут возмущаться), либо аудитория пойдет на докладчиков, которым не нужно рекламировать свои продукты и услуги. Коллизия, вытекающая из ориентации на спонсоров. На RSA Conference было... 30 параллельных потоков, посвященных своим темам:
Может сложиться впечатление, что спонсорские выступления лидируют, но это не так. Из 311 докладов (трехсот одиннадцати) только 20 было спонсорских - остальные вендор-независимые. Да, была завуалированная реклама, но она была ненапряжной и никогда (их тех докладов, что я слышал) про конкретные продукты. Краудсорсинговые темы выбирались путем голосования на сайте конференции (демократия в действии).
Кстати, о сайте. Тоже хороший пример грамотной организации онлайн-площадки для мероприятия. На нем задолго до начала мероприятия началось продвижения - заметки в блоге от разных экспертов, видео от участников, аннотации будущих докладов и т.п. Та идея, о которой я твержу различным организаторам наших мероприятий уже давно. С помощью сайта можно начать заранее заинтересовывать аудиторию, которая будет ориентироваться не только на программу, которая часто еще и публикуется всего за пару недель до мероприятия и участников не остается времени на принятие решения.
Но вернемся к самому мероприятию. Число параллельных потоков - не единственное разительное отличие RSAC от других конференций. Хотя наличие 30 потоков не гарантировало попадание на них. Да-да, несмотря на оплату 2000 долларов за конференцию, на поток можно было и не попасть из-за переполненности зала. Сами доклады длились по 50 минут. Не 15, не 20 и даже не 30 минут; целых 50. Этого достаточно, чтобы адекватно раскрыть тему, не пытаясь вложить кучу информации в небольшой временной тайм-слот.
Вот так обычно выглядела очередь на доклад (она доходила до 500 метров):
Чтобы не заблудиться среди хвостов очередей, на их окончаниях ставили персонал с вот такими табличками, которые двигались вместе с очередью.
Ну а уж если места не хватило, то картина была такая:
Еще одним отличием стало разнообразие форматов. У нас обычно все ограничивается схемой 1П (послушать) или 2П (послушать и посмотреть демо). На RSAC модель была 6П - послушать (обычные сессии), посмотреть демо, пощупать (можно было на IoT-потоке в отдельном зале поиграться с уязвимыми домашними Интернет-устройствами), потренироваться (было несколько лабораторных работ разного уровня - от построения стратегии ИБ предприятия и целого государства и заканчивая защитой промышленных сетей), поговорить (так называемые Peer2Peer-сессии, на которых до 25 человек за круглым столом обменивались мнениями и опытом по различным темам) и познакомиться (Dinner for 6, то есть ужин, где за столиками сидели по 6 человек, которые могли познакомиться и общаться).
Из других форматов донесения информации стоит отметить выступления в брифинг-центре (вот это была явная реклама, но уже в рамках выставки, о которой я напишу отдельно), песочницу (доклады по теме IoT и промышленной ИБ в виде подиума, вокруг которого собирались заинтересованные слушатели), тренинги (проводились SANS), семинары (были посвящены лидерству в ИБ и управлению рисками), форумы (велись отраслевыми ассоциациями - CSA, ISSA, CForum и т.п.) и телевидение RSAC TV.
Я смог побывать на разных вариантах сессий - все было организовано на высоком уровне. Но я не устаю отмечать качество контента. Работа программного комитета, над которым не довлели спонсоры, выше всяких похвал. У меня даже сложилось впечатление, что программа RSA Conference напоминает мини-MBA, где раскрываются ключевые и важнейшие темы, которые волнуют руководителей по ИБ - от выхода на уровень топ-менеджмента (этому было посвящено не менее пяти выступлений) до количественного измерения различных аспектов ИБ, от трендов в области угроз и ИБ до работы с персоналом. Из несколько десятков докладов, что я послушал, не было ни одного неполезного и из которого бы я не извлек что-то новое и интересное для себя. И, блин, как им удалось такое количество докладов сделать без рекламы?.. Не устаю удивляться :-) Кстати, нередко, когда выступающих было двое - тоже интересная форма подачи материала (у нас такое редко бывает).
Материалы были выложены заранее - и это тоже необычно. Хотя, если рассудить, то это было логично. При наличии 300 докладов и невозможности их посещения всех, стоило заранее ознакомиться с докладами, чтобы выбрать, на что идти. Это очень сильно помогло лично мне, когда я формировал свою программу посещения презентаций. Очень понравилось приложение конференции, но про него я напишу отдельную заметку (там есть, на что обратить внимание).
Русскоговорящих участников на конференции я не встречал или это были представители Лаборатории Касперского (они были большой делегацией) и местных компаний. Все-таки курс национальной валюты сыграл свою не самую лучшую роль. Даже при ранней регистрации надо было бы выложить 1600 долларов, что по нынешнему курсу составляет свыше 100 тысяч рублей. Поздняя регистрация обходилось уже в 2200 долларов, то есть 150 тысяч. Примерно в такую же сумму обошлось бы проживание и около 50 тысяч стоили бы билеты. Выложить 400 тысяч за участие в конференции - на это готовы немногие компании. В прошлые годы это стоило вдвое дешевле, поэтому и русских было побольше. А вот прекрасной половины человечества, наоборот, было много. Для них даже были отдельные сессии, на которых обсуждались типично женские вопросы - работа в мужском коллективе и т.п.
Завершение конференции я бы поделил на две части. В четверг была тусовка Codebreakers Bash на бейсбольном стадионе, отданном на растерзание нескольким тысячам безопасников, которые радовали пивом, закусками, игровыми автоматами, фейрверками, экскурсиями по полю и другим местам стадиона, концертом Шэрил Кроу и т.п.
А в пятницу финальным аккордом стала пленарная дискуссия с Шоном Пенном, актером и режиссером.
На закономерный вопрос: "А причем тут Шон Пенн и ИБ?", могу только поделиться своим мнением. После пяти очень насыщенных и интенсивных дней погружения в ИБ, нужна была некоторая разрядка. При этом, привлечь людей можно было только некоторой известной фигурой. Шон Пенн, а в прошлом году Алек Болдуин, как раз и были такими персонажами. С одной стороны интересно, с другой стороны - перегружает мозг от полученной информации, давая ей улечься. По крайней мере у меня было так. Не знаю, что уж там реально задумывали организаторы.
ЗЫ. У нас обычно по результатам какой-либо конференции отзывы пишутся по докладам регуляторов, которым рекламировать нечего и они делятся своими планами или результатами работы. Доклады вендоров полны рекламы и писать про них бессмысленно. На RSAC было с точностью до наоборот - выступлений регуляторов не было вовсе (кроме ключевых выступления АНБ, минобороны и генпрокурора - о них я еще напишу), а вот доклады именно представителей вендоров, консультантов, вузов и т.п. организаций были действительно интересно, так как вообще ничего не рекламировали (ну или почти ничего). Посколько докладов я посетил немало, то в ближайшие недели буду делиться наиболее запомнившимися мне идеями и мыслями. Там было немало полезного и для нашего рынка.
ЗЗЫ. Кстати, в ФБ возник вопрос о том, поехал бы я за свои деньги на это мероприятие? Интересный вопрос, на который четкого ответа у меня нет, так как все-таки я сейчас нахожусь немного в иной роли. Но как монетизировать и "отбить" такую поездку я бы нашел. Уж точно стоит посещать такое мероприятие журналистам и владельцам порталов по ИБ (тем для статей и заметок потом будет у них много), интеграторам в поисках новых ниш и продуктов, в том числе и для российского рынка (хотя именно тут, возможно, лондонская InfoSecurity будет поинтереснее), стартаперам (посмотреть, как подают себя на американском рынке, который для многих является мечтой).
Но я это объясняю очень просто - совершенно иная модель бизнеса организаторов. У нас (если не рассматривать InfoSecurity Russia, в которой конференция является приложением к выставке), конференции преследуют одну цель - получить деньги от спонсоров. Именно спонсоры платят за все и именно они являются целевой аудиторией организаторов. Слушатели вторичны и ни на что не влияют. На RSA Conference, да и на других мероприятиях (Gartner, BlackHat и т.п.) целевой аудиторией является слушатель - именно он платит за свое участие и именно он определяет, что он хочет услышать. И поэтому организатор подстраивается именно под слушателя, а не под спонсора.
На российских конференциях обычно выступления идут в один, максимум, в два, потока. Отчасти это сделано потому, что докладчиков от спонсоров ограниченное количество. Если включать в программу некоммерческих докладчиков, то либо это всплывет (и коммерческие докладчики начнут возмущаться), либо аудитория пойдет на докладчиков, которым не нужно рекламировать свои продукты и услуги. Коллизия, вытекающая из ориентации на спонсоров. На RSA Conference было... 30 параллельных потоков, посвященных своим темам:
Может сложиться впечатление, что спонсорские выступления лидируют, но это не так. Из 311 докладов (трехсот одиннадцати) только 20 было спонсорских - остальные вендор-независимые. Да, была завуалированная реклама, но она была ненапряжной и никогда (их тех докладов, что я слышал) про конкретные продукты. Краудсорсинговые темы выбирались путем голосования на сайте конференции (демократия в действии).
Кстати, о сайте. Тоже хороший пример грамотной организации онлайн-площадки для мероприятия. На нем задолго до начала мероприятия началось продвижения - заметки в блоге от разных экспертов, видео от участников, аннотации будущих докладов и т.п. Та идея, о которой я твержу различным организаторам наших мероприятий уже давно. С помощью сайта можно начать заранее заинтересовывать аудиторию, которая будет ориентироваться не только на программу, которая часто еще и публикуется всего за пару недель до мероприятия и участников не остается времени на принятие решения.
Но вернемся к самому мероприятию. Число параллельных потоков - не единственное разительное отличие RSAC от других конференций. Хотя наличие 30 потоков не гарантировало попадание на них. Да-да, несмотря на оплату 2000 долларов за конференцию, на поток можно было и не попасть из-за переполненности зала. Сами доклады длились по 50 минут. Не 15, не 20 и даже не 30 минут; целых 50. Этого достаточно, чтобы адекватно раскрыть тему, не пытаясь вложить кучу информации в небольшой временной тайм-слот.
Вот так обычно выглядела очередь на доклад (она доходила до 500 метров):
Чтобы не заблудиться среди хвостов очередей, на их окончаниях ставили персонал с вот такими табличками, которые двигались вместе с очередью.
Ну а уж если места не хватило, то картина была такая:
Еще одним отличием стало разнообразие форматов. У нас обычно все ограничивается схемой 1П (послушать) или 2П (послушать и посмотреть демо). На RSAC модель была 6П - послушать (обычные сессии), посмотреть демо, пощупать (можно было на IoT-потоке в отдельном зале поиграться с уязвимыми домашними Интернет-устройствами), потренироваться (было несколько лабораторных работ разного уровня - от построения стратегии ИБ предприятия и целого государства и заканчивая защитой промышленных сетей), поговорить (так называемые Peer2Peer-сессии, на которых до 25 человек за круглым столом обменивались мнениями и опытом по различным темам) и познакомиться (Dinner for 6, то есть ужин, где за столиками сидели по 6 человек, которые могли познакомиться и общаться).
 |
| Киберучения по обеспечению ИБ государства в кризисной ситуации |
 |
| Peer2Peer-сессия про угрозы ИБ при управлении цепочками поставок |
 |
| Лаба по безопасности промышленных сетей |
 |
| "Песочница" по безопасности промышленных сетей |
 |
| SANSовские "сетевые войны" |
 |
| Ключевые выступления (keynote) |
 |
| Выступления по RSAC TV |
 |
| Дискуссии с отраслевыми экспертами |
Я смог побывать на разных вариантах сессий - все было организовано на высоком уровне. Но я не устаю отмечать качество контента. Работа программного комитета, над которым не довлели спонсоры, выше всяких похвал. У меня даже сложилось впечатление, что программа RSA Conference напоминает мини-MBA, где раскрываются ключевые и важнейшие темы, которые волнуют руководителей по ИБ - от выхода на уровень топ-менеджмента (этому было посвящено не менее пяти выступлений) до количественного измерения различных аспектов ИБ, от трендов в области угроз и ИБ до работы с персоналом. Из несколько десятков докладов, что я послушал, не было ни одного неполезного и из которого бы я не извлек что-то новое и интересное для себя. И, блин, как им удалось такое количество докладов сделать без рекламы?.. Не устаю удивляться :-) Кстати, нередко, когда выступающих было двое - тоже интересная форма подачи материала (у нас такое редко бывает).
Материалы были выложены заранее - и это тоже необычно. Хотя, если рассудить, то это было логично. При наличии 300 докладов и невозможности их посещения всех, стоило заранее ознакомиться с докладами, чтобы выбрать, на что идти. Это очень сильно помогло лично мне, когда я формировал свою программу посещения презентаций. Очень понравилось приложение конференции, но про него я напишу отдельную заметку (там есть, на что обратить внимание).
Русскоговорящих участников на конференции я не встречал или это были представители Лаборатории Касперского (они были большой делегацией) и местных компаний. Все-таки курс национальной валюты сыграл свою не самую лучшую роль. Даже при ранней регистрации надо было бы выложить 1600 долларов, что по нынешнему курсу составляет свыше 100 тысяч рублей. Поздняя регистрация обходилось уже в 2200 долларов, то есть 150 тысяч. Примерно в такую же сумму обошлось бы проживание и около 50 тысяч стоили бы билеты. Выложить 400 тысяч за участие в конференции - на это готовы немногие компании. В прошлые годы это стоило вдвое дешевле, поэтому и русских было побольше. А вот прекрасной половины человечества, наоборот, было много. Для них даже были отдельные сессии, на которых обсуждались типично женские вопросы - работа в мужском коллективе и т.п.
Завершение конференции я бы поделил на две части. В четверг была тусовка Codebreakers Bash на бейсбольном стадионе, отданном на растерзание нескольким тысячам безопасников, которые радовали пивом, закусками, игровыми автоматами, фейрверками, экскурсиями по полю и другим местам стадиона, концертом Шэрил Кроу и т.п.
А в пятницу финальным аккордом стала пленарная дискуссия с Шоном Пенном, актером и режиссером.
На закономерный вопрос: "А причем тут Шон Пенн и ИБ?", могу только поделиться своим мнением. После пяти очень насыщенных и интенсивных дней погружения в ИБ, нужна была некоторая разрядка. При этом, привлечь людей можно было только некоторой известной фигурой. Шон Пенн, а в прошлом году Алек Болдуин, как раз и были такими персонажами. С одной стороны интересно, с другой стороны - перегружает мозг от полученной информации, давая ей улечься. По крайней мере у меня было так. Не знаю, что уж там реально задумывали организаторы.
ЗЗЫ. Кстати, в ФБ возник вопрос о том, поехал бы я за свои деньги на это мероприятие? Интересный вопрос, на который четкого ответа у меня нет, так как все-таки я сейчас нахожусь немного в иной роли. Но как монетизировать и "отбить" такую поездку я бы нашел. Уж точно стоит посещать такое мероприятие журналистам и владельцам порталов по ИБ (тем для статей и заметок потом будет у них много), интеграторам в поисках новых ниш и продуктов, в том числе и для российского рынка (хотя именно тут, возможно, лондонская InfoSecurity будет поинтереснее), стартаперам (посмотреть, как подают себя на американском рынке, который для многих является мечтой).
3.3.16
Уральский форум: финальный аккорд
Что еще запоминающегося с точки зрения новостей от регуляторов прозвучало на Уральском форуме? Пожалуй, выделю еще несколько моментов, на которые стоит обратить внимание:
- Планируется законодательно закрепить право Банка России по нормативному регулированию вопросов, связанных с обеспечением информационной безопасности всей информационной инфраструктуры кредитной организации и всех видов информации, обрабатываемой в кредитной организации, в том числе информации, отнесенной к категории банковской тайны. Иными словами, опыт 27-й статьи ФЗ-161, которая наделяет ЦБ правом устанавливать требования по защите информации при осуществлении денежных переводов и контролировать их исполнение, хотят распространить и на другие сферы, попадающие в прицел регулятора. Когда это произойдет пока непонятно, но у регулятора есть желание сделать это поскорее.
- В рамках СТО БР ИББС должна появиться РС по квалификации персонала, чтобы новичкам можно было ориентироваться на набор знаний и умений, а уже опытным - оценивать сотрудников при найме. Сроки появления этого документа пока не объявлены. Вообще в утвержденном плане работ ПК1 ТК122 на 2016-2017 годы этого документа нет - это новация. Но квалификация - это боль для многих организаций, поэтому неслучайно про нее заговорил и ЦБ. Первый зампред Швецов в своем выступлении даже упомянул, что по инициативе ЦБ сейчас переводится некий лондонский курс по кибербезопасности, который может в долгосрочной перспективе (5 лет) стать обязательным для сотрудников, мечтающих пойти в банковскую ИБ.
- У банковского надзора есть желание реализовать систему надзорных мер, учитывающую результаты контроля информационной безопасности. Как это будет, не до конца понятно, но в кулуарах даже звучала мысль о том, что надо взять за основу Базель II/III и привязать требования по достаточности капитала (а они уже введены в России) к уровню безопасности, который является некоторой дифференциальной величиной, зависящей и от уровня защищенности, оцениваемого в рамках надзорных мероприятий, и от числа инцидентов, произошедших в организации, и от числа похищенных в банке средств. Но пока это дальняя перспектива и сроки ее реализации не озвучивались (явно не раньше проведения революции по изменению 382-П и перевода СТОБР в разряд ГОСТа).
- ДНПС планирует во второй половине 2016 года выпустить "Рекомендации по обеспечению устойчивости инфраструктуры финансовых рынков к угрозам кибербезопасности" (в развитие Письма Банка России от 29.06.2012 №94-Т "О документе Комитета по платежным и расчетным системам "Принципы для инфраструктур финансового рынка"). И хотя к инициативам ДНПС в области ИБ я отношусь скептически, они уже и примерную структура этого документа имеют:
- Корпоративное управление
- Идентификация
- Защита
- Обнаружение
- Реагирование и восстановление
- Тестирование
- Ситуационная осведомленность
- Обучение и совершенствование.
Вот такая картина вырисовывается по итогам Уральского форума. Много планов, как краткосрочных, так и долгосрочных. Много полезных вещей. Что из этого будет реализовано, пока не знаю - будем ждать. А пока могу подвести черту под серией заметок про Уральский форум. Ключевые, на мой взгляд, вещи я изложил.
2.3.16
Уральский форум: предварительная отчетность по инцидентам
С отчетность по инцидентам вышла промашка; очередная. Я уже в прошлом году высказывался по поводу того, что мне не совсем понятно, зачем ДНПС собирает 203-ю форму отчетности, если он не публикует никаких ее сводных результатов. А все, что он публикует (о сумма похищенных средств с карт и из ДБО), - это не более чем PR и игра на публику; большого смысла эти цифры не имеют и в деятельности банковских служб ИБ не помогают. Меня мало волнуют как таковые суммы украденных средств - гораздо интересней, как и почему это происходит. Но вот именно эти данные ДНПС и скрывает (или не не знает, как их интерпретировать, или просто так и не обработал за все эти годы).
В этом раз вопрос о публикации отчетности опять возник. И представитель ДНПС ответил на него со всей прямотой - 203-я форма отчетности является внутренней и публиковаться не будет. Максимум, на что можно рассчитывать, - это на публикацию цифр потер, как и в прошлом году. В скором времени этот отчет будет опубликован на сайте Банка России, а пока можно ознакомиться с предварительными цифрами:
 |
| Реальные и предотвращенные хищения в ДБО |
 |
| Хищения по картам |
Не густо, если учитывать, сколько информации заполняется в 203-й и 258-й формах по инцидентам. Но, видимо, не судьба...
Зато было интересно услышать мнение, что отчетность по СТО БР в определенной перспективе отомрет. Она и сейчас-то постоянно вызывает вопросы - зачем при наличии 202-й отчетности еще и отправлять цифры по СТО БР ИББС. Да еще и в другое подразделение (в ГУБЗИ, а не ДНПС). Но скоро это прекратится и останется только одна отчетность, которая возьмет в себя лучшее от всех существующих сегодня форм по информационной безопасности. Примерный срок этого счастья такой же, что и переход ЦД на обязательные ГОСТы и внесение долгосрочных изменений в 382-П.
1.3.16
IBM покупает Resilient Systems
На RSA Conference компания IBM объявила о намерении приобрести Resilient Systems, в России неизвестной, а в мире занимающейся консалтинговыми услугами и своей платформой по автоматизации расследования инцидентов. Гораздо больше известен один из руководителей Resilient Systems - Брюс Шнайер. Размер сделки не известен.
А вообще про стартапы в ИБ, сделки слияния и поглощения, правильный выбор ИБ-стартапа на RSA Conference говорилось и будет говорится много.
А вообще про стартапы в ИБ, сделки слияния и поглощения, правильный выбор ИБ-стартапа на RSA Conference говорилось и будет говорится много.
Уральский форум: изменения 382-П в краткосрочной перспективе
Рассмотрев в предыдущей заметке, что ждет 382-П в долгосрочной перспективе, посмотрим на то, что обещает ЦБ сделать в самом скором времени. Речь идет о двух крупных (помимо разной мелочевки) поправках:
С разделением контуров ситуация немного иная - там все проще. Требование разделения контуров подготовки и подтверждения поручений на осуществление перевода денежных средств применяется "при осуществлении переводов денежных средств с использованием сети «Интернет» и (или) размещении клиентских компонентов на средствах вычислительной техники, для которых оператором по переводу денежных средств не обеспечивается непосредственный контроль защиты информации от воздействия вредоносного кода".
Разделение реализуется путем внедрения следующих защитных мер:
- установлении правил организации работ и оценки соответствия автоматизированных банковских систем и приложений, применяемых в национальной платежной системе
- формировании правовой основы для применения средств, обеспечивающих разделение контуров подготовки и подтверждения поручений на осуществление перевода денежных средств.
С оценкой соответствия на сегодняшний день самая непонятная тема. На форуме про нее ничего конкретного не сказали, за исключением некоторых моментов. Во-первых, Банк России не хочет делать обязательную сертификацию АБС и платежных приложений. Это последнее, на что ЦБ пойдет. Во-вторых, делаться это будет в рамках законодательства о техническом регулировании, а не через саморегулируемые организации (этот вариант, наряду с техрегулированием, озвучивали в прошлом году). В-третьих, речь идет не о классической оценке соответствия ПО, а контроле процесса соблюдения жизненного цикла банковского ПО. Но пока непонятно как это будет происходить. Все-таки ЦБ не имеет полномочий над разработчиками софта и это является основным камнем преткновения в данном вопросе. Наверное, поэтому вступление в силу данной части нового 382-П запланировано по истечении 360 дней с момента опубликована нормативного акта, который сам должен быть введен в действие в первой половине 2016-года.
С разделением контуров ситуация немного иная - там все проще. Требование разделения контуров подготовки и подтверждения поручений на осуществление перевода денежных средств применяется "при осуществлении переводов денежных средств с использованием сети «Интернет» и (или) размещении клиентских компонентов на средствах вычислительной техники, для которых оператором по переводу денежных средств не обеспечивается непосредственный контроль защиты информации от воздействия вредоносного кода".
Разделение реализуется путем внедрения следующих защитных мер:
- идентификация и аутентификация клиента при подготовке и при подтверждении электронных сообщений
- возможность использования клиентом независимых программных сред для подготовки и подтверждения электронных сообщений
- возможность контроля клиентом реквизитов распоряжений (пакета распоряжений) на осуществление переводов денежных средств при подготовке электронных сообщений и их подтверждении
- реализация оператором по переводу денежных средств аутентификации и контроля достоверности (сверки) реквизитов распоряжений (пакета распоряжений) на осуществление переводов денежных средств входных электронных сообщений, полученных от клиента, на основе аутентификационных данных, сформированных с использованием реквизитов распоряжений (пакета распоряжений) на осуществление переводов денежных средств при подготовке клиентом электронных сообщений и подтверждении клиентом электронных сообщений
- удостоверение оператором по переводу денежных средств распоряжения клиента только в случае положительных результатов аутентификации и контроля достоверности (сверки) реквизитов распоряжений (пакета распоряжений) на осуществление переводов денежных средств входных электронных сообщений.
Понятно, что при очевидной простоте этих требований, реализовать их будет небыстро и недешево. Поэтому операторам по переводу денежных средств дается на их внедрение 720 дней с момента опубликования нового 382-П.
Очевидно, что требование разделения контуров реализовать можно не везде. Например, на мобильном устройстве врядли можно ожидать использования независимых программных клиентов для подготовки платежки и для ее подтверждения - это просто неудобно. Поэтому в новом 382-П будет предусмотрена и альтернатива, уже знакомая по текущей редакции:
- ограничение максимальной суммы перевода денежных средств за одну операцию и (или) за определенных период времени
- определение перечня возможных получателей денежных средств
- определение временного периода, в который могут быть совершены переводы денежных средств
- определение географического местоположения устройств, с использованием которых может осуществляться подготовка и (или) подтверждение клиентом электронных сообщений
- определение перечня устройств, с использованием которых может осуществляться подготовка и (или) подтверждение клиентом электронных сообщений, на основе идентификаторов указанных устройств
- определение перечня предоставляемых услуг, связанных с осуществлением переводов денежных средств.
Уральский форум: изменения 382-П в долгосрочной перспективе
Продолжая тему, начатую в прошлой заметке, сегодня мне хотелось бы поговорить о планах Банка России по изменению 382-П. На Уральском форуме таких изменений было озвучено два - в краткосрочной и долгосрочной перспективе. Начну со второго.
Кто читал 382-П, тот знает, что это непростой документ с точки зрения его структуры и построения. Большое число требований по защите информации при осуществлении переводов денежных средств, ориентация на широкий круг участников Национальной платежной системы... Это приводит к тому, что почти каждый абзац 382-П начинается со слов "оператор по переводу денежных средств, оператор услуг платежной инфраструктуры, банковский платежных агент (субагент) должен...". И так порядка двух страниц текста, у которого еще и отсутствует нормальная нумерация. И вдруг "оператор по переводу денежных средств, оператор услуг платежной инфраструктуры должен...". Заметили разницу? Сходу, наверное, нет. После двух страниц повтора глаз замыливается и вы уже не обращаете внимание на то, что из абзаца исчез "банковский платежных агент (субагент)". И так все несколько десятков страниц подробных технических требований по тому, как защищать платежную систему.
Если сравнить 382-П с ПП-584, который также посвящен вопросам защиты информации в платежных системах, то мы сразу увидим разницу. ПП-584 содержит всего 10 требований по защите, детализация которых остается за кадром. И несмотря на то, что 382-П касается защиты информации преимущественно при традиционных банковских взаимоотношениях, текст этого нормативного акта достаточно большой. А ведь если вспомнить, что ЦБ в прошлом году озвучил планы по унификации всех требований по защите в рамках 382-П, то в нем, как минимум, не хватает требований по защите платежных карт (где ты "русский PCI DSS"), полноценных требований по защите банкоматов, требований по антифроду и раскрытия многих других вопросов ИБ кредитных организаций и других участников НПС. Если все это добавить в текст 382-П читать и воспринимать его станет вообще невозможно.
Отсюда и возникает идея, которую в долгосрочной перспективе и хочет реализовать ЦБ, - убрать из 382-П все глубоко технические моменты по защите информации, оставив в нем только концептуальные вещи. А куда же тогда убрать "технику"? Правильно, для этого и предназначен ГОСТ, о котором я писал в предыдущей заметке. В итоге получается очень даже логичная конструкция:
Кто читал 382-П, тот знает, что это непростой документ с точки зрения его структуры и построения. Большое число требований по защите информации при осуществлении переводов денежных средств, ориентация на широкий круг участников Национальной платежной системы... Это приводит к тому, что почти каждый абзац 382-П начинается со слов "оператор по переводу денежных средств, оператор услуг платежной инфраструктуры, банковский платежных агент (субагент) должен...". И так порядка двух страниц текста, у которого еще и отсутствует нормальная нумерация. И вдруг "оператор по переводу денежных средств, оператор услуг платежной инфраструктуры должен...". Заметили разницу? Сходу, наверное, нет. После двух страниц повтора глаз замыливается и вы уже не обращаете внимание на то, что из абзаца исчез "банковский платежных агент (субагент)". И так все несколько десятков страниц подробных технических требований по тому, как защищать платежную систему.
Если сравнить 382-П с ПП-584, который также посвящен вопросам защиты информации в платежных системах, то мы сразу увидим разницу. ПП-584 содержит всего 10 требований по защите, детализация которых остается за кадром. И несмотря на то, что 382-П касается защиты информации преимущественно при традиционных банковских взаимоотношениях, текст этого нормативного акта достаточно большой. А ведь если вспомнить, что ЦБ в прошлом году озвучил планы по унификации всех требований по защите в рамках 382-П, то в нем, как минимум, не хватает требований по защите платежных карт (где ты "русский PCI DSS"), полноценных требований по защите банкоматов, требований по антифроду и раскрытия многих других вопросов ИБ кредитных организаций и других участников НПС. Если все это добавить в текст 382-П читать и воспринимать его станет вообще невозможно.
Отсюда и возникает идея, которую в долгосрочной перспективе и хочет реализовать ЦБ, - убрать из 382-П все глубоко технические моменты по защите информации, оставив в нем только концептуальные вещи. А куда же тогда убрать "технику"? Правильно, для этого и предназначен ГОСТ, о котором я писал в предыдущей заметке. В итоге получается очень даже логичная конструкция:
- ФЗ-161 определяет необходимость защиты информации при осуществлении переводов денежных средств в рамках НПС.
- Положения Банка России определяют основные организационно-правовые и технологические моменты в защите информации.
- Детальная техническая проработка отдается на откуп национальным стандартам, имеющим обязательный статус применения.
Такая трехуровневая иерархия имеет ряд преимуществ. Во-первых, мы можем под новые технологии перевода денежных средств (банкоматы и POS-терминалы, ДБО, карты, NFC, мобильные платежи и т.п.) разрабатывать свои стандарты, не меняя вышестоящих документов. Во-вторых, на один и тот же стандарт мы можем ссылаться из разных документов второго уровня. Например, вопросы защиты в НПС у нас регулирует не только 382-П, но и 437-П для организаторов торгов. Или, например, недавно вступившее в силу положение Банка России 482-П "О порядке расчёта величины кредитного риска на основе внутренних рейтингов". Оно не касается напрямую информационной безопасности, но обязывает банки для повышения качества данных, используемых при расчете величины кредитного риска, реализовывать набор защитных мероприятий. Как понять, что надо сделать, если в 482-П, как и в 437-П, просто перечислены названия защитных мер (а по сути это названия блоков защитных мер из 382-П)? Наличие трехуровневой схемы решает и эту проблему.
Вообще, я с этой идеей ношусь уже достаточно давно. Я в первый раз ее озвучивал еще в 2008-м году на InfoSecurity Russia, но к ней мало кто прислушался. Только сейчас, по сути, регуляторы приходят к такой модели. Та же ФСТЭК реализует схожий подход - "ФЗ-149 -> приказ №17 -> методические рекомендации".
Вообще, я с этой идеей ношусь уже достаточно давно. Я в первый раз ее озвучивал еще в 2008-м году на InfoSecurity Russia, но к ней мало кто прислушался. Только сейчас, по сути, регуляторы приходят к такой модели. Та же ФСТЭК реализует схожий подход - "ФЗ-149 -> приказ №17 -> методические рекомендации".
Очевидно, что реализовано это изменение будет не быстро. Оно должно случиться вместе с принятием ГОСТов Банка России, то есть, не ранее чем через 2-3 года. Но когда это произойдет, будет очень даже неплохо. Будет заложена основа для дальнейшего развития нормативных актов ЦБ в области информационной безопасности.
29.2.16
Уральский форум: СТОБР станет обязательным
Убедившись, что с июля 2016-го года национальные стандарты, определяющие требования по защите сведений ограниченного доступа, к которым может относиться и банковская тайна, и инсайдерская информация, могут быть обязательными, мы вновь возвращаемся к вопросу обязательности СТО БР ИББС Банка России. Если вспомнить предысторию, то в 2011-2012-м годах эта тема уже поднималась и Банк России хотел перевести СТО в ранг ГОСТа. Но тогда это не имело большого смысла, так как, что в статусе СТО, что в статусе ГОСТа документ ЦБ не мог перейти из разряда рекомендаций в обязательные к применению нормативные акты. Сейчас ситуация меняется, о чем и говорили на Уральском форуме.
Разумеется, не стоит ждать, что в июле СТОБР поменяет свой статус. Пройдет немало времени, прежде чем это радостное (а для кого-то и не очень) событие произойдет. Давайте прикинем, сколько времени на это понадобится. До июля точно никто никаких шагов предпринимать не будет; да и ЦБ сейчас занят новой редакцией 382-П, о которой я еще скажу дальше. Переводить текущую, пятую версию СТО в разряд ГОСТа тоже не имеет смысла, - потребуется переработка этого документа. Это займет не менее (по моим оценкам) года. Не менее еще одного года уйдет на внесение проекта нового стандарта в Ростехрегулирование, его рассмотрение и принятие. По опыту участия в ТК362 "Защита информации" могу сказать, что обычно на вступление в силу нового ГОСТа уходит около полутора-двух лет с момента его внесения в Ростехрегулирование. Получается, что у нас есть около 3-х лет на этот переходный период. Есть время подготовиться к этой "революции".
На самом деле, переводом СТОБР в ГОСТ дело не ограничивается. После того как ГУБЗИ получило контроль над 382-П (раньше за его развитие отвечал ДНПС) и вся основная нормативная база по ИБ кредитных (и некредитных, но об этом позже) организаций вновь сосредоточилась в одних руках (так было до 2012-го года), ГУБЗИ затеяло небыстрый проект по гармонизации и унификации своих требований по защите информации, которые будут разнесены на два уровня - требования технического характера уйдут на уровень ГОСТов, а требования организационно-правового и технологического характера будут определяться нормативными актами Банка России - положениями и указаниями. Из этого вытекает и логичный вывод о том, что 382-П также претерпит серьезные изменения, о которых я расскажу в следующей заметке.
Разумеется, не стоит ждать, что в июле СТОБР поменяет свой статус. Пройдет немало времени, прежде чем это радостное (а для кого-то и не очень) событие произойдет. Давайте прикинем, сколько времени на это понадобится. До июля точно никто никаких шагов предпринимать не будет; да и ЦБ сейчас занят новой редакцией 382-П, о которой я еще скажу дальше. Переводить текущую, пятую версию СТО в разряд ГОСТа тоже не имеет смысла, - потребуется переработка этого документа. Это займет не менее (по моим оценкам) года. Не менее еще одного года уйдет на внесение проекта нового стандарта в Ростехрегулирование, его рассмотрение и принятие. По опыту участия в ТК362 "Защита информации" могу сказать, что обычно на вступление в силу нового ГОСТа уходит около полутора-двух лет с момента его внесения в Ростехрегулирование. Получается, что у нас есть около 3-х лет на этот переходный период. Есть время подготовиться к этой "революции".
На самом деле, переводом СТОБР в ГОСТ дело не ограничивается. После того как ГУБЗИ получило контроль над 382-П (раньше за его развитие отвечал ДНПС) и вся основная нормативная база по ИБ кредитных (и некредитных, но об этом позже) организаций вновь сосредоточилась в одних руках (так было до 2012-го года), ГУБЗИ затеяло небыстрый проект по гармонизации и унификации своих требований по защите информации, которые будут разнесены на два уровня - требования технического характера уйдут на уровень ГОСТов, а требования организационно-правового и технологического характера будут определяться нормативными актами Банка России - положениями и указаниями. Из этого вытекает и логичный вывод о том, что 382-П также претерпит серьезные изменения, о которых я расскажу в следующей заметке.
Может ли ГОСТ быть обязательным? Теперь может!
4 года назад я написал заметку про "обязательность" национальных стандартов (ГОСТов), которые могли получить статус обязательного применения не только путем включения упоминаний в ТЗ, но и в том случае, если автором ГОСТа был один из 4-х регуляторов в области защиты информации ограниченного доступа - ФСТЭК, ФСБ, МинОбороны и СВР. Шли годы и ситуация изменилась.
В июле 2015-го года был принят новый закон №162-ФЗ "О стандартизации в Российской Федерации" (на сайте "Российской газеты", в Консультанте, в Гаранте, у Президента). Согласно данному закону, а точнее его 6-й статье, в том случае, если речь идет о "стандартизации в отношении оборонной продукции (товаров, работ, услуг) по государственному оборонному заказу, продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа, продукции, сведения о которой составляют государственную тайну, продукции, для которой устанавливаются требования, связанные с обеспечением безопасности в области использования атомной энергии, а также в отношении процессов и иных объектов стандартизации, связанных с такой продукцией", то такие стандарты являются обязательными к применению. Порядок такой стандартизации устанавливается Правительством РФ.
Этот закон вступил в силу 29-го сентября 2015-го года, но в полной мере (всеми своими статьями, включая и 6-ю) он заработает с 1-го июля 2016-го года. С этого момента (и после опубликования соответствующего Постановления Правительства, на что тоже понадобится некоторое время) национальные стандарты по информационной безопасности смогут уже безо всяких обиняков получать статус обязательных к применению, что открывает новые возможности для всех федеральных органов исполнительной власти, наделенных правом создавать свои собственные стандарты.
В законе говорится еще много чего о процедуре разработке и принятия ГОСТов и других документов по стандартизации, о признании международных стандартов и других вопросах, но в контексте последующих заметок я хотел остановиться только на одном аспекте нового закона - обязательности применения ГОСТа по защите информации ограниченного доступа.
В июле 2015-го года был принят новый закон №162-ФЗ "О стандартизации в Российской Федерации" (на сайте "Российской газеты", в Консультанте, в Гаранте, у Президента). Согласно данному закону, а точнее его 6-й статье, в том случае, если речь идет о "стандартизации в отношении оборонной продукции (товаров, работ, услуг) по государственному оборонному заказу, продукции, используемой в целях защиты сведений, составляющих государственную тайну или относимых к охраняемой в соответствии с законодательством Российской Федерации иной информации ограниченного доступа, продукции, сведения о которой составляют государственную тайну, продукции, для которой устанавливаются требования, связанные с обеспечением безопасности в области использования атомной энергии, а также в отношении процессов и иных объектов стандартизации, связанных с такой продукцией", то такие стандарты являются обязательными к применению. Порядок такой стандартизации устанавливается Правительством РФ.
Этот закон вступил в силу 29-го сентября 2015-го года, но в полной мере (всеми своими статьями, включая и 6-ю) он заработает с 1-го июля 2016-го года. С этого момента (и после опубликования соответствующего Постановления Правительства, на что тоже понадобится некоторое время) национальные стандарты по информационной безопасности смогут уже безо всяких обиняков получать статус обязательных к применению, что открывает новые возможности для всех федеральных органов исполнительной власти, наделенных правом создавать свои собственные стандарты.
В законе говорится еще много чего о процедуре разработке и принятия ГОСТов и других документов по стандартизации, о признании международных стандартов и других вопросах, но в контексте последующих заметок я хотел остановиться только на одном аспекте нового закона - обязательности применения ГОСТа по защите информации ограниченного доступа.
26.2.16
Уральский форум: почему половина презентаций были бестолковы
Я взял за правило в 15-тиминутный обзор Уральского форума не включать то, что говорили вендоры в своих презентациях. Отчасти потому, что там редко бывает что-то интересное, отчасти потому, что там одна реклама... В первые два раза, когда я делал обзор, я еще пытался указать спикерам на типичные ошибки при выступлении, но потом отказался от этой идеи. Все-таки каждый сам кузнец своего счастья и каждый самостоятельно определяет как он отбивает маркетинговые затраты на поездки в Магнитогорск. Для кого-то основная задача - поймать тепленького клиента вечером и договориться обо всем (в таких случаях можно и на выступление свое не ходить - такое бывало). Для кого-то выступление - это отбывание повинности и результат в этом случае неважен. Для кого-то выступление - это самолюбование. Но есть и те, кто действительно пытается с пользой потратить 15-20 минут. Для них моя заметка.
В презентациях по финансовой эффективности ИБ я не раз фокусирую внимание на очень важной мысли, без понимания которой любая оценка обречена на неудачу. Важно понимать не ЧТО вы делаете в ИБ, а для ЧЕГО вы это делаете. В случае с презентациями я могу повторить ту же самую идею. Не так важно, ЧТО вы хотите вложить в вашу презентацию; гораздо важнее, ЧЕГО вы хотите достичь, читая вашу презентацию.
Те, кто могут сделать шаг от "ЧТО" к "ДЛЯ ЧЕГО" еще только находятся на полпути к победе, так как очень часто "ДЛЯ ЧЕГО" они трансформируют в "ДЛЯ ИНФОРМИРОВАНИЯ" и дальше честно рассказывают кучу слайдов о своих продуктах или продукте, забывая все-таки ответить на вопрос "для чего информировать целевую аудиторию". Цель нормальной презентации - не информировать о чем-то, а изменить что-то. Например, изменить поведение людей и организаций (правильно выбирать пароли или проводить расследование инцидентов), изменить убеждения (перестать тупо повторять про зло от импортных продуктов) и т.п. Это задача минимум. Задача максимум - заставить целевую аудиторию сделать что-то (например, пойти и купить продукт или хотя бы протестировать его, скачать freeware-решение для анализа вредоносного кода, присоединиться к FinCERT и т.п.). Иными словами, идеально, если презентация сможет не только убедить что-то сделать, но и заставить что-то сделать. И в презентации должен быть мостик между этими двумя пунктами.
Именно поэтому рассказы о современных угрозах, тенденциях и других аналогичных темах, могут быть интересны с точки зрения получения информации, но малополезны с точки зрения конкретных действий и пользы от них для конкретной организации, направившей своего сотрудника в командировку. Если бы еще каждый докладчик рассказывал что-то новое и ранее неслышанное, то тут ему можно было бы сказать спасибо хотя бы за новую информацию (спикер запомнится только этим, но он запомнится). А если все повторяют про APT, АРМ КБР, DDoS как попугаи, то это на третьем докладе становится уже скучным и народ начинает покидать зал.
Запугивать страшилками про "кражу миллиарда из АБС", "апокалипсис в мобильных банковских приложениях", "повсеместные импланты АНБ" и т.п. - дело нехитрое и много ума не требующее. Гораздо сложнее показать, как с этими угрозами бороться. И уж совсем непросто показать конкретные шаги, которые нужно сделать для того чтобы борьба с угрозами превратилась из слов в дело. Желательно, конечно, чтобы эти шаги были выполнимыми и их можно было бы начать делать сразу после презентации. Тогда шанс, что аудитория их попробует сделать гораздо выше, чем попытка "продать слона целиком". Но опять же повторю, что все это имеет смысл, если задача спикера - получить выгоду от своей презентации. Если он демонстрирует себя - забудьте, что я написал. Если он уже все "порешал" на горе или в баре - забудьте, что я написал.
На Уральском форуме были не только представители продавцов, задача которых должны была состоять в том, чтобы заставить слушателей после конференции попробовать их продукты/услуги. Были также и представители банков, которые ничего никому не продают, а просто делятся своим опытом. Как к ним применить то, что я написал выше? Как ни странно, но ничего не меняется. Если заказчик выступает на конференции и он не мотивирован производителем скрыто рекламируемой услуги или продукта, то у выступающего могут быть следующие цели:
В презентациях по финансовой эффективности ИБ я не раз фокусирую внимание на очень важной мысли, без понимания которой любая оценка обречена на неудачу. Важно понимать не ЧТО вы делаете в ИБ, а для ЧЕГО вы это делаете. В случае с презентациями я могу повторить ту же самую идею. Не так важно, ЧТО вы хотите вложить в вашу презентацию; гораздо важнее, ЧЕГО вы хотите достичь, читая вашу презентацию.
Те, кто могут сделать шаг от "ЧТО" к "ДЛЯ ЧЕГО" еще только находятся на полпути к победе, так как очень часто "ДЛЯ ЧЕГО" они трансформируют в "ДЛЯ ИНФОРМИРОВАНИЯ" и дальше честно рассказывают кучу слайдов о своих продуктах или продукте, забывая все-таки ответить на вопрос "для чего информировать целевую аудиторию". Цель нормальной презентации - не информировать о чем-то, а изменить что-то. Например, изменить поведение людей и организаций (правильно выбирать пароли или проводить расследование инцидентов), изменить убеждения (перестать тупо повторять про зло от импортных продуктов) и т.п. Это задача минимум. Задача максимум - заставить целевую аудиторию сделать что-то (например, пойти и купить продукт или хотя бы протестировать его, скачать freeware-решение для анализа вредоносного кода, присоединиться к FinCERT и т.п.). Иными словами, идеально, если презентация сможет не только убедить что-то сделать, но и заставить что-то сделать. И в презентации должен быть мостик между этими двумя пунктами.
Именно поэтому рассказы о современных угрозах, тенденциях и других аналогичных темах, могут быть интересны с точки зрения получения информации, но малополезны с точки зрения конкретных действий и пользы от них для конкретной организации, направившей своего сотрудника в командировку. Если бы еще каждый докладчик рассказывал что-то новое и ранее неслышанное, то тут ему можно было бы сказать спасибо хотя бы за новую информацию (спикер запомнится только этим, но он запомнится). А если все повторяют про APT, АРМ КБР, DDoS как попугаи, то это на третьем докладе становится уже скучным и народ начинает покидать зал.
Запугивать страшилками про "кражу миллиарда из АБС", "апокалипсис в мобильных банковских приложениях", "повсеместные импланты АНБ" и т.п. - дело нехитрое и много ума не требующее. Гораздо сложнее показать, как с этими угрозами бороться. И уж совсем непросто показать конкретные шаги, которые нужно сделать для того чтобы борьба с угрозами превратилась из слов в дело. Желательно, конечно, чтобы эти шаги были выполнимыми и их можно было бы начать делать сразу после презентации. Тогда шанс, что аудитория их попробует сделать гораздо выше, чем попытка "продать слона целиком". Но опять же повторю, что все это имеет смысл, если задача спикера - получить выгоду от своей презентации. Если он демонстрирует себя - забудьте, что я написал. Если он уже все "порешал" на горе или в баре - забудьте, что я написал.
На Уральском форуме были не только представители продавцов, задача которых должны была состоять в том, чтобы заставить слушателей после конференции попробовать их продукты/услуги. Были также и представители банков, которые ничего никому не продают, а просто делятся своим опытом. Как к ним применить то, что я написал выше? Как ни странно, но ничего не меняется. Если заказчик выступает на конференции и он не мотивирован производителем скрыто рекламируемой услуги или продукта, то у выступающего могут быть следующие цели:
- Закрепить имидж своей компании ("смотрите, какую классную штуку мы у себя внедрили") или свой собственный авторитет ("смотрите, с какой классной штукой мне удалось поработать - я готов поделиться опытом").
- Приобрести статус эксперта в какой-либо области ("смотрите, я обладаю уникальными знаниями/опытом - обращайтесь ко мне").
- Сформировать сеть знакомств ("смотрите, я могу тоже самое сделать и для вас").
И чтобы этих целей достичь надо не только заинтересовать слушателей (им должна быть знакома проблема, описываемая в докладе), но и заставить после доклада обратиться за деталями. Разумеется, доклады в стиле "я обладаю сокровенным знанием, но каким не скажу" не срабатывают. Тут нет даже информирования и убеждения, не говоря уже о действиях.
Наконец, третья категория выступающих - регуляторы. Они могут попадать как в первые две категорию докладчиков - продающие что-то (новые нормативные акты) и продающие себя, так и относиться к третьей - озвучивать отчет о деятельности по какому-то направлению (FinCERT, 202-я или 203-я форма отчетности, проверки и т.п.). В последнем случае регулятор тоже хочет (я надеюсь, что он хочет) добиться некоторых управленческих решений от слушателей, подпадающих под регулирование. Если, например, по отчетности число атак на ДБО растет, то надо снизить это число путем внедрения новых защитных мер. Если по результатам анализа 202-й формы оказывается, что у многих банков либо завышена, либо занижена итоговая оценка, то надо изменить что-то в самой отчетности и предостеречь банки от махинаций с цифрами. Поэтому регуляторам, отчитывающимся о своей деятельности, я бы рекомендовал следующий простой план выступления:
- Основные показатели деятельности (лицензии, дыры, сертификаты, проверки, уровни соответствия, хищения и т.п.). Достигнуты установленные в начале отчетного периода значения или нет? Если нет, то почему?
- Что произошло в работе важного за этот отчетный период? Почему это важно ("важно" для регулятора и для целевой аудитории может быть разным)?
- Все движется и развивается как должно или есть отклонения? Они серьезные? Если да, то почему они возникли и как в будущем вернуться на путь истинный?
- Есть ли какие-то сложности, которые нужно разрешить в будущем? Регулятор это сделает сам или ему нужна помощь от регулируемых?
- Если есть возможность рассказать о планах, то почему бы и нет - аудитория любит слушать о будущих изменениях; особенно если рассказ о них сопровождается объяснением, зачем эти изменения нужны.
Вот такие размышления о том, как выступали различные докладчики на Уральском форуме.
25.2.16
BlackBerry покупает Encription
24 февраля канадская компания BlackBerry объявила о приобретении английской Encription Limited, занимающейся консалтинговыми услугами в области кибербезопасности. Размер сделки не сообщается.
Уральский форум: Роскомнадзор и кредитные организации
Начну потихоньку выкладывать расширенные мысли и впечатления от Уральского форума по ИБ финансовых организаций, который закончился на прошлой неделе в Магнитогорске. В первой заметке выложу запись презентации замначальника РКН Приезжевой А.А. Причин две. Во-первых, это выступление было самым технически продвинутым (сделано и показано в Prezi), а, во-вторых, его удалили с сайта Prezi в тот же день и доступа к нему ни у кого не оказалось (причины удаления мне непонятны). Хотя в нем были очень интересные мысли и факты относительно деятельности РКН применительно к кредитным организациям.
Реестр отечественного софта в контексте информационной безопасности
Все думал, писать или не писать про реестр якобы отечественного софта в контексте информационной безопасности. Но тут, после публикации новости о внесении в реестр около сотни российских продуктов, все-таки решил выплеснуть ушат эмоций на околореестровую тему. Собственно, даже это будут не эмоции, а скорее мысли вслух по поводу конкретно этого реестра и способа его ведения. Сразу скажу, что я не против развития отечественной ИТ/ИБ-индустрии. Только вот делается это как-то несуразно и вот несколько тому подтверждений.
Итак, данный реестр создается на основании Постановления Правительства №1236 от 16 ноября 2015 года и поэтому я буду полностью ориентировать именно на его текст в своих размышлениях. Во-первых, где в этом ПП-1236 и, как следствие, в реестре ПО не для ЭВМ? И вообще, почему все так привязаны к этой дурацкой формулировке "программное обеспечение для ЭВМ и баз данных", кочующее из закона в закон? То, что эта фраза появилась в старом законе "Об авторском праве и смежных правах", не делает ее истиной в последней инстанции. Просто авторы этого дремучего закона от 93-го года на момент его написания и не знали, что программа может запускаться не только на ЭВМ. А сейчас? Возьмем уже всем набивший оскомину Интернет вещей. Если рассматривать ПО для работы какого-нибудь датчика IoT, то считать ли его программой для ЭВМ? И тоже самое сетевое оборудование? А BIOS/UEFI? Собственно к фразе "происходящего из иностранных государств" тоже есть немало претензий. Linux у нас откуда происходит? Ну да ладно, пойдем дальше.
Реестр должен содержать код (коды) продукции в соответствие с ОКВЭД. Тыц-тыц... С ОКВЭД в ПП-1236 вообще фееричная история. Дело в том, что в России принято... три классификатора ОКВЭДа. Один, ОКВЭД ОК 029-2001 был принят в 6-го ноября 2001 года. Второй - ОКВЭД ОК 029-2007 от 22.11.2007. Третий - ОКВЭД ОК 029-2014, принятый 31.01.2014. Так вот у нас сейчас действует не финальная редакция ОКВЭД, а первые две (тоже странная конструкция). Действуют они до 1-го января 2017-го года, и в них нет кодов для области информационной безопасности. Есть вот такие:
Правда, вопрос о том, какой из трех ОКВЭДов использовать при заполнении реестра, так и остается открытым - все три действительны, но последний еще не вступил в силу. Если подаваться по будущему классификатору (а именно его коды приведены в приложении к методичке Минкомсвязи по подаче заявления на включение ПО в реестр), то возникает коллизия - согласно приказа Росстандарта от 10.11.2015 №1745ст он вступает в силу только с 1-го января 2017 года. А если подаваться по действующему классификатору, то с 1-го января придется вновь подавать документы в связи с изменением сведений в первично поданных документах.
В отношении Лаборатории Касперского, Parallels, ABBYY, Яндекса и ряда других компаний с мировым именем часто возникают инсинуации относительно того, что эти компании зарегистрированы не в России и права собственности принадлежат не российским юридическим лицам. Да, возможно это так, но... в ПП-1326 говорится о том, что правообладателем ПО может быть и физическое лицо, а к нему предъявляется только одно требование - быть гражданином РФ. Но и тут есть подводный камень; даже два. Во-первых, ни слова не говорится о запрете двойного или даже тройного гражданства (на предварительных обсуждениях эта тема всплывала, но ее как-то замылили), что как бы намекает... А, во-вторых, мне интересно посмотреть на документы, в которых правообладателем является конкретное физическое лицо, а не компания.
Но мы идем дальше. Следующим пунктом является требование наличия страницы в Интернете, где была бы представлена пользовательская документация. Возьмем, к примеру, Wallarm, который может, вдруг, захотеть продаваться в госорганы в качестве альтернативы Application Firewall от Positive Technologies. И попробуем мы зайти на страницу www.wallarm.ru и... Перекинут нас на американский сайт компании-разработчика, которая не имеет своего российского Интернет-представительства. Тут на днях ко мне обратились организаторы одного мероприятия, желающие пригласить Wallarm для проведения мастер-класса. Просили они у меня контактов Wallarm, так как не могли найти контактов этой компании; российских контактов, я имею ввиду. Разрешено ли иметь англоязычную страницу в Интернет и такую же англоязычную документацию? Формально да, а вот если здраво рассуждать (в контексте национальной идеи, импортозамещения и т.п.), то получается как-то некузяво. Дальше по тексту говорится, что представленная информация может быть и на иностранном языке, но с заверенными переводами на русский язык.
И вот мы подступаем к 5-му (да-да, только к 5-му) пункту ПП-1236, в котором говорится о требованиях, которым должно удовлетворять ПО, включаемое в реестр. Одним из таких требований является свободная реализации ПО на всей территории РФ. С точки зрения авторов нормативного акта, как я их понимаю, главным был фрагмент "на всей территории РФ", чтобы отсечь всяких супостатов, не желающих торговать на территории Крым (про российские банки и платежные системы, не желающие работать в Крыму, я скромно умолчу). Но... мы же люди подкованные и не должны выдергивать фразу из контекста. Возьмем и вторую часть этого абзаца и увидим, что в нем говорится о "свободной реализации". А согласно действующему законодательству в России нет свободной реализации средств шифрования - существует вполне конкретное ПП-330, которое устанавливает условия, при которых организация, имеет право получить лицензию ФСБ, после чего только получает право реализовывать (распространять) средства шифрования. А при подаче документов на лицензию, еще необходимо указать адреса, по которым будет вестись лицензируемый вид деятельности. Интересно... Получается, что российские средства шифрования не могут попасть в данный реестр.
Дальше больше. В пункте 5д говорится о том, что если ПО реализует функции защиты конфиденциальной информации, то у такого ПО должен быть сертификат соответствия. В этом пункте вообще скрывается целый букет междустрочий. Во-первых, неявно, но речь идет о сертификате ФСТЭК, который подтверждает как раз соответствие требованиям безопасности конфиденциальной информации. С одной стороны, где ФСБ? Но мы уже увидели выше, что на средства шифрования по ПП-1236 вообще не могут быть занесены в реестр. И хотя это явный косяк разработчиков, незнакомых с законодательством по ИБ, формально никакого нарушения нет. С другой стороны, где говорится о том, что функция защиты конфиденциальной информации является основной? Без этого, под данное требование попадают все программные продукты. Ведь каждый из них реализуют ту или иную функцию по защите, например, идентификацию и аутентификацию администратора ПО. А может быть и другие функции. Но сейчас в реестре внесено чуть менее 10% ПО, имеющего сертификат ФСТЭК. Опять нарушение установленных требований. Кстати, сейчас в стадии подачи в реестр находится несколько средств защиты информации, которые... тыц-тыц еще не имеют сертификата ФСТЭК и только ждут его получения. Будет забавно если их внесут в реестр в нарушение установленных правил. Не то, чтобы я сомневаюсь, что их внесут, но лишнее подтверждение, что документ писали люди, далекие от ИБ, и что вся эта затея с импортозамещением - всего лишь профанация, все-таки будет налицо. Кстати, с сертификацией ФСТЭК есть и еще один нюанс. В ФСТЭК подается на сертификацию конкретная версия ПО, а не просто его наименование. А в реестре про этот момент ни слова. Поэтому не исключаю ситуацию, что через полгода-год возникнет ситуация, когда в реестре будет ПО с уже недействующим сертификатом соответствия или с сертификатом, выданным на предыдущую версию отечественного ПО.
Следующее требование. Если правообладателем является российская коммерческая или некоммерческая компания, то у нее должна быть лицензия ФСТЭК на разработку средств защиты информации. Тут на поверхности никаких косяков нет. Но это на поверхности. Этот пункт, особенно в контексте, грядущего изменения требований к лицензиатам, ставит крест на попытках отечественных стартапов попасть в реестр. Без системы менеджмента качества по ISO 9000 и внедренного (и подтвержденного) SDLC получить лицензию будет нельзя, а без лицензии нельзя попасть в реестр. Внедрять ISO 9000 и SDLC стартапу не по карману, так как у них нет еще достаточного количества клиентов и денег на развитие такой темы. А получить новых клиентов они не могут, так как в госорганы (более половины российского рынка ИБ) им путь закрыт. Замкнутый круг. То есть все красивые слова о развитии инноваций и стартапов в России опять оказываются пустым звуком. Стартапы так и будут ориентироваться на западный рынок, а российский будет поделен среди десятка ИБ-игроков, которые и сейчас чувствуют себя неплохо, не особо и нуждаясь в каких-либо преференциях.
Но с требованием лицензии ФСТЭК (кстати, опять забыта лицензия ФСБ на разработку средств шифрования, которым, видимо путь в реестр закрыт сознательно) связан и еще один момент, на который некоторые специалисты не обращают внимание, возможно сознательно. Представьте, что права на "отечественное" ПО зарегистрированы не на российское юрлицо, а на физлицо (как это иногда утверждают представители имеющих российские корни компаний, которые уже давно ушли на западные рынки). Тогда, по тому же ПП-1236, у этого физлица должна быть лицензия ФСТЭК. А много ли таких физлиц вы видели? Я - ни одного. Фактически, получается, что гражданин России не может быть правообладателем ПО, выполняющего функции защиты информации. А если ПО зарегистрировано на него, то... оно формально не может быть внесено в реестр (у физлиц же нет лицензии ФСТЭК).
Дальше ПП-1236 описывает процедуру подачи заявления на включение в реестр, из которой я бы хотел отметить только один момент - заявление должно быть подписано усиленной квалифицированной электронной подписью. А получение этой подписи для недавно образованного стартапа та еще "Одиссея". Очередной камень преткновения на пути молодых предпринимателей на отечественный рынок ИБ.
Еще один нюанс мне бы хотелось отметить применительно к классификатору ПО, который приведен в приложении к методичке Минкомсвязи по заполнению заявления на включение ПО в реестр. В нем по нашей теме приводится (впрямую) всего два типа ПО - "средства обеспечения ИБ" и "средства анализа исходного кода на закладки и уязвимости". Вот почему именно такое деление? Почему сканеры исходного кода вынесены в отдельную категорию, а сканеры уязвимостей нет? Тут у меня, конечно, есть подозрения, учитывая активное участие некоторых коллег в формировании всего пакета нормативных документов, но пусть эти подозрения останутся со мной.
В заключение у меня остается два вопроса, которые я задам вслух, но ответы на которые я жду увидеть в самом ближайшем будущем:
Итак, данный реестр создается на основании Постановления Правительства №1236 от 16 ноября 2015 года и поэтому я буду полностью ориентировать именно на его текст в своих размышлениях. Во-первых, где в этом ПП-1236 и, как следствие, в реестре ПО не для ЭВМ? И вообще, почему все так привязаны к этой дурацкой формулировке "программное обеспечение для ЭВМ и баз данных", кочующее из закона в закон? То, что эта фраза появилась в старом законе "Об авторском праве и смежных правах", не делает ее истиной в последней инстанции. Просто авторы этого дремучего закона от 93-го года на момент его написания и не знали, что программа может запускаться не только на ЭВМ. А сейчас? Возьмем уже всем набивший оскомину Интернет вещей. Если рассматривать ПО для работы какого-нибудь датчика IoT, то считать ли его программой для ЭВМ? И тоже самое сетевое оборудование? А BIOS/UEFI? Собственно к фразе "происходящего из иностранных государств" тоже есть немало претензий. Linux у нас откуда происходит? Ну да ладно, пойдем дальше.
Реестр должен содержать код (коды) продукции в соответствие с ОКВЭД. Тыц-тыц... С ОКВЭД в ПП-1236 вообще фееричная история. Дело в том, что в России принято... три классификатора ОКВЭДа. Один, ОКВЭД ОК 029-2001 был принят в 6-го ноября 2001 года. Второй - ОКВЭД ОК 029-2007 от 22.11.2007. Третий - ОКВЭД ОК 029-2014, принятый 31.01.2014. Так вот у нас сейчас действует не финальная редакция ОКВЭД, а первые две (тоже странная конструкция). Действуют они до 1-го января 2017-го года, и в них нет кодов для области информационной безопасности. Есть вот такие:
- 72.10 Консультирование по аппаратным средствам вычислительной техники
- 72.20 Разработка программного обеспечения и консультирование в этой области
- 72.30 Обработка данных
- 72.40 Деятельность по созданию и использованию баз данных и информационных ресурсов
- 72.50 Техническое обслуживание и ремонт офисных машин и вычислительной техники
- 72.60 Прочая деятельность, связанная с использованием вычислительной техники и информационных технологий
- 74.6 Проведение расследований и обеспечение безопасности (правда, физической и антитеррористической)
- 75.24 Деятельность по обеспечению общественного порядка и безопасности (сюда, наряду с деятельностью ФСБ, СВР, МВД, ФНС и других силовиков, попало и обеспечение безопасности средств связи и информации, но не информационных систем, и не сетей связи, и не СВТ).
- Издание прочих программных продуктов (программных продуктов общего пользования), включая перевод или адаптацию программных продуктов общего пользования для конкретного рынка за собственный счет: операционные системы, приложения для бизнеса и прочие приложения)
- 18.20 - воспроизведение программного обеспечения
- 47.41 - розничная торговля готовым программным обеспечением
- 62.01 - производство программного обеспечения, не связанного с изданием, включая перевод или адаптацию программного обеспечения общего пользования, для конкретных приложений, за вознаграждение или на договорной основе
- 63.11 - интерактивное предоставление программного обеспечения (предоставление прикладного хостинга, предоставление прикладных программ)
- 46.51 - деятельность консультативная и работы в области компьютерных технологий продажу аппаратных средств вычислительной техники или программного обеспечения
- 33.20 - установка универсальных ЭВМ и аналоговых компьютеров
- 62.09 - установка (настройка) персональных компьютеров
- 80 - Деятельность по обеспечению безопасности и проведению расследований
- 26.30.11.160 - программное обеспечение, обеспечивающее выполнение установленных действий при проведении оперативно-розыскных мероприятий
Правда, вопрос о том, какой из трех ОКВЭДов использовать при заполнении реестра, так и остается открытым - все три действительны, но последний еще не вступил в силу. Если подаваться по будущему классификатору (а именно его коды приведены в приложении к методичке Минкомсвязи по подаче заявления на включение ПО в реестр), то возникает коллизия - согласно приказа Росстандарта от 10.11.2015 №1745ст он вступает в силу только с 1-го января 2017 года. А если подаваться по действующему классификатору, то с 1-го января придется вновь подавать документы в связи с изменением сведений в первично поданных документах.
В отношении Лаборатории Касперского, Parallels, ABBYY, Яндекса и ряда других компаний с мировым именем часто возникают инсинуации относительно того, что эти компании зарегистрированы не в России и права собственности принадлежат не российским юридическим лицам. Да, возможно это так, но... в ПП-1326 говорится о том, что правообладателем ПО может быть и физическое лицо, а к нему предъявляется только одно требование - быть гражданином РФ. Но и тут есть подводный камень; даже два. Во-первых, ни слова не говорится о запрете двойного или даже тройного гражданства (на предварительных обсуждениях эта тема всплывала, но ее как-то замылили), что как бы намекает... А, во-вторых, мне интересно посмотреть на документы, в которых правообладателем является конкретное физическое лицо, а не компания.
Но мы идем дальше. Следующим пунктом является требование наличия страницы в Интернете, где была бы представлена пользовательская документация. Возьмем, к примеру, Wallarm, который может, вдруг, захотеть продаваться в госорганы в качестве альтернативы Application Firewall от Positive Technologies. И попробуем мы зайти на страницу www.wallarm.ru и... Перекинут нас на американский сайт компании-разработчика, которая не имеет своего российского Интернет-представительства. Тут на днях ко мне обратились организаторы одного мероприятия, желающие пригласить Wallarm для проведения мастер-класса. Просили они у меня контактов Wallarm, так как не могли найти контактов этой компании; российских контактов, я имею ввиду. Разрешено ли иметь англоязычную страницу в Интернет и такую же англоязычную документацию? Формально да, а вот если здраво рассуждать (в контексте национальной идеи, импортозамещения и т.п.), то получается как-то некузяво. Дальше по тексту говорится, что представленная информация может быть и на иностранном языке, но с заверенными переводами на русский язык.
И вот мы подступаем к 5-му (да-да, только к 5-му) пункту ПП-1236, в котором говорится о требованиях, которым должно удовлетворять ПО, включаемое в реестр. Одним из таких требований является свободная реализации ПО на всей территории РФ. С точки зрения авторов нормативного акта, как я их понимаю, главным был фрагмент "на всей территории РФ", чтобы отсечь всяких супостатов, не желающих торговать на территории Крым (про российские банки и платежные системы, не желающие работать в Крыму, я скромно умолчу). Но... мы же люди подкованные и не должны выдергивать фразу из контекста. Возьмем и вторую часть этого абзаца и увидим, что в нем говорится о "свободной реализации". А согласно действующему законодательству в России нет свободной реализации средств шифрования - существует вполне конкретное ПП-330, которое устанавливает условия, при которых организация, имеет право получить лицензию ФСБ, после чего только получает право реализовывать (распространять) средства шифрования. А при подаче документов на лицензию, еще необходимо указать адреса, по которым будет вестись лицензируемый вид деятельности. Интересно... Получается, что российские средства шифрования не могут попасть в данный реестр.
Дальше больше. В пункте 5д говорится о том, что если ПО реализует функции защиты конфиденциальной информации, то у такого ПО должен быть сертификат соответствия. В этом пункте вообще скрывается целый букет междустрочий. Во-первых, неявно, но речь идет о сертификате ФСТЭК, который подтверждает как раз соответствие требованиям безопасности конфиденциальной информации. С одной стороны, где ФСБ? Но мы уже увидели выше, что на средства шифрования по ПП-1236 вообще не могут быть занесены в реестр. И хотя это явный косяк разработчиков, незнакомых с законодательством по ИБ, формально никакого нарушения нет. С другой стороны, где говорится о том, что функция защиты конфиденциальной информации является основной? Без этого, под данное требование попадают все программные продукты. Ведь каждый из них реализуют ту или иную функцию по защите, например, идентификацию и аутентификацию администратора ПО. А может быть и другие функции. Но сейчас в реестре внесено чуть менее 10% ПО, имеющего сертификат ФСТЭК. Опять нарушение установленных требований. Кстати, сейчас в стадии подачи в реестр находится несколько средств защиты информации, которые... тыц-тыц еще не имеют сертификата ФСТЭК и только ждут его получения. Будет забавно если их внесут в реестр в нарушение установленных правил. Не то, чтобы я сомневаюсь, что их внесут, но лишнее подтверждение, что документ писали люди, далекие от ИБ, и что вся эта затея с импортозамещением - всего лишь профанация, все-таки будет налицо. Кстати, с сертификацией ФСТЭК есть и еще один нюанс. В ФСТЭК подается на сертификацию конкретная версия ПО, а не просто его наименование. А в реестре про этот момент ни слова. Поэтому не исключаю ситуацию, что через полгода-год возникнет ситуация, когда в реестре будет ПО с уже недействующим сертификатом соответствия или с сертификатом, выданным на предыдущую версию отечественного ПО.
Следующее требование. Если правообладателем является российская коммерческая или некоммерческая компания, то у нее должна быть лицензия ФСТЭК на разработку средств защиты информации. Тут на поверхности никаких косяков нет. Но это на поверхности. Этот пункт, особенно в контексте, грядущего изменения требований к лицензиатам, ставит крест на попытках отечественных стартапов попасть в реестр. Без системы менеджмента качества по ISO 9000 и внедренного (и подтвержденного) SDLC получить лицензию будет нельзя, а без лицензии нельзя попасть в реестр. Внедрять ISO 9000 и SDLC стартапу не по карману, так как у них нет еще достаточного количества клиентов и денег на развитие такой темы. А получить новых клиентов они не могут, так как в госорганы (более половины российского рынка ИБ) им путь закрыт. Замкнутый круг. То есть все красивые слова о развитии инноваций и стартапов в России опять оказываются пустым звуком. Стартапы так и будут ориентироваться на западный рынок, а российский будет поделен среди десятка ИБ-игроков, которые и сейчас чувствуют себя неплохо, не особо и нуждаясь в каких-либо преференциях.
Но с требованием лицензии ФСТЭК (кстати, опять забыта лицензия ФСБ на разработку средств шифрования, которым, видимо путь в реестр закрыт сознательно) связан и еще один момент, на который некоторые специалисты не обращают внимание, возможно сознательно. Представьте, что права на "отечественное" ПО зарегистрированы не на российское юрлицо, а на физлицо (как это иногда утверждают представители имеющих российские корни компаний, которые уже давно ушли на западные рынки). Тогда, по тому же ПП-1236, у этого физлица должна быть лицензия ФСТЭК. А много ли таких физлиц вы видели? Я - ни одного. Фактически, получается, что гражданин России не может быть правообладателем ПО, выполняющего функции защиты информации. А если ПО зарегистрировано на него, то... оно формально не может быть внесено в реестр (у физлиц же нет лицензии ФСТЭК).
Дальше ПП-1236 описывает процедуру подачи заявления на включение в реестр, из которой я бы хотел отметить только один момент - заявление должно быть подписано усиленной квалифицированной электронной подписью. А получение этой подписи для недавно образованного стартапа та еще "Одиссея". Очередной камень преткновения на пути молодых предпринимателей на отечественный рынок ИБ.
Еще один нюанс мне бы хотелось отметить применительно к классификатору ПО, который приведен в приложении к методичке Минкомсвязи по заполнению заявления на включение ПО в реестр. В нем по нашей теме приводится (впрямую) всего два типа ПО - "средства обеспечения ИБ" и "средства анализа исходного кода на закладки и уязвимости". Вот почему именно такое деление? Почему сканеры исходного кода вынесены в отдельную категорию, а сканеры уязвимостей нет? Тут у меня, конечно, есть подозрения, учитывая активное участие некоторых коллег в формировании всего пакета нормативных документов, но пусть эти подозрения останутся со мной.
В заключение у меня остается два вопроса, которые я задам вслух, но ответы на которые я жду увидеть в самом ближайшем будущем:
- Как быть с облачными сервисами, например, с анти-DDoS? С одной стороны в классификаторе ПО есть такой пункт как "средства обеспечения облачных и распределенных вычислений", а с другой, видно, что реестр заточен именно на классическое понимание софта, как отчуждаемого на носителе или получаемого по каналам связи экземпляра. Да и с сертификацией сервисов ИБ по документам ФСТЭК не все так просто. Тут скорее подходит аттестация, но про нее в ПП-1236 ни слова.
- Зарегистрируют ли как отечественное ПО антивирус от словацкой компании ESET?
24.2.16
Своя ИБ-игра: как это было
В декабре я уже писал, что на Уральском форуме по информационной безопасности я буду проводить Свою ИБ-игру, которая похожа на то, что показывали по НТВ, но полностью ориентированной на банковскую тематику. В итоге я ее все-таки сделал и провел в последний день форума.
В качестве платформы был выбран PowerPoint ввиду его распространенности и относительной простоты реализации (вся логика работы, подсчет очков, вопросы-аукцион были реализованы на макросах). Когда я эту игру в первый раз увидел у нас в штаб-квартире в ноябре прошлого года на конференции Cisco SecCon, то там это было реализовано руками наших программистов как Web-проект. Мне показалось это сложным и плохо отчуждаемым вариантом. В моем случае все гораздо проще - все внутри одного файла.
Самым сложным оказалось составить 60 разноплановых вопросов к игре. Но с другой стороны этот процесс был сам по себе интересным - я и сам узнал немало нового, когда составлял кандидатов на включение в список. Попутно наполнялся пул вопросов и по другим направлениям. Если в Магнитогорске я делал банковскую ИБ-игру, то сейчас у меня есть свой набор вопросов по криптографии и по технологиям безопасности Cisco. В принципе можно таких наборов сделать и еще несколько - более технических, более юридических или сфокусированных на какой-либо отрасли или компании. Пройдя уже один раз через, второй и последующие разы будут легче.
Чтобы стало понятно, как это все было устроено, записал небольшой ролик, показывающий и сам движок и некоторые вопросы, которые задавались на Уральском форуме 4-м командам - вендорам, интеграторам, банкирам и Центральному банку.
А вот и капитан команды-победителя - Лев Шумский :-) Шапочка на голове означала не только статус капитана, но и позволяла выделять одну команду от другой.
В качестве платформы был выбран PowerPoint ввиду его распространенности и относительной простоты реализации (вся логика работы, подсчет очков, вопросы-аукцион были реализованы на макросах). Когда я эту игру в первый раз увидел у нас в штаб-квартире в ноябре прошлого года на конференции Cisco SecCon, то там это было реализовано руками наших программистов как Web-проект. Мне показалось это сложным и плохо отчуждаемым вариантом. В моем случае все гораздо проще - все внутри одного файла.
Самым сложным оказалось составить 60 разноплановых вопросов к игре. Но с другой стороны этот процесс был сам по себе интересным - я и сам узнал немало нового, когда составлял кандидатов на включение в список. Попутно наполнялся пул вопросов и по другим направлениям. Если в Магнитогорске я делал банковскую ИБ-игру, то сейчас у меня есть свой набор вопросов по криптографии и по технологиям безопасности Cisco. В принципе можно таких наборов сделать и еще несколько - более технических, более юридических или сфокусированных на какой-либо отрасли или компании. Пройдя уже один раз через, второй и последующие разы будут легче.
Чтобы стало понятно, как это все было устроено, записал небольшой ролик, показывающий и сам движок и некоторые вопросы, которые задавались на Уральском форуме 4-м командам - вендорам, интеграторам, банкирам и Центральному банку.
А вот и капитан команды-победителя - Лев Шумский :-) Шапочка на голове означала не только статус капитана, но и позволяла выделять одну команду от другой.
 |
| Лев Шумский, капитан команды победителей |
20.2.16
Уральский форум за 15 минут (видео + презентация)
Вчера завершил свою работу Уральский форум по информационной безопасности... нет, не банков, а финансовых организаций. С этого года спектр организаций, которые на целую неделю попадают в реальную зиму, расширился за счет некредитных финансовых организаций, для которых на мероприятии был целый отдельный поток.
Я уже традиционно завершаю весь форум 15-тиминутным обзором ключевых новостей, мыслей и тезисов, прозвучавших в течение пяти дней деловой программы. В этот раз традиция тоже не была нарушена и в ночь с четверга на пятницу я сводил все в небольшую презентацию. Надо сразу сказать, что все в установленные рамки не вместилось. В итоге я сконцентрировался только на изменении регуляторики со стороны Банка России, ФСБ и Роскомнадзора (ФСТЭК в этом году не смог участвовать, но новостям ФСТЭК я посвятил предыдущие 6 заметок).
Первоначально я хотел выложить свою презентацию 24-го, в первый рабочий день после праздников, но так получилось, что организаторы (Авангард-Про) записали мой доклад и, что самое важное, выложили эту запись на Youtube. Поэтому не стану дожидаться среды и выложу тут эту запись.
А так как в данной записи не очень хорошо видно текст презентации на экране, то прикладываю и саму презентацию.
ЗЫ. Ощущения и впечатления от форума, а также другую свою презентацию и демки с практического дня я выложу позже.
Я уже традиционно завершаю весь форум 15-тиминутным обзором ключевых новостей, мыслей и тезисов, прозвучавших в течение пяти дней деловой программы. В этот раз традиция тоже не была нарушена и в ночь с четверга на пятницу я сводил все в небольшую презентацию. Надо сразу сказать, что все в установленные рамки не вместилось. В итоге я сконцентрировался только на изменении регуляторики со стороны Банка России, ФСБ и Роскомнадзора (ФСТЭК в этом году не смог участвовать, но новостям ФСТЭК я посвятил предыдущие 6 заметок).
Первоначально я хотел выложить свою презентацию 24-го, в первый рабочий день после праздников, но так получилось, что организаторы (Авангард-Про) записали мой доклад и, что самое важное, выложили эту запись на Youtube. Поэтому не стану дожидаться среды и выложу тут эту запись.
А так как в данной записи не очень хорошо видно текст презентации на экране, то прикладываю и саму презентацию.
ЗЫ. Ощущения и впечатления от форума, а также другую свою презентацию и демки с практического дня я выложу позже.
17.2.16
Конференция ФСТЭК: банк данных угроз и уязвимостей
Еще одним интересным докладом на конференции ФСТЭК оказалось выступление Владимира Минакова из воронежского ГНИИ ПТЗИ, который рассказывал о том, что из себя сегодня представляет банк данных угроз и уязвимостей, разработку и ведение которого поручено ФСТЭК России.
За прошедший с прошлой конференции год БДУ сильно изменился - добавилось 20 новых угроз и около 3000 тысяч уязвимостей, общее число которых составило соответственно 182 и 13052 (на 25-е января).
Представитель Воронежа сделал очень недурной обзор существующих в мире баз уязвимостей угроз и уязвимостей. Я не буду его повторять - отмечу только два момента. На фоне многих других баз уязвимостей ФСТЭКовская выглядит очень и очень достойно. И это всего за один год ее работы. А вот в части угроз мне не совсем понятно оказалось исключение из списка сравнения американской базы CAPEC - по сути она схожа с тем, что делает наш регулятор.
В части развития ФСТЭК видит несколько направления приложения своих сил:
В части функционала самого банка данных ФСТЭК вместе с ГНИИ ПТЗИ планирует сделать тоже немало и, в частности, подписку на обновления БДУ, описание небезопасных конструкций кода (в контексте SDLC), "личный кабинет" для формирования собственного профиля интересующих уязвимостей и ряд других новшеств.
Я в своей презентации про моделирование угроз в UEFI и BIOS приводил на последнем слайде скриншот разработанного в Cisco внутреннего инструментария по моделированию угроз, который позволяет автоматизировать непростую задачу и дать аналитику возможность отрисовать схему анализируемого объекта защиты и подгрузить в нее данные об уязвимостях, угрозах и мерах защиты из внешних и внутренних баз данных. Этакая экспертная система, задача которой - снизить вероятность ошибки и автоматизировать процесс, что приведет к оперативному составлению качественных моделей угроз. Вот если бы ФСТЭК запланировала создание такого инструмента - в виде Web-инструмента или в виде open source проекта. Цены бы ему не было.
ЗЫ. Пожалуй, это все, что я хотел рассказать про мероприятие ФСТЭК. Про аккредитацию я писать не буду. Про новые требования к лицензиатам я уже высказывался. Выступления других участников - лицензиатов ФСТЭК - пересказать не могу, так как убежал. В любом случае все материалы выложены на сайте организатора или вот тут.
За прошедший с прошлой конференции год БДУ сильно изменился - добавилось 20 новых угроз и около 3000 тысяч уязвимостей, общее число которых составило соответственно 182 и 13052 (на 25-е января).
Представитель Воронежа сделал очень недурной обзор существующих в мире баз уязвимостей угроз и уязвимостей. Я не буду его повторять - отмечу только два момента. На фоне многих других баз уязвимостей ФСТЭКовская выглядит очень и очень достойно. И это всего за один год ее работы. А вот в части угроз мне не совсем понятно оказалось исключение из списка сравнения американской базы CAPEC - по сути она схожа с тем, что делает наш регулятор.
В части развития ФСТЭК видит несколько направления приложения своих сил:
- расширение числа угроз (порядка 140 еще находятся на стадии рассмотрения) и уязвимостей
- введение разных классификаций угроз и уязвимостей для облегчения поиска по ним и фильтрации
- связь с CVSS 3.0
- включение поля "дата устранения уязвимости" для каждой из полутора десятков тысяч дыр
- описание уязвимостей на языке OVAL
- описание способа нейтрализации уязвимости
- активизация поиска уязвимостей в отечественном, а не только в западном ПО.
В части функционала самого банка данных ФСТЭК вместе с ГНИИ ПТЗИ планирует сделать тоже немало и, в частности, подписку на обновления БДУ, описание небезопасных конструкций кода (в контексте SDLC), "личный кабинет" для формирования собственного профиля интересующих уязвимостей и ряд других новшеств.
Я в своей презентации про моделирование угроз в UEFI и BIOS приводил на последнем слайде скриншот разработанного в Cisco внутреннего инструментария по моделированию угроз, который позволяет автоматизировать непростую задачу и дать аналитику возможность отрисовать схему анализируемого объекта защиты и подгрузить в нее данные об уязвимостях, угрозах и мерах защиты из внешних и внутренних баз данных. Этакая экспертная система, задача которой - снизить вероятность ошибки и автоматизировать процесс, что приведет к оперативному составлению качественных моделей угроз. Вот если бы ФСТЭК запланировала создание такого инструмента - в виде Web-инструмента или в виде open source проекта. Цены бы ему не было.
ЗЫ. Пожалуй, это все, что я хотел рассказать про мероприятие ФСТЭК. Про аккредитацию я писать не буду. Про новые требования к лицензиатам я уже высказывался. Выступления других участников - лицензиатов ФСТЭК - пересказать не могу, так как убежал. В любом случае все материалы выложены на сайте организатора или вот тут.
Конференция ФСТЭК: АСУ ТП, ГОСТы, методички, моделирование угроз, сертификация
Среди других документов, которые готовит ФСТЭК стоит отметить новую методичку по 31-му приказу, которая раскроет, что скрывается за многими, не всегда понятными защитными мерами для промышленных сетей. Это будет полный аналог методического документы "Меры защиты информации в государственных информационных системах", который был выпущен в дополнение к 17-му приказу. ФСТЭК называет срок - конец 2016-го года, но я побуду пессимистом и предположу, что это будет скорее первый квартал 2017-го года (все-таки при нехватке ресурсов, ФСТЭК не потянет все свои планы и обязательно что-то да передвинет).
В контексте национальной стандартизации хочется отметить следующее:
Тоже касается и включения соответствующих разделов в документацию для пользователей:
В контексте национальной стандартизации хочется отметить следующее:
- В 2015-м году было утверждено два новых ГОСТа (56545 и 56546) по классификации и описанию уязвимостей.
- В Росстандарт направлены два разработанных ГОСТа - по безопасности технологий виртуализации и по безопасной разработке ПО (SDLC). После утверждения первого ГОСТа ФСТЭК будет принимать требования к средствам защиты виртуализации. Второй ГОСТ возможно со временем станет обязательным - пока же он будет носить рекомендательный характер.
- Подготовлены к направлению в Росстандарт еще два ГОСТа - по разработке профилей защиты и заданий по безопасности и по анализу уязвимостей. Последний, в свою очередь, состоит из двух частей - по использованию доступных источников для идентификации потенциальных уязвимостей и по тестированию на проникновению (пентестам).
Кстати, по анализу уязвимостей ФСТЭК готовит еще один, безусловно интересный документ - методику анализа уязвимостей и недекларированных возможностей программного обеспечения. Это давно назревший документ, который позволит проводить анализ на отсутствие НДВ даже при отсутствии исходных кодов устаревшего ПО или ПО, происходящего из других государств.
Из важного: ФСТЭК планомерно добивается того, чтобы заявители на сертификацию включали в документацию на свою продукцию требования по порядку обновления и информирования потребителей об обновлении и способах его получения. То, что так усложняло жизнь многим заказчикам, которые не знали, где взять сертифицированные обновления, теперь постепенно сходит на нет. ФСТЭК на конференции несколько раз повторил, что они будут сильно "драть" заявителей, не соблюдающих эти правила.
Тоже касается и включения соответствующих разделов в документацию для пользователей:
Что касается методички по моделированию угроз, то я уже про него высказывался. Виталий Сергеевич Лютиков назвал срок - конец марта 2016-го года. Стоит подождать.
16.2.16
Конференция ФСТЭК: новые требования к средствам защиты
Вспомните вот эту картинку:
Она была представлена на конференции ФСТЭК в феврале 2015-го года, то есть ровно год назад. А теперь посмотрите вот на эту картинку:
Она была представлена в одном из выступлений ФСТЭК осенью 2015-го года. Прошло всего полгода, а какие изменения произошли в ней - на первые два места вышли требования к операционным системам и системам управления базам данных.
А вот картинка уже этого года. Из списка исчезли требования к средствам разграничения доступа (управление доступом осталось), средствам ограничения программной среды и средствам контроля целостности. При этом добавились требования к... фанфары, SIEM.
Значит ли это, что ФСТЭК отказалась от упомянутых выше РД? Нет! Я еще раз напомню, что задачей ФСТЭК, озвученной несколько лет назад, является выпуск требований, закрывающих все меры защиты, упомянутые в 17/21/31-м приказах и которые могут быть закрыты именно техническими решениями. Просто у регулятора по ходу работы меняются приоритеты и не всегда хватает ресурсов на то, чтобы выпустить все и в озвученные ранее сроки. Например, в списке отсутствуют требования к промышленным антивирусам, а они уже в проекте есть. Так и со всеми другими требованиями - они в проектах той или иной степени готовности есть почти по всем направлениям. Но рассылаться по экспертам для оценки они будут позже, по мере утверждения более приоритетных документов.
В Facebook по данному слайду были комментарии, что ФСТЭК физически не успеет к 1-му марта выложить на сайт для общественного обсуждения проекты РД по ОС и СУБД. Ну так этого и не планируется. ФСТЭК вообще проекты РД к средствам защиты в публичный доступ не выкладывает - они доступны только заявителям, разработчикам (не всем) и испытательным лабораториям. Вот к 1-му марта именно от них планируется получить замечания, принять или нет, и утвердить финальную версию.
Она была представлена на конференции ФСТЭК в феврале 2015-го года, то есть ровно год назад. А теперь посмотрите вот на эту картинку:
Она была представлена в одном из выступлений ФСТЭК осенью 2015-го года. Прошло всего полгода, а какие изменения произошли в ней - на первые два места вышли требования к операционным системам и системам управления базам данных.
А вот картинка уже этого года. Из списка исчезли требования к средствам разграничения доступа (управление доступом осталось), средствам ограничения программной среды и средствам контроля целостности. При этом добавились требования к... фанфары, SIEM.
Значит ли это, что ФСТЭК отказалась от упомянутых выше РД? Нет! Я еще раз напомню, что задачей ФСТЭК, озвученной несколько лет назад, является выпуск требований, закрывающих все меры защиты, упомянутые в 17/21/31-м приказах и которые могут быть закрыты именно техническими решениями. Просто у регулятора по ходу работы меняются приоритеты и не всегда хватает ресурсов на то, чтобы выпустить все и в озвученные ранее сроки. Например, в списке отсутствуют требования к промышленным антивирусам, а они уже в проекте есть. Так и со всеми другими требованиями - они в проектах той или иной степени готовности есть почти по всем направлениям. Но рассылаться по экспертам для оценки они будут позже, по мере утверждения более приоритетных документов.
В Facebook по данному слайду были комментарии, что ФСТЭК физически не успеет к 1-му марта выложить на сайт для общественного обсуждения проекты РД по ОС и СУБД. Ну так этого и не планируется. ФСТЭК вообще проекты РД к средствам защиты в публичный доступ не выкладывает - они доступны только заявителям, разработчикам (не всем) и испытательным лабораториям. Вот к 1-му марта именно от них планируется получить замечания, принять или нет, и утвердить финальную версию.
Конференция ФСТЭК: межсетевые экраны
Судя по статистике ФСТЭК - межсетевые экраны являются самыми распространенными сертифицированными средствами защиты информации в России - они составляют четверть от общего числа. Поэтому неслучайно, что ФСТЭК решила обновить давно необновляемые (с 97-го года) требования к МСЭ. Приказом №9 от 9 февраля 2016 года были утверждены новые требования к ним, которые начнут применяться с 1-го декабря 2016-го года. Это, пожалуй, первый пример, когда ФСТЭК обновляет (хотя правильнее было бы сказать “переписывает”) ранее выпущенный РД с требованиями к средствам защиты. Пока такой чести не удостоился ни РД на АС (и врядли удостоится), ни РД на СВТ, ни РД на НДВ (а вот это стоит ожидать).
Что обновилось в новом документе? На самом деле все, но я бы выделил несколько ключевых моментов:
На очевидно возникший вопрос о действии уже выданных сертификатов ФСТЭК здраво отмечает, что закон обратной силы не имеет и уже используемые МСЭ можно продолжать использовать - пересертифицировать ничего не надо. Как минимум, до окончания срока действия сертификата. Да и после, если среда и условия функционирования не менялись, - тоже.
Документ ушел на регистрацию в Минюст, а сами профили и типовые методики тестирования, дополняющие данный документ, находятся в финальной стадии разработки (их согласовывать ни с кем не надо).
Что обновилось в новом документе? На самом деле все, но я бы выделил несколько ключевых моментов:
- Число классов защищенности МСЭ стало 3 для гостайны и 3 для обычных информационных систем (вместо 5-ти по прежнему РД на МСЭ). Мотивация такого изменения проста - на 5-й и 1-й классы мало кто сертифицировался (да и на 2-й было всего несколько решений). Да и классов защищенности ГИС и АСУ ТП три и поэтому соотносить их с классами МСЭ гораздо проще.
- Вместо плоской классификации сетевых МСЭ ФСТЭК ввела еще один критерий классификации - тип МСЭ. Выделяется 5 типов - А (уровень сети), Б (уровня логических границ сети), В (уровень узла), Г (уровень Web-сервера) и Д (промышленные МСЭ). Деление между ними достаточно простое, МСЭ типа А - это периметровая железка (только железка). Б - это аппаратный или виртуальный МСЭ, который может стоять только внутри сети. Если вы хотите поставить виртуальный МСЭ на периметре, то на сертификацию надо будет подавать комплекс - виртуальный МСЭ + аппаратная платформа, на которой он работает. Тип В очевидно размещается на защищаемых узлах и по версии ФСТЭК может иметь только программное исполнение. Что делать с МСЭ в сетевых картах не совсем понятно, но таких решений не так уж и много на рынке. Тип Г - это обычные WAF (Web Application Firewall), которые так популярны у отечественных стартаперов (PT WAF, Wallarm, Tempesta FW). Тут ФСТЭК, на мой взгляд, допустила промашку - совершенно выпал из ввиду такой класс МСЭ, как NGFW. Либо именно его надо было делать типом В, либо не выносить WAF в отдельный класс. В принципе, я понимаю мотивацию ФСТЭК, но со стороны это выглядит не совсем логично. Можно попробовать NGFW сертифицировать как МСЭ типа А или Б, но время покажет, насколько это будет адекватно.
- Помните, я писал про проект документа ФСТЭК, который так и не увидел свет, и в котором говорилось о том, что средства защиты должны оцениваться с трех точек зрения - функционал, среда функционирования и требования к разработке (уровни доверия). В новом РД все эти пункты нашли свое отражение. Во первых были усилены основные, функциональные требования к МСЭ.
- Коренным образом были переработаны и расширены требования к доверию. Учитывая, что львиная доля МСЭ на российском рынке разработаны не в России, а эксалация киберугроз все нарастает и нарастает, регулятору ничего не остается как усиливать контроль за процессом разработки, поставки, обновления межсетевого экрана.
- Обратите внимание, что и в данном документе ФСТЭК не смогла пропустить раздел про анализ уязвимостей. Регулятор требует выстроить процесс обнаружения и устранения уязвимостей в подаваемом на сертификацию изделии. Как представитель разработчика самых популярных в мире и России (что доказывает статистика продаж в мире и в России) межсетевых экранов, могу сказать, что уже сейчас при согласовании документов на сертификацию этой теме уделяется огромное внимание и без данного раздела продукт на сертификацию просто не принимается.
- Также не принимается на оценку соответствия МСЭ, для которого не расписана процедура его обновления - устранения уязвимостей, установки патчей, обновления ядра системы защиты и т.п.
Документ ушел на регистрацию в Минюст, а сами профили и типовые методики тестирования, дополняющие данный документ, находятся в финальной стадии разработки (их согласовывать ни с кем не надо).
Подписаться на:
Сообщения (Atom)
