22 октября, понедельник 09:35
Bankir.Ru

Объявление

Свернуть
Пока нет объявлений.

Классификация инцидентов ИБ

Свернуть
X
  • Фильтр
  • Время
  • Показать
Очистить всё
новые сообщения

  • Классификация инцидентов ИБ

    Добрый день, коллеги!

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

    В связи с этим предлагаю попробовать создать такой общий классификатор инцидентов. Думаю всем будет полезно.
    Если же вдруг он есть, то подскажите где его можно взять.

  • #2
    )) ИМХО заранее проводить классификацию(составлять каталог инцидентов ИБ) - это значит изначально ограничить возможные инциденты)) а значит есть риск их потери(отказа от регистрации)- в случе если возникшего инцидента нет в "официальном" перечне(((.
    Моя позиция- регистрировать все нештатные(необычные) ситуации = а уж потом разбираться что это было - инцидент ИБ, инцидент ИТ, или просто "бред с бодуна" оператора)))))
    Мы продолжаем делать то, что мы уже много наделали

    Комментарий


    • #3
      George-on-Don, полностью согласна.
      Если пользователь не найдет в предложенном классификаторе аналога тому, что случилось у него, то СБ может вовремя не узнать об инциденте, который не был учет при составлении классификатора. А последствия могут быть самые разные.

      Комментарий


      • #4
        Есть проект ГОСТа Р ИСО/МЭК 18044, может помочь

        Комментарий


        • #5
          Сотрудники не регистрируют инциденты, а только указывают события ИБ, которые уже потом могут быть классифицированы сотрудниками отдела ИБ как инцидент.

          p.s. посмотрите представленные указанным мной ГОСТом типовые формы.

          Комментарий


          • #6
            Стандарт 18044 видел. И даже использовал его при написании политики.

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

            Комментарий


            • #7
              Если у тех. поддержки есть дежурный (диспетчер и т.п.), то обычно есть справочник (таблица), рассказывающий кому отправлять ту или иную проблему, с которой обратился пользователь.
              Имхо, ИБ логично встроиться в этот процесс, дополнив таблицу своими "событиями ИБ".

              Кстати, возникает интересная коллизия при использовании слова "инцидент", т.к. ИТ под этим понимает одно (ITIL, ITSM, 20000), а ИБ - другое (18044, 27000).

              Комментарий


              • #8
                Насчет встроиться в процесс техподдержки я согласен. Так вот у меня и возникает вопрос, чем дополнить таблицу (справочник) дежурного оператора техподдержки. Т.е. что мы считаем событием ИБ? Какие проблемы надо направлять в Службу ИБ?

                Т.е. все таки нужна некая классификация для дежурного оператора?

                Комментарий


                • #9
                  griboff возникает интересная коллизия при использовании слова "инцидент"

                  Это если пытаться объединить два процесса под одной крышей

                  Комментарий


                  • #10
                    Handy76 Т.е. что мы считаем событием ИБ?

                    Так событием или инцидентом? 18044 на это, кстати, отвечает.

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

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

                    ЗЫ. 18044, к сожалению, не связывает инциденты с более серьезными являениями, такими как кризис и катастрофа.

                    Комментарий


                    • #11
                      Если сообщают пользователи, то скорее всего событие, которое (или совокупность которых) может вылиться в инцидент.
                      Вопрос несколько в другом, нужно или нет делать классификатор этих событий(инцидентов)? Вот ниже предлагали встроиться в процесс техподдержки. Чтобы и они в том числе (или единолично) регистрировали эти события и инциденты. И было сказано, что у них есть некая таблица о чем и каким специалистам сигналить. Так вот в отношении событий (инцидентов) ИБ я так понимаю все таки нужна некая классификация, чтобы техподдержка знала о чем нужно сообщать в Службу ИБ? Или все таки не нужна? Тогда как они будут знать о чем надо просигналить в Службу ИБ?

                      Комментарий


                      • #12
                        Сообщение от Handy76 Посмотреть сообщение
                        Т.е. все таки нужна некая классификация для дежурного оператора?
                        Имхо, оператор должен знать, какие именно сообщения (из всех касающихся ИТ) нужно передавать в ИБ.
                        А у специалиста со стороны ИБ, обрабатывающего эти сообщения должна быть своя инструкция по классификации этих событий (с учетом других источников, например, информации с IDS), т.к. это влияет на приоритет, скорость обработки и т.п. Т.е. специалист ИБ принимает решение, является ли то или иное событие уже инцидентом.

                        Что именно считаем событием ИБ – берете свои документы по ИБ и смотрите, какие именно наблюдения и проблемы с ИТ для вас важны. Смотрите риски (если оценивались).
                        Оцениваете поток таких сообщений (разных видов), как с некоторыми из них справлялось ИТ. Определяете, необходимо ли еще и участие ИБ в обработке некоторых из них (или достаточно просмотра статистики по данным проблемам в системе обработки обращений польз.).

                        При обработке рисков вносите изменения как в таблицу оператора, так и в инструкцию ИБшника...

                        Комментарий


                        • #13
                          Сообщение от Алексей Лукацкий Посмотреть сообщение
                          Это если пытаться объединить два процесса под одной крышей
                          Оба процесса живут под крышей одной организации и хочется договориться об одних терминах, особенно в тех случаях, когда процессы пересекаются. Но к сожалению, это не всегда получается.

                          Комментарий


                          • #14
                            Сообщение от Алексей Лукацкий Посмотреть сообщение
                            ЗЫ. 18044, к сожалению, не связывает инциденты с более серьезными являениями, такими как кризис и катастрофа.
                            А здесь уже другой стандарт начинает работать - 25999.
                            Т.к. гармонизация стандартов медленно, но идет, есть вероятность, что такая связь появится в след. редакциях.

                            Комментарий


                            • #15
                              griboff А здесь уже другой стандарт начинает работать - 25999

                              Проще уж ITU-T E.409 применить

                              Комментарий


                              • #16
                                Сообщение от Алексей Лукацкий Посмотреть сообщение
                                Проще уж ITU-T E.409 применить
                                Алексей, спасибо за подсказку. ;-) Очень интересный документ. Давно не смотрел документы от ITU-T и зря :-)

                                P.S. В пункте 1.3 этой рекомендации в частности сказано, что группа реагирования должна использовать одну терминологию, чтобы избегать ошибочного понимания. "Осуществлять сотрудничество значительно легче, когда используется один и тот же "язык"" ;-)

                                Комментарий


                                • #17
                                  griboff Очень интересный документ. Давно не смотрел документы от ITU-T и зря

                                  Это точно ;-) У ITU-T огромное количество здравых документов по ИБ, которые часто проработаны лучше, чем у ISO. И многие на русский переведены.

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

                                  Опять же, если они работают под одной крышей того же Service Desk. А если они выстраивают процессы самостоятельно, то общая терминология им не так уж и нужна (хотя и желательна).

                                  Комментарий


                                  • #18
                                    Сообщение от George-on-Don Посмотреть сообщение
                                    )) ИМХО заранее проводить классификацию(составлять каталог инцидентов ИБ) - это значит изначально ограничить возможные инциденты)) а значит есть риск их потери(отказа от регистрации)- в случе если возникшего инцидента нет в "официальном" перечне(((
                                    А почему бы в перечень не добавить вариант "прочее"? С одной стороны, по большей части инцидентов будет произведена первичная классификация в соответствии с действующим на тот момент каталогом, в единичных случаях - начальное отнесение к пункту "прочее" с последующим дополнением и обновлением перечня...

                                    Комментарий

                                    Пользователи, просматривающие эту тему

                                    Свернуть

                                    Присутствует 1. Участников: 0, гостей: 1.

                                    Обработка...
                                    X