Оценка защищенности (эффективности мероприятий) - Форум по вопросам информационной безопасности

> Нет, инструм.оценка (она же в ряде случаев "инструм.контроль") - это для технических каналов утечки информации, о чем и говорил тов. Чак.

Я знаю, о чем говорил Чак.

Состав и содержание работ по анализу уязвимостей тоже предусматривает проведение инструментальных проверок с помощью сканеров. Мы предлагали расширить нынешнее понятие "оценка защищенности", включив в него проверку системы защиты от НСД. Но авторы проектов ГОСТ и коллеги из ФСТЭК решили не смешивать понятия из разных областей, что, впрочем, тоже разумно.

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

to malotavr
Мой последний пост тов. Любознателю предназначался :)
А вообще, лично мне крайне режет глаза формулировка "анализ уязвимостей". Лучше уж "комплексный контроль защищенности". Ведь наличие уязвимости - это только один из компонентов совершения успешной атаки. В рамках того же пен-теста не только конечные уязвимости выявляются и используются. Опять-таки "неверную настройку применяемых СЗИ" нельзя в полной мере "уязвимостью" назвать. Иначе последует сумбур понятий в неокрепшем разуме конечных ЗИшников. К примеру, берем базу CVE, анализируем ее и не паримся (ибо у нас все обновлено и опасность только 0-day представляют якобы), не смотря на то, что тот же .htaccess у нас стоит с дефолтным конфигом :)

ГОСТ Р 50922-2006
п. 2.8 - весть раздел все определения...

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

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

Неправильно понимаете. Анекдот про раввина "Слушай, окрестить, а?" знаете?

1. ГОСТ 50922-2006 (фиговый листок аж на целых 12 страничках) морально устарел еще в момент принятия. Он был сильно переработан еще в 2015 году (проект пока не утвержден), но даже после этого кардинально отстает от жизни - например, в нем нет многих терминов и определений, введенных в стандартах и методических документах, вступивших в силу в 2014-2016 годах.

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

> А вообще, лично мне крайне режет глаза формулировка "анализ уязвимостей". Лучше уж "комплексный контроль защищенности".

Смотря что вы называете "контролем защищенности" :) Если анализ уязвимостей - то да :)

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

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

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

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

То есть анализ уязвимостей - комплексное (в смысле - сложное, состоящее из нескольких компонентов) исследование, которое охватывает не весь спектр мер защиты :) Дополните его аудитом - тогда да, можно говорить о полном исследовании (с оговоркой насчет достаточности квалфикации как пентестеров так и аудиторов)

> Опять-таки "неверную настройку применяемых СЗИ" нельзя в полной мере "уязвимостью" назвать. Иначе последует сумбур понятий в неокрепшем разуме конечных ЗИшников.

А вот это - проблема недостаточной квалификации конкретных ЗИшников. Я язык стер, с 2008 г .объясняя таким вот ЗИшникам, что такое "уязвимость". Звучит это примерно так:

- Чувак, если твой цискарь не настроил на портах коммутаторов, к которым подключены АРМ пользователей, фильтрацию протокола STP - это уязвимость. Потому что если хотя бы один коммутатор готов взаимодействовать с АРМ пользователя по протоколу STP, этому пользователю не составит труда победить в процедуре "выбора самого главного коммутатора года" в каскаде и объяснить всем коммутатором каскада, что теперь этот АРМ будет рассказывать всем коммутаторам, как именно коммутировать соединения в ЛВС. И мне трижды наплевать, что такой уязвимости нет в базе CVE - есть cheat sheet "Мальчики, запомните 237 параметров цисковского конфига, которые никогда нельзя настраивать вот так", и если ваш цискарь его не читал - это его личные проблемы

Утрирую, но квалифицированные безопасники, наряду с буковками CVE, обязаны также знать буковки CWE и CCE :)

to malotavr
1. Комплесное - в моем понимании (как учили когда-то давно) - это ряд мероприятий, охватывающий все вопросы области / предмета. Т.е. и пен-тест, и аудит, и модернизация, и обучение и т.д. В части "комплексного контроля защищенности" - это проверка "по всем фронтам", а не только попытка несанкционированного проникновения...
2. Уязвимости надо различать по месту их происхождения и характеру их эксплуатации. Да, в целом, и некорректные параметры СЗИ (системы, не средства) можно назвать "уязвимостью". Проблема в том, что в нашей стране далеко не все понимают однозначность терминов в концепции тех же Cisco. Да и регулятор (в частности, ФСТЭК) под уязвимостью понимает нечто первично имеющееся и, возможно, некоторое время назад открытое в самих используемых компонентах ИС и СЗИ. Ошибки кода, ошибки сборки (ТС), намеренно внедренные "косяки", ошибки раздачи обновлений, ошибки подготовки баз сигнатур и т.д. А вот на базе уязвимостей уже идут угрозы, которые должны быть ликвидированы внедрением СЗИ. Следовательно, косяки настройки СЗИ - это, не уязвимости. Это, в сущности, отсутствие реализации СЗИ для определенных угроз. Именно поэтому у них "уязвимости" отдельно, а "угрозы" отдельно (в bdu, ага). И тут главный нюанс - безопасники, с молоком матери впитавшие понятия CVE, CWE и т.д. не до конца разбираются в терминологии "уязвимостей" и "угроз" по логике наших регуляторов. И наоборот. А подмена и некорректное использование понятий иногда оказывается критичным. За примером далеко ходить не надо - тот же пен-тест как защитное мероприятие до сих пор "узаконен" крайне слабо. Хотя бы в причину явного несоответствия стандартов и понятий, априорных для пен-тестеров, нашей законодательной базе...
3. И, пожалуй, главное. Отсутствие известных или потенциальных уязвимостей (на взгляд составителей баз уязвимостей или на взгляд тестировщиков - не суть важно) в использумых компонентах ИС и технологическом процессе - это как и результат отрицательного пен-теста. Т.е. ни к чему не ведущие понятия. Уязвимости может и не быть, но угрозы реализовать возможно. Краткий пример: брутфорс паролей. Кто рискнет назвать уязвимостью использование сетевого пасса оптимальной длины (символов, эдак, 16) в ситуации, когда у нарушителя имеется мощнейшая распределенная сеть для брута, пусть даже и с перерывами на краткосрочный бан? При достаточной мощности и удаче нарушитель своего добьется. И администратор виноват не будет - все сделал правильно, но не рассчитывал столкнуться с таким "монстром". Дальнейшие дискуссии про "виноват - надо было через СОВ регистрировать активность и принимать меры" - это бессмысленное усложнение примера. Как говорится: коса на камень все-таки найдет (аналог классического про "винт" и "закоулок" или не менее классического закона Мёрфи)... Также отсутствие СОВ, невнимательность администратора или отказ в рассмотрении подобных таргетированных атак нельзя назвать "уязвимостью", применительно к ИС. Это скорее некорректность или попросту недоработка в реализованной комплексной системе защиты. Другой пласт проблем, совершенно не касающийся конечной защищенности конечной ИС...

>И, пожалуй, главное. Отсутствие известных или потенциальных уязвимостей (на взгляд составителей баз уязвимостей или на взгляд тестировщиков - не суть важно) в использумых компонентах ИС и технологическом процессе - это как и результат отрицательного пен-теста. Т.е. ни к чему не ведущие понятия. Уязвимости может и не быть, но угрозы реализовать возможно.

Меня постоянно напрягает в типовых методиках моделей угроз представление всего либо черным либо белым.
Либо угроза актуальна, либо нет. Эдакие математические абстракции.
"угроза, проникновение по сетевому каналу" - "мера защиты, межсетевой экран" - "актуальность? все неактуальн0."
Все довольны - расходимся.
А как-же зеродеи? Они и в МЭ бывают. Принять угрозу актуальной? Тогда как защищаться?

Наверное лучше было-бы вообще не применять понятия "актуально-не актуально", а использовать "угроза" -" мера снижения реализации угрозы".

> 1. Комплесное - в моем понимании (как учили когда-то давно) - это ряд мероприятий, охватывающий все вопросы области / предмета.

А поскольку пентест охватывает не все области предмета, не могу назвать его комплексной оценкой, и термин "анализ уязвимостей", как обобщающее понятие, меня вполне устраивает :)

> 2. Уязвимости надо различать по месту их происхождения и характеру их эксплуатации. Да, в целом, и некорректные параметры СЗИ (системы, не средства) можно назвать "уязвимостью".

Не "можно", а "нужно". По определению :)

> косяки настройки СЗИ - это, не уязвимости.

Заметим, в своем примере я ни разу не упомянул косяки настройки СЗИ. Я говорил о коммутаторе. Могу привести пример еще проще - использование в ЛВС неуправляемого коммутатора - это уязвимость. Если у вас локалка на неуправляемых коммутаторах, вы в принципе не можете помешать пользователю сети манипулировать трафиком в ней - вам просто нечем бороться с ARP-спуфингом. Неуправляемый коммутатор - уязвимость by design, нарушение конфиденциальности передаваемх данных - угроза, ARP-спуфинг - способ ее реализации, который стал возможен благодаря этой уязвимости. Никакой путаницы.

> За примером далеко ходить не надо - тот же пен-тест как защитное мероприятие до сих пор "узаконен" крайне слабо. Хотя бы в причину явного несоответствия стандартов и понятий, априорных для пен-тестеров, нашей законодательной базе.

И не только в нашей :) Почитайте ISO 20004 - худшей бредятины в ISOшных стандартах я не встречал.

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

> Уязвимости может и не быть, но угрозы реализовать возможно. Краткий пример: брутфорс паролей. Кто рискнет назвать уязвимостью использование сетевого пасса оптимальной длины (символов, эдак, 16) в ситуации, когда у нарушителя имеется мощнейшая распределенная сеть для брута,

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

Использование 16-символьных паролей, разумеется, не является уязвимостью, потому совокупной вычислительной мощности существующих сегодня "мощнейших распределенных сетей для брута" для честного подбора недостаточно. С линейным ростом длины пароля объем времени для перебора вариантов и памяти для их хранения растет экспоненциально.

Так что в реальности, когда пользователь говорит, что украли его пароль, оказывается , что:

1. В системе используется кривая хеш-функция (как в старых версиях SAP, когда пароль приводился к одному регистру и обрезался по длине перед хешированием, или в виндовом LanManager, когда пароль разбивался разбивается на короткие фрагменты);
2. Пароли в системе хранятся в открытом виде и из тупо слили после взлома;
3. И хеш функция хорошая, и пароль хранится зашифрованным, но блин, объясните этим дебилам, что предлагать пользователю в качестве контрольного вопроса для восстановления пароля указать девичью фамилию матери - это надо быть больным на всю голову. Мощность множества возможных словарных фамилий рядом не стоит с мощностью множества нормальных паролей.
4. И вообще хакеры даже не пытались подбирать пароль - им оказалось вполне достаточно перехватить/подобрать неслучайный идентификатор сессии.

Т.е. каждый раз речь идет о хорошо известной типовой уязвимости в реализации системы.

> Также отсутствие СОВ, невнимательность администратора или отказ в рассмотрении подобных таргетированных атак нельзя назвать "уязвимостью", применительно к ИС.

А кто его так называет? Есть четкие определения. Есть weakneess - недостаток в обеспечении безопасности. Если этот недостаток можно использовать для реализации угрозы - это vulnerability, уязвимость. Кривая реализация проверки пароля, позволяющая провести брутфорс - это уязвимость. То, что разработчик системы не предусмотрел меры защиты, которые позволяют заметить брутфорс, а персонал не умеет на такие атаки реагировать - это weakness. Бороться надо и с тем. и с другим, но уязвимости - приоритетнее.

> Как говорится: коса на камень все-таки найдет (аналог классического про "винт" и "закоулок" или не менее классического закона Мёрфи)...

Открою вам страшную тайну (все равно первая редакция документа уже рассылалась рецензентам). В нормативке по ГосСОПКА прямо говорится, что центр ГосСОПКА будет изначально неспособен реагировать на большинство атак, и это нормально. Ненормально - если из неудачно отработанной атаки не будут сделаны выводы, не будут доработаны меры защиты, и центр ГосСОПКА пр