![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Реагирование на инциденты информационной безопасности
July 25, 2014 Vladimir Bezmaly IT-Security
https://www.it-community.in.ua/2014/07/reagirovanie-na-intsidenty-informatsionnoj-bezopasnosti.html/
Сегодня большой популярностью пользуется тема реагирования на инциденты информационной безопасности (ИБ). С одной стороны – тема весьма популярна, с другой – она покрыта завесой тайны, ведь именно во время расследования проявляются конкретные уязвимости системы, обнаруживаются следы атак, проверяется квалификация сотрудников ИБ, качество построения системы ИБ.
Вместе с тем нельзя не отметить, что об инцидентах информационной безопасности компании стараются молчать, ведь никто не хочет признавать свои ошибки и давать тем самым дополнительные аргументы конкурентам. В результате – количество инцидентов непрерывно растет, а сведения о них, тем не менее, как правило, держатся в секрете, ведь мы узнаем лишь о тех немногочисленных инцидентах, информация о которых «просочилась» в прессу. Обратной стороной такой «прозрачности» является трудность при поиске специалистов по расследованию компьютерных инцидентов или по созданию в компании процесса реагирования на инциденты. По вполне понятным причинам исполнитель не может представить отзывы своих клиентов о выполненной работе. Вместе с тем стоит подчеркнуть, что выполнение таких работ требует высочайшего доверия между исполнителем и заказчиком.
Попробуем кратко перечислить, что же требуется от специалиста подобного рода:
На Украине существует целый ряд серьезнейших проблем в этой области:
За рубежом, в свою очередь, существуют стандарты, которые описывают процесс реагирования на компьютерные инциденты. В первую очередь это стандарт NIST Special Publication 800-61 “Computer security incident handling guide”. К слову, новая версия ISO 17799:2005 требует наличия процесса реагирования на инциденты (раздел 13 – “Information security incident management”).
Попробуем коротко рассмотреть основные составляющие процесса реагирования на инцидент.
Что такое инцидент ИБ?
Инцидент, согласно требований IT Infrastructure Library (ITIL), – любое событие, не являющееся частью нормальной работы услуги и ведущее или способное привести к остановке или потере уровня качества этой услуги.
Согласно ISO/IEC TR 18044:2004 инцидент информационной безопасности (information security incident): одно или серия нежелательных или неожиданных событий информационной безопасности, которые имеют значительную вероятность компрометации бизнес-операции и угрожают информационной безопасности.
Основной целью процесса управления инцидентами (Incident Management) является восстановление нормальной работы ИТ-услуги как можно быстрее и минимизация неблагоприятного воздействия сбоя на работу отделов предприятия, что обеспечит согласованный уровень качества услуги.
Организация процесса реагирования на инцидент преследует следующие цели:
Примеры инцидентов
Возможные нарушения требований конфиденциальности:
Возможные нарушения требований целостности:
Возможные нарушения требований доступности:
Обзор общепризнанных практик по управлению инцидентами
На сегодняшний день разработано достаточное количество организационных документов, в которых описаны вопросы управления инцидентами ИБ.
Так, подобные вопросы описаны в:
В рамках данного обзора невозможно рассмотреть все имеющиеся рекомендации по управлению инцидентами, и вполне вероятно, что наиболее эффективным для конкретной организации будет использование какой-либо другой методологии, в том числе и разработанной самостоятельно. Но на наш взгляд любая используемая методология должна быть совместима с основными современными стандартами систем управления, такими как ISO/IEC 27001 и ISO 20000.
Реагирование на инциденты ИБ – весьма сложный процесс, который требует участия сотрудников многих подразделений компании таких как:
Многие компании сейчас создают комиссию по расследованию инцидентов ИБ (Computer Security Incident Response Team – CSIRT), в которую включаются специалисты по решению юридических и технических вопросов.
Далее: Основные этапы процесса реагирования на инцидент
July 25, 2014 Vladimir Bezmaly IT-Security
https://www.it-community.in.ua/2014/07/reagirovanie-na-intsidenty-informatsionnoj-bezopasnosti.html/
Сегодня большой популярностью пользуется тема реагирования на инциденты информационной безопасности (ИБ). С одной стороны – тема весьма популярна, с другой – она покрыта завесой тайны, ведь именно во время расследования проявляются конкретные уязвимости системы, обнаруживаются следы атак, проверяется квалификация сотрудников ИБ, качество построения системы ИБ.
Вместе с тем нельзя не отметить, что об инцидентах информационной безопасности компании стараются молчать, ведь никто не хочет признавать свои ошибки и давать тем самым дополнительные аргументы конкурентам. В результате – количество инцидентов непрерывно растет, а сведения о них, тем не менее, как правило, держатся в секрете, ведь мы узнаем лишь о тех немногочисленных инцидентах, информация о которых «просочилась» в прессу. Обратной стороной такой «прозрачности» является трудность при поиске специалистов по расследованию компьютерных инцидентов или по созданию в компании процесса реагирования на инциденты. По вполне понятным причинам исполнитель не может представить отзывы своих клиентов о выполненной работе. Вместе с тем стоит подчеркнуть, что выполнение таких работ требует высочайшего доверия между исполнителем и заказчиком.
Попробуем кратко перечислить, что же требуется от специалиста подобного рода:
- понимание принципов безопасности;
- знания о слабостях и уязвимостях информационных объектов;
- представление об устройстве Интернет;
- навыки анализа информационных рисков;
- знание сетевых протоколов;
- знание сетевых приложений и сервисов;
- владение вопросами сетевой безопасности;
- владение вопросами безопасности узла или системы;
- знание о вредоносных программах (вирусы, черви, трояны);
- навыки программирования.
На Украине существует целый ряд серьезнейших проблем в этой области:
- нет единого центра регистрации инцидентов;
- отсутствует статистика инцидентов;
- отстает законодательство;
- нет открытых методик и стандартов организации процесса реагирования и расследования инцидентов ИБ;
- неясно, как можно подготовиться к такого рода событиям;
- не определено, какие превентивные меры стоит предпринять;
- отстает подготовка сотрудников правоохранительных органов.
За рубежом, в свою очередь, существуют стандарты, которые описывают процесс реагирования на компьютерные инциденты. В первую очередь это стандарт NIST Special Publication 800-61 “Computer security incident handling guide”. К слову, новая версия ISO 17799:2005 требует наличия процесса реагирования на инциденты (раздел 13 – “Information security incident management”).
Попробуем коротко рассмотреть основные составляющие процесса реагирования на инцидент.
Что такое инцидент ИБ?
Инцидент, согласно требований IT Infrastructure Library (ITIL), – любое событие, не являющееся частью нормальной работы услуги и ведущее или способное привести к остановке или потере уровня качества этой услуги.
Согласно ISO/IEC TR 18044:2004 инцидент информационной безопасности (information security incident): одно или серия нежелательных или неожиданных событий информационной безопасности, которые имеют значительную вероятность компрометации бизнес-операции и угрожают информационной безопасности.
Основной целью процесса управления инцидентами (Incident Management) является восстановление нормальной работы ИТ-услуги как можно быстрее и минимизация неблагоприятного воздействия сбоя на работу отделов предприятия, что обеспечит согласованный уровень качества услуги.
Организация процесса реагирования на инцидент преследует следующие цели:
- Подтвердить или опровергнуть факт инцидента;
- Предупредить нескоординированные действия служб при устранении последствий инцидента;
- При возникновении инцидента восстановить работоспособность компании в кратчайшие сроки;
- Представить детализированный отчет о произошедшем инциденте;
- Представить полезные рекомендации по недопущению подобных инцидентов в дальнейшем;
- Создать условия для накопления в базе данных точной информации об инцидентах и путях устранения последствий;
- Обеспечить быстрейшее обнаружение (предупреждение) инцидентов в дальнейшем путем совершенствования политики ИБ, модернизации системы ИБ и т.д.);
- Обеспечить целостность доказательств произошедшего инцидента;
- Создать условия для возбуждения уголовного дела против злоумышленников;
- Минимизировать последствия инцидента;
- Защитить репутацию компании;
- Провести обучение сотрудников компании процессу реагирования на инцидент.
Примеры инцидентов
Возможные нарушения требований конфиденциальности:
- Инциденты, из-за которых получен несанкционированный доступ к информации;
- Утеря носителей информации за пределами помещения;
- Утеря или кража ноутбука;
- Попытки персонала организации получить доступ выше имеющегося уровня;
- Попытки изнутри или снаружи получить доступ к системам (взлом).
Возможные нарушения требований целостности:
- Потеря данных или незавершенные транзакции;
- Вирусы, «троянские кони» (вредоносное программное обеспечение);
- Поврежденные сектора на жестких дисках, ошибки четности и памяти;
- Неверные контрольные суммы или значения хеш-функций.
Возможные нарушения требований доступности:
- Простои в работе в течение неприемлемого периода времени. Если простой длится дольше, чем оговорено в Соглашении об Уровне Услуг и не может быть устранен в течении определенного времени, вступает в силу чрезвычайный план;
- Вирусы, «Троянские кони»;
- Кража ноутбуков, комплектующих или носителей информации.
Обзор общепризнанных практик по управлению инцидентами
На сегодняшний день разработано достаточное количество организационных документов, в которых описаны вопросы управления инцидентами ИБ.
Так, подобные вопросы описаны в:
- ISO/IEC 27001:2005 Information security management system. Requirements. В данном документе выдвигаются общие требования к построению системы управления информационной безопасности, относящиеся в том числе и к процессам управления инцидентами.
- ISO/IEC TR 18044 Information security incident management. Данный документ описывает инфраструктуру управления инцидентами в рамках циклической модели PDCA. Даются подробные спецификации для стадий планирования, эксплуатации, анализа и улучшения процесса. Рассматриваются вопросы обеспечения нормативно-распорядительной документацией, ресурсами, даются подробные рекомендации по необходимым процедурам.
- CMU/SEI-2004-TR-015 Defining incident management processes for CISRT. Этот документ описывает методологию планирования, внедрения, оценки и улучшения процессов управления инцидентами. Основной упор делается на организации работы CISRT (Critical Incident Stress Response Team) — группы или подразделения, обеспечивающего сервис и поддержку предотвращения, обработки и реагирования на инциденты информационной безопасности. Вводится ряд критериев, на основании которых можно оценивать эффективность данных сервисов, приводятся подробные процессные карты.
- NIST SP 800-61 Computer security incident handling guide. Здесь представлен сборник “лучших практик” по построению процессов управления инцидентами и реагирования на них. Подробно разбираются вопросы реагирования на разные типы угроз, такие как распространение вредоносного программного обеспечения, несанкционированный доступ и другие.
В рамках данного обзора невозможно рассмотреть все имеющиеся рекомендации по управлению инцидентами, и вполне вероятно, что наиболее эффективным для конкретной организации будет использование какой-либо другой методологии, в том числе и разработанной самостоятельно. Но на наш взгляд любая используемая методология должна быть совместима с основными современными стандартами систем управления, такими как ISO/IEC 27001 и ISO 20000.
Реагирование на инциденты ИБ – весьма сложный процесс, который требует участия сотрудников многих подразделений компании таких как:
- Служба ИТ;
- Служба ИБ;
- Отдел кадров;
- Юридическая служба;
- Служба безопасности;
- Бизнес-менеджеры;
- Служба по связям с общественностью и т.д.
Многие компании сейчас создают комиссию по расследованию инцидентов ИБ (Computer Security Incident Response Team – CSIRT), в которую включаются специалисты по решению юридических и технических вопросов.
Далее: Основные этапы процесса реагирования на инцидент