Файл: воронежский государственный университет инженерных технологий.pdf

122
 помимо солидного образования и опыта в области защиты информации
CISO, несомненно, должен обладать стратегическим складом ума, фундаменталь- ными знаниями в управлении и лояльностью к организации.
А для этого недостаточно только технического или технологического образо- вания, так же как и только «защитного». Позицию CISO, скорее всего, будут зани- мать аудиторы или аналитики в области защиты информации.
Контрольные вопросы
1. Какие основные функции объединяет в себе понятие «управление»?
2. Назовите основные виды планирования.
3. В чем заключается технология планирования?
4. Чем определена общая методология оценки безопасности информацион- ных технологий?
5. Каков основной критерий эффективности службы защиты информации?
6. В чем выражаются основные пути и способы повышения эффективности управления службой защиты информации?

123
Лекция 10. ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ
БЕЗОПАСНОСТИ
План
1. Понятие инцидента информационной безопасности.
2. Методы и средства обнаружение и реагирования на инциденты информа- ционной безопасности.
3. Порядок расследования инцидентов информационной безопасности.
Типовые политики информационной безопасности или защитные меры ин- формационной безопасности (ИБ) не могут полностью гарантировать защиту ин- формации, информационных систем, сервисов или сетей. После внедрения защит- ных мер, вероятно, останутся слабые места, которые могут сделать обеспечение ин- формационной безопасности неэффективным, и, следовательно, инциденты инфор- мационной безопасности – возможными.
1. Инцидент информационной безопасности (information security incident): появление одного или нескольких нежелательных или неожиданных событий ИБ, с которыми связана значительная вероятность компрометации бизнес-операций и со- здания угрозы ИБ.
Инциденты ИБ могут быть преднамеренными или случайными (например, яв- ляться следствием какой-либо человеческой ошибки или природных явлений) и вы- званы как техническими, так и нетехническими средствами. Их последствиями мо- гут быть такие события, как несанкционированные раскрытие или изменение ин- формации, ее уничтожение или другие события, которые делают ее недоступной, а также нанесение ущерба активам организации или их хищение.
Ниже приведены некоторые примеры инцидентов ИБ и их причин, которые даются только с целью разъяснения. Важно заметить, что эти примеры не являются исчерпывающими.
Отказ в обслуживании.
Отказ в обслуживании является обширной категорией инцидентов ИБ, имею- щих одну общую черту. Подобные инциденты ИБ приводят к неспособности систем, сервисов или сетей продолжать функционирование с прежней производительно- стью, чаще всего при полном отказе в доступе авторизованным пользователям.
Некоторыми типичными примерами таких преднамеренных технических ин- цидентов ИБ «отказ в обслуживании» являются:
 зондирование сетевых широковещательных адресов с целью полного за- полнения полосы пропускания сети трафиком ответных сообщений;

124
 передача данных в непредусмотренном формате в систему, сервис или сеть в попытке разрушить или нарушить их нормальную работу;
 одновременное открытие нескольких сеансов с конкретной системой, сер- висом или сетью в попытке исчерпать их ресурсы (то есть замедление их работы, блокирование или разрушение).
Одни технические инциденты ИБ «отказ в обслуживании» могут возникать случайно, а другие – преднамеренными. Одни инциденты инициируются намеренно с целью разрушения системы и снижения производительности сети, тогда как другие
– всего лишь побочными продуктами иной деятельности.
Инциденты ИБ «отказ в обслуживании», создаваемые нетехническими сред- ствами и приводящие к утрате информации, сервиса и (или) устройств обработки информации, могут вызываться, например, следующими факторами:
 нарушениями систем физической защиты, приводящими к хищениям, преднамеренному нанесению ущерба или разрушению оборудования;
 случайным нанесением ущерба аппаратуре;
 экстремальными условиями окружающей среды;
 неконтролируемыми изменениями в системе;
 некорректным функционированием программного или аппаратного обес- печения.
Сбор информации.
В общих чертах инциденты ИБ «сбор информации» подразумевают действия, связанные с определением потенциальных целей атаки и получением представления о сервисах, работающих на идентифицированных целях атаки. Подобные инциден- ты ИБ предполагают проведение разведки с целью определения:
 наличия цели, получения представления об окружающей ее сетевой топо- логии и о том, с кем обычно эта цель связана обменом информации;
 потенциальных уязвимостей цели или непосредственно окружающей ее сетевой среды, которые можно использовать для атаки.
Типичными примерами атак, направленных на сбор информации технически- ми средствами, являются:
 сканирование доступных сетевых портов на протокол передачи файлов си- стеме с целью идентификации соответствующих сервисов и версий программного обеспечения;
 сканирование одного или нескольких сервисов с известными уязвимостями по диапазону сетевых адресов;
 зондирование системы с целью идентификации операционной системы хо- ста.

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

126
рования программного или аппаратного обеспечения, приводящих к результатам, рассмотренным выше;
 разрушением устройств физической защиты с последующим несанкциони- рованным доступом к информации.
2. Программа менеджмента инцидентов ИБ предназначена для создания по- дробной документации, описывающей процессы и процедуры обработки инциден- тов ИБ и оповещения (информирования) об инцидентах ИБ. Программа менеджмен- та ИБ приводится в действие при обнаружении события ИБ. Она используется в ка- честве руководства при:
 реагировании на события ИБ;
 определении того, становятся ли события ИБ инцидентами ИБ;
 идентификации полученных уроков при обработке инцидентов, а также необходимых улучшений системы и (или) безопасности в целом;
 реализации идентифицированных улучшений.
Программа менеджмента инцидентов ИБ предназначена для всего персонала ор- ганизации, включая лиц, ответственных за:
 обнаружение и оповещение о событиях ИБ. Эти лица могут быть служа- щими, работающими на постоянной основе или по контракту;
 оценку и реагирование на события ИБ и инциденты ИБ, которые участву- ют в извлечении уроков на этапе разрешения инцидентов ИБ и в улучшениях ИБ и самой программы менеджмента инцидентов ИБ.
Следует также учитывать пользователей третьей стороны, которые сообщают об инцидентах ИБ и связанных с ними уязвимостях, и, кроме того, государственные и коммерческие организации, предоставляющие информацию об инцидентах ИБ и уязвимостях.
В содержание программы менеджмента инцидентов ИБ должны быть включе- ны:
 обзор политики менеджмента инцидентов ИБ;
 общее представление о программе менеджмента инцидентов ИБ в целом;
 детальные процессы и процедуры, информация о соответствующих сер- висных программах и шкалах, связанных:
для этапа «Планирование и подготовка»:
 с обнаружением и оповещением о появлении событий ИБ (человеком или автоматическими средствами);
 со сбором информации о событиях ИБ;
 с проведением оценок событий ИБ, используя принятую шкалу серьезно- сти инцидентов;

127
для этапа «Использование» (в случае подтверждения инцидентов ИБ):
 с оповещением сотрудников своей организации и сторонних лиц или орга- низаций о наличии инцидентов ИБ или любых важных деталях, касающихся инци- дентов;
 с осуществлением немедленного реагирования, которое может включать в себя активизацию процедур восстановления и (или) передачу сообщений соответ- ствующему персоналу согласно анализу и принятым степенями шкалы серьезности инцидентов;
 с проведением правовой экспертизы по степеням шкалы серьезности ин- цидентов ИБ и изменением этих степеней;
 с созданием дополнительных реагирований, включая те, которые могут по- требоваться гораздо позднее;
 в случае отсутствия контроля над инцидентами ИБ с инициированием ан- тикризисных действий (например, вызов пожарной команды или активизация плана обеспечения непрерывности бизнеса);
 с детализацией дальнейшей оценки и (или), если потребуется, дальнейших решений;
 с проверкой правильности регистрации всей деятельности для дальнейше- го анализа;
 с обновлением базы данных событий/инцидентов ИБ.
для этапа «Анализ»:
 с проведением, если потребуется, дальнейшей правовой экспертизы;
 с идентификацией и документированием опыта, извлеченного из инциден- тов ИБ;
 с определением и анализом улучшений ИБ на основе полученного опыта;
 с анализом эффективности процессов и процедур реагирования на инци- денты ИБ;
 с оценкой инцидентов ИБ и восстановления после каждого из них;
 с определением улучшений программы менеджмента инцидентов ИБ в це- лом (на основе полученного опыта);
 с обновлением базы данных событий/инцидентов ИБ;
для этапа «Улучшение» – уточнение на основе полученного опыта:
 с результатами анализа и менеджмента рисков ИБ;
 с программой менеджмента инцидентов ИБ (например, процессами и про- цедурами, формой оповещения и (или) структурой организации);

128
 с общей безопасностью внедрения новых и (или) улучшенных защитных мер;
 с градацией шкалы серьезности событий/инцидентов и соответствующими руководствами;
 с руководством для решения о необходимости интенсификации каждого процесса, для кого должна проводиться интенсификация и в соответствии с какими процедурами.
Персонал, оценивающий событие или инцидент ИБ, должен знать, когда при нормальных обстоятельствах необходимо переходить к интенсификации процессов.
Кроме того, возможно возникновение непредвиденных обстоятельств, когда интен- сификация процессов может стать необходимой. В руководстве должны определять- ся типы событий и инцидентов ИБ, типы интенсификации процессов и лица, кото- рые могут ее проводить:
 с необходимыми процедурами для надлежащей регистрации всех действий в соответствующей форме и проведением анализа журнала регистрации назначен- ным персоналом;
 с процедурами и механизмами поддержания режима контроля изменений, который включает в себя прослеживание событий и инцидентов ИБ, обновление от- чета об инцидентах ИБ и обновление самой программы;
 с процедурами правовой экспертизы;
 с процедурами и руководством по использованию систем обнаружения вторжений (СОВ), обеспечивающими соблюдение связанных с ними правовых и нормативных аспектов.
Перед тем как приступить к работе с программой менеджмента инцидентов
ИБ, необходимо иметь в наличии документированные и проверенные процедуры
1
. В документации по каждой процедуре должны указываться лица из группы эксплуа- тационной поддержки, ответственные за использование и менеджмент этой проце- дуры. Такие процедуры должны включать в себя процедуры сбора и защищенного хранения электронных свидетельств, которые должны непрерывно контролировать- ся на случай судебного разбирательства или дисциплинарного расследования внут- ри организации. Более того, должны существовать документированные процедуры, включающие в себя не только действия группы эксплуатационной поддержки, но и процедуры, задействованные в правовой экспертизе и «антикризисной» деятельно- сти, если они не задействованы где-либо еще, например, в плане обеспечения не- прерывности бизнеса.
1
ГОСТ Р ИСО/МЭК ТО 18044-2007. Информационная технология. Методы и средства обеспече- ния безопасности. Менеджмент инцидентов информационной безопасности.

129
Необходимо иметь в виду, что не все процедуры являются общедоступными.
Например, нежелательно, чтобы весь персонал организации знал подробности о ра- боте группы реагирования на инциденты ИБ (ГРИИБ) при взаимодействии с ней.
ГРИИБ должна обеспечивать наличие «общедоступного» руководства, включая ин- формацию, полученную из результатов анализа инцидентов ИБ, которая находится в легкодоступной форме, например в интранете организации. Более того, иногда не- желательно раскрывать некоторые детали программы менеджмента инцидентов ИБ, чтобы лицо, обладающее конфиденциальной информацией внутри организации (ин- сайдер), не могло помешать процессу расследования.
Содержание рабочих процедур зависит от многих критериев, особенно свя- занных с характером уже известных потенциальных событий и инцидентов ИБ и ти- пами задействованных активов информационных систем и их средой.
Для обработки уже известных типов событий и инцидентов ИБ должны суще- ствовать рабочие процедуры. Необходимы также рабочие процедуры, которым надо следовать, если тип обнаруженного инцидента ИБ или события неизвестен. В этом случае рассматривают следующие аспекты:
 процесс оповещения для обработки таких «исключительных случаев»;
 указания, определяющие время для получения одобрения реагирования на инцидент со стороны руководства.
Для выявления потенциальных дефектов и проблем, которые могут возник- нуть в процессе менеджмента событий и инцидентов ИБ, необходимо запланировать регулярные проверки и тестирование процессов и процедур менеджмента инциден- тов ИБ. Любые изменения, возникающие в результате анализа реагирований на ин- циденты ИБ, должны подвергаться строгой проверке и тестированию.
Быстрое и эффективное реагирование на инциденты ИБ осуществляется го- раздо легче, когда все необходимые технические и другие средства поддержки по- лучены, подготовлены и протестированы. Эти мероприятия включают в себя:
 доступ к деталям активов организации (предпочтительно иметь обновлен- ный перечень активов) и информацию по их связям с бизнес-функциями;
 доступ к документированной стратегии обеспечения непрерывности биз- неса и соответствующим планам;
 документированные и опубликованные процессы передачи информации;
 использование электронной базы данных событий/инцидентов ИБ и техни- ческих средств для быстрого пополнения и обновления базы данных, анализа ее ин- формации и упрощения процессов реагирования;
 адекватные меры по обеспечению непрерывности бизнеса для базы данных событий/инцидентов ИБ.

130
Технические средства, используемые для быстрого пополнения, обновления баз данных, анализа содержания информации и баз данных и облегчения процессов реагирования на инциденты ИБ, должны содействовать:
 быстрому получению отчетов о событиях и инцидентах ИБ;
 уведомлению ранее отобранного персонала подходящими для этого сред- ствами;
 соблюдению предосторожностей, соответствующих оцененным рискам, избеганию прослушивания электронной связи, реализуемой через Интернет или иным образом, во время атаки на систему, сервис и (или) сеть;
 соблюдению предосторожностей, соответствующих оцененным рискам, для сохранения доступности электронной связи, реализуемой через Интернет или иным образом, во время атаки на систему, сервис и (или) сеть;
 процессу сбора всех данных об информационной системе, сервисе и (или) сети и всех обрабатываемых данных;
 использованию криптографического контроля целостности, если это соот- ветствует оцененным рискам;
 упрощению архивирования и защиты собранной информации;
 подготовке распечаток, демонстрирующих развитие инцидента ИБ и про- цесс разрешения инцидента;
 восстановлению штатного режима работы информационной системы, сер- виса и (или) сети.
Атакованная информационная система, сервис и (или) сеть могут функциони- ровать неверно. Поэтому работа технического средства, необходимого для реагиро- вания на инцидент ИБ, не должна быть основана на системах, сервисах и (или) сетях, используемых в организации. По возможности, технические средства реагирования на инциденты должны быть полностью автономными.