Как создать корпоративную систему информационной безопасности

9 Ноя, 2018
Aleks Yenin

Опубликовано Aleks Yenin

Крупные хакерские атаки, которые происходят даже с такими казалось бы неуязвимыми компаниями, как Reddit, Apple, Facebook, служат прекрасным доказательством того, что информация a) чрезвычайно ценный актив, который б) невозможно полностью защитить. Означает ли это, что вам даже не стоит пытаться этого сделать? Совсем нет. Считайте, что это вызов 21 века, однако и к нему можно подобрать решение — если знать как.

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

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

1. Разработка политики и стратегии информационной безопасности

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

Источник:  http://trustedtoolkit.blogspot.com/

2. Мониторинг

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

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

Источник: www.pagerduty.com/

3. Ведение журнала инцидентов

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

  • Уникальный идентификационный номер
  • Категория инцидента
  • Дата и время записи
  • Влияние инцидента
  • Сведения о пользователе
  • Описание симптомов
  • Сведения о разрешении инцидента
  • Дата и время закрытия тикета

4. Анализ журналов инцидентов и пост-анализ

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

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

Источник: www.slideshare.net/Jaiveer/post-mortem-analysis

5. База знаний

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

Источник: www.knowledge-management-tools.net

6. Менеджмент проблем

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

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

Источник: Fomin.org

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

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

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

Источник: wilsoncgrp.com
Поделиться:

Напишите нам

Мы всегда рады Вам помочь