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

Добрый день, уважаемые коллеги.

Требуется определить исходные требования к системе защиты информации в ИС.
ИС не является ни ГИС/МИС, ни ИСПДн, ни КСИИ, не обрабатывает ГТ. Из конфиденциального - только пароли пользователей.

Вижу 2 варианта - определить по:
1) РД. Автоматизированные системы. Защита от НСД к информации. Классификация автоматизированных систем и требования по защите информации"
(утв. решением Гостехкомиссии России от 30.03.1992).

2) Методический документ ФСТЭК России "Меры защиты информации в государственных информационных системах" от 11.02.2014.

Но в 1 случае ИС не попадает ни в какой класс, а во 2 случае возникает СОВ, что "несколько не устраивает". Может есть еще какие-либо способы определить исходные требования к системе защиты информации в ИС?

Приветствую!
Три вопроса.
Первый: точно ли в ИС нет явно определенной законом ИОД? А не явно? Так сказать, "чисто для себя" (она же КОНФИ)? Полностью общедоступных ИС не бывает...

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

И третий (самый любопытный). Это ж как вы ИС с "конфи-паролями only" умудрились предварительно классифицировать как ГИС или ИСПДн 2 и выше класса/уровня защищенности, чтобы на выходе обязательность применения СОВ получить? И вдогонку: как применение СОВ поможет защитить пароли пользователей от компрометации (камень в огород "компенсирующих мер", ага) ? :)

ЗЫ Если все-таки вся соль только в паролях (мне даже интересно, что же это за ИС такая - на ум приходит только Интернет-кафе с паролем от админской машины), то называется это "политика обращения с ИАФ и ключевой информацией в организации". В оной же "политике" все требования указываются самостоятельно и, зачастую, исходя исключительно из здравого смысла...

> Второй, вытекающий из ответа на первый: зачем определять класс ИС по существующей принятой системе классификаций, если она не обрабатывает информацию ограниченного доступа, установленную законодательством?

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

> И вдогонку: как применение СОВ поможет защитить пароли пользователей от компрометации (камень в огород "компенсирующих мер", ага)

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

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

to malotavr
1. Дык, общедоступные ресурсы внутри компании, веб-порталы с общедоступной инфой и проч. - это не ИС с ИОД в рамках нашего законодательства. Иначе, юридически, ее необходимо обзывать конфой по соответствующему перечню (своему или общему). Что никто в здравом уме делать не будет, поскольку инфа-то общедоступная. Потому и сказал, что коли дело "только в паролях" - утверждается политика безопасности и вперед - без всяких классификаторов. Они для другого предназначены...
2. СОВ (по ФСТЭК, ага) не IPS. А дежурной группы админов в режиме 24/7 никто не отменял даже (особенно) при использовании СОВ. А так... fail2ban под iptables (из простейшего). Назвать этот "довесок" к МЭ "системой обнаружения вторжений" язык явно не повернется. Или вообще ограничить кол-во попыток ввода паролей на уровне веб-сервера+СУБД. Вариантов много, но это опять-таки не СОВ. Пробежался по 638 Приказу - точно не СОВ, даже не 6 класса :)
3. Цимес в том, что топикстартеру, imho, не следует брать "грех на душу" и классифицировать свою ИС в рамках ГИС/ИСПДн/АС. Если речь идет действительно только о защите парольной/ключевой информации. Максимум - если используются ключевые носители СКЗИ - выполнить требования формуляров по линии ФСБ. И закончить на этом, наведя защитный марафет подручными средствами, исходя из собственной логики/политики безопасности. В противном случае геморроя будет больше, а уровень фактической защищенности не изменится (если не снизится вообще)...

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

По РД классифицировать никак не получилось. По ГИС - масштаб:федеральный, степень ущерба: не может быть определена/низкая/низкая, уровень значимости:УЗ 3, класс защищенности:К2.

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

Как вариант - в соответствии с п.6.3.1 ГОСТ 51583-2014 сделать модель угроз, позакрывать в ней угрозы средствами защиты информации и все? Насколько такой подход применим, Гуру?

to Александр
1. Подход с Моделью (+ЧТЗ, в котором уже требования по результатам анализа угроз безопасности) без приплетения 17, 21 и иных приказов идеален. Раз уж заказчик такой настойчивый (что конфиденциалки нет, ага). Только не совсем по приведенному ГОСТ. Скорее по адаптации (самопальной) одной из существующих Методик (рекомендую Проект Методики-2015 ФСТЭК, она оптимальнее в вашем случае). Ибо ГОСТ все-таки для вновь создаваемых систем. Т.е. применим в случае, когда система разрабатывается с 0 или модернизируется не столько в части ЗИ, сколько по общему функционалу. Если ваша ИС уже существует и работает, но в нее надо внедрить подсистему ЗИ, то ГОСТ, пожалуй, не подойдет. + в нем методика анализа и описания УБИ не расписана все-таки...
2. Ошибочка классификации у вас. 17 Приказ: "Информация имеет низкий уровень значимости (УЗ 3), если для всех свойств безопасности информации (конфиденциальности, целостности, доступности) определены низкие степени ущерба." А в части конфиденциальности, как я понимаю, у вас "не может быть определена". Так что итоговый класс по ГИС - К3 - т.е. без СОВ и СДЗ. Над чем, собственно, я ранее и недоумевал...
3. Кстати, ИС автономна по отношению к другим ИС, в которых ИОД однозначно циркулирует? Т.е. как идет наполнение ИС общедоступной информацией: автоматизированные скрипты поиска и заполнения полей БД или все-таки подключение и частичный ручной ввод из других ИС? Просто в ином случае, imho, этот "портал" надо рассматривать как часть конфиденциальной ИС, ее рубеж, "открытый контур", так сказать. Ну, это если Проект Методики-2015 для моделирования угроз применять, ага. И вот так, пожалуй, будет вернее всего (и с позиции закона, и с позиции здравого смысла)...

ЗЫ И вообще, еще раз обращаю внимание: классифицировать ИС (АС) с целью внедрения (выполнения) требований ЗИ по факту защиты одного из компонент этой самой системы ЗИ (пароли и права доступа, ага) - это чистой воды оксюморон... Аля бородатый анекдот про "нашу страну", "тонны стали" и "экскаваторы" или то самое "У попа была собака"...

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

to oko
to malotavr
большое человеческое спасибо

to WORM
понял, спасибо

> 2. СОВ (по ФСТЭК, ага) не IPS.

А мужики-то и не знают :)

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

Как непосредственный участник процесса принятия профилей сообщаю: они разрабатывались именно как профили на IDS/IPS :)

> А так... fail2ban под iptables (из простейшего). Назвать этот "довесок" к МЭ "системой обнаружения вторжений" язык явно не повернется. Или вообще ограничить кол-во попыток ввода паролей на уровне веб-сервера+СУБД. Вариантов много, но это опять-таки не СОВ. Пробежался по 638 Приказу - точно не СОВ, даже не 6 класса :)

Правильно, потому что от подбора словарных паролей все перечисленное ни хрена не помогает, от слова "совсем". Поэтому только СОВ, причем заточенные под конкретные протоколы :)

В остальном согласен: если нет нормативных требований, надо подключать здравый смысл. В методическом документе ФСТЭК меры защиты расписаны довольно разумно, и даже по классам разумно разнесены (хотя я бы понизил уровень для СОВ и АНЗ, сделав их базовыми уже для 4 класса защищенности), но привязываться при этом к классам защищенности совсем не обязательно.