Экспертные рекомендации. Чек-лист для ИТ менеджера по обеспечению информационной безопасности в крупной организации.
Крупные хакерские атаки и угрозы информационной безопасности, которые происходят даже с такими казалось бы неуязвимыми компаниями, как Reddit, Apple, Facebook, служат прекрасным доказательством того, что информация a) чрезвычайно ценный актив, который б) невозможно полностью защитить. Означает ли это, что вам даже не стоит пытаться этого сделать? Совсем нет. Считайте, что это вызов 21 века, однако и к нему можно подобрать решение — если знать как.
Стандарты ISO / IEC 27001 предоставляют исчерпывающее описание целей, задач, элементов и ролей для обеспечения надежной системы информационной безопасности. Тем не менее, в этой лавине официальных инструкций менеджеру не найти практических советов о том, с чего начать создание информационной системы безопасности и что именно она должна включать.
Из моего более чем десятилетнего опыта ITSM консалтинга в корпорациях и небольших стартапах по всему миру я сформулировал свою концепцию того, из чего должна состоять из структура информационной безопасности.
1. Разработка политики и стратегии информационной безопасности
Обычно очень хочется пропустить эту, казалось бы, бюрократическую процедуру, утвердить ISO / IEC 27001 в компании и забыть о об этом. Тем не менее, сотрудники нуждаются в едином унифицированном документе, который будет определять четкие цели, задачи и отношение к информационной безопасности именно в этой компании. ISO / IEC 27001 следует использовать в качестве основы своей политики информационной безопасности, однако разработать её лучше самостоятельно, с учётом всех индивидуальных особенностей деятельности и устройства организации. Кстати, таким образом вы создадите дополнительную меру безопасности, что никогда не повредит.
2. Мониторинг
Внедрение автоматизированной системы мониторинга, производящая постоянные проверки на случай инцидентов, которые могут привести к нарушению безопасности. Для хорошего функционирования этой системы важно определить, какие именно данные и события должны быть определены системой мониторинга как сигнал об инциденте и какой инцидент, в свое очередь, считать настолько серьёзным, что стоит известить о нём службу безопасности.
Когда дело доходит до мониторинга, я рекомендую систему в стиле DevOps, а именно проактивный, а не реактивный мониторинг, обычно используемый в IT-индустрии. Проактивный мониторинг — это когда вы настраиваете систему таким образом, что она больше ищет нарушения безопасности, а не просто наблюдает за целостностью системы и оповещает в случае нарушения.
3. Ведение журнала инцидентов
Если организация большая и распределенная, то важно уметь видеть тенденции и тренды. Данные о случившихся инцидентах могут оказаться критически важными для информационной безопасности и здоровья организации, поэтому в каждый журнал инцидентов следует вносить следующие данные:
- Уникальный идентификационный номер
- Категория инцидента
- Дата и время записи
- Влияние инцидента
- Сведения о пользователе
- Описание симптомов
- Сведения о разрешении инцидента
- Дата и время закрытия тикета
4. Анализ журналов инцидентов и пост-анализ
Журналы инцидентов информационной безопасности — это не просто скопление данных; их необходимо проанализировать. Существуют различные виды анализа: распознавание паттерна, классификация событий и маркировка, корреляционный анализ и т. д.
После фиксирования нарушения информационной безопасности важно убедиться, что уроки извлечены. Создайте вопросник, чтобы выяснить, насколько эффективным было разрешение инцедента, и проведите интервью с сотрудниками службы поддержки и менеджерами, чтобы понять, что произошло и как избежать подобной ситуации в будущем.
5. База знаний
Проанализированные данные становятся знанием, которое нужно где-то хранить, и корпоративная база знаний — это прекрасное место для накопления всей ценной информации. Этот шаг может показаться ненужной бюрократией и тратой места для хранения, но это не так. Это знание окажется очень ценным, когда такая же или подобная ситуация случится в другой раз. Воспользовавшись уже опробованными практиками, вы справитесь со схожим инцидентом гораздо быстрей и с меньшими затратами человеческих усилий.
6. Менеджмент проблем
Постоянно возникающие инциденты, связанные с информационной безопасностью, всегда следует возводить в статус проблемы и назначать высокий приоритет. Мониторинг данных и анализ журнала инцидентов имеют жизненно важное значение для быстрого и качественного решения проблем, поэтому проводящие его IT-специалисты должны иметь доступ к базе знаний. Более того, решение таких проблем должно быть согласовано со стратегией корпоративной безопасности.
Поскольку информация является такой чувствительной областью, я бы настоятельно рекомендовал внедрить проактивное управление проблемами. Этот процесс основан на аналогичном принципе, как проактивный мониторинг, когда служба безопасности пытается предсказать и предотвратить проблему.
7. Управление рисками и уязвимостями
IT-инфраструктура обычно распределенная, сложная и состоит из множества устройств аппаратного и программного обеспечения. Ни один из не является неуязвимым, поэтому, чтобы предотвратить серьезные нарушения и защитить систему от частичного или полного отключения, лучше выделить время и ресурсы для управления рисками и уязвимостями.
Прежде всего, создайте регистр оценки рисков — соотношение уровня риска с бизнес необходимостью использования того или иного приложения или оборудования. Например, вы хотите ввести новое приложение в корпоративную экосистему. Если у приложения найдена незначительная лазейка в системе безопасности, команда и технический директор должны, руководствуясь установленным регистром оценки рисков, определить, насколько рационально его устанавливать. Аналогичная схема применяется к регулярной оценке уязвимости и оценки рисков уже установленных приложений и систем. И, конечно, эти проверки и оценки должны быть надлежащим образом задокументированы и сохранены в базе знаний.
