Многие коллеги уже высказались по поводу проекта новой методики ФСТЭК по моделированию угроз ( тут , тут , тут , тут и тут ) и мне бы не хотелось повторять за ними. Я поступил проще - я взял в качестве примера систему удаленного доступа, которую многие реализуют сейчас для своих работников, и попробовал реализовать пошаговую процедуру, предусмотренную проектом методики. Раздел 1 практической ценности не несет - он просто определяет некоторые общие вещи и вводит ограничения на моделирование угроз. Комментировать историю с БДУ сейчас, наверное, нет смысла. ФСТЭК обещала серьезно переработать эту базу и привести ее в соответствие с новой методикой.
Раздел 2 является обзорным, описывающим, как нам надо выстраивать процесс моделированияЕ не погружаясь в детали. Пункт 2.1 говорит нам, что мы можем закрыть глаза на ошибки пользователей, так как они врядли относятся к неправомерным действиям. С другой стороны у нас неоправданно расширен список возможных угроз, с которыми нам придется бороться, так как в качестве угроз мы рассматриваем не только действия и(или) воздействия, в результате которых возможно нарушение безопасности информации и(или) нарушение или прекращение функционирования систем и сетей, повлекшее наступление негативных событий, но и все остальные неправомерные действия и(или) воздействия, в результате которых возможно нарушение безопасности информации; уже независимо от наступления негативных событий. Возможно, в предпоследней строке п.2.1 вместо слова "повлекшЕе" должно было стоять "повлекшИе", но пока это слово относится только к последней части абзаца, то есть к нарушению или прекращению функционирования систем и сетей. Также, этим пунктом мы исключаем из рассмотрения все угрозы, связанные с бездействием. Например, появилась уязвимость в VPN-клиенте или шлюзе удаленного доступа и логично было бы ее устранить, но мой администратор решил забить на это и ничего не делать. Позже через эту уязвимость в сеть залезли хакеры, но администратор разводит руками, так как в модели угроз его бездействие не было учтено.
Пункт 2.2 говорит нам, что результатом моделирования угроз является формирование перечня угроз. Проведя такое моделирование для системы удаленного доступа я действительно получил такой список, но что с ним делать дальше я так и не понял. Моделирование ради моделирования... Все-таки результатом моделирования должен быть перечень мер, нейтрализующих выявленные угрозы (об этом упоминается только в п.2.6 и то походя). В текущем варианте я могу отдельно написать модель угроз, но защищаться так, как считаю нужным или так, как мне подсказывает производитель средств защиты.
На пункте 2.3 я впал в ступор, так как мне казалось, что прежде чем определять негативные последствия, надо все-таки определиться с объектом защиты, с его границами, условиями функционирования, взаимосвязями и решаемыми задачами. Тогда у меня сразу сузится область моделирования и моя деятельность будет более эффективной. И косвенно моя правота подтверждается и самой методикой. По крайней мере входными данными для 1-го этапа моделирования на рисунке 1 указаны как раз сведения об архитектуре систем и сетей (на мой взгляд было бы проще написать просто "объект защиты") и особенностях их функционирования. Многие пункты 2-го раздела говорят именно об описании границ анализируемой системы, но почему этот этап не выделен отдельно.
Пункт 2.4 как раз нам и говорит о том, что надо определиться с границами объектам защиты (почему-то названными границами процесса моделирования) и его взаимосвязями, в том числе и с обеспечивающими системами. Например, если злоумышленники выведут из строя подстанцию, которая дает электричество на мой офис, то им не надо будет атаковать ни моих удаленных пользователей, ни кластер удаленного доступа. Они решат свою задачу окольным путем (если им надо было нарушить доступность всей системы). Тоже самое касается и провайдеров VPN-доступа, которые не относятся к моему объекту защиты, но при этом этот объект от них сильно зависит и мы должны включить его в зону нашего внимания. Правда, регулятор, возможно, чтобы не усложнять методику, исключил обслуживающие системы из процесса моделирования, оставив только те, которые принадлежат обладателю информации или оператору ИС или сети, ее обрабатывающей, то есть лицу, с которым у меня заключен соответствующий договор. Рисунок 2, про границы моделирования для ИС, использующих ресурсы внешнего ЦОДа, это подтверждает. Не знаю, насколько это правильно; я бы все-таки старался учитывать еще и системы обеспечения. Пока я не дошел до следующих пунктов, задамся вопросом, а надо ли мне при моделировании учитывать возможные неправомерные действия, осуществляемые при ремонте компонентов моей системы? А при их поставке и разработке?
Пункт 2.7 подсказывает нам, что у меня могут быть и средства защиты, и выстроенные процессы ИБ, но в них могут быть уязвимости и поэтому безоговорочно доверять им не стоит. Хорошее замечание, но которое нам еще аукнется на последующих шагах.
Моделировать угрозы, согласно п.2.8, может либо обладатель информации или оператор, ее обрабатывающий, либо лицензиат ФСТЭК. Почему моделирование угроз вдруг стало лицензируемым видом деятельности я не знаю; наверное, просто по привычке. Также не совсем понятно, почему я не могу воспользоваться моделью угроз от разработчика системы, который гораздо лучше знает свое детище, чем другие лица? Тем более, что дальше в разделе именно на провайдеров используемых нами систем возлагается обязанность предоставить нам эту модель угроз.
Внезапно, пункт 2.9, который должен быть в 1-м разделе, говорит нам о том, что для экспертной оценки я могу создавать группы экспертов согласно приложению 2, которое нам подсказывает, что эксперты должны быть независимыми, не иметь финансовых интересов (у лицензиатов ФСТЭК их, конечно же, нет), быть квалифицированными и т.п. А чтобы их оценка была более взвешенной, методика ФСТЭК рекомендует использовать больше столетия используемый в разных отраслях метод Дельфи. Хорошо, что Приложение 2 рекомендуемое, а не обязательное, а то согласно нему формирование экспертной группы превратится в задачу посложнее самого моделирования угроз. Но рекомендацию использовать метод Дельфи я могу только приветствовать.
П.2.11 рекомендует для "внешних" систем использовать модели угроз, разработанные владельцем этих внешних систем (ЦОДов, облаков, сервисов телеконференций, файловых хранилищ, CRM-систем и т.п.). Тут у меня два комментария. Во-первых, таких владельцев, которые бы готовы были делиться своими моделями угроз, почти нет. На их сайтах вы этой информации точно не найдете, а при общении с ними, они, даже если и имеют разработанные модели угроз, будут ссылаться на конфиденциальность этой информации и невозможность поделиться ею. ФСТЭК в этом случае не рекомендует пользоваться услугами таких компаний. С точки зрения специалиста по ИБ я может и разделяю подход регулятора, но с точки зрения бизнеса прекрасно понимаю, что ему наплевать на наличие/отсутствие моделей угроз у контрагентов. Он оценивает свои риски совсем иначе. И если уж мы говорим о риск-ориентированном моделировании угроз (раз уж мы привязываемся к негативным последствиям), то и стоять на этом надо до конца (хотя стоять на своем бывает больно). И задача службы ИБ как раз и состоит в том, чтобы оценить эти риски и дать бизнесу рекомендации по их снижению. Поэтому если у выбранного поставщика услуг нет модели угроз, ее надо разработать самим и исходя из нее сформировать защитные мероприятия.
Этот же пункт почему-то накладывает на поставщика услуг какие-то обязанности; хотя в преамбуле проекта методики этот субъект не указан в числе тех, на кого методика распространяется. Поэтому он никому ничего не обязан предоставлять, обновлять, информировать и т.п. Не надо строить иллюзий насчет этого.
А рисунок 3, кстати, запутывает процесс моделирования. Распределение зон ответственности лучше было отражать на рисунке 2. Это же относится и к рисункам 4 и 5. Понятно, что хотел сказать регулятор, но отобразить это стоило бы, как мне кажется, в виде вертикальных блоков/зон, как это часто показывают в презентациях и статьях по защите облаков, рассказывая про разделяемую ответственность. Я вот нашел такую в какой-то из своих презентаций 10-тилетней давности. На ней, кстати, показан и такой непростой вопрос при моделировании угроз, как API, который в методике назван интерфейсами взаимодействия с иным программным обеспечением.
Пункты 2.13 и 2.15 противоречат друг другу в той части, что в первом случае указано, что структура модели угроз должна соответствовать приложению 3, а во втором - это уже не требование, а рекомендация.
Пункт 2.15, говорящий о том, что модель угроз должна быть актуальной, очень правильный. Он описывает ситуации, когда надо обновлять модель угроз, но он же и ставит вопрос о том, насколько эту задачу в описанном виде способны реализовать те, для кого эта методика станет обязательной. В последнем абзаце этого пункта говорится о том, что надо выявлять максимально возможное число сценариев реализации угроз безопасности, которые должны быть помещены в модель угроз. Забегая вперед, можно сказать, что хотя термин "сценарий реализации угроз" нигде не определен, это совокупность возможных техник и тактик, применяемых нарушителем.
Таблица 4 6-го раздела содержит 10 тактик и 77 техник. И если мне надо определить максимально возможное число таких совокупностей, то взяв на вооружение комбинаторику и предположив, что для реализации угрозы нарушитель будет использовать все 10 тактик (то есть шагов kill chain), я получу... до хрена вариантов. Очень условно, я бы назвал, что таких комбинаций будет чуть больше 1 триллиона (число сочетаний из 77 техник по 10 штук в каждом). Даже если "выровнять" число техник до 5 для каждой из 10 тактик, число возможных сочетаний у меня будет больше 10 миллиардов. Для матрицы MITRE ATT&CK (я о ней писал неоднократно), которую использовать тоже можно, у меня число возможных сочетаний будет измеряться квадриллионами. Да, я понимаю, что в реальности не все такие сочетания будут возможны, но формулировка "максимально возможное число сценариев" заставляет перебирать их все и отбрасывать неприменимые. А в условиях отсутствия средств автоматизации такой работы, на ней все и умрут...
На этой позитивной ноте я завершил изучение 2-го раздела проекта методики моделирования угроз. Завершу и эту заметку, продолжение которой будет завтра.
Раздел 2 является обзорным, описывающим, как нам надо выстраивать процесс моделированияЕ не погружаясь в детали. Пункт 2.1 говорит нам, что мы можем закрыть глаза на ошибки пользователей, так как они врядли относятся к неправомерным действиям. С другой стороны у нас неоправданно расширен список возможных угроз, с которыми нам придется бороться, так как в качестве угроз мы рассматриваем не только действия и(или) воздействия, в результате которых возможно нарушение безопасности информации и(или) нарушение или прекращение функционирования систем и сетей, повлекшее наступление негативных событий, но и все остальные неправомерные действия и(или) воздействия, в результате которых возможно нарушение безопасности информации; уже независимо от наступления негативных событий. Возможно, в предпоследней строке п.2.1 вместо слова "повлекшЕе" должно было стоять "повлекшИе", но пока это слово относится только к последней части абзаца, то есть к нарушению или прекращению функционирования систем и сетей. Также, этим пунктом мы исключаем из рассмотрения все угрозы, связанные с бездействием. Например, появилась уязвимость в VPN-клиенте или шлюзе удаленного доступа и логично было бы ее устранить, но мой администратор решил забить на это и ничего не делать. Позже через эту уязвимость в сеть залезли хакеры, но администратор разводит руками, так как в модели угроз его бездействие не было учтено.
Пункт 2.2 говорит нам, что результатом моделирования угроз является формирование перечня угроз. Проведя такое моделирование для системы удаленного доступа я действительно получил такой список, но что с ним делать дальше я так и не понял. Моделирование ради моделирования... Все-таки результатом моделирования должен быть перечень мер, нейтрализующих выявленные угрозы (об этом упоминается только в п.2.6 и то походя). В текущем варианте я могу отдельно написать модель угроз, но защищаться так, как считаю нужным или так, как мне подсказывает производитель средств защиты.
На пункте 2.3 я впал в ступор, так как мне казалось, что прежде чем определять негативные последствия, надо все-таки определиться с объектом защиты, с его границами, условиями функционирования, взаимосвязями и решаемыми задачами. Тогда у меня сразу сузится область моделирования и моя деятельность будет более эффективной. И косвенно моя правота подтверждается и самой методикой. По крайней мере входными данными для 1-го этапа моделирования на рисунке 1 указаны как раз сведения об архитектуре систем и сетей (на мой взгляд было бы проще написать просто "объект защиты") и особенностях их функционирования. Многие пункты 2-го раздела говорят именно об описании границ анализируемой системы, но почему этот этап не выделен отдельно.
Пункт 2.4 как раз нам и говорит о том, что надо определиться с границами объектам защиты (почему-то названными границами процесса моделирования) и его взаимосвязями, в том числе и с обеспечивающими системами. Например, если злоумышленники выведут из строя подстанцию, которая дает электричество на мой офис, то им не надо будет атаковать ни моих удаленных пользователей, ни кластер удаленного доступа. Они решат свою задачу окольным путем (если им надо было нарушить доступность всей системы). Тоже самое касается и провайдеров VPN-доступа, которые не относятся к моему объекту защиты, но при этом этот объект от них сильно зависит и мы должны включить его в зону нашего внимания. Правда, регулятор, возможно, чтобы не усложнять методику, исключил обслуживающие системы из процесса моделирования, оставив только те, которые принадлежат обладателю информации или оператору ИС или сети, ее обрабатывающей, то есть лицу, с которым у меня заключен соответствующий договор. Рисунок 2, про границы моделирования для ИС, использующих ресурсы внешнего ЦОДа, это подтверждает. Не знаю, насколько это правильно; я бы все-таки старался учитывать еще и системы обеспечения. Пока я не дошел до следующих пунктов, задамся вопросом, а надо ли мне при моделировании учитывать возможные неправомерные действия, осуществляемые при ремонте компонентов моей системы? А при их поставке и разработке?
Пункт 2.7 подсказывает нам, что у меня могут быть и средства защиты, и выстроенные процессы ИБ, но в них могут быть уязвимости и поэтому безоговорочно доверять им не стоит. Хорошее замечание, но которое нам еще аукнется на последующих шагах.
Моделировать угрозы, согласно п.2.8, может либо обладатель информации или оператор, ее обрабатывающий, либо лицензиат ФСТЭК. Почему моделирование угроз вдруг стало лицензируемым видом деятельности я не знаю; наверное, просто по привычке. Также не совсем понятно, почему я не могу воспользоваться моделью угроз от разработчика системы, который гораздо лучше знает свое детище, чем другие лица? Тем более, что дальше в разделе именно на провайдеров используемых нами систем возлагается обязанность предоставить нам эту модель угроз.
Внезапно, пункт 2.9, который должен быть в 1-м разделе, говорит нам о том, что для экспертной оценки я могу создавать группы экспертов согласно приложению 2, которое нам подсказывает, что эксперты должны быть независимыми, не иметь финансовых интересов (у лицензиатов ФСТЭК их, конечно же, нет), быть квалифицированными и т.п. А чтобы их оценка была более взвешенной, методика ФСТЭК рекомендует использовать больше столетия используемый в разных отраслях метод Дельфи. Хорошо, что Приложение 2 рекомендуемое, а не обязательное, а то согласно нему формирование экспертной группы превратится в задачу посложнее самого моделирования угроз. Но рекомендацию использовать метод Дельфи я могу только приветствовать.
П.2.11 рекомендует для "внешних" систем использовать модели угроз, разработанные владельцем этих внешних систем (ЦОДов, облаков, сервисов телеконференций, файловых хранилищ, CRM-систем и т.п.). Тут у меня два комментария. Во-первых, таких владельцев, которые бы готовы были делиться своими моделями угроз, почти нет. На их сайтах вы этой информации точно не найдете, а при общении с ними, они, даже если и имеют разработанные модели угроз, будут ссылаться на конфиденциальность этой информации и невозможность поделиться ею. ФСТЭК в этом случае не рекомендует пользоваться услугами таких компаний. С точки зрения специалиста по ИБ я может и разделяю подход регулятора, но с точки зрения бизнеса прекрасно понимаю, что ему наплевать на наличие/отсутствие моделей угроз у контрагентов. Он оценивает свои риски совсем иначе. И если уж мы говорим о риск-ориентированном моделировании угроз (раз уж мы привязываемся к негативным последствиям), то и стоять на этом надо до конца (хотя стоять на своем бывает больно). И задача службы ИБ как раз и состоит в том, чтобы оценить эти риски и дать бизнесу рекомендации по их снижению. Поэтому если у выбранного поставщика услуг нет модели угроз, ее надо разработать самим и исходя из нее сформировать защитные мероприятия.
Этот же пункт почему-то накладывает на поставщика услуг какие-то обязанности; хотя в преамбуле проекта методики этот субъект не указан в числе тех, на кого методика распространяется. Поэтому он никому ничего не обязан предоставлять, обновлять, информировать и т.п. Не надо строить иллюзий насчет этого.
А рисунок 3, кстати, запутывает процесс моделирования. Распределение зон ответственности лучше было отражать на рисунке 2. Это же относится и к рисункам 4 и 5. Понятно, что хотел сказать регулятор, но отобразить это стоило бы, как мне кажется, в виде вертикальных блоков/зон, как это часто показывают в презентациях и статьях по защите облаков, рассказывая про разделяемую ответственность. Я вот нашел такую в какой-то из своих презентаций 10-тилетней давности. На ней, кстати, показан и такой непростой вопрос при моделировании угроз, как API, который в методике назван интерфейсами взаимодействия с иным программным обеспечением.
Пункты 2.13 и 2.15 противоречат друг другу в той части, что в первом случае указано, что структура модели угроз должна соответствовать приложению 3, а во втором - это уже не требование, а рекомендация.
Пункт 2.15, говорящий о том, что модель угроз должна быть актуальной, очень правильный. Он описывает ситуации, когда надо обновлять модель угроз, но он же и ставит вопрос о том, насколько эту задачу в описанном виде способны реализовать те, для кого эта методика станет обязательной. В последнем абзаце этого пункта говорится о том, что надо выявлять максимально возможное число сценариев реализации угроз безопасности, которые должны быть помещены в модель угроз. Забегая вперед, можно сказать, что хотя термин "сценарий реализации угроз" нигде не определен, это совокупность возможных техник и тактик, применяемых нарушителем.
Таблица 4 6-го раздела содержит 10 тактик и 77 техник. И если мне надо определить максимально возможное число таких совокупностей, то взяв на вооружение комбинаторику и предположив, что для реализации угрозы нарушитель будет использовать все 10 тактик (то есть шагов kill chain), я получу... до хрена вариантов. Очень условно, я бы назвал, что таких комбинаций будет чуть больше 1 триллиона (число сочетаний из 77 техник по 10 штук в каждом). Даже если "выровнять" число техник до 5 для каждой из 10 тактик, число возможных сочетаний у меня будет больше 10 миллиардов. Для матрицы MITRE ATT&CK (я о ней писал неоднократно), которую использовать тоже можно, у меня число возможных сочетаний будет измеряться квадриллионами. Да, я понимаю, что в реальности не все такие сочетания будут возможны, но формулировка "максимально возможное число сценариев" заставляет перебирать их все и отбрасывать неприменимые. А в условиях отсутствия средств автоматизации такой работы, на ней все и умрут...
На этой позитивной ноте я завершил изучение 2-го раздела проекта методики моделирования угроз. Завершу и эту заметку, продолжение которой будет завтра.
