Перейти к содержимому. | Перейти к навигации

Персональные инструменты
Вход Регистрация
Вы здесь: Главная РУБРИКАТОР Приобретение, разработка и сопровождение информационных систем Приобретение, разработка и сопровождение информационных систем (BS ISO/IEC 27002:2005 RU, раздел 12)
Protectiva Compliance Manager
Навигация
 

Приобретение, разработка и сопровождение информационных систем (BS ISO/IEC 27002:2005 RU, раздел 12)

Операции с документом
Требования к безопасности информационных систем, Корректное выполнение приложений, Безопасность системных файлов, Безопасность в процессах разработки и поддержки, Управление техническими уязвимостями

Требования к безопасности информационных систем

Цель: Обеспечить встраивание механизмов безопасности в информационные системы.

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

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

Анализ и спецификация требований безопасности

 

Механизм контроля

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

Руководство по внедрению

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

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

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

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

Дополнительная информация

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

ISO/IEC TR 13335-3 предоставляет руководство по использованию процессов управления рисками для идентификации требований к механизмам безопасности.

Корректное выполнение приложений

Цель: Предотвратить ошибки, потери, несанкционированную модификацию или неправильное использование информации в приложениях.

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

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

Проверка входных данных

 

Механизм контроля

Данные, вводимые в приложения, должны проверяться на предмет их корректности и приемлемости.

Руководство по внедрению

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

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

Дополнительная информация

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

Контроль внутренней обработки данных

 

Механизм контроля

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

Руководство по внедрению

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

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

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

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

Дополнительная информация

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

Целостность  сообщения

 

Механизм контроля

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

Руководство по внедрению

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

Дополнительная информация

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

Проверка выходных данных

 

Механизм контроля

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

Руководство по внедрению

Проверка выходных данных может включать в себя следующее:

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

Дополнительная информация

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

Безопасность системных файлов

Цель: Обеспечить безопасность системных файлов.

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

Контроль действующего программного обеспечения

 

Механизм контроля

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

Руководство по внедрению

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

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

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

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

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

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

Дополнительная информация

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

Защита тестовых данных в системах

 

Механизм контроля

Тестовые данные должны тщательно выбираться, защищаться и контролироваться.

Руководство по внедрению

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

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

Дополнительная информация

Для проведения системных и приемо-сдаточных испытаний обычно требуются значительные объемы тестовых данных, которые должны быть максимально близки к рабочим данным.

Контроль доступа к исходным текстам программ

 

Механизм контроля

Доступ к исходным текстам программ должен быть ограничен.

Руководство по внедрению

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

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

Дополнительная информация

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

Стандарты ISO 10007 и ISO/IEC 12207 предоставляют дополнительную информацию по управлению конфигурацией и процессу жизненного цикла программного обеспечения.

Безопасность в процессах разработки и поддержки

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

Следует строго контролировать проектную среду и среду технической поддержки.

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

Процедуры управления изменениями

 

Механизм контроля

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

Руководство по внедрению

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

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

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

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

Дополнительная информация

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

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

Технический анализ приложений после внесения  изменений в операционные системы

 

Механизм контроля

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

Руководство по внедрению

Этот процесс должен охватывать:

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

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

Ограничения на внесение изменений в пакеты программного обеспечения

 

Механизм контроля

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

Руководство по внедрению

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

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

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

Утечка информации

 

Механизм контроля

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

Руководство по внедрению

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

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

Дополнительная информация

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

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

Аутсорсинг разработки программного обеспечения

 

Механизм контроля

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

Руководство по внедрению

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

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

Управление техническими уязвимостями

Цель: Уменьшить риски, связанные с использованием опубликованных технических уязвимостей.

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

Контроль технических уязвимостей

 

Механизм контроля

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

Руководство по внедрению

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

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

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

Дополнительная информация

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

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

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

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

Comments (0)

Как стать участником |  Что может участник  |  Как работать с порталом  |  Реклама |  Авторские права  |  Контакты  |  Конкурсы  |  RSS  |  Форум
©2003 - 2019 GlobalTrust
Рейтинг@Mail.ru Rambler's Top100 Yandex