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

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

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

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

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

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

Четвертое достоинство касается связей с прессой. Сведения о компьютерном инциденте могут повредить репутации организации у нынешних или потенциальных клиентов. Эффективная реакция на инцидент уменьшает вероятность нежелательной огласки.

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

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

• обзор (цели, преследуемые политикой безопасности в плане реакции на инциденты;.

• оценка (насколько серьезен инцидент);

• извещение (кого следует известить об инциденте);

• ответные меры (что следует предпринять в ответ на инцидент);

• правовой аспект (каковы правовые последствия инцидента);

• регистрационная документация (что следует фиксировать до, во время и после инцидента).

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

• гарантировать целостность критически важных (для сохранения человеческих жизней) систем;

• сохранить и восстановить данные;

• сохранить и восстановить сервисы;

• выяснить, почему инцидент стал возможен;

• предотвратить развитие вторжения и будущие инциденты;

• избежать нежелательной огласки;

• найти виновников;

• наказать нарушителей.

Важно заранее определить приоритеты действий, совершаемых во время инцидента. Бывают столь сложные случаи, когда невозможно одновременно принять все необходимые ответные меры; без учета приоритетов тут не обойтись. Хотя, как всегда, шкала приоритетов зависит от организации, следующий список может послужить отправной точкой при выработке иерархии ответных мер: • первый приоритет - защитить жизнь и здоровье людей; при всех обстоятельствах защита человеческих жизней должна стоять на первом месте;

• второй приоритет - защитить секретные и/или критически важные данные (в соответствии с правительственными или организационными нормами);

• третий приоритет - защитить прочие данные, включая частную, научную и управленческую информацию, поскольку потеря данных обходится дорого с точки зрения ресурсов, затраченных на их накопление;

• четвертый приоритет - предотвратить повреждение систем (потерю и изменение системных файлов, повреждение дисководов и т. п.), чтобы избежать дорогостоящих простоев и восстановлений;

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

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

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

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

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

Оценка А что на самом деле? На этой фазе точно выясняется характер проблем. Конечно, многие, если не большинство, проявлений, часто приписываемых вирусным инфекциям или вторжениям злоумышленников, являются следствием обычных отклонений, таких, как аппаратные сбои. Чтобы понимать, действительно ли имеет место нарушение режима безопасности, полезно приобрести и использовать специальное программное обеспечение. Например, широко доступные программные пакеты могут оказать существенную помощь в выявлении вируса, проникшего в Macintosh. Весьма полезна и регистрационная информация, особенно применительно к сетевым атакам. При подозрениях на вторжение чрезвычайно важно сделать моментальный снимок системы. Многие инциденты порождают целую цепь событий, и снимок системы, сделанный на начальной стадии, может оказаться полезнее других мер для установления сути проблемы и источника опасности. Наконец, важно завести регистрационную книгу. Запись системных событий, телефонных разговоров, временных меток и т. д. способна ускорить и систематизировать процесс идентификации проблемы, послужить основой последующих действий по нейтрализации инцидента.

Имеется ряд отчетливых признаков, или «симптомов», инцидента, заслуживающих особого внимания:

• крахи системы;

• появление новых пользовательских счетов (например, необъяснимым образом создался счет RUMPLESTILTSKIN) или необычайная активность со стороны пользователя (счета), практически не подававшего признаков жизни в течение нескольких месяцев;

• новые файлы (обычно со странными именами, такими, как data.xx или к);

• рассогласования в учетной информации (например, на UNIX-системах это может проявляться как сокращение файла /usr/admin/lastlog, что вызывает сильные подозрения в присутствии нарушителя);

• изменения в размерах и датах файлов (например, пользователя MS-DOS должно насторожить внезапное удлинение. ЕХЕ-файла более чем на 1 800 байт);

• попытки записи в системные файлы (например, системный администратор замечает, что привилегированный пользователь VMS пытается изменить RIGHTSLIST.DAT);

• модификация или удаление данных (например, начали исчезать файлы);

• отказ в обслуживании (например, системные администраторы и все остальные пользователи оказались выброшенными из UNIX-системы, которая перешла в однопользовательский режим);

• необъяснимо низкая производительность системы (например, необычно плохое время отклика системы);

• аномалии (например, на экране терминала вдруг появляется слово GOTCHA или раздаются частые и необъяснимые звуковые сигналы);

• подозрительные пробы (например, многочисленные неудачные попытки входа с другого узла сети);

• подозрительное «рысканье» (например, некто стал пользователем root UNIX-системы и просматривает файл за файлом).

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

Масштабы инцидента. Идентификации инцидента сопутствует выяснение его масштабов и возможных последствий. Для эффективного противодействия важно правильно определить границы инцидента, Кроме того, оценка возможных последствий позволит установить приоритеты при выделении ресурсов для принятия ответных мер. Без выяснения масштабов и возможных последствий события трудно определить, как именно нужно действовать.

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

• затрагивает ли инцидент несколько организаций;

• затрагивает ли инцидент многие компьютеры вашей организации;

• находится ли под угрозой критически важная информация;

• какова стартовая точка инцидента (сеть, телефонная линия, локальный терминал и т.

д);

• знает ли об инциденте пресса;

• каков потенциальный ущерб от инцидента;

• каково предполагаемое время ликвидации инцидента;

• какие ресурсы требуются для ликвидации инцидента.

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

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

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

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

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

Извещение конкретных лиц. Кого извещать во время и после инцидента? На этот предмет можно рассмотреть несколько категорий лиц:

• персонал в точках контакта (техническая и административная группы, группа реагирования, органы дознания, другие правоохранительные органы, производители, поставщики услуг). Необходимо определить, кто отвечает за извещения в адрес каждой из перечисленных контактных групп;

• более широкое сообщество (пользователи);

• другие организации, вовлеченные в инцидент.

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

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

Если пресс-центра нет, следует тщательно взвешивать сообщаемые прессе сведения.

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

Хотя заранее сложно определить, насколько детальные сведения стоит сообщать прессе, разумно учесть следующие соображения:

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

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

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

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

• не позволяйте прессе отвлекать ваше внимание от реакции на инцидент. Постоянно помните, что успешная борьба с нарушением - дело первостепенной важности.

Чьей помощью воспользоваться? В мире существует довольно много групп реагирования на нарушения информационной безопасности (например, CERT, CIAC). Аналогичные группы имеются во многих важных правительственных агентствах и больших корпорациях. Если у вашей организации есть контакты с подобной группой, с ней необходимо связаться в первую очередь и как можно раньше. Такие группы отвечают за координацию реакции на инциденты нескольких организаций или более крупных сообществ. Даже если кажется, что нарушение затрагивает только одну организацию, информация, доступная через группу реагирования, способна помочь успешной борьбе с нарушением. При выработке политики, касающейся реакции на инциденты, может быть принято решение о создании собственной группы реагирования по типу существующих, отвечающей перед организацией за борьбу с нарушениями информационной безопасности. Если группа создана, ей необходимо наладить взаимодействие с аналогичными структурами - во время инцидента налаживать доверительные отношения гораздо труднее.

Ответные меры Важная тема, которой мы пока не касались, - это реальные меры, предпринимаемые для борьбы с нарушением. Их можно подразделить на следующие основные категории: сдерживание, ликвидация, восстановление, «разбор полетов».

Сдерживание. Цель сдерживания - ограничить атакуемую область. Например, важно как можно быстрее приостановить распространение «червя» в сети. Обязательной частью сдерживания является принятие решений (останавливать ли систему, отсоединять ли ее от сети, отслеживать ли ее работу и события в сети, устанавливать ли ловушки, отключать ли некоторые сервисы, такие, как удаленная пересылка файлов в ОС UNIX и т. д.). Иногда подобные решения очевидны. Если риску подвергается секретная, конфиденциальная или частная информация, систему нужно остановить. В некоторых случаях стоит пойти на риск, связанный с нанесением системе определенного ущерба, если поддержание ее работы способно помочь в идентификации злоумышленника.

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

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

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

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

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

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

Человек, находящийся в единой точке контакта, может быть, а может и не быть руководителем работ по борьбе с нарушением. В принципе речь идет о двух разных ролях, для которых нужно подобрать «исполнителей». Руководитель работ принимает решения (например, он интерпретирует политику безопасности применительно к происходящим событиям). На него возлагается ответственность за реакцию на инцидент. Напротив, непосредственная функция точки контакта состоит в координации усилий всех сторон, вовлеченных в ликвидацию инцидента.

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

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

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

Регистрационная документация Целесообразно документировать все детали, связанные с инцидентом. В результате вы получите информацию, незаменимую для восстановления хода событий. Детальное документирование в конечном итоге ведет к экономии времени. Если, например, не зафиксировать телефонный звонок, вы, скорее всего, забудете почти все, что вам сообщили. В результате придется звонить еще раз и повторно получать информацию. При этом будет потрачено и ваше, и чужое время, что едва ли можно считать приемлемым. Фиксация деталей поможет и при проведении расследования. Далее, документирование инцидента позволяет оценить размер нанесенного ущерба (что необходимо и вашему руководству, и правоохранительным органам) и организовать «разбор полетов», из которого можно извлечь полезные уроки.

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

• все системные события (приобщите к документации системный регистрационный журнал);

• все ваши действия (с указанием времени);

• все телефонные переговоры (имя собеседника, дата, время и содержание разговора).

Самый простой способ сохранить документацию - записывать все в регистрационную книгу. Это избавит вас от поиска среди разрозненных листов бумаги и предоставит в случае необходимости централизованный, упорядоченный по времени источник информации. Большая часть записанных сведений может понадобиться в случае судебного рассмотрения. Таким образом, если вы начали подозревать, что инцидент приведет к расследованию, или когда расследование уже началось, необходимо регулярно (например, ежедневно) относить в архив подписанные вами копии страниц регистрационной книги вместе с другими необходимыми носителями информации, чтобы сохранить их в надежном месте. Разумно потребовать квитанцию о сдаче документации на хранение, с подписью и датой. Если всего этого не сделать, суд может не принять Ваших показаний. Выработка мер, предпринимаемых после нарушения Обзор

После ликвидации нарушения режима информационной безопасности необходимо предпринять ряд действий, а именно:

• произвести переучет системных активов, то есть тщательно проверить, как инцидент повлиял на состояние систем;

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

• произвести новый анализ риска с учетом информации, полученной вследствие инцидента;

• должно быть начато следствие против виновников инцидента, если это признано необходимым.

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

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

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

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

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

Оценивая ущерб. Прежде чем начинать восстановительные работы, необходимо уяснить истинные размеры ущерба. Возможно, на это уйдет много времени, но зато появится понимание природы инцидента и будет заложена база для проведения расследования. Лучше всего сравнивать текущее состояние с резервными копиями или с лентами, полученными от поставщика; еще раз напомним: предварительная подготовка - ключевой элемент восстановления. Если система поддерживает централизованное ведение регистрационного журнала (как правило, так и бывает), перемещайтесь по журналу назад и отмечайте аномалии.

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

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

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

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

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

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

Ресурсы:

дополнительные устройства и методы обеспечения безопасности;

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

хранилище книг, списков, источников информации;

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

сформируйте подгруппу.

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

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

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

Руководство по информационной безопасности предприятия (site security handbook, rfc 1244) | Политики информационной безопасности | Политики безопасности


Политики информационной безопасности



Новости за месяц

  • Июль
    2019
  • Пн
  • Вт
  • Ср
  • Чт
  • Пт
  • Сб
  • Вс