По чьей вине чаще всего происходят инциденты информационной безопасности в компаниях

Управление и ответственность в системах защиты информации от утечки

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

Управление событиями и инцидентами в системах защиты от утечки информации

В современных DLP все это максимально автоматизировано. При внедрении решения в нем задаются правила и политики, по которым фильтруется контент, и обрабатываются события, происходящие в защищаемой системе. DLP следит за 3 видами сущностей: люди, информация и нарушения. Все, что происходит в защищаемом периметре, — это события (отправка файлов, переписка, копирование каких-то файлов на внешние носители и так далее). Каждое событие анализируется по установленным правилам и политикам. В случае обнаружения отклонений возникает инцидент информационной безопасности. На этом этапе управление переходит к специалисту по ИБ (офицеру ИБ). Инцидент обрабатывается, и на основе полученных результатов принимается решение (назначение расследования, блокировка определенных действий для пользователя, усиление контроля и так далее).

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

Зона ответственности специалиста по ИБ при использовании DLP-решения в компании

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

• ответственность за защиту от утечек конфиденциальных данных не должна быть дополнительной нагрузкой для IT-специалистов в добавок к их основному профилю. Эксперты не рекомендуют в целях экономии «навешивать» такие функции, например, на системных администраторов или сотрудников службы технической поддержки. За работу DLP-системы и других решений должен отвечать отдельный специалист (группа сотрудников);

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

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

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

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

Ответственность рядовых сотрудников за утечки

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

Еще один аргумент в пользу необходимости оповещения работников об использовании средств обеспечения ИБ, и DLP, в частности, — требования законодательства. Работодатель обязан оповещать сотрудников об использование средств контроля. А системы защиты от утечек как раз относятся к ним, т.к. могут контролировать рабочее время, действия сотрудников с файлами, переписку и другие параметры.

СДО для вагонников

Ответы для вагонников на часто встречающиеся вопросы в системе дистанционного образования ОАО«РЖД» (http://sdo.rzd.ru)

• ОБЩАЯ ИНФОРМАЦИЯ 
• СТАТИСТИКА 
• НАШУМЕВШИЕ ИНФОРМАЦИОННЫЕ ИНЦИДЕНТЫ
• ТЕНДЕНЦИИ ПОСЛЕДНИХ ЛЕТ И ПРОГНОЗЫ

ОБЩАЯ ИНФОРМАЦИЯ И СТАТИСТИКА 

Компании разных организационно-правовых форм, размеров и форм собственности регулярно сталкиваются с инцидентами информационной безопасности. Этот показатель из года в год растёт параллельно с увеличением дефицита специалистов в области ИБ и приближается к 100%: большинство компаний столкнулись хотя бы с одним инцидентом , вызванным внешними или внутренними факторами.

По отчету управления по раскрытию преступлений в сфере высоких технологий МВД Республики Беларусь почти 75% киберпреступлений в Беларуси связаны с хищениями. Анализ криминогенной обстановки свидетельствует, что количество выявленных преступлений в сфере высоких технологий в 2017-м году по сравнению с 2016-м годом увеличилось на 25,4% (с 2471 до 3099). «Почти три четверти злодеяний в киберпространстве связаны с хищениями путем использования компьютерной техники.

Кроме того, на 20% (с 651 до 781) увеличилось количество выявленных преступлений против информационной безопасности. В первую очередь это обусловлено ростом числа фактов неправомерного завладения компьютерной информацией (с 13 до 29), а также случаев модификации компьютерной информации (с 13 до 25) и несанкционированного доступа к компьютерной информации (с 258 до 462).

В 2017-м году сотрудники подразделений по раскрытию преступлений в сфере высоких технологий криминальной милиции Министерства внутренних дел Беларуси установили 1052 причастных к киберзлодеяниям граждан, что на 86 человек больше, чем в 2016 году. Сумма ущерба от противоправных действий в виртуальном пространстве в 2017 году составила Br3,2 млн.

ОБЩАЯ СТАТИСТИКА 

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

Процентное соотношение инцидентов информационной безопасности: 

1. Вредоносное ПО — 77%
2. Спам — 74%
3. Фишинговые атаки — 28%
4. Корпоративный шпионаж — 26%
5. Сетевые вторжения — 23%
6. Отказ в обслуживании (Dos, DDos- атаки) — 18%
7. Кража мобильных устройств — 17%
8. Кража сетевого, компьютерного и др. оборудования — 11%
9. Таргетированные (целевые) атаки — 10%
10. Преступное вредительство — 5% 
11. Иные инциденты — 2% 

Процентное соотношение убытков, понесенных предприятиями от инцидентов ИБ:

1. Вредоносное ПО — 46%
2. Корпоративный шпионаж — 19%
3. Сетевые вторжения — 14%
4. Фишинговые атаки — 14%
5. Кража мобильных устройств — 13%
6. Отказ в обслуживании (Dos, Ddos — атаки) — 11%
7. Кража сетевого, компьютерного и др. оборудования — 9%
8. Таргетированные (сетевые) атаки — 5%
9. Преступное вредительство — 4%

Одним из основных последствий осуществлённой злоумышленниками успешной кибератаки (независимо от типа и способа) становится потеря организацией критической с точки зрения информационной безопасности информации. Атаки с использованием вредоносного ПО являются не только самыми распространенными, но и самыми опасными: они приводили к утечке подобной информации в 46% случаев и в 14% случаев компании теряли информацию из-за фишинговых атак.

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

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

Процентное соотношение внутренних угроз ИБ: 

1. Уязвимости в ПО — 48%
2. Случайная утечка информации по вине персонала — 36% 
3. Намеренная утечка информации- .23%
4. Утечка из-за ненадлежащего обмена информацией — 21% 
5. Потеря мобильных устройств — 20%
6. Мошенничество сотрудников не связанное с IT — 19%
7. Утечка информации через привлекаемых поставщиков — 12%
8. Иные инциденты, связанные с внутренними факторами — 13%

Главными рисками внутри компаний являются уязвимости в ПО (48%), незнание сотрудниками правил IT-безопасности, приводящее к случайным утечкам данных (36%), а также намеренное раскрытие конфиденциальной информации сотрудниками (23%). Разумеется, все эти типы угроз приводили к потере компаниями критической секретной информации. В среднем в результате внутренних инцидентов ИБ лишились конфиденциальных сведений около 24% организаций. 

ПРИМЕРЫ НАШУМЕВШИХ ИНЦИДЕНТОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ

«Логическая бомба» Роджера Дуронио

В отместку за слишком маленькую премию и увольнение 63-летний Рожер Дуронио (бывший системный администратор компании UBS Paine Webber) установил на серверах компании «логическую бомбу», которая уничтожила все данные и парализовала работу компании на продолжительное время.

Внедрение «логической бомбы» Дуронио осуществил с домашнего компьютера за несколько месяцев до того, как получил слишком маленькую, на его взгляд, премию. «Логическая бомба» была установлена примерно на 1500 компьютеров в сети филиалов по всей стране и настроена на определенное время — 9.30, как раз на начало банковского дня .

Уволился Дуронио из UBS Paine Webber 22 февраля 2002 г., а четвертого марта 2002 г. «логическая бомба» последовательно удалила все файлы на главном сервере центральной базы данных и 2000 серверов в 400 филиалах банка, при этом отключив систему резервного копирования.

Кроме того, Дуронио решил заработать на атаке: ожидая падения акций банка в связи с ИТ-катастрофой, он сделал фьючерсную заявку на продажу, чтобы при снижении курса получить разницу. На это обвиняемый потратил 20 000 долларов. Однако бумаги банка не упали, а инвестиции Дуронио не окупились.

Заложенная Дуронио «логическая бомба» остановила работу 2000 серверов в 400 офисах компании. В компании воцарился хаос, который почти сутки устраняли 200 инженеров из IBM. Всего над исправлением ситуации работало около 400 специалистов, включая ИТ-службу самого банка. Ущерб от случившегося оценивают в 3,1 млн долларов. Восемь тысяч брокеров по всей стране вынуждены были прекратить работу. Некоторым из них удалось вернуться к нормальной деятельности через несколько дней, некоторым — через несколько недель, в зависимости от того, насколько сильно пострадали их базы данных и осуществлялось ли в филиале банка резервное копирование.

В целом же банковские операции были возобновлены в течение нескольких дней, однако работа некоторых серверов так и не была восстановлена в полном объеме, в большей степени из-за того, что на 20 % серверов не было средств резервного копирования. Только через год весь серверный парк банка снова был полностью восстановлен.

Крупнейшая утечка персональных данных за всю историю Японии

Японская фирма Dai Nippon Printing, специализирующаяся на выпуске полиграфической продукции, допустила крупнейшую утечку в истории своей страны. Хирофуми Йокояма, бывший сотрудник одного из подрядчиков компании, скопировал на мобильный винчестер и украл персональные данные клиентов фирмы. В общей сложности под угрозу попали 8,64 млн человек, так как похищенная информация содержала имена, адреса, телефоны и номера кредитных карт. В похищенной информации содержались сведения о клиентах 43 различных компаний, например о 1 504 857 клиентах компании American Home Assurance, 581 293 клиентах компании Aeon Co и 439 222 клиентах NTT Finance .

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

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

В результате данного инцидента убытки граждан, которые пострадали из-за мошенничества с кредитными картами, ставшего возможным только вследствие этой утечки, составили несколько миллионов долларов. Всего пострадали клиенты 43 различных компаний, в том числе Toyota Motor Corp., American Home Assurance, Aeon Co и NTT Finance. 

Запорожский хакер против украинского банка

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

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

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

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

Уволившись, бывший системный администратор решил вернуть у бывшего руководства интерес к своей персоне посредством использования несовершенства применяемой практически во всех банках Украины системы «Банк-Клиент»2. План системного администратора состоял в том, что он решил разработать свою программу защиты и предложить ее банку, вернувшись на свое прежнее место работы. Реализация плана заключалась в проникновении в систему «Банк-Клиент» и внесении в нее минимальных изменений. Весь расчет был сделан на то, что в банке должны были обнаружить взлом системы.

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

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

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

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

В действительности системный администратор рассчитывал на то, что денежные средства не будут переведены, что факт взлома будет обнаружен до перевода средств, но на практике все оказалось по-другому и он стал преступником и его липовый перевод перерос в кражу.

Факт взлома и хищения денежных средств в особо крупных размерах были обнаружены только через несколько часов после перевода, когда работники банка позвонили на таможню — подтвердить перевод. Но там сообщили, что такую сумму никто не перечислял. Деньги в срочном порядке были возвращены назад в банк, а в прокуратуре Запорожской области заведено уголовное дело.

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

Инциденты ИБ в Республике Беларусь: 

• В 2010 году ученик одиннадцатого класса средней школы г. Смолевичи ради развлечения взломал ряд ПК пользователей, а также информационные системы нескольких предприятий, среди которых СМУ ОАО «Промтехмонтаж» г. Солигорск, быховский УКП «Бытуслуги», РУП «Гомельское ПО «Кристалл». Школьник уничтожил архивы сетевых дисков подразделений, образ операционной системы компьютера сисадмина, базы данных специализированных программ. На восстановление информации у работников предприятия ушли недели, убытки от шалости школьника оцениваются сотнями миллионов рублей. 
• В мае 2012 года двое жителей Витебска получили несанкционированный доступ к базам данных РУП «Белтелеком». Злоумышленники изменили пароли и коды доступа пользователей информационной системы, после чего некоторое время контролировали их личные счета.
•  В апреле 2014 года житель Слуцка, работавший системным администратором, имел доступ к редактированию данных в интернет-магазине, электронным базам данных предприятия. За нарушение трудового контракта был уволен. В качестве мести он взломал систему защиты и удалил около 140 тысяч файлов, что привело к потере части прибыли коммерческого предприятия и большим временным затратам на восстановление информации.
• В июле 2014 года неизвестный хакер взломал сервер электронной почты и получил доступ к электронным ящикам частной фирмы, написал ее работникам ряд писем от имени зарубежных деловых партнеров. В своем сообщении он уверял, что банковский счет, куда нужно перечислять деньги, изменился. Работники фирмы поверили ему и исправно переводили деньги злоумышленнику. Так ему удалось получить 7000 евро и 6000 долларов США.
• Также в 2014 году имел место довольно известный инцидент, хакер взломал сайт производителя белорусского печенья «Слодыч» и менял названия в графе «Наша продукция»: вместо печенья «Сдобного» появлялись то «говняшка», то «обсирашка», то прочие не менее остроумные названия. Инцидент продолжался более недели и обошел весь белорусский твиттер и социальные сети. Компании был нанесен серьезный рейтинговый ущерб.
• В сентябре 2014 года неизвестными через Интернет были атакованы номера из баз сотовых операторов. Многие абоненты получили сообщения в которых предлагалось пройти по определенной ссылке и скачать фотографию. Во многих случаях смс приходили от людей, чьи имена записаны в телефонной книге. Вместе с фото на мобильник загружалась вредоносная программа, которая начинала самостоятельно отправлять сообщения с зараженного телефона. Пострадавшие заявляют об ущербе на сотни тысяч рублей.
•  В апреле 2015 года была предпринята очередная, но весьма массированная атака хакреов на информационную систему РУП «Белтелеком». Долгое время отсуствовала связь с сайтами, расположенными в ЦОД РУП «Белтелеком». По некоторым данным были выведены из строя системы хранения данных. 
• В мае 2015 года сайт Центрального избирательного комитета Беларуси взломали неизвестные и разместили фотографии с силуэтами людей с оружием на фоне флага Курдистана. 
• Также в 2015 году подверглись DoS-атакам многие белорусские сайты, в рейтинге самых крупных DDOS-атак Беларуси занимает известный портал Tut.by, второе место с уровнем мощности трафика 8-12 Гбит/с принадлежит атаке на портал Onliner.by DDOS-атаке предшествовал анонимный звонок с угрозой, но без объяснения причин и целей. Подвергался атакам и сайт Президента Республики Беларусь, сайты ряда других организаций в общей сложности более двух десятков. 

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

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

ТЕНДЕНЦИИ ПОСЛЕДНИХ ЛЕТ И УГРОЗЫ

2017-Й год стал показательным для бизнеса в контексте информационной безопасности. Выражение «лучше один раз увидеть, нежели сто раз услышать» — как раз о нем. Столкнувшись с вирусами-шифровальщиками, компании прочувствовали на себе важность элементарных правил ИБ-гигиены. Отсутствие актуальных обновлений и привычка жить с уязвимостями привели к остановке заводов Renault во Франции, Honda и Nissan в Японии; пострадали банки, школы, энергетические, телекоммуникационные компании; только лишь одна компания Maersk потеряла 300 млн долларов. На фоне информационного цунами, вызванного вирусами-вымогателями, некоторые важные события остались за пределами массового внимания. 

Перечислим основные тренды в инцидентах ИБ за последние год-два в мире кибербезопасности: 

• Практическая безопасность. С бумажной безопасностью начали бороться на самом высоком уровне. Например, федеральный закон РФ N 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации» не просто рекомендует, а обязывает компании различных отраслей (как государственные, так и коммерческие) защищаться и вводит механизмы контроля эффективности защитных мер. 
• Уязвимости SS7 заметили. Злоумышленники начали перехватывать коды для двухфакторной аутентификации с помощью уязвимостей сигнального протокола SS7. Первыми пострадали абоненты O2- Telefonica. 
• «Масштабируемые» атаки на банкоматы. Банкоматы грабят давно и разными способами, например, привязывают к тросу автомобиля и увозят. Но когда киберпреступники стали подключаться к локальной сети банка и удаленно контролировать множество ATM, у банков появился серьезный повод для беспокойства. 
• Тайный майнинг. Весной 2017 года эксперты сферы ИБ обнаружили сотни компьютеров в крупных компаниях, которые майнили криптовалюту для неизвестных взломщиков. Майнер использовал ту же уязвимость, что и WannaCry, и защищал от шифровальщика захваченные ПК. 
• Войти через IoT. Не успел стихнуть шум вокруг безопасности IoT из-за ботнетов и DDoS-атак, как с помощью незащищенных «умных» кофемашин стали останавливать нефтехимические заводы, а смарт-аквариумы использовать для атак на казино.
• Биткоины и уязвимый веб. К концу 2017-го года биткоин опередил по капитализации российский рубль, и хакеры сконцентрировали свое внимание на блокчейн-стартапах. Самая простая схема атаки стала наиболее популярной — найти уязвимости на сайте ICO и подменить адрес кошелька для сбора инвестиций. Израильский CoinDash таким образом лишился $7,5 млн. 
• Эпидемия целевых атак. Число компаний, столкнувшихся в 2017 году с APT-атаками, увеличилось почти вдвое. Одновременно с этим атаки прямо на глазах усложняются, начинают активно применяться методы, затрудняющие анализ и расследование инцидентов.

При создании материала использовались данные ресурсов: 

Содержание

• Об исследовании
• Как начать выявлять инциденты ИБ с помощью SIEM-системы
• Задачи для SIEM-системы: типичные и нестандартные
• Источники для сбора событий
• Выявленные инциденты ИБ
• Предполагаемая атака
• Обнаружение вредоносного ПО
• Аномальное поведение пользователей
• Нарушение политик ИБ
• Заключение

Об исследовании

В инфраструктуре компаний происходит много событий, которые могут свидетельствовать о различных инцидентах информационной безопасности, таких как нарушение политик пользователями или проникновение злоумышленника в локальную сеть. Для централизованного сбора и анализа информации о событиях используют решения класса security information and event management (SIEM). Основная задача SIEM-системы — не просто собрать информацию о событиях с различных источников — сетевых устройств, приложений, журналов ОС, средств защиты, — но и автоматизировать процесс обнаружения инцидентов, а также своевременно информировать о них специалистов по безопасности. Пилотный проект позволяет продемонстрировать работу SIEM-системы в условиях, приближенных к условиям реальной корпоративной инфраструктуры. После таких проектов мы получаем много ценной информации от экспертов, поработавших с системой, и эта обратная связь позволяет совершенствовать продукт.

В этой статье мы расскажем о результатах 23 пилотных проектов по внедрению системы MaxPatrol SIEM, проведенных во второй половине 2019 — начале 2020 года ¹, и на их примере покажем, как информация из различных источников при использовании SIEM-системы позволяет выявлять инциденты ИБ в компании. Кроме того, расскажем о решении нетипичных задач с помощью SIEM-системы.

124 дня средняя длительность пилотного проекта

Как начать выявлять инциденты ИБ с помощью SIEM-системы

Для того чтобы начать выявлять инциденты ИБ в инфраструктуре компании с помощью SIEM-системы, необходимо сначала тщательно подготовиться:

1. Сформулировать задачи, которые вы планируете решать с помощью SIEMсистемы. Следует учитывать особенности инфраструктуры, положения корпоративной политики ИБ, а также требования и рекомендации регулирующих организаций.
2. Определить список источников, которые необходимо подключить к SIEMсистеме для решения поставленных задач.
3. Если вы готовитесь к пилотному внедрению, то следует определить четкие границы пилотной зоны. Фрагмент инфраструктуры, попадающий под пилотное внедрение, должен позволить оценить работу SIEM-системы и решить поставленные задачи.

Рассмотрим подробнее, какие задачи решались с помощью SIEM-системы в ходе пилотных проектов, и разберем, какие источники следует подключать для выявления различных типов инцидентов. Также приведем примеры реальных инцидентов и кибератак, выявленных в ходе проведенных работ.

Задачи для SIEM-системы: типичные и нестандартные

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

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

Пример из практики: несанкционированное появление активов

В одной из компаний SIEM-система была настроена на выявление несанкционированного появления активов внутри сети, когда служба ИТ без согласования со службой ИБ вводила какие-либо новые информационные объекты. Благодаря встроенной функции инвентаризации сети появилась возможность в реальном времени детектировать события в контурах разработки и стандартизировать процесс DevOps.

Источники для сбора событий

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

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

Источники событий ИБ — специализированное программное и аппаратное обеспечение для информационной безопасности, порождающее события ИБ. Такие источники обладают дополнительными внешними знаниями о том, как трактовать те или иные события с точки зрения безопасности (является ли наблюдаемое явление «хорошим» или «плохим»). Примеры источников событий ИБ: IDS/IPS (для сбора данных о сетевых атаках), средства антивирусной защиты (обнаружение вредоносных программ).

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

Для сбора наиболее полных данных со всех источников SIEM-система должна уметь взаимодействовать с широким спектром сетевых протоколов и технологий сетевого взаимодействия: syslog, WMI, RPC, Telnet, SSH, ODBC и другими. Например, для получения сообщений из системных журналов и журналов безопасности Windows (WinEventLog, WindowsAudit) на серверах и рабочих станциях используется протокол syslog. Так в SIEM-систему попадает информация о событиях, определенных политиками аудита Windows (таких как вход в систему, доступ к объектам, изменение привилегий). WMI позволяет собирать информацию с Windows-устройств о таких событиях, как создание, изменение или удаление файлов с определенным расширением; подключение физических устройств; запуск служб в ОС. Также рекомендуется дополнительно использовать инструмент расширенного аудита — Sysmon, поскольку в журналы аудита безопасности Windows попадает не вся информация. Sysmon отслеживает изменения в ветках реестра, видит, когда злоумышленник пытается получить хеш-значения паролей пользователей, а также позволяет отследить вредоносную активность внутри сети, получить информацию об источнике, включая хеш-значение файла, породившего процесс.

Не все инциденты можно выявить, основываясь на данных, полученных с серверов и рабочих станций. Для обнаружения атак в сетевом трафике (например, при использовании злоумышленником туннелей для передачи вредоносного кода или атаки DCSync) рекомендуется дополнить решение класса SIEM системой анализа сетевого трафика (NTA/NDR).

Ниже представлен список основных событий ИБ, выявляемых с помощью SIEM-системы, и соответствующих им источников.

События ИБ	Источники событий
Вредоносный контент, доставленный легальным образом, как правило по электронной почте (спам и фишинговые атаки)	Прокси-серверы с контролем контента Средства защиты веб-трафика Средства защиты почты Средства защиты конечных узлов со встроенными модулями контроля веб-ресурсов и электронной почты
Сбор данных об инфраструктуре компании, определение доступных сервисов, поиск уязвимых узлов	Межсетевые экраны Средства обнаружения и предотвращения вторжений
Нарушение доступности отдельных сервисов и систем в целом (например, в случае DDoS-атаки)	Межсетевые экраны Системы обнаружения и предотвращения вторжений Системы выявления и блокировки сетевых DoS-атак
Эксплуатация уязвимостей в компонентах системы	Средства обнаружения и предотвращения вторжений
Использование хакерских утилит, применяемых для взлома систем или иных противоправных действий	Средства обнаружения и предотвращея вторжений Сканеры уязвимостей и средства аудита Антивирусные средства защиты
Выполнение вредоносного кода	Антивирусные средства защиты Средства обнаружения и предотвращения вторжений
Нарушение политик ИБ, невыполнение требований нормативных документов (PCI DSS, приказа ФСТЭК № 21), корпоративных политик безопасности	Сканеры уязвимостей
Утечка конфиденциальных данных по любым коммуникационным каналам	Системы предотвращения утечек данных
Выявление аномалий, существенных отклонений параметров объекта защиты или его поведения от ранее установленной нормы	Межсетевые экраны нового поколения (NGFW) Системы предотвращения течек данных Системы класса User and Entity Behavior Analytics

Выявленные инциденты ИБ

В рамках пилотных проектов для демонстрации возможностей SIEM-системы часто выполняется моделирование условий, которые приводят к регистрации киберинцидента. Однако, помимо смоделированных, в 100% проектов, вошедших в выборку, MaxPatrol SIEM зафиксировал еще и реальные инциденты ИБ. Во время пилотных проектов были выявлены события ИБ, свидетельствующие о потенциальных кибератаках, заражении вредоносным ПО, нарушении политик ИБ, а также об отклонениях в поведении пользователей.

Предполагаемая атака

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

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

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

В ходе атак на контроллер домена, в котором используется аутентификация по протоколу Kerberos, злоумышленники могут прибегнуть к атаке Kerberoasting. Любой аутентифицированный в домене пользователь может запросить Kerberos-билет для доступа к сервису (Ticket Granting Service, TGS). Билет TGS зашифрован NT-хешем пароля учетной записи, от имени которой запущен целевой сервис. Злоумышленник, получив значение TGS-REP, может его расшифровать, подобрав пароль от ассоциированной с сервисом учетной записи, который зачастую является простым или словарным. В ходе пилотных проектов в ряде компаний были выявлены подобные атаки.

Перечисление существующих пользователей через запрос сеансового билета Kerberos, а также Kerberoasting злоумышленники применяют в атаках с использованием тактик «Разведка» (Discovery) и «Получение учетных данных» (Credential Access) по модели MITRE ATT&CK. SIEM-система, обладающая правилами детектирования популярных техник атак, сумеет обнаружить активность злоумышленников еще во время их попыток получить список учетных записей домена и перечень установленных приложений и служб.

Пример из практики: фишинг

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

SIEM-система помогает в выявлении и других типов атак. Так, во время проведения одного из пилотных проектов была своевременно обнаружена DDoS-атака. После анализа внешних адресов, с которых обращались злоумышленники, эти адреса были заблокированы на корпоративном межсетевом экране.

В ряде пилотных проектов выполнялся ретроспективный анализ событий ИБ для выявления атак и фактов компрометации объектов инфраструктуры компании, пропущенных или неверно приоритизированных при реализации штатных мер защиты. Так, например, удалось выявить и пресечь целенаправленную атаку на ресурсы одной компании, которая длилась не менее 8 лет. По результатам анализа журналов регистрации событий SIEM-системы были выявлены следы действий злоумышленников на 195 узлах контролируемой инфраструктуры. Причем, как выяснилось во время расследования, преступники были активны на протяжении всех этих лет, а именно использовали вредоносное ПО:

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

В минимальные сроки были заблокированы командные серверы злоумышленников и ликвидировано их присутствие в инфраструктуре. В ходе расследования специалисты Positive Technologies установили принадлежность атакующих к группировке TaskMasters.

Обнаружение вредоносного ПО

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

В одном из пилотных проектов было зафиксировано большое количество вредоносных писем, в частности содержащих Trojan-Banker.RTM, отправленных сотрудникам компании с 592 различных IP-адресов. Операторов этого вредоносного ПО в основном интересуют корпоративные банковские счета, поэтому фишинговые письма адресуют бухгалтерам и финансистам, имитируя переписку с финансовыми структурами. Темой такого письма может быть, например, «Заявка на возврат», «Пакет документов за прошлый месяц» или «Паспортные данные сотрудников».

Аномальное поведение пользователей

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

Нарушение политик ИБ

Еще одна категория инцидентов — это нарушения политик ИБ. Речь идет о выявлении фактов несоответствия требованиям нормативных документов, таких как PCI DSS, приказ ФСТЭК № 21, а также корпоративным политикам ИБ. Правила, устанавливаемые этими документами, направлены на обеспечение приемлемого уровня защищенности компании. Однако пользователи не всегда строго соблюдают все требования. В половине компаний в ходе пилотных проектов были выявлены нарушения политик ИБ. Так, например, в 39% пилотных проектов были зафиксированы случаи работы программ для удаленного управления компьютером. Эти события могут быть легитимными, например когда инженер технической поддержки удаленно подключается для настройки сервера, а могут указывать на получение доступа злоумышленниками (техника атаки Remote Access Software). Как правило, компаниям рекомендуется ограничить список узлов, на которых может использоваться ПО для удаленного доступа.

Пример из практики: выполнение политик ИБ

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

Заключение

Во всех компаниях происходят инциденты ИБ: выявляются использование вредоносного ПО, события, которые могут свидетельствовать о кибератаке или нарушении политик ИБ. Работы по тестированию на проникновение, выполняемые экспертами Positive Technologies, подтверждают, что в компаниях нередко выявляются следы более ранних атак хакеров, которые не были вовремя замечены службой ИБ. Для обнаружения атак на ранней стадии необходимо знать обо всем, что происходит в инфраструктуре компании. Для этого нужно собирать как можно больше информации о событиях, ведь чем полнее ведется сбор событий и чем больше источников подключено, тем больше шансов своевременно выявить подозрительную активность, принять меры по пресечению атаки и минимизировать негативные последствия.

Большой объем регистрируемых данных требует автоматизированной обработки с помощью таких решений, как SIEM. SIEM-система использует корреляцию, чтобы связывать вместе собранные данные, выявлять шаблоны, указывающие на инцидент. Опыт специалистов экспертного центра безопасности Positive Technologies показывает, что правила корреляции дают отправную точку для обнаружения большинства кибератак ², в том числе сложных многоступенчатых APT-атак, а также служат основой для расследования инцидентов. Если дополнительно используется система глубокого анализа трафика (решения класса NTA/NDR), то это позволяет отследить подозрительную активность не только на узлах, но и в сетевом трафике. Стоит принять во внимание, что к расследованию инцидентов следует привлекать квалифицированных экспертов, которые сумеют полностью восстановить цепочку атаки.

Проверьте возможности MaxPatrol SIEM на вашей инфраструктуре

Начните выявлять инциденты ИБ с помощью экспертизы Positive Technologies

Заказать пилот

1. В выборку вошли пилотные проекты по внедрению системы мониторинга и корреляции событий MaxPatrol SIEM, в которых объем инфраструктуры, выделенной для проведения пилотных работ, и обрабатываемых данных был достаточен для фиксации реальных инцидентов. Из исследования были исключены компании, которые не дали своего согласия на использование обезличенных результатов пилотного проекта в исследовательских целях.
2. MaxPatrol SIEM благодаря встроенным правилам корреляции позволяет выявлять актуальные техники атак без дополнительной настройки. Кроме того, MaxPatrol SIEM обладает правилами детектирования популярных техник атак (используется классификация MITRE ATT&CK), что позволяет обнаружить активность злоумышленников на ранних этапах.