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

    Доброго дня, уважаемый хабрахабр!

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


    Информирование об инцидентах


    Перво наперво необходимо получить информацию об инциденте. Этот момент необходимо продумать ещё на этапе формирования политики безопасности и создания презентаций по ликбезу в ИБ для сотрудников.
    Основные источники информации:

    1. Helpdesk.
    Как правило (и это хорошая традиция) о любых неполадках, неисправностях или сбоях в работе оборудования звонят или пишут в хелпдеск вашей IT-службы. Поэтому необходимо заранее «встроиться» в бизнес-процесс хелпдеска и указать те виды инцидентов, с которыми заявку будут переводить в отдел информационной безопасности.

    2. Сообщения непосредственно от пользователей.
    Организуйте единую точку контакта, о чём сообщите в тренинге по ИБ для сотрудников. На данный момент отделы ИБ в организациях, как правило, не очень большие, зачастую из 1-2 человек. Поэтому будет несложно назначить ответственного за приём инцидентов, можно даже не заморачиваться с выделением адреса электропочты под нужды IS Helpdesk.

    3. Инциденты, обнаруженные сотрудниками ИБ.
    Тут всё просто, и никаких телодвижений для организации такого канала приёма не требуется.

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

    Категорирование инцидента


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

    1. Разглашение конфиденциальной или внутренней информации, либо угроза такого разглашения.
    Для этого необходимо иметь, как минимум, актуальный перечень конфиденциальной информации, рабочую систему грифования электронных и бумажных носителей. Хороший пример — шаблоны документов, практически на все случаи жизни, находящиеся на внутреннем портале организации или во внутренней файлопомойке, по умолчанию имеют проставленный гриф «Только для внутреннего использования».
    Немного уточню про угрозу разглашения, в предыдущем посте я описывал ситуацию, когда документ с грифом «Только для внутреннего использования» был вывешен в общем холле, смежным с другой организацией. Возможно, самого разглашения и не было (вывешено было после окончания рабочего дня, да и замечено было очень быстро), но факт угрозы разглашения — на лицо!

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

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

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

    5. Компрометация учетных записей.
    Этот пункт перекликается с 3. Фактически инцидент переходит из 3 в 5 категорию, если в ходе расследования инцидента выясняется, что пользователь в этот момент физически и фактически не мог использовать свои учётные данные.

    Классификация инцидента


    С этим пунктом в работе с инцидентами можно поступить 2-мя путями: простым и сложным.
    Простой путь: взять соглашение об уровне сервиса вашей IT-службы и подогнать под свои нужды.
    Сложный путь: на основе анализа рисков выделить группы инцидентов и/или активов, в отношении которых решение или устранение причин инцидента должны быть незамедлительными.
    Простой путь неплохо работает в небольших организациях, где не так уж и много закрытой информации и нет огромного количества сотрудников. Но стоит понимать, что IT-служба исходит в SLA из своих собственных рисков и статистики инцидентов. Вполне возможно, что зажевавший бумагу принтер на столе генерального директора будет иметь очень высокий приоритет, в том случае, как для вас важнее будет компрометация пароля администратора корпоративной БД.

    Сбор свидетельств инцидента


    Есть особенная прикладная наука — форензика, которая занимается вопросам криминалистики в области компьютерных преступлений. И есть замечательная книга Федотова Н.Н. «Форензика — компьютерная криминалистика». Я не буду сейчас расписывать детально аспекты форензики, просто выделю 2 основных момента в сохранении и предоставлении свидетельств, которых необходимо придерживаться.

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


    После устранения инцидента


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

    • переоценка рисков, повлекших возникновение инцидента
    • подготовка перечня защитных мер для минимизации выявленных рисков, в случае повторения инцидента
    • актуализация необходимых политик, регламентов, правил ИБ
    • провести обучение персонала организации, включая сотрудников IT, для повышения осведомленности в части ИБ

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

    Несколько советов


    1. Ведите журнал регистрации инцидентов, где записывайте время обнаружения, данные сотрудника, обнаружившего инцидент, категорию инцидента, затронутые активы, планируемое и фактическое время решения инцидента, а так же работы, проведенные для устранения инцидента и его последствий.
    2. Записывайте свои действия. Это необходимо в первую очередь для себя, для оптимизации процесса решения инцидента.
    3. Оповестите сотрудников о наличие инцидента, что бы во-первых они не мешали вам в расследовании, во-вторых исключили пользование затронутыми активами на время расследования.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 11

      0
      Обычно проблема возникает при анализе логов от кучи разных средств (маршрутизаторы, веб-серверы, ПО контроля целостности ФС и т.д.), которые пишут эти логи в самых разных форматах
        0
        Есть программы-аггрегаторы, они собирают информацию из логов, либо со своих агентов в системе и выдают единый отчёт.
          0
          Вот как раз для этого и нужны «аггрегаторы», упомянутые в статье. Обычно их называют SIEM, системы собирают логи, приводят их в читаемый вид, обеспечивают поиск и т.д. + к всему этому корреляция — сопоставление событий и действий пользователей для выявления потенциально опасных процессов и нарушений. Есть у многих производителей, McAfee ESM, HP ArcSight, Symantec (забыл как), IBM Qradar, Splunk.
            0
            Symantec SIM.
            На самом деле, использовать SIEM как логсервер это отвратительно. Для этого есть другие решения, например Logger у того же HP Arcsight. Основная задача SIEM это макрокорреляция.
              0
              Я считаю, что лог-менеджмент — это часть SIEM. Может быть такой модуль, может не быть, а может использоваться отдельно. Что отвратительного?
                0
                Поддержу!
                Аггрегация логов — это неотъемлемая часть функционала SIEM. Конечно использовать такой комбайн ради ограниченного функционала не комильфо, но и не отвратительно.
                  0
                  Лог-менеджмент — это не просто часть SIEM, это его фундамент. Я уточню, использовать SIEM только как логсервер — это отвратительная, бессмысленная трата денег и потенциала системы. Что печально, именно как логсервер и используют SIEM очень многие заказчики. Потратили 500К (а то и пару миллионов) на интеллектуальную, мощную систему, а могли за 80К купить Логгер с тем же успехом. А вся проблема в кадрах. Просто некому по-нормальному заниматься этими системами, мало кадров профессиональных, по крайней мере в России.
            0
            Есть ли смысл заносить успешно отраженные сетевые атаки на узлах сети в журнал инцидентов?
              0
              Смотря откуда: из интернета, думаю, не стоит, а вот если внутри сети, то стоит. Это как пример.
                0
                А если атаки из корпоративной сети, но из других регионов, не нашей подчиненности? И если их сотни на разные узлы? Бюрократия поглотит все рабочее время…
                  0
                  Вот-вот, это зависит от конфигурации каждой отдельной сети. Однозначного ответа нет.

            Only users with full accounts can post comments. Log in, please.