Сегодня большой популярностью пользуется тема реагирования на инциденты информационной безопасности (ИБ). С одной стороны – тема весьма популярна, с другой – она покрыта завесой тайны, ведь именно во время расследования проявляются конкретные уязвимости системы, обнаруживаются следы атак, проверяется квалификация сотрудников ИБ, качество построения системы ИБ.

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

Попробуем кратко перечислить, что же требуется от специалиста подобного рода:

• понимание принципов безопасности;
• знания о слабостях и уязвимостях информационных объектов;
• представление об устройстве Интернет;
• навыки анализа информационных рисков;
• знание сетевых протоколов;
• знание сетевых приложений и сервисов;
• владение вопросами сетевой безопасности;
• владение вопросами безопасности узла или системы; 
  знание о вредоносных программах (вирусы, черви, трояны); 
  навыки программирования.

На Украине существует целый ряд серьезнейших проблем в этой области:

• нет единого центра регистрации инцидентов;
• отсутствует статистика инцидентов;
• отстает законодательство;
• нет открытых методик и стандартов организации процесса реагирования и расследования инцидентов ИБ;
• неясно, как можно подготовиться к такого рода событиям;
• не определено, какие превентивные меры стоит предпринять;      отстает подготовка сотрудников правоохранительных органов.

За рубежом, в свою очередь, существуют стандарты, которые описывают процесс реагирования на компьютерные инциденты. В первую очередь это стандарт NIST Special Publication 800-61 «Computer security incident handling guide». К слову, новая версия ISO 17799:2005 требует наличия процесса реагирования на инциденты (раздел 13 — «Information security incident management»).

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

Что такое инцидент ИБ?

Инцидент, согласно требований IT Infrastructure Library (ITIL), — любое событие, не являющееся частью нормальной работы услуги и ведущее или способное привести к остановке или потере уровня качества этой услуги.

Согласно ISO/IEC TR 18044:2004 инцидент информационной безопасности (information security incident): одно или серия нежелательных или неожиданных событий информационной безопасности, которые имеют значительную вероятность компрометации бизнес-операции и угрожают информационной безопасности.

Основной целью процесса управления инцидентами (Incident Management) является восстановление нормальной работы ИТ-услуги как можно быстрее и минимизация неблагоприятного воздействия сбоя на работу отделов предприятия, что обеспечит согласованный уровень качества услуги.

Организация процесса реагирования на инцидент преследует следующие цели:

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

Примеры инцидентов

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

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

Возможные нарушения требований целостности:

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

Возможные нарушения требований доступности:

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

Обзор общепризнанных практик по управлению инцидентами

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

Так, подобные вопросы описаны в:

• ISO/IEC 27001:2005 Information security management system. Requirements. В данном документе выдвигаются общие требования к построению системы управления информационной безопасности, относящиеся в том числе и к процессам управления инцидентами.
• ISO/IEC TR 18044 Information security incident management. Данный документ описывает инфраструктуру управления инцидентами в рамках циклической модели PDCA. Даются подробные спецификации для стадий планирования, эксплуатации, анализа и улучшения процесса. Рассматриваются вопросы обеспечения нормативно-распорядительной документацией, ресурсами, даются подробные рекомендации по необходимым процедурам.
• CMU/SEI-2004-TR-015 Defining incident management processes for CISRT. Этот документ описывает методологию планирования, внедрения, оценки и улучшения процессов управления инцидентами. Основной упор делается на организации работы CISRT (Critical Incident Stress Response Team) — группы или подразделения, обеспечивающего сервис и поддержку предотвращения, обработки и реагирования на инциденты информационной безопасности. Вводится ряд критериев, на основании которых можно оценивать эффективность данных сервисов, приводятся подробные процессные карты.
• NIST SP 800-61 Computer security incident handling guide. Здесь представлен сборник «лучших практик» по построению процессов управления инцидентами и реагирования на них. Подробно разбираются вопросы реагирования на разные типы угроз, такие как распространение вредоносного программного обеспечения, несанкционированный доступ и другие.

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

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

• Служба ИТ;
• Служба ИБ;
• Отдел кадров;
• Юридическая служба;
• Служба безопасности;
• Бизнес-менеджеры;
• Служба по связям с общественностью и т.д.

Многие компании сейчас создают комиссию по расследованию инцидентов ИБ (Computer Security Incident Response Team — CSIRT), в которую включаются специалисты по решению юридических и технических вопросов.

Основные этапы процесса реагирования на инцидент

Чаще всего инцидент ИБ это проявление комплексной проблемы и потому решать его нужно тоже только комплексно.

Основными этапами реагирования на инцидент являются:

• Подготовка к возможному факту возникновения инцидента. На данном этапе предпринимаются действия для подготовки компании к вероятному инциденту (для минимизирования последствия инцидента и обеспечения быстрого восстановление работы компании).
• Формирование комиссии по расследованию инцидентов (CSIRT). Данный этап, пожалуй, является главнейшим, ведь от компетенции комиссии будет зависеть успех проводимого расследования.
• Обнаружение и идентификация инцидента.
• Регистрация Инцидента:

  o
  Дата, время, порядковый номер отчета; o
  Дата, время возникновения инцидента в сфере безопасности; o
  Данные о докладчике; o
  Заголовок; o
  Детальное описание; o
  Ориентировочная оценка ущерба; o
  Срочность; o
  Организационная единица, в которой произошел или был замечен инцидент; o
  Пострадавшая система или инфраструктура; o
  Контактный орган для справки/осведомления о результатах доклада; o
  Уровень эскалации; o
  Решение.

• Начальное реагирование – фиксирование основных деталей событий, сопровождающих инцидент, сбор и информирование комиссии по реагированию на инцидент, выбор стратегии реагирования, проведение начального расследования.
• Формулировка стратегии реагирования. Стратегия базируется на всех известных на данный момент фактах и определяет наиболее эффективный путь реагирования на инцидент. Стратегия должна подтверждаться руководством компании и определять какие действия будут предприниматься в дальнейшем (возбуждение уголовного дела и т.д.).
• Расследование инцидента. На данном этапе проводится сбор и анализ данных.
• Отчет. Составляется детальный отчет о проделанной работе.
• Решение. Применение полученных выводов, изменение настроек системы ИБ, изменение политики ИБ, обучение сотрудников отдела ИБ на примере инцидента.
  
• Анализ произошедших инцидентов с целью планирования превентивных мер защиты и улучшения процесса обеспечения информационной безопасности в целом.

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

Рассмотрим фазу расследования инцидента более внимательно.

Расследование инцидента

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

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

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

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

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

Процедурные вопросы реагирования на инциденты

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

Пресекать или следить?

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

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

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

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

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

Следующий контрольный перечень помогает сделать выбор между стратегиями «защититься и продолжить» и «выследить и осудить».

Обстоятельства предпочтения стратегии «защититься и продолжить»:

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

Обстоятельства предпочтения стратегии «выследить и осудить»:

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

Заключение

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

Приложение

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

Программно-техническая экспертиза

1. Какую информацию содержат предъявленные на экспертизу системные блоки и дискеты? Какая информация имеется на системных блоках и на магнитных носителях, ее назначение и возможность использования?
2. Какие программы содержатся на предъявленных системных блоках и магнитных носителях? Каково их назначение и возможность использования?
3. Содержатся ли на предъявленных системных блоках и магнитных носителях текстовые файлы? Если да, какое их содержание и возможность использования?
4. Имеется ли уничтоженная информация на представленных магнитных носителях? Возможно ли ее восстановление? Если да, то каково ее содержание, возможности использования?
5. Какие программные продукты содержатся на предъявленных магнитных носителях? Каково их содержание, назначение, возможность использования?
6. Имеются ли на представленных магнитных носителях специализированные программы, используемые для подбора паролей, либо иного незаконного проникновения в компьютерные сети? Если да, то каковы их названия, особенности работы, возможности использования для проникновения в конкретную компьютерную сеть? (Имеются ли признаки, свидетельствующие о применении конкретной программы для незаконного проникновения в вышеуказанную сеть? Если да, то какие?)
7. Какова хронологическая последовательность необходимых действий для запуска конкретной программы либо совершения определенной операции?
8. Возможно ли, работая в данной компьютерной сети, произвести в среде программных продуктов какие-либо изменения программных файлов? Если возможно, то какие, каким образом и с какого компьютера могут быть произведены подобные изменения?
9. Возможно ли получить доступ к финансовой и иной конфиденциальной информации, имеющейся в указанной сети? Каким образом осуществляется такой доступ?
10. Каким образом осуществлено незаконное проникновение в указанную локальную компьютерную сеть? Каковы признаки, свидетельствующие о таком проникновении?
11. Если незаконное проникновение произведено извне, то какие имеются возможности по идентификации компьютера, с которого произошло проникновение?
12. Если отсутствуют признаки вхождения в сеть стороннего пользователя, с каких компьютеров можно произвести подобные операции?

Техническая экспертиза компьютеров и комплектующих

1. Компьютер какой модели представлен на исследование?
2. Каковы технические характеристики его системного блока и периферийных устройств?
3. Каковы технические характеристики данной вычислительной сети?
4. Где и когда изготовлен и собран данный компьютер и его комплектующие?
5. Осуществлялась ли сборка компьютера в заводских условиях или кустарно?
6. Соответствует ли внутреннее устройство компьютера и периферийных устройств прилагаемой технической документации?
7. Не внесены ли в конструкцию компьютера изменения (например, не установлены ли дополнительные встроенные устройства: жесткие диски, устройства для расширения оперативной памяти, считывания оптических дисков и пр., иные изменения конфигурации)?
8. Исправен ли компьютер и его комплектующие?
9. Каков их износ?
10. Каковы причины неисправности компьютера и периферийных устройств?
11. Не содержат ли магнитные носители информации физических дефектов?
12. Не производилась ли адаптация компьютера для работы с ним специфических пользователей (левша, слабовидящий и др.)?
13. Каковы технические характеристики иных электронных средств приема, накопления и выдачи информации (пейджер, электронная записная книжка, телефонный сервер)?
14. Исправны ли эти средства?
15. Каковы причины неисправности?

Диагностические вопросы, разрешаемые экспертизой данных и программного обеспечения

1. Какая операционная система использована в компьютере?
2. Каково содержание информации, хранящейся на внутренних и внешних магнитных носителях, в том числе какие программные продукты там находятся?
3. Каково назначение программных продуктов?
4. Каков алгоритм их функционирования, способа ввода и вывода информации?
5. Какое время проходит с момента введения данных до вывода результатов при работе данной компьютерной программы, базы данных?
6. Являются ли данные программные продукты лицензионными (или несанкционированными), копиями стандартных систем или оригинальными разработками?
7. Не вносились ли в программы данного системного продукта какие-либо коррективы (какие), изменяющие выполнение некоторых операций (каких)?
8. Соответствует ли данный продукт оригинальному техническому заданию (ТЗ) ?
9. Обеспечивается ли выполнение всех предусмотренных функций при его работе?
10. Использовались ли для ограничения доступа к информации пароли, скрытые файлы, программы защиты и др.?
11. Каково содержание скрытой информации?
12. Не предпринимались ли попытки подбора паролей, взлома защитных средств и иные попытки несанкционированного доступа?
13. Возможно ли восстановление стертых файлов?
14. Возможно ли восстановление дефектных магнитных носителей информации?
15. Каково содержание восстановленных файлов?
16. Каков механизм утечки информации из локальных компьютерных сетей, распределенных сетей, глобальной сети Интернет?
17. Имеются ли сбои в функционировании компьютера, работе отдельных программ?
18. Каковы причины этих сбоев?
19. Не вызваны ли сбои в работе компьютера влиянием вируса (какого)?
20. Распространяется ли негативное влияние вируса на большинство программ или он действует только на определенные программы?
21. Возможно ли восстановить в полном объеме функционирование данной программы (текстового файла), поврежденного вирусом?
22. Каково содержание информации хранящейся: на пейджере, в электронной записной книжке и пр.?
23. Имеется ли в книжке скрытая информация и каково ее содержание?
24. Когда производилась последняя корректировка данного файла или инсталляция данного программного продукта?
25. Каков уровень профессиональной подготовки в области программирования и работы с компьютерной техникой лица, произведшего данные действия с компьютером и программным обеспечением?

Вопросы идентификационного характера, разрешаемые компьютерно–технической экспертизой

1. Имеют ли комплектующие компьютера (печатные платы, магнитные носители, дисководы и пр.) единый источник происхождения?
2. Не написана ли данная компьютерная программа определенным лицом (решается комплексно при производстве компьютерно–технической и автороведческой экспертиз)?

Примерный перечень вопросов, разрешаемых при исследовании носителей машинной информации

1. Каков тип носителя, его технические характеристики (на каких типах ЭВМ может быть использован, максимально-допустимая емкость записи)?
2. Имеет ли носитель механические повреждения?
3. Как размечен носитель, в каком формате информация записана на него?
4. Какая информация записана на данный носитель?
5. Как информация фактически размещена на носителе (для лент последовательности записи, для дисков сектора, дорожки, цилиндры и пр.)?
6. Какая информация размещена логически на носителе (файлы, каталоги, логические диски)?
7. Имеются ли повреждения информации (плохие сектора, потерянные блоки и пр.)?
8. Возможна ли коррекция информации на носителе?
9. Имеется ли на носителе компьютерный вирус, если да, то какой, какие изменения вносит и возможна ли его нейтрализация без ущерба для информации?
10. Являются ли изменения на носителе результатом действия вируса?
11. Возможно ли копирование информации с данного носителя и возможно ли физическое копирование носителя в целом?
12. При повреждении носителя, возможно ли восстановление информации?
13. Какая информация ранее была записана на данный носитель (отмечена как стертые файлы) и возможно ли ее восстановление?
14. Какой объем занимает вся информация на носителе, ее отдельные части и сколько имеется свободного места?
15. Какое время занимает копирование данной информации с учетом типа ЭВМ?
16. Требуются ли для работы с информацией на носителе специальные аппаратные или программные средства дешифровки и перекодировки?
17. Нет ли на носителе специальных программ, уничтожающих информацию в случае несанкционированного доступа, отсутствия ключей и паролей или использования на другом компьютере, стоит ли счетчик возможных инсталляций и другие средства защиты, возможен ли обход и каким образом?

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

1. Каково назначение данного программного обеспечения?
2. Могло ли данное программное обеспечение использоваться для совершения данного преступления?
3. Достаточно ли данного программного обеспечения для совершения данного преступления, если недостаточно, то какое программное обеспечение необходимо дополнительно?
4. Кто разработчик данного обеспечения?
5. Каким образом данное программное обеспечение распространяется?
6. Кто является владельцем данной копии?
7. Имеется ли лицензия или разрешение на использование данного продукта?
8. Каков серийный номер данной копии программного обеспечения?
9. С какими входными и выходными данными оно работает, каким образом и в какой форме эти данные вводятся в ЭВМ, создаются ли (а, если создаются, то где) временные файлы и файлы статистики и их содержание, в какой форме выдается, где хранится или куда передается выходная информация?
10. Содержат ли файлы, созданные программным обеспечением, информацию о совершенном преступлении, если содержат, то какую?
11. Требует ли данная программа при своей работе ввода паролей и наличия ключей?
12. Если требует, то каким образом они хранятся и кодируются, имеется ли возможность прочитать файл с паролем с помощью простейших редакторов?
13. Возможен ли обход паролей при запуске программы через отладчик?
14. Имеются     ли     на     машинном     носителе     исходные     коды     программ     на     языке программирования?
15. Когда последний раз вносились изменения в программу (например, по дате и времени создания или внесения изменений в файлы)?
16. Имеются ли в программе изменения по сравнению с исходной версией, что было изменено, к каким последствиям данные изменения приводят?
17. Имеются ли в программе враждебные функции, которые влекут уничтожение, блокирование, модификацию либо копирование информации, нарушение работы ЭВМ, системы ЭВМ или их сети? Каким образом эти функции осуществляются и к каким последствиям приводят?
18. Возможно ли самопроизвольное распространение данной программы, т.е. является ли данная программа вирусом?
19. Возможно ли осуществление копирования информации или требуется инсталляция?
20. Были ли внесены в программу изменения, направленные на преодоление защиты?
21. Какие количественные (занимаемый объем, требуемое количество дискет, количество файлов и пр.) и качественные (назначение конкретных файлов, требование к оборудованию и пр.) характеристики программы?
22. Есть ли соответствие алгоритма работы конкретной программы требованиям, указанным в ТЗ, или заявленным в инструкции по эксплуатации?
23. Имеются ли ошибки при проведении расчетов с помощью данной программы (правильно ли происходит округление чисел, правильный ли алгоритм расчета конкретных данных и пр.)?
24. Имеется ли совместимость программного и аппаратного обеспечения на данном компьютере, если ее нет, то каким образом это влияет на нормальную работу программы?
25. Имеется ли полная совместимость конкретного программного обеспечения с другими программами, выполняемыми на данном компьютере, если нет, то каким образом это влияет на нормальное функционирование системы?

Примерный перечень вопросов при исследовании баз данных

1. Каким образом организована база данных?
2. В каком формате записана информация и какие СУБД могут ее обрабатывать?
3. Какая информация записана в данной базе?
4. Информация в базе записана обычным образом или закодирована?
5. Когда в последний раз обновлялась информация?
6. Имеются ли в данной базе скрытые (помеченные для удаления) поля и их содержание?
7. Имеются ли повреждения или изменения в записях базы по сравнению с эталоном или резервной копией, если да, то какие?
8. Сколько записей в базе?
9. Имеется ли в данной базе запись конкретного содержания?
10. Возможно ли внести изменения в данную базу с помощью простейших программных средств (например, текстовых редакторов и пр.)?

Примерный перечень вопросов при исследовании аппаратного обеспечения ЭВМ

1. Каков тип устройства и его технические характеристики?
2. Исправно ли данное устройство или нет, тип неисправности (отказ или сбой), как она влияет на работу системы в целом?
3. Полностью ли совместимы между собой компоненты данного устройства, если нет, то как это сказывается на его работе?
4. Полностью ли совместимо данное устройство с каким-либо конкретным устройством, если нет, то как это сказывается на их работе?
5. Имеются ли следы ремонта, повреждений, демонтажа микросхем, замены блоков?
6. Соответствует ли комплектация устройства технической документации, если нет, то какие компоненты были изменены, демонтированы?
7. Нет ли в данном устройстве дополнительных блоков (жучков) с враждебными функциями, если есть, то каково их предназначение?
8. Возможно ли на данном оборудовании решать какие-либо конкретные задачи?
9. Какой уровень излучений у данного устройства, возможен ли его прием специальными техническими средствами для последующей расшифровки? Если возможен, то на каком расстоянии?
10. Возможно ли отключение аппаратных средств защиты и как это влияет на работы системы?
11. Соблюдались ли правила эксплуатации?
12. Могла ли данная проблема возникнуть в результате несоблюдения правил технической эксплуатации?