Старое но не бесполезное.

Аватар пользователя e.v.rodygin
Автор: Родыгин Евгений, Группа "Кронштадт"
(0)
()
Опубликовано в:

Угрозы НДВ (старенькое но живое)

В соответствии с ПП 1119 от 1 ноября 2012 г. вводятся угрозы 3-х типов так или иначе связанных с наличием недокументированных (недекларированных) возможностей в программном обеспечении.

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

Итак, мы имеем два уровня угроз:

  1. Угрозы, связанные с наличием недокументированных (недекларированных) возможностей в системном программном обеспечении.
  2. Угрозы, связанные с наличием недокументированных (недекларированных) возможностей в прикладном программном обеспечении.

Меры, направленные на нейтрализацию угроз делятся на четыре основные составляющие:

  1. Меры, направленные на недопущение появления угрозы.
  2. Меры, направленные на выявление угрозы.
  3. Меры, направленные на нейтрализацию выявленных угроз.
  4. Меры, направленные на минимизацию вреда или эффективности реализации угрозы.

Теперь проведем оценку реализации мер, но перед этим учтем несколько важных условий:

  1. Мы рассматриваем информационные системы (ИС), которые строятся операторами ПДн. Нужно понимать, что подавляющее число операторов решают задачи по созданию ИС только с использованием типовых продуктов как на системном так и на прикладном уровне (операционных систем, офисных систем обработки данных, СУБД и средств обеспечения). Разработка специальных информационных систем и технологий – редкое явление. Это дорого и у операторов в массе своей такая задача не стоит и не может быть решена имеющимися ресурсами.
  2. Оператор получает программные компоненты ИС в готовом виде – без конструкторской документации, без исходных текстов и т.п. Только дистрибутив и эксплуатационную документацию. При этом важно понимать, что значительная часть операторов не строят ИС а только эксплуатирует ее.
  3. К основным методам обеспечения безопасного применения программного обеспечения относятся:

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

Но указанные методы вряд ли доступны оператору.

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

(Угроза 1, мера 1) Недопущение появления угроз связано с контролем технологий безопасной разработки системного ПО. Если рассматривать угрозы на этом уровне, то мы в общем случае получим следующие:

Источники угроз на этапе формирования требований к системному ПО

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

Источники угроз на этапе проектирования системного ПО

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

Источники угроз на этапе реализации (кодирования/компиляции/сборки) системного ПО

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

Источники угроз на этапе тестирования системного ПО разработчиком

  • Проведение тестирования разработчиком или заказчиком системного ПО
  • целенаправленное использование методов тестирования, которые направлены на сокрытие уязвимостей;
  • тестирование не проводится или проводится не в полном объеме;
  • целенаправленное сокрытие результатов тестирования.

Проведение тестирования системного ПО независимой лабораторией в процессе сертификационных или иных испытаний

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

Источники угроз на этапе внедрения системного ПО

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

С учетом условий указанных выше, очевидно, что оператор не имеет возможностей по осуществлению контроля и обеспечения отсутствия недокументированных (недекларированных) возможностей в системном ПО. Вывод: меры 1.1. – оператору недоступны.

(Угроза 1, мера 2) Меры, направленные на выявление угрозы оператору доступны. Для этого оператор может самостоятельно или с привлечением специалистов:

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

(Угроза 1, мера 3) С учетом мер (Угроза 1, мера 2) оператор может самостоятельно или с привлечением специалистов:

  • производить установку сервиспаков, патчей для нейтрализации выявленных уязвимостей;
  • применять дополнительные СрЗИ, позволяющие нейтрализовать выявленные уязвимости системного ПО;
  • применять дополнительные организационно-технические меры связанные с изменением архитектуры ИС, настроек системного ПО и т.п.

(Угроза 1, мера 4) оператор может самостоятельно или с привлечением специалистов применять меры, направленные на минимизацию вреда или эффективности реализации уязвимостей (как выявленных, так и еще не выявленных) системного ПО:

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

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

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

Рассмотрев угрозы первого типа мы видим, что все тоже самое относится и к прикладному ПО.

Выводы:

  • оператор не имеет возможности самостоятельно выявлять угрозы, связанные с наличием недокументированных (недекларированных) возможностей в ПО.
  • оператор имеет возможности самостоятельно или с привлечением сторонних специалистов отслеживать выявленные уязвимости системного и прикладного ПО и принимать меры, направленные на их нейтрализацию, минимизацию возможного вреда и/или эффективности реализации угроз.
Оцените материал:
Total votes: 105
Тэги: 
 
Комментарии в Facebook
 

Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.