с информацией, не должны испытывать особых неудобств при получении доступа к ней.
 |
| Искандер Конеев — начальник отдела безопасности компьютерных систем Национального банка Узбекистана. С ним можно связаться по электронной почте: ikoneev @central.nbu.com. |
Довольно часто злоумышленник может совершать несанкционированные действия, формально находясь в рамках границ, определяемых системой безопасности. Например, сотрудник банка, уполномоченный выполнять платеж (транзакцию), производит перевод денег не на тот счет, который предусмотрен платежным документом, а на другой. С точки зрения компьютерной системы безопасности сотрудник действует в рамках своих полномочий: ему разрешено знакомиться с данными по счетам, проводить по ним платежи и пр. Несанкционированность совершенного платежа может определить только компетентный сотрудник (например, бухгалтер), но никак не рядовой оператор системы информационной безопасности.
Обычный способ предотвращения подобных инцидентов — разделение процедур придания легальности транзакции (например, ее ввода и авторизации) между различными сотрудниками. Эта система будет действовать до тех пор, пока один из ее участников не завладеет правами другого. Самый распространенный случай — захват пароля доступа на ввод или авторизацию. Вот тут на помощь приходят журналы — файлы, в которых регистрируются действия пользователей.
| 1997 | 1998 | |
| Несанкционированный доступ со стороны сотрудников компании | 181437 | 2,81 млн. |
| Кражи внутренней информации | 954666 | 1,67 млн. |
| Намеренное искажение данных или повреждение сетей | 164840 | 86000 |
| Несанкционированный доступ к системным данным посторонних лиц | 132250 | 86000 |
| Злоупотребления доступом в Internet со стороны сотрудников компании | 18304 | 56000 |
| Вирусы | 75746 | 55000 |
В ситуации, которую мы описали, есть несколько возможностей обнаружить несанкционированный платеж.
В частности, если ввод транзакции и ее авторизация проводились с одного и того же рабочего места либо если время между вводом и авторизацией объективно слишком мало и не позволяет авторизатору оценить корректность транзакции, то такой платеж следует изучить внимательно — вполне возможно, что он был произведен некорректно.
Предварительная подготовка
Для того чтобы схема обнаружения подобных нарушений безопасности заработала, необходима большая предварительная работа.
Во-первых, нужно самому себе продекларировать, что вы рассматриваете своих пользователей как потенциальных нарушителей. Это не так уж маловероятно, учитывая, например, статистику состава участников банковских компьютерных преступлений (как правило, это недобросовестные сотрудники банков). Несмотря на кажущуюся простоту этой декларации, необходимость такого подхода не совсем очевидна. Мне приходилось беседовать с западными коллегами, которые считали, что если человек принят на работу, то компания должна ему доверять.
Во-вторых, нужно определить, какие именно угрозы учитываются и анализируются в системе: передача или утрата пароля, корректировка администратором прав пользователя без уведомления службы безопасности или что-то другое. Необходимо запретить реализацию описанных угроз, закрепив этот запрет в правилах, инструкциях, описаниях политик, и ознакомить с этими документами пользователей.
Следующая стадия подготовки носит технический характер и заключается в формировании базы данных, в которой фиксируются параметры пользователей.
Такие базы не всегда входят в состав системы безопасности конкретной прикладной системы, с которой работают пользователи, поэтому ее заполнение может занять некоторое время. Кроме того, в прикладных автоматизированных комплексах, где по каким-либо причинам система безопасности отсутствует, использование такой базы совместно с регистрационным журналом, например, операционной системы может повысить общую безопасность комплекса.
После того как подобная база сформирована, встает задача поддержки ее актуальности. Это значит, что вы должны учитывать, кто из зарегистрированных пользователей уволен, кто находится в отпуске, болеет, отсутствует или не может пользоваться системой, поскольку его учетная запись по каким-либо причинам заблокирована. Для этого необходимо поддерживать оперативный контакт с подразделением по работе с персоналом (отделом кадров).
Итак, подготовительный этап пройден, теперь нужно, чтобы система безопасности (не важно, встроенная или внешняя по отношению к системе, в которой работают пользователи) обеспечила фиксацию в регистрационных журналах всех необходимых данных: кто, в какое время, с какого места, к какому ресурсу системы получал доступ и какие действия выполнял.
Анализ
Собственно обнаружение нарушений безопасности возможно в ходе анализа регистрационных журналов. Нужно обеспечить их регулярный просмотр, причем в тот период времени, когда последствия потенциального ущерба от нарушения будут минимальными.
Способы анализа зависят от объемов обрабатываемых данных. Используя редакторы электронных таблиц или другие средства работы с БД, позволяющие производить сортировку и связывание данных, можно вручную обрабатывать журналы, содержащие значительные объемы информации, но такой труд утомителен, малоквалифицирован — и, следовательно, должен быть автоматизирован.
Для конкретизации задачи по автоматизации обработки регистрационных журналов следует провести классификацию событий, которые, как правило, указывают на возможность нарушения безопасности, и выделить признаки таких событий. Например, об использовании чужого пароля (событие) может свидетельствовать регистрация сеанса работы разных пользователей с одного рабочего места (признак). Еще один настораживающий факт — информация о работе пользователя, который в этот момент совершенно точно отсутствовал на рабочем месте.
Теперь, когда определены события и их признаки, необходимо описать способы обнаружения этих признаков. Нужно указать, совокупность каких параметров будет являться признаком наступления события. Причем не исключено, что для получения полного набора признаков одного события придется анализировать различные журналы. Например, регистрационный журнал автоматизированной платежной системы указывает, что пользователь А работал в системе с двух адресов, физически находящихся в различных местах (на разных этажах здания), однако время работы между двумя сеансами работы в системе (всего несколько секунд) объективно меньше времени, которое требуется, чтобы перейти от одного рабочего места к другому, либо время двух сеансов вообще пересекается. Или другой пример: регистрационный журнал прикладной системы указывает на работу пользователя Б, а регистрационный журнал системы ограничения доступа в здание показывает, что Б в это время отсутствовал в здании.
По ряду признаков специалист, проводивший анализ журнала, не сможет однозначно установить факт нарушения информационной безопасности, однако должен представить отчет, в котором отметить эти признаки как подозрительные.
Реакция на обнаружение события
После обнаружения нарушения безопасности или признаков, которые указывают на такую вероятность, надо выстроить цепочку предположений о причинах происшествия. Для этого следует использовать и другие данные, которые могут не поддаваться автоматизации. Например, обнаружено: пользователь А десять раз ошибся при вводе пароля, что определяется как событие — попытка подбора пароля злоумышленником (предположение 1). Однако затем А сообщил в службу информационной безопасности, что забыл пароль и пытался вспомнить его, подбирая различные значения. Таким образом, мы имеем дело с ошибкой пользователя (предположение 2). Но при дальнейшем исследовании выясняется, что три ошибочных попытки действительно проведены с адреса пользователя А, но еще семь сделаны с другого адреса, удаленного от рабочего места А, причем после седьмой попытки зафиксирован успешный вход пользователя в систему. Таким образом, обнаруживается другое возможное событие — несанкционированное проникновение в систему (предположение 3).
Из построенных предположений необходимо выбрать то, которое соответствует действительности. Для этого нужно провести тщательный анализ всех зафиксированных действий пользователя из всех возможных источников электронной информации, то есть накопить необходимые доказательства нарушения.
Вопрос о юридических доказательствах компьютерного преступления требует специального обсуждения. В рамках же корпоративной политики информационной безопасности необходимо определить факторы, служащие основанием для признания пользователя нарушителем. При этом следует по возможности уберечь службу информационной безопасности от возможных обвинений в подтасовке. Этого можно достичь благодаря хранению исходных версий регистрационных журналов таким образом, чтобы они были доступны службе информационной безопасности только для чтения или не допускали внесения изменений в принципе.
После того как компьютерные доказательства получены, время приниматься за пользователей. Специфика этой работы определяется различными аспектами. Тут и официальный статус службы безопасности в организации, и психологическая подготовка сотрудника, проводившего расследование, и его чувство такта. В любом случае основная задача заключается в сборе дополнительных, некомпьютерных доказательств (например, подтвержденная начальником отдела информация о передаче пароля одного сотрудника другому) или признание пользователя в совершении нарушения. Здесь также многое зависит от того, сочтете ли вы нужным информировать пользователя об обнаружении совершенного им нарушения (и таким образом дать ему возможность подготовится), или же решите с этим подождать. Если факт нарушения безопасности подтвердился, то следует поставить вопрос об административной (а может, и уголовной) ответственности.
В заключение отметим важность профилактики компьютерных преступлений. Если вы обнаружили, что пользователь совершает действия, которые так или иначе настораживают, его следует предупредить, что за ним ведется контроль. Хотя при приеме на работу новых сотрудников могут предупреждать о контроле за их действиями в ИС, реально они почувствуют это, только получив, например, такое предупреждение:
«Уважаемый пользователь!Вчера, используя сервис Интернет, Вы неосторожно зашли на узел www.sex.com, посещение которого не связано с Вашими служебными обязанностями. Обращаем Ваше внимание, что использование Интернета в неслужебных целях запрещено Правилами безопасности. При повторном неслужебном использовании сервиса он будет для Вас отключен.
Служба информационной безопасности».
Настораживающие действия, которые сами по себе не могут быть квалифицированы как нарушения безопасности, тем не менее должны фиксироваться. Периодически просматривая такой перечень, можно обнаружить интересные закономерности в поведении пользователей и своевременно пресечь преступления.
| Какой твой номер? |
В базе данных, описывающей параметры пользователей, мы рекомендуем иметь нижеприведенные пункты. Ясно, что составить полный список будет трудно, а то и невозможно, но даже увязка первых двух параметров может принести существенную пользу.
|