IT-безопасность: стоит ли рисковать корпорацией?
Шрифт:
Придерживайтесь плана действий
Главная цель заблаговременного написания процедур реагирования на инцидент состоит в том, что вы (или ваши сотрудники) можете реагировать немедленно и не раздумывая. Не пытайтесь как-либо истолковывать план — просто выполняйте его!
Записывайте все!
Как только возникнут подозрения, что система подвергается атаке, крайне важно получать об этом информацию. Сделайте «моментальный снимок» системы. Любая собранная вами информация имеет ценность для расследования и может оказаться решающей для установления источника атаки и привлечения взломщика к ответственности.
При
Эскалация — это привлечение к решению проблемы вышестоящего руководства [8] В процедуре реагирования на инцидент должно быть указано, при каких обстоятельствах нужно прибегать к эскалации — как внутренней, так и внешней.
Внутренняя эскалация — это передача проблемы на более высокий уровень руководства внутри компании. Она требуется, когда масштаб взлома выходит за пределы знаний, имеющихся у группы обслуживания. Внешняя эскалация заключается в вызове эксперта со стороны, и к ней прибегают, когда инцидент слишком сложен для сотрудников компании.
8
или дополнительных сил. — Примеч. пер.
Также важно иметь в плане способ эскалации в условиях конфликта интересов. Он необходим, если под подозрение попадает кто-нибудь из группы обслуживания. (В случае с First Fidelity главный подозреваемый входил в группу безопасности. Эскалация при конфликте интересов могла бы разрядить стрессовую ситуацию и последующие проблемы с персоналом.)
Создайте надежную систему отчетов
Разумным будет создание механизма составления отчета обо всех вторжениях, даже тех, которые не причинили системе какого-либо очевидного вреда. Отчеты о взломах дают общую картину состояния безопасности сети. Они также помогают обнаружить участки в вашей сети, представляющие угрозу ее безопасности.
Завершающие действия
После взлома вы должны провести оценку случившегося. Следовал ли ваш персонал намеченным целям и приоритетам? Какие уроки вы извлекли? Что бы вы хотели в дальнейшем сделать по-другому? Возвращены ли ваши системы в безопасное состояние и не осталось ли «черного хода»?
После любого инцидента, связанного с безопасностью, проделайте следующее.
Просмотрите ваши политики и процедуры
Тщательно изучите надежность работы ваших процедур и примите решение, нужно ли их изменить на будущее.
Представьте отчет по инциденту (и как вы действовали в нем) руководству
Если вы сами являетесь руководителем, то потребуйте, чтобы обо всех инцидентах вам были представлены отчеты. Стандартная процедура составления отчета по любому и каждому взлому заключается в создании всеохватывающей картины состояния безопасности сети. Если из отчетов будет видно, что взломы приобретают хронический характер или их частота увеличивается, то, очевидно, нужно совершенствовать или усиливать меры безопасности. По протоколам отчетов также можно установить участки вашей сети, на которые нацеливаются взломщики для получения информации (например, стараются получить исходный код проектируемого вами нового чипа).
По-новому взгляните на ваш бюджет
На бумаге все любят безопасность. Но когда речь заходит о вложении средств, то расходы на планирование и осуществление мер безопасности часто урезаются. «Так как с бюджетом в этом квартале имеются трудности, то руководство говорит, что нужно подождать с расходами на реагирование на инциденты». За этим последует конец года, и процедуры все еще останутся ненаписанными.
Важность безопасности легко забывается. Лишь на некоторое время после самых значительных из взломов какая-нибудь несчастная компания оказывается в фокусе передач «60 минут» или CNN. Все вдруг сразу беспокоятся о мерах безопасности и о том, чтобы такое не произошло с ними. Затем в телестудиях гаснет свет, шум в прессе затихает, а хакер отправляется за решетку или исчезает в киберпространстве. Интерес к безопасности пропадает, и руководство снова не хочет включать ее в бюджет.
Маркус Ранум (Marcus Ranum), часто упоминающийся как отец брандмауэров, однажды сказал: «Когда дело доходит до безопасности, то нужно, чтобы парень, стоящий рядом с вами, получил пулю в голову прежде, чем руководство обратит внимание на безопасность». Если вы руководитель, отвечающий за безопасность, то не занимайте позицию «ожидания пули» в этих вопросах. Ведь на самом деле стоимость восстановления после серьезного взлома значительно превосходит расходы на установку защиты. Для уменьшения этой стоимости до минимума в будущем убедитесь, что в бюджет включено финансирование требуемой безопасности.
Контрольный список
Используйте этот список для определения готовности вашей компании реагировать на взлом. Можете ли вы поставить «Да» напротив каждого пункта?
— Есть ли у вас процедуры реагирования на инцидент?
— Понятны ли эти процедуры и отвечают ли они современным требованиям?
— Обучены ли все ответственные сотрудники использованию этих процедур?
— Есть ли в процедурах инструкции по контакту с экспертами по безопасности 24 часа в сутки и 7 дней в неделю?
— Предусмотрена ли процедура эскалации проблемы на вышестоящий уровень, если не удается связаться с экспертом по безопасности?
— Есть ли процедура, определяющая, когда обращаться за внешней помощью и к кому?
— Предусмотрено ли в процедурах немедленное уведомление руководителя информационной службы при возникновении вторжения и после его отражения?
— Выделено ли достаточно средств на разработку и поддержание реагирования на инциденты, связанные со взломом?
— Действительно ли ответственные сотрудники посещают все требуемые занятия?
— Проводятся ли личные проверки ответственного персонала?
— Все ли гладко во взаимоотношениях между системными администраторами и группами обеспечения безопасности?
— Имеются ли планы восстановления системы после инцидента?
— Надлежащим ли образом контролируются меры безопасности в системах? («Надлежащим» здесь означает, что такая оценка дана реальной аудиторской проверкой.)
— Включены ли контрольные журналы систем?
— Просматриваются ли периодически журналы регистрации в системах?
— Установлены и работают ли необходимые инструменты по обнаружению вторжения?
— Установлены ли в вашей сети программы-детекторы, обнаруживающие «неизвестные» атаки?
— Можете ли вы обнаружить и предотвратить атаки как на сеть, так и на хост-компьютер (многоуровневый подход к обнаружению)?
— Легко ли отслеживается путь атаки в вашей сети?
Заключительные слова
Статистика, которую ведет CERT, показывает, что количество нарушений безопасности более чем удваивается каждый год. По данной статистике, число инцидентов возросло с 3934 в 1998 году до 9859 в 1999 году, а затем до 211 7569 в 2000 году и до 52 658 в 2001 году. Только за первый квартал 2002 года было зарегистрировано еще 26 829 инцидентов. Пугает то, что о многих нарушениях не было сообщений, так как их не удалось обнаружить. В то время как 38 % респондентов, участвующих в опросе CSI 2002 года, сообщили о неавторизованном использовании своих веб-сайтов в прошедшем году, 21 % других респондентов честно признались, что не знают, были ли взломаны их сайты или нет.