среда, 28 сентября 2011 г.

Информационная угрозология, уязвимоведение и рисководство

Изначально, данный текст готовился, как ответ Чемберлену комментарий в топик Информационная опасность, но в итоге вырос до объемов отдельного поста, в связи с чем и публикуется в данном формате.

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

Чуть-чуть теории информации

К сожалению, чтобы получить ответ на наш вопрос, необходимо слегка углубиться в теорию. Оставив пока в стороне столь сомнительный термин "безопасность", рассмотрим первую составляющую названия нашей предметной области - "информацию". Единого и стандартизованного определения данному термину нет, поэтому мы возьмем наиболее распространенное и широко используемое во многих дисциплинах: Информация — это осознанные знания об окружающем мире, выраженные в сигналах, сообщениях, известиях, уведомлениях и т.д., которые являются объектом хранения, преобразования, передачи и использования. Несмотря на то, что информация является объектом хранения, преобразования, передачи и использования, она вполне может быть рассмотрена в отрыве от средств осуществления данных действий (носителей, источников, каналов передачи и приемников) совокупность которых, более известна под термином "информационная система" (ИС). Стоит отметить, что термин "ИС", здесь и далее, используется в более широком смысле, нежели в предметной области информационных технологий, не ограничиваясь лишь техническими способами реализации подобных систем. Информация, независимо от своей системы и четвертого измерения (я про время, если что), обладает рядом свойств, таких как кумулятивность, неассоциативность и некоммутативность, концентрация, старение, рассеяние и прочие, называемые атрибутивными свойствами. При рассмотрении информации в совокупности с конкретной системой и с учетом времени, у информации появляются новые свойства - прагматические, такие как объективность, достоверность, полнота, точность, актуальность, избыточность и интересующее нас - безопасность. Прагматические свойства, в силу их изменчивости во времени, правильнее было бы называть состояниями и безопасность здесь не исключение. Это означает, что если информация безопасна сейчас, т.е. находится в состоянии защищенности, то это еще никоим образом не говорит о том, что она останется таковой через мгновение. Но какую информацию можно называть безопасной? Из прагматичности данного свойства следует, что такую, которая хранится, обрабатывается и передается в защищенной в рассматриваемый отрезок времени системе. Иными словами, информация - сама по себе, не может быть безопасной или небезопасной - это целиком и полностью определятся той системой в которой она "живет". Состояние защищенности системы - кумулятивное свойство, складывающееся из трех необходимых, но не всегда достаточных состояний: - конфиденциальности, - означающего, что получить информацию могут только те субъекты ИС, которые имеют на это право; - целостности, - означающего, что информация не была подвержена несанкционированной модификации; - доступности, - означающего, что каждый субъект ИС, имеющий право на доступ к информации, имеет возможность реализовать его. Перечисленные состояния формируют так называемую стандартную модель безопасности информации "CIA". В зависимости от специфики и деталей реализации конкретной ИС и даже конкретного информационного потока или компонента, могут также рассматриваться и другие состояния. Так, в модель безопасности, на основе который построено моделирование угроз STRIDE, широко используемое в технических информационных системах, введены еще три состояния: - аутентичность, - означающее, что субъект, либо объект ИС является именно тем, в качестве чего он был идентифицирован или заявлен; - авторизованность, - означающее, что спектр действий аутентичного субъекта в отношении объектов ограничен; - апеллируемость, - означающее, что субъект ИС не имеет возможности отказаться от авторства совершенных им действий в отношении объектов. Понятно, что поскольку все перечисленные состояния не являются перманентными характеристиками, то в любой момент времени возможно нарушение одного или сразу нескольких из них. Такая возможность называется угрозой.

Угрозология

На самом деле, упомянутая выше STRIDE - это аббревиатура от названий угроз нарушения каждого из перечисленных состояний ИС: - spoofing, - аутентичности; - tampering, - целостности; - repudiation, - апеллируемости; - information disclosure, - конфиденциальности; - denial of service, - доступности; - elevation of privilege, - авторизованности. Совершенно очевидно, что далеко не каждая угроза актуальна для каждого из объектов ИС. Для выявления актуальных угроз строятся их модели. Подходов к построению моделей угроз достаточно много, наиболее распространенным и формализованным является поход на основе диаграмм потоков данных (DFD). Подробное рассмотрение данного подхода - тема отдельной, весьма немаленькой статьи, поэтому рассмотрим его в общих мазках. Для начала, строится верхнеуровневая DFD для моделируемой системы. Традиционно, элементами такой диаграммы являются: - процесс, - компонент ИС, осуществляющий обработку или передачу информации; - интерактор, - внешний, по отношению к ИС компонент, осуществляющий информационный обмен с каким-либо компонентом ИС; - хранилище, - компонент ИС, осуществляющий хранение или передачу информации; - поток данных, - канал обмена информацией между процессами, интеракторами и хранилищами; - граница доверия, - проходит через потоки данных и отделяет доверенные компоненты ИС от недоверенных. После этого, на основании актуальности угроз для каждого из типов компонентов (это все угрозы для процессов; S и R для интеракторов; T,R,I,D для хранилищ и T,I,D для потоков данных), а также на основании информации о пересечении потоками данных границ доверия, формируется список актуальных угроз для рассматриваемой модели. Затем осуществляется декомпозиция каждого из элементов диаграммы так, как если бы этот компонент был отдельной ИС, причем потоки данных, циркулирующие внутри него, также размечаются границами доверия, если это необходимо. По полученной DFD вновь строится список актуальных угроз, дополняющий предыдущий. Этот процесс повторяется рекурсивно до тех пор, пока достигнутая степень детализации модели не перестанет вносить новые актуальные угрозы, либо пока возможна декомпозиция, как таковая. В итоге, получается диаграмма типа (картинка взята из статьи, ссылка на которую приведена ниже): ...и весьма приличный, даже в случае небольших систем, список информационных угроз, актуальных для рассматриваемой ИС. Обратите внимание, при достижении достаточной степени детализации модели (и эта степень вполне достижима на практике), мы получаем список всех актуальных для нас угроз. Более подробно и с иллюстрациями, об этом процессе, можно почитать, например тут. Кроме того, рекомендую также весьма удобный инструмент на базе Visio, позволяющий в большей степени автоматизировать процесс моделирования угроз по STRIDE: Threat Modeling Tool, в документации к которому есть достаточно подробное описание процесса и пример готовой модели реальной системы (плагина для интеграции TMT с Visual Studio TFS, если быть точным). Однако же, построенная нами модель не учитывает специфику реализации ИС, которая почти всегда закрывает довольно большой процент актуальных угроз. Например, если для обмена информацией, проходящей через границу доверия, между интерактором и процессом используется защищенный канал, то угрозы T и I для соответствующего потока данных уже закрыты. Если, помимо этого, для подтверждения аутентичности интерактора используются криптографические средства (клиентский сертификат, цифровая подпись), то можно говорить о закрытии в данном компоненте угрозы S. И так далее и тому подобное. В конечном итоге, мы получим список всех угроз, контрмеры против которых в нашей ИС не внедрены. Условия, которые обуславливают существование таких угроз в системе называются уязвимостями.

Уязвимоведение

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

Рисководство

Чего-чего, а методик оценки рисков - как грязи, благо этот процесс не является специфичным для области ИБ и относится скорее к дисциплине риск-менеджмента. Тем не менее, для оценки рисков уязвимостей технических информационных систем традиционно применяются две методики. Первая - носит название DREAD, что является аббревиатурой факторов, которые учитывает эта шкала: - damage potential, - оценка ущерба от реализации угроз через эксплуатацию уязвимости; - reproducibility, - воспроизводимость способа эксплуатации уязвимости; - exploitability, - легкость эксплуатации уязвимости; - affected users, - оценка аудитории пользователей, затрагиваемых при реализации угроз через эксплуатацию уязвимости; - discoverability, - обнаруживаемость уязвимости. Для каждой из выявленных уязвимостей, перечисленных факторам дается оценка от 0 до 10 и рассчитывается суммарное значение риска по формуле: Risk_DREAD = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5 После чего приходит понимание того, какие уязвимости необходимо закрывать в первую очередь. Однако, DREAD несет в себе довольно оценочный характер и не учитывает многие факторы, например то, какие именно угрозы позволяет реализовать оцениваемая уязвимость и каково ее влияние на состояние защищенности системы в целом. Для более детальной оценки используется шкала CVSS (Common Vulnerability Score Sytem), с которой встречался каждый, кто подписан хотя бы на одну bugtraq-рассылку. Доводилось встречать в описаниях уязвимостей векторы типа AV:N/AC:L/Au:N/C:N/I:N/A:C? Вот, это - CVSS и есть. Шкала достаточно комплексная, учитывающая гораздо большее количество факторов, поэтому расписывать ее тут подробно - вряд ли будет разумным. Спецификация этой шкалы есть тут, калькулятор (ибо формулы там чуть сложнее, чем в DREAD) тут. Оценка рисков, несмотря на то, что ее в исходном топике отнесли к мишуре и яляется по сути конечной целью в процессе управления ИБ: получить представление о рисках информационной безопасности, связанных с эксплуатацией тех или иных уязвимостей, имеющихся в ИС и принять меры для того, чтобы снизить уровень этих рисков до приемлемого. Не более того, но и не менее. Собственно, это все, что касается предметной области информационной безопасности. Однако же, и в исходном топике, и в комментариях к нему, прозвучало несколько вопросов, которые остались неосвещенными здесь. Рассмотрим их и на этом закончим.

Классификации, стандарты, сертификации

Если, по ходу чтения этого поста, у кого-то возникло ощущение, что моделирование угроз - весьма кропотливый и рутинный процесс, то он совершенно прав. Это действительно весьма низкоуровневый подход, который позволяет добиться очень хороших результатов, но ценой довольно серьезных трудозатрат. С другой стороны, если рассматривать технические информационные системы, то вполне возможно выделить нечто общее между их отдельными группами. Взять к примеру веб-приложения: как считаете, сколько у различных веб-приложений будет общих угроз, выявленных на первых итерациях построения модели? Большая часть. Следовательно, к чему каждый раз строить новую модель, если специфика ИС уже дает некоторый базовый набор угроз, которые будут актуальны для каждого веб-приложения, независимо от деталей его реализации? И именно в результате рассмотрения некоей обобщенной модели, с учетом специфики, инструментария и средств реализации веб-приложений и появились классификации уязвимостей от WASC и OWASP. XSS, SQLi, LFI, CSRF, всевозможные мисконфигурации и т.п. - это оттуда. И это не уязвимости. Это их классы. Уязвимостями будут являться конкретные факторы и условия, специфичные для конкретной ИС: отсутствие экранирования входных данных при формировании текста SQL-запроса или при формировании текста HTML-документа, недостаточный контроль фрагментов путей, передаваемых в пользовательских параметрах, отсутствие контроля аутентичности источника HTTP-запроса и т.п. А вот может кто-нибудь сказать, в отрыве от конкретной ИС, какие именно информационные угрозы могут быть реализованы посредством эксплуатации XSS? Ну, основная-то понятно: нарушение целостности документа, отдаваемого сервером бразуеру пользователя, а дальше? Нарушение конфиденциальности сессионного токена? Да, вполне может быть. А это влечет за собой спуфиг и неапеллируемость, как минимум. А если будет угнана сессия администратора, то и повышение привилегий. А если сессии неугоняемые, но есть условия для CSRF? Тот же набор угроз или уже другой? А, по большому счету, разработчикам оно надо? Ведь они точно знают, что если в их коде не будет условий для XSS, то и угроз, которые могут быть реализованы через его эксплуатацию, также не будет, какими бы эти угрозы не были. Классификации уязвимостей в конкретных предметных областях инженерии ИС - это просто следующий уровень абстракции, позволяющий уйти от кропотливого моделирования угроз к принятию конкретных и уже сформулированных за вас контрмер, не более того. И, разумеется, чем менее ваша система будет соответствовать обобщенной модели, тем менее эффективны будет эти контрмеры. Стандарты - это еще более высокий уровень абстракции, предназначенный не столько для обеспечения состояния защищенности вашей системы, сколько для убеждения окружающих в том, что оно обеспечено. Любой стандарт слишком обобщен, чтобы говорить об эффективности описываемых в нем контрмер. Он решает иные задачи, и подлежит дополнению и уточнению практически для каждой системы, если перед вами стоит задача не только получить документ, подтверждающий, что вы соответствуете этому стандарту, но и иметь хорошо защищенную систему. Что же касается сертификаций, то это прямое следствие из основного предназначения стандартов. И, поскольку, тут есть интерес ряда крупных корпораций и государств, то относится к этому стоит, как к неизбежному злу, через которое надо пройти, чтобы продолжать заниматься тем или иным бизнесом, не более того. Стандарты - стандартами, сертификации - сертификациями, а обеспечение ИБ - процесс, хоть и пересекающийся с ними, но все же "чуть-чуть" иной.

Автору исходного поста

Информационную безопасность действительно тяжело измерить. Тяжело и переложить ее на язык математики и алгоритмизации (это примерно то же самое, что попросить PM'а алгоритмизировать в деталях процессы разработки и управления проектами), поскольку, как ни крути, но основным фактором, даже в технических ИС, являются люди. Хотя бы, потому что они их разрабатывают. Но дело тут в том, что все это - и не является целью данной предметной области. Я сам не люблю "белых воротничков", которые с умным видом рассуждают о необходимости соответствия стандартам, называют моделями угроз какие-то убогие сочинения на тему "как я провел все лето в офисе" и пытаются внедрять контрмеры, не понимая какие угрозы в терминах, озвученных выше, они реально закрывают. Хотя все как на подбор - "эксперты по ИБ", таки-да. Поэтому, если кто-то начнет оперировать пределами в качестве оценки защищенности ИС, или говорить об необходимости обеспечения отсутствия опасностей в какой-либо системе, прошу вас: ткните ему пальцем в глаз и передайте, что это от меня, ладно? Потому что задачами информационной безопасности является выявление всех актуальных угроз, обуславливающих их уязвимостей и управление связанными с их эксплуатацией рисками. Угрозология, уязвимоведение и рисководство.

Комментариев нет:

Отправить комментарий

Пожалуйста, будьте вежливы к автору и остальным посетителям этого блога