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

На прошлой неделе по приглашению Руслана Юсуфова из Mindsmith пригласил меня на "Открытые инновации" (которым впору называться "Открытые просторы" исходя из места проведения) выступить в секции про кибербезопасность медицинских учреждений. Учитывая небольшую длительность, количество участников и формат, я не смог систематизировать все, что я хотел сказать. Поэтому вынесу это в формат заметки для блога.

Часто между кибербезопасностью медицинских учреждений и защитой персональных данных ставят знак равенства, считая, что именно это является основной задачей медиков, не допустить утечки наших с вами историй болезней, диагнозов, результатов анализов и т.п. Но, не ставя под сомнение данную задачу, все-таки хотел бы обратить внимание, что массовые утечки по сути своей не представляют собой серьезной угрозы, так как клиника от нее мало что теряет. Штраф от РКН? Ну мы не дети, понимаем, что это несерьезно. Снижение лояльности пациентов? Так они уже привыкли к "своим" врачам и врядли будут менять клинику только по причине утечки. Особенно если в округе клиника всего одна или вы приписаны к ней по страховке. GDPR? Ну в России эта страшилка вообще не работает.

По сути речь идет о попытке обосновать нужду в ИБ опираясь на три составных части, которые "заинтересованы" в атаках и защите от них - пациенты, регуляторы и хакеры. Но как мы уже поняли, первым двум категориям в целом ИБ не так уж и важна. А третья... А что третья? Как она может монетизировать атаки на медицинские учреждения? Социнжиниринг? Может быть, но маловероятно, так как что можно заставить сделать пациента, которому представились представителем его медучреждения? Повторно сдать анализы?

Но... давайте посмотрим чуть шире и попробуем встать на место конкретного пациента, который ходил не только в поликлиники по врачам, но и может лечь в стационар на 2-3 недели. Что можем ему помешать "насладиться" лежанием в больничной палате? Отсутствие Wi-Fi, выведенного из строя хакерской атакой? Может быть, если речь идет не о Москве с его безлимитным LTE. Подмена лекарств или рецептуры в электронной карте больного? Тоже может быть. Но пока не в России, где электронные карты - еще редкость. Шантаж родных, близких и знакомых разглашением факта "плохой" болезни? Да, вполне. В свое время представители РКН и Госдумы именно под этим соусом продвигали ФЗ-152 в его жесткой редакции. Еще утечка может быть актуальной в тех случаях, когда среди пациентов есть всяческие селебрити - звезды шоу-бизнеса, чиновники, телеведущие и т.п. Из информации об их болезнях можно сварганить репортаж, который привлечет массу людей, рекламодателей и т.п. Вспомните, непрекращающуюся последние пару месяцев эпопею с "болезнью" Заворотнюк...

А что клиники? Утечка их клиентской базы может повлиять на... доходы. Ведь конкуренты, украв базу пациентов, могут сделать им более выгодные предложения, переманив к себе. При условии, что в округе есть не одна клиника и они конкурируют между собой. В такой ситуации какое-то количество клиентов может все-таки уйти к конкурентам. Но это опять же только в крупных городах, где конкуренция среди клиник достаточно высока. Чему еще может угрожать инцидент ИБ, ставший достоянием гласности? Снижением репутации? Только если это попали на федеральные СМИ (тогда это еще и потеря новых клиентов и стратегических партнеров). А вот если клиника ведет какие-то исследования, за которые платят деньги, то утечка их результатов может быть на руку многим. Конкуренты получают за меньшие деньги то, на что потрачены гораздо большие ресурсы. Заказчики исследований тоже теряют и могут отказаться от продолжения сотрудничества. Еще одним мотивом задуматься о кибербезопасности клиники могут стать затраты на восстановление данных, потерянных в результате кибератаки. Фотография в начале заметки, кстати, посвящена как раз такому событию. Пока в России нет практики, обязывающей сообщать клиентам об инцидентах с их данными, а на Западе - это достаточно большая статья расходов (до 20 долларов на контакт с 1-м пациентом). Я не слышал о таких историях, но допускаю, что в особо вопиющих случаях такое может произойти - смена клиник в рамках договоров ДМС, что влечет за собой еще большие потери для медиков.

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

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

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

Запор Ярилы, стезя педагогона или старославянский словарь импортозаместителей от ИБ

Не секрет, что в России немало находится людей и компаний, активно продвигающих идеи импортозамещения в области информационной безопасности. Это патриотическое занятие на благо России сегодня омрачается только одним - использование англицизмов, а то и вовсе английских слов в названии продуктов и компаний, который считают себя апологетами импортозапрещения ИБ. И пока в российских школах не ввели изучение старославянского языка и Закона Божия, многие отечественные специалисты сталкиваются с трудностями в поиске слов-синонимов, которые бы отражали суть отечественных инноваций и при этом бы были исконно русскими. Я решил немного помочь поборникам ИБ-нравственности и составил небольшой словарик старорусских слов, которые можно использовать при создании новых или переименовании существующих продуктов и технологий защиты информации. Тем более, что за 4 года с моей последней публикации на эту тему, ничего не поменялось.

Вначале приведу список слов, которые могли бы стать названиями или частью названий продуктов по ИБ - градеж, забрало, заклеп, затвор, запор, оплот, твердыня и столпостена. Все эти слова имеют отношение к ограждению, защите или безопасности. Как могло бы звучать название компании "PT Security"? "Благая твердыня" или "Благой оплот" :-) А "Solar Security"? Например, "Запор Ярилы" (Ярила - это славянский бог солнца, а запор - это от глагола запирать) или "Забрало Ярилы" :-) А вот наезды или хула на Solar Security могли бы называться коротким "обсолонь", то есть движение против солнца.

Какие еще у нас могут быть применимы слова старославянского языка в кибербезопасности? Вот список, например, для английских слов, столь популярных в лексиконе отечественных безопасников:

• backdoor - афедрон
• blackholing - хлябь
• Cisco - лепота
• CISO - воевода, стража, стратиг, стратилат
• compliance - путы 
• CTF - палестра, ристалище 
• dlp - брещи
• Huawei - стезя педагогона
• Infosecurity Russia - позорище 
• SIEM - многоочитый 
• SOC - чертог.

А теперь список англицизмов и соответствующих им посконно русских синонимов:

• админ, оставивший сервер ElasticSearch в открытом виде - кукомоя
• атаковать - уязвлять 
• блокчейн - пленица 
• безопасник - поборник 
• бумажный безопасник - законник
• вирусная эпидемия  - проказа, лепра 
• деятельность без лицензии - забобоны
• идентификатор - ипостась
• инсайдер - афарим, сходник
• инцидент - тля 
• киберпреступник - окаянный, пакостник, тать 
• конфа по ИБ - глумилище
• кража - татьба 
• тайновидец - криптограф 
• лицензия - вериги
• место для лицензий регуляторов - красный угол 
• метрика - литра, мерило 
• межсетевой экран - мандра (это еще и названием собственным может стать), вратарь, вратник
• облако - мгла, морок 
• оплата аутсорсинговых услуг - оброк
• отказ системы - долгонедужие
• патч - плат 
• последователи реальной безопасности, отрицающие ФСТЭК и ее требования - штундисты 
• реестр российского ПО Минкомсвязи - буява
• рынок сертифицированных средств защиты информации - вертеп
• система обнаружения вторжений - мрежа, бредень
• сотрудники службы ИБ - челядь
• социальный инжиниринг - искушение
• требования по ИБ - умовредие
• уязвимость - язва
• фейковый аккаунт - личина, харя, лярва
• ФинЦЕРТ - нощный вран
• фишинговые учения - козни
• фишинг - прелесть 
• ФСТЭК - доилица, кормило 
• хакер - супостат, боритель
• чиновник - косноязычный 
• штраф за нарушение требований по защите информации - епитимия
• 8-й центр - капище

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

• Infowatch - Инфоглядун, Инфосоглядатай или Инфооко
• Secret Net - Тайный Невод
• ViPNet - Знатный Невод
• DIONIS - Корс (это уже не греческий, а славянский бог пьянства)
• Secret Studio - Тайная светлица
• Комрад - Товарисч
• UserGate - Холопские врата
• Мастерчейн - Гривнозлатарь
• Перспективный мониторинг - Узреющая ворожения.

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

Эскалация инцидентов ИБ

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

Что нас может не устраивать? Аналитик не справляется с работой в заданное в SLA время? Извините, но тут не может быть никакой эскалации. Это неприятно, это требует внимания со стороны руководителя дежурной смены, но это ни в коем случае не должно быть причиной эскалации. А вот если масштаб инцидента оказался больше, чем предполагалось изначально? Например, предполагалась утечка 100 записей о клиентах, а потом оказалось, что утекало 100 тысяч или 10 миллионов? Это, безусловно, причина для эскалации, что потребует привлечения внимания более высокого руководства, чем предполагалось изначально и принятия немного иных мер. В данном случае у инцидента еще и приоритет повысится. Но эскалация - это не всегда повышение приоритета. Оно может сопровождать эскалацию, но не обязательно следует за ней.

А что еще нас может не устраивать, что повлечет за собой эскалацию? Допустим вас не устраивает, как проводятся работы над вашим инцидентом. Недавно у меня была история. Потребовалась помощь службы поддержки - и я открыл соответствующий кейс. Мне назначили инженера, который пытался связаться со мной в нерабочее время, о чем я ему и сообщил, попросив позвонить с 10 до 18 по Москве. Он сказал "ОК" и пропал. День его нет, второй, третий,  При этом в истории кейса появляются записи, что он никак не может со мной связаться. Ну бывает :-) И хотя ситуация была некритичная, я все-таки в какой-то момент эскалировал ее на руководителя дежурной смены, который "дал пинка" моему инженеру и тот быстро разрешил стоящую передо мной задачу. Иными словами, причиной эскалации стало недовольство тем, как разбирался мой инцидент. И никакой приоритет у него не изменялся - просто мне потребовалось как-то обратить внимание на него. Но тут важно отметить, что причиной эскалации стало не просто мое необоснованное желание ("я хочу"), а мотивированный запрос с объяснением причин эскалации.

Многие советские детективы начинаются с того, что происходит незначительное происшествие, которое затем раскручивается в нечто более серьезное. Какая-нибудь авария в начале фильма разворачивается в убийство или хищение в особо крупном размере, что требует привлечения больших ресурсов и большего внимания от доблестных сотрудников советской милиции. Вот и в ИБ - если изменились существенные обстоятельства инцидента, может потребоваться его эскалация и, возможно, изменение приоритета. Причем изменение приоритета может произойти и в обратную сторону. Например, СМИ написали про утечку у вас 10 миллионов записей о клиентах со всех регионов, где у вас есть точки присутствия, что привело к установке максимально возможного приоритета для этого инцидента. Но в результате расследование выяснилось, что СМИ немного приукрасили и реальное число утекших записей составило всего 1000 и только из одного региона. Приоритет такого инцидента должен быть снижен, но решение об этом может принять не руководитель дежурной смены, а, например, руководитель SOC/CSIRT или руководитель всей ИБ, что и потребует эскалации, то есть привлечения их внимания.

Что еще? Допустим с личного ноутбука сотрудника по компании стал распространяться вредоносный код, который при этом не поразил большого количества компьютеров в сети. Вроде бы рядовая ситуация, и приоритет не очень высокий. Но так получилось, что этим сотрудником оказался генеральный директор компании (кстати, реальная ситуация). В этом случае может потребоваться эскалация инцидента, чтобы привлечь к нему внимание руководителя ИБ, которому, возможно, придется  объясняться перед генеральным директором о произошедшем. Кстати, вместо генерального директора может быть и рядовая секретарша, у которой слишком тесные отношения с генеральным, что ставит ее в немного привилегированное положение и требует (такова уж внутренняя политика) немного иного внимания, чем к рядовым сотрудникам.

Представим, что аналитик SOC получил в работу кейс, но в процессе выясняется, что ему не хватает знаний и кейс выходит за рамки полномочий аналитика. У него нет инструментов для обогащения данных, у него нет доступа к дополнительным инструментам расследования. Что ему остается? Расписаться в собственном бессилии или передать кейс дальше, например, аналитикам следующего уровня (линии)? Второй вариант тоже можно назвать эскалацией, хотя это будет достаточно условно. На мой взгляд это скорее обычный режим работы SOC/CSIRT, чем нечто необычное, что требует привлечения внимания.

При эскалации одной из важнейших задач является обоснование для нее. Я, как, думаю, и многие люди, не всегда объясняю причины своих поступков, считая, что "все же и так очевидно". Вот в эскалации такая фигня не работает - чтобы эскалация прошла успешно, должна быть веская причина. "Я так хочу", "Это же очевидно", "Я же босс" к таковым не относятся. Интересно, но когда пытаешься внятно сформулировать, зачем тебе нужна эскалация, часто получается, что она и не нужна :-) Если же верно все-таки обратное, то обоснование для эскалации должно быть бизнес-ориентированным. "Данный инцидент может стать достоянием СМИ и надо подготовиться", "Несмотря на стандартные двое суток на решение данного типа инцидента, нам надо его решить к завтрашнему совету директоров", "По результатам расследования стало известно, что утекло не 1000 записей о клиентах, а 1 миллион записей", "Шифровальщик заразил компьютеры бухгалтерии и они не успевают сдать отчетность в налоговую, что может привести к штрафам" и т.п.

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

Приоритезация инцидентов ИБ: все не так просто

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

Как бы вы поступили в таком кейсе? Посчитали бы вы такую ситуацию инцидентом ИБ или отнесли бы в разряд чисто айтишных проблем (ну по крайней мере, пока не появится больше деталей)? Возможно, тут сыграл эффект погружения (раз мы на киберучениях по ИБ, то и все кейсы про ИБ, несмотря на то, что я с самого начала сказал, что могут быть подвохи и некоторые кейсы могут быть случайными или не имеющими отношения к ИБ), но большинство команд посчитало, что такое описание однозначно говорит о том, что в компании инцидент ИБ и его надо передавать от службы поддержки в службу ИБ, которая и должна проводить расследование инцидентов. Последующие несколько кейсов лишний раз продемонстрировали, что далеко не всегда компании могут с четкостью определиться с тем, что относится к инцидентам (даже те, кто "ходит" под Банком России с его  ФинЦЕРТом или под ГосСОПКОЙ с НКЦКИ).

Но дело даже не в этом, а в том, что все инциденты ИБ считаются равнозначными. Я неоднократно в рамках киберучений задавал вопрос о том, надо ли на основе полученной информации изменить приоритет инцидента или нет. И судя по многочисленным ответам и не только на этих киберучениях, это оказалось достаточно распространенной проблемой. Но если вдуматься, мы же понимаем, что не все инциденты одинаковы. Например, заражение шифровальщиком ПК секретарши или сервера АСУ ТП, утечка 5000 записей о клиентах или 60 миллионов, простой на 1 час или на неделю... Как минимум, по уровню ущерба инциденты сильно отличаются друг от друга. Я в мае уже писал про варианты оценки ущерба от инцидентов ИБ. Это один, и самый популярный, пожалуй, из вариантов классификации инцидентов ИБ. Градации вы можете определить самостоятельно - обычно их пять, но это число может быть и три, и шесть, и семь, и девять. В зависимости от направления бизнеса и варианты ущерба могут быть разные.

Очевидно, что от приоритета/класса инцидента зависит, например, в течение какого времени необходимо реагировать на него. Потенциальная утечка миллиона записей о клиентах относится скорее к критичному инциденту (а может быть и к катастрофичному, если в организации вводится еще одна, шестая категория), а вот утечка "всего" 100 записей могла бы быть отнесена к инциденту среднего, а то и низкого приоритета.

Приоритет инцидента будет влиять и на режим работы группы реагирования. В масштабных кейсах этот режим скорее всего будет круглосуточным, а для мелочи можно по-прежнему работать в режиме 5х8.

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

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

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

ЗЫ. Пытливый читатель мог бы задаться вопросом - а что, если в процессе расследования окажется, что инцидент масштабнее, чем предполагалось изначально? А что если мы не уложимся в отведенное время? А что если понадобится принять решение, выходящее за рамки полномочий лица, на чьем уровне принятия решения сейчас находится инцидент? Для всех этих случаев потребуется эскалация, о которой разговор пойдет в другой раз.

Вас шантажируют утечкой данных. Что делать?

Весной 2019-го года, на CISO Forum, я проводил киберучения, где среди прочего был и такой кейс - вы получаете сообщение через соцсети (чат в Facebook Messenger, Telegram, Whatsapp, Viber и т.п.) от человека, который называет себя известным в отрасли ИБ именем и который заявляет, что нашел в Darknet доказательства утечки у вас базы данных. Он, разумеется, готов вам помочь провести расследование данного инцидента. Следующий кейс - этот же человек публикует в открытом доступе информацию об утечке в вашей компании и вы сталкиваетесь с запросами со стороны СМИ.

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

Вот представьте, что пока вы читаете эту заметку, к вам пришло сообщение о том, что ваша база клиентов утекла и ее продают в Darknet? Что вы будете делать? Если собрать все, что звучало в рамках киберучений (не только двух упомянутых) и добавить кое-что от себя, то вырисовывается следующий набор действий, который надо делать в таких ситуациях.

Во-первых, если с вами говорит кто-то известный или представитель известной ИБ-компании, то стоит проверить, что с вами связывается именно то лицо, чье имя указано в выходных данных вашего контакта? Во-вторых, стоит проверить, что это не информационная атака, которая направлена против вас. В-третьих, стоит начать внутреннее расследование (возможно с привлечением внешних компаний), которое подтвердит или опровергнет факт утечки. В-четвертых, стоит уведомить руководство компании о факте "шантажа". В-пятых, стоит быть готовым к общению со СМИ (о том, как это делать, я уже писал 3,5 года назад). В-шестых, в зависимости от характера утечки и содержащихся в ней данных, может потребоваться уведомить как самих пострадавших клиентов, так и регуляторов (РКН, ФинЦЕРТ, ГосСОПКА, GDPR и т.п.). Наконец, необходимо будет извлечь уроки и внести изменения как в систему защиты (если факт утечки подтвердится), так и в план реагирования на инциденты.

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

Применение роботов (платформ RPA) для кибербезопасности

В сентябре на Хабре я написал большой материал про мониторинг ИБ облаков (первая и вторая части). Среди прочего я описывал достаточно частую ситуацию, встречающуюся у облачных провайдеров. Журналы регистрации событий доступны, но выгрузить их можно только в ручном режиме - сформировать лог за интересующий временной интервал и скачать к себе на компьютер  в виде таблички Excel или CSV-файла. При этом делать это на регулярной основе непросто и можно в какой-то момент времени забыть сделать выгрузку, потеряв часть данных для анализа. Можно ли автоматизировать выгрузку таких данных при полном отсутствии API?

Оставим пока в стороне ответ на этот вопрос. Зададимся другим. Точнее я им задавался достаточно долгое время, наблюдая за реализацией сервиса CAPTCHA на разных сайтах. Какое-то время считалось, что этот простой механизм позволяет отсечь ботов и пройти его может только человек. Но если посмотреть на то, как реализуется CAPTCHA, то будет понятно, что мы всегда повторяем одни и те же действия - вводим увиденный на картинке текст в соответствующее поле или нажимаем на картинки, показывающие то, что нас спрашивает сервис CAPTCHA (светофоры, машины, вывески, мосты, гидранты и т.п.). Можно ли автоматизировать действия по нажатию клавиш или движению мыши? Ведь в конце концов мы это делаем не сами,  а просто даем команды компьютеру, которые он и реализует. Но куда вбивать текст и куда кликать мышью указывает человек! Да, но эти действия тоже можно автоматизировать. Помогает решить эту задачу технология RPA (Robotics Process Automation), которая позволяет автоматизировать различные процессы, используя настраиваемых программных роботов, имитирующих действия человека за счет взаимодействия с информационной системой и она не видит разницы между роботом и человеком.

Что умеют  роботы RPA? Они работают с Web-формами, приложениями, почтой, документами, базами данных, файлами на диске или в Интернет, которые могут быть преобразованы по заданному сценарию или алгоритму. Такой робот:

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

Внедрение робота занимает немного времени - от 2-х дней уходит на изучение процесса, определение необходимых приложений и ИС, с которыми нужно работать, и снятие скриншотов действий пользователя. От 5-ти дней уходит на настройку робота - сценариев его работы и взаимодействия с нужными системами. От 3-х дней уходит на тестирование и доработку робота. Для простых случаев автоматизации внедрение робота займет около 10 дней - в более сложных может понадобиться 1-2 месяца.

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

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

• Заход в личный кабинет ФинЦЕРТ или ГосСОПКА для получения бюллетеней или уведомлений
• Обогащение событий безопасности из источников TI
• Заведение тикетов в IRP / SOAR
• Анализ заявок на предоставление доступа к корпоративным ресурсам
• Организация фишинговых симуляций
• Сбор облачных логов в Excel/CSV и загрузка их в SIEM
• Анализ входящих сообщений от пользователей
• Работа с унаследованными или legacy системами ИБ
• Тестирование защищенности Web-приложений
• Сбор инвентаризационных данных из десятка источников и приведение к единому формату с загрузкой в CMDB
• Мониторинг Интернет-ресурсов, а также анализ новостей по ИБ и отправка ключевых во внутреннюю рассылку
• Построение dashboard
• Получение согласий на обработку ПДн от клиентов
• Уведомление о нарушении прав субъекта ПДн.

Это неполный перечень, но он достаточно показательный. С помощью RPA можно автоматизировать многие рутинные задачи, возникающие в деятельности ИБ. Кто выпускает RPA-платформы? Вот список некоторых вендоров, которых можно встретить в России, - UiPath, Automation Anywhere, Blueprism, WorkFusion, Pegasystems, NICE, Kryon, Kofax, Contextor, Softomotive, Redwood Software, EdgeVerve, Another Monday, Antworks, Toughtonomy, SAP iRPA, Datamatics Trubot, Jacada, NTT-AT, Helpsystems, Servicetrace, Robin, PIX, HyperUp, electroNeek.