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

[marsen]

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

[ValentineS]

marsen
1. Всем раздаются противогазы и костюмы химзащиты.
2. Кому не досталось застрелиться.
3. Кто не смог сам - их застрелят те, кто остался в п.1

[marsen]

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

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

[Людмила Кулагина]

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

[malotavr]

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

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

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

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

[surfer]

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

[Людмила Кулагина]

Кстати, а что есть непредвиденные обстоятельства?
Засела писать такой план и поняла, что теряюсь.

[malotavr]

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

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

[box_roller]

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

[malotavr]

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

Не задавался таким вопросом. У нас BCP - часть работы IT risk manager'а

[box_roller]

Не задавался таким вопросом. У нас BCP - часть работы IT risk manager'а

Перефразирую )
Где заканчиваются угрозы по Доступности и начинается BCP?

[malotavr]

Понял

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

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

[box_roller]

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

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

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

[Людмила Кулагина]

Рискну вклииниться со своей дилетантской колокольни. Мне классификация малотавра кажется правильной.

[malotavr]

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

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

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

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

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

[box_roller]

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

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

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

[malotavr]

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

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

[box_roller]

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

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

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

[Hancock]

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

Unable to load requested url

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

[Sergey_V]

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

[surfer]

Да там ничего особенного.
Нарыл в инете. Типа этого
Неплохо расписано тутачки.

План действий в случае возникновения чрезвычайной ситуации

У меня название "План обеспечения непрерывной работы и восстановления работоспособности автоматизированных систем"
"Как ты яхту назовёшь..." (с) Капитан Врунгель.

[surfer]

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

[Mc`Sim]

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

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

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

[Алексей Чеканов]

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

[Myp3a]

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

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

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

[Para.Bellum]

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

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

[Hitch]

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

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

[smiant]

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

[nremezov]

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

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

[smiant]

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

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