tag:blogger.com,1999:blog-40657706934991153142024-03-18T08:42:34.358+03:00Бизнес без опасностиБизнес безопасности или безопасность бизнеса? О том и о другом в одном непросветительском блоге от еще неиностранного агента... Имеющий мозг да применит его (6+)Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.comBlogger2737125tag:blogger.com,1999:blog-4065770693499115314.post-47894007202008466592021-11-30T00:53:00.004+03:002021-11-30T00:53:45.698+03:00Блог переезжает на новый домен - lukatsky.ru<p>Месячник молчания закончен - спешу сообщить, что блог переехал на новый домен - <a href="https://lukatsky.ru">lukatsky.ru</a>, где мы с вами и встретимся :-)</p><p> </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggc3g5_tzGGVRUmy_ubB_34Ryqe6A8Wo2v8emSchtc5A2uNWQZnU_O5Efsux92FUAuKPgLolrE0QHnQFZ-lf4mq1b4MweC4fMOsREnqdpaGHBsNGLTjVXwhshn1lgaAMddUGiZ-3Dw9syh/s700/lukatsky5.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="700" data-original-width="526" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEggc3g5_tzGGVRUmy_ubB_34Ryqe6A8Wo2v8emSchtc5A2uNWQZnU_O5Efsux92FUAuKPgLolrE0QHnQFZ-lf4mq1b4MweC4fMOsREnqdpaGHBsNGLTjVXwhshn1lgaAMddUGiZ-3Dw9syh/s320/lukatsky5.png" width="240" /></a></div><br /><p></p><p>Тут всем пока, а там всем привет! И с международным днем защиты информации!!! </p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com2tag:blogger.com,1999:blog-4065770693499115314.post-63956451122512542972021-10-27T05:52:00.000+03:002021-10-27T05:52:00.293+03:00Куда падает качество нормативки наших регуляторов и что с этим делать?<p>Вы обращали внимание на снижение качества нормативных документов от наших регуляторов? Когда смотришь в сторону только одного регулятора или одной сферы регулирования это не так заметно. Но когда пропускаешь через себя творчество всех органов исполнительной власти, то это очень сильно бросается в глаза. И дело не столько в синтаксических или орфографических ошибках, сколько в большом числе нестыковок, неточных и непонятных формулировок, которые требуют разъяснений от их автора, которые, конечно же, никаких пояснений не дают.</p><p>Давайте к примерам? Возьмем методику оценки угроз ФСТЭК, утвержденную 5-го февраля <b>этого</b> года. ЭТОГО! Но уже известно, что регулятор готовит в нее поправки. Документу от силы было полгода, когда регулятор решил вносить в него изменения, которые, согласно публичным высказываниям регулятора, планируют утвердить в первом квартале уже следующего года. У Банка России такая же проблема. 716-П по рискам вступило в силу 1-го октября прошлого года, но уже готов проект с поправками в него на 30+ (!) страниц. Не это ли свидетельство того, что документ получился сложным для восприятия? Ну а как может быть иначе, когда у вас нормативный акт занимает 130 страниц и к нему еще готовится ГОСТ на 180 страниц. 300 страниц (!), которые можно было бы изложить на одной странице формата А4! И это только один пример - у ЦБ таких косяков просто масса (отдельный пост им посвящу). РКН со своим 1046-м Постановление Правительства по надзору в области персональных данных тоже накосячил - и в расширительном толковании отдельных терминов, и синтаксических ошибках. И это только три примера, которые достаточно свежие и от разных регуляторов, но их ведь гораздо больше. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhp8_HkEa6EWsG_oFrjSUu9EPILg_J085-SCS8CPOMBw3V2LDtONSPoXUcvrJ_tPAYVTTP5iONMVO_avJAuGa9JEPxqw4CO11zhq8SU-NC9ZwVKkNcozBPBZ0onk1oKxw-ZxzvqOmMA4QOs/s889/5rqph5.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="499" data-original-width="889" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhp8_HkEa6EWsG_oFrjSUu9EPILg_J085-SCS8CPOMBw3V2LDtONSPoXUcvrJ_tPAYVTTP5iONMVO_avJAuGa9JEPxqw4CO11zhq8SU-NC9ZwVKkNcozBPBZ0onk1oKxw-ZxzvqOmMA4QOs/s320/5rqph5.jpg" width="320" /></a></div><p>Как с этим бороться? На мой взгляд вариантов решения проблемы всего несколько. Первый - сформировать пул лояльных специалистов, которые не будут зависеть от регулятора, и через которых можно было бы пропускать проекты нормативки с обещанием принять всю критику и постараться ее исправить. Причем делать это адресно в обе стороны, а не так обезличенно, как это сейчас работает на regulations.gov.ru. Хотя где найти таких специалистов в достаточном количестве? Все же реально ссут сказать что-то супротив регулятора, от которого зависит сертификация выпускаемых твоей компанией продуктов или обновление/расширение лицензии или еще какие-то ништяки. Надо сказать, что это не совсем проблема регулятора, что у нас исторически все боятся сказать что-то против политики партии, но и его тоже - он же поощряет ее.</p><p>Второй вариант - при выходе каждого нормативного акта давать переходный период в 6-12 месяцев на его апробацию и без введения его в контур обязательных требований. Тогда первые желающие смогут попробовать что-то сделать, наступить на все грабли и сообщить о них регулятору, который внесет поправки в свои документы и выпустит уже гораздо более проработанный с точки зрения практики документ. Но и тут есть подводные камни. Не все захотят по доброй воле апробировать необязательные пока еще нормативные требования. А потом нужно время на повторную регистрацию документов в МинЮсте, что занимает много времени (сейчас доходит до шести месяцев). Ну и проблема "бесстрашных" рецензентов из предыдущего пункта тоже никуда не девается. </p><p>Можно попробовать пропустить документ через маленькие предприятия, в том числе поднадзорные, чтобы понять, насколько написанное реализуемо с малыми ресурсами. Такое замечание было очень частым после принятия ЦБшного ГОСТа 57580.1, который рассчитан на крупные финансовые организации, которые и принимали участие в его написании. Но и тут нас поджидают упомянутые ранее подводные камни.</p><p>Хорошей практикой является обучение. Есть высказывание, что когда начинаешь готовить материал для обучения и преподавать, то начинаешь лучше разбираться в вопросе (а почему я так активно преподаю, а?). А когда начинаешь рассказывать, что же ты имел ввиду в документе по 10 раз перед разными людьми, тогда лучше начинаешь понимать и область регулирования и свои корявые формулировки. Можно, конечно, сделать вариант-минимум - читать перед подчиненными, но они же правду в глаза не скажут все равно. Поэтому только публичная активность, но на это рассчитывать не приходится - не приучен у нас регулятор к публичной критике, а еще и отомстить может. </p><p>Пятый вариант заключается в том, чтобы попробовать сферического коня в вакууме в своем загоне, то есть в самом регуляторе. Вот выпустил ДИБ положение 716-П по рискам - так ты сначала его пропусти через своих ИТшников и ИБшников и посмотри, что они тебе скажут (ничего хорошего, кстати, не скажут). Вот выпустил ты методику по оценке угроз - так ты ее сначала на себе опробуй и выложи в качестве примера разработанный по методике документ. Причем обязательно, чтобы реализовывал нормативные требования не их автор, а лицо, которое впервые эти требования увидит.</p><p>Вот тогда у нас начнет реализовываться хотя бы один из озвученных вариантов, а лучше все вместе, тогда у нас качество документов сильно поднимется и претензий к регуляторам станет гораздо меньше. Если их, конечно, это волнует.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8OESLQM_zOImUkvx1qEs6OVm2CR5AkNKmG99uNjbScHsdhlFS5IrCTlJ8Yqkdgl5bc5T2lEt7-wuR30-tIQSYM2sFjLhedtMCVLnYMWaDLjeKEidOREoQ6e7Xp-0rTDasjmbRt4NfN3Re/s684/5rqqnx.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="500" data-original-width="684" height="234" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8OESLQM_zOImUkvx1qEs6OVm2CR5AkNKmG99uNjbScHsdhlFS5IrCTlJ8Yqkdgl5bc5T2lEt7-wuR30-tIQSYM2sFjLhedtMCVLnYMWaDLjeKEidOREoQ6e7Xp-0rTDasjmbRt4NfN3Re/s320/5rqqnx.jpg" width="320" /></a></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com5tag:blogger.com,1999:blog-4065770693499115314.post-47767547266729095672021-10-26T05:11:00.031+03:002021-10-26T05:11:00.252+03:00Моделирование угроз в процессе разработки ПО<p>Решил я тут раскрыть чуть больше краткую <a href="https://t.me/alukatsky/4680">заметку</a> в своем Telegram, посвященную моделированию угроз в процессе разработки ПО. Я написал следующее: "<i>Методика оценки угроз ФСТЭК не применяется при моделировании угроз в рамках безопасной разработки. Учитывая, что ФСТЭК уделяет последней очень много внимания, стоит ли ждать отдельного документа/стандарта по этому вопросу? Пока у меня нет ответа на этот вопрос, хотя появление ГОСТа по этой теме было бы логичным.</i></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTrVRXRKhj9w6oQem0UuaHkf2iw6br5d01yxVE5ujG_IY-GTDcxoytt3hieCHO0ZWzttFFYJ6yMHri6bZRxBoRxTKWdVA13VCk0_NVHZlL4yQgmTSwuQq_-b41OHg8OwLyHNiwf7Mzti4Q/s2048/matrix.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1084" data-original-width="2048" height="169" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTrVRXRKhj9w6oQem0UuaHkf2iw6br5d01yxVE5ujG_IY-GTDcxoytt3hieCHO0ZWzttFFYJ6yMHri6bZRxBoRxTKWdVA13VCk0_NVHZlL4yQgmTSwuQq_-b41OHg8OwLyHNiwf7Mzti4Q/s320/matrix.png" width="320" /></a></div><p><i>А пока можно использовать сторонние источники для моделирования угроз в рамках разработки:</i></p><p><i>- <a href="https://www.microsoft.com/en-us/securityengineering/sdl/threatmodeling">STRIDE</a> от Microsoft (и Threat Modeling Tool от них же)</i></p><p><i>- <a href="https://owasp.org/www-community/Threat_Modeling_Process">OWASP</a> - (и <a href="https://owasp.org/www-project-threat-dragon/">Threat Dragon Tool</a> от них же)</i></p><p><i>- <a href="https://github.com/rung/threat-matrix-cicd">Матрица угроз ATT&CK для CI/CD</a></i></p><p><i>- Инструмент <a href="https://github.com/secmerc/materialize_threats">Materialize Threats Tools</a></i></p><p><i>- <a href="https://github.com/threatspec/threatspec">threatspec</a></i></p><p><i>- <a href="https://github.com/devsecops/raindance">The Raindance Project</a></i></p><p><i>- <a href="https://github.com/izar/pytm">PyTM</a></i></p><p><i>- <a href="https://mal-lang.org">Meta Attack Language</a></i></p><p><i>- <a href="https://github.com/Threagile/threagile">Agile Threat Modeling Toolkit</a></i>"</p><p>Коллеги обратили мое внимание, что у ФСТЭК есть разделы в ГОСТах по безопасной разработке, посвященные моделированию угроз. И вот этот момент я бы и хотел прокомментировать. Если мы возьмем ГОСТ Р 56939 "Разработка безопасного ПО. Общие требования", то в разделе 5.2.1 говорится, что разработчик должен провести моделирование угроз, а в разделе 5.2.3.1 этот вопрос раскрывается чуть подробнее, но и в нем не приводится никакой методологии моделирования, а всего лишь уточняется, что она должна быть и что документация разработчика должна содержать описание выбранной методологии, список выявленных угроз и список мер, эти угрозы нейтрализующих.</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrzIMp26_Ca16Uk1nC_fcb367kNvL2MNNWl49JiwOVuG_kWi7RQS62u1Y31jQptbPfAQ3Fk3guAGnq4J7MML78GeQV3ObCYbQDsBkFkoZ1C7309UTCcST1hSE5oZtQadQcT6JxobfijeQ6/s2048/Screenshot+2021-10-26+at+00.01.20.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1323" data-original-width="2048" height="207" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrzIMp26_Ca16Uk1nC_fcb367kNvL2MNNWl49JiwOVuG_kWi7RQS62u1Y31jQptbPfAQ3Fk3guAGnq4J7MML78GeQV3ObCYbQDsBkFkoZ1C7309UTCcST1hSE5oZtQadQcT6JxobfijeQ6/s320/Screenshot+2021-10-26+at+00.01.20.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Эта процедура моделирования из методики Microsoft</td></tr></tbody></table><p>Список угроз можно найти в другом стандарте - ГОСТе Р 58412 "Разработка безопасного ПО. Угрозы безопасности информации при разработке ПО", в котором перечислено 19 угроз. Но в нем также нет методологии выбора из перечисленного перечня угроз актуальных. Да и сами угрозы достаточно высокоуровневы и хотелось бы иметь их большую детализацию. Например, огромный <a href="https://github.com/rung/threat-matrix-cicd">пласт угроз</a> для процесса CI/CD или угрозы, реализуемые через репозитории кода, объединяются в одну - угрозу внедрения уязвимостей программы из-за неверного использования инструментальных средств при разработке ПО. Лично мне не хватает в ГОСТ 58412 деталей, - тех же техник и тактик, которые есть в методике ФСТЭК, процедуры выбора угроз, примеров, то есть ровно того, что сделает документ практически полезным в работе.</p><p>А, например, угрозы при использовании API куда попадают в рамках упомянутого ГОСТа? А отсутствие шифрования или хотя бы хэширования паролей в разрабатываемых приложениях? А отсутствие контроля вводимых параметров? Или это не угроза, а уязвимость переполнения буфера (хотя SQL Injection это именно угроза)? А угрозы генерации неслучайных чисел в "датчиках случайных чисел"? А работа с памятью, позволяющая выполнять вредоносный код от имени привилегированных пользователей/процессов? А, в конце концов, нарушение правил контроля доступа, которое отвечает за 10 из 30 основных проблем безопасности ПО? Или такой уровень детализации не является предметом регулирования ГОСТ 58412? Вообще, хотелось бы видеть либо что-то аналогичное проекту <a href="http://capec.mitre.org">CAPEC</a> от MITRE (раз уж мы так активно используем концепции этой корпорации у нас), либо ссылку на возможность его использования в том же ГОСТе 58412 (рах уж мы ссылаемся на CAPEC в методике оценки угроз от 5-го февраля).</p><p>Главное, не забывать, что в методике важно иметь не только сам перечень угроз и процедуру их выбора, но и способ ранжирования актуальных угроз, которых может получиться немало и которые надо устранять не одним разом, а по частям. А вот в какой последовательности эти части будут формироваться нам подскажет методика ранжирования.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4mgnob6bVL57g_RD-WXziJtSiVnkcbe5fGtpLWGCFUs52TmWs-4AGdRsiClgO8cTuc33hHydraGarg5DRGZwIfuafKAHiqhxvVotH-Ome-_v97X5IiVeaSjPHe2w0C3MTxl1Q5aWFT68L/s2048/Screenshot+2021-10-26+at+00.05.24.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1151" data-original-width="2048" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4mgnob6bVL57g_RD-WXziJtSiVnkcbe5fGtpLWGCFUs52TmWs-4AGdRsiClgO8cTuc33hHydraGarg5DRGZwIfuafKAHiqhxvVotH-Ome-_v97X5IiVeaSjPHe2w0C3MTxl1Q5aWFT68L/s320/Screenshot+2021-10-26+at+00.05.24.png" width="320" /></a></div><p>Ее, кстати, нет и в текущей методике оценки угроз, что ставить нас перед непростой задачей - какую из актуальных угроз нейтрализовывать первой, какую второй, какую третьей и т.д. Ровно то, о чем я писал в июне, <a href="https://lukatsky.blogspot.com/2021/06/blog-post_29.html">рассказывая</a> о методике TARA той же MITRE. А применительно к моделированию угроз в рамках безопасной разработке за основу такого метода ранжирования можно взять DREAD от Microsoft, а можно и что-то другое.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTQ6CxwjSNOc2S_dSCgRdI1GeK5JLiknE8KZRT1ZxkCR7L0KFntrgrLjAW0M_x_xFnTGiy1uJTf03wM-qKYoVdg74eJuRPy_F3do8AhcDncwRTdlyUGhYj1NelE9Fgd4BEKKqeFFAY0dzr/s2048/Screenshot+2021-10-26+at+00.05.49.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1152" data-original-width="2048" height="180" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTQ6CxwjSNOc2S_dSCgRdI1GeK5JLiknE8KZRT1ZxkCR7L0KFntrgrLjAW0M_x_xFnTGiy1uJTf03wM-qKYoVdg74eJuRPy_F3do8AhcDncwRTdlyUGhYj1NelE9Fgd4BEKKqeFFAY0dzr/s320/Screenshot+2021-10-26+at+00.05.49.png" width="320" /></a></div><p>А пока я остаюсь при своем мнении относительно того, что пока у нас нет методики оценки угроз в рамках процесса безопасной разработки. Но именно что пока...</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com14tag:blogger.com,1999:blog-4065770693499115314.post-2984334545367899632021-09-30T05:50:00.001+03:002021-09-30T05:50:00.257+03:00Как может s-curve'иться CISO?<p>Последний круглый стол на конференции “Кибербезопасность нового времени” в рамках казанской DigitalWeek оказался мне ближе всех, так как обсуждаемая на нем тема интересует меня давно и мой блог по сути и начинался скоро уже 15 лет как именно с нее, а именно с бизнес-ориентации в деятельности службы ИБ. Это постоянная тема дискуссий последних пару лет и без нее не обходится ни одно мероприятие. Должен ли CISO заниматься только ИБ в классическом его понимании (борьба с угрозами и выполнение требований регуляторов) или ИБ - это более широкая тема и CISO может и должен выходить за привычный, но достаточно узкий мир нарушителей и compliance. В этой дискуссии, так уж случилось, участвовали только представители финансовой отрасли:</p><p></p><ul style="text-align: left;"><li>Яшкин Вячеслав - Управляющий директор Аппарата Правления ПАО «АК БАРС» БАНК</li><li>Титков Константин, Исполнительный директор Департамента защиты информации Газпромбанк</li><li>Демидов Сергей - Директор департамента операционных рисков, информационной безопасности и непрерывности бизнеса, Московская биржа</li><li>Волков Олег, начальник Департамента кибербезопасности ПАО "Банк ЗЕНИТ".</li></ul><p></p>
<p>Но несмотря на это озвученные ими примеры могут быть применены не только там, а гораздо шире. Одним из таких примеров стали кадровые риски, в снижении которых ИБ может принять самое непосредственное участие и дело тут не только в том, чтобы заниматься повышением осведомленности персонала или поиском инсайдеров внутри компании, помогая экономической безопасности (хотя это тоже вполне себе интересный кейс, выходящий за рамки классической ИБ). Уже набивший оскомину пример с обнаружением работников, готовящихся к увольнению. Да, этот сценарий требует определенных условий для срабатывания (сотрудник должен пользоваться корпоративными устройствами для доступа на сайты для поиска работы, рассылку резюме или получение предложений о работе), но он вполне себе укладывается в возможности ИБ, имеющей весь необходимый инструментарий для того, чтобы оперативно обнаруживать тех, кто готов пойти на сторону. Возможно менее этичный, но недавно активно обсуждаемый кейс, - это анализ активности работника и предоставление кадрам и начальству данных об активности сотрудника и том, работает он вообще или балду гоняет. И вот тут закономерно развернулась некоторая дискуссия. Одни высказывались в пользу того, что не дело ИБ следить за тем, как тратится рабочее время компании. Другие говорили, а почему бы и нет?</p>
<p>Как мне кажется, все будет зависеть от того, с какой позиции мы смотрим на эти примеры; с точки зрения функции или инструмента? Да, возможно слежение за рабочим времени - это не функция ИБ (что не мешает ИБ-вендорам активно допиливать свои решения именно для этой задачи). Но не стоит забывать, что ИБ - это не только функция, но и инструмент, который может быть использован и другими подразделениями для их задач. ИБ дает возможность, а уж применить ее или нет - дело другое. Поэтому в описанных выше двух случаях ИБ имеет инструмент, который может собрать данные, которые могут быть предоставлены кадрам. Если для компании удержание сотрудников и снижение ротации важны, то ИБ может помочь решить эту задачу (наряду с другими подразделениями). Если в компании руководство беспокоится о том, не бездельничают ли сотрудники за зарплату, то ИБ может помочь и тут (хотя контроль рабочего времени - это вообще отдельная тема, имеющая очень много граней и нюансов). </p>
<p>Другой пример бизнес-ориентированности CISO - снижение CapEx. Да, урезание бюджета - вещь неприятная, но встречающаяся достаточно часто. Можно жаловаться на жизнь, а можно попробовать извлечь из нее пользу и показать, что ИБ разделяет интересы компании, перейдя в части своих услуг с CapEx-ной модели на OpEx-ную, заменив “железные” решения на облачные, а внутренние сервисы передав на аутсорсинг. Да, это грозит потерей компетенций и снижением контроля, но на то мы и говорим с позиций бизнеса, что нужно взвешивать все за и против, всю плюсы и минусы, предлагая взвешенное решение и демонстрируя бизнес-ориентированность.
</p><p>А может ли ИБ зарабатывать? Такой вопрос тоже прозвучал на круглом столе и Сергей Демидов ответил на него положительно, хотя и не скажу, что озвученный им вариант подойдет многим. Сергей возглавляет небольшого оператора связи, работающего в интересах биржи, который помимо услуг связи предоставляет также услуги удостоверяющего центра, зарабатывая на них (есть и другие варианты, о которых говорится в видео по ссылке ниже). Да, это уже не совсем in-house функция, но все равно служит интересным примером того, как руководитель ИБ может выйти за пределы своих привычных задач. Я знаю пример финансовой организации, которая предлагает своим привилегированным клиентам, имеющим на счетах сумму, выше определенного значения, услуги по ИБ, в том числе и защиту бренда. В другом случае служба ИБ оказывает услуги своим клиентам из сегмента малого бизнеса, по сути выполняя для них роль сервис-провайдера по ИБ. Ведь малый бизнес не имеет возможности строить у себя нормальную ИБ. Почему бы тогда не возложить эту задачу на службу ИБ своего банка?</p>
<p>Если не заработок, то может ли ИБ влиять на прибыль компании? Надо отметить, что не слишком подкованные в финансах технари, часто путают прибыль и доход. Да, ИБ может не приносить дохода, но при этом влиять на снижение расходов, тем самым увеличивая прибыль предприятия. И дело не только и не столько в том, чтобы снижать стоимость инцидентов или предотвращать мошенничество, о чем мы тоже говорили. Например, можно существенно снизить затраты компании на отправку одноразовых кодов по SMS для входа в систему ДБО, если подумать о том, как обычно клиенты подключаются к своему онлайн-банкингу. Делается это обычно с одного и того же мобильного устройства, которое не меняется годами. Так зачем каждый раз спрашивать клиента “Это ты?”, если можно профилировать его устройство и в случае совпадения с профилем, считать устройство доверенным и не отвлекать пользователя смсками? Такой подход позволяет сократить 10-40% затрат на отправку SMS, что выливается при текущих расценках в кругленькую сумму. Заработок ли это? Нет. Влияет ли на прибыль? Безусловно. Интересно это бизнесу? Конечно. Об этом кейсе, кстати, можно послушать в "<a href="https://ib-bank.ru/soc-forum2021/#podcasts">свежевыжатом подкасте</a>", приуроченном к грядущему SOC Forum 2021, в котором моим гостем был Лев Шумский, глава кибербеза Яндекс.Банка (подкаст №2). </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgT_rViUaO5JybDANei3ovgDrfPXOJYtKfl-rk6Jtk3Qg2LZN0aouCprEzJDvR7zopSjBrU8uZMPaClHGQGW9a-gqElJZbIxmPw5ckNeWXN-svPR83ILV7RfPZ_mKrqPLf3ONOyKwwoPmjK/s709/142589_original.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="548" data-original-width="709" height="247" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgT_rViUaO5JybDANei3ovgDrfPXOJYtKfl-rk6Jtk3Qg2LZN0aouCprEzJDvR7zopSjBrU8uZMPaClHGQGW9a-gqElJZbIxmPw5ckNeWXN-svPR83ILV7RfPZ_mKrqPLf3ONOyKwwoPmjK/s320/142589_original.png" width="320" /></a></div>
<p>Но такая ориентация на бизнес требует от CISO новых навыков. Как было правильно отмечено на круглом столе - CISO может быть “военным” или “предпринимателем”. В первом случае он может отлично выполнять традиционные для ИБ задачи, но не выходить за их рамки. Во втором случае он ищет как помочь бизнесу с позиций предпринимателя. И у него это получается. И тогда у него появляется шанс вырасти за пределы обычного руководителя ИБ, “подмяв” под себя управление операционными рисками, непрерывность бизнеса, операционную надежность. Сергей Демидов упомянул концепцию S-кривых, которая описывает эволюцию многих технологий, многих компаний и даже людей. Сначала вы растете в своей роли, но в какой-то момент достигаете пика в развитии и у вас начинается движение по длительному плато, которое может в любой момент прерваться, так как вас обойдут более агрессивные, опытные, квалифицированные коллеги. Чтобы расти дальше вам надо выйти за пределы своей роли и сделать шаг в неизвестность, который может вывести вас на новый уровень, на новую кривую. И так далее. Для ибешника это означает, что он может начать свою карьеру как обычный сотрудник отдела защиты информации, занимаясь своей узкой сферой, развиваясь в ней. Следующим кардинально новым шагом может стать желание быть руководителем, что требует новых навыков и знаний. Проработав в этой роли, CISO может захотеть пойти еще выше и тут варианты его карьеры могут разойтись. Он может пойти в корпоративную безопасность, подмяв под себя темы экономической, физической, антитеррористической безопасности. А может пойти в сторону рисков и непрерывности бизнеса. И это очередной вызов, требующий новых знаний и навыков. А потом это может быть собственный бизнес и т.д.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2N897UtmIuc9zjZjXPyZdwpkwvcuf2mtcxbzVuMbzdbRBGHoXwIA7Kbl5EMrHroa2CCo0Zb5V0zXev_BOet6Wm5uoY7h_ObkcNh-fauD3XqE0OkwjELulPOrOfHMANp-20rDsodV403zI/s1440/IMG_3851.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="753" data-original-width="1440" height="167" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2N897UtmIuc9zjZjXPyZdwpkwvcuf2mtcxbzVuMbzdbRBGHoXwIA7Kbl5EMrHroa2CCo0Zb5V0zXev_BOet6Wm5uoY7h_ObkcNh-fauD3XqE0OkwjELulPOrOfHMANp-20rDsodV403zI/s320/IMG_3851.JPG" width="320" /></a></div><p>На круглом столе мы обсуждали еще многие темы, но я не хочу пересказывать абсолютно все и не буду раскрывать секрет, как связана деятельность CISO с движением Black Lives Matter или концепцией ответственного инвестирования ESG, о которой сегодня не говорит только ленивый и которая вроде как не имеет никакого отношения к ИБ, но оказывается, что имеет. А ESG - это повестка дня руководителей крупнейших мировых компаний. И если CISO может встроиться в эту повестку, то это отлично. Но об этом вы можете сами услышать, <a href="https://youtu.be/39uQthS6NC0?t=7724">посмотрев эфир</a>, любезно записанный компанией Innostage, которая и организовала этот и другие два круглых стола, которые я вел, ссылки на записи которых ниже, и о которых я писал последние заметки:</p><p></p><ul style="text-align: left;"><li><a href="https://youtu.be/XTUt7zDRYkM?t=3932">Запись</a> первого круглого стола, о котором я <a href="https://lukatsky.blogspot.com/2021/09/blog-post_23.html">писал</a></li><li><a href="https://youtu.be/XTUt7zDRYkM?t=11711">Запись</a> второго круглого стола, о котором я <a href="https://lukatsky.blogspot.com/2021/09/vs.html">писал</a></li><li><a href="https://youtu.be/39uQthS6NC0?t=7724">Запись</a> третьего круглого стола, о котором данная заметка.</li></ul><p></p><p></p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-74922190952372437122021-09-27T05:16:00.052+03:002021-09-27T05:16:00.195+03:00Круглый стол "Формальная безопасность vs практическая безопасность: как достичь синергии"<p>Вторым круглым столом на конференции "Кибербезопасность нового времени", проведенной Innostage в рамках казанской DigitalWeek, был "Формальная безопасность vs практическая безопасность: как достичь синергии", который получился не таким, как я его задумывал изначально, готовя вопросы. Поэтому в этой заметке я буду говорить не столько о самом круглом столе, сколько о том, во что вылилась дискуссия и что я про все это думаю.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5cjtOVxr00BN89fjlenv4ezf2LMXtL8uACISkGiGN1A6Rp-IjpqiP6l8L86VC0CDlftIf3avBhyGjundnKwqEo9EfopuPkOoGmEr55zIXL2qltusq64eZtfu6LBkoOI2XHZR9JGqtPwWv/s612/5o9dpn.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="408" data-original-width="612" height="213" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh5cjtOVxr00BN89fjlenv4ezf2LMXtL8uACISkGiGN1A6Rp-IjpqiP6l8L86VC0CDlftIf3avBhyGjundnKwqEo9EfopuPkOoGmEr55zIXL2qltusq64eZtfu6LBkoOI2XHZR9JGqtPwWv/s320/5o9dpn.jpg" width="320" /></a></div><p>На самом круглом столе немного предсказуемо почти все участники высказались в поддержку нормативных требований регуляторов, что, на мой взгляд, вполне объяснимо, - не любят у нас публично критиковать регулятора, так как последний этого не любит и может отыграться во время проверок или продления лицензий или еще как. Только Сергей Демидов из ММВБ высказал все (ну или почти все), что он думает про регулирование финансовой сферы и КИИ и про то, насколько подкованы регуляторы во многих практических вопросах. Интересно, что на вечерних посиделках (а Innostage славится своими неформальными мероприятиями - от автогонок до /censored/) многие представители госорганов гораздо более откровенны и высказывают все, что они думают о регуляторах и об их требованиях.</p><p>Возьмем к примеру уже полгода как принятую модель оценки угроз ФСТЭК. Я про это писал уже неоднократно, но даже сейчас меня регулярно удивляют "вести с полей". Например, во время согласования модели угроз (а это обязательное требования по 676-ПП для всех ГИС) одно из региональных управлений сначала долго отнекивалось и пыталось манкировать своими обязанностями, а потом предупредили, что все равно придется пересогласовывать, так как после разработки нового БДУ (банк данных угроз) потребуется пройти процедуру заново! Ну вот как так? Почему об этом нигде не говорится и зачем вообще тогда надо было принимать документ, который нормально и не применить и меньше через год надо повторять процедуру (а деньги где брать)?</p><p>Или вот еще история. В самом начале круглого стола, который проходил сразу после выступления Романа Чаплыгина из Positive Technologies об открытых стандартах по ИБ (лучших практиках, создаваемых сообществом), я задал вопрос в зал, сколько из них знает о профессиональном стандарте 12.004 "Специалист по обнаружению, предупреждению и ликвидации последствий компьютерных атак", который был утвержден в 2015 (!) году? Шесть лет назад! Было всего 3 поднятых руки! Всего три на зал из 150 человек. А все потому, что этот стандарт имеет пометку "для служебного пользования". Ну вот о каких открытых стандартах можно говорить, если регуляторы у нас так любят политику засекречения всего, даже списка навыков, которым должен обладать специалист по реагированию на инциденты ИБ? Но интересно не это, а то, что получить этот документ нереально. Если вы запросите его в Минтруде (захотите найти - спрашивайте в Минтруде приказ 1179н/дсп от 29.12.2015), вам откажут и пошлют в ФСБ. Запрос в ФСБ тоже закончится ничем - вас отправят в Минтруд. Вот такой замкнутый круг. А я напомню, что согласно ПП-584 от 27.06.2016 профстандарты являются обязательными к применению всем государственным и муниципальным учреждениям, фондам, а также предприятиям, компаниям и корпорациям, что принадлежат государственным либо муниципальным органам власти (на праве владения более чем 50% от уставного капитала).</p><p>Еще одна обсуждаемая на круглом столе тема - трактовки требований регуляторов. Это вообще боль; даже для самих регуляторов, в которых написание требований и их проверка - это часто разные подразделения. А тут еще приближенные к регуляторам компании, которые часто участвуют в разработке требований в составе рабочих групп. Представители этих компаний потом выступают на мероприятиях, в чатах, в соцсетях и выдают собственное мнение за позицию регулятора. Ну есть еще и просто эксперты, которые также по своему трактуют требования нормативных актов. И вот у нас уже 4 разных точки зрения на один документ. И как тут быть? Участники круглого стола, например, Виктор Вячеславов из Innostage, Шальнов Олег из Росэнергоатома или Александр Дубасов из ФГБУ ЦНИИОИЗ Минздрава, посоветовали общаться с регулятором, задавать ему вопросы. Но тут всплывает классическая история - лучше не светиться :-( Наши регуляторы любят при общении с народом задавать вопрос: "Представьтесь, пожалуста" или "Какую организацию вы представляете?" Ну и кто захочет отвечать на такой вопрос? Смельчаков мало. Вот и любят у нас все ждать, когда кто-то храбрый сам спросит регулятора, а потом выложит ответ в каком-нибудь чатике. А сам регулятор, не видя вопросов, считает, что все нормально. Или он видит вопросы с мест, но не хочет публично показывать, что он поторопился с каким-то требованием. Поэтому и информационные письма с разъяснениями он не часто выпускает, ограничиваясь короткими комментариями в узком кругу специалистов или на закрытых встречах. И те, кого на этих мероприятиях "за закрытыми дверями", нет, потом вынуждены слушать пересказы и играть в испорченный телефон.</p><p>А вот еще один классический вопрос: "Почему <регулятор> сам у себя не реализовал свои же требования?" Почему на сайте ФСТЭК в разделе "<a href="https://fstec.ru/obshchaya-informatsiya/gosudarstvennye-informatsionnye-sistemy">Государственные информационные системы</a>" написано, что у регулятора нет ни одной ГИС? Вы верите в это? Я лично нет. Особенно слыша ответы регулятора на мероприятиях по поводу того, что считать ГИС. Но тогда почему у самой ФСТЭК нет ни одной ГИС? А ОКИИ? ФСТЭК говорила на мероприятиях, что у них есть ОКИИ (научной деятельностью они же занимаются в том же Воронеже). Тогда почему они часто "плывут" на практических вопросах по 235/239-м приказам? А Банк России? ДИБ пишет кучу Пэшек, Ушек, ГОСТов, а потом их должны выполнять в том числе и другие подразделения ЦБ. И у них тоже немало вопросов к регуляторике, которую непонятно как выполнять на практике, так как она местами предельно неконкретна, расплывчата, а то и имеет двойственное/тройственное толкование. С ФСБ все проще - они по-моему до сих пор не имеют локальной сети и живут в мире автономных компьютеров, а обмениваются документами бумажными. В их мире их требования чуть ли не идеальны.</p><p>Еще одним выводом с круглого стола стало, что выполнение требований никак не гарантирует безопасности организации. Зачем тогда нужны требования, тем более обязательные? Не лучше ли превратить их в рекомендации? Особенно в условиях, когда отдельные регуляторы начинают пропагандировать риск-ориентированный подход, который, как известно, отличается от обязательных требований тем, что в нем мы сами определяем, что для нас опасно, а потом определяем, что мы будем с этим делать - принимать риски, перекладывать, уклоняться или снижать их. Такой подход, кстати, ФСТЭК реализует в ИСПДн и КИИ (для ГИС установлен минимальный, базовый набор требований по защите). А ЦБ, на гербе которого двуглавый орел, смотрящий одновременно в разные стороны, успешно реализует эту идею и в регулировании ИБ, одновременно устанавливая обязательные требования по ИБ в своих Пэшках и Ушках, а также обязывая оценивать риски и меры управления ими. Зачем мне управлять рисками, если все равно я обязан выполнять кучу требований?</p><p>Вот такой был круглый стол в Казани, который не ограничился только залом, а вышел за его пределы и дал возможность поговорить с участниками "не под камеру". А это всегда ценно.</p><p>ЗЫ. Мне кажется, что регуляторам надо выпускать свои документы тройками - сами требования, разъяснения к ним для тех, на кого требования распространяются, и методика их проверки (в идеале тоже публичная). Все три документа должны быть взаимоувязаны между собой. Тогда и проблем ни с их толкованием, ни выполнением, ни проверкой не будет (ну кроме редких ошибок и клинических идиотов). Прислушался бы кто-нибудь, а?!</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com2tag:blogger.com,1999:blog-4065770693499115314.post-54094449385647216822021-09-23T05:34:00.014+03:002021-09-23T05:34:00.297+03:00Подомнет ли большая пятерка ИБ-игроков российский рынок или когда выпи***т всех иностранцев с рынка?<p>Во вторник и среду довелось мне по приглашению моих друзей из компании Innostage посетить организованную ими конференцию по кибербезопасности в рамках более крупного ИТ-мероприятия DigitalWeek с участием Президента Татарстана, министра российской цифровизации и других не менее высоких чинов. Я не выступал, но зато вел три дискуссии, обзором которых и хочу поделиться в серии заметок. Первая из них называлась "Отстает ли российский рынок ИБ от западного?".</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgal8BXSaBREtpkH2FwaW4y6oHixonAtfA9QMotf8W7Yop643rH-JC-cQXWFUySQw1ivVBuXIayKt_xZkf39VmsaYuCAmiz0VkQvUEzUg_ukr1MTjv9R99FFmqqHQKHNgQOj5XFpjO38Pi0/s2048/IMG_3764.HEIC" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1536" data-original-width="2048" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgal8BXSaBREtpkH2FwaW4y6oHixonAtfA9QMotf8W7Yop643rH-JC-cQXWFUySQw1ivVBuXIayKt_xZkf39VmsaYuCAmiz0VkQvUEzUg_ukr1MTjv9R99FFmqqHQKHNgQOj5XFpjO38Pi0/s320/IMG_3764.HEIC" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Фрагмент ИТ-выставки</td></tr></tbody></table><br /><p>Началось все с провокационной просьбой в зал поднять руки тем, кто считает, что российские решения лучше или хотя бы не уступают по своим функциональным характеристиками и качеству иностранным аналогам. И чтобы вы думали? Всего одна рука в зале на 200 человек. Это достаточно показательная картина, на которой можно было и завершить круглый стол, так и не начав его, но мы не ищем легких путей и поэтому я стал мучать участников дискуссии вопросами о том, когда “иностранцам” в России укажут на дверь и что делать потребителю, которого заставляют мучаться, но есть кактус?</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxRGPevcosvR16NBZSZ96Z98cbMmck5fTOIAkUQNxKdXMNp4QVHucenIsHJ-8EWBUFlIFMScjlUMyvX5ucmuZfQOByJPelvlZCkzwAqoUYIs6PbmXx5Hadrd5x7cBDQZBhd_XTdL2p69QZ/s2048/IMG_3758.HEIC" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1536" data-original-width="2048" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxRGPevcosvR16NBZSZ96Z98cbMmck5fTOIAkUQNxKdXMNp4QVHucenIsHJ-8EWBUFlIFMScjlUMyvX5ucmuZfQOByJPelvlZCkzwAqoUYIs6PbmXx5Hadrd5x7cBDQZBhd_XTdL2p69QZ/s320/IMG_3758.HEIC" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Фото с предшествующей сессии про то, что ждет отрасль ИБ и ИТ через 3-5 лет </td></tr></tbody></table>
<p>Василий Дягилев (CheckPoint) высказал мысль, что российские игроки за последнее время сделали гигантский скачок и если еще три года назад никто всерьез их и не рассматривал, то уже в прошлом, пандемийном году они очень быстро перестроились под нужды рынка, а сейчас достаточно активно наступают на пятки иностранным игрокам. Тут я могу частично согласиться с этой позиций - с момента подготовки <a href="https://lukatsky.blogspot.com/2015/03/blog-post_6.html">моей презентации</a> о домотканных средствах защиты (вот <a href="https://lukatsky.blogspot.com/2016/07/blog-post_29.html">тут</a> я тоже про это писал) на российском рынке появились не только новые имена среди игроков, но и среди номенклатуры средств защиты. IRP, SOAR, DDP (обманки), THP (Threat Hunting), TIP (Threat Intelligence) и т.п. Да, пока многие из этих решений делают только свои первые шаги и аналогами их называть еще рано, но по крайней мере с точки зрения категорий решений они уже явно не пустуют, как это было еще несколько лет назад. Олег Шальнов из Концерна “Энергоатом” своей репликой подтвердил слова Василия и сказал даже больше - у них в Концерне произошло практически полное импортозамещение и в области информационной безопасности они используют практически 100% отечественных решений. Лично для меня это было удивительно слышать, так как буквально в этот же день на площадке ТНФ-2021 прошла сессия "Импортозамещение в ИТ: отечественные решения для нефтегазовой отрасли", на которой выступила с докладом Лилия Загородных, директор программ по рискам, импортозамещению и непрерывности деятельности Департамента информационных технологий, автоматизации и телекоммуникаций "Газпромнефти”. Она сообщила, что заявленный план перехода объектов КИИ на российское ПО и оборудование к 2023-2024 г. выглядит красиво, но нереалистично. "Как мне, как директору по импортозамещению перевести нефтянку на все российское ПО и оборудование? Это сложно. Для нефтяников в первую очередь приоритетом является безопасность. Я за импортозамещение и могла бы сказать, что мы это сделаем. Но я опасаюсь, что нет". Возможно в Газпромнефти и Энергоатоме разные ПО и железо, но я из практики тоже больше склоняюсь к позиции Лилии Загородных. Но вернемся к секции.</p>
<p>Владимир Бенгин (Минцифры), который отдувался за всех регуляторов, высказал очень здравую мысль о том, что импортозамещение должно быть умным, то есть не всех и не сразу, а только значимых объектов (уже немалое подспорье) и только по окончании срока амортизации (это из проекта Указа Президента по импортозамещению в КИИ). При этом субъект КИИ может и дальше использовать иностранные решения, если сможет обосновать соответствующей комиссии свое решение. При этом Владимир высказал мысль, что Минцифры против ухода иностранных игроков с российского рынка, так как у отечественных вендоров тогда пропадет не только пример, к которому можно стремиться, но и конкуренция, что приведет только к застою. Я целиком и полностью поддерживаю позицию Владимира и его министерства, но вот шаги, которые я вижу все-таки говорят о том, что государство в целом планомерно выдавливает “иностранцев” из страны, не предложим ничего взамен. Если государство думает, что иностранные игроки всеми конечностями будут жержаться за российский рынок и довольствооваться подачками, то это не так. И в тучные времена доля России в объеме бизнеса иностранных ИТ и ИБ-компаний составляла около 1%. По мере импортозамещения эта цифра будет снижаться и экономического смысла продолжать держать в стране мощные офисы, вкладываться в сертификацию (которая не дает никаких преференций и не позволяет попасть в нужные реестры), разработку и поддержку нет. Поэтому в какой-то момент времени крупные ИТ и ИБ компании могут просто развернуться и уйти из страны вслед за уже ушедшими небольшими игроками рынка.</p>
<p>Семирханов Мидхат (Forcepoint) добавил, что хороший (продаваемый) продукт, интересный не только в России, но и на Западе/Востоке, зависит не только и не столько от программистов, которые в России и правда хороши. Очень важную роль играет маркетинг и продажи, с чем у наших игроков наблюдается провал. Без них не то, что выходить к иностранным заказчикам бессмысленно (о том, что у вас классный продукт просто никто не узнает), но и в России и ее сателлитах о серьезном прорыве говорить не приходится. Ему вторил и Андрей Брызгин (Group-IB), упомянув клиентоориентированность как фундамент для развития бизнеса в ИБ-сфере. Тут, правда, и Владимир Бенгин. и Василий Дягилев отметили, что у российских игроков есть преимущество, так как они находятся ближе к клиентам и готовы быстрее реагировать на потребности рынка и заказчиков, реализуя фичи, которые у иностранцев нет и в ближайших релизах может и не появиться. Хватило бы денег на реализацию всех хотелок. Все-таки многие иностранные ИТ-монстры развивались на заказах от государства, что позволило им потом завоевать весь мир. Владимир Бенгин отметил, что наше государство тоже готово поддерживать ИТ-компании, хотя со своей стороны отмечу, что не каждый ИБ-игрок (особенно если он сервисный провайдер) может рассчитывать на помощь государства. Кроме того, пока о госзаказах речи нет и не факт, что они появятся в области ИБ. </p>
<p>Кстати, о сервисных провайдерах. Мидхат Семирханов несколько раз упоминал сервисную модель как некий тренд в мире и в России, но, как мне показалось, он так и не выразил до конца свою мысль, что если сервисный провайдер использует иностранные решения, то заказчик этого все равно не видит, получая готовый сервис от российской компании, что позволяет в целом обойти требование по импортозамещению. И насколько мне известно некоторое количество зарубежных ИБ-игроков прекрасно используют эту модель на практике (лайфхак для тех, кто ищет пути).</p>
<p>Пытаясь вовлечь зал в дискуссию, я задал еще один вопрос, - есть ли решения, которых им не хватает у российских игроков. Ответов не последовало, из чего я могу сделать вывод, что либо все участники просто стеснялись, либо они не используют российских решений и пока не рассматривают импортозамещение, поэтому и не знакомы с предложениями российских ИБ-вендоров (вариант, что их все устраивает я даже не рассматриваю). И только Андрей Иванов из компании Яндекс ответил на этот вопрос, сказав, что им не хватает высокопроизводительных МСЭ. средств шифрования для облачных сред. И это правда. Таких решений у нас действительно нет. И даже для необлачных их тоже нет. Я знаю, что даже регуляторы, навязывающие импортозамещение в России, по-прежнему используют иностранные решения у себя в ядре или в ЦОДах, не имея отечественных альтернатив или не рискуя их ставить у себя в инфраструктуре.</p>
<p>Продолжая тему поддержки государства хотел бы еще отметить негативный факт - если посмотреть на резидентов Сколково, которые являются реально стартапами, а не монстрами типа Инфовотча или Group-IB, то они либо умирают через год-другой, либо сразу ориентируются на западные рынки, просто не имея возможности найти в России свою аудиторию. Тут получается замкнутый круг, чтобы продать свои решения крупным заказчикам, надо быть в реестре Минцифры и Минпромторга и иметь сертификаты ФСТЭК или ФСБ. А чтобы получить эти сертификаты, надо потратить кучу денег на танцы с бубном и выполнение никому ненужных телодвижений или функций, которые еще и будут шоу-стоппером при выходе на зарубежные рынки. А чтобы потратить кучу денег - надо ее заработать. А чтобы заработать... В итоге у нас нет достаточного количества стартапов, как это происходит, например, в Китае, Корее, Израиле, Германии, Испании и, конечно, США. Я не успел задать этот вопрос, но есть мнение, что скоро в России останется только большая пятерка именно отечественных игроков по ИБ, а все остальные будут либо поглощены, либо вынуждены будут уйти с рынка.</p><p>Кстати, схожую мысль об укрупнении, но вокруг государственных компаний (Ростех, Ростелек, Сбер и т.п.) высказал и Мидхат Семирханов. Владимир Бенгин, как представитель государства, что интересно, высказался против такого огосударствления рынка ИБ, так как это приведет к его выхолащиванию. Посмотрим, кто будет прав на горизонте в 3-5 лет, а именно такой временной отрезок рассматривался на секции до “моей”, где представители Positive Technologies и Касперского высказали мысль, что у российских игроков все прекрасно, много перспектив, на Западе много денег и скоро отечественные ИБ-компании (которые еще останутся не под санкциями) завоюют весь мир. Мне понравился такой оптимизм, хотя, как мне кажется, коллеги, высказавшие эти мысли, не учитывают один простой факт. Китаю мы нафиг не сдались - у них игроков гораздо больше и иностранцев они не жалуют. А вот западный мир, живущий по христианскому принципу “око за око”, будут ставить такие же заградительные препоны (уже ставят), как это делается и в России. Причем, я не буду спорить о том, кто “первый начал”, но факт есть факт. Нас там никто не ждет и примеров действительно успешной экспансии на иностранные рынки, особенно в последние 4-6 лет (после реализации непреодолимого желания Крыма влиться в состав нашей необъятной Родины) я сейчас и не вспомню. Есть отдельные попытки выйти на рынки Средней Азии и Ближнего Востока, есть примеры поставок в страны Южной Америки и даже Африки, но победоносным шествием это пока назвать нельзя; так, скорее пробираемся огородами. Приводить в пример Касперского не стоит - он это делал задолго до геополитических баталий и объявления России врагом №2 (после Китая) почти во всех прогрессивных странах. После этого, успехом пока хвастаться некому. Разве что Group-IB, которая сменила прописку и штаб-квартиру с России на Сингапур. Но пока оценивать ее успехи и насколько она будет продолжать называть себя российской рановато.</p>
<p>В целом, если подводить итог часовой дискуссии, я бы отметил, что перспективы есть у всех сторон - у государства не накосячить, у иностранцев - не уйти с рынка, у российских вендоров - сделать действительно востребованные потребителями продукты, а не только закрывающие регулятивные требования. А пока мы находимся в позе Ван Дамма, раскорячившегося между двумя грузовиками, - либо удержимся, либо е*немся и тогда будет больно.</p>
<p>ЗЫ. Кстати, в заголовке использовалось слово “выпихнут”, а не то, что вы подумали.
</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com2tag:blogger.com,1999:blog-4065770693499115314.post-54219031857148405072021-09-13T05:40:00.013+03:002021-09-13T05:40:00.232+03:00Перевод MITRE ATT&CK и ее маппинг на техники ФСТЭК<p>В пятницу, на конференции Kaspersky ICS Cybersecurity Conference, я выступал с темой "Основные сценарии реализации угроз на АСУ ТП и их преломление на методику оценки угроз ФСТЭК" (презентацию <a href="https://t.me/alukatsky/4497">выложил</a> в своем Telegram-канале). К этому выступлению я планировал завершить перевод последней версии матрицы MITRE ATT&CK v9 на русский язык и маппинг техник ФСТЭК в техники MITRE ATT&CK, что и было сделано (ссылки будут ниже).</p><p>Ключевая идея моей презентации заключалась в том, что моделировать угрозы по методике ФСТЭК можно (по-крупному) двумя путями - сверху вниз и снизу вверх. В первом случае мы последовательно выполняем все шаги методики, перебираем все возможные угрозы и сценарии их реализации и на выходе получаем список актуальных угроз, который, в зависимости от типа организации, должен или не должен быть согласован с регулятором. Второй подход, как мне кажется, более практичен и применим именно к АСУ ТП, в которых атак пока гораздо меньше, чем в корпоративных сетях. Поэтому вместо моделирования сверху вниз можно отталкиваться от уже известных инцидентов, которые просто надо описать с помощью методики ФСТЭК. И тут нас подстерегает засада - все известные отчеты по инцидентам на АСУ ТП, в том числе написанные и нашими лицензиатами, описывают техники и тактики нарушителей по MITRE ATT&CK. А ФСТЭК требует моделировать по своей "матрице" техник и тактик, которые отличаются от MITRE. Поэтому я и задался целью связать то, что принято во всем мире как стандарт де-факто (пусть и неидеальный) и что требует делать ФСТЭК.</p><p>Первым делом я перевел текущую, девятую версию матрицы MITRE ATT&CK на русский язык. Да, я прекрасно понимаю, что специалист по ИБ должен знать английский и должен самостоятельно читать матрицу MITRE в оригинале, но, увы, это пожелание далеко от реализации и многие не так хорошо говорят/понимают по-английски, как того хотелось бы. Да чего там, я сам не могу похвастаться хорошим знанием языка :-) Но это не помешало мне перевести названия техник ATT&CK на русский язык.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCFMpEDH-5ozxOxlp1aA8ipEcJ6vz-tARK-HHdlVMTbCUSgGACBJu-8dISOMO7GYUgqwq2uGgNwwdXlmi8fTvO_m2R3KUQ1ttVUZEUZIksCIGTeF4-2P1NMMhqNX8fePQRLedOnvOnd8H0/s2787/Screenshot+2021-09-10+at+02.13.55.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1129" data-original-width="2787" height="130" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCFMpEDH-5ozxOxlp1aA8ipEcJ6vz-tARK-HHdlVMTbCUSgGACBJu-8dISOMO7GYUgqwq2uGgNwwdXlmi8fTvO_m2R3KUQ1ttVUZEUZIksCIGTeF4-2P1NMMhqNX8fePQRLedOnvOnd8H0/s320/Screenshot+2021-09-10+at+02.13.55.png" width="320" /></a></div><div><br /></div><div>При этом я переводил только названия техник, без их описания (там многовато текста набирается). Но так как в этом случае далеко не всегда понятно, что означает оригинальная техника, я в русский перевод добавил некоторые уточнения. Надеюсь будет понятно. Кроме того, перевод позволил и самому чуть лучше начать разбираться в техниках злоумышленников. Так что даже если перевод никому не пригодится, то лично для меня это упражнение оказалось полезным.</div><div><br /></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgw33ziC864KycTVLXiVfTMIoPrHUNWUMTxr0b13i_cxyIdqWRwHKWFdm2MrMQa4Lxr3LPYPgcxTD6woP6cVs38h4mPWlNUrGfOj2afnwuCL-S_ZqROWoZLHrTw_nZS4LuFaAxh37ysxFRi/s2100/Screenshot+2021-09-10+at+02.15.17.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1048" data-original-width="2100" height="160" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgw33ziC864KycTVLXiVfTMIoPrHUNWUMTxr0b13i_cxyIdqWRwHKWFdm2MrMQa4Lxr3LPYPgcxTD6woP6cVs38h4mPWlNUrGfOj2afnwuCL-S_ZqROWoZLHrTw_nZS4LuFaAxh37ysxFRi/s320/Screenshot+2021-09-10+at+02.15.17.png" width="320" /></a></div><br /></div><div>Второй и, наверное, более серьезной задачей было найти соответствие между 145 техниками ФСТЭК и 400+ техник MITRE ATT&CK. Сразу скажу, что это была более сложная работа, так было не всегда просто понять, что имел ввиду наш регулятор под той или иной техникой? Иногда техники повторялись по смыслу, но чуть-чуть отличались по тексту. Иногда смысл техники вообще ускользал от меня. Иногда техника ФСТЭК могла быть описана сразу несколько техниками ATT&CK. В ряде случаев у техник ФСТЭК отсутствовал аналог в ATT&CK (такое тоже было, но нечасто). Наконец, необходимо отметить, что если ATT&CK использует не только техники, но и подтехники, описывающие детали реализации для конкретной платформы (Windows, Linux, облака и т.п.), то у ФСТЭК все ограничивается только уровнем техник, что также не всегда позволяет сделать четкое сопоставление.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSQ0DBG3lK1PAUsbhCFZUvuvkR2fBkJgjy63_BvtPeoRfQtWPYAAnYelYoAFcj2obfq9ngphQIuttaXU-XEz2mau5f6baEzxRUPFeKJaIv0cpDnuCP960iKdNCY83cZf-_rmbUAPa698S6/s2178/Screenshot+2021-09-10+at+02.14.15.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1064" data-original-width="2178" height="156" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSQ0DBG3lK1PAUsbhCFZUvuvkR2fBkJgjy63_BvtPeoRfQtWPYAAnYelYoAFcj2obfq9ngphQIuttaXU-XEz2mau5f6baEzxRUPFeKJaIv0cpDnuCP960iKdNCY83cZf-_rmbUAPa698S6/s320/Screenshot+2021-09-10+at+02.14.15.png" width="320" /></a></div><div><br /></div><div>В итоге я выполнил достаточно творческое упражнение, в результате которого транслировал техники ФСТЭК в техники MITRE ATT&CK. Допускаю, что у кого-то может быть свой вариант маппинга (я знаю, как минимум, о двух схожих инициативах), но, думаю, что моя оценка точна более чем на 80%. </div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfV_J1Dq4EUVEBwPpKZh_rS1jmDeryVmXHCRIo5XV1bq72RjRyQMfNQIfu77JWo-b4zSowHtCC3KvjKBnb4Df_M2o0znypEd8LlDs3xJAH3gKJxbrIVlYrRWEjqJuToHXKinipG1v7c92y/s2782/Screenshot+2021-09-10+at+02.14.53.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1118" data-original-width="2782" height="129" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgfV_J1Dq4EUVEBwPpKZh_rS1jmDeryVmXHCRIo5XV1bq72RjRyQMfNQIfu77JWo-b4zSowHtCC3KvjKBnb4Df_M2o0znypEd8LlDs3xJAH3gKJxbrIVlYrRWEjqJuToHXKinipG1v7c92y/s320/Screenshot+2021-09-10+at+02.14.53.png" width="320" /></a></div><div><br /></div><div>В октябре должна быть анонсирована новая, 10-я версия, MITRE ATT&CK и я планирую обновить свои переводы и маппинг. Кроме того, у меня в планах перевести матрицу ATT&CK for ICS, провести маппинг техник ФСТЭК с ней, а также провести обратный маппинг - из ATT&CK в ФСТЭК. Пока все сделано в Excel (мне было так удобнее), но, возможно, я сменю формат или просто экспортирую перевод и маппинг в что-то другое (ODS или CSV).</div><p>Переводы и маппинг выложил пока в свой <a href="https://t.me/alukatsky">Telegram-канал "Пост Лукацкого"</a>, но думаю над Google.Drive и Github (точнее я туда уже тоже выложил, но пока не пойму, где удобнее). Но судя по опросу, проведенному в Телеграме, большинству удобнее, чтобы файлы были выложены именно там.</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com3tag:blogger.com,1999:blog-4065770693499115314.post-84489915473137184002021-09-03T05:40:00.003+03:002021-09-03T05:40:00.237+03:00Сколько ИБшников надо в штат службы ИБ: формула расчета<p>Если не рассматривать крупные организации, службы ИБ которых насчитывают сотни человек, то в массе своей нам обычно не хватает людей на все наши хотелки и мы всегда чувствует дефицит персонала. И чем мельче компания, тем сильнее этот дефицит, который надо как-то закрывать. И когда ты приходишь к генеральному директору за одобрением новых ставок в штат ИБ, ты часто слышишь: "Вас и так много (а "вас" в реальности всего один или двое)" или "И так непонятно, что вы там в ИБ делаете, дармоеды". И ты выходишь весь оплеванный и не знаешь, как обосновать выделение ресурсов. Могу поделиться достаточно простой моделью, которая, если и не обеспечит 100% выделение нужных ресурсов, но позволит с цифрами в руках обосновать, что вам нужно именно такое количество людей; не больше и не меньше.</p><p>Идея заключается в том, что мы должны выписать все функции, которые нам нужны для обеспечения ИБ в табличку и против каждой функции проставить число часов, которые эта функция требует. Подсчитать число часов не так уж и сложно - достаточно просто замерить, сколько времени тратится на работу с тем или иным техническим решением или на организацию какой-либо задачи/процесса. В качестве примера могу привести такую табличку для небольшой компании с достаточно простой инфраструктурой.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjk0obg83VIpKXaPtidSaOfMoa9_uKyvae9DZvvoDWH5b4PCAdZvESlAsQRwr-l1l951OF6v6b_9tngnbqZZCM3dWqYnk1iu7pq4m8x61-2zGsZHt3eHTgyUzlsjsUsdZf42Y4cwhwV_if/s2048/securityfunctions-base.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1262" data-original-width="2048" height="197" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjjk0obg83VIpKXaPtidSaOfMoa9_uKyvae9DZvvoDWH5b4PCAdZvESlAsQRwr-l1l951OF6v6b_9tngnbqZZCM3dWqYnk1iu7pq4m8x61-2zGsZHt3eHTgyUzlsjsUsdZf42Y4cwhwV_if/s320/securityfunctions-base.png" width="320" /></a></div><div><br /></div><div>Очевидно, что чем крупнее организация, тем больше функций ИБ в ней реализуется и тем больше времени на них нужно. Но в данном примере нам нужно 140 часов в неделю, что при 40 рабочих часах по Трудовому Кодексу составит 3,5 FTE (Full-Time Equivalent). Иными словами, вам нужно (если отбросить в сторону круглосуточный режим работы некоторых функций) 3,5 сотрудника, чтобы обеспечивать минимальный набор функций ИБ на среднестатистическом предприятии. Если у вас в штате всего 2 человека, то вам не хватает "полутора землекопов", а на самом деле двух, так как у нас еще не научились делать половинки людей.</div><div class="separator" style="clear: both; text-align: center;"><p style="text-align: left;">Такой расчет является точкой отсчета для общения с руководством, которое начинает понимать, что вы не из пальца высосали нужное вам количество людей, а имеете подтвержденные цифрами доказательства. Когда вы просто приходите с протянутой рукой, вы находитесь в позиции человека просящего. Когда у вас есть обоснованные расчеты, у вас появляется предмет обсуждения с руководством, которое будет стоять перед вполне осознаваемым ими выбором:</p><p style="text-align: left;"></p><ul style="text-align: left;"><li>Выделить вам деньги на эти две вакансии.</li><li>Отказать в выделении вакансий, но предложить подумать об аутсорсинге указанных функций во внешней сервисной компании. Лично знаю ооооочень крупную компанию из списка Fortune500, которая имеет бюджеты на закупки различных игрушек по ИБ, но выбить там увеличение фонда оплаты труда (ФОТ) практически невозможно.</li><li>Подумать о сокращении времени на выполнение описанных функций за счет их автоматизации, то есть приобретении соответствующего инструментария.</li><li>Попросить вас сократить число функций или объем усилий по ним.</li></ul><p></p><p style="text-align: left;">Возможно, вам стоит заранее подготовить этот список альтернатив с описанием каждой из них, чтобы руководство принимало решение, опираясь на конкретику, а не на эмоции. Теперь, когда вам надо будет добавить новых функций, например, после появления новой нормативки, вам будет проще добавлять к имеющемуся расчету новые FTE. Допустим, вы банк и вам "навесили" обеспечение непрерывной надежности и уведомление ФинЦЕРТ об инцидентах ИБ, а ИТ сбагрила вам проект по идентификации и аутентификации. В итоге у вас получится уже 260 часов или 6,5 FTE (7 человек).</p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgl89WUxz2lV7mJMNSG5buEVHx-RMI5hUgPVoW9ankrBdaOIgRKOg-VRmkkcirL_iPfUXX1cgpI2AXIXMXYLXiXSnXc-zDkhbq9wZOA4y66sNEttJQx971abB5hKj3tKS69YnOlW3OL-0hp/s2905/securityfunctions-advanced.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="902" data-original-width="2905" height="99" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgl89WUxz2lV7mJMNSG5buEVHx-RMI5hUgPVoW9ankrBdaOIgRKOg-VRmkkcirL_iPfUXX1cgpI2AXIXMXYLXiXSnXc-zDkhbq9wZOA4y66sNEttJQx971abB5hKj3tKS69YnOlW3OL-0hp/s320/securityfunctions-advanced.png" width="320" /></a></div><p>Бывает конечно и так, что в организации один человек - "и швец, и жнец, и на дуде игрец", то есть этакий многостаночник, который способен работать за двоих, а то и троих человек, подменяя собой 2-3 FTE. Это редкость, но бывает. Также бывает и обратная история, сотрудник вроде и есть, штатную единицу занимает, но при этом работает вполсилы, а то и вовсе на четверть от требуемого. Обычно каждый руководитель ИБ обладает о своих сотрудниках такими сведениями и может планировать работу службы исходя из реалий, а не теории, но это не лучший вариант. Вот уйдет такой многостаночник и придется где-то искать ресурсы закрывать то, что он раньше делал в одиночку. Но это уже лирика.</p><p>Если вы хотите увидеть какие-то иные оценки временных затрат на обеспечение отдельных функций ИБ, то я могу порекомендовать интереснейший документ от Банка России, а именно <a href="https://www.cbr.ru/StaticHtml/File/59420/rs-27-15.pdf">РС 2.7 2015-го</a> года по ресурсному обеспечению ИБ в финансовой организации. Он, правда, ориентирован еще на СТО БР ИББС, но ежегодные усилия для каждого процесса ИБ там расписаны достаточно детально. Согласно Банку России минимальный состав службы ИБ банка составляет 12 человек (при росте числа филиалов и отделений и число растет пропорционально). Там приводится более сложная формула расчета ресурсов, но суть у нее та же.</p><p>Если вы дочитали эту заметку до конца и решили, что я выложил на блюдечке рецепт выбивания ставок из начальства, то не обольщайтесь. Все зависит не от используемых формул и затрачиваемых вами усилий, а от того, умеете ли вы общаться с руководством "на равных" и доверяет ли оно вам.</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com2tag:blogger.com,1999:blog-4065770693499115314.post-14905881793010328502021-09-02T05:33:00.001+03:002021-09-02T05:33:00.276+03:00О резюме специалистов по ИБ<p>В Фейсбуке моя краткая заметке привела к некоторой дискуссии, поэтому я решил написать чуть более развернуто. Но начну я с копипаста своей заметки, чтобы было понятно, о чем идет речь.</p><p>"<i>Вот почему люди так пофигистически относятся к подготовке своих резюме? Они ищут работу и, вроде как, должны быть заинтересованы в том, чтобы поразить будущего работодателя своими умениями, навыками и знаниями. Но нет!
Почему мало кто из ИБшников или ИБшных сейлов пишет о своих измеримых достижениях в резюме? Меня лично мало интересует, какой ВУЗ человек закончил 10-20-30 лет назад (а это ставят на первое место в резюме почти все - как будто все один плохой шаблон используют). А достижения интересуют. По ним оценивается специалист, а не по тому какому КОИБАСу его учили старперы по учебникам времен Петра Первого.
С достижениями, кстати, тоже засада. Если они и есть, то никак не учитывают, кому резюме отправляется. Вот зачем в американской компании человек, который на первое место в своих достижениях выносит проекты по импортозамещению? 😉
Интересно, когда пишется ТЗ на систему по ИБ, оно же не универсальное (я надеюсь). Почему тогда резюме универсальное? Почему нельзя под каждого потенциального работодателя сделать свой вариант, "бьющий точно в цель"?</i>"</p><p>Собственно, что я имел ввиду, когда говорил о достижениях? Ну вот, например, вместо указания продуктов, с которыми человек работал (а может не вместо, а вместе), можно было бы написать "внедрил IdM в масштабах предприятия на 1000 сотрудников". Вместо указания названия IRP-платформы, работе с которой можно научиться за пару дней на курсах вендора, а то и вовсе по роликам в YouTube, было бы классно увидеть что-то типа "выстроил процесс incident response, снизив время приема заявки с 17 минут до 3-х". А вместо "работал с заявками пользователей на доступ" горазо выгоднее бы смотрелось "написал средство автоматизации работы с заявками пользователей на доступ, сократив время предоставление доступа до 1 часа".</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikmR3-RlTEjF3lGHeVzaR5cAaNiKrp3JxpkHfxrHLdK280PZdg_8MpfiNAhOr7IDZb-jTEp4Vr_j8D_MHVNdXUmeD-Hh0qhPJ_72tXKo5apEVYprpehedUrvqBoYQ9K39Iwy2OV02aY3A3/s2048/cyber_security_resume_example.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1092" data-original-width="2048" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEikmR3-RlTEjF3lGHeVzaR5cAaNiKrp3JxpkHfxrHLdK280PZdg_8MpfiNAhOr7IDZb-jTEp4Vr_j8D_MHVNdXUmeD-Hh0qhPJ_72tXKo5apEVYprpehedUrvqBoYQ9K39Iwy2OV02aY3A3/s320/cyber_security_resume_example.jpg" width="320" /></a></div><p>В ФБ Юлия Омельяненко справедливо пишет, что "умение делать работу и умение продать себя - две, не всегда связанных между собой навыка". С одной стороны я с не соглашусь. Это совсем разные навыки. С другой - если ты хочешь найти себе новую работу (а не просто "а почему бы и не попробовать закинуть резюме, вдруг прокатит"), то чуть напрячься и потратить время на осмысливание того, что ты делал/делаешь на работе и какую пользу ты принес, полезно. Представьте, что вы ищете сейла (специалиста по продажам) и он в резюме пишет, что он каждый день искал клиентов и продавал им какие-то продукты или услуги. Вас разве не заинтересует вопрос, а успешно ли он продавал? На какую сумму он продал на прошлом месте работы и насколько он перевыполнил план? Так и с ИБшником. Он тоже не просто "крутит гайки на файрволах" или выдает ключи электронной подписи - он улучшает состояние ИБ на предприятии.</p><p>Насколько улучшает? Как улучшает? К чему приводит его деятельность? "А меня не интересует, насколько безопаснее стало предприятие от моей работы. Я делаю свое дело. Я делаю то, что мне говорит начальство". Ну ОК. Ты классный чувак, наверное. Но на кой ты такой нужен, если тебе абсолютно пофигу, есть результат от твоей работы или нет? Я бы такого человека не только не взял на работу, но и гнал бы в шею поганой метлой, потому что такой пофигист не только не приносит пользы, но и заражает свои безразличием окружающих. Как правильно отметила в заметке Екатерина Калугина, большинство соискателей в резюме пишут, что делали (а это у многих схожих по роли специалистов очень похоже), а не что сделали.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL86OyoXfTfms_0jsQNToKtiUcw8vebSdHFwJVxkeH3HLyttmeXpwWNz8oshy1XUpkDlLymiFB11spblVRdTC0oXDpGlY3kvnyfMfT78VeJAeodZGDLkTH7uS2KZ-Xq35wZ4pR8CASNqT1/s2048/security_officer_resume_example_1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1092" data-original-width="2048" height="171" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiL86OyoXfTfms_0jsQNToKtiUcw8vebSdHFwJVxkeH3HLyttmeXpwWNz8oshy1XUpkDlLymiFB11spblVRdTC0oXDpGlY3kvnyfMfT78VeJAeodZGDLkTH7uS2KZ-Xq35wZ4pR8CASNqT1/s320/security_officer_resume_example_1.jpg" width="320" /></a></div><p>Рустем Хайретдинов в ФБ написал "<i>Специалист такой же продукт, как и софт, чтобы его продать, надо знать своего покупателя, его "боли", свои сильные и слабые стороны. Мне очевидно, что для разных компаний надо писать разные резюме, выбирать те свои "фичи", которые максимально выпячивают конкурентные преимущества на конкретной должности, выбрасывать второстепенные, не врать, но умалчивать недостатки. Писать резюме - несложная штука, научиться сильно проще, чем обращаться с PowerPoint</i>" и я с ним согласен. Если ты веерно рассылаешь одинаковые резюме, то шансов найти что-то стоящее немного. С другой стороны, появляется шанс у тех, кто чуть напрягся и потратил время на изучение потенциального работодателя и подкрутку своего резюме под конкретную организацию. А если еще и сопроводительное письмо было написано, то вообще космос и шансов становится гораздо больше. Причем даже если такое резюме не прошло фильтр в виде HR, который смотрит только на знакомые слова или аббревиатуры, которые ему дали в ИБ (CISSP, OSCP, TIP, NGFW, ФСТЭК, SOC, SIEM и т.п.), то даже в этом случае есть смысл.</p><p>"А я вот аналитик первой линии SOC и просто работаю по плейбукам. Какие у меня могут быть достижения?" Логичный вопрос. Тоже самое может сказать человек, который настраивает МСЭ или генерит криптографические ключи или обрабатывает заявки на доступ или... Этих "или" может быть очень много. ИБ - не столь творческая профессия, как у художника, у которого каждая его картина уже достижение. И это не продажи, которые легко измерить по объему продаж, перевыполнению плана и другим показателям. И это не начальник, который может писать в резюме, что он управлял 10 сотрудниками или увеличил бюджет подразделения на 20% за пять лет (при ежегодной инфляции в 8%). Но!.. Как мне кажется, на любой должности в области ИБ надо не тупо выполнять то, что написано в плейбуке или инструкции, а думать прежде всего. Если вы тупо выполняете какие-то рутинные операции, то будьте уверены - вы первый кандидат на увольнение. Любая рутинно выполняемая операция рано или поздно будет автоматизирована - либо с помощью специализированных решений класса SOAR, либо с помощью технологий no code/low code, которые начинают проникать в ИБ, либо с помощью машинного обучения (как бы мы к нему не относились), либо с помощью технологий RPA (robot process automation). А если вернуться к работе аналитика, то у вас идеально выстроены процессы мониторинга и идеальные плейбуки, которые не надо улучшать? Мониторя инциденты, вы не замечали, что описанные процедуры неидеальны и могут быть улучшены? А новые правила корреляции вам не нужны? Вы предлагали улучшения? Да? Вы молодец! Это и пишите в "достижения". Не предлагали? Ну тогда повод задуматься.</p><p>О том, как писать резюме можно писать еще много, но я не ставил перед собой такую задачу. Главное, что я бы вынес из этой заметки - любая работа должна приносить результат, оцифрованную форму которого и нужно вносить в резюму. Разумеется, все это имеет смысл, если действительно человек не просто ходил на работу "с 9-ти до 6-ти" просиживать штаны, а реально что-то делал полезное для своей компании или хотя бы для своего подразделения. И, конечно, идея "пишите про свои достижения" должна быть принята во внимание, если вы действительно ищете работу (а то многих работа находит сама) и не рассылаете веером свое стандартное резюме "лишь бы куда-нибудь оно попало".</p><p>Ну а если вам интересно еще глубже погрузиться в тему строительства своей карьеры по ИБ, то есть несколько книжек на тему: </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHcmcvzs6L3RjAzTFzwNDzf5-AHLuiKF0dswzNeXfLrP-e0YUV5rWAqt5b2SggHsgOfv6ueFNlpStuost3C46bgC_83GD7oqMVtSaZ7QTbrlzha_VdisH7TKUC-oS3DoUk7KsqiHsHQ34x/s1402/Screenshot+2021-09-01+at+19.32.41.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1402" data-original-width="1090" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHcmcvzs6L3RjAzTFzwNDzf5-AHLuiKF0dswzNeXfLrP-e0YUV5rWAqt5b2SggHsgOfv6ueFNlpStuost3C46bgC_83GD7oqMVtSaZ7QTbrlzha_VdisH7TKUC-oS3DoUk7KsqiHsHQ34x/s320/Screenshot+2021-09-01+at+19.32.41.png" width="249" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPYy0-1zohz6j2VAfmfNlvzapEy6lz4qaHWbd8O_t2TiNkm-4kgVHPVYJw3PWMWnrB2xw_bwQsH5TT2d0x2QGAT0kwNHqazdpklO3fLDa0vbrbFNT7KcFNiqlZZe8nDlPxUSpLVEM75cwX/s500/0692514155.01._SCLZZZZZZZ_SX500_.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="500" data-original-width="333" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPYy0-1zohz6j2VAfmfNlvzapEy6lz4qaHWbd8O_t2TiNkm-4kgVHPVYJw3PWMWnrB2xw_bwQsH5TT2d0x2QGAT0kwNHqazdpklO3fLDa0vbrbFNT7KcFNiqlZZe8nDlPxUSpLVEM75cwX/s320/0692514155.01._SCLZZZZZZZ_SX500_.jpg" width="213" /></a></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDM1Dvgtc1oIHD8rQ95oPH9YMOyHRxTCJ1SMiqYylSBfSjAeEtw7v5QgHAdms7WNDPxCttiyy93qrQF5v9kCnKtTTo1mbsBDXqRbQMf_8gNcBm3WWZcxXyTQfmJR_sDQoHS552SgxqxAl-/s500/1659808340.01._SCLZZZZZZZ_SX500_.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="500" data-original-width="333" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhDM1Dvgtc1oIHD8rQ95oPH9YMOyHRxTCJ1SMiqYylSBfSjAeEtw7v5QgHAdms7WNDPxCttiyy93qrQF5v9kCnKtTTo1mbsBDXqRbQMf_8gNcBm3WWZcxXyTQfmJR_sDQoHS552SgxqxAl-/s320/1659808340.01._SCLZZZZZZZ_SX500_.jpg" width="213" /></a><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYkAA5k3SpcnAZURrNCj55ePL5a10iSVGvLlfjEaGbVT9FUHyWWSuhvqnqKKifMI6d4APTI3L0kaDFfCGVC9DItLe0hLPA6NjgYBWHZhyphenhyphenVT_l4pZF8A9rNDCMUVdvBpzA2xjOciysUYgac/s451/Miller-MEAP-HI.png.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="451" data-original-width="360" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjYkAA5k3SpcnAZURrNCj55ePL5a10iSVGvLlfjEaGbVT9FUHyWWSuhvqnqKKifMI6d4APTI3L0kaDFfCGVC9DItLe0hLPA6NjgYBWHZhyphenhyphenVT_l4pZF8A9rNDCMUVdvBpzA2xjOciysUYgac/s320/Miller-MEAP-HI.png.jpeg" width="255" /></a></div><div><br /></div><div>ЗЫ. Все это сугубо мое личное мнение :-) Но если я когда-нибудь я буду писать резюме и искать работу с нуля, то я обязательно буду фокусироваться на достижениях и что работодатель получит от моего найма, то есть буду писать не о том, какой я классный (а это даже не обсуждается :-), а о том, что получит работодатель от того, какой я классный. </div><div class="separator" style="clear: both; text-align: center;"><br /></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com13tag:blogger.com,1999:blog-4065770693499115314.post-84117780906376457042021-08-24T05:08:00.002+03:002021-08-24T05:08:00.247+03:002 государевых модели угроз, авторы которых забили болт на требования ФСТЭК<p>Вчера я <a href="https://vybory.gov.ru/materials/6">наткнулся</a> на модель угроз и нарушителя безопасности информации, обрабатываемой в программно-техническом комплексе дистанционного электронного голосования (ДЭГ). И хотя это всего лишь выписка, она все равно дает пищу для размышлений. В частности, беглый просмотр этого документа вызвал у меня следующие вопросы:</p><p></p><ul style="text-align: left;"><li>Где модель нарушителя? Предположу, что это в неопубликованной части, но что-то по тексту это не прослеживается. Либо модели нарушителя не было вообще, либо на сайте выборов опубликовали не просто выписку, а отдельно написанный документ для публичного ознакомления. Походя указано, что администраторы могут иметь деструктивные наклонности и негативно повлиять на инфраструктуру ДЭГ и поэтому для борьбы с этим предлагается использовать... СКЗИ (как связаны СКЗИ и возможность противодействия деструктивным действия администраторов, я не знаю).</li><li>Меня немного удивило заявление, что в ДЭГ не обрабатываются специальная категория персональных данных о политических взглядах. При выборах в Госдуму и при волеизъявлении в пользу той или иной политической партии ДЭГ не обрабатывает данных о политических взглядах? Смелое заявление, отображающее стремление занизить уровень защищенности ИСПДн. Но рассчитано явно на людей, плохо соображающих или тех, с кем есть договоренность. С другой стороны, РКН модель не согласовывает, а ФСТЭКу в целом все равно, какой там уровень защищенности ИСПДн, если класс защищенности ГИС 1-й. </li><li>Также, видимо, в целях снижения уровня защищенности ИСПДн в ДЭГ признаны неактуальными недокументированные возможности (читай, закладки) на уровне ОС и приложений. Я склонен был бы согласиться с таким выводом, если бы речь шла о ИСПДн какой-либо noname-компании, но система для государственных выборов?.. Но тогда возникает вопрос, зачем там СКЗИ класса КА, которое как раз от таких угроз среди прочего и защищает? </li><li>Кстати, о криптографии. А где угрозы по этой части? В выписке написано, что модель разрабатывалась в соответствие с 676-м Постановлением Правительства, но в нем есть требование согласования модели не только с ФСТЭК, но и (а не или) с ФСБ, которой все равно, что написано в БДУ, но которая требует, чтобы были указаны угрозы именно по части СКЗИ. Но их в опубликованной выписке нет. Видимо, в закрытой части. </li><li>А что есть в открытой, так это упоминание необходимости применения СКЗИ при общении с избирателем и СКЗИ это должно быть класса КС1. Но как это сделать, если у избирателя нет браузера "Спутник" или он работает с мобильного устройства? По тексту допускается применение шифрования RSA (написано, что это даже согласовано), но вот зачем тогда упоминается КС1? Кстати, меня покоробило упоминание RSA в контексте шифрования данных. Обычно с помощью RSA шифруется только сеансовый ключ, а уж сам сеанс защищается симметричной криптографией, включенной в протокол TLS. Ну да оставим это на совести тех, кто писал часть по криптографии - она вообще очень куцая в выписке.</li><li>В выписке перечислен чуть ли не весь банк данных угроз, признанных актуальными для ДЭГ, но я не нашел в модели, описывающей угрозы для системы на базе блокчейна, угроз для собственно самого блокчейна. Они признаны неактуальными? </li><li>В одной из своих презентаций, я рассказывал о том, как была взломана три года назад компания British Airways. Одной из высказанных версий назывался взлом не самого сайта авиакомпании, а кеширующих серверов CDN, которые не контролировались самой BA. Так вот в описании модели угроз ДЭГ также говорится об использовании CDN, но ни слова о том, что эти распределенные сервера входят в контур защиты ДЭГ и что для них рассматривались угрозы. Возможно технология взаимодействия с избирателями никак не завязана на CDN и угрозы ему признаны неактуальными, "а что, мля, если да", как пелось в известной песне Слепакова? </li><li>В приложении А в выписке отображена архитектура ДЭГ. Если она верна, то компоненты всей системы работают через VPN, а Интернет используется только на получение данных от избирателей. То есть, если верить опубликованной схеме, у членов избирательных комиссий нет прямого выхода в Интернет для того, чтобы посерфить в свободное от мониторинга голосования время. И это правильно. Но тогда зачем в списке актуальных угроз фишинг и фарминг? А откуда взялась угроза внедрения ВПО через рекламу (члены электронных избирательных комиссий рекламу смотрят)? А угрозы внедрения ВПО при посещении зараженных сайтов? Угроза хищения информации из cookies? Зачем рассматривать угрозы, которых по идее быть вообще не должно на рабочих местах людей, ответственных за голосование? </li></ul><div>Но основной вопрос, который у меня возник после прочтения этой выписки, связан не с упомянутыми выше темами. Вопрос в другом. В феврале этого года ФСТЭК утвердила методику оценки угроз, которая является обязательной для всех ГИС (а система дистанционного электронного голосования относится к ним). В этом нормативном документе описана и структура модели угроз, которая должна быть, и ряд обязательных элементов, среди которых сценарии реализации угроз. Но где они в выписке? Они судя по всему отсутствуют и в закрытой части. <b>ПОЧЕМУ?</b></div><div><b><br /></b></div><div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOj0sQvhos1VcnLOplthLuGTwHQ_ZpDy6fwn5QJcYN6v1C4Dc9pdDQvO9v1cTZFnKEhZAX1JEQO2mqfk7rAPwNjcaHnGVwkSoigRheXLwX54H2M3pUHtkm7DNLYegqnqdOhjCwwHPqrY75/s994/IMG_3181.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="994" data-original-width="640" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjOj0sQvhos1VcnLOplthLuGTwHQ_ZpDy6fwn5QJcYN6v1C4Dc9pdDQvO9v1cTZFnKEhZAX1JEQO2mqfk7rAPwNjcaHnGVwkSoigRheXLwX54H2M3pUHtkm7DNLYegqnqdOhjCwwHPqrY75/s320/IMG_3181.jpg" width="206" /></a></div></div><div><br /></div><div>Почему владельцы государственной информационной системы забили болт на требования регулятора по ИБ? И если такое сделано публично, то почему остальные госорганы не должны сделать тоже самое? И почему субъекты КИИ, операторы ИСПДн и АСУ ТП не должны следовать той же логике?</div><div><br /></div><div>Но возможно ФСТЭК не согласовала эту модель угроз или ей приказали сверху не чинить препятствие системе честных выборов, где россияне, все как один, должны в очередной раз поддержать партию власти. Но как тогда воспринимать <a href="https://minenergo.gov.ru/node/20966">модель угроз для интеллектуальных систем учета электроэнергии</a>, письмо об утверждении которой в июне этого года была разослано от имени министре энергетики г-на Шульгинова? В письме написано, что эта модель разработана Минэнерго совместно с ФСБ, ФСТЭК и Минцифры. Но как? Как ФСТЭК могла согласовать эту модель, если она нарушает требования самой же ФСТЭК, выпущенных 5 месяцами раньше? Опять кто-то ровнее других? Опять одним можно, а другим нельзя?</div><div><br /></div><div>Если честно такая политика ФСТЭК в отношении своих требований немного смущает и удивляет. То есть сначала выпускается документ, в отношении понятности которого (чтобы не говорили представители компании-лицензиата, участвовавшие в его разработке) с самого начала были вопросы его реализуемости. Потом оказывается, что один из ключевых элементов процесса моделирования (БДУ) не совместим с новой методикой, но при этом обязателен к использованию. Но ФСТЭК молчит и не публикует никаких информационных писем на этот счет, разъясняющих свою позицию. Зато представители ФСТЭК участвуют в мероприятиях коммерческих компаний и комментируют (как сотрудники регулятора или как частные лица?) свой же документ. А теперь еще и сам документ вроде как необязательно выполнять, коль скоро две государственных структуры публично это демонстрируют. Доверие к регулятору в такой ситуации явно не растет :-(</div><p></p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com5tag:blogger.com,1999:blog-4065770693499115314.post-17746836414746606312021-08-09T05:08:00.002+03:002021-08-09T05:08:00.289+03:00Платить вымогателям или нет?<p>На очередном мероприятии, где я выступал с рассказом о стратегии борьбы с шифровальщиками, и поднял тему об оплате выкупа вымогателям, завязалась дискуссия, в которой я отстаивал точку зрения, что оплата выкупа - это бизнес-решение, а мои оппоненты, сплошь одни безопасники, защищали противоположную точку зрения, что платить вымогателям нельзя, тем самым мы стимулируем их на совершение еще больших преступлений. И поскольку такие дискуссии завязываются достаточно часто, я попробую сформулировать свои тезисы в виде заметки, чтобы потом просто давать всем ссылку :-)</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2uVLZ_41CL60LQDlwSlQqPXRgavsOs400br8b5Twp6k75FLEhwkLzwXXyhoB7lr8K7F1V4-Gc8W0ell9xPQcYfDlUQdu0t99Aa0ZdGEY1iKoplb5TaawH2j0rwyLFGGP_naQDALdhAbER/s2800/ey-ransomware-payment-decision-flowchart.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1123" data-original-width="2800" height="128" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2uVLZ_41CL60LQDlwSlQqPXRgavsOs400br8b5Twp6k75FLEhwkLzwXXyhoB7lr8K7F1V4-Gc8W0ell9xPQcYfDlUQdu0t99Aa0ZdGEY1iKoplb5TaawH2j0rwyLFGGP_naQDALdhAbER/s320/ey-ransomware-payment-decision-flowchart.png" width="320" /></a></div><div><br /></div><div>Для начала стоит определится с простым тезисом - хорошо выстроенная система резервного копирования обойдется дешевле выкупа в большинстве случаев. Как-то несколько лет назад, на Ramsomware Summit в Сан-Франциско, почти все эксперты по ИБ, не сговариваясь, утверждали, что единственным эффективным способом борьбы с шифровальщиками является резервное копирование (вопрос шифрования или уничтожения резервных копий оставим в стороне). Но сейчас не об этом. Допустим такой системы нет и мы все-таки столкнулись с шифровальщиком и распространяющая его группировка требует выкуп. Платить или нет? Кстати, на том же саммите представитель ФБР допускал возможность оплаты выкупа, что уже говорит о многом. В <a href="https://www.ic3.gov/Media/Y2019/PSA191002">своих бюллетенях</a> ФБР повторяет эту мысль.</div><div><br /></div><div>Если следовать набившей оскомину идее, что ИБ должна говорить с бизнесом на его языке и быть вообще бизнес-ориентированной, то и проблему выплаты выкупа надо рассматривать как проблему бизнеса и приравнивать ее к "платить за переход к облакам или нет", "платить за кофе или нет", "поднять зарплату или нет", "открыть новый офис или нет". Я не призываю всегда платить вымогателям, но прекрасно осознаю, что это вполне реальная опция. Особенно если отбросить банальности и эмоции. Если бы шифровальшик зашифровал фотографии моих детей с самого их рождения и у меня не было бы резервной копии, то мой ответ на вопрос "Заплачу ли я?" вполне мог бы быть положительным. Если такой ответ рассматриваете как возможный и вы (наряду с другими опциями), то при ответе на стоящий в заголовке заметки вопрос нам надо будет ответить на ряд сопутствующих вопросов, а именно:</div><div><ol style="text-align: left;"><li>Уверены ли мы, что нам пришлют ключи для расшифрования? Бывает так, что не присылают. Да, неприятно. Но это как вы инвестировали в запуск нового продукта, а он провалился в продаже и не окупился. Это бизнес - деятельность на свой страх и риск. Правда, в случае с шифровальщиками лучше все-таки проконсультироваться со специалистами по ИБ, которые могут иметь статистику по случаям отказа от отправки ключей шифрования для тех или иных шифровальщиков.</li><li>Уверены ли мы, что ключи шифрования помогут и в реализации шифрования нет ошибок? Для этого надо побепокоиться о пробниках, которые многие группы присылают для демонстрации своих "добрых намерений".</li><li>Какие из пострадавших систем требуют скорейшего восстановления и за какие из них нам надо заплатить выкуп (да-да, в процессе переговоров, вы можете поторговаться и определиться не только с суммой выплаты, но и с набором возвращенных данных)? Например, если атака накрыла финансовые системы за неделю до сдачи финансовой отчетности, то сможет ли финансовый департамент выполнять свои обязанности? У вас вообще есть альтернативные процедуры и процессы на случай простоя/остановки ваших вычислительных систем? </li><li>Как быстро вам нужно восстановить доступ? В истории с Colonial Pipeline жертва заплатила выкуп не потому, что у нее не было резервной копии, а потому что процесс восстановления из нее шел очень медленно. И это, кстати, ставит перед нами другой вопрос - а мы вообще тестируем систему восстановление из резервных копий или делаем это только после успешной атаки шифровальщика? Да, тестирование восстановления - это процесс недешевый, но все равно он обойдется дешевле выкупа. Хорошей метрикой для оценки состояния в этой области будет "% систем, для которых за прошедший год было проведено тестирование восстановления из резервной копии".</li><li>Есть ли что-то в зашифрованных и утекших данных (а шифровальщики часто выкачивают все данные для последующего шантажа жертв), чтобы мы не хотели делать достоянием гласности? Может быть у нас есть все бэкапы, но мы не хотим, чтобы кто-то узнал о наших секретах - двойной бухгалтерии, "грязном белье", ноу-хау, списках клиентов и условиях работы с ними и т.п.</li><li>Не будет ли данная оплата рассматриваться как финансирование терроризма или экстремизма, а для госорганов - как нецелевое расходование средства? В России скорее всего нет (я надеюсь), но лучше уточнить у юристов и финансистов этот вопрос.</li><li>Кто будет договариваться и как платить? Есть ли у вас криптовалютный кошелек (если вы будете платить сами) или за вас будет платить специально нанятая компания или даже страховая? Ответ на вторую часть вопроса зависит от того, насколько для вас критична публичность? Не надо ли вам вносить это в публичную отчетность? Не находится ли получатель денежных средств под санкциями (актуально для дочек американских компаний)?</li></ol><div>На картинке выше EY преставил свое видение процесса, позволяющего вам лучше подготовиться к выплате выкупа. Хотя мне кажется он не полным и я бы добавил в него несколько дополнительных элементов/вопросов из <a href="https://blog.talosintelligence.com/2016/04/ransomware.html">блок-схемы</a> Cisco Talos.</div></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguFZnDj_cnH08F1iM3NplAmMpZPi1fZUmPgxY6SWyjz377ALBr3Io70_8EyCk95TgKqgQXujcGygW9lYVaB9mPE7m6kDw62SDQNrM1Z0rUlG1NbqtHV1QtYmLJEIAuDaYyWaCjsXR4DEXJ/s1490/ransomware+fig14.jpeg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1140" data-original-width="1490" height="245" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguFZnDj_cnH08F1iM3NplAmMpZPi1fZUmPgxY6SWyjz377ALBr3Io70_8EyCk95TgKqgQXujcGygW9lYVaB9mPE7m6kDw62SDQNrM1Z0rUlG1NbqtHV1QtYmLJEIAuDaYyWaCjsXR4DEXJ/s320/ransomware+fig14.jpeg" width="320" /></a></div><div><br /></div>В любом случае я хочу вновь повторить свой тезис. Выплата выкупа - это вопрос, который решает бизнес в конкретной ситуации и опираясь на всю полноту имеющейся информации. Решит бороться с последствиями и вручную восстанавливать данные, как мэр Балтимора в мае 2019-го года, который отказался заплатить 76 тысяч долларов вымогателям и в итоге восстановление всех городских систем обошлось бюджету в 18,2 миллиона долларов, так тому и быть. Решит обратиться к страховой компании (если раньше был застрахован), отлично. Решит заплатить? Ну что ж. Это тоже возможная опция, которую нельзя сбрасывать со счетов. И она может оказаться наименее затратной из всех. Американская Атланта в марте 2018-го года столкнулась с SamSam и, отказавшись заплатить 51 тысячу выкупа, потратила на восстановление своей инфраструктуры 17 миллионов. Взвешивать все "за" и "против" бизнесу, а безопасность должна беспристрастно подготовить все необходимые данные для принятия решения. <p>ЗЫ. "А я буду настаивать, что платить выкуп ни в коем случае нельзя", - продолжаете стоять на своем вы. Но, стоя на своем, помните, что бизнес может задать встречный и вполне закономерный вопрос: "А как ИБ допустила, что шифровальщик натворил таких дел?". Поэтому стоять на своем может быть больно :-) </p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-31661361036996948272021-07-27T08:29:00.001+03:002021-07-27T08:29:49.019+03:00Калькулятор оценки технологической зрелости соответствия 239-му приказу<p> Несколько лет назад, а именно пять, я писал о том, как можно было бы облегчить жизнь с реализацией приказов ФСТЭК, внедрив неку/ю модель зрелости, которая бы позволила оценивать текущий уровень реализации требований регулятора и выстраивать некую дорожную карту достижения желаемого уровня соответствия. К сожалению, описанная мной тогда идея так и осталась идеей и, в отличие от NIST, который к своему фреймворку CSF предложил как раз схожую тему, наш регулятор, видимо по причине загруженности в условиях нехватки кадров, оставил этот вопрос в стороне. И вот на днях подумал я, что неплохо бы реализовать такую идею самостоятельно, что я и сделал. Итак, представляю калькулятор оценки <b>технологической</b> зрелости реализации приказа №239 ФСТЭК (для значимых объектов КИИ).</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwIc6dBNbJQ6oVctZUCMJy5mXXrqY5W3vdef-GZl6D0TfarH8Z0pxemZpCnQ4H8VczzF-lY4GjoK7nTPu7gCgPDOXnw7hnkNh9OMetOPG2Cl46-AEfPVV4PwkpSHOAAPFaOvFBpf-e1gBV/s2048/FSTECCybersecurityMaturityLevelCalculatorLite2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1904" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwIc6dBNbJQ6oVctZUCMJy5mXXrqY5W3vdef-GZl6D0TfarH8Z0pxemZpCnQ4H8VczzF-lY4GjoK7nTPu7gCgPDOXnw7hnkNh9OMetOPG2Cl46-AEfPVV4PwkpSHOAAPFaOvFBpf-e1gBV/s320/FSTECCybersecurityMaturityLevelCalculatorLite2.png" width="320" /></a></div><div><br /></div>Почему я особо выделяю слово "технологической" в названии? Причина этого проста - мне хотелось сделать облегченный калькулятор, в котором надо было бы себя оценивать не по каждому из полутора сотен требований (этот вариант я сейчас доделываю), а по каждому блоку целиком. Поэтому классический вариант с оценкой зрелости по CMMI сюда не подходил. Поэтому я и решил, что раз большинство защитных мер из 239-го приказа являются технологическими, то и оценивать реализацию приказа можно именно с этой точки зрения.<p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2TPvXVVfQ3DeUgNTbxE70ioxrX9QkVMvDVr2KEkJLTMo06jdCqjD6vFqlOauq3Cl1buGymYZptklQkE2CrJpzqoayhuO7N0khsZ0-PS48oeSAH0b7YRQmerUxiLFI7VqLzKFSR4KYgLqc/s2740/Screenshot+2021-07-23+at+22.51.32.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="644" data-original-width="2740" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi2TPvXVVfQ3DeUgNTbxE70ioxrX9QkVMvDVr2KEkJLTMo06jdCqjD6vFqlOauq3Cl1buGymYZptklQkE2CrJpzqoayhuO7N0khsZ0-PS48oeSAH0b7YRQmerUxiLFI7VqLzKFSR4KYgLqc/s320/Screenshot+2021-07-23+at+22.51.32.png" width="320" /></a></div><p>В итоге получилась вот такая табличка, где для каждого блока защитных мер были выделены 5 уровней зрелости, характеризующихся применением тех или иных технологий или тем или иным уровнем автоматизации. Например, на первом уровне блока ИАФ (идентификация и аутентификация) компания применяет обычные пароли для своих пользователей. Затем она переходит к многофакторной аутентификации, потом задумывается о Zero Trust или 802.1x начинает аутентифицировать не только пользователей, но и устройства. Потом компания созревает до доступа к своим активам внешних пользователей и начинает аутентифицировать их, а в финале, на пятом уровне зрелости, применяет федеративную систему аутентификации, применяемую в том числе и на внешних ресурсах - облаках и т.п.</p><p>Сложность возникла для такого, казалось бы простого, блока защитных мер, как обнаружение вторжений. Всего две меры защиты в нем и вроде бы не так все сложно, но... У ФСТЭК под понятием СОВ понимается вполне конкретный набор решений, который описывается их руководящими документами. Я же считаю, что обнаружение вторжений - это гораздо более широкий спектр технологий, которые не только делятся на уровни реализации - сетевые и хостовые, но и по используемым алгоритмам обнаружения, интеграции их в единый комплекс (XDR), а также применением в облачных средах.</p><p>Но и с обнаружением вторжений ситуация не столь сложна, как с аудитом безопасности, под которым приказ 239 понимает не только классический аудит, но и мониторинг ИБ, а также применение решений по анализу трафика, которому, на мой взгляд, место больше в обнаружении вторжении. Но такова уж карма термина "активный аудит", который в России известен уже давно и в него засовывают и обнаружение вторжений, и анализ защищенности. Но и с этим я тоже справился. В итоге получилась небольшая таблица, в которой достаточно всего лишь 20 раз выбрать нужный уровень вашей технологической зрелости, после чего будет отрисована радарная диаграмма, показывающая уровень зрелости по каждому из блоков защитных мер и насколько нам далеко до желаемого/рекомендуемого уровня. Кстати, о последнем. Я его выбирал опираясь на собственный опыт. При желании там можно поиграться с уровнем, к которому надо стремиться.</p>Вот такой вот легонький инструмент, который я <a href="https://t.me/alukatsky/4374">выложил</a> у себя в Телеграме.<br /><p></p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com2tag:blogger.com,1999:blog-4065770693499115314.post-37301418775329956982021-07-19T05:54:00.017+03:002021-07-19T05:54:00.278+03:00Об ИБ-спикерах и их мотивации выступать на мероприятиях<p>Вы думали, почему на конференциях по ИБ выступают Рустем Хайретдинов, Дима Мананников, Алексей Качалин, Антон Карпов, Дима Гадарь, Мона Архипова и другие достойные специалисты? Я не знаю, почему. Да и наверное неправильно додумывать за них об их причинах. Я хочу поделиться своим видением того, почему человек начинает выступать на конференциях. Будем считать это продолжением моего опуса об ИБ-блогерстве, <a href="https://lukatsky.blogspot.com/2016/05/phdays_24.html">написанном</a> 5 лет назад. Многое из того, что было написано тогда, продолжает оставаться актуальным и в отношении спикеров ИБ-мероприятий, но отдельные моменты все-таки надо уточнить и прокомментировать. Тем более, что и повод на днях появился. 8 лет назад я уже <a href="https://lukatsky.blogspot.com/2013/07/blog-post_4.html">пытался оформить</a> свои причины участия в ИБ-мероприятиях, но за это время ситуация немного поменялась.</p><p>Итак, давайте посмотрим на мотивацию организатора мероприятия. Он, очевидно, заинтересован в том, чтобы заманить в свои ряды именитого, интересного или востребованного спикера, на которого пойдут участники, что позволит привлечь много денежных спонсоров и не только отбить, но и заработать на мероприятии (либо сразу, либо впоследствии). Для решения этой задачи в ход идут совершенно различные инструменты и подходы - давнее знакомство со спикером, запрос через друзей спикера, гонорар, запрос начальству, оплата перелета и проживания, предоставление доступа к материалам мероприятия, предоставление доступа к другим проектам организатора мероприятия и т.п. Кто-то считает, что выступить на их мероприятии - это уже само по себе ценно и поэтому спикеры должны быть рады самому факту их приглашения на мероприятие. Кстати, это местами действительно так. Если бы меня пригласили выступить на RSA Conference, то я мог бы считать это некоей вершиной (возможно, промежуточной) для себя, как для спикера.</p><p>Кто-то из организаторов заманивает к себе спикеров тем, что они повысят свою экспертность и смогут получать больше зарплату. Последнее, конечно, вызывает только улыбку. Если человек не эксперт, то никакое выступление его экспертность не повысит (разве что он получит еще один опыт выступления, что тоже полезно, но слушателям нужно не это). Если же он признанный эксперт, то участие в большинстве отечественных мероприятий по ИБ на его экспертности никак не скажется (разве что его пригласят выступать в Госдуме или для олигархов в Барвиха Luxury Village). Если человек - неопытный спикер, но он работает на стороне заказчика, то возможность ему поделиться опытом ценна само по себе (и тоже никак не влияет на экспертность). В любом случае, бартер "выступление за рост экспертности" - это демонстрация непонимания того, что нужно спикеру. </p><p>Попробую сформулировать причины, по которым спикер соглашается выступать на разных мероприятиях. Через многие из них я прошел за 30 лет в области ИБ, поэтому могу сказать, что они все имеют место быть (правда, на разных стадиях развития и известности спикера). Итак, я бы составил следующий перечень причин для выступлений:</p><p></p><ul style="text-align: left;"><li><b>Гонорар</b>. Это самая очевидная для спикера и самая нелюбимая для организатора причина. Правда, стоит помнить, что чем известнее спикер, тем... нет, не больше гонорар, тем выше у него доходы по его основному месту работы (есть такая корреляция) и поэтому гонорар становится не столь уж значимой причиной для выступления. Тем более, что организаторы часто оценивают выступление исходя из часовой ставки, забывая про время, затрачиваемое на подготовку. Хороший спикер, если он не мотивационный, очень редко когда читает одну и ту же презентацию из года в год. Хороший спикер для каждого нового выступления делает новую презентацию или мастер-класс, что требует в разы больше часов на подготовку, что тоже требует определенной компенсации. Но оплата выступления, как и вообще платные мероприятия, - это больная тема, про которую я <a href="https://lukatsky.blogspot.com/2013/10/blog-post_7.html">писал</a> еще 10 лет назад, но без особого результата. </li><li><b>Желание поделиться опытом</b>. Как говорил Жванецкий, писАть, как и пИсать надо тогда, когда уже невмоготу. Также и с выступлениями. Часто хочется поделиться своим опытом, своими знаниями в аудиторией. И уже это одно может быть хорошим стимулом для того, чтобы спикер сказал "да" организаторам. </li><li><b>Возможность обкатать новую тему</b>. У меня бывало так, что я погружался в некую тему, но у меня все не хватало времени на то, чтобы поставить в ней некоторую промежуточную точку. Я все откладывал, откладывал... Потом, организаторы мероприятия спрашивают меня, чтобы я мог рассказать и я называл незавершенную еще тему, которая, вдруг, заинтересовывала и организаторов и аудиторию. Ее вставляли в программу и это мотивировало меня довести дело до конца.</li><li><b>Оттачивание навыков выступления</b>. Для начинающего спикера это тоже может быть причиной, почему он соглашается на выступление. Опытный (во всех смыслах) обычно уже умеет говорить и правильно доносить свои мысли до аудитории. Начинающему это только предстоит. Выступление как раз и дает возможность наработать соответствующий опыт публичных выступлений. Организаторы его дают, получая взамен спикера. </li><li><b>Новый формат выступления</b>. Зато опытному спикеру может быть интересно обкатать новый формат выступления. Я под таким соусом раньше соглашался проводить киберучения или иные форматы с геймификацией, которые позволяют попробовать что-то новое. Существует под сотню разных форматов мероприятий по ИБ, которые можно опробовать, и иногда само это является интересной возможностью для спикера (если он такое практикует). </li><li><b>Интересное место выступления</b>. За свою жизнь я много где бывал, - и занимаясь туризмом в детстве и юности, и уже работаю и ездя в командировки. Поэтому интересное место, в которое спикер сам может быть никогда и не поедет, может стать прекрасным "гонораром" за выступление. Разумеется, это место должно быть интересным для спикера, а не для организатора. Мне вот интересно было бы посетить Камчатку и закрыть для себя "пояс гейзеров" (в Америке и в Исландии я уже их видел), Байкал или Путораны (это если рассматривать только российские места), но совсем неинтересно посетить Москву (да, иногда такое "интересное" место называют), Сочи (как говорилось в фильме "Москва слезам не верит", в Сочи хоть раз отдыхал каждый советский гражданин) и т.п. </li><li><b>Понимание целевой аудитории</b>. Где как не на мероприятиях можно услышать все, что целевая аудитория думает о вас и о вашем взгляде на мир (если, конечно, эта аудитория готова делиться этим взглядом, что тоже бывает не всегда)? Набившее оскомину выражение, что с аудиторией надо говорить на ее языке, может стать как раз той причиной, по которой вы согласитесь выступить где-то. Допустим, вы хотите понять, как и что думают об ИБ бухгалтера или кадровики? Или вас приглашают на мероприятие директоров по безопасности нефтяной компании? Это может быть мотивом для выступления. Если же речь идет об аудитории ибшников, то тут важно, кто они и будет ли у них возможность позадавать вам или вам им вопросы. </li><li><b>Возможность встретиться с друзьями</b>. В Фейсбуке частый комментарий по поводу того или иного мероприятия звучит так - "хочу встретиться с друзьями и коллегами". И иногда это действительно так. В обычной жизни сложно пересечься и пообщаться, а на мероприятии можно выкроить какое-то время для этого.</li><li><b>Новые знакомства</b>. Кому-то нужны не старые друзья, а новые знакомства и расширение своей "социальной сети". Может быть для будущего карьерного роста, может быть для поиска кандидатов к себе на работу, может быть для продажи своих продуктов и услуг.</li><li><b>Возможность послушать коллег и узнать что-то новое</b>. Спикеры такие же люди и также хотят получать новые знания, особенно в тех областях, в которых они не сильны. И возможность послушать других спикеров для них может являться очень интересным доводом сказать "да". Разумеется, если программа и спикеры интересные. Иногда спикеру можно предложить записи всех докладов, чтобы он смог в спокойной обстановке ознакомиться с ними.</li><li><b>Моя роль как спикера</b>. В качестве кого меня зовут? Ключевой спикер, открывающий мероприятие (мое эго скажет спасибо)? Спикер с 20-тиминутным докладом? Участник панельной дискуссии? Ведущий мастер-класса? Фасилитатор? Модератор? От этого тоже зависит принятие решения об участии в мероприятии. </li><li><b>Рост доверия и желание славы</b>. Если я, выступив на мероприятии, получу свои толику славы, массу оваций, знакомства с нужными людьми, рост доверия к персональному бренду, то кому-то это важнее всего остального. Хотя со временем понимаешь, что просто известность, неподкрепленная иными причинами, перестает быть главным мотивом для выступлений.</li><li><b>Карьерный рост</b>. Иногда организаторы ИБ-мероприятий приводят это в качестве заманухи на свои конференции. Если честно, то я не очень понимаю этого, так как зачастую именитые и известные спикеры сами являются высокопоставленными руководителями по ИБ и сами нанимают на работу, не ища такой возможности для себя. Если спикер начинающий, то да, у него может быть такая мотивация, но если она стоит во главе угла, то ничего хорошего из этого не выйдет. Если ты выступаешь, чтобы продать себя, а не чтобы поделиться полезным с аудиторией, то это видно сразу и отношение к такому спикеру будет соответствующим. Хотя да, он может добиться своей цели, но у аудитории он доверия больше вызывать не будет. </li><li><b>Новые лица</b>. У меня такого никогда не было, но пару раз я слышал от коллег высказывание: "Достали уже одни и те же спикеры на конференциях. Хочется новых лиц. Подамся с CFP". Да, у организаторов часто есть желание получить новые лица на мероприятие и на этот можно сыграть (правда, спикеру, а не организатору), подавшись со своим докладом и получив возможность разбавить "звезд советской эстрады", по 20 лет гастролирующих по России со своими "концертами".</li><li><b>Экономия</b>. Это другая сторона медали, связанной с предыдущей причиной. ИБшник хочет поехать на интересное ему мероприятие по ИБ, но у него на это нет денег. Тогда он подается как спикер и если его выбирают, то он сильно экономит на проезде и проживании на площадке мероприятия. </li><li><b>Репутация мероприятия</b>. Я выше уже писал, что есть ряд мероприятий, которые можно было бы назвать некоей вершиной для спикера по ИБ (у каждого такой перечень свой). И если у мероприятия уже сложилась репутация, то приобщиться к ней само по себе может являться очень ценным для спикера. </li><li><b>Организатор</b>. Есть организаторы, с которыми хочется работать снова и снова. У них отличная репутация и в какой-то момент времени у тебя даже дружеские отношения могут сформироваться с ними. Ты готов им помогать, зная, что тебя не кинут и не обманут. А есть организаторы токсичные, которые не выполняют своих обещаний, которые говорят одно, а делают другое. Ты можешь повестить один раз, другой, но потом уже формируешь собственный черный список и ни при каких условиях больше не соглашаешься участвовать в мероприятиях этого организатора. В свое время была такая история с компанией "Форт-Росс", которая проводила мероприятия для CISO (и для CIO), потом собрала денег на выездное мероприятие и не выполнила свои обязательства, а потом и вовсе была неприятная ситуация с акционерами. Бывали случаи, когда твои контактами организаторы торгуют или занимаются сводничеством. Бывает и так, что твой контент начинают продавать, даже не получив на это предварительного разрешения и, конечно, не выплачивая никакого роялти. Причем бывают вообще анекдотичные истории. Организаторы начинают продавать твои выступления, считая, что раз ты согласился у них выступить, то ты автоматом согласился, что твои выступления потом можно продавать, не платя тебе никакого вознаграждения. Потом оказывается, что они не смогли ничего продать и тогда тебе заявляют, что мы вам ничего не должны, так как никому ничего не продали (как связано неумение продавать с отказом от авторского вознаграждения я не знаю). А потом тебе еще и заявляют, что вы у нас в базе и мы будем продавать доступ к вашим контактам (позже оговорившись, что это будет с вашего согласия). Про законодательство о персональных данных, которое запрещает использовать персданные в целях, которые не были оговорены при их сборе, организаторы, видимо, не в курсе.</li><li><b>Спонсоры</b>. Иногда токсичными бывают не только организаторы, но и спонсоры, с которыми спикер может на захотеть связывать свое имя. Особенно если этот спонсор купил право вставить свой логотип в твой доклад/презентацию или ты должен модерировать секцию с его участием или у тебя и вовсе совместный доклад с ним. Но бывает и наоборот. Мероприятие проводится "при участии" именитой организации или даже регулятора, от которого на мероприятии будет высокопоставленный человек, доступ к которому интересен спикеру. Тоже вполне себе причина для участия в мероприятии.</li><li><b>Неудобно отказать</b>. Эту причину я комментировать не буду. Бывает, что тут сказать...</li></ul><p></p><p>Вот такой вот набор причин, почему спикер может сказать "Да" (или "Нет") участию в мероприятии по ИБ. Но если попробовать выразить все эти мотивы более коротко, то выступление - это время, которое помогает или не помогает спикеру достигать поставленных им самому себе целей (ну или его работодателем, но спонсорские выступления - это отдельная тема для обсуждения). Зная спикера, его мысли, его планы, его желания (а это отличает хорошего организатора мероприятий от временщика), можно предложить ему ровно то, что его заинтересует и что повысит шансы на его участие в мероприятии, от чего выиграют все - и спикер, и организатор, и аудитория. А в противном случае получается какая-то инфоцыганщина :-(</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh7nROqdndt5u10Gachk0WbdEvL3lMAD7bceI0iDzS7DO9JgdQsmxon_QogBb7jKLmf5WBC2hsPYebH4GUOVhSSO9eIm0O-2QXK-nm6PRpdSoTUY39Gdp0ZrFGpU1mtomPC-I_3k4Ds6dn/s1414/Screenshot+2021-07-18+at+15.42.03.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="590" data-original-width="1414" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgh7nROqdndt5u10Gachk0WbdEvL3lMAD7bceI0iDzS7DO9JgdQsmxon_QogBb7jKLmf5WBC2hsPYebH4GUOVhSSO9eIm0O-2QXK-nm6PRpdSoTUY39Gdp0ZrFGpU1mtomPC-I_3k4Ds6dn/s320/Screenshot+2021-07-18+at+15.42.03.png" width="320" /></a></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-40793340727320515372021-07-02T05:59:00.001+03:002021-07-02T05:59:00.277+03:00TARA - методология моделирования угроз и защитных мер от MITRE<p>В последнее время меня никак не отпускает тема моделирования угроз, что закономерно. Это один из последних документов регуляторов и по нему возникает немало вопросов. Но сегодня я буду писать не об этом. Сегодня я хотел бы подвести итог и завершить серию заметок, начатую во вторник. В них я описал подходы к ранжированию угроз/техник и мер защиты, список которых мы формируем в рамках моделирования угроз. Вчера я обещал назвать методику оценки негативных событий, в которой используются эти подходы. Речь идет о TARA - Threat Assessment & Remediation Analysis, методике, предложенной корпорацией MITRE еще в 2011-м году.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxIy2LizS1OPErfldqNfXjXRL2qbs3_y6NYQYEqDwgRup7FcU-NrXbII_HZXAVuOVxd8FIp0sXWuJJVbcnPwpIgGiuB6Q3-k6CMr0UsrSNrOHLPAvCQ5Rc8Ym4v1UZIZFGxniC5CRDwnzU/s1471/tara1.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="893" data-original-width="1471" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxIy2LizS1OPErfldqNfXjXRL2qbs3_y6NYQYEqDwgRup7FcU-NrXbII_HZXAVuOVxd8FIp0sXWuJJVbcnPwpIgGiuB6Q3-k6CMr0UsrSNrOHLPAvCQ5Rc8Ym4v1UZIZFGxniC5CRDwnzU/s320/tara1.jpg" width="320" /></a></div><div><br /></div>Методология TARA включает в себя три активности - анализ угроз (Cyber Threat Susceptibility Analysis), анализ защитных мер (Cyber Risk Remediation Analysis) и разработку данных и инструментов. Идеологически, методология TARA очень сильно похожа на то, что описано в методике оценки угроз ФСТЭК, но есть ряд нюансов, которые и отличают эти два подхода; причем существенно. <div><p>Я не буду подробно расписывать всю методику - все-таки 60 страниц лучше прочитать самостоятельно. Коснусь только ключевых моментов, которые и отличают TARA от методики, предложенной ФСТЭК:</p><p></p><ol style="text-align: left;"><li>Методика не является обятельной к применению. Право ее выбора лежит на потребителе.</li><li>TARA не ссылается на матрицу техник и тактик MITRE ATT&CK (ее еще тогда просто не было), но само понятие TTP в методике TARA присутствует ровно в том же контексте, что и в ATT&CK. В последующих версиях TARA это понятие немного трансформировалось в вектора атак, то есть последовательность действий, которые злоумышленник осуществляет для достижения своей цели, но суть опять же не поменялась.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZdTc9pAUYtlP1LmBmVu0EQsLu0wt4sf_jZI58oo6FnU_AlVn_szQvx5JO-cUTvJ084roqHBjOxIJisVdSegiE9OHnn-aAvnEBiA7RBH9HoZcJtNzDOrBgsi7wqZOIAYyfnmOFNwuJcTwG/s870/tara8.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="870" data-original-width="606" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgZdTc9pAUYtlP1LmBmVu0EQsLu0wt4sf_jZI58oo6FnU_AlVn_szQvx5JO-cUTvJ084roqHBjOxIJisVdSegiE9OHnn-aAvnEBiA7RBH9HoZcJtNzDOrBgsi7wqZOIAYyfnmOFNwuJcTwG/s320/tara8.png" /></a></div><br /></li><li>Указанные вектора атак объединяются в группы, которые могут быть классифицированы по разному. Обратите внимание, в конструкторе есть и группа техник MITRE ATT&CK и собственные варианты систематизации векторов атак. Например, у меня может быть группа векторов "аутентификация пользователя по паролю", а вектора, входящие в нее, - атаки по словарю, перебор паролей, радужные таблицы и т.п.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglbGul4A2g1Yj2wyRMLT_bLHBSOQRvj1m78-lydqMrCGQNGdDTmEGYtdsoHqvPuwVtflsjCsKGsDACVb9iseWwrCw2qxHokYz7xuRnngZFgy1kqyIFhKgKtF-onTkQvci8v7HfaiSqItq5/s1812/tara7.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1002" data-original-width="1812" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEglbGul4A2g1Yj2wyRMLT_bLHBSOQRvj1m78-lydqMrCGQNGdDTmEGYtdsoHqvPuwVtflsjCsKGsDACVb9iseWwrCw2qxHokYz7xuRnngZFgy1kqyIFhKgKtF-onTkQvci8v7HfaiSqItq5/s320/tara7.png" width="320" /></a></div><br /></li><li>Методика начинается с инвентаризации и оценки защищаемых активов, которая может быть выполнена как самостоятельно, так и с помощью другой методологии MITRE - CJA (Crown Jewels Analysis). При этом TARA не требует описания активов вплоть до интерфейсов и уровней, как это описано у ФСТЭК. Все чуть проще - Web-сервер, браузер, СУБД, приложение e-mail, коммутатор, УПАТС и т.п. Но при необходимости можно и углубиться в детали, если такая задача стоит. Например, сам каталог возможных активов достаточно обширен с точки зрения описываемых атакуемых объектов.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkLQlEfXbfKbdb8NMo5pj_zoTWu213D1yA-ikKtPRvSpcAeWCFNdKOFYzR-SsDHQI3hI0XGlVTBZmwuNZfpK8z3L_RMVxsICBWCkElqtfwCSa3SkAhV4UClaboXoWG9OwjLEVE1BsQMhgH/s658/tara9.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="658" data-original-width="629" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkLQlEfXbfKbdb8NMo5pj_zoTWu213D1yA-ikKtPRvSpcAeWCFNdKOFYzR-SsDHQI3hI0XGlVTBZmwuNZfpK8z3L_RMVxsICBWCkElqtfwCSa3SkAhV4UClaboXoWG9OwjLEVE1BsQMhgH/s320/tara9.png" /></a></div><br /></li><li>Методика очень сильно завязана на так называемые каталоги, которые и содержат уже скрупулезно собранные и систематизированные техники и тактики угроз, вектора атак, защитные меры, активы и т.п. Эти каталоги позволяют легко автоматизировать процедуру моделирования угроз. Модель данных этих каталогов выглядит следующим образом:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxlOF3HlBOQ7EoQ12-vKsIJzY0-6C-FhB68Q852IFTRWxhyphenhyphenxnS7lZJ0n1rPvxtQMQCPlcdF1Ol1Vby8fN6WGyLl9LHwPabJq12RfHRLAuyCIs_W5i_jdJqUb0qWWwdlLucxRERlVAZKNAj/s1058/tara3.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="474" data-original-width="1058" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxlOF3HlBOQ7EoQ12-vKsIJzY0-6C-FhB68Q852IFTRWxhyphenhyphenxnS7lZJ0n1rPvxtQMQCPlcdF1Ol1Vby8fN6WGyLl9LHwPabJq12RfHRLAuyCIs_W5i_jdJqUb0qWWwdlLucxRERlVAZKNAj/s320/tara3.png" width="320" /></a></div><br /></li><li>Наличие в каталогах данных как из открытых, так и закрытых источников. В зависимости от оцениваемого объекта такое деление позволяет использовать более широкий круг источников данных, в том числе и грифованных, для оценки возможных векторов атак и негативных последствий от их использования. Из открытых источников TARA использует CAPEC, CWE, CVE. </li><li>Скоринговая оценка угроз и защитных мер, описанных в трех предыдущих заметках. При этом рейтинг угрозы оценивается для разных типов нарушителей, коих TARA выделяет всего три - внешний, внутренний и привилегированный внутренний. Я не разделяю позицию, что нарушителей надо делать на внешних и внутренних, но в 2011-м году такой подход мог быть вполне разумным. Сейчас я бы отталкивался от другой классификации нарушителей, но идею по разному ранжировать угрозы, в зависимости от того, кто их реализует, я вполне поддерживаю. Вот как это выглядит в оригинальной методике TARA.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEht9jFkQOJ1Djp34vMzYnPLRosCRJY_TZWf-QjXG-2oxSYSAbhrGfpvdAkpINPN8_pCIc-oVFllCsdoWFvqiDbAR7UhrPsp35tNaT5gNhfdSPeQy1hZ00uBE-H8AiFerADrxL6cndLNqLnH/s899/tara2.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="725" data-original-width="899" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEht9jFkQOJ1Djp34vMzYnPLRosCRJY_TZWf-QjXG-2oxSYSAbhrGfpvdAkpINPN8_pCIc-oVFllCsdoWFvqiDbAR7UhrPsp35tNaT5gNhfdSPeQy1hZ00uBE-H8AiFerADrxL6cndLNqLnH/s320/tara2.png" width="320" /></a></div><br /></li><li>TARA предлагает нейтрализовывать не все актуальные угрозы, а согласно их рейтингу. Другой предлагаемой стратегией является нейтрализация угроз, в зависимости от важности актива. </li><li>В первоначальной версии TARA все защитные меры оценивались не по трем типам эффекта (предотвращение, обнаружение и реагирование), которые я описал вчера, а по 4-м - нейтрализация угрозы, ее обнаружение, ее ограничение и восстановление после нее. Но после появления фреймворка NIST CSF подход немного изменили.</li><li>Итогом моделирования угроз по TARA было составление оптимального перечня защитных мер, которые обеспечивали бы эффективную защиту от угроз/техник с минимальными затратами на внедрение и эксплуатацию.</li><li>Автоматизация оценки, которая заключается в том, что все каталоги и интерфейсы для моделирования размещены в инфраструктуре MITRE, что позволяет не только обеспечить конфиденциальность проводимой оценки, но и ускорить процесс моделирования в разы по сравнению с самостоятельной разработкой инструментария для оценки.</li><li>Интересно, что уже в 2011-м году среди угроз, которые могли быть проанализированы TARA, предусматривались не только киберугрозы, но и угрозы воздействия по техническим каналам, а также угрозы цепочке поставок.</li><li>Упомянутые в начале заметки инструменты позволяют как создавать новые записи в каталогах, так и импортировать/экспортировать их их/во внешние системы в формате XML, искать в каталогах, а также генерить различные отчеты. Например, вот так выглядят интерфейсы создания новой техники реализации угроз, новой защитной меры и маппинг защищаемого актива в техники реализации угроз.<br /><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipfiqNfYAfgn7SMuGOLWKq61Tx9gzUPJdnqQarZSztONZ59uRp_wr8kWaTWqkQXg-tySUb3q6w3trDHuR_f0oR5Z6RVTPoE54v1N_wvtZavgQZ-MLEQeWD_eKxV2h9NmmBT1huyrTX1BRd/s1045/tara4.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="833" data-original-width="1045" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipfiqNfYAfgn7SMuGOLWKq61Tx9gzUPJdnqQarZSztONZ59uRp_wr8kWaTWqkQXg-tySUb3q6w3trDHuR_f0oR5Z6RVTPoE54v1N_wvtZavgQZ-MLEQeWD_eKxV2h9NmmBT1huyrTX1BRd/s320/tara4.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Описание угрозы</td></tr></tbody></table><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5KuW75m0IEhKOFVBUKWKOfIuo25MY1GfKeItW1mcra773AjVf35v9Gp3rdcJbY0N8xwqDu2NJivXICVui8GX49r8Jx3zrZIQE0g9Q_1iyDgVWWvesUcQXaA6tVoFuhwQOrRm1klwaDWX9/s1170/tara5.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="712" data-original-width="1170" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi5KuW75m0IEhKOFVBUKWKOfIuo25MY1GfKeItW1mcra773AjVf35v9Gp3rdcJbY0N8xwqDu2NJivXICVui8GX49r8Jx3zrZIQE0g9Q_1iyDgVWWvesUcQXaA6tVoFuhwQOrRm1klwaDWX9/s320/tara5.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Описание защитной меры</td></tr></tbody></table><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwEhZVnE4mllG24gI4q9pj15P33glsCInXM30qy588Cshyphenhyphen9l1dudUfPHUQSZAl6YF23JlxmmgXLAoFynEQR5AlqZKQvc4jar1AtFjaOU5j-8svSXkT7IMxlBHWtPFZtdAeKKrGNk_TtRDI/s858/tara6.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="787" data-original-width="858" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwEhZVnE4mllG24gI4q9pj15P33glsCInXM30qy588Cshyphenhyphen9l1dudUfPHUQSZAl6YF23JlxmmgXLAoFynEQR5AlqZKQvc4jar1AtFjaOU5j-8svSXkT7IMxlBHWtPFZtdAeKKrGNk_TtRDI/s320/tara6.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Маппинг актива в угрозы</td></tr></tbody></table><br /></li><li>Если первые версии TARA не фокусировались на нарушителях, то текущая версия уделяет этому вопросу немало внимания, требуя составить профиль нарушителя, который базируется на трех ключевых элментах - мотивация (зачем кому-то вас атаковать), цели (разведка, утечка, кража, удар по репутации и т.п.) и возможности для реализации угроз. Все эти параметры нарушителей могут меняться с течением времени, поэтому процесс составления "модели нарушителя" не статический и не одноразовый, а динамичный, требующий автоматизации.</li><li>Еще одним важным, и ранее отсутствующим элементом TARA, является определение поверхности атаки, которая определена как последовательность шагов нарушителя для достижения атакуемого объекта из точки входа. Понятно, что при одной точке входа и объекте атаки путей между ними может быть несколько. Также очевидно, что из одной точки входа можно попасть в множество целей, одну цель можно достичь из разных точек входа, а также что цель в случае ее компрометации может стать точкой входа для дальнейших атак. Точками входа по TARA могут быть запросы к полям баз данных, USB-порты, пользовательские учетные записи, вложения в e-mail и загружаемые из Интернет файлы, временные сетевые соединения, процессы обновления системы и т.п. В каталогах TARA многие из векторов атак, обеспечивающих переход из точки входа в точку назначения, уже прописаны и их надо просто выбирать из готового списка. Авторы TARA говорят, что более 25 векторов атак оценивать достаточно сложно. </li><li>Опираясь на описанные выше данные, мы составляем список сценариев реализации угрозы, которые в отличие от векторов атак и их групп, дополнены контекстом для лучшего понимания актуальных угроз. В отличие от методики ФСТЭК TARA не требует перебора всех возможных сценариев, привязанных к техникам и тактикам.<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjZBO47n976XmHjmt1ImbF9CnbU7qPIKrH5xRx0p6QVJUv8PQVA7cdJKBrOAVP0MvAYZ-PrJcrhNOIfPsUiEhtYvT1TLmhzuxZIgb2uNJSZt0I5eWygVkancroIrdIS26uApPFC6k0jisa/s1733/tara10.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="797" data-original-width="1733" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgjZBO47n976XmHjmt1ImbF9CnbU7qPIKrH5xRx0p6QVJUv8PQVA7cdJKBrOAVP0MvAYZ-PrJcrhNOIfPsUiEhtYvT1TLmhzuxZIgb2uNJSZt0I5eWygVkancroIrdIS26uApPFC6k0jisa/s320/tara10.png" width="320" /></a></div></li></ol><p></p><p>Вот такая методика была предложена MITRE десять лет назад. Во многом она похожа на то, что предложила ФСТЭК в феврале, но все-таки есть и пара коренных отличий, а именно необязательность как самой методики, так и ее отдельных элементов, а также глубокая автоматизация работы на разных этапах моделирования, снижающих волюнтаризм экспертов и ускоряющих сам процесс. Кстати, о времени, которое требуется на моделирование угроз по методике TARA. По оценкам ее авторов - вся процедура занимает 13 недель, то есть полный квартал с небольшим. И это при полной автоматизации. Так что делаем выводы о том, сколько может занять моделирование угроз по текущему варианту методики нашего регулятора в области защиты информации. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmeK4IGexw95LXtG-ZNemQxeH2uFebFVaWyfpUTrWzuV7IVBuo4rvvSrmSwXlBhCtaM3UfgP83D42-VuBdExMnI2At5_GyN51RbiKb-suNjgj_6TPFVkLrxi8h_kkOzHQoBkvFhkhwF80n/s1560/Screenshot+2021-06-29+at+16.04.59.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="802" data-original-width="1560" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmeK4IGexw95LXtG-ZNemQxeH2uFebFVaWyfpUTrWzuV7IVBuo4rvvSrmSwXlBhCtaM3UfgP83D42-VuBdExMnI2At5_GyN51RbiKb-suNjgj_6TPFVkLrxi8h_kkOzHQoBkvFhkhwF80n/s320/Screenshot+2021-06-29+at+16.04.59.png" width="320" /></a></div></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com2tag:blogger.com,1999:blog-4065770693499115314.post-18975670617542862302021-07-01T05:47:00.004+03:002021-07-01T05:47:00.257+03:00Выбор защитных мер: финальный подсчет рейтинга<p>Вчера я упомянул, что выборе защитных мер мы не только оцениваем стоимость их внедрения и эксплуатации, но и эффективность, которая в самом простейшем случае определяется тем, сколько угроз можно нейтрализовать с помощью конкретной защитной технологии, средства или меры. Это можно легко изобразить в виде матрицы.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmrbjzdxnbASqj4iZijcmnpzQAJBTDiTGDRPMuRhYsSyFm3ofR8CQk6E0NtYTSm8a2F9x5LOfTo1VcttsONRnki7r8qcxPV-T09om4WMalqy1vkUB3beFs8zotLU9OZ-71DVrv1h72sRfO/s2560/Screenshot+2021-06-28+at+19.01.58.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="700" data-original-width="2560" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhmrbjzdxnbASqj4iZijcmnpzQAJBTDiTGDRPMuRhYsSyFm3ofR8CQk6E0NtYTSm8a2F9x5LOfTo1VcttsONRnki7r8qcxPV-T09om4WMalqy1vkUB3beFs8zotLU9OZ-71DVrv1h72sRfO/s320/Screenshot+2021-06-28+at+19.01.58.png" width="320" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div>Мы видим, что мера 1 "закрывает" 5 угроз, 6-я и последняя мера - по 3, а остальные по 2 угрозы. Выбор в пользу первой меры не вызывает вопросов - с ее помощью мы сможем нейтрализовать большее число угроз. Но у данного подхода, несмотря на его очевидные преимущества, есть и один недостаток. Он не учитывает эффект, которого достигает защитная мера. Если вспомнить NIST Cybersecurity Framework, то все защитные меры там разделены на 5 блоков - идентификация, предотвращение, обнаружение, реагирование и восстановление. Это и есть эффекты защиты, которые, для упрощения (если функцию восстановления отдать в ИТ, а функцию идентификацию реализовывать по любому), можно свести к трем:<div><ul style="text-align: left;"><li>Предотвращение. Защитные меры этого типа делают атаку невозможной. Например, межсетевой экран или средство установки патчей.</li><li>Обнаружение. Защитные меры этого типа позволяют определить, что атака/угроза произошла, происходит или может произойти. Сюда можно отнести антиспам, обнаружение вторжений и т.п.</li><li>Реагирование. Защитные меры этого типа позволяют снизить негативнвй эффект в случае реализации угрозы.</li></ul><div>Понятно, что одна и та же защитная мера может иметь разный эффект на разные угрозы, а также несколько разных эффектов на одну и ту же угрозу. </div><p>Поэтому в матрице выше стоит ставить не просто крестик, а указывать конкретный эффект от защитной меры. Зачем нам защитная мера, которая позволяет только обнаруживать угрозы, но никак на них не реагирует? Вспоминая вчерашнюю таблицу показателей защитной меры, мы понимаем, что их зрелость может быть разной. Туже самую идею можно применить и к эффекту от защитной меры и выделить для них три уровня:</p><p></p><ul style="text-align: left;"><li>Высокий. Эффект защитной меры подтвержден демонстрацией, сертификацией, тестами, пилотом и т.п.</li><li>Средний. Оценка эффекта защитной меры базируется на предположении эксперта.</li><li>Низкий. Эффект имеет правдоподобную картину, но еще никак не подтвержден.</li></ul><p>В итоге, если мы объединим эффект защитной меры с его уровнем и поместим в матрицу, то мы получим следующий вариант (P, D и R означают эффект - prevention, detection и response, а H, M и L - уровень - High, Medium и Low):</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiD6T45ADyZnlWi9n34BCoo1FoVhRM-MFysZB0OB65J53kNhQ3aikVvOsIBCpdpDDBO-Ydsj-oV37nNbmcAeSydic26CW24RuQPhvXJP2aeODGUEtHIs78X0msOYCGrgos__gp2bcHZh9QR/s2470/Screenshot+2021-06-28+at+19.32.11.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="788" data-original-width="2470" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiD6T45ADyZnlWi9n34BCoo1FoVhRM-MFysZB0OB65J53kNhQ3aikVvOsIBCpdpDDBO-Ydsj-oV37nNbmcAeSydic26CW24RuQPhvXJP2aeODGUEtHIs78X0msOYCGrgos__gp2bcHZh9QR/s320/Screenshot+2021-06-28+at+19.32.11.png" width="320" /></a></div><div><br /></div>Обратите внимание - результат поменялся, так как первая мера защиты много обнаруживает, но ничего не предотвращает и не снижает негативный эффект от обнаруженных угроз. В итоге рейтинг защитных мер у нас поменялся, но стал выглядеть более адекватным. К нему можно также добавить еще и веса, но это уже опционально.</div><div><p>Если сложить А и Б, вчерашний рейтинг защитный меры и сегодняшний, то поделив сегодняшний рейтинг на вчерашний и умножив результат на 100, мы и получим итоговый рейтинг защитной меры, проранжировав которые мы получим список того, с чего стоит начинать построение системы защиты. Можно использовать и иные стратегии выбора. Например, выбирать наименее затратные (по вчерашнему рейтингу) технологии ИБ или самые эффективные (по сегодняшнему).</p><p>Последние три дня я уделил внимание тому, как ранжировать угрозы и нейтрализующие их защитные меры. Завтра мы соберем все эти кусочки пазла вместе и я покажу, что за методика моделирования угроз работает по этому принципу.</p></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-62323778385087855632021-06-30T05:58:00.006+03:002021-06-30T05:58:00.277+03:00Ранжирование защитных мер: практичный подход<p>С ранжированием угроз мы разобрались вчера, но что делать с ситуацией, когда у меня для нейтрализации угрозы подходит сразу несколько защитных мер? Возьмем, к примеру, угрозу вредоносного кода для мобильного устройства. Как я могу ее нейтрализовать? Сходу я вижу несколько вариантов - установка средства защиты от вредоносного кода (читай, мобильного антивируса), создание замкнутой программной среды с помощью MDM, перенаправление всего трафика с мобильного устройства на сетевой шлюз нейтрализации вредоносного кода, мониторинг компрометации. У каждого из этих вариантов есть свои плюсы и минусы, своя стоимость владения, а также возможность нейтрализации и других угроз (всегда неплохо, если одним средством можно "убить сразу нескольких зайцев", сэкономя деньги компании). Как выбрать из них ту меру, которая будет подходить нам лучше всего?</p><p>Можно оценить любую защитную меру с трех позиций - покрытие угроз (чем больше угроз покрывает защитная мера, тем лучше), стоимость внедрения и стоимость эксплуатации. При этом второй показатель складывается из стоимости разработки (покупки) защитной меры, стоимости ее тестирования (пилотирования) и стоимости интеграции защитной меры в защищаемую среду. Стоимость эксплуатации в свою очередь также складывается из ряда параметров - стоимость обслуживающего персонала (можно иметь классную систему защиты, но не иметь персонала, умеющего с ней работать), стоимость обучения персонала (попробуйте найти в России или СНГ нормальные курсы по threat hunting или SOCам), стоимость обслуживания, поддержки, утилизации и перехода на новую или обновленную меру.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1v-0B6CUWmxs-D6efwIj73F0iq-pt45BUX3jrj0ahC8G0QAXhaN5shqgsRqwuwdpf9TXURRhLAoMLfC1ZY5bEOTmYnxAlPAGNCdYsshvzlogEYdeRyKQcirs9JMfgwrcy6TolhrlyI82E/s2286/Screenshot+2021-06-27+at+17.31.16.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1010" data-original-width="2286" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg1v-0B6CUWmxs-D6efwIj73F0iq-pt45BUX3jrj0ahC8G0QAXhaN5shqgsRqwuwdpf9TXURRhLAoMLfC1ZY5bEOTmYnxAlPAGNCdYsshvzlogEYdeRyKQcirs9JMfgwrcy6TolhrlyI82E/s320/Screenshot+2021-06-27+at+17.31.16.png" width="320" /></a></div><p>Как и в случае с ранжированием угроз, ключевым является введение шкалы значений показателей и их веса, которые позволяют получить некую усредненную картину по каждой защитной мере. Да, у разных экспертов могут отличаться взгляды на зрелость защитной меры или необходимые для ее внедрения ресурсы и возможности, но по другим показателям такие отличия будут минимальны. Да и по спорным моментам все-таки мы получаем единую шкалу измерения, которая лучше чем просто экспертная оценка. </p><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNZjlEKZmLMW8i9MeObHhqOCA61OSNANBdqY5IaG_dkyOkLA0mh5Jf2_VVHn94vvqlTxAWSH8hyphenhypheneTHIJaqjKFK2_7aEoVjWQLiQCwJCH-mbR0BLA5KyxiECDKcbMqng-g-kArYAmnLXxC4/s2306/Screenshot+2021-06-27+at+17.31.30.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="732" data-original-width="2306" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNZjlEKZmLMW8i9MeObHhqOCA61OSNANBdqY5IaG_dkyOkLA0mh5Jf2_VVHn94vvqlTxAWSH8hyphenhypheneTHIJaqjKFK2_7aEoVjWQLiQCwJCH-mbR0BLA5KyxiECDKcbMqng-g-kArYAmnLXxC4/s320/Screenshot+2021-06-27+at+17.31.30.png" width="320" /></a></div><br />В принципе, уже описанного метода ранжирования достаточно для того, чтобы оценивать защитные меры и выбирать между ними, опираясь на более менее точные оценки, а не банальную экспертную оценку методом "пальцем в небо". Однако можно пойти чуть дальше и еще улучшить выбор защитных мер, но об этом мы поговорим завтра.<p></p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-81587971195809386532021-06-29T05:14:00.003+03:002021-06-29T05:14:00.258+03:00Ранжирование угроз и их техник: практичный подход<p>Почти любая методика оценки угроз начинается с того, что вы составляете перечень всех возможных угроз, после чего начинаете отсекать все неактуальное. При этом актуальность обычно определяется экспертным путем, что приводит к определенному волюнтаризму в оценках и отсутствию повторяемости результатов при обращении к другому эксперту. Хорошая методика оценки угроз должна снижать фактор предвзятости эксперта и стараться получать воспроизводимые результаты раз за разом.</p><p>Сегодня хочется попробовать описать один из вариантов, который может помочь не только облегчить процесс оценки угроз, но и автоматизировать его. Идея достаточно проста и ее можно применить к абсолютно любой методике оценки угроз, в том числе и к ФСТЭКовской. Каждая угроза характеризуется набором показателей - наличие доступа для реализации угрозы, масштаб последствий, требуемое время восстановления, легкость обнаружения, необходимые навыки для реализации, требуемые ресурсы и т.п. Так вот, чтобы прийти к воспроизводимости результатов надо варианты ответов по каждому из них ранжировать по трех- или пятибалльной шкале, а самим показателям присвоить определенные веса. После этого механизм расчета величины угрозы превратится в банальную задачу, которую можно автоматизировать даже в Excel.</p><p>Ниже я привожу один из возможных вариантов такого расчета. Пять градаций могут быть заменены на три, а количество показателей может быть как увеличено, так и уменьшено. Значения весов также указаны для примера - в конкретной ситуации с ними можно "поиграться" для достижения лучших результатов в той или иной организации. Например, в данном примере веса факторов, связанных с последствиями нарушения конфиденциальности и доступности выше, чем для нарушения целостности. Чем выше значение фактора (от 1 до 5), тем опаснее угроза. Кстати, точно по такой же методике можно оценивать и техники угроз. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjE_wFcWKnRQ0GpQtXw3KR16YvLARQZb1V4-CYVcsrD-NW68AFqen9PE_FC_hQmsceLivlgRby0ORW1lVtIZq_OjDIzpcTL7drWiuel3-s3MrAg0bVyE2_yFIccfPB2ho_yk2nKo3zKTAs/s2048/Screenshot+2021-06-27+at+13.12.30.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1032" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjE_wFcWKnRQ0GpQtXw3KR16YvLARQZb1V4-CYVcsrD-NW68AFqen9PE_FC_hQmsceLivlgRby0ORW1lVtIZq_OjDIzpcTL7drWiuel3-s3MrAg0bVyE2_yFIccfPB2ho_yk2nKo3zKTAs/s320/Screenshot+2021-06-27+at+13.12.30.png" width="320" /></a></div><div><br /></div><div>Для части показателей, чем выше их значение, чем угроза становится менее опасной. Может быть это не сразу становится понятным, но логика в этом есть. Чем сложнее атака, тем ниже вероятность ее реализации и, как следствие, ниже итоговый рейтинг. Хотя не исключаю, что под конкретные задачи можно пойти и привычным путем и более сложную атаку (и в части ресурсов, и в части детектируемости) считать и более опасной.</div><br /><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWk7vE5LqhX5hgstQ6Bns7o_ZKitQ-LXSrmEtBtjFKmdiWcV6WApMd6osaC61BlS1xwZvvghyphenhyphen-rjpL-2zYcmz1Ii8Hk1nVDziijj6DTK9EC13LPgn678klAjKaFi79yC_0NJYIStI5fBFd/s2208/Screenshot+2021-06-27+at+13.12.55.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="724" data-original-width="2208" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiWk7vE5LqhX5hgstQ6Bns7o_ZKitQ-LXSrmEtBtjFKmdiWcV6WApMd6osaC61BlS1xwZvvghyphenhyphen-rjpL-2zYcmz1Ii8Hk1nVDziijj6DTK9EC13LPgn678klAjKaFi79yC_0NJYIStI5fBFd/s320/Screenshot+2021-06-27+at+13.12.55.png" width="320" /></a></div><div><br /></div><p>После того, как для каждой угрозы/техники указываются их значения, осуществляется подсчет итогового значения рейтинга (сумма по всем показателям, умноженным на весовые коэффициенты), что и позволяет нам получить не просто список всех актуальных угроз, а угроз систематизированных по уровню опасности для нашей компании. В примере выше 4 "фиолетовых" показателя имеют нулевые веса и соответственно в расчете не учитываются. В реальности это происходит очень часто - мы просто не можем оценить отдельные показатели по угрозы - требуемые ресурсы и навыки, легкость атрибуции и т.п. Но тогда надо учесть, что такие показатели с нулевым весом будут приводить к автоматическому снижению рейтинга угроз, хотя и незначительно.</p><p>У данного подхода есть, как минимум, три преимущества. Во-первых, он легко автоматизируется - я прикладываю к заметке табличку в Excel, которую вы можете использовать для своих нужд и которая позволит вам ускорить процесс моделирования. Во-вторых, такое матричное представление и ранжирование угроз гораздо более компактное и помещается на половине страницы А4, что позволяет методики на ее основе делать также более компактными. Наконец, если вдруг возникнет задача обмена моделями угроз или их согласования, то отправить табличку в Excel гораздо проще, чем 200-300 страниц в Word. Да и проверять и согласовывать такие таблицы гораздо проще, чем вникать в сотнистраничные манускрипты.</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com5tag:blogger.com,1999:blog-4065770693499115314.post-83027478436982443122021-06-28T05:06:00.001+03:002021-06-28T05:06:00.948+03:00Не методикой ФСТЭК единой или модели угроз, утвержденные государством российским<p>Разрешая операторам информационных систем различного типа самостоятельно проводить оценку и моделирование угроз, наши регуляторы не забывают выпускать и собственные перечни негативных событий, которые по разумению регуляторов в обязательном порядке должны быть учтены в рамках выстраивания системы защиты информации в той или иной области. Учитывая, что сейчас таких моделей/перечнем стало немало, я подумал, что было бы правильно собрать их в рамках одной заметки, к которой можно было бы обращаться по мере необходимости. При этом стоит обратить внимание, что пока 90% этих моделей крутится вокруг всего одной темы - персональные данные, в том числе и биометрические.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEslZOq63IH1SAMnX5Z4I7ZiDi9Bd5fAB1qEoeBx9cFPH0y_0jqwVb3vuUh7RnfUD8Bs6tuROIqcDmIpaNbuqR7lnAmcecDj01XHrUYbW6oDvgI9JOCIb_uDrXM4CwnKDBBz48zBHBvSFE/s800/batman-threat-model-1200-800x535.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="535" data-original-width="800" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhEslZOq63IH1SAMnX5Z4I7ZiDi9Bd5fAB1qEoeBx9cFPH0y_0jqwVb3vuUh7RnfUD8Bs6tuROIqcDmIpaNbuqR7lnAmcecDj01XHrUYbW6oDvgI9JOCIb_uDrXM4CwnKDBBz48zBHBvSFE/s320/batman-threat-model-1200-800x535.png" width="320" /></a></div><p>Итак, на первое место я поставлю <a href="https://fstec.ru/en/114-tekhnicheskaya-zashchita-informatsii/dokumenty/spetsialnye-normativnye-dokumenty/379-bazovaya-model-ugroz-bezopasnosti-personalnykh-dannykh-pri-ikh-obrabotke-v-informatsionnykh-sistemakh-personalnykh-dannykh-vypiska-fstek-rossii-2008-god">базовую модель угроз</a> безопасности персональных данных при их обработке в ИСПДн (<a href="http://www.consultant.ru/document/cons_doc_LAW_99662/">она же в Консультанте</a>), выпущенную ФСТЭК в 2008-м году. Несмотря на выпущенную в 2021-м году методику оценки угроз, которая отменила методику оценки угроз безопасности ПДн 2008-го года, базовую модель при этом никто не отменял, что заставляет задавать вопросы, какой статус этой базовой модели, празднующей свое 13-тилетие. </p><p>На второе место можно смело ставить модель угроз безопасности ПДн, выпущенную в 2015-м году Банком России и утвержденную в виде <a href="http://www.consultant.ru/document/cons_doc_LAW_195662/">Указания Банка России</a> от 10.12.2015 №3889-У "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных".</p><p>Спустя 3 года после предыдущего нормативного акта банковский регулятор выпустил новый документ - <a href="https://www.garant.ru/products/ipo/prime/doc/71908502/">Указание Банка России</a> от 9 июля 2018 года №4859-У "О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации", в единой биометрической системе". Однако, ввиду серьезной переработки законодательства о ЕБС и навязывании ее везде и всем, Банк России <a href="https://www.cbr.ru/Queries/XsltBlock/File/90538/4480">решил отменить</a> данное Указание, предложив вместо него два новых проекта, которые должны быть приняты в этом году:</p><p></p><ul style="text-align: left;"><li><a href="http://www.garant.ru/products/ipo/prime/doc/400173822/">Проект Указания Банка России</a> "О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица, при взаимодействии организаций финансового рынка с единой биометрической системой с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных"</li><li><a href="https://www.garant.ru/products/ipo/prime/doc/400483073/">Проект Указания Банка России</a> "О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в информационных системах организаций финансового рынка, осуществляющих идентификацию и (или) аутентификацию с использованием биометрических персональных данных физических лиц, за исключением единой биометрической системы, а также актуальных при взаимодействии организаций финансового рынка, иных организаций, индивидуальных предпринимателей с указанными информационными системами, с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных"</li></ul>Минцифры также решило вступить в гонку по подготовке нормативных правовых актов в области моделирования угроз и представило в прошлом году два новых приказа, которые устанавливали перечни угроз, нейтрализация которых должна была быть обязательно реализована при работе аккредитованного удостоверяющего центра (но тоже речь идет о биометрии), а также в ИСПДн, находящихся в сфере регулирования Минцифры:<p></p><p></p><ul style="text-align: left;"><li><a href="https://digital.gov.ru/ru/documents/7526/">Приказ Минцифры</a> от 26.11.2020 № 624 «Об утверждении перечня угроз безопасности, актуальных при идентификации заявителя – физического лица в аккредитованном удостоверяющем центре, выдаче квалифицированного сертификата без его личного присутствия с применением информационных технологий путем предоставления сведений из единой системы идентификации и аутентификации и единой информационной системы персональных данных, обеспечивающей обработку, сбор и хранение биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации, а также хранении и использовании ключа электронной подписи в аккредитованном удостоверяющем центре».</li><li><a href="http://publication.pravo.gov.ru/Document/View/0001202106010042">Приказ Минцифры</a> от 21.12.2020 № 734 "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых в сферах деятельности, нормативно-правовое регулирование которых осуществляется Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации".</li></ul>Кроме того, Мицифры подготовило еще один <a href="http://www.consultant.ru/cons/cgi/online.cgi?req=doc;base=PNPA;n=71830">проект приказа</a>, который также касается угроз биометрическим ПДн, - "Об утверждении перечня угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в информационных системах организаций, осуществляющих идентификацию и (или) аутентификацию с использованием биометрических персональных данных физических лиц, за исключением единой биометрической системы, а также актуальных при взаимодействии государственных органов, органов местного самоуправления, индивидуальных предпринимателей, нотариусов и организаций, за исключением организаций финансового рынка, с указанными информационными системами, с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных, и учетом вида аккредитации организации из числа организаций, указанных в частях 18.28 и 18.31 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации".<div><p></p><p>Минцифры вернулось в стройные, но плохо согласующие свои действия, ряды регуляторов по ИБ относительно недавно. Лет 10 от них ничего в этой области не было слышно, хотя раньше они были вполне активны и выпускали/согласовывали разные документы по защите информации. Одним из таких документов была "<a href="https://digital.gov.ru/common/upload/publication/1410065MC.pdf">Модель угроз и нарушителя безопасности ПДн, обрабатываемых в ИСПДн отрасли [связи]</a>", согласованная с ФСТЭК и ФСБ России. Текущий статус этого документа ввиду выхода новой методики ФСТЭК не совсем ясен (хотя с сайта министерства она не убрана) и возможно новый руководитель департамента кибербезопасности Минцифры наведет порядок в том, что делали его предшественники, коих сменилось на этом посту не мало. </p><p>При этом не забывайте, что помимо указанных нормативных актов, выпущенных регуляторами и действующими на территории всей страны, существует немало перечней угроз ПДн, которые утверждались или каким-либо субъектом РФ, или каким-то министерством для себя и своих поднадзорных структур. Например, <a href="http://docs.cntd.ru/document/550114960">приказ Департамента здравоохранения</a> Курганской области от 30 мая 2018 года №632 "Об утверждении Перечня угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных в Департаменте здравоохранения Курганской области и подведомственных ему учреждениях, организациях", <a href="http://www.consultant.ru/document/cons_doc_LAW_335487/">приказ Минэнерго</a> от 02.08.2019 №819 "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении Минэнерго России функций, определенных законодательством Российской Федерации" или <a href="http://base.garant.ru/47309504/">Постановление Правительства Пензенской области</a> от 20.04.2017 №192-пП "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных Пензенской области" (почти в каждом субъекте РФ есть такое постановление).</p><p>Немного особняком стоит тема моделирования угроз, а точнее атак, на средства криптографической защиты информации. И если раньше ею можно было и не заниматься, так как обычно все эти вопросы ложились на производителей СКЗИ, которые и должны были решить эту задачу, то сейчас ситуация меняется. ФСБ подготовило <a href="https://regulation.gov.ru/projects#npa=110754">проект приказа</a> "Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, с использованием средств криптографической защиты информации", а последние правки в <a href="http://pravo.gov.ru/proxy/ips/?docbody=&nd=102375086">Постановление Правительства</a> от 6 июля 2015 №676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации". Оба документа подразумевают согласование модели угроз с ФСБ, что заставляет нас задумываться о том, есть ли утвержденные этим, уже 4-м в сегодняшней заметке регулятором, перечни угроз безопасности? На самом деле их нет. Но есть документы, на которые стоит ориентироваться при составлении модели угроз (атак) на СКЗИ:</p><p></p><ul style="text-align: left;"><li><a href="http://www.consultant.ru/document/cons_doc_LAW_167862/">Приказ ФСБ</a> от 10.07.2014 №378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности".</li><li><a href="http://www.fsb.ru/files/PDF/Metodicheskie_recomendacii.pdf">Методические рекомендации</a> ФСБ по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности.</li></ul><p></p><p>Но не персональными данными едиными. Существуют перечни угроз и для других объектов защиты, например, для Интернета, а точнее для функционирования Интернета на территории России. Российские власти выделяют для него три типа негативных событий - угрозы устойчивости, безопасности и целостности функционирования Рунета. Они описаны в <a href="http://publication.pravo.gov.ru/Document/View/0001202002170013">Постановлении Правительства</a> от 12.02.2020 № 127 "Об утверждении Правил централизованного управления сетью связи общего пользования".</p><p>Еще одним "особняком" я бы назвал тему моделирования угроз при разработке безопасного программного обеспечения, которая стала новым "фетишем" (в хорошем смысле) и для ФСТЭК и для Банка России. Существующая методика оценки угроз ФСТЭК не очень подходит для моделирования угроз для разрабатываемого ПО, как того требует утвержденный ГОСТ Р 56939-2016 "Защита информации. Разработка безопасного программного обеспения. Общие положения". Но зато в качестве перечня угроз можно ориентироваться на ГОСТ Р 58412-2019 "Защита информации. Разработка безопасного программного обеспения. Угрозы безопасности информации при разработке программного обеспечения". Не STRIDE, конечно, но тоже ничего.</p><p>Есть и совсем специфические перечни угроз, которые применимы для объектов защиты, работающих в очень узких сферах деятельности. Например, <a href="https://minenergo.gov.ru/system/download/14522/95345">приказ Минэнерго</a> от 6 ноября 2018 года №1015 «Об утверждении требований в отношении базовых (обязательных) функций и информационной безопасности объектов электроэнергетики при создании и последующей эксплуатации на территории Российской Федерации систем удаленного мониторинга и диагностики энергетического оборудования» определяет базовые атаки и базовые уязвимости для построения модели угроз СУМиД, а также перечень из 59 угроз безопасности.</p><p>Наконец, стоит упомянуть еще угрозы безопасности, связанные с техническими каналами утечки информации, но регулируются они ДСПшными документами наших регуляторов и поэтому в заметке не упоминаются.</p><p>Вот такая картина получается - свобода свободой, но стоит оглядываться и по сторонам, вдруг регуляторы за вас посчитают какие-то негативные действия актуальными, которые вам придется учитывать в своих моделях/перечнях угроз.</p></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com6tag:blogger.com,1999:blog-4065770693499115314.post-73020237842295285812021-06-22T05:40:00.003+03:002021-06-22T05:40:00.287+03:00Что лучше - длина или объем или почему спецсимволы в пароле не нужны?<p>Думаю все мы сталкивались с советами, что для того, чтобы выбираемый пароль был надежным, он должен быть больше 8 символов, содержать не только буквы, но и цифры и спецсимволы, а буквы должны быть в разном регистре. Именно такие советы всегда даются на вопрос, как сделать пароль стойким к подбору. На днях я в своем <a href="https://t.me/alukatsky">Telegram-канале</a> провел опрос, в котором задал схожий вопрос и получил очень интересные результаты (на основе 773 голосов). Обратите внимание, длина пароля попала на третье месте среди факторов, которые влияют на надежность пароля, а ведь на самом деле именно длина является самым главным, а на самом деле единственно важным параметром, который и определяет, насколько сложно будет хакерам подобрать ваш пароль. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFDxN5Jno4JSOT_F2VfALn9rsKOOIOrx_i-bRkdiVIIYn7PgYFUpX6ygKeaKMbabr6kNV-eKDa8VpAos0FM5-IxweokHOmnPy-rR9Tj560WR7_XFW9fO63CzBl3pr-lOGPo9U13YwHmh5n/s2048/passwordfactors.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1253" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFDxN5Jno4JSOT_F2VfALn9rsKOOIOrx_i-bRkdiVIIYn7PgYFUpX6ygKeaKMbabr6kNV-eKDa8VpAos0FM5-IxweokHOmnPy-rR9Tj560WR7_XFW9fO63CzBl3pr-lOGPo9U13YwHmh5n/s320/passwordfactors.png" width="320" /></a></div><div><br /></div>Доказательством тому является формула Андерсона. Я не знаю, учат ли сейчас ее в институтах, но в мое время ее преподавали. С помощью нее определяют время подбора пароля, который характеризуется двумя параметрами - длиной (количество символов) и объемом алфавита (количество вариантов символа в каждой позиции пароля). Школьный курс комбинаторики подсказывает нам, что число возможных комбинацией пароля из L символов и объеме (мощности) алфавита A будет равно A^L (A в степени L). В формуле Андерсона также присутствует такой параметр как скорость перебора пароля (V). В итоге мы получаем следующую формулу, которая и показывает время перебора пароля определенной длины и определенной мощности алфавита при заданной скорости. Понятно, что чем, мощнее у нас компьютер или кластер компьютеров, тем быстрее будет производиться перебор (отсюда отличия в картинках, которые можно найти в Интернете и которые показывают сколько лет будут ломать ваш пароль).<div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGEGB1CsBPuWZvagf71pNnXmBKofqB30JV_ZhQzkULapSxUnEBxSCmlliHgHcauqeODiyiDxhYV2QD4qNzuOzzFbFCqOTqeFlDwKEFLFoPNm7tmgM2g_IzlvLzOqUMujXXHA51d1T_tea/s322/andersonformula2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="239" data-original-width="322" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhBGEGB1CsBPuWZvagf71pNnXmBKofqB30JV_ZhQzkULapSxUnEBxSCmlliHgHcauqeODiyiDxhYV2QD4qNzuOzzFbFCqOTqeFlDwKEFLFoPNm7tmgM2g_IzlvLzOqUMujXXHA51d1T_tea/s320/andersonformula2.png" width="320" /></a></div>Есть и другой вариант этой формулы, в которой P - это вероятность подбора пароля за указанный интервал времени, G - число попыток подбора за 1 такт времени, T - число тактов времени и A^L - число возможных комбинаций пароля.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAmxn-gr2hhpjO1dMp-XRDnRO1a2NjLUp-mNh-9aWbn1xTYPmlqMxxcsJbbEKgeHy9wjfluQYfcOWQDILxlrLY15dciRYIO0KsxwT4O_LzP-uVjlWVhfxUeAbzrwMycdPxKrKnQm9FPP4W/s364/andersonformula1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="187" data-original-width="364" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAmxn-gr2hhpjO1dMp-XRDnRO1a2NjLUp-mNh-9aWbn1xTYPmlqMxxcsJbbEKgeHy9wjfluQYfcOWQDILxlrLY15dciRYIO0KsxwT4O_LzP-uVjlWVhfxUeAbzrwMycdPxKrKnQm9FPP4W/s320/andersonformula1.png" width="320" /></a></div><div>И вот вновь нужно вспомнить курс школьной математики, а именно раздел степенных функций, которым и относится формула подсчета числа возможных паролей. Так вот это число растет быстрее, если увеличивать показатель степени (длину пароля), а не основание (мощность алфавита). При увеличении основания значение функции тоже растет, но не так быстро. Отсюда вывод - длина пароля гораздо важнее используемого в нем алфавита, то есть этих ваших спецсимволов, регистров, комбинаций цифр и букв и т.п.</div><div><br /></div><div>Понятно, что речь не идет о просто длинных словах. Какая-нибудь "электрификация" (14 символов) хоть и длинна, но все-таки это слово присутствует в словарях, которые могут быть использованы при переборе. Слово "метоксихлордиэтиламинометилбутиламиноакридин" (44 символа) я бы тоже не стал использовать, а то кто знает, может у хакеров есть и словари названий химических веществ. Но вот какое-нибудь "модясачепродвшузаиувсезанобовынемо" (34 символа) вполне себе подойдет (немного шучу, но только немного). Запомнить его несложно - это первые два символа из начала "Евгения Онегина" ("Мой дядя самых честных правил..."). На самом деле начало у Онегина другое ("Не мысля гордый свет забавить..."), но "мой вариант" более привычен.</div><div><br /></div><div>У такого совета (опираться на длину пароля, а не спецсимволы) есть и другое преимущество - нестандартные клавиатуры, на которых приходится искать непонятные символы. Помните в "Падение Олимпа", когда главный герой вводит код отмены запуска баллистических ракет, мучается с тем как ввести "решетку", которую ему назвали среди других символов кода (советник по нацбезопасности вовремя подсказала, что это будет Shift+3)? </div><div><br /></div><div>Не пора ли поменять рекомендации по выбору паролей для своих пользователей, облегчив им жизнь?ч</div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-89797764203313346112021-06-15T05:24:00.002+03:002021-06-15T05:24:00.289+03:00Разбитая чашка кинцуги, как символ современной ИБ, или о чем говорили на RSA Conference 2021<p>Кинцуги - это японское искусство реставрации керамических изделий, которое, как и многое, что есть в Японии, имеет свой философский смысл. Согласно нему трещины и поломки являются неотъемлемой частью, неотделимой от самого объекта и его истории, и скрывать их и "замазывать" не имеет никакого смысла. Так и с инцидентами ИБ. Да, они происходят. Да, они наносят урон бизнесу, который, однако, может восстановиться после них и продолжить свое развитие. Не надо скрывать инциденты или считать их концом всего. Жизнь продолжается!</p><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBluULd3fxmy75D0YlzGkXnQrc9i_-FCTPrH1bQuqDL_Q7CmiQNsGYYh18LzaABG_FnEmvH8j5SXwmY06mYderhAmVfIQiD9x0Y8kUHtAs_yrULYw65hcZG_d2qLi_Budz2zSHZgDFxeSL/s2048/Screenshot+2021-05-17+at+18.11.26.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1280" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjBluULd3fxmy75D0YlzGkXnQrc9i_-FCTPrH1bQuqDL_Q7CmiQNsGYYh18LzaABG_FnEmvH8j5SXwmY06mYderhAmVfIQiD9x0Y8kUHtAs_yrULYw65hcZG_d2qLi_Budz2zSHZgDFxeSL/s320/Screenshot+2021-05-17+at+18.11.26.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Еще один слайд с аналогиями ИБ</td></tr></tbody></table><p>Именно с такой аналогии началась конференция RSA 2021, завершившаяся почти месяц назад, а у меня все не доходили руки, чтобы о ней написать. В этом году тема устойчивости (resilience) пронизывала красной нитью все мероприятие, которое проходило целиком в онлайн-формате. Могу сказать, что получилось очень неплохо. Да, нехватало нетворкинга и очных дискуссий, который все-таки имеют свою атмосферу, отличную от виртуальных выступлений. Но организаторы смогли все-таки показать, что и онлайн может быть интересным. Рекламы почти нет (как и всегда), куча практики, множество дискуссий и интерактивных сессий, возможность задавать вопросы спикерам (на очной RSAC это всегда было непросто). И все это за почти пять сотен долларов, что гораздо дешевле прошлогодних RSAC, цена участия в которых начиналась с 2-х тысяч; плюс стоимость перелета и проживания. И хотя отсутствие очных встреч оттолкнуло ряд участников, более 16000 человек на RSAC все-таки пришли.</p><p>Я не буду подробно погружаться в каждый из нескольких сотен докладов (а как и на обычной RSAC и в этот раз параллельно проходило около 10 сессий), но ключевые направления и наиболее популярные темы подсвечу. Тем более, что они характеризуют определенные тенденции на рынке ИБ. Итак, мои наблюдения (тезисно):</p><p style="text-align: left;"></p><ol style="text-align: left;"><li>Очень активно обсуждалась тема кибербезопасности в авиации и медицине. И если последнее понятно (атаки шифровальщиков на медицинские организации и проникновения в фармацевтические компании, занимающиеся исследованиями COVID-19), то внимание к авиационной ИБ для меня стало некоторым открытием. Вроде как инцидентов серьезных в этом сегменте не было; как и новых регулятивных требований. В любом случае именно эти две отрасли стали наиболее популярными на RSAC. Финансы, госы, транспорт, нефтянка, энергетика и т.п. не удостоились чести быть активно представленными на мероприятии.</li><li>Машинное обучение (не поворачивается у меня язык называть это искусственным интеллектом) стало еще одной горячей темой RSAC, но дифирамбов этой технологии уже никто не поет. Надо признать, что на пути активного внедрения ML в ИБ встало несколько сложностей, а именно отсутствие актуальных и публичных датасетов, а также отсутствие тех, кого на английском языке модно называть data scientist. Без первого сложно обучать модели ML; без второго - разрабатывать сами модели. И хотя аналитиков данных сегодня выпускают все кому не лень, прикладных аналитиков среди них почти нет. Ну не будем же мы всерьез называть аналитиком данных того, кто прошел двухнедельные курсы по Python и умеет извлекать ключевые слова из массива данных или суммировать значения в таблице. Но даже при наличии аналитиков возникает вопрос с тем, на чем они будут обкатывать свои данные - несмотря на прогнозы Рустема Хайретдинова, что скоро датасеты по ИБ будут выкладывать в открытый доступ и они перестанут быть конкурентным преимуществом, до этого еще очень далеко. Такие датасеты, еще и регулярно обновляемые и размеченные, находятся в собственности крупных игроков рынка и они делиться ими не спешат. Остальным же остается довольствоваться <a href="https://lukatsky.blogspot.com/2019/02/blog-post_26.html">датасетом KDD 99</a> :-)</li><li>На удивление популярной стала тема моделирования угроз, о которой говорили многие, приводя различные примеры моделей и подходов к моделированию для различных систем - от облаков до АСУ ТП. Отдельно хотелось бы отметить интересный мастер-класс по форкастированию угроз, то есть, по-русски, по научному предсказанию того, что будет в долгосрочной перспективе и на горизонте в 7-10 лет. Интересное было упражнение - надо будет его как-нибудь повторить на других данных. Кстати, практики на RSAC было немало, что необычно для онлайн-мероприятий. Но предварительная подготовка и хорошее модерирование показали, что даже не собирая людей в одной комнате, можно отлично проводить лабораторные работы, давать задания, принимать ответы и т.п. </li><li>Предсказуемо много говорили про матрицу MITRE ATT&CK и ее применение в различных сценариях ИБ - от редтиминга до моделирования угроз, от оценки средств защиты до формирования стратегии ИБ. У меня в последнее время в блоге тоже немало заметок по этому фреймворку и я планирую продолжить писать про него.</li><li>После истории с SUNBURST немало докладов было посвящено атакам на цепочки поставок и тому, как с ними бороться. Примерно такая же история была в свое время с WannaCry - после него многие ИБ-компании рассказывали, как надо обнаруживать и предотвращать эту угрозу. Правда, почему их решения не обнаруживали WannaCry ДО его начала (хотя прошел месяц с момента публикации данных об уязвимости до начала эпидемии), никто не отвечал :-) Так и с проникновением в сеть компании SolarWinds. Но идеи были озвучены интересные и эта тема осстанется популярной на ближайшее время.</li><li>Удивительно, но, в отличие от прошлых лет почти никто не обвинял русских хакеров (исключая Альперовича). Вообще тему атрибуции обходили стороной, видимо, понимая, что делать выводы о принадлежности хакеров тому или иному государству, не пристало на серьезной конференции специалистов по ИБ. </li><li>Новых технологий по ИБ представлено почти не было, исключая, пожалуй, Attack Surface Management, о которых я <a href="https://lukatsky.blogspot.com/2021/06/soc-rsa-conference-2021.html">писал</a> несколько дней назад. Но зато из всех щелей звучало три аббревиатуры - ZT (Zero Trust), XDR (eXtended Detection & Response) и SASE (Secure Access Service Edge). Я про них уже тоже писал - про ZT <a href="https://lukatsky.blogspot.com/2014/08/blog-post.html">аж в 2014-м году</a> еще, про SASE <a href="https://lukatsky.blogspot.com/2019/12/sase.html">пару лет</a> назад. Но это, по сути, и не новые технологии, а скорее новый взгляд на комбинирование этих технологий для достижения новых результатов. ZT - это ответ на размывание периметра и необходимость обеспечивать непрерывный контроль доступа по динамическим правилам. XDR - это новый взгляд на обнаружение угроз, когда разные системы (хостовые, сетевые, облачные и т.п.) объединяются в единый комплекс для обнаружения того, что ранее было скрыто от отдельных решений по мониторингу. Не удивлюсь, если скоро кто-то скажет, что SIEM мертвы и нужно переходить на XDR. Ну а SASE - это очевидный ответ на переход всех в облака и нехватку кадров для решения всех вопросов ИБ своими силами.</li><li>С технологической точки зрения также немало докладов было посвящено безопасности АСУ ТП и приложениям. Но это тренд последних лет, который просто усиливается.</li><li>А SOCи? Как же SOCи? Эта аббревиатура тоже слышалась из всех динамиков, но не как самостоятельное направление, а как необходимый элемент любой системы ИБ любой организации, в котором аккумулируются все усилия по мониторингу (с помощью XDR и SASE в том числе) и реагированию на инциденты на широкий спектр атак - от шифровальщиков (про них, кстати, много не говорили, видимо все сказав на прошедшем в рамках RSAC Ransomware Summit пару лет назад).</li></ol><div>Вот такая картинка вырисовывается. Каких-то прорывов и откровений не звучало - скорее все обсуждали, как обеспечить киберустойчивость предприятий в условиях постоянных атак. В целом мне мероприятие понравилось. Хотя и не хватило живого общения, брожения по стендам вендоров, споров в близлежащих барах и вечерних посиделок. Интересно, что на выставке раньше было раза в 3-4 больше экспонентов, чем в онлайне, что странно. По идее порог входа в онлайн гораздо ниже - просто выложи свои материалы на страницу и собирай лиды. Но, видимо, этот пассивный маркетинг уже не работает и компании не хотят тратить на него усилия, желая очного общения, демонстраций на стендах, рассказа о преимуществах глядя в глаза посетителям. Этого не хватало, да.</div><div><br /></div><div>Но я лишний раз убедился, что сделать онлайн-мероприятие, которое не будет жалким подобием своей оффлайн-версии вполне возможно. И у него будут свои фишки и отличительные особенности. И ты не будешь думать "посмотрю доклад в записи на ускоренной перемотке", так как немалое количество сессий просто не записывалось, предполагая живое общение, а часть требовало непосредственного вовлечения в лабораторные работы, которые тоже никто не записывал и по окончании RSAC уже не предоставлял доступ к удаленным стендам и лабам.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYsdTFCsj8RMkqS4LpaaStLzfUiciDbO-l3YYlJcvgTn4G0tw7KzSLF-mjTgNOKInbxGqG9YJRPfr3P1qwkib-Cd1LWWvZACNyowEJEsEycWVdRHXwsMBEmXVxMZPlEK3YFym9OciFyoaa/s2048/Screenshot+2021-05-18+at+21.57.58.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1299" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgYsdTFCsj8RMkqS4LpaaStLzfUiciDbO-l3YYlJcvgTn4G0tw7KzSLF-mjTgNOKInbxGqG9YJRPfr3P1qwkib-Cd1LWWvZACNyowEJEsEycWVdRHXwsMBEmXVxMZPlEK3YFym9OciFyoaa/s320/Screenshot+2021-05-18+at+21.57.58.png" width="320" /></a></div><div><br /></div><div>ЗЫ. Пойду разгребать свои записи с RSAC - было немало того, что достойно того, чтобы про него написать.</div><p></p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-65946621244513180922021-06-10T05:20:00.001+03:002021-06-10T05:20:00.276+03:00От техник и тактик угроз к мерам обнаружения и защиты. Как сопоставить первое со вторым?<p>Читая методику оценки угроз ФСТЭК, собственно как и матрицу MITRE ATT&CK, понимаешь, что делается это все не просто так, а для какой-то цели (вот новость-то). И целью этой является выработка защитных мер, которые позволят нам противодейстовать выбранным нами как актуальными техникам и тактикам нарушителей. Еще во время появления первых документов ФСТЭК в 2013-м году многие эксперты задавались вопросом, а как увязать защитные меры с моделью угроз. У ФСТЭК пока нет ответа на этот вопрос, а вот у MITRE есть. Ему я и посвящу данную заметку.</p><p>В фреймворк MITRE ATT&CK помимо техник и тактик входит еще один блок - <a href="https://attack.mitre.org/mitigations/enterprise/">защитных мер</a> (mitigations), которые увязаны с блокируемыми ими техниками и тактиками.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg34xh_jKQbFQbOwDN-AkyKJcuora5nzbzwUbuEvZ9LZK8qVgDkW6c2yhOrq3voXr0hMM3AkLZ7f-60_pEdIGgQmzIn__qB2BS220bil7b3dnUm4G3ACDSe6KaNBP5CReISrIKNq1k47ucI/s2048/Screenshot+2021-06-09+at+21.13.19.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1152" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg34xh_jKQbFQbOwDN-AkyKJcuora5nzbzwUbuEvZ9LZK8qVgDkW6c2yhOrq3voXr0hMM3AkLZ7f-60_pEdIGgQmzIn__qB2BS220bil7b3dnUm4G3ACDSe6KaNBP5CReISrIKNq1k47ucI/s320/Screenshot+2021-06-09+at+21.13.19.png" width="320" /></a></div><div><div><br /></div><div>Таким образом, выбрав актуальные для вас техники и тактики, можно перейти к мерам, которые позволяют их нейтрализовать. На текущий момент фреймворк MITRE ATT&CK содержит 42 защитные меры (для мобильных устройств еще 13 защитных мер), среди которых шифрование важных данных, антивирус, контроль сетевого доступа, управление привилегированными учетными записями, обновление ПО, программа Threat Intelligence и т.п. Среди 42-х мер (вот он ответ на главный вопрос жизни, вселенной и всего такого) есть и такая "не надо блокировать", в описании которой сказано, что реализация защитной меры может повлечь рост риска компрометации: а значит нейтрализация не рекомендуется (сейчас техник, для которых эта рекомендация дана, всего две).</div></div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSNnNGSUWYL_mS-yY5E6VqcRqx2agOKm-cddLvMzIijEwYUAnYb42wbS9SpoQzNHI8EhxjypLsZtD89WRH57tLj_2PDBfC4pFkJB1rUghr6zwbDP3yy3HvXr6M4UiAvVtFaPey3f51FFTa/s2048/Screenshot+2021-05-28+at+18.08.14.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1153" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSNnNGSUWYL_mS-yY5E6VqcRqx2agOKm-cddLvMzIijEwYUAnYb42wbS9SpoQzNHI8EhxjypLsZtD89WRH57tLj_2PDBfC4pFkJB1rUghr6zwbDP3yy3HvXr6M4UiAvVtFaPey3f51FFTa/s320/Screenshot+2021-05-28+at+18.08.14.png" width="320" /></a></div><div><br /></div><div>Для многих техник и тактик в матрице указаны не только защитные меры, но и источники данных, которые позволяют их детектировать с помощью различных технологий - от XDR и SIEM до антивирусов и средств контроля целостности файлов и ПО.</div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8i73gkvg8cvx880xKGYCtuuDYPjTR0PBYKrnIS5glMz9Iq4VAUlnJh_e_VvBjbSN0ZsSnkzUJp7rTnWalZOWaSETABBnA78Up9iOhUgXMIWbllh6NDIgkNgUde3BhIa3NKUNB98WU8v9a/s2354/Screenshot+2021-06-09+at+21.52.29.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="908" data-original-width="2354" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8i73gkvg8cvx880xKGYCtuuDYPjTR0PBYKrnIS5glMz9Iq4VAUlnJh_e_VvBjbSN0ZsSnkzUJp7rTnWalZOWaSETABBnA78Up9iOhUgXMIWbllh6NDIgkNgUde3BhIa3NKUNB98WU8v9a/s320/Screenshot+2021-06-09+at+21.52.29.png" width="320" /></a></div><div><br /></div>В итоге, если объединить блок защитных мер с блоком источников данных мы получим возможность бороться со всеми почти 400 техниками, которые описаны в текущей версии MITRE ATT&CK. Этого тоже пока не хватает подходу ФСТЭК, у которого из всего "фреймворка" есть пока только перечень техник и тактик. Поэтому-то я и ратую за то, чтобы ФСТЭК прекратила заниматься самодеятельностью и унифицировала нумерацию своих техник и тактик с тем, что есть у MITRE. В этом случае даже при отсутствии времени и ресурсов на разработку полного собственного фреймворка можно было бы использовать уже имеющиеся наработки от MITRE. <br /><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjb31jnXF-b2qFny9kLDTXzo_L14GO3B76uBIjft2bFSXzWCY3oTktt23cjgm-d_1psapdo1uOhEKy0StQjCD0f6KTImBSI51Yb5GAyHykkYdi_903KhGiiCOgMePkszFCUNK6w00x0Uz0c/s1998/Screenshot+2021-06-09+at+21.38.43.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1192" data-original-width="1998" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjb31jnXF-b2qFny9kLDTXzo_L14GO3B76uBIjft2bFSXzWCY3oTktt23cjgm-d_1psapdo1uOhEKy0StQjCD0f6KTImBSI51Yb5GAyHykkYdi_903KhGiiCOgMePkszFCUNK6w00x0Uz0c/s320/Screenshot+2021-06-09+at+21.38.43.png" width="320" /></a></div><br /><div>Самое интересное, что 42 защитные меры от MITRE ATT&CK могут быть смаппированы в различные иные защитные фреймворки - ISO 27001/27002, NIST CSF и CIS Controls. Например, вот так этом может выглядеть для последнего фреймворка. </div><div><br /></div><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlYAmgx8NOADuEbDfg__yvd9U3F_Rp6psi8K4O8diQCedXt6HP0RAMxQeuEd1WeYUn9F7qsMTVGWg-tNS4e_aLbQDYJYDK1iq534m8LCbR1yEqDFzi3OVIQcyfXhZ7OW5SUAtLPpJAR8Lq/s2048/Screenshot+2021-06-09+at+21.19.10.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1152" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlYAmgx8NOADuEbDfg__yvd9U3F_Rp6psi8K4O8diQCedXt6HP0RAMxQeuEd1WeYUn9F7qsMTVGWg-tNS4e_aLbQDYJYDK1iq534m8LCbR1yEqDFzi3OVIQcyfXhZ7OW5SUAtLPpJAR8Lq/s320/Screenshot+2021-06-09+at+21.19.10.png" width="320" /></a></div><p>В защитные меры из приказов ФСТЭК тоже можно смаппировать, но про это в другой раз.</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-92055509705553800742021-06-08T05:07:00.001+03:002021-06-08T05:07:00.281+03:00Как написать свой профстандарт специалиста по ИБ, а заодно и должностную инструкцию для него?<p>В последнее время в России активно взялись за образование по ИБ и стали... нет, не готовить больше специалистов и лучше. Стали больше формализовать их навыки и знания в профстандартах, которым этим специалисты должны соответствовать, чтобы смело называть себя специалистами и претендовать на работу по этой востребованной (если отбросить риски не поехать за границу, присесть за сотрудничество с иностранными компаниями, получить допуск к гостайне и т.п.) специальности. Но при подготовке таких профстандартов слишком много внимания уделяется бюрократии и оформлению стандарта, чем его наполнению. Также нередко профстандарты пишутся людьми, далекими от практической работы, что приводит к тому что, львиную долю требуемых навыков и знаний составляет нормативная, а не практическая составляющая.</p><p>Мне подумалось, что надо помочь писателям профстандартов и подсказать им прекрасный ресурс, с которого можно копипастить все, что необходимо для качественного профстандарта специалиста по ИБ. Самим же авторам стандартов останется заниматься только оформлением переведенного текста. Да, это не русскоязычный ресурс, но от этого он не стал хуже, скорее наоборот. Речь идет об постоянно обновляемом фреймворке NICE (<a href="https://niccs.cisa.gov/workforce-development/cyber-security-workforce-framework">National Initiative for Cybersecurity Education</a>).</p><p>В рамках этого фреймворка выделяется 7 категорий (высокоуровневых функций, связанных с ИБ), 33 специализации по ИБ и 52 роли, для которых описываются необходимые знания, навыки и обязанности, которыми должен обладать специалист по ИБ, претендующий на конкретную роль.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEit6JtblkGD2kcIjNZMLDQA1j5SwHR3Ye7T_zS6eEc-IRzXI24-LKBXKWwzpwynVD_oMedrYIqjFSlW7LWmPZ4tsVYHHacbG6G_qSCpTZB1vw0lD37l8eos7AbO4gRxHn0Ns3HokqmVDP_a/s591/1-382.png" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="372" data-original-width="591" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEit6JtblkGD2kcIjNZMLDQA1j5SwHR3Ye7T_zS6eEc-IRzXI24-LKBXKWwzpwynVD_oMedrYIqjFSlW7LWmPZ4tsVYHHacbG6G_qSCpTZB1vw0lD37l8eos7AbO4gRxHn0Ns3HokqmVDP_a/s320/1-382.png" width="320" /></a></div><br /><p>К семи категориям и 33 специализациям внутри них относятся:</p><p></p><ul style="text-align: left;"><li>анализ</li><ul><li>анализ всех источников</li><li>анализ уязвимостей</li><li>лингвистический анализ</li><li>географический/политический анализ</li><li>анализ угроз и нарушителей </li></ul><li>сбор данных и операции</li><ul><li>операции по сбору данных</li><li>планирование киберопераций</li><li>сбор доказательств</li></ul><li>расследование</li><ul><li>расследование инцидентов</li><li>сбор и анализ доказательств (форензика)</li></ul><li>операции и поддержка</li><ul><li>поддержка пользователей</li><li>управление данными</li><li>управление знаниями</li><li>сетевые сервисы</li><li>системное администрирование</li><li>системный анализ</li></ul><li>управление</li><ul><li>управление ИБ</li><li>лидер по ИБ (для топ-менеджеров)</li><li>юридическая поддержка ИБ</li><li>управление программами и проектами</li><li>стратегическое планирование</li><li>организация обучения и повышения осведомленности </li></ul><li>защита</li><ul><li>анализ событий ИБ</li><li>тестирование, внедрение, администрирование инфраструктуры ИБ</li><li>реагирование на инциденты</li><li>управление и оценка уязвимостей </li></ul><li>архитектура и разработка</li><ul><li>управление рисками</li><li>разработка ПО</li><li>системная архитектура</li><li>разработка систем</li><li>планирование требований к системам</li><li>технологические исследования и разработка</li><li>тестирование и оценка.</li></ul></ul><p></p><p>В зависимости от специализации выделяются 52 роли или, можно сказать, должности по ИБ. Например, аналитик по киберпреступлениям, архитектор, администратор баз данных, аналитик SOC, специалист по расследованиям, аудитор, разработчик ПО, инструктор и т.п. Но NICE полезен не тем, что он классифицировал ИБ-роли, а тем, что для каждой из них прописаны рекомендуемые обязанности, знания и навыки. Например, возьмем специалиста по реагированию на инциденты. Он должен разбираться в 30-ти областях знаний, среди которых:</p><p></p><ul style="text-align: left;"><li>знание угроз и уязвимостей</li><li>знание законодательства (без уточнения какого)</li><li>знание сетевых сервисов и протоколов</li><li>знание категорий инцидентов</li><li>знание методов обнаружения атак на уровне сети, хостов и облаков</li><li>знание основных сетевых концепций, включая топологии, протоколы, компоненты</li><li>знание концепций и методологий анализа вредоносного ПО</li><li>знание рисков безопасности приложений, например, OWASP Top10</li><li>и т.п.</li></ul><div>Навыков от специалиста по реагированию требуется "всего" восемь:</div><div><ul style="text-align: left;"><li>навыки идентификации, получения, локализации и репортинга по вредоносному ПО</li><li>навыки обеспечения целостности цифровых доказательств на разных платформах и в соответствие с требованиями локального законодательства</li><li>навыки защиты сетевых коммуникаций</li><li>навыки распознавания и категоризации типов уязвимостей и связанных с ними атак</li><li>навыки защиты сети от вредоносного ПО</li><li>навыки оценки ущерба</li><li>навыки использования средств корреляции событий ИБ</li><li>навыки реализации реагирования на инциденты для облаков (этот пункт, видимо, добавился совсем недавно).</li></ul></div><p></p><p>Наконец, в NICE для каждой роли описаны еще и служебные обязанности, среди которых, например:</p><p></p><ul style="text-align: left;"><li>классификация и приоритизация инцидентов</li><li>документирование инцидента</li><li>оценка тенденций</li><li>анализ логов от разных источников</li><li>корреляция данных по разным инцидентам и подготовка рекомендаций по их нейтрализации</li><li>сбор артефактов по инцидентам</li><li>написание отчетов по инцидентам</li><li>взаимодействие с правоохранительными или иными специальными органами, проводящими расследование инцидента</li><li>мониторинг внешних источников данных</li><li>координация функций по реагированию на инциденты</li><li>и т.п.</li></ul><p></p><p>В заключение, для каждой роли прописаны дополнительные требования, привязанные к трем уровням "крутости" специалиста (начальный, средний, продвинутый). У нас бы их назвали как-нибудь типа инженер по защите информации I-III категории, ведущий или старший инженер по защите информации. Для каждого из 3-х уровней NICE рекомендует:</p><p></p><ul style="text-align: left;"><li>наличие сертификации (с указанием покрываемых сертификатом тем и направлений)</li><li>необходимость ежегодного повышения квалификации (с указанием его длительности)</li><li>необходимый уровень образования - среднее, высшее (бакалавр/магистр) и, даже, аспирантура</li><li>необходимость практического обучения</li><li>необходимые тренинги. </li></ul><div>В США, где, собственно, и родилась инициатива NICE, сейчас все требования к специалистам по ИБ, особенно для госорганов, базируются на NICE, что позволяет использовать этот фреймворк как единую точку отсчета для оценки специалистов по ИБ. Работодатели знают, что требовать от кандидатов при приеме на работу, а также что включать в должностные инструкции. ВУЗы знают, какие навыки будут востребованы работодателями и готовят свои учебные планы, отталкиваясь от нужных навыков и знаний. Кандидаты понимают, что им надо знать/уметь, когда они отзываются на ту или иную вакансию. Учебные центры могут готовить нужных специалистов в соответствие с классификацией NICE.</div><div><br /></div><div>Вообще, NICE - классная инициатива, поддерживаемая государством. Если бы у нас ФСТЭК не дистанцировалась от всего, что связано с образованием, и перешла от согласования разрозненных и неимеющих единого знаменателя обучающих программ, то это был бы большой шаг вперед. А пока у нас за все отвечает УМО, которое малость оторвано от жизни и реальных чаяний работодателей, которые вынуждены переучивать с нуля выпускников, а также ВУЗов, которые не могут готовить востребованных специалистов. В итоге мы имеем то, что имеем.</div><p></p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-87994826716850704042021-06-07T05:15:00.034+03:002021-06-07T05:15:00.238+03:00Куда движутся SOCи? Взгляд с RSA Conference 2021<p>Занимаясь проектами по SOC (как проектированием, так и оценкой существующих и разработкой их улучшений) постоянно сталкиваюсь с темой развития центров мониторинга в соответствие с лучшими практиками. Готовя такие планы, обычно включаешь в них только то, что уже проверено и действительно дает эффект. Понятно, что есть различные идеи и технологии, которые вроде и появились на рынке, но пока непонятно, насколько они полезны на практике. Рекомендовать их в рамках консалтинга не совсем правильно, но и скрывать тоже не имеет смысла. Поэтому решил вкратце пройтись по интересным новациям, которые были представлены в рамках прошедшей в конце мая RSA Conference 2021, где одной из популярных тем стал именно мониторинг ИБ. И хотя в условиях п<strike><b>р</b></strike>овального импортозамещения все это так и останется красивой сказкой, но кому-то может и поможет. Итак, что добавляют различные компании, производители и потребители, в свои SOCи для повышения их эффективности.</p><p>Во-первых, это решения класса Security Intelligence Automation, которые обладают следующими отличительными особенностями:</p><p></p><ul style="text-align: left;"><li>Библиотека знаний по ИБ. Человек принимает решения, опираясь на достаточно широкий кругозор и имеющийся опыт, который отсутствует у многих средств анализа ИБ. Идея заключается в формализации правил принятия решений и помещении их в систему для того, чтобы и другие аналитики могли воспользоваться этой библиотекой, и сами средства анализа могли в автоматическом режиме обращаться к этой библиотеке при проверке гипотез и поступающих от источников данных событий. По сути речь идет о набившем оскомину тезисе о контекстно-ориентированной аналитике, но с ее формализацией для удобства использования.</li><li>Роботизация экспертизы расследований инцидентов. При проведении расследований инцидентов аналитики опираются не только на плейбуки, но и на свой опыт, позволяющий им сопоставлять разные данные и делать на их основе выводы, облегчающие принятие решений, классификацию и приоритизацию инцидентов. Анализ выполняемых аналитиками ежедневных действий и выявление в них закономерностей, которые потом могут быть автоматизированы, это тоже тренд в SOCостроении. </li><li>Роботизация человеческой классификации и приоритизации инцидентов. Многие средства анализа ИБ построены по принципу обнаружения "известного плохого" и пасуют перед новыми событиями, в классификации и приоритизации которых задействуется человек. Часто набор производимых при этом действий достаточно стандартный и может быть автоматизирован с помощью инструментов, схожих с RPA. </li></ul><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2YXPA58iuAAlsehzWj0B1wnZdwVE64Wb0D7CiYclSbxHEazDphoGgd23GHRuEx8vz6zEpjAgR-qLak8-5IlviWMIMlVOnasvotyI3HBtU1TFXhatNcbiQMCaOcbshN11wmhtkNBR0PJyi/s1200/5-logichub-powershell-decide-100827947-large.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="661" data-original-width="1200" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg2YXPA58iuAAlsehzWj0B1wnZdwVE64Wb0D7CiYclSbxHEazDphoGgd23GHRuEx8vz6zEpjAgR-qLak8-5IlviWMIMlVOnasvotyI3HBtU1TFXhatNcbiQMCaOcbshN11wmhtkNBR0PJyi/s320/5-logichub-powershell-decide-100827947-large.jpg" width="320" /></a></div><p>Ключевыми тут являются последние две возможности, которые позволяют не ждать, когда занятые аналитики соблаговолят записать свои действия и облегчит себе жизнь, а заставить "робота", наблюдая за действиями аналитика, записать их и потом их будет гораздо проще проверить, "согласовать" и ввести в действие.</p><p>Вторым интересным рассмотренным на RSAC направлением стали решения класса Attack Surface Management, которые позволяют в непрерывном режиме оценивать потенциальные точки проникновения в организацию. Делают они это за счет нескольких функций:</p><p></p><ul style="text-align: left;"><li>Автоматическая инвентаризация, которая позволяет идентифицировать все ваши активы без указания, как в сканерах, диапазона IP-адресов. При этом решения класса ASM учитывают наличие облачных сред, динамические инфраструктуры и т.п.</li><li>Непрерывный мониторинг позволяет отслеживать все изменения, происходящие в сети.</li><li>Риск-ориентированный анализ, который заключается в приоритизации ресурсов и активов на основе различных данных - уязвимостей, критичности активов, наличие известных эксплойтов, сложности их использования и т.п. На основании этой информации каждому активу присваивается уровень риска.</li></ul><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq3H7WEIqU4lFYP_mM0EJhxsqbcn6cD-4aPOu-lfFIj4u47s4pCXuZ0_BtlD87fUKqQNfFY4dWK5tW6qTv2tnD_yBIdd_udWfFQw5FGoryBwTEb0ghCQCpDQnwPw2HoZZfvszLC-X29DAI/s1040/ASM1.jpg" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="627" data-original-width="1040" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjq3H7WEIqU4lFYP_mM0EJhxsqbcn6cD-4aPOu-lfFIj4u47s4pCXuZ0_BtlD87fUKqQNfFY4dWK5tW6qTv2tnD_yBIdd_udWfFQw5FGoryBwTEb0ghCQCpDQnwPw2HoZZfvszLC-X29DAI/s320/ASM1.jpg" width="320" /></a></div><div><br /></div><div>Да, все эти действия по отдельности уже и сейчас решаются - есть средства инвентаризации, решения CMDB, сканеры безопасности и т.п. Инструменты ASM объединяют в себе все эти функции и, будучи заточенными под ИБ, позволяют решить важнейшую задачу любого предприятия - в любой момент времени иметь возможность ответить на вопрос "что мне надо защищать?".</div><div><br /></div>Другой проблемой, на которой были направлены усилия отрасли, стала снижение числа ложных срабатываний, с которыми сталкиваются почти все организации (число фолсов достигает 50% и выше). Одним из способов борьбы с этим является внедрение риск-ориентированной аналитики в SIEM, в рамках которой происходит не просто обычная корреляция событий ИБ, но к ней добавляется учет TTP по MITRE ATT&CK (увы, ТТУ от ФСТЭК не поддерживается), уровень риска узла или системы или пользователя и ряд других показателей (у Splunk такой механизм называется RBA - Risk Based Alerting).<div><br /></div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPTtoKtqOnBhRvejAOIZNZH_R6rNY_iam9is4jyQ36MTLQQt8KehVVCVMRdAknnNHm71IiwnNpKc04RZ1yyg7PK-XQBAEqCVqpSzzngSwQkYj6xpfJGZrLxlfOhe7MOdo2LdGUpzVqNjrR/s1423/RBA.jpg" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="816" data-original-width="1423" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPTtoKtqOnBhRvejAOIZNZH_R6rNY_iam9is4jyQ36MTLQQt8KehVVCVMRdAknnNHm71IiwnNpKc04RZ1yyg7PK-XQBAEqCVqpSzzngSwQkYj6xpfJGZrLxlfOhe7MOdo2LdGUpzVqNjrR/s320/RBA.jpg" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Пример риск-ориентированной оценки активов в SIEM</td></tr></tbody></table><br /><div>И тут вроде ничего нового. Все это можно было делать с помощью SIEM и раньше, но для этого приходилось сильно заморачиваться, делая все руками, прописывая цепочки событий, задавая уровень критичности актива для бизнеса, вычисляя риски по самостоятельно написанным формулам и т.п. Сейчас появляется возможность автоматизации этих процедур и объединения их в единое решение.</div><div><br /></div><div>Последним в этой заметке я упомяну решения класса no code, которые начали завоевывать рынок (сложно от всех требовать умения программировать), в том числе и в ИБ. В частности сегмент SOAR стал одним из первых, в которых стали появляться решения no code, позволяющие описывать плейбуки и интеграции с другими решениями без написания отдельных коннектов. Причем в этом направлении сейчас идут многие игроки - от стартапов типа Tines, sirp.io, D3 Security:</div><div><br /></div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgwibVAGdbTXYGIqM9CI_HXI78z-9MttMzG1Ccec-jJ-NvEkdhqfPd8XmvuHqaAHYTvW-Tf3o4av2h1cX0kS3_QG6Ewqr2Kqpx_NRoJw8Y5MZeAsPq9Gpf1UdSiU7GlQFLsR-Py-aAwBUy/s1015/quickstart_creating_an_action_updated_diagram.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="633" data-original-width="1015" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgwibVAGdbTXYGIqM9CI_HXI78z-9MttMzG1Ccec-jJ-NvEkdhqfPd8XmvuHqaAHYTvW-Tf3o4av2h1cX0kS3_QG6Ewqr2Kqpx_NRoJw8Y5MZeAsPq9Gpf1UdSiU7GlQFLsR-Py-aAwBUy/s320/quickstart_creating_an_action_updated_diagram.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Пример описания workflow без программирования</td></tr></tbody></table><div><br /></div><div>до крупных игроков типа Spunk (с Phantom) или Cisco (с бесплатным SecureX):</div><br /><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNY77LhN_TcUSykebJ-hne-QPmDUOKGlPXIikFEWjmpS3GEl9wMn229MDwXvi4ICHuuJsO92JHYMb7c26E_RSfdF7wMbxKoRssQyx_XXKDQq-pqXExJJzc4TOTb9Yh4SQ6s6znEH1iVgqP/s1909/SecureX-Integrations-light.png" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="641" data-original-width="1909" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgNY77LhN_TcUSykebJ-hne-QPmDUOKGlPXIikFEWjmpS3GEl9wMn229MDwXvi4ICHuuJsO92JHYMb7c26E_RSfdF7wMbxKoRssQyx_XXKDQq-pqXExJJzc4TOTb9Yh4SQ6s6znEH1iVgqP/s320/SecureX-Integrations-light.png" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Пример встроенных коннекторов с разными решениями по ИБ</td></tr></tbody></table><br /><div>Вот такая вырисовывается картина. В условиях роста числа событий ИБ, увеличения ложных срабатываний, нехватки кадров и большого разнообразия средств защиты, которые надо объединять в единый комплекс, вполне очевидной становится задача автоматизации различных аспектов работы SOC, что и наблюдается в отрасли и ее мероприятиях, включая и RSA Conference. </div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-56995429892416603362021-06-02T05:49:00.001+03:002021-06-02T05:49:00.232+03:00Что не покрывает методика оценки угроз ФСТЭК?<p>Когда ФСТЭК выпустила новую методику оценку угроз, многие мои коллеги облегченно вздохнули и рьяно взялись за работу по моделированию угроз, считая, что теперь их жизнь наладится и то, чего они ждали столько лет наконец-то свершится. Но не тут-то было. Новая методика оценки позволяет оценивать вполне определенный спектр угроз, оставляя в стороне много из того, что может произойти и нанести ущерб организации. В данной заметке я хотел бы как раз описать на что, не распространяется методика ФСТЭК.</p><p>Во-первых, угрозы, связанные с шифровальными средствами, регулируются различными публичными и не очень документами ФСБ, в том числе:</p><p></p><ul style="text-align: left;"><li>«Методические рекомендации по разработке нормативных правовых актов, определяющих угрозы безопасности ПДн, актуальные при обработке ПДн в ИСПДн, эксплуатируемых при осуществлении соответствующих видов деятельности» (утверждены руководством 8 Центра ФСБ России 31 марта 2015 года, № 149/7/2/6-432)</li><li>«Состав и содержание организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности» (утверждены приказом ФСБ России от 10 июля 2014 года № 378).</li></ul><div>Во-вторых, финансовые организации, которые являются либо операторами ПДн, либо владельцами ЗОКИИ, обязаны соблюдать помимо документов ФСТЭК еще и документы Банка России, а именно два действующих Указания:</div><div><ul style="text-align: left;"><li>Указание Банка России от 10 декабря 2015 г. № 3889-У «Об определении угроз безопасности ПДн, актуальных при обработке ПДн в ИСПДн»</li><li>Указание Банка России и ПАО «Ростелеком» от 9 июля 2018 г. № 4859-У/01/01/782-18 «О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических ПДн, их проверке и передаче информации о степени их соответствия предоставленным биометрическим ПДн гражданина РФ в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ «Об информации, информационных технологиях и о защите информации», в единой биометрической системе»</li></ul>Также, ввиду внесения крупных изменений в законодательство по Единой биометрической системе, сейчас планируется выход двух новых указаний Банка России по угрозам персональным данным при их передаче финансовыми организациями в ЕБС и внутренних системах биометрических ПДн в финансовых организациях.</div><p></p>В третьих, если вы всерьез рассматриваете утечки по техническим каналам, то вам понадобятся документы с пометкой "для служебного пользования", положения которых не учтены в новой методике по понятным причинам. Как собственно, не очень хорошо там учтены и угрозы, вызванные не антропогенными источниками (то бишь не людьми), а также антропогенными, но без злого умысла. Все это потребует от вас выйти за рамки действующего документа и обратиться к другим документам.<div><br /></div><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY3bOw9rxhiYmm6gEdhem8C96GLD8jhtcUmmrUk8mBLCT8sqqWpFg-sH2PUXS0cWWIswVog5PE5aSMTuRJ7U3QVNOi3-J3XReIvLeEsNL1WDMExFT_z3rQwVUA0050qitZv-w6ROo0tOs7/s1659/threatmodels.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1134" data-original-width="1659" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY3bOw9rxhiYmm6gEdhem8C96GLD8jhtcUmmrUk8mBLCT8sqqWpFg-sH2PUXS0cWWIswVog5PE5aSMTuRJ7U3QVNOi3-J3XReIvLeEsNL1WDMExFT_z3rQwVUA0050qitZv-w6ROo0tOs7/s320/threatmodels.jpg" width="320" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;">Разные методики моделирования угроз</td></tr></tbody></table><div><br /></div><div>Кроме того, в преамбуле к методике написано, что она ориентирована на угрозы нарушения конфиденциальности, целостности, доступности, неотказуемости, подотчетности, аутентичности и достоверности информации и средств ее обработки. Также методика покрывает угрозы прекращения функционирования систем и сетей.<br /><p></p>Но если внимательно посмотреть на описанные зоны действия методики, то мы увидим, что она, например, плохо подходит для оценки угроз при разработке программного обеспечения, что, например, требуется по отечественным ГОСТам по безопасной разработке. В этом случае вам потребуется что-то другое. Например, хорошим стартом может послужить методика от Microsoft, которую для краткости называют STRIDE, хотя она этой аббревиатурой и не ограничивается. Она, безусловно покарывает не все угрозы для ПО, но самые популярные точно. Кроме того, по ней существует немало материалов и курсов, а также бесплатные средства автоматизации данной задачи. Можно еще посмотреть в сторону методики OWASP, но она не сильно отличается от Microsoft'овской.<div><p></p></div><div>Но и это не все. Вы наверняка рассматривали в качестве реальной угроз санкции азиатских, европейских или американских производителей или поставщиков продуктов и услуг ИТ и ИБ, которые могут отключить вас от обновлений своих решений. Такие угрозы достаточно плохо ложатся на методику ФСТЭК. А приход регулятора, который накажет вас штрафом (негативные последствия налицо) за отсутствие лицензии или сертификата соответствия? А МВД, которое в рамках борьбы с контрафактом и пиратством может изъять у вас средства вычислительной техники для проведения экспертизы? Это тоже угроза и я бы относил ее к ИБ, если изъяты будут именно средства защиты информации. Методика ФСТЭК и про них ничего не говорит.</div><p></p>Таких примеров можно приводить еще немало и все они связаны с тем, что ФСТЭК хоть и регулятор в области защиты информации, но закрывает далеко не все темы, которые относятся к информационной безопасности (что шире защиты информации). Поэтому при моделировании угроз вы не только должны по отдельным методикам оценивать угрозы шифровальным средствам (и согласовывать их отдельно с ФСБ, если вы вводите в эусплуатацию ГИС) и угрозы утечек по техническим каналам, но еще и брать в расчет угрозы, которые для вас могут быть вполне реальными и актуальными, но которые выходят за рамки компетенций ФСТЭК и которые поэтому не учитываются по методике от 5-го февраля. Для согласования вам это и не нужно (а может быть даже и вредно - ну кто вам согласует модель угроз, в которой написано, что один из источников угроз - это сама ФСТЭК), а вот для реальной работы может понадобиться.<p></p></div>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com0tag:blogger.com,1999:blog-4065770693499115314.post-13377345038348916552021-05-31T05:31:00.004+03:002021-05-31T05:31:00.240+03:00Магия моделирования угроз по ФСТЭК<p>Известно выражение, что когда готовишь какой-то курс и потом его преподаешь, то и сам начинаешь лучше разбираться в предмете. Так вот по просьбе одного учебного центра я разработал такой курс по новой методике оценки угроз ФСТЭК, в процессе которого я прохожу все этапы моделирования, наступая на все те грабли, которые, по идее, должны были отсутствовать, если бы регулятор сам бы прошел по своей же методике перед ее опубликованием хотя бы для одной из своих систем. У меня в процессе подготовки и чтения этого курса, накопилось уже много вопросов, часть из которых я бы и хотел подстветить в этой заметке:</p><p></p><ol style="text-align: left;"><li>ФСТЭК обязывает использовать <a href="https://bdu.fstec.ru/">БДУ</a>, как основной источник данных об угрозах, но он вообще никак не синхронизирован с текущей методикой оценки. Методика требует оценивать угрозы для 6 свойств информации, а БДУ описывает их только для трех (классической триады - КДЦ). БДУ использует понятие "потенциал", которое хоть и отличается от "уровень возможностей нарушителя" из методики, но все же идентично. Но в БДУ таких уровней 3, а в методике уже 4. Кстати, кто-то может объяснить отличие "базового" уровня от "базового повышенного" и "базового повышенного" от "среднего"? Если уж за год с лишним (а о новом подходе в моделировании угроз объявили еще в феврале 2020-го года и тогда же обещали, что в БДУ уже вносятся изменения) в БДУ так и не смогли внести изменения, то может выпустить письмо о неприменении БДУ на переходный период? А то на курсах один из самых популярных вопросов - как натянуть БДУ на новую методику.</li><li>С источниками угроз тоже все непросто. В одном месте ФСТЭК пишет, что они рассматривают только антропогенные источники, то бишь людей. В другом, что техногенные тоже нужно, если к системам и сетям предъявляются требования к устойчивости и надежности. А вы вообще видели где-нибудь системы, к которым не предъявляются такие требования?</li><li>Зачем ФСТЭК при классификации уровней возможностей нарушителей использовала букву Н, получив 4 уровня возможностей, - от Н1 до Н4? А то, что ФСБ использовала эту букву в своей классификации моделей нарушителей Н1-Н6, регулятора не волнует? И да, кому какое дело, что госорганы по 676-П обязаны согласовывать свою модель с двумя регуляторами и чтобы это сделать, они вынуждены писать 2 модели и согласовывать их по отдельности. Да-да, я помню, что проблемы индейцев шерифа не волнуют.</li><li>Я бы вообще при определении уровней возможностей нарушителей вернулся к первоначально рассматриваемой идее с потенциалом нападения из ГОСТ 18045, который позволяет оценить все возможности по идентификации слабых мест и их использовании и разделить их именно на 4 уровня. Но в отличие от методики ФСТЭК в ГОСТе эти уровни вычисляются по элементарной и понятной формуле, которая не позволяет скатиться в волюнтаристскую экспертную оценку.</li><li>Про категории нарушителей я уже писал и вновь повторюсь - смысла деления на внутренних и внешних нарушителей сегодня никакого нет. Эта грань уже давно канула в небытие и тратить время на то, чтобы понять, кем является китаец из Zoom (а он внутренний нарушитель по методике), смысла нет. Избыточное упражнение, которое не дает никакого эффекта с точки зрения защитных мероприятий, но отнимает время.</li><li>С перечнем возможных нарушителей тоже не все просто. По сути вроде все верно - определили актуальных по их мотивации, а остальных отсекли. Но на практике все немного иначе. Согласно методике, если поставщик внешних услуг (например, облачный провайдер) отказывается предоставлять мне свою модель угрз (а кто ж ее предоставит-то?), то я должен исходить из предположения, что против меня действует нарушитель с максимальным уровнем возможностей, то есть спецслужба иностранного государства. А можете ли вы себе представить организацию, которую не использует внешних и обслуживающих себя систем? Например, DNS-сервера, которые можно прекрасно атаковать и подменить записи соответствия доменных имен и IP-адресов, перенаправив жертву с сайта, например, ФСТЭК на сайт клон. Получается, что те, кто завязан на сервисы Zoom, Google, Cloudflare, Box, Яндекс, Mail.ru, Ростелекома и т.п., должны всегда рассматривать спецслужбы в своей модели угроз со всеми вытекающими отсюда последствиями? Ну надо было так и прописать, что этот нарушитель для всех обязателен - сэкономили бы кучу времени.</li><li>Кстати, о спецслужбах иностранных государств. КГБ Беларуси относится к таковым? А КНБ Казахстана? С АНБ и ЦРУ вроде вопросов нет, но вот что с остальными, менее известными обычному безопаснику спецслужбами или спецслужбами дружественных нам, а местами и союзных государств. У меня в ВУЗе был даже отдельный предмет (секретный), на котором нам рассказывали об оргструктуре разведывательных органов и иных спецслужб разных государств. А откуда этот список взять при моделировании? А террористы и экстремисты? С ними все понятно (хотя ФСТЭК могла бы и сослаться на реестр террористических и экстремистких организаций, которые ведут Минюст и ФСБ) и мы должны опасаться атак со стороны Свидетелей Иеговы и ФБК Навального. </li><li>Кстати, рассматривать ли санкции в отношении меня как угрозу ИБ? Если мне, например, отключат обновления средств защиты или операционной системы и приложений, то это повлечет за собой негативные последствия. Очевидно. И более того, это будет сделано с умыслом. А что за источник угрозы, который будет реализовывать данную угрозу? Антропогенный ли он? Ну, допустим, что иностранное государство, которое и реализует эту угрозу, мы персонифицируем до ее Президента или госсекретаря (хотя это и очень условно). Но кто будет нарушителем в классификации ФСТЭК? Максимально возможный вариант - это спецслужба иностранного государства, но не они вводят санкции. Так кого же писать в этом случае в модель?</li><li>Почему, взяв за основу MITRE ATT&CK при описании своих техник и тактик угроз, ФСТЭК решила придумать свои тактики и свои техники? Где-то они совпадают, а где-то нет. И ладно, если бы регулятор пошел бы по пути MITRE и описал бы субтехники для разных платформ, добавил бы еще соответствие техник и хакерских групп (у MITRE их почти 100 описано) или хотя бы хакерского инструментария (у MITRE их почти 400 описано), но нет. Все надо придумывать самим и даже опыт MITRE ATT&CK тут не сильно помогает - я пытался смаппировать одно в другое и у меня не очень-то и получилось. А что мешает регулятора заставить всех своих лицензиатов, которые имеют SOCи и выпускают бюллетени Threat Intelligence, описывать угрозы, используя ТТУ от ФСТЭК, а не от супостатной MITRE? У нас импортозамещение или где? Да, пусть они по-прежнему используют TTP от ATT&CK, раз уж у нас НКЦКИ ориентирован на американские стандарты Threat Intelligence (тот же TLP или ATT&CK). Но пусть маппят и в техники ФСТЭК, не перекладывая эту проблему на потребителей (это второй по популярности вопрос на курсе - как соотнести уже имеющиеся отчеты и описания угроз и инцидентов по MITRE ATT&CK в то, что делает ФСТЭК?).</li><li>Последний момент связан с перечислением актуальных сценариев реализации угроз. Вы же в курсе, что сначала вы должны составить перечень всех угроз, потом оставить из них возможные, а потом уже определить актуальные? Вы же понимаете разницу между возможной угрозой и актуальной? Возможная становится актуальной, если есть хотя бы один сценарий реализации угрозы. А вы видели угрозы, для которых нет хотя бы одного сценария? Сценарий же это не последовательность из обязательно всех десяти тактик. Одна техника (например, сканирование) тоже может быть сценарием. Но проблема даже не в очередном ненужном этапе (выделении актуальных угроз из списка возможных), а в том, что какие бы сценарии у вас не были (а число их комбинаций из 145 имеющихся техник и 10 тактик измеряется даже не триллионами), все они все равно состоят из ограниченного числа техник. Их всего 145. Если я смогу определить и нейтрализовать эти 145 техник, то какая мне разница, сколько у меня сценариев их использующих? Ровно на этом построены почти все зарубежные подходы, базирующиеся на MITRE ATT&CK, и ровно эта идея заложена в зарубежные средства защиты, которые борются не со сценариями угроз, а с конкретными техниками. И сравнивают продукты по обнаруживаемым/блокируемым техникам. И пентесты и редтиминг по техникам выстраивают, а не по сценариям. Этап с определением сценариев надо убирать - он лишний. Все равно весь рынок ИБ (что консалтинговый, что продуктовый) заточен именно на техники.</li></ol><p></p><div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhroktjm3cMrDLhyphenhyphenuC2JttmOpN7z9eRzf6XNntXUrFyupGaYPoJtnT-UXeG67ULSMCydMgtJne4qLshyphenhyphensw_o6UfkIye9SptBU9EwHUFdbvxm1pLBOs0ZWrelxsanG48hh-pAMyWaQozFUYL/s2048/fstecfail.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="1980" data-original-width="2048" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhroktjm3cMrDLhyphenhyphenuC2JttmOpN7z9eRzf6XNntXUrFyupGaYPoJtnT-UXeG67ULSMCydMgtJne4qLshyphenhyphensw_o6UfkIye9SptBU9EwHUFdbvxm1pLBOs0ZWrelxsanG48hh-pAMyWaQozFUYL/s320/fstecfail.png" width="320" /></a></div><p>Всего 10 вопросов я вынес в эту заметку, но даже они показывают, что регулятор сам не пропускал через свою методику ни свой сайт, ни свою ИС бухгалтерии или кадров, ни даже ИС своего подведомственного воронежского института. Если бы он это сделал, то сразу бы сам и наткнулся на явные косяки методики, с которыми сейчас сталкиваются, как минимум, все госорганы, которые обязаны согласовывать свои модели угроз по 676-му Постановлению Правительства. И то, что должно было облегчить им жизнь, сделало ее только хуже. Особенно тем, кто должен был ввести в эксплуатацию свои системы весной/летом этого года, но неожиданный выпуск новой методики и отсутствие переходного периода на ее внедрение спутал все карты и увеличил сроки на выполнение обязательных требований, сорвав ввод в эксплуатацию или, что чаще всего, заставив сделать процесс моделирования для галочки.</p><p>Вообще, методические документы обычно пишутся, чтобы снять вопросы или разъяснить неочевидные или поверхностно описанныые темы в документах более высокого уровня. Но с методикой ФСТЭК по оценке угроз получилось наоборот. Если бы в приказах регулятора осталась только одна фраза про необходимость моделирования угроз, то я бы мог использовать любую из нескольких десятков методик моделирования. Но нет, регулятор обязал всех использовать свой подход, который, если следовать буквально всем требованиям, результата достигнуть не даст. Увы...</p><p>ЗЫ. Решить описанные проблемы можно одним из двух вариантов - поменять методику или выпустить средство автоматизации, которое проведет "за ручку" своих адептов по шагам, не давая им думать, а просто выбирая нужные варианты из выпадающих меню или ставя нужные чекбоксы.</p>Алексей Лукацкийhttp://www.blogger.com/profile/08434361034703403028noreply@blogger.com4