С 1-го ноября прошлого года, с того самого дня, как было принято Постановление Правительства РФ №1119, специалисты и заинтересованные лица из числа операторов персональных данных наперебой задают себе, друг другу и регулятору несколько вопросов, касающихся угроз 1-го, 2-го и 3-го типа (если кто не помнит/не знает или вообще не понимает, о чем речь - даю ссылку на замечательную запись и дискуссию в комментариях тут). Вопросы вкратце следующие:
Как вообще можно определить наличие НДВ и актуальность связанных с ними угроз.- Как вообще можно, не проводя анализ используемого ПО, определить наличие НДВ и актуальность связанных с ними угроз?
- Как можно защититься от угроз, связанных с НДВ, не влияя на код ПО или процесс его производства?
- Зачем вообще регулятору надо было акцентировать внимание на НДВ?
Не вдаваясь в подробности терминологии, принятой в мире и РФ в отношении безопасности приложений, инфраструктуры и прочего, не вступая в грубые дискуссии с коллегами (пример дискуссии оживленной, но интеллигентной - по ссылке выше), попробую ответить на все эти вопросы, не общественности ради, а может быть даже больше для себя, чтобы утрясти эти спорные моменты в голове.
Под НДВ в системном или прикладном ПО понимается возможность, функциональная или иная, присутствующая в ПО, но не описанная в документации, не заявленная на этапе создания ПО и, возможно, даже не известная никому, за исключением разработчика или высококвалифицированного исследователя (тех, кто называется в Методических рекомендациях ФСБ нарушителями Н4-Н6).
В данном случае важно понимать, что уязвимость и НДВ - понятия не тождественные. Не всякая уязвимость объясняется наличием НДВ, и не всякая НДВ влечет за собой уязвимость. Однако тот факт, что во многих случаях эти ситуации совпадают, заставил экспертное сообщество, занимающееся разработкой НПА обратить на это внимание. И с этого момента принято считать, что любые НДВ создают уязвимость, которую теоретически может использовать злоумышленик для реализации угрозы. Угрозы, связанные с использованием НДВ в системном или прикладном ПО (в точной формулировке ПП РФ №1119), могут быть актуальны при весьма определенных условиях, специфических и крайне редко встречающихся. Это и ценность обрабатываемой информации, и технология обработки информации, и характер НДВ, и - на мой взгляд, самое главное - модель нарушителя. Сочетание этих факторов и приводит к тому, что в подавляющем большинстве случаев угрозы, связанные с НДВ, неактуальны для защищаемых ИСПДн (и тут я согласен с господином Лукацким, хотя и, как мне кажется, привожу более весомые аргументы :-)). Вступив недавно с одним коллегой-разработчиком в около-философский спор: он утверждал, что никакие СЗИ не способны защитить от недостатков ПО, т.е. от НДВ, я сформулировал два наглядных примера:
Пример 1: При разработке ПО, обрабатывающего персональные данные, разработчиком явно была создана защитая в код и не отображающаяся ни в каких списках и перечнях учетная запись, позволяющая получить полный доступ ко всем данным вполне легально (без обхода функций разграничения доступа, соответственно, без появления инцидента ИБ). Является ли данная учетная запись НДВ? Несомненно. Будет ли угроза, связанная с этой НДВ, актуальной для ИС, где будет использоваться это ПО? Вряд ли. Звучит странно, но это совершенно логично, потому что о существовании данной НДВ знает только разработчик либо лицо, обладающее возможностью изучить исходный код ПО (например, кто-то в сговоре с разработчиком). Очевидно, что данным лицам нет смысла проводить исследовательскую работу, изучение исходных кодов (для не-разработчика), или нарушать соглашения с заказчиком вплоть до нарушений законодательства и соответствующего наказания (для разработчика). Для получения несанкционированного доступа к персональным данным есть гораздо более простые способы, и нарушители, выполняющие подобные действия, гораздо более низкого уровня, чем те, которые могут использовать НДВ. Следовательно, в данном случае угрозы, связаные с НДВ, будут неактуальны. Конечно, данный вывод можно сделать только по итогам анализа и моделирования угроз, но в большинстве случаев, он будет именно таким.
Пример 2: В качестве системного ПО используется ОС семейства Microsoft Windows. НДВ, существующие в Windows, известны и даже описаны в соответствующей литературе (что, кстати, звучит крайне интересно - недекларированные возможности документированы..), поэтому использовать их может не только разработчик ПО (представить, что Microsoft, при взаимодействии с иностранной технической разведкой, будет взламывать ИСПДн ЖЭКа, очень сложно), но и любое лицо, обладающее навыками разработки средств атак. Будет ли угроза, связанная с НДВ в СПО, актуальной для этой ИСПДн? Далеко не факт. Только в данном случае неактуальность будет обусловлена не соответствующей моделью нарушителя (требуется более низкая квалификация и меньшая осведомленность о системе), а особенностями обработки информации. Прямого доступа к ОС сервера, обслуживающего пользователей (в том числе, потенциального злоумышленника), нет ни у кого, кроме администратора, а следовательно выполнить некий произвольный программный код, чтобы воспользоваться известной НДВ в ОС, будет невозможно. И вновь угрозы, связанные с НДВ, неактуальны, хотя уже и по другой причине. И снова, данный вывод можно сделать только по итогам анализа угроз, который должен делать специалист, умеющий строить правильные причинно-следственные связи, а не паникер-оператор, который считает, что именно его ИСПДн будет объектом атаки по всем возможным фронтам.
Как можно защититься от угроз, связанных с НДВ, не влияя на код ПО или процесс его производства.
Правильный ответ - никак. Если возможность использования НДВ является легальной для рассматриваемой ИСПДн (как в Примере 1), то никакие наложенные СЗИ не обеспечат защиты соответствующей угрозы. Ни МСЭ, ни шифрование, ни аутентификация не помогут в этом случае. В Примере 1, мы в качестве меры защиты (априорной, позволяющей нам сделать вывод о неактуальности угрозы) рассматриваем организационную меру - договоренность и ответственность разработчика за нераспространение любой информации о создаваемой им системе. В том случае, если эта НДВ будет использована (и в этот момент она перестанет быть неизвестной для оператора), можно будет однозначно сделать вывод о том, что виновное в атаке лицо связано с разработчиком ПО. Этот факт должен работать как сдерживающий в отношении противоправных действий со стороны разработчика.
Если же вы ехидно ухмыльнулись, услышав про сдерживание путем ответственности, то единственный рабочий для вас метод защиты - сертификация разработанного ПО на отсутствие НДВ в системе сертификации ФСТЭК. Этот процесс долгий и дорогой (по сравнению даже с сертификацией СЗИ), и думается, что его выполнение не оправдано защитой от ущерба, определенного при моделировании угроз.
Зачем вообще регулятору надо было акцентировать внимание на НДВ.
Кажется, что причина неочевидна, ведь ранее НДВ никак не выделялись на фоне угроз периметра, вирусов и т.д. (то, что сейчас называется угрозами 3-го типа). Однако, по-моему, этот момент стоило выделить отдельно именно из-за факторов, упоминающихся мной в тексте выше. Угрозы, связанные с НДВ, следует предполагать и иметь ввиду, так как нет гарантированных способов подтверждения их отсутствия в готовом ПО (за исключением сертификации, но и ее "ценность" мы знаем, с учетом того, что Windows была сертифицирована без исходных кодов). От актуальных угроз, связанных с НДВ, очень сложно, практически невозможно защититься, и никакие средства защиты периметра или инфраструктуры в данном случае не будут эффективными. Для принятия решения по этим угрозам требуется проведение полноценного моделирования угроз и глубокого анализа, что, на мой взгляд, отличается от принятой в последние годы практики брать типовой перечень угроз из документов ФСТЭК и заниматься простой математикой. К тому же акцент требований по защите ПДн, связанных с НДВ, позволяет санкционировать появление таких технологий как SDLC, защищенное программирование и тестирование на проникновение на законодательном уровне.
Комментариев нет:
Отправить комментарий