19 Июня, 2011

ИнцЫдент МанагеМент

Алексей Волков
Слушая доклады коллег на тему борьбы с утечками на 4 форуме директоров по ИБ  я, как и Ригель, отметил странную тенденцию: почему-то все чаще и чаще встречается мнение, что инцидент - это когда уже все плохое, что могло произойти - уже произошло, ИБ-шники вместе с компетентными органами начинают "стрелять по хвостам" в поисках виновных и, в случае отыскания, корчиться в попытках привлечения их к ответственности. По сути, именно такая прадигма заложена в рекомендациях Leta IT , хорошую рецензию на которые написал Алексей Лукацкий . Такая прадигма являет собой смысл выражения "хорошая мина при плохой игре" и свойственна всей нашей правоохранительной системе (т.н. "ментовской" или "палочный" подход) : мягкое место отрывается от стула в лучшем случае тогда, когда субъект уже мертв, а объект утрачен безвозвратно. Это - плохой подход с никому не нужным, выдаваемым для "галки" результатом, и если ИБ-шник этим бахвалится - будьте уверены: в его организации ИБ никого не ИБ. Почему - покажу на близком к реальному примере. Однажды менеджер по продажам одной торгово-закупочной организации, ковыряясь в интернете, обнаружил на одном из сайтов предложение о продаже базы клиентов его собственной фирмы. Проявив сознательность, он немедленно сообщил об этом руководству, и закрутилось-понеслось. Безопасность зарегистрировала инцидент и начала ковырять всех и вся, и подключила к расследованию (на хороших отношениях) правоохранительные органы. Вместе со службой ИТ они выяснили, что один из терминальных серверов компании день назад был взломан неизвестным злоумышленником и, судя по логам, именно через него и была похищена клиентская база. Правоохранительные органы проявили сознательность и немедленно возбудили дело по статье 272 УК РФ (неправомерный доступ к компьютерной информации). После проведения оперативно-следственных мероприятий было установлено, что к делу причастен бывший ИТ-специалист этой фирмы, отвечавший за обслуживание терминальных серверов и уволившийся аккурат за неделю до регистрации инцидента. Одновременно с этим, служба ИТ сообщила, что взломанный терминальный сервер вообще не должен был "светить" в открытом доступе, поэтому злоумышленник переконфигурировал сеть ненадлежащим образом и воспользовался своей собственной учетной записью. А кадровая служба сообщила о том, что должностная инструкция уволенным сотрудником почему-то не подписана, и в трудовом договоре в месте, где должна быть подпись об ознакомлении с внутренней организационно-распорядительной документацией, подписи тоже нет. "Вот везде есть, а вот там - нет" - сказал начальник отдела кадров, разведя руками. Руками развели и правоохранительные органы: нет подписей - нет и 274-й УК РФ (нарушение правил эксплуатации ЭВМ, системы ЭВМ или их сети). Оперативники под видом потенциального покупателя вышли на контакт со злоумышленником, при покупке за 10 тысяч меченых рублей его взяли с поличным, но поскольку в организации не было установлено режима коммерческой тайны, похищенная информация не находилась на балансе фирмы и не была оценена, какой-либо материальный ущерб отсутствовал, иных фактов продажи информации установлено не было, а сам обвиняемый нигде не работал и пошел на сделку со следствием - суд ограничился исправительными работами сроком на 6 месяцев. Объявление о продаже, само собой, было удалено, служба безопасности с гордостью внесла эту победу в свои скрижали, а оперативники отчитались об успешно проведенной операции и заработали премию. Есть ли толк от всего этого для владельца информации? Ответ очевиден - нет. Ценные сведения украдены, неограниченный круг лиц, среди которых, безусловно, есть конкуренты, их получил, а ущерб так и не был компенсирован. И вроде все молодцы, сработали хорошо, как по учебнику, да, есть недостатки, но все же выхлоп от этого - практически нулевой. Давайте попробуем разобраться, почему так вышло, как этого можно было избежать и самое главное - что в этой ситуации должно быть инцидентом и как правильно нужно реагировать. На рисунке ниже - диаграмма развития инцидента, разбитая на 6 этапов. Полагаю, пояснять их долго не нужно: идея украсть клиентскую базу с целью ее продажи (1), умышленное неподписание документов, переконфигурация сети и увольнение (2), собственно несанкционированный доступ (3), получение данных и размещение объявления о продаже (4) и получение денег (5). Где же начало инцидента? Очевидно, в кружочке "замысел" - на 1 этапе. Можно ли как-то обнаружить? Безусловно, нет - в голову не залезешь. Однако его можно постараться предотвратить: тщательней отбирать персонал, усиленно беседовать и инструктировать (промывать мозги), наконец - предлагать проверку на детекторе лжи. Дикость? Отнюдь - все больше и больше компаний использует эту практику для ключевого персонала, тем самым отсекая большинство нарушителей еще на первом этапе. В классической, хорошо выстроенной СУИБ, раннее обнаружение инцидента (напоминаю, что мы рассматриваем прадигму "инцидент = компьютерное преступление") должно автоматически происходить на 2 этапе. В нашем случае отсутствие подписи в документах должна была обнаружить кадровая служба, и если вдруг она это пропустила, то служба ИБ уж точно должна была выявить (например, путем регулярной проверки правильности подписания документов). Если бы в компании была налажена система управления изменениями в ИТ-инфраструктуре, просто так переконфигурировать сеть было бы весьма затруднительно. В идеальном случае - кадровая служба, обнаружив факт отсутствия подписей сразу после возврата документов от сотрудника, добилась бы их подписания и сообщила бы об этом службе ИБ, которая, в свою очередь, должна поставить его деятельность под особый контроль. После увольнения системного администратора, служба ИТ должна была сменить пароли административных учетных записей и провести инструментальную проверку настройки локальной сети предприятия - тем самым уязвимость могла быть обнаружена между 2 и 3 этапом и своевременно устранена. Наконец, если бы существовал мониторинг информационных систем (на худой конец, правильно эксплуатируемая IPS), то инцидент можно было обнаружить на этапе его реализации (3). Однако если ничего этого нет и в помине - все, что остается - регистрировать инцидент после его окончания и расследовать его как компьютерное преступление (этап 4, в нашем случае дело фактически дошло до 5 этапа). При этом компания должна хотя бы самой себе признаться, что главная задача системы безопасности - предотвращение и профилактика - не выполнена. Конечно, ситуации бывают всякие, и пример этот - лишь один из миллионов вариантов развития событий, но если к обеспечению безопасности подходить не кусочно, а комплексно, то шансов столкнуться с инцидентом по версии Leta будет гораздо меньше, а момент его регистрации будет перенесен на самый ранний этап, и на пути развития инцидента будет возведено несколько защитных барьеров, существенно снижающих вероятность эскалации его до точки "полной G".
или введите имя

CAPTCHA