Планирование реагирования на инциденты требует постоянного тестирования

Планирование реагирования на инциденты требует постоянного тестирования Информационная безопасность, Взлом, IT

anti-malware.ru

Джек Чепмен, вице-президент по анализу угроз компании Egress, рассказывает на портале ComputerWeekly о том, что входит в состав хорошего плана реагирования на инциденты и какие шаги должны предпринять специалисты по безопасности, чтобы должным образом подготовиться к практически неизбежной атаке и добиться поддержки со стороны руководства организации.

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

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

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

План реагирования на инциденты должен быть надежным и учитывать приоритеты бизнеса: не все системы одинаково важны, поэтому важно знать, какие системы необходимо защитить и восстановить раньше других.

План должен охватывать все объекты, уделяя особое внимание взаимосвязанным системам. И помните, что системы, на которые вы полагаетесь для реализации плана, тоже могут выйти из строя!

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

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

Владелец также должен отслеживать прогресс и, в конечном счете, отмечать подводные камни, чтобы совершенствовать план для будущих инцидентов.

После инцидента необходимо уделить время анализу того, что получилось, а что нет, — это очень важно и требует строгого подхода; нет смысла иметь план, который не развивается в соответствии с постоянно меняющимися инцидентами.

Источник