Страница:
использоваться, если они есть в АС (например, утилита SYSCON в
Netware 3.Х).
Некоторые АС содержат программы, которые заставляют регулярно
пользователей регулярно изменять пароли. Многие из этих АС также
имеют генераторы паролей, которые обеспечивают пользователя
набором паролей, из которого он может выбирать. Пользователю этих
АС не разрешается самому задавать пароль. Существуют аргументы и
за , и против таких АС. С одной стороны, используя
сгенерированные пароли, пользователи защищены от выбора плохих
паролей. С другой стороны, если только генератор не делает легкие
для запоминания пароли, пользователи начнут записывать их для
того, чтобы запомнить.
То, как производится изменение паролей, очень важно для
сохранения паролей в тайне. В идеале, пользователи должны
оперативно изменять свои пароли. (Отметим, что программы
изменения паролей - излюбленная мишень злоумышленников. Смотрите
раздел 4.4 об управлении конфигурацией для более подробной
информации).
Тем не менее, существуют исключительные ситуации, в которых
нужно поступать очень осторожно. Пользователи могут забыть пароли
и потерять доступ к АС. Стандартной процедурой является
назначение пользователю нового пароля. Следует проверять, что
запросил изменение пароля и получил его настоящий пользователь.
Распространенной среди злоумышленников уловкой является звонок
или посылка сообщения системному администратору с запросом нового
пароля. Нужно по другому каналу связаться с пользователем и
проверить, что это действительно он, перед тем, как назначать
пароль. В некоторых организациях пользователям требуется лично
прийти к администратору.
Также могут возникнуть ситуации, когда требуется изменить
сразу много паролей. Если АС скомпрометирована злоумышленником,
то он может украсть файл паролей из АС и стереть его. В таком
случае единственным решением должна быть замена всех паролей в
АС. Ваша организация должна иметь процедуры того, как это сделать
быстро и эффективно. Что конкретно вы будете делать, зависит от
ситуации. Если это атака, имевшая целью разрушение АС, то можно
принудительно удалить все регистрационные имена и назначить
пользователям новые пароли до того, как они смогут войти в АС. В
некоторых организациях пользователям посылается сообщение о том,
что им нужно изменить свой пароль в течение определенного периода
времени. Если пароль не меняется по истечении указанного периода
времени, то регистрационное имя блокируется.
Пользователи должны быть извещены о том, какова стандартная
процедура, применяемая при замене паролей, в случае нарушения
защиты. Один хорошо известный инцидент, о котором сообщила CERT,
заключался в том, что пользователям посылались сообщения, якобы
от местного системного администратора, требующие их заменить свой
пароль на новый, указанный в этом сообщении. На самом деле эти
сообщения были посланы не администратором, а злоумышленником,
пытающимся узнать регистрационные имена. Поэтому пользователей
следует предупредить, чтобы они немедленно сообщали о всех
подозрительных сообщениях, аналогичных этому, администрации
организации.
Понятие контроля за конфигурацией обычно применяется в
области разработки программ. Тем не менее, в какой-то степени оно
также применимо и к функционированию программ. Напомним, что
многие из системных программ так или иначе реализуют ПРД, поэтому
важно, чтобы они корректно работали. То есть не следует разрешать
произвольно изменять системные программы (такие, как операционную
систему, и т.д.). По крайней мере, эти меры должны определять,
кто имеет право изменять их, в каких случаях, и как эти изменения
должны быть задокументированы.
В некоторых средах, контроль за конфигурацией также желателен
в отношении физической конфигурации оборудования. Сохранение
правильной конфигурации оборудования также должно быть отражено в
ваших ПРД.
Иногда может оказаться выгодным слегка изменить конфигурацию,
для того чтобы расстроить стандартные атаки, используемые
некоторым злоумышленниками. Нестандартная часть конфигурации
может включать измененные алгоритмы шифрования паролей, другое
местоположение файлов, а также переписанные или функционально
ограниченные системные команды.
Тем не менее, нестандартные конфигурации имеют свои
недостатки. Изменяя "стандартную" АС, эти модификации затрудняют
поддержание работы программного обеспечения, требуя написания
дополнительной документации, модификации программ после
обновления операционной системы, и обычно, кого-то, кто знает все
об этих изменениях.
Из-за этих недостатков, нестандартные конфигурации часто
используются на ЭВМ с "горящими стенами "(смотри раздел 3.9.1).
ЭВМ с "горящей стеной" модифицируется для более успешного
отражения атак, в то время как во внутренних ЭВМ позади
"горящей стены" конфигурация остается стандартной.
Эта часть документа даст вам некоторые советы, связанные с
тем, что делать, когда происходит нарушение ПРД на СВТ, в сети
или в организации. При этом стратегической задачей при нарушении
ПРД, независимо от того, атака ли это внешнего злоумышленника или
недовольного служащего, должна быть подготовленность ко
всевозможным событиям такого рода. Не следует ее заменять
выработкой спорадических планов для типов событий, описанных
выше.
Традиционная защита СВТ, хотя и играет важную роль в общем
плане защиты организации, обычно уделяет мало внимания защите АС
от атак, и наблюдению за АС для обнаружения атаки. Также обычно
практически ничего не говорится о том, как реально отражать
атаку, когда она началась. Результатом является то, что когда
атака начинается, многие решения принимаются в спешке и могут
помешать выявить причину инцидента, собрать улики для суда,
подготовиться к восстановлению АС, и защитить ценные данные,
хранящиеся в АС.
То, как вы будете улаживать инцидент, должно быть определено
до того, как произойдет инцидент. Это включает установление
подходящей степени защиты, так чтобы если инцидент станет
опасным, потенциальные разрушения были бы ограниченными. Защита
включает подготовку рекомендаций по улаживанию инцидента или
выработку сиюминутного плана ответных действий вашей организации.
Наличие написанного плана во-первых освобождает от двусмысленных
ситуаций, возникающих во время инцидента и помогает принять более
подходящие и строгие ответные действия. Во-вторых, частью защиты
является разработка метода уведомления, чтобы вы знали, кому
звонить и соответствующие номера телефонов. Например, важно
провести тренировки, в ходе которых персонал компьютерной защиты,
системные администраторы, и управляющие имитировали бы действия в
ходе инцидента.
Тренировка эффективных ответных действий при инциденте важна
по ряду причин. Самым важным является то, что таким образом
предотвращается опасность человеческой жизни. Некоторые АС
являются системами, от которых зависят человеческие жизни
(например, система управления госпиталем или воздушным
движением).
Важным, но часто забываемым достоинством является
экономичность. Наличие как технического, так и управленческого
персонала, готового к инцидентам, требует значительных ресурсов,
которые могли бы быть использованы более выгодно, если бы не
требовалась их готовность к отражению атаки. Если этот персонал
натренирован на улаживание инцидента, им потребуется меньше
времени для этого.
Третьим достоинством является защита конфиденциальной
информации. Одна из основных опасностей инцидента с компьютерной
защитой состоит в том, что нельзя будет восстановить эту
информацию. Эффективное улаживание инцидента минимизирует эту
опасность. Если инцидент затрагивает секретную информацию, то в
любой план улаживания инцидента должны быть включены
государственные законы, имеющие отношение к секретной информации.
Четвертое преимущество связано с прессой. Новости об
инциденте с компьютерной защитой приводят к падению авторитета
организации в глазах текущих или потенциальных клиентов.
Эффективное улаживание инцидента минимизирует потенциальное
негативное воздействие.
Последнее преимущество эффективного улаживания инцидента
связано с судебной ответственностью. Весьма вероятно, что в
ближайшем будущем организации будут привлекаться к
ответственности в случае, если с одного из СВТ, принадлежащих им,
была начата сетевая атака. Аналогично, люди, разрабатывающие
"заплатки" (изменения в загрузочных модулях для исправления
ошибок), возможно будут привлекаться к ответственности, если их
изменения приведут к разрушениям в АС, или окажутся
неэффективными при защите. Знание уязвимых мест операционных
систем и типовых атак, а также действий, которые нужно
предпринять, помогут избежать возможных проблем с законом.
Эта глава составлена таким образом, чтобы список, полученный
из оглавления, мог бы послужить отправной точкой при выработке
мер по улаживанию инцидентов. Основными моментами, которые должны
быть отражены в мерах по улаживанию инцидентов являются:
- Обзор (каковы цели и задачи при улаживании инцидента)
- Оценка (насколько серьезен инцидент)
- Уведомление (кого следует уведомить об инциденте)
- Ответные действия (каковы должны быть ответные действия)
- Законность (каковы последствия инцидента с точки зрения
закона)
- Документирование (какие записи должны быть сделан перед
инцидентом, в его течение, и после улаживания)
Каждый из этих моментов важен в общем плане улаживания
инцидентов. Остаток этой главы детально рассмотрит вопросы,
связанные с каждым из этих разделов, и даст некоторые
рекомендации, которые следует включить в меры организации по
улаживанию инцидентов.
Прежде всего следует уделить внимание целям, достигаемым при
улаживании инцидента. Конечно, в зависимости от организации,
важность целей будет меняться, но один из возможных вариантов
приведен ниже:
Гарантировать целостность критических АС
Поддержать и восстановить данные
Поддержать и восстановить службы
Определить, что случилось
Избежать эскалации и дальнейших инцидентов
Избежать нежелательной огласки
Определить, кто это сделал
Наказать атакующего
Важно определить приоритеты действий, предпринимаемых во
время инцидента, до того, как инцидент произойдет. Иногда
инцидент может быть настолько сложен, что просто невозможно
делать все одновременно для его ликвидации; нужно расставить
приоритеты. Хотя эти приоритеты могут меняться от организации к
организации, предлагаемые ниже приоритеты могут послужить
отправной точкой при определении ответных действий организации:
1) Защитить человеческие жизни - человеческая жизнь всегда
является самым важным;
2) Защитить критические и секретные данные (с точки зрения
организации и закона);
3) Защитить другие данные, включая частные, научные, и другие
данные, так как потеря данных дорого обходится в терминах
ресурсов;
4) Предотвратить разрушение АС (например, потерю или изменение
системных файлов, разрушение дисковых накопителей, и т.д.);
разрушение АС может привести к затратам времени на ее
восстановление;
5) Минимизировать разрушение вычислительных ресурсов; во
многих случаях лучше выключить АС или отключить ее от сети,
чем рисковать данными или самой АС.
Важным следствием определения приоритетов является то, что
если затрагиваются вопросы человеческой жизни и национальной
безопасности, то в этом случае гораздо более важно сохранить
данные, чем программное обеспечение и оборудование. Хотя
разрушение или стирание чего-либо в ходе инцидента нежелательно,
АС можно заменить; потеря же или компрометация данных (особенно
секретных данных) обычно неприемлема при любых условиях.
То, как будет улаживаться инцидент, должно быть определено до
того, как случится инцидент. Это включает в себя соответствующие
защитные меры, чтобы, в случае серьезного инцидента, можно было
ограничить разрушения. Защита включает подготовку рекомендаций по
улаживанию инцидента или конкретный план действий, которые
предпримет ваша организация. Наличие написанного плана позволяет
избежать неясностей, возникающих в ходе инцидента, и ведет к
более уместным и более строгим мерам. Во-вторых, частью защитных
мер является разработка метода уведомления, чтобы вы знали, кому
звонить, и как с ним связаться. Например, каждый член группы
компьютерной безопасности Министерства Энергетики США носит с
собой карточку с рабочими и домашними телефонами других членов
группы, а также с номерами их пэйджеров. В-третьих, ваша
организация должна разработать процедуры создания архивных копий
для каждого СВТ и АС. Наличие архивных копий позволяет избежать
большей части угроз даже при серьезном инциденте, так как
архивные копии делают невозможным серьезные потери данных.
В-четвертых, вы должны сделать АС защищенными. Это включает
ликвидацию уязвимых мест, выработку эффективных правил работы с
паролями, и другие процедуры СРД, которые будут рассмотрены позже
в этом документе. Наконец, проведение тренировок также является
частью защиты. Например, важно проводить тренировки, в ходе
которых персонал, обеспечивающий защиту СВТ, системные
администраторы и управляющие имитировали бы действия при
улаживании инцидента.
Любой план ответных действий в инциденте с защитой должен
составляться на основе ПРД. Правительственные и коммерческие
организации, работающие с секретной информацией, имеют
специфические ПРД.
ПРД вашей организации, определяющие как следует улаживать
инциденты (это рассматривалось в пунктах 2.4 и 2.5), помогут
сформировать основной план ваших действий. Например, не имеет
смысла создавать механизмы наблюдения и слежения за
злоумышленниками, если ваша организация не планирует
предпринимать никаких действий по отношению к злоумышленникам в
случае их поимки. Другие организации могут иметь свои ПРД,
которые окажут влияние на ваши планы. Телефонные компании часто
дают информацию о номерах телефонов только правоохранительным
органам.
Раздел 5.5 также отмечает, что если планируется предпринимать
какие-либо правовые действия, то существуют специфические
рекомендации, которым нужно следовать, чтобы быть уверенным, что
вся собранная информация может использоваться в качестве улик.
Эта этап включает точное выявление проблемы. В большинстве
случаев причиной событий, ассоциируемых с заражением вирусами,
проникновением в АС, и т.д., оказываются просто аппаратные сбои.
Для того чтобы помочь выявить, произошел ли инцидент на самом
деле, обычно полезно получить и применить любое
обнаруживающее программное обеспечение, которое может быть
доступно. Например, широко распространенные программы могут
сильно помочь любому, кто подозревает наличие вируса на
компьютере Macintosh. Контрольная информация также очень важна,
особенно при выявлении сетевой атаки. Крайне важно получить образ
памяти АС, если есть подозрение, что происходит что-то необычное.
Многие инциденты приводят к возникновению динамической цепочки
событий, и образ памяти АС в начале может помочь при выявлении
проблемы и источника атаки больше, чем любые другие действия,
предпринимаемые на этом этапе. Наконец, важно завести журнал.
Занесение в него записей о системных событиях, телефонных
звонках, и т.д. поможет произвести более быстрое и надежное
выявление проблемы, а также послужит основой для следующих этапов
улаживания инцидента.
Существуют определенные признак или "симптомы" того, что
произошел инцидент, требующий особого внимания:
- аварийные завершения работы АС;
- новые регистрационные имена пользователей (например, может
появиться необъяснимым образом регистрационное имя
RUMPLESTILTSKIN), или высокая активность регистрационного имени,
которое несколько месяцев не проявляло никакой активности;
- новые файлы (обычно со странными именами, такими как
data.xx или k);
- наличие несоответствий в информации о работе
регистрационных имен ( например, в UNIX вы можете заметить, что
файл учета работы регистрационных имен, названный
/usr/admin/lastlog, был обрезан, что является очень
подозрительным);
- изменения в длинах файлов или их датах (например, у
пользователя должно появиться подозрения, если он видит, что
.EXE-файлы в ЭВМ с MS-DOS неожиданно увеличились на 1800 байт);
- попытки записи в системные файлы (например, системный
администратор замечает, что привилегированный пользователь в VMS
пытается изменить файл RIGHTSLIST.DAT);
- модификация или удаление данных (например, начинают исчезать
файлы);
- отказ в обслуживании (например, системный администратор и
остальные пользователи блокированы ОС UNIX, которая перешла в
однопользовательский режим);
- необъяснимо медленная работа АС (например, выдача сообщений
АС становится необычно медленной);
- аномалии (например, на экране терминала высвечивается
GOTCHA или слышатся частые необъяснимые гудки динамика ЭВМ);
- подозрительные входы в АС (например, большое число
неудачных попыток войти в АС с другого узла сети);
- подозрительный просмотр файлов (например, кто-то
становится суперпользователем в UNIX и начинает последовательно
просматривать файлы одного регистрационного имени, затем
другого и т.д.).
Ни один из этих признаков не является абсолютным
доказательством того, что происходит инцидент, кроме того при
инциденте могут наблюдаться не все перечисленные выше признаки.
Если вы заметили любой из этих признаков, то следует, тем не
менее, заподозрить возникновение инцидента и действовать
соответствующим образом. Не существует формулы, позволяющей со
стопроцентной точностью определить, что происходит инцидент
(возможное исключение: когда антивирусная программа сообщает, что
на вашем СВТ есть вирус nVIR, и вы убеждаетесь в этом, обнаружив
на вашем Macintosh его текст, вы можете быть уверены, что ваше
СВТ заражено). В этот момент лучше всего связаться с персоналом,
отвечающим за защиту СВТ, для принятия коллективного решения о
том, происходит ли инцидент.
Вместе с идентификацией инцидента следует проводить оценку
области распространения и опасности инцидента. Важно корректно
идентифицировать границы инцидента, для того чтобы эффективно его
уладить. Помимо этого, опасность инцидента определит приоритеты
при распределении привлекаемых ресурсов. Не зная области
распространения и опасности события, трудно произвести корректные
ответные действия.
Для того чтобы идентифицировать область распространения и
опасность, следует создать набор критериев, который будет
меняться в зависимости от организации и сетевых соединений. Вот
некоторые из них:
- Этот инцидент затрагивает несколько организаций?
- Много ли СВТ вашей организации пострадали из-за этого
инцидента?
- Затрагивает ли он конфиденциальную информацию?
- Что было начальной точкой при его распространении (сеть,
телефонная линия, местный терминал, и т.д)?
- Знает ли о нем пресса?
- Каковы потенциальные разрушительные последствия инцидента?
- Сколько ориентировочно понадобится времени, чтобы уладить
инцидент?
- Какие ресурсы потребуются для улаживания инцидента?
Когда вы получили подтверждение того, что на самом деле
произошел инцидент, нужно уведомить соответствующий персонал. Кто
и как уведомляется, очень важно для сохранения контроля над
событиями как с технической, так и с эмоциональной точки зрения.
Прежде всего, любое уведомление либо местного, либо
удаленного персонала должно быть четким. Это требует, чтобы любое
заявление (будь то электронное письмо, телефонный звонок или
факс) содержали бы информацию об инциденте, которая была бы
ясной, краткой и квалифицированной. Когда вы сообщаете другому
человеку, что просите его помочь вам справиться с проблемой, вы
только запутываете дело. Если существует разделение труда,
полезно дать информацию каждому отделу, где можно получить
интересующую их информацию. Это не только позволит избежать
дублирования работы, но также поможет людям, работающим над этой
проблемой знать, где можно получить информацию, которая поможет
решить их часть проблемы.
Другим важным аспектом является то, что взаимодействие,
связанное с инцидентом, должно быть конкретным. Попытки скрыть
некоторые аспекты инцидента при помощи ложной или неполной
информации могут не только помешать успешному разрешению
проблемы, но и ухудшить ситуацию. Это особенно верно, когда об
инциденте узнала пресса. Когда инцидент настолько серьезен, что
привлек внимание прессы, весьма вероятно, что любая ложная
информация, которую вы сообщите, не будет подтверждена другими
источниками. Это плохо отразится на организации и может привести
к напряженности в отношениях между организацией и прессой.
Правильный выбор языка, используемого при уведомлении людей
об инциденте, может оказать большое влияние на то, как будет
воспринята информация. Если вы используете эмоциональные слова,
то люди будут ожидать разрушений и негативных последствий в
результате инцидента. Важно оставаться спокойным как при
написании сообщений, так и при разговорах с людьми.
Другой вопрос, связанный с выбором языка, - это уведомление
нетехнического персонала. Важно точно описать инцидент, не делая
при этом никаких тревожных сообщений. Хотя описать инцидент
неспециалистам более сложно, часто это более важно. Нетехническое
описание может потребоваться для верхнего звена управления,
прессы, или правоохранительных органов. Важность этих сообщений
не может быть недооценена, так как правильное описание поможет
грамотно уладить инцидент и избежать больших разрушений.
Наконец, возникает вопрос, кого следует уведомить во время
инцидента и после него. Существует несколько классов людей,
которых следует не забывать при таких уведомлениях. Это
технический персонал, администрация, правоохранительные органы,
производители. Эта информация важна для координаторских пунктов,
так как люди, работающие там, отвечают за доведение ее до всех
остальных (смотри раздел 5.3.6 для более подробной информации).
Список людей в каждой из этих категорий поможет сохранить время
для людей, работающих на координаторских пунктах, во время
инцидента. Гораздо труднее определить соответствующих людей во
время инцидента, когда возникает неразбериха.
Помимо людей, ответственных за улаживание части инцидента,
другие организации также могут быть затронуты этим инцидентом
(или просто подвергаться риску). Более широкому кругу
пользователей также будет полезно узнать об инциденте. Часто
самым разумным является публикация сообщения об инциденте после
его улаживания, предназначенная пользователям.
Одним из самых важных вопросов, которые нужно решить,
является когда, кто, и как должен известить публику через прессу.
При решении этой проблемы следует учитывать много факторов.
Во-первых, если в организации есть отдел связей с прессой, то
важно использовать его как посредника. Этот отдел умеет
составлять отчеты для прессы, и поможет быть уверенным в том, что
авторитет организации защищен в ходе инцидента и после него (по
возможности). Отдел связей с прессой имеет то достоинство, что вы
может давать ему всю информацию, а он будет буфером между
постоянным вниманием прессы и необходимостью удерживать контроль
за инцидентом.
Если же такого отдела нет, нужно крайне осторожно давать
информацию прессе. Если эта информация критическая, то лучше дать
прессе только минимальную или обзорную информацию. Вполне
возможно, что любая информация, предоставленная прессе, будет
быстро получена виновником инцидента. Но все-таки предоставление
прессе ложной информации более опасно, чем критической
информации.
Хотя трудно заранее определить, насколько детальную
информацию следует сообщить прессе, нужно помнить о следующих
рекомендациях:
- Держите в тайне технические детали инцидента. Детальная
Netware 3.Х).
Некоторые АС содержат программы, которые заставляют регулярно
пользователей регулярно изменять пароли. Многие из этих АС также
имеют генераторы паролей, которые обеспечивают пользователя
набором паролей, из которого он может выбирать. Пользователю этих
АС не разрешается самому задавать пароль. Существуют аргументы и
за , и против таких АС. С одной стороны, используя
сгенерированные пароли, пользователи защищены от выбора плохих
паролей. С другой стороны, если только генератор не делает легкие
для запоминания пароли, пользователи начнут записывать их для
того, чтобы запомнить.
То, как производится изменение паролей, очень важно для
сохранения паролей в тайне. В идеале, пользователи должны
оперативно изменять свои пароли. (Отметим, что программы
изменения паролей - излюбленная мишень злоумышленников. Смотрите
раздел 4.4 об управлении конфигурацией для более подробной
информации).
Тем не менее, существуют исключительные ситуации, в которых
нужно поступать очень осторожно. Пользователи могут забыть пароли
и потерять доступ к АС. Стандартной процедурой является
назначение пользователю нового пароля. Следует проверять, что
запросил изменение пароля и получил его настоящий пользователь.
Распространенной среди злоумышленников уловкой является звонок
или посылка сообщения системному администратору с запросом нового
пароля. Нужно по другому каналу связаться с пользователем и
проверить, что это действительно он, перед тем, как назначать
пароль. В некоторых организациях пользователям требуется лично
прийти к администратору.
Также могут возникнуть ситуации, когда требуется изменить
сразу много паролей. Если АС скомпрометирована злоумышленником,
то он может украсть файл паролей из АС и стереть его. В таком
случае единственным решением должна быть замена всех паролей в
АС. Ваша организация должна иметь процедуры того, как это сделать
быстро и эффективно. Что конкретно вы будете делать, зависит от
ситуации. Если это атака, имевшая целью разрушение АС, то можно
принудительно удалить все регистрационные имена и назначить
пользователям новые пароли до того, как они смогут войти в АС. В
некоторых организациях пользователям посылается сообщение о том,
что им нужно изменить свой пароль в течение определенного периода
времени. Если пароль не меняется по истечении указанного периода
времени, то регистрационное имя блокируется.
Пользователи должны быть извещены о том, какова стандартная
процедура, применяемая при замене паролей, в случае нарушения
защиты. Один хорошо известный инцидент, о котором сообщила CERT,
заключался в том, что пользователям посылались сообщения, якобы
от местного системного администратора, требующие их заменить свой
пароль на новый, указанный в этом сообщении. На самом деле эти
сообщения были посланы не администратором, а злоумышленником,
пытающимся узнать регистрационные имена. Поэтому пользователей
следует предупредить, чтобы они немедленно сообщали о всех
подозрительных сообщениях, аналогичных этому, администрации
организации.
Понятие контроля за конфигурацией обычно применяется в
области разработки программ. Тем не менее, в какой-то степени оно
также применимо и к функционированию программ. Напомним, что
многие из системных программ так или иначе реализуют ПРД, поэтому
важно, чтобы они корректно работали. То есть не следует разрешать
произвольно изменять системные программы (такие, как операционную
систему, и т.д.). По крайней мере, эти меры должны определять,
кто имеет право изменять их, в каких случаях, и как эти изменения
должны быть задокументированы.
В некоторых средах, контроль за конфигурацией также желателен
в отношении физической конфигурации оборудования. Сохранение
правильной конфигурации оборудования также должно быть отражено в
ваших ПРД.
Иногда может оказаться выгодным слегка изменить конфигурацию,
для того чтобы расстроить стандартные атаки, используемые
некоторым злоумышленниками. Нестандартная часть конфигурации
может включать измененные алгоритмы шифрования паролей, другое
местоположение файлов, а также переписанные или функционально
ограниченные системные команды.
Тем не менее, нестандартные конфигурации имеют свои
недостатки. Изменяя "стандартную" АС, эти модификации затрудняют
поддержание работы программного обеспечения, требуя написания
дополнительной документации, модификации программ после
обновления операционной системы, и обычно, кого-то, кто знает все
об этих изменениях.
Из-за этих недостатков, нестандартные конфигурации часто
используются на ЭВМ с "горящими стенами "(смотри раздел 3.9.1).
ЭВМ с "горящей стеной" модифицируется для более успешного
отражения атак, в то время как во внутренних ЭВМ позади
"горящей стены" конфигурация остается стандартной.
Эта часть документа даст вам некоторые советы, связанные с
тем, что делать, когда происходит нарушение ПРД на СВТ, в сети
или в организации. При этом стратегической задачей при нарушении
ПРД, независимо от того, атака ли это внешнего злоумышленника или
недовольного служащего, должна быть подготовленность ко
всевозможным событиям такого рода. Не следует ее заменять
выработкой спорадических планов для типов событий, описанных
выше.
Традиционная защита СВТ, хотя и играет важную роль в общем
плане защиты организации, обычно уделяет мало внимания защите АС
от атак, и наблюдению за АС для обнаружения атаки. Также обычно
практически ничего не говорится о том, как реально отражать
атаку, когда она началась. Результатом является то, что когда
атака начинается, многие решения принимаются в спешке и могут
помешать выявить причину инцидента, собрать улики для суда,
подготовиться к восстановлению АС, и защитить ценные данные,
хранящиеся в АС.
То, как вы будете улаживать инцидент, должно быть определено
до того, как произойдет инцидент. Это включает установление
подходящей степени защиты, так чтобы если инцидент станет
опасным, потенциальные разрушения были бы ограниченными. Защита
включает подготовку рекомендаций по улаживанию инцидента или
выработку сиюминутного плана ответных действий вашей организации.
Наличие написанного плана во-первых освобождает от двусмысленных
ситуаций, возникающих во время инцидента и помогает принять более
подходящие и строгие ответные действия. Во-вторых, частью защиты
является разработка метода уведомления, чтобы вы знали, кому
звонить и соответствующие номера телефонов. Например, важно
провести тренировки, в ходе которых персонал компьютерной защиты,
системные администраторы, и управляющие имитировали бы действия в
ходе инцидента.
Тренировка эффективных ответных действий при инциденте важна
по ряду причин. Самым важным является то, что таким образом
предотвращается опасность человеческой жизни. Некоторые АС
являются системами, от которых зависят человеческие жизни
(например, система управления госпиталем или воздушным
движением).
Важным, но часто забываемым достоинством является
экономичность. Наличие как технического, так и управленческого
персонала, готового к инцидентам, требует значительных ресурсов,
которые могли бы быть использованы более выгодно, если бы не
требовалась их готовность к отражению атаки. Если этот персонал
натренирован на улаживание инцидента, им потребуется меньше
времени для этого.
Третьим достоинством является защита конфиденциальной
информации. Одна из основных опасностей инцидента с компьютерной
защитой состоит в том, что нельзя будет восстановить эту
информацию. Эффективное улаживание инцидента минимизирует эту
опасность. Если инцидент затрагивает секретную информацию, то в
любой план улаживания инцидента должны быть включены
государственные законы, имеющие отношение к секретной информации.
Четвертое преимущество связано с прессой. Новости об
инциденте с компьютерной защитой приводят к падению авторитета
организации в глазах текущих или потенциальных клиентов.
Эффективное улаживание инцидента минимизирует потенциальное
негативное воздействие.
Последнее преимущество эффективного улаживания инцидента
связано с судебной ответственностью. Весьма вероятно, что в
ближайшем будущем организации будут привлекаться к
ответственности в случае, если с одного из СВТ, принадлежащих им,
была начата сетевая атака. Аналогично, люди, разрабатывающие
"заплатки" (изменения в загрузочных модулях для исправления
ошибок), возможно будут привлекаться к ответственности, если их
изменения приведут к разрушениям в АС, или окажутся
неэффективными при защите. Знание уязвимых мест операционных
систем и типовых атак, а также действий, которые нужно
предпринять, помогут избежать возможных проблем с законом.
Эта глава составлена таким образом, чтобы список, полученный
из оглавления, мог бы послужить отправной точкой при выработке
мер по улаживанию инцидентов. Основными моментами, которые должны
быть отражены в мерах по улаживанию инцидентов являются:
- Обзор (каковы цели и задачи при улаживании инцидента)
- Оценка (насколько серьезен инцидент)
- Уведомление (кого следует уведомить об инциденте)
- Ответные действия (каковы должны быть ответные действия)
- Законность (каковы последствия инцидента с точки зрения
закона)
- Документирование (какие записи должны быть сделан перед
инцидентом, в его течение, и после улаживания)
Каждый из этих моментов важен в общем плане улаживания
инцидентов. Остаток этой главы детально рассмотрит вопросы,
связанные с каждым из этих разделов, и даст некоторые
рекомендации, которые следует включить в меры организации по
улаживанию инцидентов.
Прежде всего следует уделить внимание целям, достигаемым при
улаживании инцидента. Конечно, в зависимости от организации,
важность целей будет меняться, но один из возможных вариантов
приведен ниже:
Гарантировать целостность критических АС
Поддержать и восстановить данные
Поддержать и восстановить службы
Определить, что случилось
Избежать эскалации и дальнейших инцидентов
Избежать нежелательной огласки
Определить, кто это сделал
Наказать атакующего
Важно определить приоритеты действий, предпринимаемых во
время инцидента, до того, как инцидент произойдет. Иногда
инцидент может быть настолько сложен, что просто невозможно
делать все одновременно для его ликвидации; нужно расставить
приоритеты. Хотя эти приоритеты могут меняться от организации к
организации, предлагаемые ниже приоритеты могут послужить
отправной точкой при определении ответных действий организации:
1) Защитить человеческие жизни - человеческая жизнь всегда
является самым важным;
2) Защитить критические и секретные данные (с точки зрения
организации и закона);
3) Защитить другие данные, включая частные, научные, и другие
данные, так как потеря данных дорого обходится в терминах
ресурсов;
4) Предотвратить разрушение АС (например, потерю или изменение
системных файлов, разрушение дисковых накопителей, и т.д.);
разрушение АС может привести к затратам времени на ее
восстановление;
5) Минимизировать разрушение вычислительных ресурсов; во
многих случаях лучше выключить АС или отключить ее от сети,
чем рисковать данными или самой АС.
Важным следствием определения приоритетов является то, что
если затрагиваются вопросы человеческой жизни и национальной
безопасности, то в этом случае гораздо более важно сохранить
данные, чем программное обеспечение и оборудование. Хотя
разрушение или стирание чего-либо в ходе инцидента нежелательно,
АС можно заменить; потеря же или компрометация данных (особенно
секретных данных) обычно неприемлема при любых условиях.
То, как будет улаживаться инцидент, должно быть определено до
того, как случится инцидент. Это включает в себя соответствующие
защитные меры, чтобы, в случае серьезного инцидента, можно было
ограничить разрушения. Защита включает подготовку рекомендаций по
улаживанию инцидента или конкретный план действий, которые
предпримет ваша организация. Наличие написанного плана позволяет
избежать неясностей, возникающих в ходе инцидента, и ведет к
более уместным и более строгим мерам. Во-вторых, частью защитных
мер является разработка метода уведомления, чтобы вы знали, кому
звонить, и как с ним связаться. Например, каждый член группы
компьютерной безопасности Министерства Энергетики США носит с
собой карточку с рабочими и домашними телефонами других членов
группы, а также с номерами их пэйджеров. В-третьих, ваша
организация должна разработать процедуры создания архивных копий
для каждого СВТ и АС. Наличие архивных копий позволяет избежать
большей части угроз даже при серьезном инциденте, так как
архивные копии делают невозможным серьезные потери данных.
В-четвертых, вы должны сделать АС защищенными. Это включает
ликвидацию уязвимых мест, выработку эффективных правил работы с
паролями, и другие процедуры СРД, которые будут рассмотрены позже
в этом документе. Наконец, проведение тренировок также является
частью защиты. Например, важно проводить тренировки, в ходе
которых персонал, обеспечивающий защиту СВТ, системные
администраторы и управляющие имитировали бы действия при
улаживании инцидента.
Любой план ответных действий в инциденте с защитой должен
составляться на основе ПРД. Правительственные и коммерческие
организации, работающие с секретной информацией, имеют
специфические ПРД.
ПРД вашей организации, определяющие как следует улаживать
инциденты (это рассматривалось в пунктах 2.4 и 2.5), помогут
сформировать основной план ваших действий. Например, не имеет
смысла создавать механизмы наблюдения и слежения за
злоумышленниками, если ваша организация не планирует
предпринимать никаких действий по отношению к злоумышленникам в
случае их поимки. Другие организации могут иметь свои ПРД,
которые окажут влияние на ваши планы. Телефонные компании часто
дают информацию о номерах телефонов только правоохранительным
органам.
Раздел 5.5 также отмечает, что если планируется предпринимать
какие-либо правовые действия, то существуют специфические
рекомендации, которым нужно следовать, чтобы быть уверенным, что
вся собранная информация может использоваться в качестве улик.
Эта этап включает точное выявление проблемы. В большинстве
случаев причиной событий, ассоциируемых с заражением вирусами,
проникновением в АС, и т.д., оказываются просто аппаратные сбои.
Для того чтобы помочь выявить, произошел ли инцидент на самом
деле, обычно полезно получить и применить любое
обнаруживающее программное обеспечение, которое может быть
доступно. Например, широко распространенные программы могут
сильно помочь любому, кто подозревает наличие вируса на
компьютере Macintosh. Контрольная информация также очень важна,
особенно при выявлении сетевой атаки. Крайне важно получить образ
памяти АС, если есть подозрение, что происходит что-то необычное.
Многие инциденты приводят к возникновению динамической цепочки
событий, и образ памяти АС в начале может помочь при выявлении
проблемы и источника атаки больше, чем любые другие действия,
предпринимаемые на этом этапе. Наконец, важно завести журнал.
Занесение в него записей о системных событиях, телефонных
звонках, и т.д. поможет произвести более быстрое и надежное
выявление проблемы, а также послужит основой для следующих этапов
улаживания инцидента.
Существуют определенные признак или "симптомы" того, что
произошел инцидент, требующий особого внимания:
- аварийные завершения работы АС;
- новые регистрационные имена пользователей (например, может
появиться необъяснимым образом регистрационное имя
RUMPLESTILTSKIN), или высокая активность регистрационного имени,
которое несколько месяцев не проявляло никакой активности;
- новые файлы (обычно со странными именами, такими как
data.xx или k);
- наличие несоответствий в информации о работе
регистрационных имен ( например, в UNIX вы можете заметить, что
файл учета работы регистрационных имен, названный
/usr/admin/lastlog, был обрезан, что является очень
подозрительным);
- изменения в длинах файлов или их датах (например, у
пользователя должно появиться подозрения, если он видит, что
.EXE-файлы в ЭВМ с MS-DOS неожиданно увеличились на 1800 байт);
- попытки записи в системные файлы (например, системный
администратор замечает, что привилегированный пользователь в VMS
пытается изменить файл RIGHTSLIST.DAT);
- модификация или удаление данных (например, начинают исчезать
файлы);
- отказ в обслуживании (например, системный администратор и
остальные пользователи блокированы ОС UNIX, которая перешла в
однопользовательский режим);
- необъяснимо медленная работа АС (например, выдача сообщений
АС становится необычно медленной);
- аномалии (например, на экране терминала высвечивается
GOTCHA или слышатся частые необъяснимые гудки динамика ЭВМ);
- подозрительные входы в АС (например, большое число
неудачных попыток войти в АС с другого узла сети);
- подозрительный просмотр файлов (например, кто-то
становится суперпользователем в UNIX и начинает последовательно
просматривать файлы одного регистрационного имени, затем
другого и т.д.).
Ни один из этих признаков не является абсолютным
доказательством того, что происходит инцидент, кроме того при
инциденте могут наблюдаться не все перечисленные выше признаки.
Если вы заметили любой из этих признаков, то следует, тем не
менее, заподозрить возникновение инцидента и действовать
соответствующим образом. Не существует формулы, позволяющей со
стопроцентной точностью определить, что происходит инцидент
(возможное исключение: когда антивирусная программа сообщает, что
на вашем СВТ есть вирус nVIR, и вы убеждаетесь в этом, обнаружив
на вашем Macintosh его текст, вы можете быть уверены, что ваше
СВТ заражено). В этот момент лучше всего связаться с персоналом,
отвечающим за защиту СВТ, для принятия коллективного решения о
том, происходит ли инцидент.
Вместе с идентификацией инцидента следует проводить оценку
области распространения и опасности инцидента. Важно корректно
идентифицировать границы инцидента, для того чтобы эффективно его
уладить. Помимо этого, опасность инцидента определит приоритеты
при распределении привлекаемых ресурсов. Не зная области
распространения и опасности события, трудно произвести корректные
ответные действия.
Для того чтобы идентифицировать область распространения и
опасность, следует создать набор критериев, который будет
меняться в зависимости от организации и сетевых соединений. Вот
некоторые из них:
- Этот инцидент затрагивает несколько организаций?
- Много ли СВТ вашей организации пострадали из-за этого
инцидента?
- Затрагивает ли он конфиденциальную информацию?
- Что было начальной точкой при его распространении (сеть,
телефонная линия, местный терминал, и т.д)?
- Знает ли о нем пресса?
- Каковы потенциальные разрушительные последствия инцидента?
- Сколько ориентировочно понадобится времени, чтобы уладить
инцидент?
- Какие ресурсы потребуются для улаживания инцидента?
Когда вы получили подтверждение того, что на самом деле
произошел инцидент, нужно уведомить соответствующий персонал. Кто
и как уведомляется, очень важно для сохранения контроля над
событиями как с технической, так и с эмоциональной точки зрения.
Прежде всего, любое уведомление либо местного, либо
удаленного персонала должно быть четким. Это требует, чтобы любое
заявление (будь то электронное письмо, телефонный звонок или
факс) содержали бы информацию об инциденте, которая была бы
ясной, краткой и квалифицированной. Когда вы сообщаете другому
человеку, что просите его помочь вам справиться с проблемой, вы
только запутываете дело. Если существует разделение труда,
полезно дать информацию каждому отделу, где можно получить
интересующую их информацию. Это не только позволит избежать
дублирования работы, но также поможет людям, работающим над этой
проблемой знать, где можно получить информацию, которая поможет
решить их часть проблемы.
Другим важным аспектом является то, что взаимодействие,
связанное с инцидентом, должно быть конкретным. Попытки скрыть
некоторые аспекты инцидента при помощи ложной или неполной
информации могут не только помешать успешному разрешению
проблемы, но и ухудшить ситуацию. Это особенно верно, когда об
инциденте узнала пресса. Когда инцидент настолько серьезен, что
привлек внимание прессы, весьма вероятно, что любая ложная
информация, которую вы сообщите, не будет подтверждена другими
источниками. Это плохо отразится на организации и может привести
к напряженности в отношениях между организацией и прессой.
Правильный выбор языка, используемого при уведомлении людей
об инциденте, может оказать большое влияние на то, как будет
воспринята информация. Если вы используете эмоциональные слова,
то люди будут ожидать разрушений и негативных последствий в
результате инцидента. Важно оставаться спокойным как при
написании сообщений, так и при разговорах с людьми.
Другой вопрос, связанный с выбором языка, - это уведомление
нетехнического персонала. Важно точно описать инцидент, не делая
при этом никаких тревожных сообщений. Хотя описать инцидент
неспециалистам более сложно, часто это более важно. Нетехническое
описание может потребоваться для верхнего звена управления,
прессы, или правоохранительных органов. Важность этих сообщений
не может быть недооценена, так как правильное описание поможет
грамотно уладить инцидент и избежать больших разрушений.
Наконец, возникает вопрос, кого следует уведомить во время
инцидента и после него. Существует несколько классов людей,
которых следует не забывать при таких уведомлениях. Это
технический персонал, администрация, правоохранительные органы,
производители. Эта информация важна для координаторских пунктов,
так как люди, работающие там, отвечают за доведение ее до всех
остальных (смотри раздел 5.3.6 для более подробной информации).
Список людей в каждой из этих категорий поможет сохранить время
для людей, работающих на координаторских пунктах, во время
инцидента. Гораздо труднее определить соответствующих людей во
время инцидента, когда возникает неразбериха.
Помимо людей, ответственных за улаживание части инцидента,
другие организации также могут быть затронуты этим инцидентом
(или просто подвергаться риску). Более широкому кругу
пользователей также будет полезно узнать об инциденте. Часто
самым разумным является публикация сообщения об инциденте после
его улаживания, предназначенная пользователям.
Одним из самых важных вопросов, которые нужно решить,
является когда, кто, и как должен известить публику через прессу.
При решении этой проблемы следует учитывать много факторов.
Во-первых, если в организации есть отдел связей с прессой, то
важно использовать его как посредника. Этот отдел умеет
составлять отчеты для прессы, и поможет быть уверенным в том, что
авторитет организации защищен в ходе инцидента и после него (по
возможности). Отдел связей с прессой имеет то достоинство, что вы
может давать ему всю информацию, а он будет буфером между
постоянным вниманием прессы и необходимостью удерживать контроль
за инцидентом.
Если же такого отдела нет, нужно крайне осторожно давать
информацию прессе. Если эта информация критическая, то лучше дать
прессе только минимальную или обзорную информацию. Вполне
возможно, что любая информация, предоставленная прессе, будет
быстро получена виновником инцидента. Но все-таки предоставление
прессе ложной информации более опасно, чем критической
информации.
Хотя трудно заранее определить, насколько детальную
информацию следует сообщить прессе, нужно помнить о следующих
рекомендациях:
- Держите в тайне технические детали инцидента. Детальная