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

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

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

Не устраненные (неустранимые на данный момент) уязвимости заносятся в дополнительный отчет, используя классификацию ГОСТ Р 56546-2015.

4.2.3 Путем проведения тестирования информационной системы на проникновение

Проведение тестирования на проникновение не является лицензируемым видом деятельности согласно Федеральному Закону «О лицензировании отдельных видов деятельности» №99 от 04.05.2011.

Поэтому существуют два варианта проведения тестирования на проникновение:

• с привлечением сторонней организации, предоставляющей услуги по проведению тестирования на проникновение;

• силами собственной организации.

В случае привлечения сторонней организации, следует определить следующие положения в процессе разработки договора о предоставлении услуги:

• модель потенциального нарушителя (внешний или внутренний);

• степень осведомленности нарушителя об информационной системе;

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

• точки остановки процесса тестирования для минимизации ущерба информационной системе в процессе тестирования;

• неразглашение информации, полученной в процессе тестирования, третьим лицам.

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

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

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

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

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

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

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

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

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

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

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

Ответственные лица должны ознакомиться с рекомендуемыми методиками проведения тестирования на проникновение. На данный момент (2017 год) это:

• OWASP Testing Guide (https://www.owasp.org/images/1/19/OTGv4.pdf);

• OSSTMM (http://www.isecom.org/mirror/OSSTMM.3.pdf).

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

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

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

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

• процесс повторяется с первого пункта, принимая во внимание новые возможности тестирующего лица.

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

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

Ответственные за выполнение мероприятий лица обеспечивают внесение изменений в состав и конфигурацию информационной системы или ее частей в течении указанного времени.

Не устраненные (неустранимые на данный момент) уязвимости заносятся в дополнительный отчет, используя классификацию ГОСТ Р 56546-2015.

4.3 Контроль установки обновлений программного обеспечения и средств защиты информации

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

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

Необходимо для каждого пункта перечня получить информацию об актуальной версии. Для этого нужно обратиться к следующим источникам:

• официальный сайт разработчика;

• контактное лицо компании разработчика;

• другие источники, обозначенные оператором как доверенные.

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

4.4 Контроль правильности функционирования программного обеспечения и средств защиты информации

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

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

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

• тестовый сценарий;

• назначенное для тестирования лицо;

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

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

• описание ошибочной ситуации;

• название части программного обеспечения;

• номер версии программного обеспечения;

• серьезность ошибки;

• приоритет ошибки;

• лицо, обнаружившее ошибку;

• окружение (операционная система);

• шаги воспроизведения ошибки;

• фактический результат;

• ожидаемый результат.

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

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

• обновление до новой версии программного обеспечения, не содержащей ошибку;

• изменение параметров конфигурации программного обеспечения для достижения состояния, в котором ошибка не наблюдается;

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

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

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

• описание функции;

• используемый тестовый сценарий;

• тестирующее лицо;

• результат тестирования;

• дата тестирования;

• лицо, устранившее ошибку;

• способ устранения ошибки;

• дата устранения ошибки.

4.5 Контроль соответствия настроек программного обеспечения и средств защиты информации проектной документации на создание информационной системы

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

• описание программного обеспечения или средства защиты;

• описание параметра конфигурации;

• настоящее значение параметра конфигурации, полученное с использованием средств инвентаризации;

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

• отметка о соответствии;

• лицо, проводящее контроль соответствия;

• дата проведения контроля соответствия.

Разрешается сгруппировать пункты в отчете по наименованию программного обеспечения или средства защиты.

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

• отметка об устранении несоответствия;

• описание устранения несоответствия;

• лицо, устранившее несоответствие;

• дата устранения несоответствия.

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

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

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

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