Пояснительная записка (1209237), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Таблица 3.3 – Запись не устраненной уязвимости в дополнительный отчет

Заметим, что одна уязвимость может генерировать несколько недостатков информационной системы. При этом важная часть информации содержится в описании уязвимости.

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

3.2.1.2 Поиск уязвимостей с использованием сканеров безопасности

Согласно методическому документу ФСТЭК «Меры защиты информации» от 11.02.2014 от оператора информационной системы требуется использование автоматизированных средств поиска уязвимостей. К таким средствам относятся сканеры безопасности.

Отчеты сканеров безопасности представляют собой уже готовые списки уязвимостей системы с рекомендациями по устранению и ссылками на источники. Оператору следует собрать результаты работы использованных сканеров безопасности и свести их в единый отчет, используя форму описания уязвимости «Паспорт уязвимости», описанную в ГОСТ Р 56545-2015.

Затем следует произвести слияние полученного отчета с уже существующим отчетом по уязвимостям информационной системы, полученным при использовании других способов обнаружения уязвимостей. При слиянии в отчет добавляются только новые уязвимости, которые не были добавлены в отчет ранее. Уже обнаруженные уязвимости не следует дублировать.

Рекомендации по устранению новых уязвимостей следует перенести в план по устранению уязвимостей, дополнив его.

3.2.1.3 Поиск уязвимостей нулевого дня

Уязвимости «нулевого дня» – это те уязвимости, информация о которых уже раскрыта в общедоступных источниках, но не включена в базы данных уязвимостей или базы данных сканеров безопасности. Чаще всего такая информация появляется на новостных сайтах, специализирующихся на вопросах информационной безопасности.

К таким сайтам относятся:

• Anti-Malware.ru (https://www.anti-malware.ru/news);

• SecurityLab.ru (http://www.securitylab.ru);

• Cert.org (http://www.cert.org);

• Secunia (https://secuniaresearch.flexerasoftware.com/community/research/).

Данные новостные сайты рекомендуются к использованию. Возможно использование и других, предпочитаемых ответственным сотрудником оператора, источников информации об уязвимостях «нулевого дня».

Некоторые уязвимости «нулевого дня» попадают в общедоступные базы данных уязвимостей. Таким образом, помимо просмотра новостных источников, ответственному сотруднику следует просматривать новые записи об уязвимостях в этих базах данных.

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

Вся собранная информация должна быть сведена в промежуточный список возможных уязвимостей согласно ГОСТ Р 56545-2015. Этот промежуточный отчет выполняет функцию базы данных уязвимостей, которую затем нужно использовать для поиска уязвимостей в информационной системе в ручном режиме. Это производится путем редуцирования промежуточного отчета по признаку отсутствия в информационной системе продукта, имеющего уязвимость «нулевого дня».

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

• изменение настроек средств защиты информации;

• изменение режима и порядка использования информационной системы;

• иные действия.

Полученные мероприятия добавляются в план по устранению уязвимостей «нулевого дня» с указанием временных рамок выполнения и ответственных лиц. Составленный план согласовывается и реализуется.

3.2.1.4 Тестирование на проникновение

Методический документ ФСТЭК «Меры защиты информации» от 11.02.2014 требует от оператора проведения тестирования на проникновение своей информационной системы с целью поиска уязвимостей. Данное тестирование можно проводить как собственными силами, так и с привлечением сторонней организации исполнителя.

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

Тест на проникновение позволяет получить следующую информацию:

• насколько эффективно система защиты справляется с используемыми в настоящее время способами проникновения;

• уровень знаний об информационной системе, необходимый злоумышленнику для успешного проникновения;

• дополнительные меры защиты, которые позволят устранить уязвимости, существующие в системе в настоящее время;

• способности системы защиты по обнаружению атак и реагированию на них.

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

Тест на проникновение подразделяется на четыре фазы:

• планирование;

• исследование;

• проникновение;

• создание отчетов.

Фаза планирования включает в себя определение правил проведения теста, согласование с руководством, установку целей тестирования. Во время данной фазы тестирование еще не происходит.

Фаза исследования подразделяется на две части: сбор информации и поиск уязвимостей. Во время сбора информации система в первую очередь сканируется на предмет открытых портов и запущенных сетевых служб. Также ищется дополнительная информация:

• имена и IP-адреса хостов системы. Данная информация собирается путем DNS-опроса, рассылки запросов WHOIS и перехвата трафика в системе (если эти методы доступны);

• контактная информация и ФИО сотрудников. Данная информация собирается путем обследования Web-серверов и файловых серверов компании;

• системные имена и сетевые ресурсы. Данная информация собирается путем обследования информации от NetBIOS и NIS;

• информация о приложениях и сервисах (например, номер версии). Данная информация собирается путем захвата заголовков пакетов трафика.

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

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

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

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

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

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

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

Для сценариев с внутренним нарушителем, проводящее тестирование лицо снабжается информацией об информационной системе, доступной сотруднику с уровнем доступа, позиция которого подозревается в уязвимости. Также предоставляется соответствующий доступ к информационной системе или ее сегменту.

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

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

В методических рекомендациях по проведению анализа защищенности описывается только общая структура проведения тестирования информационной системы на проникновение. Более детализированная информация представлена в общедоступных методических документах, поэтому не имеет смысла ее дублировать в методических рекомендациях. Главные рекомендуемые к использованию методики (из [12]):

• OWASP Testing Guide (https://www.owasp.org/images/1/19/OTGv4.pdf) Данная методика сконцентрирована на всевозможных технических аспектах тестирования на проникновение, с указанием категорий используемых уязвимостей.

• OSSTMM (http://www.isecom.org/mirror/OSSTMM.3.pdf) Данная методика рассматривает более широкий круг аспектов тестирования на проникновение, включая социальный инжиниринг.

Использование данных методик проведения тестирования информационной системы рекомендуется при самостоятельном проведении тестирования.

3.2.1.5 Устранение уязвимостей

Необходимо составить план устранения уязвимостей исходя из результатов поиска уязвимостей. План должен содержать все мероприятия, которые будут выполнены. Для каждого мероприятия обязательны следующие поля:

• содержание мероприятия;

• временные рамки выполнения мероприятия;

• лицо, ответственное за своевременное выполнение мероприятия.

Содержание мероприятия получается из отчета по поиску уязвимостей, так как каждая уязвимость описывается по форме ГОСТ Р 56545-2015, в которой есть поле «Меры по устранению уязвимости». В случае отсутствия записи в этом поле уязвимость считается неустранимой стандартными средствами и в дальнейшем будет рассматриваться при определении актуальных угроз безопасности информации и актуализации системы защиты информации.

3.2.2 Контроль установки обновлений программного обеспечения (АНЗ 2)

Методический документ ФСТЭК «Меры защиты информации» требует от оператора информационной системы осуществления контроля установки обновлений программного обеспечения. Оператор должен осуществлять получение из доверенных источников и установку обновлений программного обеспечения.

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

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

Характеристики

Список файлов ВКР