Аудит и обнаружение вторжений

Общие сведения

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

Необходимость включения в защищенную систему функций аудита диктуется следующими обстоятельствами.

  • • Подсистема защиты компьютерной системы, не обладая интеллектом, неспособна отличить случайные ошибки пользователей от злонамеренных действий. Например, то, что пользователь в процессе входа в систему ввел неправильный пароль, может означать как случайную ошибку при вводе пароля, так и попытку подбора пароля. Но, если сообщение о подобном событии занесено в журнал аудита, администратор, просматривая этот журнал, возможно, сможет установить, что же имело место на самом деле — ошибка легального пользователя или атака злоумышленника. Если пользователь ввел неправильный пароль всего один раз — это явная ошибка. Если же пользователь пытался угадать собственный пароль 20-30 раз — это явная попытка подбора пароля.
  • • Администраторы защищаемой системы должны иметь возможность получать информацию не только о текущем состоянии системы, но и о том, как она функционировала в недавнем прошлом. Журнал аудита дает такую возможность, накапливая информацию о важных событиях, связанных с безопасностью операционной системы.
  • • Если администратор обнаружил, что против защищаемой системы проведена успешная атака, ему важно выяснить, когда она была начата и каким образом она осуществлялась. При наличии в системе подсистемы аудита не исключено, что вся необходимая информация содержится в журнале аудита. Некоторые эксперты по компьютерной безопасности полагают,

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

Однако на практике отделение аудиторов от администраторов применяется редко, что обусловлено следующими причинами:

  • • обслуживание аудита на одном компьютере занимает существенно меньше времени, чем администрирование одного компьютера. В большой организации на одного аудитора должно приходиться 5-20 администраторов. Если организация невелика и в ней предусмотрены всего 1-2 штатные должности системных администраторов, создавать отдельную штатную должность аудитора нецелесообразно;
  • • администраторы и аудиторы часто вступают в приятельские отношения, в результате чего аудитор далеко не всегда докладывает начальнику об обнаруженных злоупотреблениях администраторов. Бывает, что аудиторы не только прикрывают злоупотребления администраторов, но и сами участвуют в них. Если отделение аудиторов от администраторов не подкреплено организационно-административными мерами, оно может оставаться чисто формальным — аудитор знает пароль администратора, администратор знает пароль аудитора, и оба они пользуются полномочиями друг друга по мере необходимости;
  • • при наличии в организации выделенного аудитора, недостаточно загруженного работой, аудитор часто вводит чрезмерно строгий контроль за действиями пользователей, негативно сказывающийся на моральном климате в коллективе. Пользователей сильно нервирует ситуация, когда малейшее нарушение правил работы с компьютерной системой (например, однократное посещение развлекательного сайта Internet) немедленно становится известным службе безопасности и влечет за собой неотвратимое наказание. Практика показывает, что выделенные аудиторы более склонны к реализации «параноической» политики безопасности, чем аудиторы, совмещающие свои обязанности с обязанностями системного администратора.

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

Подсистема аудита операционной системы должна удовлетворять следующим требованиям.

  • • Добавлять записи в журнал аудита могут только псевдопользователи, от имени которых выполняются системные процессы. Если предоставить эту возможность какому-то физическому пользователю, данный пользователь получит возможность компрометировать других пользователей, добавляя в журнал аудита соответствующие записи.
  • • Ни один субъект доступа, в том числе и сама операционная система, не имеет возможности редактировать или удалять отдельные записи в журнале аудита.
  • • Только пользователи-аудиторы, обладающие соответствующей привилегией, могут просматривать журнал аудита.
  • • Только пользователи-аудиторы могут очищать журнал аудита. После очистки журнала в него автоматически вносится запись о том, что журнал аудита был очищен, с указанием времени очистки журнала и имени пользователя, очистившего журнал. Система аудита должна поддерживать возможность сохранения журнала аудита перед очисткой в другом файле.

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

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

  • • попытки входа/выхода пользователей из системы;
  • • попытки изменения списка пользователей;
  • • попытки изменения политики безопасности, в том числе и политики аудита.

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

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

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

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

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

Множество событий, регистрируемых в журнале аудита, не обязательно должен совпадать с множеством событий, информация о которых передается аудиторам интерактивно. Целесообразно так организовать интерактивное оповещение аудиторов, чтобы аудиторы получали оповещение только о наиболее важных событиях — в противном случае аудиторам будет трудно выделить в сплошном потоке сообщений по-настоящему полезную информацию.

Данная дополнительная функция подсистемы аудита позволяет аудиторам более оперативно реагировать на попытки преодоления злоумышленниками защиты операционной системы и тем самым повышает общую защищенность системы.

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ ОРИГИНАЛ   След >