Вайнштейн Ю.В., Демин С.Л., Кирко И.Н., Кучеров М.М., Сомова М.В. Основы информационной безопасности

Подождите немного. Документ загружается.

241

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

Безопасность системных файлов. Защита данных, используемых в

процессе тестов систем

− Система разграничения доступа к тестовой системе должна соответ-

ствовать доступу к обычной системе.

− Необходимо обеспечение разных (раздельных) авторизаций каждый

раз, когда рабочая (оперативная) информация копируется в тестовую

систему.

− Рабочая информация должна быть немедленно удалена из тестовой

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

− Копирование и использование рабочей (оперативной) информации

должно быть запротоколировано для последующей возможности ау-

дита.

Безопасность процессов разработки и поддержки. Процедуры контро-

ля изменений

1. Документальное закрепление типовых уровней доступа.

2. Обеспечение, того, что изменения сделаны авторизованными пользо-

вателями.

3. Идентификация всего программного обеспечения, информации, баз

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

4. Получение формального разрешения для детализации предложений

до начала работ.

5. Обеспечение того, что авторизованные пользователи принимают

(проверяют) изменения до их внедрения.

6. Обеспечение безопасного внедрения изменений без последствий для

бизнеса.

7. Обеспечение изменений системной документации после каждой мо-

дификации, а также архивация старой документации или ее отклоне-

ние.

8. Обеспечение контроля версий для всех обновлений программного

обеспечения.

9. Обеспечение протоколирования всех запросов на изменение.

242

10. Обеспечение соответствующих изменений оперативной и пользова-

тельской документации.

11. Обеспечение того, что внедрение изменений имело место в соответст-

вующее время и не затронуло вовлеченные в процесс бизнес процес-

сы.

Управление инцидентами информационной безопасности

Процедуры должны предусматривать все возможные ситуации, вклю-

чая:

− сбои в информационных системах;

− отказ в обслуживании;

− ошибки из-за неполных или неправильных входных данных;

− утечку информации.

В дополнении к оперативному плану восстановления процедуры долж-

ны также включать:

− анализ и определение причин инцидента;

− планирование и внедрение мер для предотвращения повторения (ес-

ли необходимо);

− анализ и сохранение сведений об инциденте, которые можно пред-

ставить в качестве доказательства (улики, свидетельства и т.п.);

− определение порядка взаимодействия между пострадавшими от ин-

цидента и участниками процесса восстановления;

− обязательное информирование ответственных лиц.

По каждому инциденту должно быть собрано максимальное количество

информации, которой также необходимо обеспечить необходимый уровень

защиты для:

− последующего анализа внутренних проблем;

− использования собранных данных для привлечения виновных к дис-

циплинарной, административной или уголовной ответственности;

− использования при ведении переговоров о компенсациях с постав-

щиками аппаратного и программного обеспечения.

Действия по восстановлению после обнаружения уязвимостей в систе-

ме безопасности, исправлению ошибок и ликвидации неисправностей долж-

243

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

гарантировать что:

− только персонал, прошедший процедуры идентификации и аутенти-

фикации может получать доступ к «ожившим» системам и данным;

− все действия по выходу из нештатной ситуации зафиксированы в ви-

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

− обо всех произведенных действиях руководство было проинформи-

ровано в установленном порядке;

− целостность и работоспособность системы подтверждена в мини-

мальные сроки.

Управление непрерывностью бизнеса

− Процесс управления непрерывностью ведения бизнеса должен быть

регламентирован;

− Создание и внедрение плана непрерывного ведения бизнеса;

− Основы планирования непрерывности бизнеса;

− Тестирование, обеспечение и переоценка плана непрерывного веде-

ния бизнеса.

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

− Осознание рисков, их вероятностей, возможных последствий, вклю-

чая идентификацию и расстановку приоритетов для критичных биз-

нес процессов;

− Осознание ущерба в случае прерывания бизнеса и создание бизнес

целей для информационно-обрабатывающей системы компании;

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

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

− Формализация и документирование стратегии ведения непрерывного

бизнеса, содержащей согласованные цели бизнеса и приоритеты;

− Регулярное тестирование и обновление планов и процессов;

− Необходимо убедиться, что управление непрерывным ведением биз-

неса внедрено в организационные процессы и структуру компании;

244

− Ответственность для координации управления непрерывным ведени-

ем бизнеса должна быть распространена по соответствующим уров-

ням внутри организации, так называемый форум по информационной

безопасности.

Создание и внедрение плана непрерывности бизнеса

− Распределение ответственности и определение всех контр аварийных

процедур (порядок действий в аварийной ситуации);

− Внедрение контр аварийных процедур для восстановления систем в

отведенный период времени. Особое внимание уделяется оценке за-

висимости бизнеса от внешних связей;

− Документирование всех процессов и процедур;

− Соответствующее обучение персонала порядку действий в аварий-

ных ситуациях включая управление в кризисных процессах;

− Тестирование и обновление планов.

Основы планирования непрерывности бизнеса

− Условия вступления в действие планов (как оценить ситуацию, кто в

нее вовлечен);

− Контр аварийные процедуры, описывающие действия в случае инци-

дентов, представляющих опасность для бизнес операций или/и чело-

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

по связям с общественностью и органами власти;

− Процедуры нейтрализации неисправностей, в которых описываются

действия по выведению жизненно важных бизнес нужд или служб

поддержки во временное альтернативное помещение и возвращение

их в соответствующий период времени;

− Процедуры восстановления, в которых описаны действия по возвра-

щению к нормальному процессу бизнес операций;

− Разработка программы, в которой описаны, как и когда план будет

протестирован и процесс внедрения этого плана;

− Действия по информированию и обучению, которые разрабатывают-

ся для понимания персоналом процесса обеспечения непрерывности

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

245

− Личная ответственность – кто именно отвечает за выполнение каждо-

го компонента плана, с указанием дублирующих лиц.

Тестирование планов обеспечения непрерывности бизнеса

− Базовые тесты различных сценариев (обсуждение мероприятий по

восстановлению бизнеса в случае различных ситуаций);

− Моделирование (практический тренинг персонала по действиям в

критичной ситуации);

− Тестирование технических мероприятий по восстановлению (для га-

рантии того, что информационная система будет эффективно восста-

новлена);

− Тестирование технических мероприятий по восстановлению в аль-

тернативном месте (запуск бизнес процессов вместе с восстанови-

тельными мероприятиями вне основного места расположения);

− Тесты систем и поставщиков услуг (гарантия, что внешние предос-

тавляемые сервисы и продукты будут соответствовать контрактным

обязательствам);

− Комплексные учения (тестирование того, что компания, персонал,

оборудование, информационная система могут справиться с нештат-

ной ситуацией).

13.15. Соответствие системы основным требованиям

1. Соответствие требованиям законодательства.

2. Соответствие политике безопасности.

3. Соответствие техническим требованиям.

4. Соответствие требованиям системного аудита.

Соответствие требованию законодательства. Копирайт на ПО

− Разработка и внедрение политики соблюдения авторского права на

программное обеспечение, где определяется легальное использова-

ние ПО и информационных продуктов;

− Выпуск стандартов для процедур приобретения программного обес-

печения;

246

− Обеспечение осведомленности пользователей об авторских правах на

программное обеспечение, правилах приобретения программного

обеспечения и уведомление пользователей, что в случае нарушения

будут предприняты дисциплинарные действия;

− Обеспечение возможности доказательства, что данное программное

обеспечение лицензионно (лицензии и т.д.);

− Контроль того, что максимальное число пользователей в лицензии не

превышено;

− Выполнение проверок, что только разрешенные и лицензионные

продукты инсталлированы;

− Разработка политики для обеспечения соответствующих условий ли-

цензионного соглашения;

− Разработка политики для размещения или передачи программного

обеспечения сторонним лицам или компаниям;

− Применение соответствующих средств аудита;

− Соблюдение условий для программного обеспечения и информации,

полученных из открытых сетей.

Защита персональных данных и информации

В РФ принят закон, регламентирующий обработку и передачу персо-

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

структуры управления и контроля. Часто лучше всего назначить специально-

го менеджера по защите персональных данных.

Сохранение улик - качество и полнота улики

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

линность улики:

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

гинала, ведется запись кто, где и когда нашел его и кто был свидете-

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

был изменен.

2. Для информации в электронной форме: гарантия доступности должна

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

информации на жестких дисках и в оперативной памяти. Все действия

в процессе копирования должны быть запротоколированы и засвиде-

247

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

безопасном месте.

Соответствие с политикой безопасности

Необходимо проводить регулярный анализ соответствия следующих

объектов политике безопасности и стандартам:

− информационные системы;

− системы обеспечения;

− владельцы информации и информационных ресурсов;

− пользователи;

− менеджеры.

Соответствие техническим требованиям

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

соответствие стандартам безопасности. Проверка технического соответствия

включает проверку ИС на предмет корректного функционирования аппарат-

ных и программных систем управления.

Проверка должна производиться либо лично инженером, либо автома-

тизированным средством, отчет которого будет анализироваться затем инже-

нером.

Проверка соответствия также включает тесты на проникновение, кото-

рые должны проводиться независимыми экспертами.

13.16. Служебные инструкции и ответственность

Контроль изменений в операционной среде:

− Идентификация и запись важных изменений;

− Оценка потенциального ущерба и последствий таких изменений;

− Формальное утверждение процедуры внесения изменений;

− Взаимодействие со всеми заинтересованными лицами при внесении

изменений;

− Процедуры определения ответственности и возврата в исходное со-

стояние при неудачных попытках изменений.

Процедуры реагирования в случае инцидентов

248

1. Процедуры должны предусматривать все возможные ситуации, вклю-

чая:

− сбои в информационных системах,

− отказ в обслуживании,

− ошибки из-за неполных или неправильных входных данных,

− утечку информации;

2. В дополнении к оперативному плану восстановления процедуры

должны также включать:

− анализ и определение причин инцидента,

− планирование и внедрение мер для предотвращения повторения (ес-

ли необходимо),

− анализ и сохранение сведений об инциденте, которые можно пред-

ставить в качестве доказательства (улики, свидетельства и т.п.),

− определение порядка взаимодействия между пострадавшими от ин-

цидента и участниками процесса восстановления.

− обязательное информирование ответственных лиц;

3. По каждому инциденту должно быть собрано максимальное количе-

ство информации, которой также необходимо обеспечить необходи-

мый уровень защиты для:

− последующего анализа внутренних проблем,

− использования собранных данных для привлечения виновных к дис-

циплинарной, административной или уголовной ответственности,

− использования при ведении переговоров о компенсациях с постав-

щиками аппаратного и программного обеспечения;

4. Действия по восстановлению после обнаружения уязвимостей в сис-

теме безопасности, исправлению ошибок и ликвидации неисправно-

стей должны быть внимательно и формально запротоколированы.

Процедура должна гарантировать, что:

− только персонал, прошедший процедуры идентификации и аутенти-

фикации может получать доступ к «ожившим» системам и данным,

− все действия по выходу из нештатной ситуации зафиксированы в ви-

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

249

− обо всех произведенных действиях руководство было проинформи-

ровано в установленном порядке,

− целостность и работоспособность системы подтверждена в мини-

мальные сроки.

Разграничение ответственности путем разделения обязанностей

Этот метод уменьшает риск от случайного или запланированного зло-

употребления системой. Разделение зон ответственности между руководите-

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

информации, злоупотребления ею или сервисами.

Все критичные операции должны выполняться, как минимум, двумя со-

трудниками" − это так называемый принцип «4 глаз».

Необходимо учесть следующие моменты:

− действия, которые могут подразумевать сговор (например, покупка

товара и контроль закупленного товара), должны быть обязательно

разделены;

− если есть опасность сговора, то тогда необходимо применение прин-

ципа «4 глаз».

− Разделение ресурсов

Все ресурсы должны быть разделены по целям использования:

− Перспективная разработка,

− Тестирование (карантин),

− Непосредственное осуществление бизнес операций (операционная

среда).

Правила переноса нового программного обеспечения в операционную

среду должны быть регламентированы.

− Операционная среда и среда разработки должны, по возможности,

располагаться на разных компьютерах, в разных доменах или дирек-

ториях.

− Среда разработки и карантин должны быть надежно изолированы

друг от друга.

− Средства разработки, системные редакторы и другие системные ути-

литы не должны быть доступны в зоне тестирования и операционной

среде.

250

− С целью снижения вероятности возникновения ошибок, для входа в

тестовую и рабочую системы должны использоваться разные иден-

тификаторы и пароли, а все меню должны иметь соответствующую

маркировку.

− Разработчики должны иметь доступ к операционной среде только ко-

гда это необходимо для оперативного сопровождения этих систем.

Для этого они получают временный доступ, удаляемый по окончании

работ.

Контрольные вопросы

1. В чем состоят основные направления политики обеспечения инфор-

мационной безопасности?

2. Каким образом осуществляется защита от вредоносного ПО?

3. В чем состоят задачи руководства организации по обеспечению ин-

формационной безопасности?