Устаревшее ПО - Форум по вопросам информационной безопасности

Разработчик ПО для обработки ПДН использует устаревшую версию Java 6. На сайте java.com есть уведомление - Июль 2015 года: Обновления для Java 7 больше не являются общедоступными – значит 6 версию тем более нельзя использовать (до февраля 2013 года). На требование использовать современную версию, был получен отказ, мотивируя что нет запрета на использование 6 версии, а есть рекомендации. Подскажите как поступить в данной ситуации, требовать использование новых версий или оставить все как есть.

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

Ни то и ни другое.

В соответствии с приказом 21, тот, кто отвечает за безопасность этой системы (вы?), обязан проводить анализ защищенности. На основании результатов анализа защищенности он должен заявить: "Чуваки, ахтунг, вы используете Java 7, в которой есть куча критических уязвимостей (номера CVE прилагаются). Ими можно воспользоваться вот так, и в результате произойдет вот такая кака".

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

to malotavr
Торопитесь, товарищ. Ежели 4 уровень защищенности ИСПДн - не обязан.
И потом, "правила и процедуры выявления, анализа и устранения уязвимостей регламентируются в организационно-распорядительных документах оператора по защите информации". Это из методдокумента ФСТЭК по мерам защиты для ГИС, в которых тоже есть АНЗ.1. Рискну предположить, что для ИСПДн они равносильны с позиции регулятора (да и здравого смысла). Следовательно, пока во внутренних инструкциях явно не определено, что обновление используемого ППО является актуальным решением для устранения уязвимостей, а также не определено (или определено из рук вон плохо), каким способом эти уязвимости выявлять, - формально, заставить нельзя никак.
И, кстати, наличие уязвимостей в ППО - не повод. Вопрос в том, как построена система защиты. Возможно, эксплуатация этих уязвимостей ни к чему плачевному привести не может (или отсутствуют нарушители, способные их эксплуатировать) и вообще была заранее предусмотрена "Моделью угроз..." и соответствующим образом закрыта. В конце концов, полно частных контор, которые до сих пор юзают WinXP и ниже, но запрещать им обработку ПДн совершенно нет необходимости...
А так, да, лучший метод - наглядная демонстрация взлома системы через какую-нибудь дырку в той же Java 6. Но это, можно сказать, на крайний случай, если другие доводы не работают...

to Игорь
Чтобы нормально разобраться в вопросе нужны дополнительные исходные данные. Причем вагон и маленькая тележка. Поэтому и рекомендую для начала посмотреть выводы "Модели..." и воспользоваться, при случае, приведенным выше советом. Или советом тов. malotavr, если АНЗ.1 обязателен к исполнению, инструкции предусматривают выявление/обновление, а в "Модели..." про уязвимости ничего не сказано или УБИ признаны актуальными...

УЗ2 и класс 2 (К2). Перештрудиловал "Модель .." про обновление ППО, не нашел, но это не показатель. Где-то читал, склероз.. не могу найти про поддержании ППО в актуальном состоянии, т.е. если производителем прекращено обновление, то необходимо менять на современное. Нас в 2015 году проверяло ФСБ, и они очень обстоятельно проверяли обновление ПО, ОС, как развернут WSUS и т.д. тогда я не думал об этом, в этом году нам спустили сверху ПО на jave 6, админы были не восторге. CVE - как вариант, на офсайте java.com - даты конечных выпусков обновлений, собираю любую информацию.
to oko
"В конце концов, полно частных контор, которые до сих пор юзают WinXP и ниже..." - до первой проверки.

to Игорь
Да не факт же. Вариантов, при которых можно юзать XP и при этом не терять в защищенности - масса. Все зависит от конкретного техпроцесса и особенностей системы защиты. Это гос.органам обязательно переходить на ОС с поддержкой обновлений, а коммерсам без разницы...
Но в вашем случае, да, при У2 и думать нечего - требование АНЗ.1 по 21 Приказу ФСТЭК и вперед. Если есть инструкция по выявлению и т.п. уязвимостей - должны проводить и, соответственно, обновляться. Если нет, то резонно спросить "почему нет?". А дальше брать тот же bdu.fstec.ru (для упрощения, ага) и опять-таки писать новую инструкцию про выявление уязвимостей и про обновления, а затем их применять...

> Торопитесь, товарищ. Ежели 4 уровень защищенности ИСПДн - не обязан

Вы о чем вообще?

Человек, отвечающий за безопасность системы может провести анализ защищенности, даже если не обязан. Если вдруг у кого-то возникнет вопрос, почему он это сделал, помимо здравого смысла он может сослаться на то, что в соответствии с п. 6 приказа 21 он провел оценку эффективности мер защиты и вот в ходе нее-то и выяснил, что в системе есть пипец какие страшные уязвимости.

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

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

Сфероконина - вещь хорошая, но мы живем в реальном мире, в котором есть вполне определенные софтины и вполне определенные уязвимости.

CVE-2013-0422, CVSS 10.0 (получение полного контроля над компом пользователя), попала в базу CVE после того, как в сплойт-паках Blackhole and Nuclear Pack появились полнофункциональные эксплойты. Единственное, что смогли сказать в US-CERT: "Пацаны, пока не выйдет обновление безопасности, отключите нахрен поддержку Java в своих браузерах". В таких обстоятельствах я бы на вашем месте не рискнул утверждать, что "все не так страшно, может уязвимость ни к чему плачевному привести не может или нарушитель отсутствует, и вообще ситуация рассматривается моделью угроз как вполне допустимая" :)

Просто пример, надо посмотреть, какие CVEшки появились для Java 7 после end-of-support. Но даже если их нет сейчас, это не значит, что они не появятся завтра.

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

Oracle бросила выпускать java 6, потому что не смогла сделать патчи, потом аналогично и 7 версию.

В "Модели.." нет про обновление, упустили момент.

Проблема еще в том, что проверяющим все-равно, должно быть установлено ППО, которое сейчас актуально, проверить лицензии, сертификаты и т.д. С Java 6 мы проверку не пройдем, даже если это хорошо защищаемая сеть.

Поэтому и спрашиваю, мне нужны железные аргументы.
CVE-2009-0217
CVE-2009-0901
CVE-2009-2493
CVE-2009-2495
CVE-2009-2625
CVE-2009-2670
CVE-2009-2671
CVE-2009-2672
CVE-2009-2673
CVE-2009-2674
CVE-2009-2675
CVE-2009-2676
CVE-2013-2463

> В "Модели.." нет про обновление, упустили момент.
...
> Поэтому и спрашиваю, мне нужны железные аргументы.
> CVE-2009-0217
> CVE-2009-0901
> CVE-2009-2493
...
> CVE-2013-2463

Вы путаете отсутствие обновления и наличие уязвимости. Вам (и проверяющим) неважно, стоит там JSE 6 или 8, важно, чтобы были устранены уязвимости. Идентифицируйте уязвимости, которые в ППО реально есть (или вручную, выписав CVEшки, появившиеся после end-of-support, или посканируйте машину, на которое установлено ППО подходящим САЗом, поддерживающим режим "белого ящика"). Сделайте сводку этих уязвимостей с разблюдовкой по степени критичности и дайте свою оценку, чем эти уязвимости опасны для системы. С этой разблюдокой идите к своему руководству (вы ведь не уполномочены самостоятельно ставить задачи разработчикам?).

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

Ваша задача как безопасника закончилась в тот момент, когда вы идентифицировали проблему и показали, что решить ее может только разработчик примерно вот таким способом.

to malotavr
Во даете, товарищ... Как ставился вопрос? "На требование использовать современную версию, был получен отказ, мотивируя что нет запрета на использование 6 версии, а есть рекомендации". И, если бы ИСПДн была 4 уровня защищенности - разработчики бы имели полное право так сказать. Ибо де-юре законодательство их не обязывает задумываться об уязвимостях в своей системе в процессе ее эксплуатации, если в ОРД и Модели не сказано обратное. То ли дело, что составителю Модели и внутренней ОРД в таком случае надо было руки оторвать...

to Игорь
Странные какие-то проверяющие, редко таких встретишь... Даже не знаю, хорош такой радикализм или плох...
Но ответ был дан ранее. На основании требования АНЗ.1 проводится выявление уязвимостей любым доступным методом - хоть методом гугления с представлением нужных ссылок на общедоступные базы. Обычно на этом этапе достаточно показать наличие данных руководству. Но, если все равно не верят - гуглится или самостоятельно прорабатывается план реализации атаки через найденные уязвимости. И либо демонстрируется, либо на словах описывается. Короче, любым методом доказываем, что действующая система защиты не позволяет нейтрализовать УБИ, связанные с этой уязвимостью (если реально не позволяет, ага). Этого обычно также хватает. А если не хватает - берем в руки чистой воды юр-инструмент - прорабатываем внутренний комплект инструкций с позиции "найдена уязвимость и есть официальный патч/новая версия, позволяющая ее устранить? => пропатчить/обновиться" На резонный вопрос со стороны руководства: "На основании чего так составлены инструкции?" отвечаем - на основании описания требования АНЗ.1 из методдокумента "Меры защиты информации в ГИС" п. 3.8, ибо требование АНЗ.1 есть не только в ГИС, но и в ИСПДн 3 и выше уровней защищенности. Profit!


К слову о Java 6. Приведу пример, чтобы отсеять ремарки про сфероконину. ИСПДн 2 уровня защищенности (т.е. АНЗ.1 актуально). Обработка информации идет через специальное ППО без Java в сетевой СУБД. МЭ в сети запрещает коннект извне к ресурсам ИСПДн. Доступ из ИСПДн вовне только через проксю и МЭ, которые работают по принципу "белых списков" (не абы каких, разумеется). Установленные средства АВЗ автоматически фильтруют сетевой трафик и активность программ/операций с файлами. Имеется СОВа с грамотным товарищем из службы безопасности, мониторящим сетевую и прочую активность. Доступ к ТС ИСПДн ограничен орг.-реж. мероприятиями (не для галочки, а реально ограничен). Производится автоматическое и разовое ручное бэкапирование критичных файлов и структур СУБД ПДн на отдельные съемные или недоступные из сети устройства. Как в такой ситуации уязвимость Java 6 может критично повлиять на защищенность ИСПДн? Даже не так: допустимо ли признавать опасность и вероятность реализации УБИ, связанных с уязвимой версией Java в такой ИСПДн, более чем "низкими"? А, э, так-то, дружок, в этом-то все и дело (с) А именно - в замкнутости тех.процесса и особенностях системы защиты...
*в сторону* таргетированные атаки не предлагать - тут ситуация 50/50 как относительно подготовки/осведомленности нарушителей, так и подготовки/скорости ответственных за безопасность. +, разумеется, в динамике жизненного цикла ИС всегда можно подгадать момент, когда при всей полноте и непробиваемости своей системы защиты она будет полностью захвачена/уничтожена подкованным злоумышленником или иными независимыми обстоятельствами...