Привет, Хабр! Меня зовут Александра, я ведущий системный аналитик отдела криптографии ИнфоТеКС. При разработке системы, важной с точки зрения безопасности, сталкиваешься с тем, как много усилий нужно потратить на учет всех требований безопасности, которые должны в ней быть. Соблазн бросить эту задачу и переключиться на более приятные пользовательские фичи очень высок :) Требования безопасности – не самая интуитивно понятная вещь, работать с ними первое время может быть непривычно и сложно. 

Моя статья будет полезна аналитикам и другим специалистам, разрабатывающим систему, для которой важна безопасность. Я поделюсь рабочими подходами из общепринятой в нашей компании практики, которые помогут справиться с требованиями безопасности и ускорить освоение этой непростой темы. 

План моего рассказа:

• Что мы подразумеваем, когда говорим о безопасности;

• Самые распространенные проблемы, с которыми мы сталкиваемся при работе с требованиями безопасности;

• Три основных подхода, которые мы используем в работе: их преимущества и ограничения;

• Какие полезные умения мы получим в результате применения этих подходов

Понятие безопасности

Сначала коротко о терминах, чтобы быть в одном контексте. Что такое безопасность? Про безопасность имеет смысл говорить в контексте угроз, от которых мы хотим защититься. Общее определение безопасности из федерального закона "О безопасности":

Безопасность – состояние защищенности жизненно важных интересов личности, общества и государства от внутренних и внешних угроз.

Вот как описано понятие информационной безопасности в ГОСТ Р 50922-2006:

Безопасность информации – состояние защищённости информации [данных], при котором обеспечены ее [их] конфиденциальность, доступность и целостность.

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

Можно взглянуть на безопасность и с точки зрения того, что она является нефункциональным требованием (НФТ) к системе. Согласно одному из популярных стандартов в области бизнес-анализа ВАВОК Guide v3:

Безопасность как НФТ – аспекты решения, защищающие содержимое или компоненты решения от случайного или злонамеренного доступа, использования, разрушения или раскрытия.

Обычно в понятие безопасности включают также и доступность, что, кстати, отражено в предыдущем определении из ГОСТ Р 50922-2006. Однако в ВАВОК Guide доступность выделена как отдельный тип нефункционального требования:

Доступность как НФТ – степень, в которой решение является работоспособным и доступным, когда это требуется для использования, при этом часто выражается в процентах времени, в течение которого решение доступно.

Далее в статье я буду подразумевать, что доступность является частью понятия безопасности. Однако для сравнения различных типов нефункциональных требований будет полезно их разделить – к этому я ещё вернусь чуть позже.

Трудности при работе с требованиями безопасности

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

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

Представим гипотетическую ситуацию. Приходит к вам заказчик и говорит – «я тут в новостях увидел, что была хакерская атака на компанию, похожую на нашу. Давайте мы от этого защитимся, чтобы с нами такого не произошло! Короче, сделайте систему безопасной, а как именно – откуда я знаю, вы же специалисты, должны сами разобраться». Часто после такой постановки задачи у аналитика возникает ступор, из-за которого он откладывает задачу и старательно пытается про неё забыть. Но, допустим, вам удалось выйти из ступора и вы сформулировали требование (к примеру): каждый пользователь должен проходить двухфакторную аутентификацию для доступа к системе. Кажется, что это позволит избежать тех атак, которые были в новостях, плюс мы учли требования регулятора по этой теме, если они были. Но тут на требования начинают жаловаться пользователи:

«А почему стало так сложно заходить в систему? Можно вернуть как раньше было? Нам без пароля было очень удобно логиниться!»

Потом на требования смотрит архитектор или разработчик и объясняет, что для выполнения всех этих требований безопасности придется не дорабатывать систему, а переписать ее заново:

«И где были раньше эти требования, сейчас уже поздно их выполнять».

Все заканчивается тем, что заказчик смотрит на объём доработок и говорит:

«Да это же полгода минимум делать, вы что! Мы передумали. Новость про атаки была неделю назад, а на этой неделе у нас новость про экономический кризис, так что приоритеты поменялись».

(занавес, расходимся)

Ситуация конечно утрированная, а все совпадения случайны, но в той или иной степени многие могли реально столкнуться с подобными репликами. Давайте попробуем разобраться, что же конкретно могло пойти не так.

Сложность трактовки требований регулятора

Когда мы анализировали требования регулятора, могли заметить, что чаще всего они отвечают на вопрос «ЧТО необходимо сделать», а не «КАК именно это сделать». Требования могут быть достаточно абстрактны или допускать несколько вариантов решения. Либо непонятно, как применить их к нашему конкретному сценарию. Еще бывает, что требования регулятора недостаточны, либо избыточны для нашей конкретной ситуации. 

Продолжение примера про аутентификацию

Например, мы прочитали в требованиях регулятора, что должна быть двухфакторная аутентификация пользователей. Сразу возникает вопрос, а какие факторы использовать? Есть три наиболее известных категории:

• что пользователь знает (например, пароль или PIN-код),

• чем владеет (например, токеном или мобильным телефоном),

• кем является (например, отпечаток пальца).

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

Сложность трактовки требований заказчика

С требованиями от заказчика тоже не всё гладко. Заказчик может на эмоциях от новостей заказать безопасную аутентификацию пользователей и, одновременно с этим, забыть про другие важные меры защиты. Держать в голове сразу все необходимые меры защиты практически невозможно. Либо заказчик может придавать бóльшее значение тем атакам и уязвимостям, про которые он недавно слышал и которые недавно случились, соответственно ставить им бóльший приоритет. В то же время, он будет недооценивать те угрозы, с которыми он лично не сталкивался и которые он не понимает. Но эта эмоциональная приоритизация очень мало связана с объективной реальностью.

Дело здесь в том, что безопасность системы в целом зависит от безопасности самого слабого звена, поэтому отдельные меры защиты могут вообще ничего не дать. Хорошо подходит метафора защиты крепости во время осады. Мы можем сколько угодно защищать ворота, но если никто не следит за тоннелями под крепостью – враг легко проникнет, и все наши усилия будут бессмысленны. Поэтому подход к безопасности должен быть комплексным.

Могут быть и другие проблемы. Требования безопасности часто идут вразрез с другими требованиями заказчика и требуют сложных компромиссов, а также могут сильно увеличить стоимость решения. При этом, попытки учесть все требования и урезание мер защиты в угоду другим требованиям могут привести к ситуации, когда вроде бы защита есть, но, по сути, это одна видимость. И хорошо, если заказчик понимает важность требований безопасности, а есть и вариант услышать рассуждения в духе «всегда нормально работало, никто систему не ломал, значит и дальше всё будет хорошо». 

Другая крайность – когда одно из заинтересованных лиц придумывает невозможное количество требований безопасности и не может остановиться. Возникает вопрос, как определить золотую середину и сделать ровно столько, сколько действительно нужно, не превращаясь в параноика?

Продолжение примера про аутентификацию

Допустим, заказчик ставит приоритет на удобстве пользования приложением и считает, что приложение должно давать доступ к своим функциям за один шаг. А мы думаем, как же нам сохранить доступ в один шаг, и при этом выполнить требование регулятора по двухфакторной аутентификации? Ведь два фактора – это минимум два действия, а обычно больше. И вот тут мы немного подвисаем, потому как в целом это возможно, но только если мы совмещаем один или оба шага аутентификации с какими-то предыдущими операциями пользователя. Например, если мы аутентифицируемся в одном из приложений, а в остальных взаимосвязанных приложениях шаги аутентификации «пропускаем», используя механизм Single Sign On. Но, мы-то думали, что доработаем быстренько только отдельное наше приложение и всё, а тут оказывается всё не так просто.

Влияние НФТ на требования по безопасности

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

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

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

Группа требований, которые либо не влияют на безопасность, либо иногда помогают, а иногда мешают.

• Совместимость. В части корректного взаимодействия должна помогать безопасности, но в части поддержки устаревших и не всегда безопасных протоколов может сильно помешать.

• Локализация. Первое что приходит тут в голову – это локализация хранения данных пользователей в пределах конкретной страны по требованиям законодательства. С точки зрения безопасности государства такая локализация безусловно полезна, но с точки зрения сохранения этих ценных данных внутри компании, которая локализует данные, – могут быть дополнительные риски, поскольку контролировать ценные данные в стране, где компания мало представлена, может быть довольно сложно. Возможна утечка данных, промышленный шпионаж и так далее.

• Доступность. Если не включать её в понятие безопасности, то может как помогать, так и мешать. Бесперебойность функционирования средств защиты безусловно помогает. Но если требовать бесперебойную работу каких-то полезных для пользователей сервисов, то возможно где-то придётся пожертвовать защитой от несанкционированного доступа. Любая защита неидеальна, и защита от несанкционированного доступа будет мешать не только нарушителям, но иногда и легальным пользователям, это неизбежно.

• Надёжность. В целом такая же ситуация, как и для доступности.

Группа требований, которые чаще мешают безопасности, чем помогают. Переносимость с одной среды на другую, расширяемость – как способность включать новую функциональность, масштабируемость, ремонтопригодность – имеют одну общую проблему. Чем больше разных конфигураций у системы, чем в большем количестве сред она может работать, чем больше данных и операций может начать обрабатывать – тем труднее учесть все нюансы безопасности. Для систем, где требуется серьёзная защита, стараются по возможности уменьшить вариативность сценариев и обстоятельств, в которых функционирует система, иначе обосновать безопасность системы становится слишком трудно. Хотя, субъективно, эти требования мешают не так часто.

Группа требований, которые обычно мешают безопасности. Как правило, с ними больше всего проблем и на них нужно обратить пристальное внимание:

• Удобство пользователей. Это действительно часто идёт вразрез с безопасностью. Запоминать пароли, вводить одноразовые коды, носить с собой токены – однозначно неудобно для пользователя, но придется адаптироваться и искать баланс.

• Эффективность и производительность. Тоже очень часто страдают, потому что меры защиты требуют вычислительных мощностей и других ресурсов.

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

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

Ограничения концепции и архитектуры системы

Думаете, на этом с проблемами закончили? Нет, пока не расслабляемся. Проектируемая нами система тоже может подкинуть сюрпризы.

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

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

Продолжение примера про аутентификацию

Может оказаться, что физического интерфейса для ввода второго фактора не предусмотрено в системе. Получается, что выполнить требование «в лоб» невозможно.

Предубеждения аналитика

Не меньше чем объективные обстоятельства, нам могут мешать наши собственные предубеждения о требованиях безопасности.

Нам может казаться, что требования безопасности – это что-то такое сложное и непонятное, поэтому лучше отложить их на потом. 

«И вообще, мы за это не отвечаем, у нас в компании есть безопасники, вот пусть они и думают!»

В результате время, когда требования безопасности могли быть реализованы с минимальными затратами, бывает упущено.

Мы также можем наделять других людей бóльшими знаниями, чем на самом деле у них есть. Если заказчик не просил сделать безопасное решение, то это совсем не означает, что оно ему не нужно. Возможно, заказчик рассуждал так же, как и вы, надеясь на ваши суждения и на суждения безопасников. 

Задача аналитика – подсветить проблемы, которые могут возникнуть из-за игнорирования безопасности, так, чтобы заказчик их осознал и смог принять обоснованное решение. А если специалист в области безопасности высказал своё экспертное мнение, то не нужно воспринимать его как истину в последней инстанции. В конце концов, никто не знает требования к системе так же хорошо, как их знаете вы, и без дискуссии с вами и с командой разработки его советы, даже сами по себе хорошие, могут быть бесполезны.

Подходы к работе с требованиями безопасности

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

Следовать правилам: опираемся на законы и стандарты

Первый подход – изучить законы и стандарты на тему безопасности. 

Подход заключается в том, что мы изучаем доступные нам и применимые к нашей системе требования регуляторов и стандарты, а потом пытаемся применить их для своей задачи. Среди российских законов и стандартов нам нужно опираться на документы от ФСБ России, ФСТЭК России, Минцифры РФ, Центрального банка и других. Не буду перечислять все, достаточно подробно и хорошо об этом уже рассказал в своем блоге Алексей Лукацкий.

Что касается зарубежных и международных стандартов/законов, то они пригодятся, если вы ориентируетесь на зарубежных пользователей. Но даже если это не так, не игнорируйте их. 

Почему? 

Во-первых, есть регуляторы с международным влиянием, такие как PCI Council – они выпускают стандарты PCI DSS по защите платёжных карт. Все международные платёжные компании подчиняются этим стандартам, а до последнего времени подчинялись и российские платёжные компании. 

Во-вторых, количество зарубежных стандартов больше, чем отечественных, и если вы не нашли информацию по нужной вам теме в отечественных стандартах, то есть смысл поискать в зарубежных. Например, стандарты от международных организаций, такие как: IETF, ISO и другие. Можно посмотреть и зарубежные национальные стандарты: американские NIST и FIPS, немецкие BSI и другие.

Продолжение примера про аутентификацию

Допустим, мы узнали, что отечественный регулятор требует двухфакторную аутентификацию. Прочитали основополагающий документ ГОСТ Р 58833— 2020, который является национальным стандартом РФ по части идентификации и аутентификации, выяснили рекомендуемый сценарий аутентификации. Хотелось бы почитать по этой теме что-то ещё, чтобы расширить свой кругозор и сделать всё правильно. Можно читать толстые учебники по ИБ, но это долго, а информация в них может быстро устаревать.В этом случае полезно ознакомиться с другими стандартами, даже необязательными для нас. Информация там достаточно сжатая и регулярно обновляется. Например, мы можем найти рекомендацию проверять несовпадение пароля с логином и отсутствие пароля в известных данных об утечках паролей (NIST SP 800-63B). Не стоит воспринимать все рекомендации буквально, поскольку придумывание пароля, который не был вообще ни в одной утечке, – это очень увлекательная игра наподобие The Password Game, не всегда выполнимая за разумное время :) Кому-то эти вещи и так понятны, но забыть про часть из них всё равно достаточно легко. Поэтому пробежаться по различным источникам бывает полезно

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

Избежали штрафов, нас приняли в какой-нибудь отраслевой клуб надёжных компаний – ок. Поняли, от чего оттолкнуться – тоже хорошо, если идей изначально было мало. Узнали лучшие практики обеспечения безопасности – вообще отлично, потому что над стандартами, как правило, работает много умных людей, и достичь того же качества требований и подходов в одиночку практически нереально.

Но всё же, с большой вероятностью мы не достигли всего, что хотели.

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

Рекомендую ограничить себя по времени, чтобы не застопоривать работу, даже если ничего полезного не удалось найти. И не удивляемся, если, в конце концов, у нас вообще не оказалось ни законов, ни стандартов, на которые мы можем опереться. 

А что тогда делать?

Формировать своё видение: используем модель угроз и нарушителя

Стоит применить подход, который помогает выделить основные угрозы для конкретной системы, обосновать необходимость закрытия этих угроз и расставить приоритеты. Подход такой – использовать модель угроз и нарушителя, а затем договориться о мерах защиты против этих угроз и нарушителей. Не буду подробно рассказывать, как сделать модель, т.к. эта отдельная большая тема. Сконцентрируемся на том, что полезного из неё можно узнать.

Что такое модель угроз и нарушителя, и как с ней связаны меры защиты? По-простому говоря, модель отвечает на вопрос «что плохого может произойти», а меры защиты отвечают на вопрос «как мы от этого плохого планируем защититься».

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

Что нам даёт информация из модели угроз и нарушителя? 

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

Во-вторых, из списка актуальных угроз и нарушителей мы поймём, какие атаки в принципе есть смысл рассматривать, а какие – нет смысла. И какие типы нарушителей безопасности (то есть атакующих) есть смысл рассматривать, а какие нет. Это важно по той причине, что уязвимости по отношению ко всем возможным атакам и ко всем возможным нарушителям закрывать очень дорого. Защититься от целенаправленных атак со стороны организованной хакерской группы гораздо сложнее, чем от хакера-одиночки. Но еще сложнее защититься от внутреннего нарушителя – системного администратора, решившего навредить по какой-то причине своему работодателю. Из этого уже следует, что благодаря модели угроз и нарушителя, мы можем обосновать, почему мы сформулировали именно такие требования безопасности, а не какие-то другие. В результате, мы можем сформулировать конечный перечень требований, которые нам необходимо выполнить.

В-третьих, мы сможем расставить приоритеты требований безопасности. Чем выше оценен риск угрозы, тем больше приоритет у требования по защите от этой угрозы. 

Риск - это комбинация вероятности нанесения ущерба и величины этого ущерба.

Чем больше вероятность и чем больше потеря в случае реализации угрозы, тем больше риск. Риск может быть измерен как количественно – через объём ущерба (потерянных денег), умноженный на вероятность, так и качественно – как высокий/средний/низкий риск. Составляющие риска, ущерба и вероятности тоже можно оценить либо количественно, либо качественно. Независимо от того, какую методику оценки вы выберете, обратите внимание, что значение имеет именно совокупность ущерба и вероятности, а не каждый параметр отдельно. 

Например, если на офис компании упадёт метеорит, то ущерб будет колоссальный, но вероятность события настолько мала, что итоговый риск очень маленький и им можно пренебречь.

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

Если у нас есть описание применяемых мер защиты, то из них мы можем вынести текущие договорённости о том, как мы планируем защищаться от угроз. Можно воспринимать меры защиты как детализированные требования безопасности, закрывающие определённый набор угроз в конкретной системе, или как технические решения. Однако, даже если решения по мерам защиты уже приняты, мы не рекомендуем принимать всё на веру и отказаться от их самостоятельного осмысления. Всё же, эта практика довольно непростая, и есть довольно много мест, где можно ошибиться. Поэтому на существующие материалы по модели угроз и нарушителя, а также меры защиты мы обязательно смотрим, но перепроверяем сами тоже, по возможности.

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

Может возникнуть резонный вопрос: всё это конечно хорошо, а где же нам взять эту модель угроз и нарушителя? Если система подпадает под требования ФСТЭК России и ФСБ России, то скорее всего они уже где-то есть либо целиком, либо отчасти. Также, вполне возможно, что в вашей компании есть собственные практики безопасной разработки, включающие построение модели угроз и нарушителя. Если эта практика уже выполнена в вашем проекте, есть смысл познакомиться с результатами. Если совсем ничего нет, то, в принципе, можете построить модель самостоятельно.

Продолжение примера про аутентификацию

Чтобы сотруднику компании не приходилось слишком часто вводить свой пароль для входа в систему, мы решили добавить функцию его сохранения на устройстве сотрудника. Однако в результате построения модели угроз и нарушителя мы выявили, что иногда пользователь заходит в систему не со своего личного устройства, а с корпоративного устройства общего пользования. Таким образом, войти в систему смогут и другие пользователи этого общего устройства, и даже те, которые не должны иметь к ней доступ.

Что тут можно делать? 

Самый простой способ – просто запретить сохранять пароли на любых устройствах, однако это вызовет неудобства у большинства пользователей системы. Можно попробовать установить разные политики безопасности для различных типов устройств, чтобы можно было сделать послабления для личных устройств, избавившись при этом от угрозы со стороны устройств общего пользования.

Что мы получили из описанного подхода. 

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

Что ещё мы можем сделать в таких случаях?

Импровизировать! Решаем проблемы по мере поступления

Злоупотреблять этим подходом очень вредно, поскольку при повсеместном использовании он приводит к бессистемному исправлению только части проблем, и не факт, что самых важных проблем! Тем не менее, на 100% запретить и исключить этот подход не получается по следующим причинам:

1. Закрыть уязвимость может быть нужно очень быстро, и пока мы будем выполнять все best practice по модели угроз и нарушителя, поезд уже уйдёт, и, возможно, спасать уже будет нечего. Например, выявлена уязвимость нулевого дня в компоненте с открытым исходным кодом – все такие случаи заранее предусмотреть нельзя.

2. Модель угроз и нарушителя отвечают на все вопросы по безопасности только в идеальном мире. А мы не живём в идеальном мире, мы живём в условиях недостатка информации. Ссылаться в этом случае на недостатки модели и оправдывать этим своё бездействие – иногда, конечно, допустимо, если это побуждает двигаться в сторону комплексного обеспечения безопасности, но всё же, чаще всего, такое поведение не оптимально.

3. Даже если модель угроз и нарушителя идеально написана, у вас могут возникнуть такие вопросы, которые требуют не просто свериться с моделью, а ещё и построить логическую цепочку рассуждений на её основе.

К комплексной безопасности нужно безусловно стремиться, но затыкать отдельные «дыры» и решать отдельные вопросы тоже надо уметь. Всё, что дальше будет рассказано в этом разделе, является отдельными частями методики построения модели угроз и нарушителя, упрощёнными таким образом, чтобы можно было быстро применить их к локальной проблеме. Например, сформулировать правильный вопрос во время интервью с заказчиком или экспертом.

Во-первых, как и всегда при разработке требований, нужно исходить из ожидаемых свойств системы. Возможных свойств безопасности может быть много, поэтому нужно выделить, какие конкретно требуются в нашем случае. Они сильно зависят от защищаемого объекта. Если защищаемым объектом является информация, то мы можем потребовать:

• конфиденциальность, то есть защиту от раскрытия информации,

• целостность, то есть защиту от её искажения,

• доступность,

• ... список можно продолжать.

Продолжение примера про аутентификацию

Например, у нас есть требование, чтобы доступ к перечисленным функциям системы имели только администраторы. Это значит, как минимум, что администраторы системы должны быть аутентифицированы, иначе мы не поймём, кто из пользователей администратор, а кто нет. Это получается свойство подлинности, или, другими словами, – свойство аутентичности для данных и для команд, посылаемых администратором.

Что ещё может помочь. 

Поспрашивайте у бизнеса и у экспертов, какие проблемы с безопасностью были в прошлом в вашей компании или у похожих компаний на рынке, как часто, какие были обстоятельства при реализации угрозы, какой ущерб был нанесён. Возможно, в прошлом была крупная утечка персональных данных, которая привела к скандалу в СМИ, возможно была утечка паролей. Может быть, была DoS атака на сайт, из-за которой он перестал работать. Это не поможет выявить полный список проблем с безопасностью, но поможет найти список проблем, которые уж точно надо решать.

Продолжение примера про аутентификацию

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

Еще одна тактика заключается в том, чтобы придумать пользовательский сценарий для нарушителя. 

Думай как злоумышленник!

Эта тактика, наверное, наиболее сложная из списка импровизационных, но, в то же время, даёт глубокое понимание происходящего и позволяет сделать неожиданные открытия. Кого мы обычно рассматриваем, когда пишем пользовательские сценарии? Мы рассматриваем пользователя, который делает с нашей системой всё правильно, получает работающий функционал, мы от этого получаем прибыль, и все довольны. Но на самом деле, есть и другие пользователи – злоумышленники, которые пытаются специально нашу систему сломать. А ещё есть пользователи, которые просто не осознают все риски и своими неосторожными действиями могут причинить вред как себе, так и другим. Про таких пользователей нам думать не очень приятно, но если мы хотим сделать систему безопасной, то это просто необходимо. Пофантазируйте, кто и почему может нарушить работу вашей системы, у кого к этому есть интерес. Накидайте идеи для таких сценариев.

Если вы хорошо постарались, у вас появился с десяток таких сценариев, а может быть и больше. Как выбрать из них только нужные?

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

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

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

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

Продолжение примера про аутентификацию

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

Если такой нарушитель у нас есть, то начинаем думать, а что ещё он может сделать? Если он может подменить данные для аутентификации пользователей, то, может быть, он и всё ПО может подменить? Может быть, он может прочитать или подменить другие критичные для безопасности файлы? Может быть, он подменит данные для аутентификации пользователей в резервной копии, а потом восстановит эту подменённую копию? 

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

Нужно стараться мыслить немного шире того вопроса, которым мы задались изначально. Как ни парадоксально, чаще всего такой широкий взгляд в конце концов упрощает рассуждения и помогает быстрее прийти к ответу. Это происходит потому, что в процессе мы выявляем важные ограничения, которые сужают количество вариантов для выбора. На детальном уровне эти ограничения часто не видны, и, как говорится, «за деревьями леса не видно».

Как обосновать и приоритизировать требования безопасности?

Если есть модель угроз и нарушителя, то там эти вопросы уже проработаны, как мы говорили об этом раньше. Если нет, то как и для любых других типов требований мы спрашиваем себя, какую выгоду даст реализация данного требования безопасности. Только в случае требований безопасности выгодой чаще всего будет не приобретение чего-либо, а отсутствие ущерба – денежного, репутационного или какого-то ещё. А может и не быть никакого ущерба, или он слишком маленький и редко возникающий – тогда требование безопасности не нужно.

Продолжение примера про аутентификацию

Если мы не реализуем аутентификацию пользователей перед выполнением каких-то значимых операций в интернет-магазине, то мы должны понимать, что допускаем к использованию системы потенциально бóльшее количество злонамеренных пользователей. Они, в свою очередь, могут вывести интернет-магазин из строя на значительное время, и это приведёт к прямым денежным потерям, поскольку обычные пользователи не смогут ничего купить на сайте.

Резюмируем. Что нам дает использование подхода «решаем проблемы по мере поступления»:

• Если проблема была критичная, то мы её быстро исправили;

• Если у заказчика появилась потребность оперативно закрыться от каких-то угроз, которые не были учтены ранее в модели угроз и нарушителя, то мы смогли выявить что это за потребность и правильно её сформулировать;

• Если модель угроз и нарушителя, а также какие-то договорённости по мерам защиты уже были ранее, мы перепроверили их своей логикой, и возможно восполнили какие-то пробелы.

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

Так какой подход в итоге выбрать?

Как обычно, всё зависит от обстоятельств :) Подумайте, преимущества каких подходов вам наиболее важны в текущий момент.

Как правило, хорошо работает следующая последовательность действий:

1. Начать с законов и стандартов, чтобы сразу отсеять большую часть неподходящих решений, и уже не тратить на них время.

2. Когда нормативные документы изучены, браться за детальную модель угроз и нарушителя.

3. В тех случаях, когда первые два подхода неприменимы, начинать импровизировать.

А оно мне точно надо, как аналитику?

А может быть, проще полностью довериться эксперту по безопасности или заказчику работ? Определённый соблазн «поплыть по течению» конечно есть, но всё же преимущества описанных подходов перевешивают.

Во-первых, мы сможем правильно и обоснованно формулировать требования безопасности. Когда мы понимаем логику их формулирования, мы начинаем больше включать критическое мышление, и если требования, затрагивающие безопасность, спускают нам «сверху», нас уже так просто не запутать. А когда мы уже умеем дискутировать на тему безопасности, тогда мы можем достигать выгодных компромиссов и с другими типами требований. 

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