Автор: turbo_b | 77684

11.09.2017 15:19

Здравствуйте, тут ушла из одного органа по аттестации в ком.фирму которая решила осуществлять поддержку в области ИБ, до этого особо в конфи старалась не лезть, так что у меня небольшой ступор. Имеется ГИС к которой орган по аттестации N готовил ОРД, ему присвоили 3 класс защищенности по 17 приказу, и 3 уровень защищенности по 21-ому. В комплекте ОРД не могу найти классификацию АС и ни одного упоминания, меня сильно берут сомнения по поводу отсутствия упоминания класса защищенности в комплекте ОРД (самих документов по аттестации у меня естественно нет). Надо же классифицировать АС по РД, а то я начинаю в себе сомневаться. И класс же 1Д? Извиняюсь, что задаю возможно глупые вопросы, но с гт было как-то проще

Автор: Влад | 77686	11.09.2017 15:45
Зачем нужно классифицировать ГИС по РД АС, если ГИС уже сертифицирована по 17 и по 21 Приказам ФСТЭК?

Автор: turbo_b | 77687

11.09.2017 16:13

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

Автор: oko | 77695

11.09.2017 23:12

to Влад Аттестована же, а не сертифицирована! :) to turbo_b АС по РД ГТК от НСД (классы 3Б, 2Б, 1Д, 1Г по КОНФИ) - это уже (чего греха таить, ага) рудимент, обычно применяемый комм.оргами для аттестации своих систем по требованиям безопасности, когда в них обрабатывается та же "Коммерческая тайна". Или организациями, желающими получить лицензию по ТЗКИ. Во всех остальных случаях уже вовсю применяются требования и классификаторы Приказа 21/ПП 1119 (для ИСПДн) и Приказа 17 (для ГИС, ну и, в сущности, для любых КОНФИ-систем). Хотя формально РД никуда не ушли... Класс 1Д вообще на практике ни разу не встречал. Тоже формально не запрещено, но должно быть железное обоснование, поскольку от 1Г отличается как небо и земля (по предъявляемым требованиям к системе защиты)... Судя по всему, у вас используется СЗИ НСД SecretNet. Только что такое виртуальные диски? Явного регламента нет - все определяется вашей же Моделью угроз и Техническим проектом системы защиты. А дальше здравый смысл: в вашем случае, если устройство всегда подключено к системе и его отключение - явный признак НСД, то имеет смысл оставить "постоянно подключено"...

Автор: turbo_b | 77698

12.09.2017 09:53

to oko Я участвовала в аттестации ГИС один раз, и то когда только начинала работать, по этому мат.часть знаю плохо (хотя это не оправдание). И 1Д я на практике тоже не встречала, по этому вообще представить не могу что это и зачем. Все верно. Как мне объяснили, это некая среда виртуализации связанная с бэкапом, пока у меня здесь вопросов больше, чем ответов, а у них ко мне слишком много вопросов с СЗИ (как они получили лицензию на работы я понятия не имею). Ни в модели угроз ни в тех.проекте, ни в тех.процессе я ничего конкретного не нашла. В моем случае устройство включается только для бэкапа. Я предлагаю разрешить подключение, без лишних сложностей, мужики сидят, боятся, а я не имею багажа опыта в 10 лет, чтоб с легкостью объяснить им что так можно.

Автор: malotavr | 77733

12.09.2017 14:26

Порядок аттестации ГИС по требованиям 17 приказа прописан в самом 17 приказе. В рамках 17 приказа вы сами решаете как именно регламентировать контроль устройств, сами определеяете, имеете ли вы право поменять локальную политику виртуальных дисков и т.п. . Т.е.: 1. Приказ 17 определяет базовые меры защиты 2. Методический документ детализирует базовые меры защиты и дополняет их обязательными мерами усиления 3. Вы самостоятельно решаете, как именно реализовать эти меры защиты и чем их дополнить, после чего описываете свои решения в проектной документации 4. При аттестации проверяется, что ваши решения не противоречат п. 1 и 2. Теоретически при аттестации должно еще проверяться, что ваши меры защиты действительно защищают от угроз, но до этого аттестаторы пока не доросли :)

Автор: turbo_b | 77774

12.09.2017 14:56

to malotavr Теоретически есть протокол НСД, а вот на сколько там правда написана, лежит на совести каждого аттестатора отдельно :) Тут сзи настраивали мои новые коллеги, но на основании чего они настроили, они не понимают. От их настроек в система слишком часто реагирует на то, что обуславливается как инцидент. Внятно мне доказать что эти настройки не излишние мне естественно не могут, от чего у меня происходит разрыв шаблона и сомнения в своей адекватности и компетентности. С органом по аттестации связи нет, так как заказчик не эта контора. как итог я все таки поменяю настройки, так как внятного требования я не нашла.

Автор: sekira | 77810	12.09.2017 19:56
"Теоретически при аттестации должно еще проверяться, что ваши меры защиты действительно защищают от угроз" а можно узнать где это написано, можно даже не в НМД... ? "так как внятного требования я не нашла" а требования чего вы искали и не нашли?

Автор: oko | 77811

12.09.2017 20:57

*в сторону* не ликбеза ради, но структуризации для... <а можно узнать где это написано, можно даже не в НМД... ?> - Нигде не написано четко. Однако в том же Приказе №17: IF: "Защита информации ... обеспечивается ... путем принятия ... мер ..., направленных на блокирование (нейтрализацию) угроз безопасности информации в информационной системе..." & "Требования ... определяются в зависимости от класса защищенности информационной системы и угроз безопасности информации..." & "В информационной системе ... должны быть реализованы меры ..., выбранные в соответствии с пунктом 21 настоящих Требований и обеспечивающие блокирование (нейтрализацию) всех угроз безопасности информации" & "Выбор мер ... включает:" + "определение базового набора мер (приложение N 2 к настоящим Требованиям)" + "адаптацию базового набора мер..." "уточнение адаптированного базового набора мер ..., в результате чего определяются меры ..., обеспечивающие блокирование (нейтрализацию) всех угроз безопасности информации..." & "Аттестация информационной системы ... включает проведение комплекса ... мероприятий, в результате которых подтверждается соответствие системы защиты информации ... настоящим Требованиям" THEN: Аттестация ИС = проверка соответствия требованиям уточненного адаптированного базового набора мер, т.е. мер, представленных в приложении №2 Требований + мер, нейтрализующих актуальные угрозы. Кстати, во время аттестация должны применяться "испытания ... путем осуществления попыток несанкционированного доступа ... в обход ее системы защиты информации". Де юре, да, согласен, картина следующая: поглядели Требования? поглядели bdu.fstec.ru? погладели Модель угроз? поглядели ТехПроект? поглядели реализацию системы защиты "на местах"? не нашли противоречий/ошибок/отсутствия реализации? не смогли "пробиться" через систему защиты путем каких-то (незнамо каких) тестовых атак? Выдаем Аттестат соответствия. А за адекватность выбора УБИ и мер их нейтрализации пусть отвечает тот, кто писал приведенные выше документы. Все остальное - на усмотрение заказчика/разработчика/лицензиата/регулятора...

Автор: Dfg | 77813	12.09.2017 22:23
Коммерческая тайна и 17 приказ... А зачем? Это внутреннее дело фирмы как свою инфу защищать.

Автор: malotavr | 77814

12.09.2017 23:16

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

Автор: sekira | 77816

12.09.2017 23:47

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

Автор: turbo_b | 77821

13.09.2017 09:50

to sekira (77810) требования того чтоб онтроль за устройствами был в режиме: всегда подключен, а не подключение разрешено, ибо устройство включается на пару часов, и я не понимаю покой это все так настроенно. to sekira (77816) "Тут та и собака порылась. Где юридически закрепленный инструментарий проверки адекватность выбора УБИ и мер их нейтрализации. Объективный а не имхо? Только если за уши притянуть мет_ рекомендации к 17 приказу" Протокол НСД выдвается же не только под ГИС, есть программы сертифицированные ФСТЭКом, для проверки настройки СЗИ, по каждому пункту надо пройтись и проверить как оно реализовано. Этими же программами может пользоваться регулятор при проверках. Как пример: если криво настроить затирание, например на DL-8 С, и по запаре установить затирание только в конфиденциальных сеансах, то терьер будет находить все несекретные файлы которые были удалены. В целом эти программы есть как для отдельных АРМ или ЛВС без подключения к интернету, так и с подключением.

Автор: oko | 77823

13.09.2017 12:24

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

Автор: turbo_b | 77824	13.09.2017 13:01
to oko Ну результаты протоколов НСД лежат на совести лицензиата, это да. Но часто лицензиат тоже лавирует между правдой, адекватностью и желанием заработать денег и не потерять клиента. Конфи, судя по тому что я вижу последние 2 недели - это какая-то жопа, извините за выражение. Может где-то у нас с ГИСами и ИСПДн нормально дела обстоят, но то что вижу я, это - фарс по отмыванию средств.

Автор: oko | 77829

13.09.2017 16:10

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

Автор: turbo_b | 77832

13.09.2017 16:31

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

Автор: malotavr | 77839

13.09.2017 22:38

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

Автор: oko | 77840

14.09.2017 01:05

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

Автор: malotavr | 77862

14.09.2017 12:34

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

Автор: oko | 77867

14.09.2017 14:11

to malotavr < С каких пор ГОСТ 2003 года> - это какой ГОСТ, позвольте поинтересоваться? 0043 (там 2 ГОСТ, кстати) определяют порядок проведения аттестации ОИ и разработки ПиМ. И они куда как более свежие... <Лютиков устал повторять> - Лютиков пусть повторит это своим же подчиненным из региональных управлений. Поскольку, лично, устал отвечать на их дурацкие вопросы, связанные с тем, что в НМД написано одно, а зачем вы сделали больше и иначе? И почему обходились "левым софтом", когда есть прекрасный "Ревизор-1XP" (например)... <Сертификации инструментов для тестирования на проникновение никогда не было, нет и не будет> - и получаем полное противоречие в ГТ и ГИС, где каждый инструмент контроля защищенности также должен пройти сертификацию хотя бы по НДВ. В противном случае, если не считать такие инструменты частью общей системы защиты информации, - никто их никогда не будет применять. Юридический коллапс. А главное, что процесс дальнейшей оценки адекватности используемых мер тестирования будет затягиваться и затягиваться, что породит еще большее число халявщиков среди лицензиатов. Утвержденный и постоянно пополняемый перечень инструментов должен быть и должен вестись именно регулятором, а не применяться лицензиатами на свой страх и риск по принципу "что нашлось"... <если лицензиат просит порекомендовать такие инструментальные средства (тем более сертифицировать их), значит он профнепригоден.> - отлично! Даешь километровые логи john по бруту пассов nix-серверов в Протоколы НСД дабы подчеркнуть профпригодность. Вопрос не в том, ЧТО применять, а КАКОЙ тип разрешен к применению и КАК оформлять его итоги... <чтобы избежать коллизий, термин "... заменяется другими формулировками, сохраняющими этот самый исходный смысл> - это они наученные горьким опытом "НДВ" в ИСПДн и в РД? Браво, оценил. Только "испытания путем попыток НСД" - слишком расплывчатая формулировка, имеющая не менее бородатые корни по сравнению с частным "тестированием на проникновение" в области ПО... <лицензиаты получают люлей от ФСТЭК именно за блеяние> - это вы к чему? Про "белые пятна"? Сдается мне, вы давно отошли от общения с конечными проверяющими "на местах". Особенно представителями "другого регулятора", которых больше волнует бумажное оформление и методы защиты бородатых годов согласно небезызвестной Инструкции. Либо вам повезло общаться с революционерами от гос-позиции по ИБ/ЗИ, так сказать "на передовой", оценивающих семантический функционал, а не формальные признаки работы лицензиата. Проблема в том, что это далеко не повсеместные реалии... <мы не умеем и не хотим делать ту работу, за выполнение которой государство заставляет нам платить> - без обид, но вы мне сейчас напомнили тов. Щеглова с его радикальной позицией по отношению к своим конкурентам... Вообще, стоит ориентировать эти слова в первую голову на наших разработчиков норм и правил, которые НМД либо затягивают, либо оформляют через ж** - яркий пример с текущей ситуацией по ГТ или с отсутствием утвержденной Методики моделирования УБИ по ГИС...

Автор: sekira | 77868	14.09.2017 14:15
"Лютиков устал повторять, что лицензиаты, тупо следующие методичкам, нафиг никому не сдались" Пусть закрепит это не на словах. 10 лет уже тема экспертов муссируется и че? "яркий пример с текущей ситуацией по ГТ или с отсутствием утвержденной Методики моделирования УБИ по ГИС..." Аххаха 100500+++

Автор: malotavr | 77871	14.09.2017 20:59
> сейчас напомнили тов. Щеглова Чур меня! Я исправлюсь, честное слово :)

Просмотров темы: 5778

Copyright © 2004-2019, ООО "ГРОТЕК"