24 сентября, понедельник 23:15
Bankir.Ru

Объявление

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

Документ: "План действий на случай непредвиденных обстоятельств"

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

  • Документ: "План действий на случай непредвиденных обстоятельств"

    Очень нужен документ под названием "План действий на случай непредвиденных обстоятельств с использованием дублирующих систем и устройств", в котором были бы прописаны действия не только отдела автоматизации, но и других отделов.
    Если у кого-нибудь есть что-то подобное, пришлите пжалста на B-mail.

  • #2
    marsen
    1. Всем раздаются противогазы и костюмы химзащиты.
    2. Кому не досталось застрелиться.
    3. Кто не смог сам - их застрелят те, кто остался в п.1
    Наша жизнь состоит из цитат. Лишь немногим удается написать что-то своё. (с)

    Комментарий


    • #3
      По поводу "Плана действий на случай непредвиденных обстоятельств с использованием дублирующих систем и устройств" нас уже достали проверяющие, что он должен быть. А что в других банках такого докУмента нет и никто его не требует?

      Нужна "рыбка", а под наши условия мы и сами потом допишем.

      Комментарий


      • #4
        marsen, да тут особой рыбы и нет. Нужно писать как есть. Вы и ваши пользователи знают, что делать, если отрубится сервак, а рейс нужно, кровь из носу, отправить?
        Чем больше связей, тем меньше степеней свободы.

        Комментарий


        • #5
          Сообщение от marsen Посмотреть сообщение
          По поводу "Плана действий на случай непредвиденных обстоятельств с использованием дублирующих систем и устройств" нас уже достали проверяющие, что он должен быть. А что в других банках такого докУмента нет и никто его не требует?

          Нужна "рыбка", а под наши условия мы и сами потом допишем.
          А что вы над человеком издеваетесь? По-человечески документ называется "Business continuity and disaster recovery plan". Он действительено включает в себя не только действия айтишников, но и, например, миграцию ключевых сотрудников фронт-офиса и бэк-офиса из разрушенного/сгоревшего/обесточенного/обыскиваемого здания на резервную площадку.

          Рыбу дать не могу - еще даже не приступал к его разработке.

          Комментарий


          • #6
            У нас в банке есть "План действий на случай непредвиденных обстоятельств..." но образца 2004 года и ТАКАЯ МУТЬ... Сам хочу переделать.
            Тут http://hghltd.yandex.net/yandbtm?url...=0&sg=47&isu=1
            есть кое-какие наработки по содержанию...
            Удачи!

            Комментарий


            • #7
              Кстати, а что есть непредвиденные обстоятельства?
              Засела писать такой план и поняла, что теряюсь.
              Чем больше связей, тем меньше степеней свободы.

              Комментарий


              • #8
                Обычно это называется Business continuity Plan.

                Банк должен быть готов возобновить свою деятельность в случае любых ЧП, вплоть до "вооруженного конфликта с применением ядерного оружия". Суть BCP - в банке должен быть организован процесс, при котором мониторится ситуация и придумываются различные ЧП, которые могут остановить бизнес. В рамках этого процесса разрабатывается и постоянно обновляется план действий на случаей придуманных ЧП. Сходу вы это не напишите, это одна из самых сложных частей ИБ.
                Последний раз редактировалось malotavr; 14.02.2008, 14:02.

                Комментарий


                • #9
                  to malotavr
                  Где кончается ИБ и начинается управление непрерывностью бизнеса?

                  Комментарий


                  • #10
                    Сообщение от box_roller Посмотреть сообщение
                    to malotavr
                    Где кончается ИБ и начинается управление непрерывностью бизнеса?
                    Не задавался таким вопросом. У нас BCP - часть работы IT risk manager'а

                    Комментарий


                    • #11
                      Сообщение от malotavr Посмотреть сообщение
                      Не задавался таким вопросом. У нас BCP - часть работы IT risk manager'а
                      Перефразирую )
                      Где заканчиваются угрозы по Доступности и начинается BCP?

                      Комментарий


                      • #12
                        Понял

                        Я отношу угрозу в область действия BCP, если выполнены два условия:
                        1. Угроза выхвана "обстоятельством непреодолимой силы"
                        2. Угроза парализует работу всего банка

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

                        Комментарий


                        • #13
                          to malotavr
                          А важно ли, чем вызваны обстоятельства, приведшие к парализации работы всего банка?

                          имхо
                          1.Прерывание основных бизнес процессов на более ХХХ часов/дней.

                          Все что ниже выбранной величины – угроза ИБ по Доступности, что выше – в BCP.
                          Как только правильно выбрать ХХХ ? Экспертная оценка?

                          Комментарий


                          • #14
                            Рискну вклииниться со своей дилетантской колокольни. Мне классификация малотавра кажется правильной.
                            Чем больше связей, тем меньше степеней свободы.

                            Комментарий


                            • #15
                              Сообщение от box_roller Посмотреть сообщение
                              to malotavr
                              А важно ли, чем вызваны обстоятельства, приведшие к парализации работы всего банка?

                              имхо
                              1.Прерывание основных бизнес процессов на более ХХХ часов/дней.

                              Все что ниже выбранной величины – угроза ИБ по Доступности, что выше – в BCP.
                              Как только правильно выбрать ХХХ ? Экспертная оценка?
                              Угрозы вида "Прерывание основных бизнес процессов на более ХХХ часов/дней" можно поделить на две класса:
                              1. Угрозы, последствия которых можно устранить силами одних айтишников.
                              2. Угрозы, последствия которых можно устранить только согласованными действиями нескольких отделов.

                              BCP нужен только для угроз второго класса. Т

                              Комментарий


                              • #16
                                to malotavr
                                Непонимаю, отчего такое внимание айтишникам? Есть виды бизнеса, где которых IT не обслуживают основные бизнес процессы.
                                Согласованность действий - да. Это приоритет. Для этого BCP и пишется.
                                Согласованность действий нескольких отделов - не более чем частный случай.

                                И какая разница бизнесу, кто и как будет востанавливать его работоспособность. В Непрерывности - критично время. И Планы составляются исходя из времени востановления. Остальное вторично.

                                Впрочем, возможно существует иная трактовка понятия Непрерывности? Я в своих утверждениях опираюсь на идеологию описанную в BS 25999-1 , которая, на мой взгляд, не противоречит, а дополняет iso27001/iso17799.

                                Комментарий


                                • #17
                                  Айтишники тут при том, что без резервной ИТ-инфраструктуры
                                  не удастся восстановаить деятельность никаких бизнес-процессов. По крайней мере, в нашем случае. Поэтому BCP у нас занимается IT risk manager. Остальные в этом процессе участвуют, но это участие ограничивается выставлением требований - что конкретно этому подразделению нужно от резервной инфраструктуры.

                                  То есть выглядит это так. Департамент А говорить: в случае пожара мне нужно мрочно развернуть резервные рабочие места вот для таких сотрудников. Зная, с какой инфой работает департамнт А, IT risk manager определяет, какие сервера нужно реплицировать в резервный центр, какая поддержка потребуется на месте и т.д. и т.п. В итоге на айтишниках лежит основная нагрузка при планировании и при развертывании.

                                  Комментарий


                                  • #18
                                    malotavr
                                    Я пишу о принципиальных вещах, а вы перечисляете частные случаи.

                                    Когда мы принимаем решение об области действия BCP, то руководствоваться нужно глобальными правилами, а не их частными трактовками. Это моё мнение.
                                    Иначе может произойти неприятное

                                    И как пример: По BCP была выбрана резервная площадка и т.д. Когда на неё перебазировались и развернулись, то оказалось что мощности электроэнергии не хватает для всего оборудования. География площадки оказалось такая, что прокладка дополнительного кабеля заняла пару месяцев. Дизеля, разумеется, никто не планировал. В нужный срок площадка не заработала. Главным оказался электрик (а не айтишник), мнением которого при составлении BCP не интересовались.

                                    Комментарий


                                    • #19
                                      Сообщение от surfer Посмотреть сообщение
                                      У нас в банке есть "План действий на случай непредвиденных обстоятельств..." но образца 2004 года и ТАКАЯ МУТЬ... Сам хочу переделать.
                                      Тут http://hghltd.yandex.net/yandbtm?url...=0&sg=47&isu=1
                                      есть кое-какие наработки по содержанию...
                                      Удачи!

                                      Unable to load requested url

                                      Вы не могли бы продублировать?

                                      Комментарий


                                      • #20
                                        Кстати, господа, вам не кажется термин "непредвиденные обстоятельства" немного неподходящим? Если мы о некоторых обстоятельствах думаем и даже пишем что делать при их возникновении, то называть их "непредвиденными" как-то странно
                                        Мы придумали более подходящее название: "План действий в случае возникновения чрезвычайной ситуации"

                                        Комментарий


                                        • #21
                                          Да там ничего особенного.
                                          Нарыл в инете. Типа этого
                                          Неплохо расписано тутачки.
                                          План действий в случае возникновения чрезвычайной ситуации
                                          У меня название "План обеспечения непрерывной работы и восстановления работоспособности автоматизированных систем"
                                          "Как ты яхту назовёшь..." (с) Капитан Врунгель.

                                          Комментарий


                                          • #22
                                            Тут ещё "Руководство по составлению Плана действий для Отдела Информационных технологий" и "Обеспечение непрерывности деятельности организации в нештатных ситуациях" образца 2003 года. Актуальности не потеряли.

                                            Комментарий


                                            • #23
                                              вставлю свои 5 копеек.
                                              Во времена былинные, когда звери еще разговаривали, а я работал на Форде, вся эта тема (по моим ощущениям) делилась на 2 большие части:
                                              1. небольшие ЧП. DRP - Disaster Recovery Plan, план восстановления в случае сбоя. Пример - сдох какой-то PC на линии - открываешь соответствующий DRP, там по пунктам - что делать(в том числе и кого информировать ДО и кого информировать ПОСЛЕ), где лежит бэкап, какие настройки после разворачивания бэкапа, где какие пароли. План написан с расчетом, что даже если взявший в руки его ни разу не читал до этого - систему он восстановит. Не до дебилизма, но подробно. План ОБЯЗАТЕЛЬНО тестируется не менее раза в год. План не только ИТ-шный, но и у других обслуживающих подразделений.
                                              2. глобальные ЧП. BCP - Business Сontinuity Plan. Вот тут все круто - если сломалось ВСЕ или что-то ОЧЕНЬ важное и надолго. Тут и запасная удаленная площадка, и кто как и кого перевозит, кто и как восстанавливает информационную систему "на природе" и т.д. Опять-же, в "мини-масштабе" учения должны проводится регулярно.

                                              понятное дело - DRP написать просто. И протестировать несложно.
                                              с BCP все сложнее.

                                              я у себя пошел по пути "не можешь сделать всё - сделай хоть что нибудь" - ИТ-шники пишут и тестируют DRP. Даже здесь всплывает масса недочетов.
                                              До BCP, думаю, дорастем нескоро.
                                              Я словно лист на ветру, посмотри как я лечу...

                                              Комментарий


                                              • #24
                                                Ну, добавлю и я свои пару пенсов
                                                1. Кроме ссылок, приведенных коллегами (местами, кстати, весьма неплохих), есть еще два реально полезных стандарта - BS25777 про непрерывность ИКТ, и BS25999 (в двух частях) за непрерывность бизнеса вообще. Там есть много полезных советов и про содержание плана, и про поддерживающий его фреймворк.
                                                2. Реальные проблемы начинаются, когда планов становится много, и они захватывают разные подразделения. Проблемы начинаются с с актуализацией планов, одновременностью актуализации, распространением последних версий, взаимосвязью между планами и т.п. Если интересно - могу рассказать подробнее, с чем чаще всего приходится бороться и как бороться.

                                                Комментарий


                                                • #25
                                                  Mc`Sim
                                                  Однако по моим ощущениям с BCP/DRP все как раз с точностью до наоборот:

                                                  1. Огромные ЧП - катастрофы, когда все рухнуло и мы восстанавливаемся из руин на основной или резервной площадке, обслуживает тема DRP - Disaster Recovery Plan, план восстановления в случае катастрофы. Очевидно, что тут не может быть никакой непрерывности - происходит восстановление после прерывания.

                                                  2. Локальные ЧП - аварии, уже выходящие за рамки обычных "штатных" ожидаемых эксплуатационных проблем с оборудованием - это BCP - Business Сontinuity Plan (У американцев встречается термин СР Contingency Planning - аварийное планирование).
                                                  В этом случае непрерывность бизнеса обеспечивается запланированным комплексом мероприятий.

                                                  Комментарий


                                                  • #26
                                                    одно из самых интересных планирований, которым доводилось руководить, было на случай вспышки эпидемии (во времена паранойи с птичьим гриппом), и это в учреждении, у которого филиалы в Юго-Восточной Азии и народ летает по кругу Китай-Гонконг-Сингапур-Куала-Лумпур регулярно

                                                    очень нетривиально получается, сложнее, чем когда Сайт А разбомблен, а в датацентре Б вырубилось электричество ..пошла копанина с сохранение склетной функциональности регионов, HQ и отдельных ключевых служб при невозможности физического контакта между сотрудниками ..
                                                    Последний раз редактировалось Para.Bellum; 17.02.2009, 14:17.

                                                    Комментарий


                                                    • #27
                                                      До кучи хотелось бы упомянуть список угроз, подготовленный BSI:

                                                      http://www.bsi.de/english/gshb/manual/t/t01.htm

                                                      Комментарий


                                                      • #28
                                                        Доброго времени суток! У меня при написании Плана возникла такая проблема. Согласно BS 25999 прежде чем писать План, нужно провести BIA, в котором указать целевое время восстановления, целевую точку восстановления и ранжировать сервисы по критичности. Это не вызвало затруднений. Однако сервисы включают в себя различные конфигурационные единицы (КЕ), такие как ПО, СУБД, БД, серверы, другие сервисы и т.д. Вопрос в следующем: по каким критериям классифицировать КЕ, чтобы в случае повреждения в сервисе нескольких КЕ (или в худщем случае всех КЕ), было ясно, какую КЕ восстанавливать первой, второй и т.д.

                                                        Комментарий


                                                        • #29
                                                          Сообщение от smiant Посмотреть сообщение
                                                          Вопрос в следующем: по каким критериям классифицировать КЕ, чтобы в случае повреждения в сервисе нескольких КЕ (или в худщем случае всех КЕ), было ясно, какую КЕ восстанавливать первой, второй и т.д.
                                                          Пара мыслей:
                                                          1) В первую очередь надо восстанавливать те КЕ, которые поддерживают более критичные сервисы
                                                          2) В первую очередь надо восстанивливать те КЕ без которых сервис точно никак не сможет работать
                                                          3) Восстанавливать те КЕ, от работы которых зависит работа других КЕ, поддерживаюищих сервис.
                                                          4) Восстанливать в первую очередь те КЕ, которые будет тяжелее (дороже и т.п) восстановить потом.

                                                          Комментарий


                                                          • #30
                                                            Пара мыслей:
                                                            1) В первую очередь надо восстанавливать те КЕ, которые поддерживают более критичные сервисы
                                                            2) В первую очередь надо восстанивливать те КЕ без которых сервис точно никак не сможет работать
                                                            3) Восстанавливать те КЕ, от работы которых зависит работа других КЕ, поддерживаюищих сервис.
                                                            4) Восстанливать в первую очередь те КЕ, которые будет тяжелее (дороже и т.п) восстановить потом.


                                                            Спасибо большое! Но хотелось бы увидеть конкретные методики. Просто когда начинаешь изучать сервис и его КЕ возникает много проблем. Как оценить тяжесть восстановления? Это может быть RTO, количество необходимых специалистов или материальные издержки. Но учесть все эти параметры очень сложно. Также почти все КЕ как-то взаимосвязаны. Тогда как их приоритезировать тоже непонятно. Если у кого-нибудь ещё какие-то предложения или мысли? Буду очень рад услышать!

                                                            Комментарий

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

                                                            Свернуть

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

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