При всей симпатии к отечественному производителю, нечасто появляется от него документ, который приятно просто в руках подержать. Но удовольствие не мешает подметить пару багов, особенно если авторы о том специально спрашивают.
Во-первых, это клеймо исходной/проектной/эксплуатационной защищенности.
Чтобы не погружать читателя в изучение проекта, суть в том, что некоторые структурно-функциональные характеристики или условия эксплуатации информационных систем награждают их добавочным коэффициентом, который применяется к оценке всех угроз для этой информационной системы. Но почему всех-то? Вот, например, загнала виртуализация информационную систему из среднезащищенных в низкозащищенные – это сразу плюс одна ступень ко всем оценкам угроз, в т.ч. которые от виртуализации не зависят или даже зависят обратно: был, скажем, риск просмотра информации с дисплеев средним – станет почему-то высоким. Или выделили рабочие места администраторов в отдельный сегмент сети – защищенность из низкой стала средней – оценка угрозы отказа резервной ленты тоже упадет, хотя с чего бы. Это как клеймо «двоечника по жизни», не позволяющее получить пять за правильный ответ столицы Буркина Фасо, или отличника, который даже за неправильный меньше четырех с минусом не получит.
Чтобы исправить, нужно отказаться от «чохового» применения показателя защищенности ко всем угрозам и расписать, какие СФХ и УЭ какие конкретно угрозы поднимают, а какие вдруг наоборот. Если это сложно, тогда вообще снести эту тему в приложения (как это, например, обстоит с рекомендациями по формированию экспертной группы), озаглавив «СФХ и УЭ, которые должны рассматриваться как смягчающее/отягчающее обстоятельство при оценке связанных с ними (!) угроз».
Кстати, требование дотянуть показатель защищенности информационной системы до высокого к моменту ее ввода в эксплуатацию путем нейтрализации актуальных угроз – это какой-то казус, т.к. повторная его оценка будет зависеть опять только от архитектуры, и если ту не меняли, то и оценка не изменится, не взирая ни на какие нейтрализации. Такова таблица 3.
Кстати, ни одна система высокий показатель защищенности вообще получить не может, похоже, имея максимум 50% плюсов по второму столбцу (добавление их туда не предусмотрено).
Во-вторых, нет умножения на ноль. Обычный ноль, конструктивно схожий с колесом и учинивший сущий переворот в античной математике, сюда еще не докатился.
Представим, что мы находимся на этапе идентификации угроз (т.е. из базового набора мер кое-что удалось «адаптировать», но это уже в прошлом) и ищем сейчас не включенные в банк ФСТЭКа. Угроза – это комбинация из объекта, уязвимости, источника, способа воздействия и последствий. Иностранные спецслужбы (источник) уничтожат (последствие) кабельные сети (объект), имеющие неважнецкую твердость (уязвимость), путем пережевывания (способ) – это угроза. Как ни странно, нет оснований такую угрозу не идентифицировать: хоть мы и понимаем, что такая комбинация исключительно маловероятна (вот раскоммутировать, оборвать или перерезать еще могут, да и то нарушители вида 7-10), но ведь про вероятность же разговор еще не идет. И возьмем еще для нашего примера угрозу с очевидно смехотворным ущербом - потерю пакетов, например. Про ущерб ведь тоже разговора пока нет, так что обязаны взять.
Дальше оценка. Вот тут уже документ формально говорит, что для актуальности ущерб должен быть неприемлемым, а способ реальным, да только предоставляемый механизм учесть это не позволяет. Если у первой угрозы объективные предпосылки для реализации отсутствуют – это низкая вероятность реализации. Вкупе с огромным ущербом (а с каким же еще, если все сети в труху, и надо тянуть заново) первая угроза получится актуальной. И ущерб тоже нельзя оценивать ниже «низкого», так что и вторая наша угроза, реализующаяся ежеминутно, тоже актуальной будет. См. таблицу 8.
Как исправить: добавить к шкалам вероятности и ущерба значение «совсем нет». Либо перенести отсев угроз на почве практической невероятности/безущербности со стадии оценки актуальности УБИjа, где он работает неординарно, на этап идентификации угроз УБИj.
Кстати, документ просит указывать в модели только актуальные угрозы. Как я исхитрился увести в неактуальные все остальные, и как они вообще звучали, никого не интересует, что воодушевляет.
Кстати, если использовать не экспертную оценку, а статистику, то непонятно, по какой области: у меня в системах такого типа буфер год не переполнялся, а у коллег переполнялся, а по миру так вообще. Тоже поле для маневра.
Кстати, при использовании шкалы высокий-средний-низкий забавно выглядит отброс максимальных и минимальных экспертных оценок: это придется только ответы «средний» оставить? А если у меня абсолютно все эксперты дали только два соседних варианта (только низкий и средний или только средний и высокий), то что останется? А если они да-нет отвечали, что тоже разрешается, тогда как?
В-третьих, очеловечивание источников угроз.
Для живых нарушителей все удобно и логично: действительно, по части смертоносных пассов тряпкой потенциал простой уборщицы не идет ни в какое сравнение с хакерами, по части физической кражи сервера нет равных атлетически развитым грузчикам и охранникам, по части засорения кондиционера или попадания сверлом в силовой кабель рулят строительные рабочие, а по части облокотиться во сне на кнопку Delete легитимные пользователи. Потенциал их складывается из двух составляющих (может и хочет / может, но не хочет / не может, но хочет / не может и не хочет), соответствующему расчету посвящено в самом документе страниц 10 и еще в приложении штук 7 – коротенько так.
Эту же методику великодушно предлагается использовать для неантропогенных нарушителей. Живо воображаю, как операторы оценивают мотивацию микросхемы контроллера к перегоранию и знание ей проекта информационной системы. Оснащенность и техническую компетентность дождевой воды. Время, затрачиваемое программным сбоем на доступ к информационной системе.
Как исправить: зафиксировать, что неантропогенные источники идут не по алгоритму с возможностью, где участвует потенциал (с его 17-страничными выкладками), а по алгоритму с вероятностью.
Предваряя вопрос «Почему ты пишешь об этом здесь, а не во ФСТЭК?»: напишу (и всегда писал). Просто чем больше людей это им по-своему перескажут, тем больше шанс, что там поймут, оттого и приглашаю беззастенчиво заимствовать, не стесняя себя соображениями авторских и смежных. Со своей стороны обещаю посмотреть перед отправкой ваши блоги - будет потом обидно, что я у вас что-то содрал, а вы у меня нет.
Одна незадача: проделана слишком большая работа, чтобы ее согласились кромсать. Нет было сначала некую концепцию методики выложить или принципиальную логическую схему. А теперь: «К пуговицам претензии есть?». К пуговицам крайне мало.
Во-первых, это клеймо исходной/проектной/эксплуатационной защищенности.
Чтобы не погружать читателя в изучение проекта, суть в том, что некоторые структурно-функциональные характеристики или условия эксплуатации информационных систем награждают их добавочным коэффициентом, который применяется к оценке всех угроз для этой информационной системы. Но почему всех-то? Вот, например, загнала виртуализация информационную систему из среднезащищенных в низкозащищенные – это сразу плюс одна ступень ко всем оценкам угроз, в т.ч. которые от виртуализации не зависят или даже зависят обратно: был, скажем, риск просмотра информации с дисплеев средним – станет почему-то высоким. Или выделили рабочие места администраторов в отдельный сегмент сети – защищенность из низкой стала средней – оценка угрозы отказа резервной ленты тоже упадет, хотя с чего бы. Это как клеймо «двоечника по жизни», не позволяющее получить пять за правильный ответ столицы Буркина Фасо, или отличника, который даже за неправильный меньше четырех с минусом не получит.
Чтобы исправить, нужно отказаться от «чохового» применения показателя защищенности ко всем угрозам и расписать, какие СФХ и УЭ какие конкретно угрозы поднимают, а какие вдруг наоборот. Если это сложно, тогда вообще снести эту тему в приложения (как это, например, обстоит с рекомендациями по формированию экспертной группы), озаглавив «СФХ и УЭ, которые должны рассматриваться как смягчающее/отягчающее обстоятельство при оценке связанных с ними (!) угроз».
Кстати, требование дотянуть показатель защищенности информационной системы до высокого к моменту ее ввода в эксплуатацию путем нейтрализации актуальных угроз – это какой-то казус, т.к. повторная его оценка будет зависеть опять только от архитектуры, и если ту не меняли, то и оценка не изменится, не взирая ни на какие нейтрализации. Такова таблица 3.
Кстати, ни одна система высокий показатель защищенности вообще получить не может, похоже, имея максимум 50% плюсов по второму столбцу (добавление их туда не предусмотрено).
Во-вторых, нет умножения на ноль. Обычный ноль, конструктивно схожий с колесом и учинивший сущий переворот в античной математике, сюда еще не докатился.
Представим, что мы находимся на этапе идентификации угроз (т.е. из базового набора мер кое-что удалось «адаптировать», но это уже в прошлом) и ищем сейчас не включенные в банк ФСТЭКа. Угроза – это комбинация из объекта, уязвимости, источника, способа воздействия и последствий. Иностранные спецслужбы (источник) уничтожат (последствие) кабельные сети (объект), имеющие неважнецкую твердость (уязвимость), путем пережевывания (способ) – это угроза. Как ни странно, нет оснований такую угрозу не идентифицировать: хоть мы и понимаем, что такая комбинация исключительно маловероятна (вот раскоммутировать, оборвать или перерезать еще могут, да и то нарушители вида 7-10), но ведь про вероятность же разговор еще не идет. И возьмем еще для нашего примера угрозу с очевидно смехотворным ущербом - потерю пакетов, например. Про ущерб ведь тоже разговора пока нет, так что обязаны взять.
Дальше оценка. Вот тут уже документ формально говорит, что для актуальности ущерб должен быть неприемлемым, а способ реальным, да только предоставляемый механизм учесть это не позволяет. Если у первой угрозы объективные предпосылки для реализации отсутствуют – это низкая вероятность реализации. Вкупе с огромным ущербом (а с каким же еще, если все сети в труху, и надо тянуть заново) первая угроза получится актуальной. И ущерб тоже нельзя оценивать ниже «низкого», так что и вторая наша угроза, реализующаяся ежеминутно, тоже актуальной будет. См. таблицу 8.
Как исправить: добавить к шкалам вероятности и ущерба значение «совсем нет». Либо перенести отсев угроз на почве практической невероятности/безущербности со стадии оценки актуальности УБИjа, где он работает неординарно, на этап идентификации угроз УБИj.
Кстати, документ просит указывать в модели только актуальные угрозы. Как я исхитрился увести в неактуальные все остальные, и как они вообще звучали, никого не интересует, что воодушевляет.
Кстати, если использовать не экспертную оценку, а статистику, то непонятно, по какой области: у меня в системах такого типа буфер год не переполнялся, а у коллег переполнялся, а по миру так вообще. Тоже поле для маневра.
Кстати, при использовании шкалы высокий-средний-низкий забавно выглядит отброс максимальных и минимальных экспертных оценок: это придется только ответы «средний» оставить? А если у меня абсолютно все эксперты дали только два соседних варианта (только низкий и средний или только средний и высокий), то что останется? А если они да-нет отвечали, что тоже разрешается, тогда как?
В-третьих, очеловечивание источников угроз.
Для живых нарушителей все удобно и логично: действительно, по части смертоносных пассов тряпкой потенциал простой уборщицы не идет ни в какое сравнение с хакерами, по части физической кражи сервера нет равных атлетически развитым грузчикам и охранникам, по части засорения кондиционера или попадания сверлом в силовой кабель рулят строительные рабочие, а по части облокотиться во сне на кнопку Delete легитимные пользователи. Потенциал их складывается из двух составляющих (может и хочет / может, но не хочет / не может, но хочет / не может и не хочет), соответствующему расчету посвящено в самом документе страниц 10 и еще в приложении штук 7 – коротенько так.
Эту же методику великодушно предлагается использовать для неантропогенных нарушителей. Живо воображаю, как операторы оценивают мотивацию микросхемы контроллера к перегоранию и знание ей проекта информационной системы. Оснащенность и техническую компетентность дождевой воды. Время, затрачиваемое программным сбоем на доступ к информационной системе.
Как исправить: зафиксировать, что неантропогенные источники идут не по алгоритму с возможностью, где участвует потенциал (с его 17-страничными выкладками), а по алгоритму с вероятностью.
Предваряя вопрос «Почему ты пишешь об этом здесь, а не во ФСТЭК?»: напишу (и всегда писал). Просто чем больше людей это им по-своему перескажут, тем больше шанс, что там поймут, оттого и приглашаю беззастенчиво заимствовать, не стесняя себя соображениями авторских и смежных. Со своей стороны обещаю посмотреть перед отправкой ваши блоги - будет потом обидно, что я у вас что-то содрал, а вы у меня нет.
Одна незадача: проделана слишком большая работа, чтобы ее согласились кромсать. Нет было сначала некую концепцию методики выложить или принципиальную логическую схему. А теперь: «К пуговицам претензии есть?». К пуговицам крайне мало.
