Акты классификации ГИСа - Форум по вопросам информационной безопасности

Sekira, конечно, можно :)

Приказ 17, п. 17.2, последние два метода, обязательные при проведении аттестации ГИС: анализ уязвимостей и испытания системы защиты информации путем осуществления попыток НСД. Ну а "не доросли" - потому что иногда приходится по просьбам уважаемых товарищей давать экспертные заключения типа "САЗ, применявшееся в ходе испытаний, не предназначено для выявления уязвимостей в программном обеспечении, используемом на объекте информатизации" :)

"А за адекватность выбора УБИ и мер их нейтрализации пусть отвечает тот, кто писал приведенные выше документы"
Тут та и собака порылась. Где юридически закрепленный инструментарий проверки адекватность выбора УБИ и мер их нейтрализации. Объективный а не имхо? Только если за уши притянуть мет_ рекомендации к 17 приказу.

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

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

to sekira (77810) требования того чтоб онтроль за устройствами был в режиме: всегда подключен, а не подключение разрешено, ибо устройство включается на пару часов, и я не понимаю покой это все так настроенно.

to sekira (77816)

"Тут та и собака порылась. Где юридически закрепленный инструментарий проверки адекватность выбора УБИ и мер их нейтрализации. Объективный а не имхо? Только если за уши притянуть мет_ рекомендации к 17 приказу"

Протокол НСД выдвается же не только под ГИС, есть программы сертифицированные ФСТЭКом, для проверки настройки СЗИ, по каждому пункту надо пройтись и проверить как оно реализовано. Этими же программами может пользоваться регулятор при проверках.
Как пример: если криво настроить затирание, например на DL-8 С, и по запаре установить затирание только в конфиденциальных сеансах, то терьер будет находить все несекретные файлы которые были удалены.
В целом эти программы есть как для отдельных АРМ или ЛВС без подключения к интернету, так и с подключением.

to turbo_b
Использование программ "контроля защищенности", сертифицированных ФСТЭК России, зачастую, не равно контролю защищенности ИС от актуальных (и потенциальных) УБИ. Поэтому их (программ) использование - это не больше чем формальный признак подтверждения соответствия ИС каким-то требованиям в части НСД. К тому же, оные программы настолько устарели (морально и фактически), что в большинстве ИС их использование либо невозможно, либо не подтверждает ничего...
Как уже писал - все базируется на честности лицензиата. Кто-то проверит отсутствие противоречий (на бумаге, ага) между ЧМУ-ТехПроектом-Требованиями-их_реализацией + для проформы пройдется программами "контроля защищенности" - и выдаст положительный Аттестат. А кто-то возмутится попыткой "закрыть" УБИ уровня web-сервера средствами того же DallasLock + протестит ИС на уязвимости и выявит хренову гору нештатного или устаревшего софта, прошивок ТС, bad-правил фильтрации и проч. - и выдаст отрицательное Заключение...
КОНФИ - это не ГТ. В ней надо искать компромисс между "Функциональностью - Экономичностью - Безопасностью". В ней нет четких, выработанных годами правил реализации тех или иных требований. В ней вообще бОльшую часть вопросов решается желанием Заказчика-обладателя КОНФИ (операторы в ту же степь, ага). И в ней нужно куда как больше знаний (умений) у конечного безопасника и лицензиата. Иначе разработка, внедрение, эксплуатация и аттестация системы защиты превратится в фарс...

to oko

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

Конфи, судя по тому что я вижу последние 2 недели - это какая-то жопа, извините за выражение. Может где-то у нас с ГИСами и ИСПДн нормально дела обстоят, но то что вижу я, это - фарс по отмыванию средств.

to turbo_b
Не только в КОНФИ. И не только фарс...
Если бы граждане на местах сами занимались безопасностью своих систем, а не нанимали лицензиатов в первую голову с целью "получить бумажку" - проблем было бы меньше. Документы той же ФСТЭК предполагают четкое разделение схемы на:
- разработку и внедрение системы защиты - либо эксплуатант самостоятельно, либо привлечение исполнителя №1;
- аттестацию системы защиты - исполнитель №2;
- поддержание соответствия - либо эксплуатант самостоятельно, либо привлечение исполнителя (можно даже №3).
В такой схеме все в порядке и на местах:
- эксплуатант заинтересован в защищенности своей системы и де юре, и де факто;
- исполнитель-разработчик заинтересован в создании и внедрении качественной системы защиты (иначе после неудачной аттестации ему влетят санкции, ага, от эксплуатанта);
- исполнитель-аттестатор заинтересован в беспристрастном анализе защищенности систем де юре и де факто (поскольку он не обещал эксплуатанту красивой бумажки, да и сам не занимался разработкой этой системы защиты).
Конечно, и тут деньги/договоренности решают все. Но уже в меньшем проценте случаев...
А пока все происходит "как обычно"... На одной аттестации не проживешь - приходится оказывать услуги и по проектированию, и по внедрению, и проч. Эксплуатанта сложности мало волнуют - у него и штата специалистов, способных оценить качество работ, зачастую нет - ему "бумажка" нужна (причем в срок контракта, который, как правило, составляли совершенно ***** люди). И, поскольку конечная цель и лицензиата, и эксплуатанта, выходит, сводится к выдаче "положительной бумажки", постольку отмеченный вами фарс имеет место быть почти повсеместно...

to oko

Я аж по прошлой работе соскучилась от вашего поста.

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

У меня просто еще все здесь по ощущениям хуже, чем ситуация "кто проектировал, тот и настраивает и аттестует".

СЗИ как минимум настраивали люди, которые в прошлом были сис.админами и не понимают что и как они реализовывали, а главное зачем (относительно класса защищенности). Потому что проект они говорят, что не читали.
Проект писался у N1, ОРД писались у N2, настраивали N3, аттестат вывадали N4, поддерживают систему удалено N5, на месте админят чуваки из N6. Но внятно даже что за система я смогла понять только через неделю, как смогла выпросить хоть какую-то документацию.

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

Спасибо за иллюстрацию тезиса про "не доросли".

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

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

Но у аттестаторов такой компетенции, как правило, нет.

to malotavr
Извиняюсь, что встреваю, но все-таки вопрос не в компетенции. Вернее, в компетенции не только лицензиатов-аттестаторов. Повторяться не буду, но, в целом, ситуация следующая:
- в рамках "аттестации" (подчеркиваю) есть только комплекс действий, утвержденных той же ФСТЭК в ГОСТ-0043, которые явно не тянут на "тестирование на проникновение";
- для анализа уязвимостей вообще нет утвержденных методик;
- сертифицированных или хотя бы негласно принятых регуляторами инструментов для пен-теста или анализа уязвимостей тоже нет (кроме расплывчатой фразы про БДУ, для которой до сих пор не придумали доступных анализаторов);
- само понятие "тестирование на проникновение" (как вы и указали) тщательно обходится в НМД и заменяется сродственными понятиями, которые юридически означают совсем другое;
- а лицензиат на то и лицензиат, чтобы в первую очередь делать все в рамках указанных регулятором направлений (т.е. вначале юзать то, что официально разрешено, а "белые пятна" оставлять на случай наличия интереса и времени);
- а регулятор на то и регулятор, чтобы требовать от лицензиата отчетности в первую очередь по утвержденным бумагам (т.е. вначале принцип "написано? выполняй. не написано? ты все-равно не прав");
- и у лицензиата зачастую нет ни времени, ни сил, ни желания, ни (удивительно, ага) финансовой выгоды согласовывать уникальные ПиМ (с покрытием "белых мест") и потом доказывать всем и каждому, что NMAP+Wireshark+etc лучше Сканера-ВС, "витая пара" между чужими этажами опаснее ПЭМИН, выявленный XSS критичнее отсутствия затирания swap, а CVE актуальнее БДУ (утрирую, конечно)...

ЗЫ Не так опасна неожиданная эскалация до root, как бездумно построенный мониторинг и единство средств ИАФ. И не все уязвимости говорят об актуальности УБИ (тут солидарен с тов. sekira). Вектор атаки - это лишь направление, а УБИ складывается из "уязвимость+нарушитель+канал атаки+недостатки СЗИ". А еще стоит добавить такую вещь, как дезинформация (модное нынче honepot)... Банальные примеры:
- использование STM8 с AES-128 (уязвимость, ага) при общей сети электропитания (канал, недостаток) != УБИ, поскольку нарушителю надо быть резидентом Лэнгли (например), и для бухгалтерии "Рога-и-Копыта" г. Мухосранска это не актуально;
- heartbleed в ssh (уязвимость) открытом вовне (канал), не прикрытом acl хотя бы по ip (недостаток) и выявленном кулл-хацкером (нарушитель) != УБИ, если сервер автономный и используется для отвлечения внимания.

> в рамках "аттестации" (подчеркиваю) есть только комплекс действий, утвержденных той же ФСТЭК в ГОСТ-0043, которые явно не тянут на "тестирование на проникновение"

- С каких пор ГОСТ 2003 года стал оправданием для невыполнения требований нормативного акта 2013 года?

- Т.е. "не доросли" :) Лютиков устал повторять, что лицензиаты, тупо следующие методичкам, нафиг никому не сдались.

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

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

- Неправда. На каждом совещании по этой теме лицензиаты получают люлей от ФСТЭК именно за блеяние "ну мы же, убогие, сами-то не умеем".

- Ну т.е. "мы не умеем и не хотим делать ту работу, за выполнение которой государство заставляет нам платить". Я это называю мягко "не доросли", но мы с вами понимаем, что получение денег за бессмысленные телодвижения обычно характеризуют более грубыми выражениями :)