InfoSec_01_2021

Cover_01_END 3/26/21 9:37 PM Page Cov1

www.itsec.ru

№ 1, март 2021 Издание компании

XVI Международная выСтавка

Сентябрь 2021

Спецпроект

контроль доСтупа

От бумАжнОй к реАльнОй безОпАснОсти кии нОвАя кОнцепция Bring Your EntErprisE HomE инструменты кОнтрОля дОступА для ОргАнизАции удАленнОй рАбОты бОрьбА с зАрАженными флешкАми в ОргАнизАции безОпАснОсть дистАнциОннОй рАбОты: прОгнОзы и рекОмендАции клАссификАция дАнных кАк фундАмент иб риски кибербезОпАснОсти для пОдключенных АвтОмОбилей прОАктивный пОиск уязвимОстей в исхОднОм кОде

Андрей Акинин

Я верю в подход Security By Nature

Реклама

IB_Jornal 3/26/21 9:37 PM Page cov2

Preview 3/26/21 9:07 PM Page 1

www.itsec.ru

Стратегическая трансформация Прошел год с начала режима ограничений, связанных с COVID-19. Жизнь почти вернулась в привычное, докоронавирусное, русло, но многие организации не торопятся возвращать сотрудников в офисы.

Амир Хафизов, выпускающий редактор журнала “Информационная безопасность”

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

Тем временем в параллель к насыщенной программе вебинаров и онлайн-конференций, ставших практически безальтернативной формой общения в период самоизоляции, в нашу жизнь возвращаются привычные офлайн-мероприятия – конференции, форумы, выставки. В феврале прошел традиционный Форум “Технологии безопасности” (он же ТБ Форум) с заметной экспозиционной и конференционной составляющей, посвященной вопросам информационной безопасности. А в сентябре пройдет отраслевая выставка ITSec Expo, более подробная информация о которой скоро будет доступна на сайте www.itsecexpo.ru

• 1

Contents 3/26/21 9:31 PM Page 2

СОДЕРЖАНИЕ В ФОКУСЕ Артем Синицын Год локдауна: новые темпы цифровой трансформации в области кибербезопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4 стр.

КИИ

4

Константин Саматов От бумажной к реальной безопасности критической информационной инфраструктуры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6 ПЕРСОНЫ Андрей Акинин Я верю в подход Security By Nature . . . . . . . . . . . . . . . . . . . . . . . . . . .8

ПРАВО И НОРМАТИВЫ Алексей Петухов, Дмитрий Правиков

стр.

8

Открытая база знаний по информационной безопасности . . . . . .12 Анастасия Заведенская Обзор изменений в законодательстве. Январь, февраль – 2021 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

ТЕхНОлОгИИ КОНТРОЛЬ ДОСТУПА Николай Валаев Критерии выбора системы PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .19 Кент Лэндфилд

стр.

32

Bring Your Enterprise Home. Кибербезопасность корпоративного уровня дома у сотрудников . . . . . . . . . . . . . . . . . .20 Светлана Конявская Инструменты контроля доступа для организации удаленной работы . . . . . . . . . . . . . . . . . . . . . . . . . .21 Ярослав Голеусов Нейтрализация неочевидных угроз безопасности при удаленной работе . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22 Александр Ветколь Классификация данных как фундамент ИБ . . . . . . . . . . . . . . . . . . .26 стр.

Светлана Конявская Борьба с зараженными флешками в организации . . . . . . . . . . . . .27 2 •

36

Contents 3/26/21 9:31 PM Page 3

СОДЕРЖАНИЕ Безопасность дистанционной работы:

Журнал "Information Security/Информационная безопасность" № 1, 2021 Издание зарегистрировано в Минпечати России Свидетельство о регистрации ПИ № 77-17607 от 9 марта 2004 г.

прогнозы и рекомендации . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Учредитель и издатель компания "ГРОТЕК"

УПРАВЛЕНИЕ Валерий Естехин

Генеральный директор ООО "ГРОТЕК" Андрей Мирошкин Издатель Владимир Вараксин

Business Information Security Officer – востребованный герой нашего времени . . . . . . . . . . . . . . . . . . . . . .30 Сергей Рысин

Выпускающий редактор Амир Хафизов Редактор Светлана Хафизова

От хорошего к великому через хаос . . . . . . . . . . . . . . . . . . . . . . . . .32 Владимир Душкевич Опыт борьбы с атаками через электронную почту:

Корректор Галина Воронина Дизайнер-верстальщик Ольга Пирадова

проблемы, стратегия борьбы и технологии . . . . . . . . . . . . . . . . . . .33 Фото на обложке Софья Ларина

ТЕХНОЛОГИИ

Юрисконсульт Кирилл Сухов, lawyer@groteck.ru

Михаил Кондрашин Риски кибербезопасности для подключенных автомобилей . . . .36

БЕЗОПАСНАЯ РАЗРАБОТКА Андрей Акинин Место безопасности в новой парадигме цифрового бизнеса. От безопасной разработки к безопасному программному обеспечению . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39 Владимир Кислицин Проактивный поиск уязвимостей в исходном коде . . . . . . . . . . . .42

Департамент продажи рекламы Зинаида Горелова, Ольга Терехова Рекламная служба Тел.: +7 (495) 647-0442, gorelova@groteck.ru Отпечатано в типографии ООО “"Линтекст", Москва, ул. Зорге, 15 Тираж 10 000. Цена свободная Оформление подписки Тел.: +7 (495) 647-0442, www.itsec.ru Департамент по распространению Тел.: +7 (495) 647-0442 Для почты 123007, Москва, а/я 26 E-mail: is@groteck.ru Web: www.groteck.ru, www.itsec.ru

Ростислав Кокарев Особенности Snort: разбираемся в настройке и управлении NIDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45

НОВЫЕ ПРОДУКТЫ И НЬЮСМЕЙКЕРЫ Новые продукты и услуги . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 Ньюсмейкеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .48

Перепечатка допускается только по согласованию с редакцией и со ссылкой на издание За достоверность рекламных публикаций и объявлений редакция ответственности не несет Мнения авторов не всегда отражают точку зрения редакции © "ГРОТЕК", 2021

• 3

Sinitsyn 3/26/21 9:32 PM Page 4

В ФОКУСЕ

Год локдауна: новые темпы цифровой трансформации в области кибербезопасности Артем Синицын, руководитель программ информационной безопасности Microsoft в странах Центральной и Восточной Европы

О

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

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

В 2020 г. компания Microsoft провела опрос в Индии, Германии, Соединенном Королевстве и США среди руководителей компаний с численностью персонала более 500 человек для того, чтобы проанализировать их отношение к проблемам, возникшим в связи с пандемией коронавируса, а также чтобы выяснить, с какими последствиями всеобщего мирового локдауна пришлось столкнуться бизнесу и как, по их мнению, пандемия повлияет на кибербезопасность в долгосрочной перспективе. Результаты этого опроса показали: l увеличение количества предприятий, пострадавших от фишинга; l увеличение бюджетов на кибербезопасность у части компаний; l организации и компании придают большое значение облачным технологиям и архитекту-

рам, таким как Zero Trust, и делают на них ставку.

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

Рис. Изменения в бюджетах на информационную безопасность в связи с пандемией COVID-19 1 2 3 4

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

Приоритетные технологии в докризисный период и эффективные антифишинговые технологии В начале марта 2020 г. подразделение Microsoft Threat Intelligence4 сообщило о всплеске атак, связанных с COVID-19. Преступники начали использовать тему коронавируса в качестве приманки для установки вредоносного ПО. В этот период фишинговые угрозы представляли собой наибольшую опасность: 90% компаний подверглись таким атакам. Более половины опрошенных руководителей компаний отметили, что наибольший риск представляют собой фишинговые письма, а 28% признались, что злоумышленники успешно атаковали пользователей в их организациях. Примечательно, что об успешных фишинговых атаках чаще сообщали организации, ресурсы которых находились в основном на собственном физическом сервере, – 36%, чем те компании, где более развита облачная инфраструктура.

https://news.microsoft.com/ru-ru/two-years-digital-transformation-two-months/ https://customers.microsoft.com/en-us/story/834417-centurylink-telecommmunications-m365-security-compliance https://www.microsoft.com/ru-ru/security/business/identity/mfa https://news.microsoft.com/ru-ru/exploiting-crisis/

4 •

Sinitsyn 3/26/21 9:32 PM Page 5

www.itsec.ru

В ФОКУСЕ

Влияние информационной безопасности на бюджеты и кадры В 2020 г. в связи с переходом организаций на удаленную работу безопасность стала напрямую влиять на формирование бюджетов и на кадровую политику по мере того, как компании масштабировали существующие решения, например используя многофакторную аутентификацию, а также применяли стратегию Zero Trust. Чтобы оправиться от последствий пандемии, некоторые компании увеличили бюджеты на обеспечение безопасности (таких 58%) и на достижение и поддержание соответствия требованиям регуляторов (65%). В то же время 81% компаний были вынуждены снизить общие расходы на безопасность, в основном это организации, ресурсы которых расположены локально. Чтобы сдержать рост расходов в краткосрочной перспективе, руководители компаний отдают предпочтение интегрированной защите от угроз для снижения риска взломов, которые могут нанести большой ущерб, и приобретают ИБ-решения, имеющие инструменты автоматизации, что в итоге повышает эффективность работы сотрудников. Почти 40% предприятий заявляют, что в долгосрочной перспективе отдают предпочтение облачным решениям для информационной безопасности, в том числе CASB (Cloud Access Security Broker), CWWP (Cloud Workload Protection Platform), CSPM (Cloud Security Posture Management). Следом идут средства защиты данных – 28% и инструменты для борьбы с фишингом – 26%. Впрочем, одни лишь технологии не позволяют поспевать за всеми угрозами, а также задачами, стоящими перед бизнесом и сотрудниками организаций на удаленной работе. Поэтому более 80% компаний нанимают экспертов в области безопасности в качестве ответа на вызовы, появивишиеся в период COVID-19.

5 аспектов сферы кибербезопасности, которые изменит пандемия Пандемия ускорила цифровую трансформацию, и это изменит парадигму безопасности в обозримом будущем5: 5

1. Кибербезопасность во время пандемии зарекомендовала себя как основа для цифровой эмпатии у удаленных сотрудников: когда миллиарды людей за одну ночь сформировали самый большой за всю историю удаленный рынок труда, команды научились гораздо большему, чем масштабирование VPN. Компаниям напомнили, что технологии обеспечения безопасности – это фундаментальная предпосылка для повышения производительности и укрепления сотрудничества с помощью инклюзивного опыта конечных пользователей. Улучшение опыта пользователей во время удаленной работы является главным приоритетом для лидеров бизнеса в области безопасности (41%), при этом распространение средств обеспечения безопасности на большее количество приложений для удаленной работы было определено как наиболее положительно воспринятое пользователями действие. Неудивительно, что обеспечение безопасного удаленного доступа к ресурсам, приложениям и данным является самой важной задачей. Для многих предприятий реализация решения начинается с внедрения многофакторной аутентификации.

2. Подавляющее большинство организаций переходит на концепцию "нулевое доверие" (Zero Trust). В первые дни пандемии "нулевое доверие" стало не просто одним из вариантов стратегии ИБ, но бизнес-приоритетом. В свете роста необходимости дистанционного формата работы 51% руководителей ускоряют реализацию этой стратегии в своих организациях. Архитектура Zero Trust со временем станет отраслевым стандартом – это означает, что все находятся на пути к "нулевому доверию". 94% компаний сообщают, что они в той или иной степени находятся в процессе развертывания новых возможностей Zero Trust.

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

https://www.microsoft.com/security/blog/2020/07/16/5-cybersecurity-paradigm-shifts-digital-experiences/

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

4. Киберустойчивость имеет фундаментальное значение для ведения бизнеса. Кибербезопасность обеспечивает основу операционной устойчивости по мере того, как все больше организаций переходят к удаленной работе. Для поддержания защищенности предприятиям необходимо регулярно оценивать свой пороговый уровень риска и способность выполнять процессы обеспечения кибербезопасности с помощью сочетания усилий человека и технологических продуктов и услуг. Облачные технологии упрощают разработку комплексной стратегии обеспечения кибербезопасности и подготовку к реагированию на широкий спектр непредвиденных обстоятельств. Более половины передовых компаний, использующих облачную или гибридную инфраструктуры, сообщают о наличии у них стратегии киберустойчивости для большинства возможных рисков по сравнению с 40% организаций, применяющих исключительно решения, установленные локально. 19% компаний, полагающихся в первую очередь на локальные технологии, не планируют создавать официальный план действий для киберустойчивости бизнеса.

5. Облако – необходимое условие безопасности. Иногда специалисты представляют себе кибербезопасность как решение, которое лишь требуется развернуть поверх существующей инфраструктуры. Однако такие события, как COVID-19, диктуют свои правила и наглядно показывают необходимость интегрированного подхода к безопасности для компаний любого размера. Интегрированные ИБрешения теперь становятся необходимостью. l

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

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

Подавляющее большинство организаций переходит на концепцию "нулевое доверие" (Zero Trust).

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 5

Samatov 3/26/21 9:31 PM Page 6

В ФОКУСЕ

От бумажной к реальной безопасности критической информационной инфраструктуры Константин Саматов, руководитель комитета по безопасности КИИ, член Правления Ассоциации руководителей служб информационной безопасности

В

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

Как появился термин "бумажная безопасность"

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

Для банков уже достаточно давно и остро стоит вопрос соблюдения баланса между "реальной" и "бумажной" безопасностью.

1

Термин "бумажная безопасность" в отечественном деловом обороте означает обеспечение соответствия требованиям по безопасности, установленным нормативно-правовыми актами. Этот термин получил наибольшую распространенность именно в сфере информационной безопасности, так как из всех направлений корпоративной безопасности оно является наиболее "зарегулированным", то есть регулируется большим количеством законов и подзаконных нормативно-правовых актов. В качестве примера можно назвать четыре "основных" закона, регулирующих данную сферу общественных отношений: l Федеральный закон "Об информации, информационных технологиях и о защите информации" от 27.07.2006 г. № 149-ФЗ; l Федеральный закон "О персональных данных" от 27.07.2006 г. № 152-ФЗ; l Федеральный закон "О коммерческой тайне" от 29.07.2004 г. № 98-ФЗ; l Федеральный закон от 26.07.2017 г. № 187-ФЗ "О безопасности критической информационной инфраструктуры Российской Федерации". Помимо указанных федеральных законов, нормы права, регулирующие информационную безопасность, также содержатся еще в целом ряде других федеральных законов и нормативно-правовых актов.

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

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

большее внимание именно реальной безопасности, так как регуляторное воздействие на компании указанной отрасли1 минимально, а риски понести значительный вред (как репутационный, так и финансовый) от атаки злоумышленника достаточно велики. Исключением из правил является такой вид "цифровых предприятий", как банки, где присутствует достаточно серьезное регуляторное воздействие Центрального Банка России, а также высоки риски возникновения вреда от успешной атаки на информационный ресурс. В этой связи для банков уже достаточно давно и остро стоит вопрос соблюдения баланса между "реальной" и "бумажной" безопасностью. Аналогичная ситуация сейчас наблюдается и в части обеспечения безопасности критической информационной инфраструктуры (КИИ).

КИИ в разрезе "бумажной" и "реальной" безопасности В 2018 г. вступил в законную силу Федеральный закон "О безопасности критической информационной инфраструктуры Российской Федерации", во исполнение которого в 2018– 2020 гг. было выпущено порядка 16 подзаконных нормативно-правовых актов, требования которых должны быть выполнены государственными органами (учреждениями), российскими юридическими лицами и индивидуальными предпринимателями, попавшими в сферу действия указанного федераль-

Если не принимать в расчет банки, которые зачастую относят к “цифровым предприятиям".

6 •

Samatov 3/26/21 9:31 PM Page 7

www.itsec.ru

КИИ

ного закона (так называемыми субъектами КИИ). Алгоритм реализации требований этих нормативно-правовых актов (укрупненно) выглядит следующим образом: 1. Определение критичности информационных ресурсов (категорирование).

2. Создание систем безопасности (значимых2) объектов КИИ.

3. Организация взаимодействия с государственной системой обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы Российской Федерации (ГосСОПКА).

4. Поддержание работоспособности и улучшение систем безопасности объектов КИИ. Если посмотреть на этот алгоритм с точки зрения "реальной" и "бумажной" безопасности, то получается следующее. Этап выполнения требований законодательства, связанный с категорированием, – это чисто "бумажная" безопасность, так как в его рамках требуется: l выпустить приказ о постоянно действующей комиссии по категорированию; l провести работу комиссии по категорированию (определение критических процессов, выявление объектов КИИ, оценка угроз, оценка показателей критериев значимости и т.п.) и оформить результаты в виде внутренних документов (протоколов); l подготовить и отправить во ФСТЭК России перечень объектов КИИ, подлежащих категорированию; l оформить актом решение комиссии по категорированию; l подготовить и отправить во ФСТЭК России сведения о категорировании. Как видно, все мероприятия, проводимые на данном этапе, не оказывают влияния на "реальную" защиту информационных ресурсов, а связаны с выявлением информационных ресурсов, нуждающихся в защите, их классификацией, а также актуальными для них угрозами безопасности. Но при этом без указанных мероприятий невозможно обеспечить безопасность объектов КИИ.

На этапе создания систем безопасности объектов КИИ уже проектируются и внедряются решения, связанные именно с "реальной безопасностью" информационных ресурсов, то есть направленные на: l предотвращение несанкционированного доступа к обрабатываемой в объекте КИИ информации; l недопущение воздействия на технические средства обработки информации, в результате которого может быть нарушено и (или) прекращено функционирование объекта КИИ; l восстановление функционирования объекта КИИ при инцидентах. Связанным с двумя предыдущими этапами3, но все-таки, по мнению автора, требующим отдельного рассмотрения, является этап организации взаимодействия с ГосСОПКА. Необходимость организации взаимодействия с ГосСОПКА связана с исполнением обязанности, предусмотренной ч. 2 ст. 9 Федерального закона "О безопасности КИИ", по незамедлительному информированию Национального координационного центра по компьютерным инцидентам (по сути, передачи информации в ГосСОПКА) о компьютерных инцидентах. В рамках исполнения указанной обязанности очень важно обратить внимание на понятия "инцидент" и "компьютерная атака". Так, согласно ст. 2 Федерального закона "О безопасности КИИ": l компьютерная атака – целенаправленное воздействие программных и (или) программноаппаратных средств на объекты критической информационной инфраструктуры, сети электросвязи, используемые для организации взаимодействия таких объектов, в целях нарушения и (или) прекращения их функционирования и (или) создания угрозы безопасности обрабатываемой такими объектами информации; l компьютерный инцидент – факт нарушения и (или) прекращения функционирования объекта критической информационной инфраструктуры, сети электросвязи, используемой

для организации взаимодействия таких объектов, и (или) нарушения безопасности, обрабатываемой таким объектом информации, в том числе произошедший в результате компьютерной атаки. Таким образом, действующее законодательство в области безопасности КИИ обязывает субъект КИИ информировать регулятора в случае произошедшего инцидента и стимулирует его (субъект КИИ) к реагированию на компьютерную атаку на как можно более ранней стадии (чтобы не допустить возникновения инцидента). Именно в этой части четко прослеживается вектор смещения акцента с формального выполнения требований ("бумажной безопасности") на реальную защиту информационного ресурса, причем на как можно более ранней стадии компьютерной атаки (компьютерного нападения). На этапе поддержания работоспособности и улучшения системы безопасности проводятся аудиты как на соответствие требованиям безопасности, так и аудиты информационной инфраструктуры, определяется зрелость процессов информационной безопасности компании, вырабатываются рекомендации по: l совершенствованию деловых процессов компании, связанных с обеспечением информационной безопасности; l настройке текущих технических решений и внедрению новых; l изменению организационнораспорядительной документации по информационной безопасности. Таким образом, когда система безопасности объектов КИИ уже создана и функционирует, активно используются механизмы "бумажной безопасности" для достижения целей раннего предупреждения о компьютерном нападении и обеспечения устойчивости функционирования объектов КИИ, то есть для достижения "реальной безопасности". l

Этап выполнения требований законодательства, связанный с категорированием, – это чисто "бумажная" безопасность.

На этапе создания систем безопасности объектов КИИ уже проектируются и внедряются решения, связанные именно с "реальной безопасностью" информационных ресурсов.

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

2 В рамках данной статьи автор сознательно исключает из рассмотрения вопросы обязательности создания систем безопасности для разных видов объектов КИИ.

3 В ряде случаев организация взаимодействия с ГосСОПКА входит в этап создания системы безопасности объектов КИИ.

• 7

Akinin 3/26/21 9:32 PM Page 8

В ФОКУСЕ

Я верю в подход Security by Nature Андрей Акинин, генеральный директор компании Web Control

Ч – Андрей, расскажите немного о себе.

– Я закончил Бауманку (МГТУ им. Н.Э. Баумана. – Прим. ред.) по космической специальности "Информационные измерительные системы", но к моменту завершения обучения космос был слабо востребован, и пришлось уйти в ИТ. До организации собственного бизнеса я успел поработать в разработке и дистрибуции ПО, телекоме, в интеграторской компании, и этот опыт не раз был востребован в дальнейшей деятельности. Когда мы с партнерами организовывали собственную компанию, поставили перед собой цель создать дистрибьютора с добавленной стоимостью (Value Added Distributor). Тогда это была довольно редкая модель бизнеса, но только она позволяла работать с высокотехнологичными передовыми решениями, с которыми нам интересно было работать. Мы cделали своей миссией продвижение на российском рынке передовых продуктов для корпоративных заказчиков, которые "будут востребованы завтра". Должен сделать оговорку: отвечая на вопросы, мне трудно разделить свое профессиональное отношение как дистрибьютора систем ИБ и управления разработкой и личный взгляд как владельца бизнеса, поэтому буду говорить скорее с точки зрения владельца бизнеса – предпринимателя, имеющего свой взгляд на вопросы его информационной безопасности.

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

– Давайте определимся, что, говоря о безопасности, мы подразумеваем в первую очередь степень защищенности

8 •

то такое Security by Nature, почему безопасная разработка является основой безопасных систем, полезна ли цифровизация бизнесу – эти и другие вопросы мы обсудили с генеральным директором компании Web Control Андреем Акининым.

как главную ценность для бизнеса и клиентов. Прежде всего я бы отметил как проблему для безопасности информационных систем не собственно их развитие как таковое... Наибольшей угрозой для безопасности является именно скорость развития систем. Когда мы выстраиваем любую безопасность, не только информационную, ее удобно выстраивать в стационарных условиях, когда есть время подумать и проверить. Защищать движущиеся и изменяющиеся объекты всегда гораздо сложнее, впрочем, равно как и атаковать их. По оценке многих экспертов, специалисты идут на компромисс при развитии новых систем, отдавая предпочтение скорости разработки или добавлению новой функциональности в ущерб безопасности. Другими словами, безопасность информационных систем часто приносят в жертву требованиям функциональности и инновационности, что, в общем-то, на первых этапах цифровизации бизнеса и общества было вполне приемлемо. В современных условиях, когда ИТ становится основным средством производства и доставки ценности, когда информационные активы и цифровые сущности, в том числе и клиентские, становятся основной целью злоумышленников, необходимо радикально изменить подход к обеспечению их безопасности. От наложенной безопасности необходимо переходить к безопасности по природе (Security by Nature).

– Можно ли сделать вывод, что для тех, кто занимается разработкой информационных систем, практически не существует такого понятия, как Security by Nature?

– Я бы не так сказал. Я бы сказал, что классический подход к обеспечению безопасности ИТ уже не работает. Ведь что такое классическая безопасность? Это защита физических и инфраструктурных активов, выстраивание физических и цифровых периметров – те же самые системы видеонаблюдения, системы разграничения доступа, системы сегментации сетей, Firewall, IDS/IPS и т.д. Все они создают, к сожалению, барьеры, которые мешают бизнес-процессам, да и в целом развитию бизнеса. И именно в условиях ускорения развития

в непрерывно меняющемся мире становится критически актуальной концепция разработки информационных систем Security by Nature или, говоря по-другому, интегрированная безопасность. Поясню свою мысль на примере: для того чтобы автомобиль был безопасен по отношению к водителю, в начале прошлого века достаточно было ограничить скорость его передвижения и поставить ограждения вдоль дороги, чтобы минимизировать потенциальный ущерб. Но в современных условиях, когда потребность в количестве и скорости автомобилей непрерывно растет, в дорожном движении участвует огромное количество автомобилей, скорость перемещения, по сути, стала основной ценностью автомобиля, и ограждение дорог уже не обеспечивает должной безопасности для движения. Это стало возможным благодаря тому, что стали разрабатывать автомобили с интегрированными системами безопасности не только водителя и пассажира, но и других участников движения. Эти автомобили становятся все более и более безопасными по природе, и в конце концов они не смогут причинять вред ни водителям, ни пешеходам. По сути, сейчас мы подошли к такому же периоду в развитии информационных систем, к эдакой фазе информационных супермагистралей, на которых существует огромное количество взаимодействующих информационных систем и их пользователей. При этом необходимо, чтобы они не мешали другу другу и не несли угрозы. А угрозы безопасности зачастую реализуются неожиданно, их сложно предсказать по времени и нередко невозможно предотвратить. Вспоминается русская поговорка "Знал бы, где упасть, соломки постелил бы"; так вот, в современной динамической информационной среде "соломку" надо носить с собой. Чтобы повысить безопасность информационных систем, нужно думать о ней в тот момент, когда мы их задумываем, не рассчитывая, что потом их можно будет защитить файрволом или создать для них безопасную среду.

– Считаете ли вы, что безопасная разработка лежит в основе обеспечения безопасности информационных систем?

Akinin 3/26/21 9:32 PM Page 9

www.itsec.ru

ПЕРСОНЫ

– Да, конечно. Но я не люблю термин "безопасная разработка", он понятен только профессионалам в информационной безопасности. Вы знаете, очень тяжело переводить на русский язык английские слова, потому что Secure и Security – это разные понятия, а Security Development Lifecycle и Secure Development Lifecycle переводят одинаково – как жизненный цикл безопасной разработки. Но есть разница... Часто этот термин ассоциируют с разработкой безопасных систем, но это тоже не совсем точно. Потому что это создает иллюзию, что, проверив результат разработки на отсутствие уязвимостей и НДВ, мы можем говорить о его безопасности. Поэтому, когда мы говорим о безопасной разработке, наверное, правильнее было бы иметь в виду, что требования обеспечения безопасности должны учитываться во всех процессах разработки наравне с требованиями функциональности, производительности, надежности и т.д. Вы верно подметили в начале нашего разговора, что безопасность системы гораздо шире, чем информационная безопасность. Это нужно иметь в виду, когда речь идет о безопасной разработке: безопасность – это не только отсутствие уязвимостей и борьба с утечкой информации, но это также и основная составляющая общей надежности продукта. Почему-то, создавая информационные системы, разработчики всегда думают о надежности работы, об отсутствии ошибок, об удобстве использования и т.д., но ведь наличие уязвимости – та же ошибка, и с ней нужно ровно так же бороться, как с неправильно работающей кнопкой в интерфейсе. Раньше продукты выпускались на рынок практически без тестирования, потому что нужно было "быстреебыстрее, вперед-вперед". Что уж говорить о контроле безопасности разработки! Сейчас, когда мы говорим о качественной разработке, то подразумеваем наличие систем автодокументирования, автоматическое тестирование и т.д. Вот точно так же нужно говорить об автотестах на безопасность, как и об автотестах на все остальное. Конечно, это следствие появления Agile-концепции в ИТ, и это неплохо. Просто нужно уметь правильно ей пользоваться. Как? Для этого необходимо вдумчиво читать литературу, а не ограничиваться поверхностным ознакомлением с двенадцатью принципами Agile. Ведь существует огромное количество фреймворков, которые позволяют сделать Agile надежным, безопасным, управляемым, предсказуемым. А еще бережливым – есть даже такой термин, Lean Agile (бережливый), эта тема сейчас очень актуальна. Последнее время активно развиваются фреймворки, которые позволяют управлять большими проектами разработки.

Agile – это хорошо, гибко, быстро и

эффективно, когда есть самоорганизующаяся команда, как правило, размером не более десяти человек. Как только в команде оказывается более десяти человек, необходимо тратить дополнительные усилия на их организацию. В этот момент и возникают проблемы нормализации работы. Agile-разработку часто называют хаотичной в противовес "водопаду". Я заметил, что многие компании стали задумываться о том, как сформулировать новые принципы разработки, во многом заново изобретая велосипед. Например, Sbergile – фреймворк, который Сбербанк создал и позиционирует на российском рынке как систему управления крупной разработкой. Впрочем, Сбербанк, несомненно, может себе позволить потратить большое количество ресурсов и времени на создание собственного фреймворка управления Agile-разработкой. Большинству же компаний, наверное, целесообразней выбрать один из имеющихся. Есть различные готовые фреймворки, например SAFe, который позволяет командам с десятками, сотнями и тысячами разработчиков выстроить управление и получать запланированный результат в прогнозируемый срок в рамках выделенного бюджета, не забывая при этом про безопасность. И здесь без изменения образа мыслей, культуры разработчиков, представителей ИБ, как, впрочем, и владельцев бизнеса, не обойтись. Это то, чем мы сейчас активно занимаемся. Некоторое время назад один из ведущих мировых производителей систем для управления разработкой подписал с нами дистрибьюторское соглашение, и в данный момент мы активно продвигаем это решение на рынке. Речь о Digital AI. Это название появилось только в прошлом году вследствие объединения нескольких компаний, которые занимались управлением разработкой. Так в нашем портфеле появился новый класс продуктов Intelligent Value Stream Management Platform, но это, наверное, тема другого разговора.

– То есть можно сделать вывод, что безопасность систем заложена в процессе безопасной разработки?

– Именно так. Есть актуальный термин Shift Left, смысл которого можно передать как "давайте думать пораньше". Я уже упоминал русскую поговорку про солому, так вот, давайте думать, где мы можем упасть, заранее, и давайте возьмем с собой правильную "соломку", я говорю об интегрированной безопасности. Концепция Shift Left позволяет в условиях хаотичной разработки смещать контрольные функции, функции дизайна безопасности на более ранние этапы. Другими словами, недостаточно тестировать конечный продукт, тестирование должно происходить на более ранних фазах, когда продукт только начинает

разрабатываться, а еще лучше тестировать на безопасность алгоритмические модели, когда они только придумываются. Это, конечно, непросто, это требует изменения культурного кода разработки, но это дает хороший результат, и прежде всего в деньгах, в повышении качества и скорости разработки. Безопасная разработка – это целый комплекс мероприятий, который требует изменения подхода к процессу разработки. Я горячо поддерживаю ФСТЭК, который вынуждает разработчиков систем безопасности не ограничиваться проверкой кода на уязвимости и недекларированные возможности, но и развивать новый подход к обеспечению уровня доверия к процессу разработки, а это и есть Shift Left. Необходимо расширить этот подход на создание всех информационных систем, критичных для бизнеса, пользователей и нашей страны в целом. То есть мы должны быть уверены в процессе нашей разработки, в ней уже реализован определенный комплекс мер, обеспечивающий безопасность. Вот это и есть Security by Nature!

– Цифровизация образования, экономики, медицины и других сфер – это хорошо или плохо?

– Это отлично! Это повышение доступности.

– И минусов нет?

– Минусы есть везде. Цифровизация – это хороший тренд, но многие путают цифровизацию и автоматизацию, а это абсолютно разные вещи. Так же, как многие берут свои классические команды разработки, называют их Agile-командами или переименовывают программ-менеджеров в продакт-менеджеров, хотя это разные роли и без изменения образа мысли это не работает. Поэтому, когда речь идет о цифровизации, многие думают, что, переведя процессы в автоматизированную систему, они выполнили условия цифровизации. Категорически – нет! Цифровизация требует не только замены инструментов; замены бумаги на электронные бланки недостаточно. Цифровизация требует радикального изменения в подходах к ведению бизнеса, созданию цифрового продукта, к разработке нового программного обеспечения, отвечающего этому подходу, сейчас ПО становится основным средством производства пользовательской ценности, которым раньше были станки и конвейеры, и его безопасность нужно обеспечивать по-другому. ПО нельзя поставить за забор и нанять охрану, оно гораздо доступней для вторжения извне и внутренней диверсии, именно поэтому вопросы информационной безопасности настолько важны в современном мире. Но при всем при этом не нужно на них зацикливаться, это лишь один из критериев надежности, необходимый, но недостаточный для успеха бизнеса.

• 9

Akinin 3/26/21 9:32 PM Page 10

В ФОКУСЕ – Возрастающая скорость цифровизации – положительный фактор? К чему в итоге это приведет?

– Конечно. Мы движемся к тому, что системы становятся все более совершенными, надежными и безопасными, и скорость цифровизации вынуждает нас уделять все больше внимания интегрированной безопасности, безопасности по природе. Без этого уже сейчас невозможно обеспечить адекватную информационную безопасность бизнеса. Безопасность – это один из базовых принципов, один из критериев качества, и нельзя его отрывать от общих подходов к обеспечению качества. Если мы посмотрим на материалы, которые готовятся нашими и иностранными государственными институтами, то увидим, что в них делается акцент на комплексном подходе к качеству, включая требования к безопасности. Причем западные регуляторы уделяют особое внимание обеспечению качества в условиях гибкой разработки Agile. Безопасность – это неотъемлемая часть любой системы. Поэтому я категорически против того, чтобы обосабливать вопросы информационной безопасности, то есть терминологически отчуждать ее от общих подходов к обеспечению качества разработки. И я давно повторяю в разговорах со специалистами информационной безопасности: хватит быть препятствием. Так и говорю: хватит тормозить бизнес, давайте думать, что мы можем дать бизнесу, как сделать его более безопасным. Наверное, не всем это нравится, ну уж извините, пора меняться, жизнь вокруг меняется все быстрей, перед бизнесом, а в последнее время и перед государством стоит дилемма "Беги или умри". Другими словами, информационная безопасность должна быть не ограничителем для развития бизнеса, а напротив – деблокиратором (enabler), позволяющим бизнесу двигаться быстрее, без пробок, без угроз, по безопасной траектории. То есть информационная безопасность должна создавать безопасную среду для работы информационных систем там, где и когда это необходимо. Самый главный положительный фактор этой скорости в том, что мы делаем нашу систему одновременно доступной для всех клиентов в любом месте, но это и главный отрицательный фактор, одновременно мы делаем ее доступной для атак со стороны всех злоумышленников, увеличиваем поверхность атаки. Масштабы бизнеса меняются, открываются новые возможности для зарабатывания еще большего количества денег. Но, если не думать о безопасности, одновременно увеличивается риск потерять уже заработанное.

– Согласны ли вы с тем, что основными источниками утечек информации являются менеджеры среднего звена?

10 •

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

– Что является основополагающим при выборе вендора, с которым вам предстоит сотрудничать? Какие продукты вас интересуют в первую очередь?

– Прежде всего продукт должен работать. Поэтому мы тщательно испытываем все решения в собственной лаборатории до подписания дистрибьюторского контракта. Там же мы в дальнейшем демонстрируем системы и оборудование своим партнерам и конечным заказчикам. Затем я должен понять, какую пользу от его применения получит наш заказчик, и отсеять те продукты, которые не имеют потребительской ценности для наших заказчиков. Ну и наконец, мы выбираем продукты, которые будут востребованы завтра, а это непростой выбор. Мы изучаем тенденции рынка, аналитические отчеты и прогнозы, общаемся с конечными потребителями, узнаем их потребности. Кроме того, я стараюсь не работать с теми продуктами, которые уже присутствуют на российском рынке: не понимаю, в чем смысл отбирать кусок пирога у действующего дистрибьютора. В наш портфель попадает в лучшем случае одно решение из пяти рассмотренных. Конечно же, бывают и ошибки, но это осознанный риск. Такая работа требует постоянного обучения, расширения экспертизы. Наши инженеры проходят обучение у вендоров и сертификацию в различных областях. Я сам постоянно обучаюсь, потому что

предлагать нашим партнерам и клиентам можно только то, в чем сам хорошо разбираешься. По многим продуктам мы имеем собственных инструкторов и читаем авторизованные курсы. Сейчас, например, я изучаю SAFe – Scaled Agile Framework 5.0, уже получил сертификат SAFe 5 Agilist и готовлюсь к сдаче экзамена на сертификат консультанта по внедрению SAFe – SAFe 5 SPC. Я считаю, что невозможно предлагать на рынке продукты по управлению разработкой, не имея соответствующей квалификации в этой области.

– Как вы считаете, ситуация с коронавирусом отрицательно повлияла на бизнес или открыла новые возможности?

– Действительно, ситуация с коронавирусом и изменением экономического климата очень сильно повлияла и на наш бизнес – существенно снизились обороты, изменилась структура спроса. Но нужно осознать, что мы живем уже в новых условиях, назад пути нет, и сотрудники назад, в офисы, с удаленного режима не вернутся. Буквально вчера я разговаривал с братом, который учится в лондонской бизнес-школе. Там всерьез говорят о том, что главная ошибка людей в современном мире – это надежда, что все будет как прежде, все вернется назад. Не вернется, привыкайте к новым условиям! Как говорил Гераклит, нельзя дважды войти в одну и ту же реку. Россия оказалась чуть больше подготовленной к этим новым условиям, потому что наше государство имеет сравнительно высокий уровень цифровизации, к тому же мы с 2014 г. живем в критическом окружении в условиях нарастающего санкционного давления. Поэтому каких-либо катастрофических изменений в нашей жизни не последовало. Крупные мировые корпорации тоже не особо пострадали от этих новых условий, потому что уже давно работают удаленно, у них давно распределенная инфраструктура. У них есть головной офис, в котором, возможно, трудятся разработчики, финансисты и т.д., но основная часть европейских офисов территориально распределена. У некоторых компаний региональные офисы располагаются в бизнесцентре аэропорта, причем исключительно для проведения деловых встреч и поддержания документооборота. Все сотрудники, даже имеющие там кабинеты, работают из дома, приезжая в этот офис только ради переговоров. Так что большинство западных компаний были готовы к подобной работе, как и многие российские компании. Технологии-то у них имелись, но удаленная работа была скорее исключением в силу определенного консерватизма в подходах к обеспечению безопасности такой работы. В этих условиях оказались актуальными средства обеспечения удаленной работы привилегированных пользова-

Akinin 3/26/21 9:32 PM Page 11

www.itsec.ru

ПЕРСОНЫ

телей. Мы достаточно давно занимаемся этими системами. Один из наших вендоров, BeyondTrust, предлагает очень интересное решение, которое не только обеспечивает удаленную работу привилегированных пользователей с инфраструктурой заказчика, но и, в отличие от других поставщиков таких решений, имеет и систему удаленной поддержки пользователей, работающих вне офиса. Это вообще интересная тема, потому что когда сотрудники уехали в домашний офис, у них стали возникать новые технические проблемы. А как их решать? Как осуществлять поддержку удаленного сотрудника? Как решать проблемы с работой удаленного сотрудника? Использование Zoom или TeamViewer порождает бреши в безопасности! Поэтому безопасная удаленная поддержка – очень важный аспект безопасности бизнеса. Решать такие вопросы подручными средствами можно, но это может быть небезопасно. Все уже есть, все придумано. Ребята, не городите огород! Стоит учитывать опыт крупных распределенных международных компаний, чтобы не проигрывать им, чтобы получать выгоду для вашего бизнеса в нашей стране. То есть тот человек, который понимает, что делать с цифровизацией, как сделать бизнес независимым от локации, от квалификации персонала – именно такой человек получит наибольшее конкурентное преимущество в современном мире, заработает больше денег и сохранит их для своих потомков.

– Прислушиваются?

– Гром не грянет – мужик не перекрестится!

– А почему не прислушиваются? С чем это связано? Дело в менталитете?

– Нет, вы знаете, это не только проблема России. С момента организации бизнеса я часто общаюсь на различных партнерских конференциях с европейскими компаниями, дистрибьюторами – у них ровно та же история в Европе, Африке, Латинской Америке. В России в этом смысле ничего специфичного нет, бизнес везде похож, и везде бизнес считает деньги. Но очень тяжело посчитать недополученные деньги, и очень тяжело считать те убытки, которые мы не замечаем. Когда у вас крадут деньги, нужно знать, сколько их было в кошельке. Если не знаете, сколько у вас было денег в кошельке, то никогда не узнаете, взяли ли их оттуда или нет. Широко известна пирамида потребностей по Маслоу. То есть, условно говоря, когда не в чем выйти на улицу, например ботинки рваные, то вы не станете думать о покупке нового галстука. Я хочу сказать: когда у вас нет хорошо выстроенной системы идентификации пользователей, бессмысленно думать об управлении привилегиями, когда у

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

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

– Это сложный вопрос. Да, они пытаются это делать. Но, мне кажется, это контрпродуктивно. Точнее, такой подход устарел. Потому что этот подход иерархический, когда у нас есть некие функциональные подразделения, которые оказывают друг другу услуги. Мир уже другой. Для того чтобы выжить в

современных условиях, компании должны быть клиент-ориентированными, значит должны формировать кросс-функциональные команды, способные решать весь спектр задач в рамках определенного потока создания ценности. Вы все, наверное, помните этот "страшный" термин "матричная организация производства". Lean Agile – это, по сути, способ формирования команд и гибкого управления, но не проектных, а собранных вокруг создания пользовательской ценности. Как я уже говорил, жизнь меняется очень быстро и скорость этих изменений растет. Чем более жесткая иерархическая структура, чем больше функциональная специализация, тем сложнее перестраивать структуру и контролировать полноту функционального покрытия потребностей бизнеса. Жизнь заставляет нас создавать динамичные кросс-функциональные команды, способные удовлетворять конкретную потребность бизнеса или клиента. Бесполезно бороться с трендом ухода от иерархической системы управления. Да, я считаю, что информационная безопасность должна двигаться в сторону интеграции с другими подразделениями. И здесь как раз специалисты информационной безопасности могут выступать лидерами перемен, проводниками идеи безопасности по природе. Они должны стать источниками информации и источниками новой культуры в бизнесе. Мне больше нравится не сервисный, а экспертный подход, который завоевывает все большую и большую популярность. То есть специалисты ИБ должны стать экспертами для других подразделений в вопросах, что и как делать, быть открытыми для конструктивного общения в рамках гибких команд. Я верю в подход Security by Nature. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 11

Energynet 3/26/21 9:32 PM Page 12

ПРАВО И НОРМАТИВЫ

Открытая база знаний по информационной безопасности Алексей Петухов, лидер рабочей группы “Кибербезопасность” (НТИ “Энерджинет”) Дмитрий Правиков, директор НОЦ НИАТ РГУ нефти и газа (НИУ) имени И.М. Губкина

В

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

Оценка данной тенденции применительно к энергетике наиболее точно выражена в докладе экспертов ENISA1: интеллектуальные сети существенно улучшат контроль за потреблением и распределением электроэнергии в интересах потребителей, поставщиков электроэнергии и сетевых операторов. Тем не менее улучшение работы и услуг будет происходить за счет того, что вся электроэнергетическая сеть будет отвечать на новые вызовы, в частности в области безопасности сетей связи и информационных систем. Осознание данного вида угроз, в свою очередь, привело к разработке соответствующих защитных мер, как к появлению различного рода решений, направленных на защиту систем промышленной автоматизации, так и формированию соответствующей нормативной базы, включая рассмотрение несанкционированного воздействия на такие системы как уголовное преступление. При этом аналогичные процессы происходят во всех промышленно развитых странах, вставших на путь цифровизации своей индустриальной сферы. Перечисленные факторы привели к тому, что модель злоумышленника, который может несанкционированно воздействовать на системы промышленной автоматизации, начинает смещаться от условного компьютерного хулигана в сторону профессиональных криминальных сообществ, называемых отдельными экспертами кибернаемниками. Так, согласно отчету "Киберугрозы для промышленных предприятий в 2021 г." центра реагирования на инциденты информационной безопасности промышленных инфраструктур "Лаборатории Касперского" (Kaspersky ICS CERT), в 2021 г. будет еще больше вызовов.

1. Заражения будут становиться менее случайными или иметь неслучайные продолжения.

2. Злоумышленники продолжат использовать приемы хакерских атак и APT. 3. Количество APT-группировок продолжит расти.

1

4. Повысится конкурентная привлекательность предложений киберкриминала на соответствующем рынке труда. Активизации деятельности киберкриминальных группировок противопоставляется работа регуляторов, правоохранительных органов, вендоров, интеграторов и специалистов по информационной безопасности. При этом, если говорить о России, подавляющее большинство промышленных предприятий уже завершили процедуру категорирования своей критической информационной инфраструктуры и начали работу по созданию сил и средств обеспечения информационной безопасности. В ходе этой работы значительную роль играет формирование и развитие нормативной базы. Можно отметить, что на государственном уровне в России в целом сформирована нормативная база, регламентирующая подходы и требования к защите критической информационной инфраструктуры. Основные направления ее развития описаны в отчете ICS-CERT "Обеспечение безопасности КИИ. Что год текущий нам готовит…"2. Вместе с тем, как известно специалистам по обеспечению информационной безопасности АСУ ТП, нормативная база регуляторов определяет только базовые требования к системам защиты информации. Уточненные требования, отражающие специфику защищаемых процессов и архитектуры системы защиты, вырабатываются на основании документов, формируемых на уровне самого предприятия. Например, у каждого предприятия должны быть разработаны организационно-распорядительные документы, формирующие систему ИБ. Процедура их подготовки обычно предусматривает следующие процессы: l выделение перечня документов, относящихся к регулированию ИБ относительно типа защищаемого объекта; l поиск соответствующих методических документов; l разработка собственных документов на уровне предприятия. Все это требует значительной работы с нормативной базой как со стороны

https://www.enisa.europa.eu/publications/ENISA-smart-grid-security-recommendations https://ics-cert.kaspersky.ru/reports/2021/02/03/obespechenie-bezopasnosti-kiichto-god-tekuschii-nam-gotovit/ 2

12 •

регуляторов, так и со стороны интеграторов и служб информационной безопасности самих предприятий. Описанные проблемы вызывают сложности у многих участников рынка информационной безопасности. С целью повышения осведомленности специалистов профильных подразделений и специализированных организаций, участвующих в разработке, защите и эксплуатации объектов цифровой энергетики, в рамках рабочей группы "Кибербезопасность" НТИ "Энерджинет" разрабатывается открытая база знаний по информационной безопасности в энергетике. База знаний указанной системы будет основываться на требованиях по информационной безопасности, изложенных в нормативных документах российских регуляторов, рамочных нормативных документах различных международных организаций, параметрах систем и решений по обеспечению информационной безопасности различных вендоров, опыте интеграторов и на принятой в крупнейших российских предприятиях энергетической отрасли практике. Представляется, что разрабатываемая система позволит проводить аналитику всех существующих нормативно-правовых документов в различных направлениях: l консолидация и смысловая "взаимоувязка" существующих документов; l определение "белых мест" и противоречий в существующей НПА и т.д; l соответствие анализируемого документа нормативно-правовым актам. Ожидаемые эффекты: l оптимизация нормативной базы; l повышение качества разрабатываемых / актуализируемых документов пользователями (все участники сферы ИБ); l создание платформы для системного и интерактивного развития нормативной базы (все участники сферы ИБ). Данный продукт разрабатывается как открытая платформа с участием представителей рынка ИБ и образовательной сферы, входящих в рабочую группу "Кибербезопасность" НТИ "Энерджинет". Приглашаем всех неравнодушных к участию и взаимодействию. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

PhD 3/26/21 9:32 PM Page 13

Zavedenskaya 3/26/21 9:32 PM Page 14

ПРАВО И НОРМАТИВЫ

Январь-2021 Анастасия Заведенская, аналитик Аналитического центра Уральского центра систем безопасности

В Изменения в законе о персональных данных В преддверии нового года был опубликован Федеральный закон "О внесении изменений в Федеральный закон "О персональных данных" от 30.12.2020 № 519-ФЗ1 (далее – ФЗ № 519), меняющий понятийный аппарат Федерального закона "О персональных данных" от 27.07.2006 № 152-ФЗ (далее – ФЗ № 152). С 1 марта 2021 г. утрачивает силу дефиниция "персональные данные (далее – ПДн), сделанные общедоступными субъектом ПДн". Вместо упомянутых ранее ПДн вводится понятие "ПДн, разрешенные субъектом ПДн для распространения". ПДн, разрешенные субъектом ПДн для распространения, – это ПДн, доступ неограниченного круга лиц к которым предоставлен субъектом ПДн путем дачи соответствующего согласия. При этом в ФЗ № 152 все еще присутствует норма об общедоступных источниках ПДн, которые, в частности, упоминаются в постановлении Правительства РФ от 01.11.2012 № 1119 "Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных". Вопрос, как классифицировать (определять уровень защищенности) информационные системы, обрабатывающие ПДн, разрешенные субъектом ПДн для распространения, пока остается открытым. К основным особенностям обработки ПДн, разрешенных субъектом ПДн для распространения, вводимых ФЗ № 519, относятся: 1. Согласие на обработку ПДн, разрешенных субъектом ПДн для распространения, оформляется отдельно от иных согласий субъекта ПДн на обработку его ПДн. Требования к содержанию согласия 1 2

январском обзоре изменений законодательства 2021 г. рассмотрим изменения от регуляторов, которые были опубликованы как в канун нового года, так и в его начале. Поговорим о процессах обработки персональных данных, о нормотворческой деятельности ФСБ России и требованиях по безопасности для финансовых платформ.

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

2. Установлено явное требование по "активному" предоставлению согласия на обработку ПДн субъектом ПДн, то есть молчание или бездействие субъекта ПДн ни при каких обстоятельствах не может считаться согласием на обработку ПДн, разрешенных субъектом ПДн для распространения.

3. Субъект ПДн вправе определить в согласии категории и перечень ПДн, для обработки которых устанавливаются условия и запреты, а также перечень устанавливаемых условий и запретов. Условия и запреты предполагают ограничение или запрет осуществления оператором действий по распространению и (или) предоставлению ПДн неограниченному или определенному кругу лиц соответственно. Изменения, вводимые ФЗ № 519, как отмечается экспертным сообществом, могут повлечь за собой неоднозначность трактования требований, а также появление возможных противоречий в исполнении требований. В частности, если из согласия на обработку ПДн, разрешенных субъектом ПДн для распространения, не следует, что субъект ПДн не определил запреты и условия на обработку ПДн, такие ПДн обрабатываются оператором, которому они предоставлены субъектом ПДн, без передачи (распространения, предоставления, доступа) и возможности осуществления иных действий с ПДн неограниченному кругу лиц. То есть некорректно составленное согласие, направленное на разрешение субъектом распространения ПДн, может это распространение и ограничить.

Согласие на обработку ПДн, разрешенных для распространения Как и следовало ожидать, 27 января 2021 г. Роскомнадзор представил проект приказа "Об установлении требований

https://rg.ru/2021/01/11/personalnie-dannie-dok.html https://regulation.gov.ru/Projects/List#npa=112660

14 •

к содержанию согласия на обработку ПДн, разрешенных субъектом ПДн для распространения"2 (далее – проект приказа). Согласно проекту приказа упомянутое ранее согласие должно включать в себя: l фамилию, имя, отчество субъекта ПДн и его контактную информацию; l наименование или фамилию, имя, отчество и адрес оператора, получающего согласие субъекта ПДн; l цель (цели) обработки ПДн; l категории и перечень ПДн, на обработку которых дается согласие; l категории и перечень ПДн, для обработки которых субъект ПДн устанавливает условия и запреты, а также перечень устанавливаемых условий и запретов; l срок, в течение которого действует согласие; l сведения об информационных ресурсах оператора, посредством которых будет осуществляться предоставление доступа неограниченному кругу лиц и иные действия с ПДн субъекта ПДн. Стоит обратить внимание на то, что проект приказа вводит некоторую детализацию понятия – категории ПДн, а также уточняет, какие ПДн относятся к той или иной категории. По проекту приказа выделяются следующие категории ПДн: общие ПДн, специальные категории ПДн и биометрические ПДн. Таким образом, по проекту приказа: l общие Пдн: фамилия, имя, отчество (при наличии), год, месяц, дата рождения, место рождения, адрес, семейное положение, социальное положение, имущественное положение, образование, профессия, доходы, другая информация, относящаяся к субъекту ПДн; l специальные категории Пдн: расовая, национальная принадлежность, политические взгляды, религиозные или философские убеждения, состояния здоровья, интимной жизни, сведения о судимости; l биометрические Пдн: ДНК, радужная оболочка глаз, дактилоскопическая информация, цветное цифровое фотографическое изображение лица, голос, фотоизображение рисунка вен ладони, полученного в диапазоне, близком к инфракрасному, и иные сведения.

Zavedenskaya 3/26/21 9:32 PM Page 15

www.itsec.ru

Реклама

ПРАВО И НОРМАТИВЫ

Интересно, что ранее в нормативноправовых актах по обработке ПДн категория "общие ПДн" не применялась, а перечень биометрических ПДн содержит упоминание цифровых фотографий изображения лица, без каких-либо дополнительных атрибутов отнесения их к биометрическим ПДн. Стоит также отметить, что сам ФЗ № 519, вводящий необходимость согласия из проекта приказа, вступил в силу 1 марта 2021 г., однако требования к содержанию согласия к указанной дате все еще находились в проекте.

Обработка инцидентов информационной безопасности в ИСПДн Кроме того, изменения в ФЗ № 152 были внесены и опубликованным 30 декабря 2020 г. Федеральным законом от 30.12.2020 № 515-ФЗ "О внесении изменений в отдельные законодательные акты Российской Федерации в части обеспечения конфиденциальности сведений о защищаемых лицах и об осуществлении оперативно-розыскной деятельности"3. Теперь в ФЗ № 152 в меры по обеспечению безопасности ПДн при их обработке, кроме обнаружения фактов несанкционированного доступа к ПДн, включены и меры по обнаружению, предупреждению и ликвидации последствий компьютерных атак на информационные системы ПДн и по реагированию на компьютерные инциденты в них.

ФСБ России и электронная подпись В конце 2020 г., 31 декабря, официально были опубликованы приказы ФСБ России, регулирующие вопросы,

связанные с электронной подписью (далее – ЭП) и вступающие в силу в январе 2021 г.: 1. Приказ ФСБ России от 04.12.2020 №554 "Об утверждении Порядка уничтожения ключей электронной подписи, хранимых аккредитованным удостоверяющим центром по поручению владельцев квалифицированных сертификатов электронной подписи"4.

2. Приказ ФСБ России от 04.12.2020 № 555 "О внесении изменений в приложения № 1 и 2 к приказу ФСБ России от 27 декабря 2011 г. № 796 "Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра"5.

3. Приказ ФСБ России от 04.12.2020 № 556 "Об утверждении Требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи"6. А уже в январе 2021 г. ФСБ России представила для публичного обсуждения проекты ведомственных актов также из области ЭП: l о внесении изменения в п. 2 приказа ФСБ России от 4 декабря 2020 г. № 554 "Об утверждении Порядка уничтожения ключей электронной подписи, хранимых аккредитованным удостоверяющим центром по поручению владельцев квалифицированных сертификатов электронной подписи"7; l о внесении изменения в приказ ФСБ России от 4 декабря 2020 г. № 555 "О внесении изменений в приложения № 1 и 2 к приказу ФСБ России от 27 декабря 2011 г. № 796 "Об утверждении Требований к средствам электронной подписи и Требований к средствам удостоверяющего центра"8;

l о внесении изменения в п. 2 приказа ФСБ России от 4 декабря 2020 г. № 556 "Об утверждении Требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи"9. l об утверждении правил подтверждения владения ключом электронной подписи10.

Лицензирование деятельности по разработке СКЗИ 25 января 2021 г. официально опубликован приказ ФСБ России от 29.12.2020 № 641 "Об утверждении Административного регламента Федеральной службы безопасности Российской Федерации по предоставлению государственной услуги по лицензированию деятельности по разработке, производству, распространению шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, выполнению работ, оказанию услуг в области шифрования информации, техническому обслуживанию шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств (за исключением случая, если техническое обслуживание шифровальных (криптографических) средств, информационных систем и телекоммуникационных систем, защищенных с использованием шифровальных (криптографических) средств, осуществляется для обеспечения собственных нужд юридического лица или индивидуального предпринимателя)"11 (далее – приказ ФСБ России № 641).

3

http://publication.pravo.gov.ru/Document/View/0001202012300041 http://publication.pravo.gov.ru/Document/View/0001202012310004?index=1&rangeSize=1 5 http://publication.pravo.gov.ru/Document/View/0001202012310003?index=1&rangeSize=1 6 http://publication.pravo.gov.ru/Document/View/0001202012310012 7 https://regulation.gov.ru/Projects/List#npa=112637 8 https://regulation.gov.ru/Projects/List#npa=112640 9 https://regulation.gov.ru/Projects/List#npa=112641 10 https://regulation.gov.ru/Projects/List#npa=112563 11 http://publication.pravo.gov.ru/Document/View/0001202101250027?index=0&rangeSize=1 4

• 15

Zavedenskaya 3/26/21 9:32 PM Page 16

ПРАВО И НОРМАТИВЫ Приказ ФСБ России № 641 определяет новый административный регламент лицензирования деятельности по разработке, производству, распространению средств криптографической защиты информации (далее – СКЗИ). Также утрачивает силу приказ ФСБ России от 30 августа 2012 г. № 440, утверждающий предыдущий административный регламент оказания государственной услуги. Заявителям на лицензируемые виды деятельности стоит обратить внимание на изменения в формы заявлений в ФСБ России, требования к которым предъявляются в зависимости от оказываемой государственной услуги.

Обеспечение безопасности операторами финансовых платформ 28 января 2021 г. официально опубликовано положение Банка России от 03.12.2020 № 742-П "О требованиях по защите информации, которые должно выполнять юридическое лицо, намеревающееся получить статус оператора финансовой платформы, о ведении Банком России реестра операторов финансовых платформ и о требованиях к порядку регистрации Банком России

изменений в правила финансовой платформы"12 (далее – положение Банка России № 742-П). Стоит отметить, что о проекте положения Банка России № 742-П мы уже писали ранее в октябре 2020 г.13, но на тот момент оно было указанием "О ведении Банком России реестра операторов финансовых платформ, о требованиях к юридическому лицу, намеревающемуся получить статус оператора финансовой платформы, по защите информации, и о требованиях к порядку регистрации Банком России изменений в правила финансовых платформ"14. В целом основной подход к требованиям по защите информации, которые должны выполнять юридические лица, намеревающиеся получить статус оператора финансовой платформы (далее – соискатель), по сравнению с проектом не изменился, но теперь это конкретные указания для выполнения определенных норм по ИБ для конкретных объектов защиты. Так, по положению Банка России № 742-П: 1. Защита информации должна осуществляться в отношении эксплуатируемых автоматизированных систем, программного обеспечения, средств вычис-

лительной техники, телекоммуникационного оборудования в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р 57580.1–2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер"(далее – ГОСТ Р 57580.1–2017); 2. Требования ГОСТ Р 57580.1–2017 должны применяться по результатам определения применимого к соискателю уровня защиты информации, предусмотренного ГОСТ Р 57580.1–2017.

3. Соискатель должен обеспечить уровень соответствия не ниже третьего согласно национальному стандарту Российской Федерации ГОСТ Р 57580.2–2018 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Методика оценки соответствия". Как и было в проекте положения Банка России № 742-П, оценка соответствия по направлению "Безопасность информационной инфраструктуры" должна осуществляться с привлечением сторонних организаций, имеющих лицензию на деятельность по технической защите конфиденциальной информации. l

Февраль-2021 Анастасия Заведенская, аналитик Аналитического центра Уральского центра систем безопасности

В

торой месяц 2021 г. оказался плодотворным на нормотворческую деятельность в области защиты информации. В февральском обзоре рассмотрим и новые методики от ФСТЭК России, и очередные усилия Минцифры России в сфере импортозамещения в КИИ, а также изменения в административных штрафах в области обработки ПДн и изменения в положениях о защите информации Банка России.

Методика оценки угроз безопасности информации Информационным сообщением 15 от 15 февраля 2021 г. N 240/22/690 ФСТЭК России проинформировала об утверждении Методики оценки угроз безопасности информации 16 (далее – Методика). В связи с утверждением Методики для оценки угроз безопасности информации больше не применяются Методика определения актуальных угроз безопасности персональных данных (далее – ПДн) при их обработке в информационных системах ПДн (ФСТЭК России, 2008 г.) и 12

Методика определения актуальных угроз безопасности информации в ключевых системах информационной инфраструктуры (ФСТЭК России, 2007 г.). Обязательно применение Методики к системам и сетям, отнесенным к государственным и муниципальным информационным системам, информационным системам ПДн, значимым объектам критической информационной инфраструктуры (далее – КИИ), информационным системам управления производством, используемым организациями оборонно-промышленного комплекса, автоматизированным

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

https://cbr.ru/Queries/UniDbQuery/File/90134/1224 См. Заведенская А.А. Обзор изменений законодательства в сентябре и октябре 2020 года // Information Security/ Информационная безопасность. 2020. № 5. С. 4–8.

14 https://regulation.gov.ru/projects#npa=109072 15 https://fstec.ru/normotvorcheskaya/informatsionnye-i-analiticheskie-materialy/2169-informatsionnoe-soobshchenie-fstek-rossii-ot15-fevralya-2021-g-n-240-22-69 16 https://fstec.ru/component/attachments/download/2919 13

16 •

Zavedenskaya 3/26/21 9:32 PM Page 17

www.itsec.ru

ПРАВО И НОРМАТИВЫ

Пирамида цифровых угроз

Импортозамещение в критической информационной инфраструктуре (и не только) 2 февраля 2021 г. Минцифры России в очередной раз представило к общественному обсуждению проект постановления Правительства РФ "Об утверждении требований к программному обеспечению, телекоммуникационному оборудованию и радиоэлектронной продукции, используемым на объектах критической информационной инфраструктуры, и порядка перехода на преимущественное использование российского программного обеспечения, телекоммуникационного оборудования и радиоэлектронной продукции" (далее – проект ПП РФ). К проекту ПП РФ для публичного обсуждения также приложен порядок перехода на преимущественное использование российского программного обеспечения (далее – ПО), телекоммуникационного оборудования и радиоэлектронной продукции (далее при совместном упоминании – ПО и оборудование). Напомним, что первые варианты проектов нормативно-правовых актов, направленных на импортозамещение в КИИ, были опубликованы еще в мае 2020 г. 17. Октябрьские проекты 2020 г.18 получили отрицательную оценку регулирующего воздействия. В новой версии проекта ПП РФ отказались от термина "оборудование, 17 18

используемое на объектах КИИ", уточнив область действия импортозамещения – телекоммуникационное оборудование и радиоэлектронная продукция. Чтобы ПО и оборудование, используемые на объектах КИИ, соответствовали требованиям новой редакции проекта ПП РФ, они должны быть включены в единый реестр российских программ для электронных вычислительных машин и баз данных (далее – РПО) или единый реестр программ для электронных вычислительных машин и баз данных из государств – членов Евразийского экономического союза (далее – РЕП) и (или) в единый реестр российской радиоэлектронной продукции (далее – РРП). Если же ПО и оборудование не включены в РПО (или РЕП) и (или) в РРП, субъект КИИ обязан предусмотреть для них: l возможность модернизации российскими организациями; l возможность гарантийного обслуживания и технической поддержки российскими организациями. Таким образом, субъект КИИ для всех объектов КИИ (независимо от присвоения им категории значимости) будет обязан: 1. Провести аудит существующего и (или) проектируемого объекта КИИ.

2. Провести анализ требований, вводимых проектом ПП РФ, и наличия аналогов используемого (планируемого для

использования) иностранного ПО и оборудования, включенных в РПО, РЕП и (или) РРП.

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

4. По результатам проведенного анализа направить на согласование перечень используемых и (или) планируемых для использования иностранных ПО и оборудования с кратким обоснованием предъявляемых требований, в части ПО – в Минцифры России,в части телекоммуникационного оборудования и радиоэлектронной продукции в – Минпромторг России.

5. С учетом проведенного анализа и при наличии (в случае необходимости) согласования Минцифры России и (или) Минпромторга России определить перечень потенциального российского ПО, оборудования и радиоэлектронной продукции для дальнейшего перехода на его использование.

6. По итогам реализованных мероприятий, с учетом сроков перехода на преимущественное использование отечественного ПО и оборудования, подготовить и до 1 июля 2021 г. утвердить план перехода на преимущественное использование российского ПО и оборудования (далее – план).

https://regulation.gov.ru/projects#npa=102172 https://regulation.gov.ru/Projects/List#npa=109874

• 17

Zavedenskaya 3/29/21 5:27 PM Page 18

ПРАВО И НОРМАТИВЫ Таблица 1. Административная ответственность за нарушение требований по обработке персональных данных Административное правонарушение

Лицо

Действующий размер штрафа, тыс. рублей

Обработка ПДн в случаях, не Физическое лицо предусмотренных Должностное лицо законодательством, либо Индивидуальный обработка ПДн, предприниматель несовместимая с целями Юридическое лицо сбора ПДн Обработка ПДн без согласия в письменной форме в случаях, когда такое согласие должно быть получено, либо обработка ПДн с нарушением требований к составу сведений, включаемых в согласие в письменной форме Невыполнение оператором обязанности по опубликованию или обеспечению иным образом неограниченного доступа к политике оператора в отношении обработки ПДн Невыполнение оператором обязанности по предоставлению субъекту ПДн информации, касающейся обработки его ПДн Невыполнение оператором в требуемые сроки требования субъекта ПДн или его представителя Роскомнадзора об уточнении ПДн, их блокировании или уничтожении Невыполнение оператором при обработке ПДн без использования средств автоматизации требований к такой обработке Невыполнение оператором, являющимся государственным или муниципальным органом, обязанности по обезличиванию ПДн либо несоблюдение установленных требований или методов по обезличиванию ПДн

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

1–3

2–6

4–12

5–10

10–20

20–50

–

–

50–100

30–50

60–100

100–300

Физическое лицо

3– 5

6–10

10–20

Должностное лицо

10–20

20–40

40–100

Индивидуальный предприниматель Юридическое лицо

–

–

100–300

15–70

30–150

300–500

Физическое лицо

0,7–1,5

1,5–3

–

Должностное лицо

3–6

6–12

–

Индивидуальный предприниматель Юридическое лицо

5–10

10–20

–

15–30

30–60

–

Физическое лицо

1–2

2–4

–

Должностное лицо

4–6

8–12

–

Индивидуальный предприниматель Юридическое лицо

10–15

20–30

–

20–40

40–80

–

Физическое лицо

1–2

2–4

12–30

Должностное лицо

4–10

8–20

30–50

Индивидуальный предприниматель Юридическое лицо

10–20

20–40

50–100

20–45

50–90

300–500

Физическое лицо

0,7–2

1,5–4

–

Должностное лицо

4–10

8–20

–

Индивидуальный предприниматель Юридическое лицо

10–20

20–40

–

25–50

50–100

–

Должностное лицо

3–6

6–12

–

7. В течение 30 рабочих дней с момента утверждения плана направить его копию в Минцифры России и Минпромторг России.

P.S. В качестве дополнения к теме импортозамещения стоит отметить инте19

Вводимый размер штрафа, тыс. рублей

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

Экономическая значимость объектов критической информационной инфраструктуры ФСТЭК России в феврале 2021 г. был опубликован проект методических рекомендаций по оценке показателей критериев экономической значимости объектов КИИ20 (далее – проект рекомендаций). Проект рекомендаций определяет методические подходы к оценке показателей критериев экономической значимости объектов КИИ, проводимой в соответствии с Правилами категорирования объектов КИИ, утвержденными постановлением Правительства РФ от 8 февраля 2018 г. № 127. Следует отметить, что по постановлению Правительства РФ от 13.04.2019 № 452 "О внесении изменений в постановление Правительства Российской Федерации от 8 февраля 2018 г. № 127" субъекты КИИ, являющиеся государственными органами или учреждениями, должны были закончить процесс категорирования до 1 сентября 2020 г. Однако проект рекомендаций публикуется впервые. Исходя из проекта рекомендаций, регулятор также считает, что показатель ущерба бюджетам Российской Федерации применим ко всем субъектам КИИ.

Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении Информационным сообщением21 от 10 февраля 2021 г. N 240/24/647 ФСТЭК России сообщает о разработке новой редакции Методики выявления уязвимостей и недекларированных возможностей в программном обеспечении (далее – Методика выявления уязвимостей и НДВ). Методика выявления уязвимостей и НДВ предназначена для организаций, осуществляющих создание специализированных средств защиты информации, заявителей на осуществление сертификации, а также для испытательных лабораторий и органов по сертификации, выполняющих работы по сертификации средств. Методика выявления уязвимостей и НДВ носит ограничительную пометку "ДСП" и предоставляется ФСТЭК России по мотивированному запросу.

Изменения в приказ ФСТЭК России от 14.03.2014 № 31 20 февраля 2021 г. ФСТЭК России опубликовала проект приказа "О внесении изменений в Требования к

https://rkn.gov.ru/news/rsoc/news73380.htm https://fstec.ru/component/attachments/download/2917 21 https://fstec.ru/normotvorcheskaya/informatsionnye-i-analiticheskie-materialy/2171-informatsionnoe-soobshchenie-fstek-rossii-ot10-fevralya-2021-g-n-240-24-647 22 https://regulation.gov.ru/Projects/List#npa=113431 20

18 •

Zavedenskaya 3/26/21 9:32 PM Page 19

www.itsec.ru

ПРАВО И НОРМАТИВЫ

обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды, утвержденные приказом Федеральной службы по техническому и экспортному контролю от 14 марта 2014 г. № 31"22. Как и следовало ожидать, изменения направлены на приведение требований по сертификации средств защиты информации в соответствие к действующим в настоящее время в системе сертификации ФСТЭК России требованиям к уровням доверия (Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической

защиты информации и средствам обеспечения безопасности информационных технологий, утвержденным приказом ФСТЭК России от 2 июня 2020 г. № 76).

Административная ответственность за нарушение требований по обработке персональных данных Федеральным законом от 24 февраля 2021 г. № 19-ФЗ "О внесении изменений в Кодекс Российской Федерации об административных правонарушениях"23 (далее – ФЗ № 19). С 27 марта 2021 г. увеличивается размер штрафов по большинству составов нарушений законодательства Российской Федерации в области ПДн, а также появилась ответственность за повторное нарушение по ряду оснований. Перечень изменений в административные штрафы приведен в таблице 1.

Требования к защите информации в платежной системе Банка России 15 февраля 2021 г. официально опубликовано положение Банка России от 23.12.2020 № 747-П "О требованиях к защите информации в платежной системе Банка России"24 (далее – 747-П).

747-П официально вступило в силу 26 февраля 2021 г. (за исключением положений, для которых установлены иные сроки вступления в силу) и признает утратившим силу положение Банка России от 09.01.2019 № 672-П. Положения практически совпадают по содержанию, однако есть изменения, связанные с внесением изменений в Федеральный закон от 27.06.2011 № 161-ФЗ "О национальной платежной системе", выходом нового положения от 24.09.2020 № 732-П "О платежной системе Банка России", изменениями в подходе Банка России к управлению рисками. l

23 http://publication.pravo.gov.ru/Document/View/0001202102240010? index=0&rangeSize=1&fbclid=IwAR141sjRsN3O5ndM_zjyFEFoMTO9RH5O4GGdk8Vh06hLbz1S6gvva FACf-U 24 https://cbr.ru/Queries/UniDbQuery/File/90134/1243

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Колонка эксперта

Критерии выбора системы PAM Николай Валаев, специалист по продуктам контроля привилегированного доступа компании Web Control В контексте нормального функционирования процессов анализа данных и принятия решений важно, чтобы каждый участник для исполнения своих обязанностей был обеспечен доступом к необходимым и достаточным ресурсам. Не больше! Для поддержания правильной работы информационной системы нужны администраторы, обладающие привилегией доступа ко всем ее подсистемам и компонентам. Возникает вопрос: как организовать выдачу прав доступа и установить ответственность для такой необычной категории пользователей? Чтобы структурировать доступ системных администраторов к корпоративным ресурсам, существуют системы контроля привилегированного доступа, PAM (Privilege Access Management).

Что нужно учесть при выборе PAM? Управляемая ИТ-инфраструктура должна быть достаточно сложной. Если у вас работают, к примеру, два сменных администратора, вполне можно обойтись стандартными средствами контроля доступа. Однако же если администраторов, серверов и систем больше двух десятков, если наблюдается текучка кадров, если вы привлекаете аутсорсеров, о которых зачастую известен лишь логин, если бизнесу необходимо защищать коммерческую

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

Что PAM должна уметь?

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

2. Нужна высокая доступность системы PAM и инструкция по действиям в случае ее отказа.

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

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

5. PAM должна уметь работать в гетерогенной среде, иметь возможность управлять всем существующим и буду-

щим набором систем и средств вашего ИТ-ландшафта.

6. Система должна поддерживать весь набор привычных вашим администраторам инструментов. Недоступность неограниченного доступа для пользователей обеспечивается за счет сокрытия паролей от привилегированных учетных записей. Система PAM сама создаст новую сессию, инжектирует логин и пароль в нужные окна и после авторизации выдаст готовую сессию пользователю. Если же необходимо раскрыть пользователю пароль, система сама поменяет этот пароль после использования. Поддерживается также контроль использования разделенных учетных записей. С помощью PAM вы без большого труда найдете того, кто, к примеру, пару недель назад неправомерно загрузил образ из-под root. В системе PAM должна поддерживаться видеозапись и журналирование всех действий пользователей с возможностью последующего поиска с фильтрацией. Во избежание ненужной траты человеческого ресурса на мониторинг в режиме 24х7 должна поддерживаться автоматическая реакция системы на некорректные действия пользователей в виде уведомлений офицерам ИБ, предупреждений пользователям, блокировки или перехвата ввода либо полной блокировки учетной записи пользователя. l

• 19

Landfield 3/26/21 9:32 PM Page 20

ТЕХНОЛОГИИ

Bring Your Enterprise Home. Кибербезопасность корпоративного уровня дома у сотрудников Кент Лэндфилд (Kent Landfield), главный специалист по разработке политики стандартов и технологий компании McAfee

Б NIST Cybersecurity Framework1, один из основных американских регламентов, адресован предприятиям, а не частным лицам. При этом число устройств и подключений в домах в наше время намного превышает аналогичные показатели, характерные для малого бизнеса двадцатилетней давности. Домашние ИТ-системы развиваются по той же схеме, что и системы малых предприятий, поэтому нуждаются в дополнительном внимании и защите. Пандемия COVID-19 в мгновение ока изменила привычный уклад организаций и стала причиной вынужденного перевода сотрудников из централизованных рабочих сред на высокораспределенные инфраструктуры для работы из дома. Внезапный переход на незащищенную и неконтролируемую "удаленку", включая ИТ, IoT, мобильные, облачные и другие среды, значительно усложнил обеспечение кибербезопасности предприятий и одновременно серьезно расширил поверхность цифровых атак. Поскольку многим сотрудникам приходится использовать для решения рабочих задач личные устройства, организациям необходимо внедрять политики, которые улучшат управление и контроль над ними. Концепция BYOD (Bring Your Own Device, личные устройства на работе) трансформировалась в BYEH (Bring Your Enterprise Home, корпоративные устройства дома). Чтобы адаптироваться к этой перемене, нужны новые стандарты и процедуры безопасности.

1

https://www.nist.gov/cyberframework

20 •

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

И хотя в нашей компании, как и на других предприятиях, изначально имелись политики, процессы, средства управления, оборудование и программное обеспечение для защиты такой распределенной корпоративной экосистемы, все же они разрабатывались с учетом того, что современный частный дом – не самая "гостеприимная" среда для внедрения защит. Например, в домашней среде могут присутствовать умные замки и розетки, несколько телевизоров Smart TV и устройств для потоковой передачи данных, охранная система, цифровые ассистенты, беспроводные светильники, колонки, камеры, термостаты и другие подключенные устройства. И все это не считая компьютеров, ноутбуков, планшетов и смартфонов. Устройства IoT, число которых постоянно растет, позволяют превратить обычные дома в умные, но собственники не всегда знают, как эффективно защитить это оборудование от киберпреступников. Кроме того, многие решения не поддерживают интеграцию или обмен данными с другими системами, что уменьшает возможности обнаружения слабых мест в защите. Сегодня хакер может проникнуть в дом, не переступая его порога, и похитить у вас самое ценное – банковский счет, реквизиты доступа и душевный покой, например включив свет в три утра или музыку из умных колонок на полную громкость. Это серьезная проблема как для физических лиц, так и для компаний и государства, ведь "удаленка" – это возможность продолжить работу, несмотря на пандемию COVID-19. Посчитайте в квартире все умные и обычные устройства и умножьте их на количество сотрудников государственных ведомств, работающих уда-

ленно, чтобы получить представление о масштабах создавшейся угрозы. Прибавьте сюда подрядчиков госучреждений, уровень безопасности систем которых обычно ниже, чем у штатных работников. И речь уже идет об угрозах национального масштаба, поэтому организациям необходимо обеспечить надежную защиту удаленного доступа сотрудников к служебным ресурсам. При этом кибербезопасность – только одна из областей, на которую нужно обратить внимание. Например, в случае выхода оборудования из строя поставщики услуг в первую очередь предоставляют поддержку корпоративным клиентам. Если о неисправности сообщила компания, ее устранят за пару часов. Потребители могут прождать решения проблемы несколько дней. Однако сегодня ответ на вопрос, какое удаленное подключение является критически важным для бизнес-процессов, не столь очевиден. Как организации сообщить провайдеру о том, что конкретная линия связи имеет приоритет и нуждается в срочном внимании? Как включить в концепцию "домашних терминалов" тот факт, что они являются компонентами инфраструктуры конкретного предприятия? "Удаленка" превратила квартиры в домашние офисы, виртуальные учебные классы, кабинеты врача и магазины, а каждое подключенное личное устройство – в потенциальный источник опасности для работодателей. Пока мы пытаемся адаптироваться к новым реалиям, очень важно переосмыслить безопасность домов и квартир, а также разработать стандарты их защиты. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Okbsapr2 3/26/21 9:32 PM Page 21

www.itsec.ru

КОНТРОЛЬ ДОСТУПА

Инструменты контроля доступа для организации удаленной работы Светлана Конявская, заместитель генерального директора ОКБ САПР

Ч

его сегодня на рынке защиты информации (и информационных технологий в целом) с избытком, так это разнообразных средств организации более-менее безопасной удаленной работы. Как водится, не все они одинаково полезные, однако конъюнктура момента такова, что пригодится все.

На правах рекламы

Мы тоже предлагаем целый ряд решений этой задачи, и, как пишут сегодня все вендоры с историей, это решения, не быстро сооруженные в новых обстоятельствах, а разработанные давно, хорошо продуманные и имеющие внедрения. О них мы не раз писали, в том числе и на страницах этого журнала1–3. Ведется работа в данном направлении и регуляторами. И пока нормативные и методические требования в стадии разработки и утверждения, мы решили обратить внимание читателей на то, что сегодня вполне возможно построить удаленную работу в привычных категориях защищенной корпоративной информационной системы, в которой все компоненты, участвующие каким-либо образом в обработке данных, являются частью этой системы и полностью подконтрольны ее управляющему персоналу. Это решение – защищенные терминалы. Оно очевидно, но обычно не рассматривается, потому что предполагается, что раздать всем сотрудникам терминалы для удаленной работы окажется слишком дорого. Защищенные терминалы разработки ОКБ САПР – m-TrusT Терминал и Центр-TrusT позволяют сделать организацию удаленного рабочего места, защищенного до класса КС3 включительно, не только достаточно простой и эффективной, но и недорогой. Варианты реализации защищенного терминала различаются способом организации хранения и загрузки ОС: l первый вариант – ОС полностью хранится в памяти микрокомпьютера, доступной в режиме "только чтение". Такой вариант реализации защищенного терминала называется m-TrusT Терминал; l второй вариант – в переменную часть выделяется не только конфигурация, но и некий набор функционального ПО, то, что не может располагаться в неизменяемой памяти. В этом случае загружаться переменная часть образа ОС может по технологии защищенной сете-

вой загрузки "Центр-Т". Такой вариант реализации защищенного терминала называется Центр-ТrusT. Функциональность защищенного терминала такова, что пользователь может работать на нем, как на обычном ПК, но при этом посредством криптографических механизмов обеспечивается защита критичной информации и высокий уровень вычислительной мощности.

Рис. 2. Общий вид микрокомпьютера m-TrusT

Рис. 1. m-TrusT Терминал Построены эти терминалы на базе специализированного микрокомпьютера с аппаратной защитой данных m-TrusT4. Защищенный терминал на базе микрокомпьютера m-TrusT является компьютером Новой гарвардской архитектуры, что обеспечивает ему "вирусный иммунитет". Встроенный резидентный компонент безопасности (РКБ) позволяет создать и поддерживать доверенную среду функционирования криптографии и высокий уровень конфиденциальности. Подключение к серверам обработки данных по защищенному каналу связи и использование встроенного аппаратного блока неизвлекаемого ключа обеспечивает простоту использования с соблюдением всех требований регулятора. Аппаратная платформа терминала имеет производительный процессор – RK3399, поддерживает последние версии ядра Linux, интерфейсы USB 3.0 и USB Type-C, что обеспечивает высокий уровень вычислительной мощности. Ресурсы терминала позволяют обеспечить СФК, дающую возможность сертифицировать вариант исполнения раз-

личных СКЗИ на m-TrusT на класс КС3. В настоящее время есть СКЗИ с действующими сертификатами классов КС2 и КС3 в исполнении на m-TrusT. В m-TrusT Терминал предустановлено СДЗ (Аккорд-MKT), сертифицированное ФСТЭК России, а также опционально – СЗИ НСД, также сертифицированное ФСТЭК России (Аккорд-X K). Дополнительно возможны: l реализация поддержки sd-карт; l реализация блока защиты от инвазивных атак.

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

is@groteck.ru

1

Конявская С.В. Доверенные мобильные решения, 5G и другие кошмары // Inside. Защита информации. 2020. № 5 (95). С. 25–31. Конявская С.В. Средства обеспечения контролируемой вычислительной среды удаленного пользователя // Information Security/Информационная безопасность. 2020. № 2. С. 34–35.

3 Конявская С.В. Самоизоляция сотрудников не защитит от заражения информационную систему // Information Security/Информационная безопасность. 2020. № 2. С. 6.

4 Батраков А.Ю., Конявский В.А., Счастный Д.Ю., Пярин В.А. Специализированный компьютер с аппаратной защитой данных. Патент на полезную модель № 191690. 15.08.2019, бюл. № 23.

2

• 21

indeed-id 3/26/21 9:32 PM Page 22

ТЕХНОЛОГИИ

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

В

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

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

Угрозы нарушения конфиденциальности учетных данных Перехват вводимых учетных данных в изолированной среде Одной из мер защиты информации при организации удаленной работы в случае, если сотрудник использует личное устройство, является виртуализация рабочих мест и публикация приложений на терминальном сервере с последующей изоляцией среды. Действительно, если на личном устройстве сотрудника будет установлено вредоносное ПО, оно не сможет воздействовать на рабочую среду или рабочие приложения. Однако даже если и для самого удаленного подключения используется альтернативная аутентификация, в случае подключения к виртуализированному рабочему месту (VDI) и терминальному приложению (например, по RemoteApp) высока вероятность того, что приложение потребует авторизации с помощью логина и пароля. В таком случае вредоносное ПО может перехватить нажатия клавиш, вычислить корректное сочетание "логин – пароль", и злоумышленник уже по другому каналу сможет получить доступ к конфиденциальным данным. Для нейтрализации этой угрозы рекомендуется использовать решения класса Single Sign-On (SSO) совместно с решениями для альтернативной усиленной аутентификации. Решение SSO должно быть установлено на офисных рабочих местах, к которым сотрудник подключается по VDI, либо на терминальном сервере. Далее для подтверждения аутентификации в корпоративных приложениях

22 •

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

Клонирование генератора одноразовых паролей Безусловно, методы усиленной (двухфакторной) аутентификации значительно повышают стойкость к угрозам при удаленном доступе. Однако разные технологии усиленной аутентификации имеют существенные различия как с точки зрения применимости, так и с точки зрения безопасности. Популярные сегодня методы двухфакторной аутентификации с помощью одноразовых кодов, генерируемых на устройстве или присылаемых в мессенджерах, имеют существенные уязвимости: если злоумышленник получит однократный продолжительный доступ к смартфону, то он может попытаться получить повышенные привилегии на смартфоне (jailbreak для iOS-устройств, root-права для Androidустройств). И если это удастся, он сможет клонировать ключи генератора одноразовых паролей либо настроить себе получение сообщений в мессенджерах на личном компьютере. Если описанный риск имеет высокую вероятность, рекомендуется вместо одноразовых паролей использовать pushаутентификацию, которая явно привязана к устройству и не будет работать на девайсе злоумышленника.

Угрозы нарушения доступности корпоративных ресурсов Удаленная блокировка учетных данных Зачастую для доступа к корпоративным ресурсам используются публичные веб-сервисы, доступные через Интернет, например веб-клиент почты.

Часто имя почтового ящика совпадает с именем доменной учетной записи. Злоумышленник может попытаться разгадать пароль методом подбора. Для нейтрализации этой угрозы включается блокировка учетной записи после нескольких неудачных попыток ввода пароля. Однако злоумышленник может перебирать пароли для последующей целенаправленной блокировки доменной учетной записи. Такая атака способна привести к частичному параличу некоторых бизнес-процессов. С целью частичной нейтрализации данной угрозы можно воспользоваться специализированным решением для двухфакторной аутентификации (2FA), например одноразовыми паролями. При этом, даже если осуществляется попытка перебора, будет заблокирован второй аутентификатор, а не учетная запись. Таким образом, сотрудник сохранит возможность получения доступа к корпоративным ресурсам, правда только через альтернативное соединение или при локальной работе.

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

indeed-id 3/26/21 9:32 PM Page 23

www.itsec.ru

КОНТРОЛЬ ДОСТУПА

Реклама

В таком случае хранение ключевой информации будет осуществляться в следующих контейнерах: l на серверной стороне, все операции с ключами выполняются на сервере; l контейнер в специализированном модуле внутри устройства – Trusted Platform Module. Использование подобных решений считается менее безопасным, чем съемные аппаратные защищенные носители, однако эти решения наиболее гибкие и подходят для описанной нештатной ситуации. После замены ключевого носителя виртуальную смарт-карту можно отключить. Таким образом, даже в случае утери или поломки ключевого носителя простоя в бизнес-процессах компании не будет.

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

ствии данных о последовательности действий, которые привели к сбою. Однако при использовании решений класса Privileged Access Management (PAM) все подключения привилегированных пользователей к критичным ресурсам фиксируются в различных форматах (видео- и текстовая запись, снимки экрана, нажатия клавиш, переданные файлы). Далее, используя записи действий, всегда можно оперативно определить, какая последовательность действий привела к сбою, выявить ответственного за инцидент и определить фактор преднамеренности.

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

Для нейтрализации данной угрозы рекомендуется совместно с решением PAM использовать решения для 2FA сотрудников. Тогда, если сотрудник действительно является инсайдером и имел место инцидент, ему будет тяжело уйти от ответственности. Если все-таки сотрудник заявит, что у него украли телефон, на котором стоит генератор одноразовых паролей, ему будет задан логичный вопрос: "Почему вы оперативно не уведомили об этом службу безопасности?"

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

is@groteck.ru

• 23

Infographics 3/26/21 9:32 PM Page 24

Infographics 3/26/21 9:32 PM Page 25

Подписка на журнал

Vetkol 3/26/21 9:33 PM Page 26

ТЕХНОЛОГИИ

Классификация данных как фундамент ИБ Александр Ветколь, ведущий системный инженер Varonis Systems

Б

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

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

Насколько все плохо? По данным нашего исследования1, сотруднику в среднем доступны миллионы корпоративных файлов. Точное значение показателя зависит от размера и специфики бизнеса, но порядок именно таков, а в ряде случаев речь идет даже о десятках миллионов документов. Примерно 20% сетевых папок доступны для всех пользователей, при этом около 39% организаций имеют более 10 тыс. устаревших, но еще активных учетных записей. Неудивительно, что в подобной ситуации у двух третей компаний более 1 тыс. конфиденциальных файлов открыто для каждого сотрудника, а у 60% респондентов обнаружилось не менее 500 паролей, срок действия которых никогда не истекает. Парольная политика не имеет прямого отношения к классификации данных, но она тоже иллюстрирует сложившийся бардак. И чем крупнее организация, тем его больше. Кроме файловых ресурсов домена Active Directory, в корпоративной инфраструктуре есть разнообразные информационные системы со своими базами данных. Настройка безопасного доступа к этим системам – отдельная головная боль. Компании покупают антивирусы, межсетевые экраны нового поколения, решения для поведенческого анализа и управления мобильными устройствами, а также другие дорогостоящие продукты для защиты информации. Прежде чем настраивать доступ, необходимо упорядочить хаос: хотя классификация данных сама по себе проблему не решит, она 1

является основой любой эффективной системы обеспечения информационной безопасности.

Как решить проблему малой кровью? Самый очевидный способ классифицировать данные – провести ручной аудит силами ИТ-департамента. Такой подход прекрасно работает в небольших фирмах с десятками пользователей. В средних и крупных компаниях переложить проблему на хрупкие плечи сисадминов не получится: слишком много цифровой информации нажито непосильным трудом, а ее структура слишком сложна и разнообразна. К тому же это не разовая работа, после первоначального наведения порядка возникнет задача актуализации сведений и мониторинга изменений. Пользователи не любят соблюдать правила и будут постоянно "подсыпать в топку свежего уголька", да и конфигурация ресурсов в ИТ-инфраструктуре периодически меняется. За всем нужно следить: увы, грамотная классификация данных – это непрерывный процесс, а не законченный объект. Как, впрочем, и все, связанное с информационной безопасностью.

Чем поможет автоматизация? На этом этапе мы приходим к необходимости внедрения специализированных решений, позволяющих не только провести разовый аудит, но и отслеживающих все изменения в реальном времени. В них используются разные методы: морфологический анализ, проставление специальных меток (O365/M365, Boldon James, TITUS) и тому подобные вещи – выбор набора технологий зависит от разработчика. Система классификации с определенной периодичностью отслеживает изменения в документах, где бы те ни находились, разбирает по полочкам логику их построения и анализирует данные с использованием заданных правил. Частота проверок сетевых ресурсов настраивается в зависимости от многих факторов, но стратегия подбирается таким образом, чтобы получать информацию об изменениях максимально оперативно.

https://info.varonis.com/hubfs/Whitepapers%20(RU)/Varonis_Financial_Data_Risk_ Report%20(RU)_2021.pdf

26 •

Система классификации должна также взаимодействовать с другими информационными системами и облачными сервисами. В частности, большинство систем ЭДО и ERP хранят информацию в обычных файлах с определенной структурой и логикой размещения – они могут быть без особого труда проанализированы. В каких-то случаях требуется и прямой доступ – вариантов масса. Необходима также интеграция со средствами обеспечения информационной безопасности и контроля доступа, поскольку одной только классификации недостаточно, ее еще нужно правильно применить, допустив к определенной категории информации только пользователей, которым та необходима для работы. Настроив взаимодействие с DLP, можно передавать туда критичные документы для снятия цифровых отпечатков и контроля прохождения похожих на внешнем периметре. Есть и другие примеры взаимодействия; важно понимать, что эффективно лишь продуманное применение всех мер в комплексе.

Как запустить процесс? Внедрить подобную систему – титанический труд, а без предварительного планирования проект будет обречен на провал. Начинать, как ни странно, стоит с контроля за доступом к самим данным. Всегда возможно, что при первичной классификации данные не будут маркированы как критичные, но, если, скажем, поведенческий анализ увидит подготовку к их "выносу", действия пользователя можно будет поставить на контроль, а классификацию изменить. Даже в крупной организации может не оказаться необходимых ресурсов, чтобы пройти все шаги по внедрению автоматизированной классификации данных и настройке ее интеграции с прочими системами самостоятельно. Хорошим выбором будет обращение к специализирующемуся на информационной безопасности системному интегратору или (в зависимости от масштабов бизнеса заказчика) напрямую к разработчику продукта. В итоге вы узнаете о своих данных главное: где они лежат и в какой защите нуждаются. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Okbsapr1 3/26/21 9:33 PM Page 27

www.itsec.ru

КОНТРОЛЬ ДОСТУПА

Борьба с зараженными флешками в организации Светлана Конявская, заместитель генерального директора ОКБ САПР

К

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

Разрешенные флешки либо запрещалось уносить с работы, либо разрешалось подключать только после "обработки в санитарной зоне", что подразумевало проверку на вирусы на специальном рабочем месте. Очевидно, что для того, чтобы не бороться с зараженными флешками в организации, надо их в организацию не пускать. Казалось бы, именно на это и направлена описанная логика защиты. Нельзя сказать, что эти усилия совершенно ничего не давали. Однако, как и в целом в борьбе с вирусами в органических и компьютерных системах, успехи тут были весьма переменные (каждый понедельник – новый букет вирусов), а ресурсы затрачивались существенные. Около 10 лет назад мы предложили радикальный подход: не пытаться препятствовать выносу флешек за пределы контролируемой зоны, но сделать невозможным их применение на каких-либо компьютерах, кроме явно разрешенных. Невозможным совсем, даже для легального пользователя, даже для операционной системы компьютера. Это принципиально, ведь от того, легален ли пользователь, никак не зависит, есть ли на компьютере вирусы. Если они там есть, то как только ОС получает доступ к флешке, к ней получают доступ и вирусы. Бесполезным для защиты от заражения является и шифрование данных на флешке. Вирусу все равно, читаемы ли данные на диске, он способен записаться и рядом с нечитаемыми, главное, чтобы у ОС был доступ к диску. Акцент в нашем решении был смещен на то, чтобы ОС получала доступ к диску только в том случае, если сам USB-накопитель определил, что на данном компьютере разрешено это сделать. Такой USB-накопитель уже не совсем "флешка", мы его называем "служебный носитель". Получение доступа к диску со стороны ОС называется монтированием диска. Оно осуществляется ОС автоматически1, если при обращении к подключенному устройству считывается атрибут "диск". Значит, чтобы ОС не получила доступа к диску на неразрешенном компьютере,

USB-накопитель должен признаваться в том, что он диск, только после успешного проведения процедур проверки компьютера на наличие в списке разрешенных. Для этого необходимы два условия: 1. Список разрешенных компьютеров находится не на том же диске, доступ к которому ограничиваем.

2. Проверка на наличие компьютера в списке производится не средствами операционной системы, доступ которой к диску ограничиваем. Это значит, что у USB-накопителя должен быть собственный аппаратно реализованный блок аутентификации, который отработает до того, как ОС смонтирует диск. То есть до успешного завершения процедур (и в случае их неуспешного завершения) USB-накопитель должен представляться системе иначе, не давая ей смонтировать диск. Легко понять, что ни необходимость наличия на компьютере какой-либо интерфейсной программы, ни требование наличия какого-либо выработанного тем или иным образом "кода доступа" не может обеспечить защищенность флешки от заражения без выполнения вышеперечисленных условий. И поэтому, хотя общая идея (менять флешки так, чтобы они не были доступны вне системы, а не ставить ПО на подконтрольные компьютеры) воспринята и эксплуатирующими организациями, и другими вендорами средств защиты информации, мы вынуждены констатировать, что все известные нам варианты реализации этой идеи, кроме семейства защищенных USB-накопителей "Секрет", основываются скорее на психологических, чем на технических приемах. Напомним в двух словах особенности "Секретов" на примере наиболее популярного продукта "Секрет Особого Назначения". Блок аутентификации "Секрета" проверяет компьютер на предмет совпадения с имеющимися в списке разрешенных по пяти параметрам (номер материнской платы, ID ОС, домен и т.д. (все это можно посмотреть на сайте2)). До успешного прохождения аутентификации компьютера диск не монтируется и недоступен для ОС, а значит и для вирусов.

Выглядит это для ОС (и для пользователя, если он полюбопытствует, что происходит) как кард-ридер без установленного в него диска. Если нажать на букву диска, увидим:

В диспетчере устройств увидим:

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

NM

Реклама

1

В Windows – всегда, в Linux, в общем-то, тоже всегда, но есть и команда для произвольного монтирования, “вручную", однако на текущее рассуждение это никак не влияет.

2 https://www.okbsapr.ru/products/storage/flash/secret/special/

АДРЕСА И ТЕЛЕФОНЫ ОКБ САПР см. стр. 48

• 27

niisokb 3/26/21 9:33 PM Page 28

ТЕХНОЛОГИИ

Безопасность дистанционной работы: прогнозы и рекомендации

Р

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

Взгляд Gartner на ближайшую перспективу Уже более 20 лет Gartner дает оценку перспектив развивающихся информационных технологий в форме так называемых циклов хайпа. В цикле хайпа каждая технология в зависимости от своей зрелости и востребованности относится к одному из следующих этапов: 1. Инновация (Innovation Trigger) – новые технологии, о которых появились первые публикации.

2. Пик чрезмерных ожиданий (Peak of Inflated Expectation) – технология наиболее популярна, ее недостатки еще мало изучены или игнорируются.

3. Избавление от иллюзий (Trough of Disillusionment) – практика выявляет недостатки технологии, которые приводят к снижению ее популярности.

4. Преодоление недостатков (Slope of Enlightenment) – устраняются основные недостатки, интерес к технологии постепенно возвращается.

5. Плато продуктивности (Plateau of Productivity) – зрелость технологии. Технология принимается как данность, ее достоинства и ограничения всем понятны и известны. Прогноз Gartner цикла хайпа информационных технологий защиты удаленных рабочих мест (Endpoint Protection) основан на следующих основных постулатах: 1. Удаленная работа в большинстве компаний меньше чем за год перестала быть привилегией. Теперь удаленная работа – это если и не необходимость, то, по крайней мере, одна из доступных форм постоянной или частичной занятости. С точки зрения безопасности это означает, что периметр безопасности компании уже не будет ограничен пределами ее офиса. К данным компании могут получать доступ из дома, кафе и общественного транспорта, и во всех таких ситуациях необходима надежная защита этих данных.

1 2 3

Рис. 1. Отчет Gartner ID: G00450232 2. Главный вызов корпоративной безопасности – это использование личных смартфонов, планшетов и ноутбуков. В спешке компании допускали подключение личных устройств без установки на них необходимых средств защиты.

3. В политике ИБ большинства компаний стал применятся подход "нулевого доверия" (Zero Trust), при котором конечные устройства пользователей никогда не считаются доверенными. Если сотрудник принес корпоративный ноутбук домой или подключился к рабочей почте с личного смартфона, нельзя исключать наличие на устройстве зловредного программного обеспечения или отсутствие шифрования канала связи.

4. Набирают популярность облачные технологии обеспечения ИБ. Основное преимущество облаков – скорость доступности изменений. За обновление облачных сервисов отвечает их поставщик, а не компания-потребитель. Gartner ожидает, что к 2024 г. облачные технологии ИБ будут преобладать в 40% компаний.

5. Разнообразие клиентских устройств формирует потребность в универсальном подходе к управлению и обеспечению безопасности. Удовлетворить эту потребность могут технологии унифицированного управления (UEM1) и защиты (UES2) клиентских устройств, а также технология защиты от мобильных угроз (MTD3). На рынке появляются комплексные продукты, сочетающие в себе функции всех этих технологий. На рис. 1 точками обозначены различные технологии. Цвет точки означает прогноз срока достижения плато продуктивности: l белый – плато будет достигнуто меньше чем за два года; l голубой – до плато осталось от двух до пяти лет; l синий – достижение плато ожидается в течение 5–10 лет; l красный – технология не достигнет плато. Большинство общемировых трендов актуальны в России, но есть и национальные особенности.

UEM – Unified Endpoint Management, унифицированное управление клиентскими устройствами.

UES – Unified Endpoint Security, унифицированная защита клиентских устройств.

MTD – Mobile Threat Defense, защита от мобильных угроз.

28 •

niisokb 3/26/21 9:33 PM Page 29

www.itsec.ru

КОНТРОЛЬ ДОСТУПА

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

Практические советы по защите мобильных рабочих мест Когда речь идет о корпоративных устройствах на базе Windows, то обычно они получают политики безопасности и необходимое программное обеспечение из корпоративного домена и других доверенных источников. Если же устройства перемещаются из офиса домой, то перед тем как давать им доступ к корпоративным ресурсам, следует осуществить проверку и убедиться, что на устройствах активен антивирус, его база актуальна, операционная система своевременно обновлена и т.д. Эту задачу успешно решают системы UEM. Еще одна типовая задача для UEM на Windows – это распространение политик безопасности и приложений на личные устройства, которые не подключены к корпоративному домену. Объективно у пользователя есть всего два варианта подключения к корпоративной инфраструктуре с личного устройства: l первый – принять те ограничения, которые предлагает работодатель; l второй – использовать аппаратный тонкий клиент с собственной операционной системой, исключающий личное использование устройства во время доступа к корпоративным данным. Ноутбуки и персональные компьютеры бывают не только на Windows. Многие руководители и айтишники предпочитают технику Apple, которую корректно подключить к Windows-домену сможет не каждый администратор. В этом случае также помогут UEM системы. Все устройства Apple, начиная с ноутбуков и заканчивая часами и ТВ-приставками, управляются с помощью единого протокола. Это не только упрощает их эксплуатацию, но и означает, что унификация безопасности различных устройств Apple заложена by design. iPhone, iPad, iMac и MacBook примут одни и те же политики безопасности и будут их применять одинаково. Защита смартфонов и планшетов имеет свою специфику. В мобильных операционных системах (ОС) не бывает внеш-

Доверенная платформа управления со встроенной библиотекой Kaspersky Mobile Security SDK

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

SafePhone MTD Edition – единственное решение, сертифицированное одновременно как средство защиты информации на мобильных устройствах от несанкционированного доступа и как средство антивирусной защиты. Сертификат ФСТЭК № 4157 от 03.09.2020

них средств доверенной загрузки, аппаратных тонких клиентов или токенов для аутентификации. В них нельзя установить приложение-криптопровайдер, которое позволит встроенному почтовому клиенту и браузеру шифровать данные отечественной криптографией. Возможен ли в этом случае удаленный доступ в соответствии с требованиями регуляторов? Да, возможен, при условии установки на мобильные рабочие места базового набора средств защиты – VPN, антивируса, UEM. VPN-решение защищает канал передачи данных между мобильным устройством и корпоративной инфраструктурой. При наличии VPN нет необходимости заниматься защитой канала передачи данных в каждом из приложений, которые получают доступ к данным вашей компании, – браузере, почтовом клиенте и т.д. Антивирус нужен для проверки файлов и приложений на мобильном устройстве. Вредоносные файлы не могут нанести мобильным ОС большой ущерб, потому что каждое приложение в этих ОС работает в изолированной "песочнице". Поэтому если malware пробрался, скажем, в браузер, он не сможет получить из него доступ к данным почты. Но мобильное устройство без антивируса может стать каналом передачи malware в инфраструктуру компании, поэтому антивирус нужен.

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

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

3. Централизованно устанавливать, обновлять и настраивать мобильные приложения. С точки зрения ИБ UEM является средством доверенного распространения ПО, а с точки зрения ИТ – профилактикой головной боли от наличия неактуальных версий приложений и необходимости напоминать пользователям их самостоятельно обновлять.

4. Регистрировать события безопасности. В первую очередь нужно оперативно регистрировать признаки программного взлома мобильных устройств (jailbreak, root). В этом случае необходимо отключить доступ мобильного устройства к корпоративной сети и удалить с него все корпоративные данные, потому что взлом устройства делает возможным несанкционированный доступ к данным внутри "песочниц" корпоративных приложений.

Выводы Всеобщая дистанционная работа, необходимость которой была вызвана пандемией в 2020 г., изменила представления о защите мобильных рабочих мест. Рабочие места отныне не всегда находятся только внутри доверенного периметра организации. Любое устройство может быть рабочим местом сотрудника, будь то смартфон, планшет, ноутбук или десктоп. Компании, которые пытаются это игнорировать, заведомо проигрывают своим конкурентам. Удаленный доступ с любого устройства из любого места требует перестройки процессов ИБ в компании. Необходимо учитывать тот факт, что пользователь работает в недоверенном окружении. Нужно обеспечить эффективную защиту удаленного доступа с мобильных устройств, применяя комплекс средств для защиты канала передачи данных (VPN) и защиты данных на мобильных устройствах от несанкционированного доступа, включая антивирусную защиту (UEM, MTD). l

NM

Реклама

4

BYOD – Bring Your Own Device, концепция использования личных устройств для работы.

5 BYOPC – Bring Your Own PC, концепция использования личных ПК для работы.

АДРЕСА И ТЕЛЕФОНЫ НИИ СОКБ см. стр. 48

• 29

Estehin 3/26/21 9:33 PM Page 30

УПРАВЛЕНИЕ

Business Information Security Officer – востребованный герой нашего времени Валерий Естехин, эксперт по вопросам информационной безопасности, автор блога estekhin.blogspot.ru

О Как ИБ стать стратегическим партнером бизнесу? Для некоторых крупных компаний уже недостаточно директора по информационным технологиям (CIO) и директора по информационной безопасности (CISO). Нужен тот, кто умеет "продавать" топменеджменту идеальную модель безопасной компании, а именно деловой директор по информационной безопасности – Business Information Security Officer (BISO). Он должен объединить стратегию кибербезопасности с бизнес-целями компании. Для этого BISO необходимо не только обладать высокой осведомленностью в ключевых технологических тенденциях ИТ и ИБ, но и разбираться в бизнес-процессах компании. Основные задачи BISO: l понимать реальную экономику бизнеса; l способствовать включению информационной безопасности во внутреннюю культуру бизнеса; l переводить технические вопросы ИТ и ИБ в русло бизнес-требований; l четко и эффективно общаться как с технологическими, так и с деловыми партнерами, выступая в качестве контактного лица – советника по вопросам ИБ;

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

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

Что же такого может BISO в отличие от CISO? BISO отводится роль связующего звена между топ-менеджментом, бизнес-подразделениями, ИТ-службой и службой информационной безопасности (ИБ). BISO может помочь бизнесу в достижении целей, представляя эффективную стратегию безопасности, дорожную карту работ и проектов по ИБ на будущее.

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

30 •

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

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

Многоотраслевой "спец на час" Во-вторых, для BISO существует риск стать директором-популяризатором ("директором на час") ключевых задач бизнеса, связанных с кибербезопасностью компании. Такой BISO будет без конца штамповать блестящие презентации в PowerPoint с манящими заголовками: "Зачем нужна ИБ и какой она должна быть?"; "Что от ИБ ждет бизнес?"; "Как реально защитить организацию и ее активы от киберпреступников, сотрудников и промышленного шпионажа?"; "Какие средства защиты и проекты по ИБ реально нужны и почему?"; "Как не "перекрутить гайки" с безопасностью?"; "Чем грозят бизнесу токсичные законодательные инициативы регуляторов?" и т.д. Но все то, что он способен привнести в компанию на своем "юношеском задоре", по причине того же "юношеского задора" по желанию руководства может в одночасье рухнуть.

Estehin 3/26/21 9:33 PM Page 31

www.itsec.ru

УПРАВЛЕНИЕ

Поэтому такие BISO-популяризаторы долго в компаниях не задерживаются. Но риск быть непонятым не особенно беспокоит этот тип BISO, ведь всегда можно найти себе применение в другой компании, которой требуется "опытный и харизматичный" человек на эту должность.

Осознание внутренней противоречивости роли BISO Приходя в новую компанию, BISO, как правило, находит повсюду факторы риска и недостатки в инфраструктуре, в ИТ-архитектуре, в кадровом, финансовом, юридическом обеспечении персонала компании, о чем немедленно докладывает руководству. И это может насторожить бизнес. С одной стороны, по мнению руководства, BISO должен демонстрировать свое понимание бережливого бизнеса, стратегии, возможностей роста, культуры, финансового управления затратами. С другой стороны, реальность такова, что без параноидального стремления к безопасности компанию рано или поздно взломают. В настоящий момент мы наблюдаем революцию в области коммуникаций и удаленной работы, а фокус деятельности у многих компаний сместился в онлайн. Можно также с уверенностью сказать, что у каждого онлайнсервиса существуют риски в процессах, влияющие на ценность услуги на разных стадиях жизненного цикла. Условия деятельности компании, влияющие на безопасность: l практически каждый сервис можно монетизировать (монетизации активов в результате действий внутренних и внешних злоумышленников либо в результате кибератак); l ошибки в стратегии защиты онлайнсервисов обойдутся компании слишком дорого (атаки вирусов-шифровальщиков); l обеспечение непрерывности бизнеса – задача всех основных и обслуживающих подразделений компании (убытки, понесенные в результате простоя ИТ-систем, не могут быть ниже, чем убытки, нанесенные прерыванием бизнес-процессов, которые эти ИТ-системы обеспечивают); l все возможные коммуникационные каналы и онлайн-сервисы компании могут подвергаться атакам злоумышленников.

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

Комментарий эксперта Современный бизнес ждет от руководителя подразделения информационной безопасности (CISO) умения выстраивать процессы информационной безопасности и управлять техническими специалистами, а также способности продавать функционал ИБ другим структурным подразделениям компании, а иногда и контрагентам. Однако ввиду того, что традиционно на должность CISO рассматриваются профессионалы, имеющие прежде всего технический бэкграунд, инженерные компетенции и техническое образование (что находит свое отражение в том числе и в требованиях регуляторов), возникает потребность в новой роли, Business Information Security Officer (BISO). Константин В целом практика включения роли BISO в мире не нова, Саматов, но следует отметить, что BISO в подавляющем большинстве член Правления случаев – это не директор и не руководитель самостояАРСИБ тельного подразделения, что, в общем-то, и следует из содержания самой аббревиатуры, BISO – это Officer, а не (Ассоциация Chief и не Head. Поэтому наиболее эффективно, на мой руководителей взгляд, рассматривать BISO как советника, консультанта служб по вопросам ИБ или менеджера по ИБ, как это и бывает во информационной многих международных компаниях. безопасности) С практической точки зрения я бы рекомендовал рассматривать на роль BISO профессионала с хорошим управленческим бэкграундом и управленческим образованием (возможно, степенью МВА) на позиции заместителя или советника для CISO, имеющего хороший технический бэкграунд. Именно на этой должности BISO и сможет эффективно выполнять роль связующего звена, про которое говорит автор статьи. Кроме того, в этом случае BISO и CISO будут хорошо дополнять друг друга, компенсируя свои слабые стороны и используя сильные, что решит многие вопросы, обозначенные автором статьи. l

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

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

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

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

is@groteck.ru

• 31

Rysin 3/26/21 9:33 PM Page 32

УПРАВЛЕНИЕ

От хорошего к великому через хаос Сергей Рысин, главный специалист по технической защите информации компании HeadHunter

15–17 32 •

2022

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

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

is@groteck.ru

Реклама

Подходит к концу I квартал 2021 года и я рад вас приветствовать в технической рубрике журнала "Информационная безопасность"! Хочу поздравить всех нас с новым опытом и навыками, приобретенными под влиянием пандемии коронавируса. Ну что же, поехали! Быстрая адаптация к новым реалиям дала части компаний возможность нарастить долю на рынке, проверить свою надежность, ну а кто-то остался

"за бортом" из-за наступившей турбулентности в условиях новой пандемической реальности. В этом смысле интересен взгляд на проблему эксперта компании McAfee, специалиста из другой корпоративной реальности, другой информационной культуры. Любопытно, что его выводы во многом созвучны мыслям российских экспертов, а основные задачи, решаемые в западных странах, практически повторяют наши – дать возможность удаленным сотрудникам работать в домашних условиях, но под защитой корпоративных систем ИБ. Особо отмечу рассмотрение в этом номере журнала любопытнейшего вопроса о новой роли BISO. Это крайне важный элемент совершенствования взглядов на управление корпоративной информационной безопасностью. Важно осознать, почему BISO востребован именно сейчас, что конкретно эта роль может дать бизнес-подразделениям и как позволит поддержать динамику развития компании, сохраняя ее информационную защищенность.

Dushkevich 3/26/21 9:33 PM Page 33

www.itsec.ru

УПРАВЛЕНИЕ

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

Э

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

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

Анализ проблемы Важная задача при построении системы защиты информации – контроль каналов передачи информации, которые используются сотрудниками в рамках своей профессиональной деятельности. Электронная почта как один из главных каналов обладает важными для потенциального злоумышленника особенностями: l как правило, получатель письма открывает его на своем рабочем месте, которое довольно часто располагается внутри сети предприятия. С наступлением пандемии ситуация несколько изменилась, но все же не кардинально; l через этот канал часто поступает важная информация от коллег, начальства, партнеров, поэтому доверие к нему со стороны пользователей велико; l многие ключевые почтовые адреса в компаниях имеют одинаковые имена: order, zakupki, kassa, secretar и т.п., что позволяет проводить атаки с использованием массовых рассылок, подставляя только доменные имена в почтовый адрес. Согласно Mitre ATT&CK, у фишинговых атак имеется три техники реализации: 1 2 3

1. Spearphishing Attachment (T1566.001). В рамках этой техники атаки злоумышленники распространяют вложение в различных форматах, при запуске которого происходит активация вредоносного ПО, в том числе с использованием уязвимостей.

2. Spearphishing Link (T1566.002). В рамках этой техники в почтовое сообщение встраивается ссылка, при переходе по которой выполняется действие, выгодное злоумышленнику: запуск и загрузка ПО, переход на заранее подготовленный для фишинга ресурс и т.п.

3. Spearphishing via Service (T1566.003). В рамках этой техники используются сервисы, не контролируемые корпоративной политикой безопасности, например LinkedIn, Whatsapp, личная почта и т.п. Кстати, фишинг также используется в техниках так называемого бокового перемещения (Lateral Movement), что отмечено в Mitre ATT&CK под термином Internal Phishing2. Этот прием заключается в том, что злоумышленники могут использовать фишинг для распространения "полезной нагрузки" внутри организации, например при помощи рассылки с скомпрометированного почтового адреса.

Меры повышения уровня безопасности Если говорить о технических мерах защиты от фишинга, то в рамках Mitre ATT&CK выделяют следующие меры борьбы с целевым фишингом:

l Antivirus/Antimalware: антивирусные решения могут заблокировать вредоносные вложения; l Network Intrusion Prevention: система предотвращения вторжений также может предотвратить передачу вложения или ссылки, заблокировав данные; l Restrict Web-Based Content: можно заблокировать доступ к контенту или отдельный файл –.exe, .scr, .pif, .cpl и т. п. в том случае, если этого требует политика безопасности; l User Training: пользователей надо обучать тому, как распознать те или иные техники фишинга. Есть большое количество факторов, которые нужно учитывать при планировании мер по защите электронной почты: 1. Выше уже говорилось, что e-mail – один из основных каналов взаимодействия для компаний. Это означает, что требуется построить защиту таким образом, чтобы она не повлияла на работу организации, то есть нормальная "белая" почта не должна блокироваться без веских оснований.

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

3. Использование антивирусных систем зависит от многих факторов и особенностей ИТ-инфраструктуры на предприятии. Но это важный инструмент защиты.

4. Чем меньше злоумышленники знают о конкретной цели, тем лучше. То есть нужно

E-mail – один из основных каналов взаимодействия для компаний. Это означает, что требуется построить защиту таким образом, чтобы она не повлияла на работу организации, то есть нормальная "белая" почта не должна блокироваться без веских оснований.

https://www.hybrid-analysis.com/sample/5daf2d7810dd11918744b2d357a35015ef491fdd5c0365d4b83efdb6404a0bb8 https://www.virustotal.com/gui/file/5daf2d7810dd11918744b2d357a35015ef491fdd5c0365d4b83efdb6404a0bb8/detection https://bazaar.abuse.ch/sample/5daf2d7810dd11918744b2d357a35015ef491fdd5c0365d4b83efdb6404a0bb8

• 33

Dushkevich 3/26/21 9:33 PM Page 34

УПРАВЛЕНИЕ отсечь утечку персональных данных сотрудников, иначе киберпреступникам будет проще найти к потенциальной жертве подход.

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

Основные этапы стратегии борьбы со спамом

Начальные условия

Нужно отсечь утечку персональных данных сотрудников, иначе киберпреступникам будет проще найти к потенциальной жертве подход.

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

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

Главный момент: корпоративная почта должна использоваться лишь для делового общения. Личное общение, какие-либо персональные рассылки, не имеющие отношения к компании, допускать нельзя. Это звучит несколько жестко, но иначе просто нельзя: все сообщения, которые не относятся к делам компании, должны отправляться в спам. В основе стратегии защиты лежат следующие действия: 1. Отсекаем общий спам на сервере. Если письмо вдруг проходит через спам-фильтр, то далее придется его анализировать самостоятельно.

2. Отсекаем целевой фишинг. Самое важное – это научить сотрудников распознавать подозрительные почтовые сообщения, которые они могут получить в рамках своей деятельности, поэтому все сообщения проверяются беглым осмотром письма на наличие в них некоторых аномалий. Если аномалии выявлены, необходимо отправить письмо на проверку специалисту по информационной безопасности. Такой проверки требуют целевые атаки: письмо в большинстве случаев составлено так, чтобы обойти все фильтры и защитные механизмы на сервере. Главная задача – не только провести такой анализ, но и скорректировать СЗИ, чтобы не допустить подобных атак в

Рис. 1. Практический пример

34 •

Предположим, что подозрительное письмо успешно прошло через спам-фильтр и антивирусные проверки на почтовом сервере. Как правило, в таких письмах довольно сложно проверить отправителя. Что это означает? Поиск аномалий в подобных сообщениях бывает затруднен, если не анализировать заголовки письма. Но у таких атак есть общие черты, по которым их и можно распознать: 1. Побуждающее действие. Злоумышленников интересует действие, которое может выполнить потенциальная жертва, например открытие и запуск вложения, переход по ссылке, целевой фишинг через сервис.

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

териев хотя бы на два балла, оно получает статус подозрительного. Вот примеры критериев, по которым мы проверяем каждое письмо: l письмо не связано или, в лучшем случае, связано косвенно с профессиональной деятельностью получателя; l искаженно имя известного домена, замена букв на визуально похожие, например shartres вместо shartrez; l длинное имя отправителя в адресе отправителя, например sometext.manager.somedata@до мен; l длинное имя домена в адресе отправителя, например cnaantours.co.il; l странные суффиксы домена в адресе отправителя, например .xyz,.it,.abc и т.д. Ключевым признаком атаки является наличие в письме некоего объекта – файла или ссылки, действие с которым надо обязательно выполнить, поэтому далее пользователю необходимо проверить письмо на наличие подозрительных объектов. Примеры: l проверить, есть ли в письме ссылки, по которым надо обязательно перейти;. l проверить, есть ли в письме вложения; l проверить, есть ли в письме подпись с данными владельца и совпадает ли подпись в письме с доменом отправителя. Затем следует проверить, что хочет отправитель. Как и говорилось выше, киберпреступнику нужно заставить пользователя выполнить какое-то действие. Это достигается при помощи таких методов: 1. Отправитель письма апеллирует к страху перед возможной ответственностью или играет на жадности, корысти, получении материальных или иных благ.

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

3. Отправитель письма шантажирует или угрожает компрометацией персональной информации – фотографий, переписки и т.п., если пользователь не выполнит указанные в письме действия.

4. Отправитель письма пытается апеллировать к чувствам пользователя, например жалости, чтобы тот перешел по ссылке.

Dushkevich 3/26/21 9:33 PM Page 35

www.itsec.ru

УПРАВЛЕНИЕ

Разумеется, признаков может быть и больше, но главное мы перечислили. Что дальше? Если пользователь посчитает письмо подозрительным, то нужно действовать по алгоритму. В первую очередь – сохранить исходный текст письма вместе со всеми заголовками в файл txt или eml и переслать полученный файл в архивированном виде ответственному за защиту информации на специальный адрес. Кроме того: l не сохранять и не открывать вложения до проведения исследования письма ответственным за защиту информации; l не отвечать на письмо и не выполнять никаких действий до проведения исследования письма ответственным за защиту информации. Далее ответственный за защиту информации проводит исследование письма. Для этого необходимо запросить у пользователя исходный код письма в формате eml или txt, предварительно упакованный в архив с паролем infected. Затем специалист анализирует сообщение в отдельной виртуальной машине, изолированной от основной сети. Мы проводим анализ в дистрибутиве Kali Linux, с целью исключения возможности запуска вредоносного ПО формата exe. Порядок следующий: l проводится анализ заголовков письма и значения заголовков; l проводится анализ вложений или ссылок. Примерный алгоритм представлен на схеме ниже (см. рис. 1). Не так давно нам пришло письмо примерно такого содержания (см. рис. 2). Можно увидеть, что данное письмо является подозрительным для пользователя, поэтому требует дополнительного анализа. В заголовках письма были найдены следующие аномалии: 1. Несовпадение параметров доменных имен в заголовках From и Received. Также домен fair-express.com не ресолвится в адрес 5.253.18.225.

Received: from fairexpress.com (unknown [5.253.18.225]) by server.uthink.eu (Postfix) with ESMTPA id 80EFC131468B83 for <order@shartrez.com>; Mon, 26 Oct 2020 09:20:10 +0000 (GMT)

From: "Steve Foreman"<sforeman@fairexpress.com>

2. Согласно анализу заголовков Received, письмо прошло через два промежуточных узла, которые никак не связаны с доменом fair-express.com:

Received: from server1.uthink.eu ([87.76.27.126]:46460 helo=server.uthink.eu) by cpanel12.d.fozzy.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_1 28_GCM_SHA256 (Exim 4.93) (envelope-from <sforeman@fairexpress.com>) id 1kWzdI-000RWd-5b for order@shartrez.com; Mon, 26 Oct 2020 13:21:51 +0300 Received: from fairexpress.com (unknown [5.253.18.225]) by server.uthink.eu (Postfix) with

ESMTPA id 80EFC131468B83 for <order@shartrez.com>; Mon, 26 Oct 2020 09:20:10 +0000 (GMT) From: "Steve Foreman"<sforeman@fair-express.com>

Дальнейшее исследование предполагает анализ вложения. Тип файла после распаковки архива – exe (см. рис. 3).

Рис. 2 рые из AS209623 довольно часто встречаются при использовании вредоносного ПО, если верить поиску по сайту https://bazaar.abuse.ch/. По результатам проведения анализа мы скорректировали защиту с учетом возможных атак с указанных IP-адресов, письмо было помечено как спам, а настройки антиспамфильтра были скорректированы для недопущения подобных атак в дальнейшем.

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

Мы проводим анализ в дистрибутиве Kali Linux, с целью исключения возможности запуска вредоносного ПО формата exe.

Рис. 3.

C результатами динамического анализа можно ознакомиться по ссылкам в конце статьи, в итоге получается следующая картина: 1. Файл-вложение представляет собой троян (семейство Remcos), написанный на C#. Детектируется большим числом антивирусов, на момент анализа их было меньше. Распространяется под разными именами.

2. Троян взаимодействует с доменным именем uzbektourism8739.ddns.net и IP-адресом 185.140.53.129, причем указанный IP-адрес и еще некото-

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

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

• 35

Kondrashin 3/26/21 9:33 PM Page 36

ТЕХНОЛОГИИ

Риски кибербезопасности для подключенных автомобилей Михаил Кондрашин, технический директор компании Trend Micro в России и СНГ

Н

Даже самые простые автомобили сегодня имеют по крайней мере 30 электронных блоков управления на базе микропроцессоров.

аиболее компьютеризированные модели автомобилей содержат до 150 электронных блоков управления (ЭБУ) и около 100 млн строк программного кода. Это в четыре раза больше, чем у современных моделей истребителей, причем, по прогнозам, к 2030 г. количество строк кода может превысить 300 млн. Вместе с этим растут и риски кибербезопасности, поскольку хакеры стремятся получить доступ к электронным системам, их данным и монетизировать его, угрожая безопасности транспортных средств и неприкосновенности частной жизни потребителей. Чтобы оценить эти риски, исследователи Trend Micro изучили уже осуществленные попытки атак1 и предложили варианты защиты.

Основное внимание исследователи уделили атакам, проведенным удаленно, в результате которых был взломан как минимум один ЭБУ в автомобиле. В качестве базы были использованы четыре хорошо изученных случая.

1. Взлом автомобиля Jeep американского производителя Chrysler в 2015 г.: злоумышленники обнаружили легкий способ отправлять команды на автомобили через незащищенный порт telnet, что привело к отзыву 1,4 млн машин.

2. В 2016 г. эксперты лаборатории Tencent Keen Security Lab нашли возможность вмешаться в работу компьютерной системы автомобиля Tesla Model S.

3. Исправление ошибок, обнаруженных в автомобилях марки Tesla в 2016 г., помогло лишь частично: в 2017 г. ситуация повторилась уже с двумя моделями Tesla – Model S и Model X. Производитель вновь исправил ошибки, обнаруженные сотрудниками Tencent Keen Security Lab. 4. В 2018 г. экспертам Tencent Keen Security Lab удалось успешно атаковать подключенные автомобили BMW.

Архитектура подключенных автомобилей Даже самые простые автомобили сегодня имеют по крайней мере 30 электронных блоков управления на базе мик-

Рис. 1. Внутренняя архитектура подключенных автомобилей. Источник: Trend Micro 1

ропроцессоров, в то время как автомобили класса люкс содержат более 100 ЭБУ. Все ЭБУ подключаются через лабиринт различных цифровых шин, например CAN (Control Area Network), Ethernet, FlexRay, LIN (Local Interconnect Network), MOST (Media Oriented Systems Transport). Шины работают с разной скоростью, передают различные типы данных и обеспечивают соединение между различными частями автомобиля. ЭБУ управляют критически важными функциями в автомобиле, включая силовой агрегат, управление системой связи, питанием, ходовой системой и безопасностью автомобиля. Доступ к некоторым из них можно получить удаленно через головное устройство. Большая часть новых моделей автомобилей имеет встроенные СИМ-карты. Они используются, в частности, для передачи телематических данных, для связи с облачной инфраструктурой автопроизводителя, для создания точек доступа Wi-Fi для водителя и пассажиров, а также для получения информации о дорожном движении в режиме реального времени. Мобильные приложения могут удаленно запускать, останавливать, запирать и разблокировать автомобиль, а также автоматически отправлять данные о текущем состоянии дороги в облако и передавать их другим транспортным сред-

https://www.trendmicro.com/vinfo/us/security/news/internet-of-things/the-cybersecurity-blind-spots-of-connected-cars/

36 •

Kondrashin 3/26/21 9:33 PM Page 37

www.itsec.ru

ТЕХНОЛОГИИ

ствам, чьи пользователи подписались на ту же услугу. В автомобилях часто имеются модули Bluetooth и Wi-Fi. Смартфоны пользователей подключаются по Bluetooth к головному устройству автомобиля для воспроизведения музыки, совершения телефонных звонков и доступа к адресным книгам. Некоторые автомобили могут подключаться к домашним Wi-Fi-сетям и загружать пакеты обновления программного обеспечения для автомобилей "по воздуху" (OTA). С введением популярных стандартов автомобильной телематики Apple CarPlay и Android Auto подключение мобильного телефона к автомобилю обеспечивает не только звонки и синхронизацию адресных книг, но и доступ к приложениям, картам, сообщениям и музыке.

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

модель SaaS, похожую на систему национальной обороны, но предназначенную для подключенных автомобилей и ITS-инфраструктур? Наиболее логичным кажется вариант ответственности автопроизводителей: производишь – будь добр обеспечить безопасность. Но реальность накладывает свои ограничения, одним из которых является совместимость. На сегодняшний день стандартизация даже обычных автокомпонентов далека от идеала. А уж когда речь заходит о совместимости ЭБУ разных производителей, становится совсем грустно. Учитывая то, какой объем средств вкладывается в разработку электронных компонентов, сложно заставить всех автопроизводителей привести их к единой стандартной программно-аппаратной базе, и особенно проблемным представляется процесс выработки этого стандарта. Но защита подключенных автомобилей от удаленных атак не ограничивается безопасностью средства передвижения. Необходимо также обеспечить защиту цепочки передачи данных, используемых во время движения, а именно: l безопасность серверной части инфраструктуры (бэкенда), обеспечивающей работу сервисов, необходимых для функционирования подключенных автомобилей; l безопасность сетевой инфраструктуры, отвечающей за взаимодействие подключенных автомобилей с бэкендом; l защиту центра обеспечения безопасности транспортных средств (VSOC), который обрабатывает и анализирует уведомления и данные первых трех компонентов. Именно поэтому участвовать в процессе обеспечения безопасности должны все участники цепочки поставок, каждый из которых будет вносить свой вклад в создание комплексных решений для защиты подключенной автомобильной экосистемы.

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

1. Сеть самого автомобиля, включая головную медиасистему, шлюзы и ЭБУ, а также сетевые модули.

2. Инфраструктура оператора мобильной сети.

3. Весь бэкэнд, включая программы, серверы и базы данных.

4. VSOC – служба обеспечения комплексной безопасности транспортных средств. Обеспечить защиту этих областей силами автопроизводителей помогут следующие технологические решения: l сетевая сегментация: помещение всех критических компонентов автомобиля в выделенную сеть, отделенную от развлекательно-пользовательской, снижает риск бокового перемещения и повышает общую безопасность; l брандмауэры для отслеживания трафика с неизвестных и ненадежных доменов, а также для идентификации приложений или устройств, которые генерируют или запрашивают вредоносный трафик; l брандмауэры нового поколения (NGFWs) или унифицированные шлюзы управления угрозами (UTM), которые могут включать в себя классические брандмауэры, системы предотвращения вторжений (IPS), системы обнаружения вторжений (IDS), антивирусное программное обеспечение, средства веб-фильтрации и управления приложениями и другие решения, объединенные в одном устройстве;

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

Учитывая то, какой объем средств вкладывается в разработку электронных компонентов, сложно заставить всех автопроизводителей привести их к единой стандартной программно-аппаратной базе.

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

Технические вопросы В отличие от обычных ИТсистем экосистема подключенных автомобилей намного более сложна и разнообразна, поэтому решения, отработанные в ИТ, применимы для авто-

Рис. 2. Внешняя инфраструктура подключенных автомобилей. Источник: Trend Micro

• 37

Kondrashin 3/26/21 9:33 PM Page 38

ТЕХНОЛОГИИ

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

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

l антивирусное программное обеспечение для бэкенда и компьютеров в составе VSOC; l антифишинговое ПО для фильтрации электронной почты сотрудников мобильного оператора, бэкенд-систем и VSOC; l системы обнаружения взлома (BDS); l IPS и IDS – системы сетевой безопасности, которые исследуют трафик для обнаружения и предотвращения сетевых атак; l обязательное повсеместное шифрование передаваемых данных; l оперативное управление исправлениями и обновлениями; l SIEM – программные продукты и сервисы, обеспечивающие анализ в режиме реального времени оповещений системы безопасности, генерируемых сетевым оборудованием, серверами, конечными точками и приложениями.

с июля 2024 г.

Действия регуляторов

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

2

Принимая во внимание сложную ситуацию с защитой подключенных автомобилей, в июне 2020 г. ООН приняла два новых положения по кибербезопасности и обновлению программного обеспечения, задача которых – помочь справиться с рисками путем установления четких требований к работе и аудиту для автопроизводителей. Это первые в истории международные согласованные и обязательные нормы в данной области. Документы регламентируют принятие мер по четырем отдельным дисциплинам:

l управление киберугрозами в транспортном средстве; l обеспечение безопасности транспортных средств для снижения рисков на протяжении всей производственно-сбытовой цепочки; l обнаружение и реагирование на инциденты по всему транспортному парку; l обеспечение безопасных и надежных обновлений программного обеспечения автотранспортных средств. Правила начали действовать с января 2021 г. и применяются к легковым автомобилям, фургонам, грузовым автомобилям и автобусам. Япония уже указала, что начнет применять эти правила после их вступления в силу, а Южная Корея приняла на вооружение поэтапный подход, включив положения постановления о кибербезопасности в национальное руководство во второй половине 2020 г. и приступив ко второму этапу осуществления этого постановления. В Евросоюзе новое положение о кибербезопасности будет обязательным для всех новых типов транспортных средств с июля 2022 г. и станет обязательным для всех транспортных средств, произведенных начиная с июля 2024 г. Предполагается, что необходимость укрепления кибербезопасности в автомобильной промышленности вызовет массовые инвестиции, объем которых может вырасти с $4,9 млрд в 2020 г. до $9,7 млрд в 2030 г. Новые регламенты ООН будут стимулировать инновации и создадут новые экономические возможности для поставщиков, ИТ-компаний, специализированных нишевых фирм и стартапов, особенно на рынке разработки программного обеспечения и услуг.

Угрозы и защита В процессе работы над исследованием The Cybersecurity Blind Spots of Connected Cars2 эксперты Trend Micro разработали и оценили 29 реальных сценариев атаки согласно модели угроз DREAD, которая позволяет провести качественный анализ рисков. Такие атаки могут удаленно осуществляться против транспортных средствжертв и/или с их помощью. Вот несколько выводов:

. https://internetofbusiness.com/worldwide-connected-car-market-to-top-125-million-by-2022/

38 •

l DDoS-атаки на интеллектуальные транспортные системы (ИТС) могут нарушить связь с автомобилями, и риск этого очень высок; l открытые и уязвимые подключенные автомобильные системы легко обнаружить, что повышает риск злоупотреблений; l более 17% всех исследованных векторов атак относились к группе высокого риска: они требуют лишь ограниченного понимания технологии подключенных автомобилей и могут быть выполнены даже злоумышленником с низкой квалификацией. По прогнозам, в период с 2018 г. по 2022 г. в мире будет выпущено более 125 млн легковых автомобилей со встроенными возможностями для подключения к Интернету, а также продолжит развиваться направление полностью автономных транспортных средств. Подобный прогресс приведет к появлению сложной экосистемы, которая будет включать облачные решения, Интернет вещей, 5G и другие ключевые технологии. Значительно увеличится и поверхность атаки, которая будет состоять из миллионов устройств и конечных пользователей. По мере развития отрасли для киберпреступников, хактивистов, террористов, национальных государств, инсайдеров и даже недобросовестных операторов появятся многочисленные возможности саботажа и монетизации уязвимостей – предупреждает Trend Micro в упомянутом выше исследовании. Во всех 29 исследованных векторах общий риск успешности кибератак был оценен как средний. Однако по мере того, как приложения SaaS будут встраиваться в архитектуру транспортных средств, а киберпреступники будут создавать новые стратегии монетизации, риски могут значительно возрасти. Чтобы снизить риски, описанные в исследовании, система безопасности подключенных автомобилей должна охватывать все критические области для защиты сквозной цепочки поставки данных. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

WebControl 3/26/21 9:33 PM Page 39

www.itsec.ru

БЕЗОПАСНАЯ РАЗРАБОТКА

Место безопасности в новой парадигме цифрового бизнеса От безопасной разработки к безопасному ПО Андрей Акинин, генеральный директор компании Web Control

Р

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

Наиболее адекватным ответом на эти вызовы стал подход Business Agility. Недостаточно быстро вывести продукт на рынок, продукт должен быть качественным, надежным и безопасным, а вопросы обеспечения безопасности с учетом сжатых сроков разработки должны быть учтены в момент формирования продуктового функционала, то есть потребительской ценности. Какое место у безопасности кода в подходе Business Agility? Перефразируя Льюиса Кэрролла, сегодня нужно бежать со всех ног, чтобы сохранить свои позиции в бизнесе, а чтобы обгонять конкурентов, надо бежать еще быстрее. При этом важно быть не только быстрым, но и гибким, ведь выживает не сильнейший, а тот, кто способен быстрее адаптироваться к требованиям рынка и эволюционировать. Гибкость присуща молодым компаниям, но по мере их развития консерватизм и бюрократия, свойственные иерархической модели управления, сокращают возможности быстро изменяться, замедляют реагирование на новые вызовы и, соответственно, снижают конкурентоспособность. Иерархическая модель управления хорошо работает в условиях стабильности, однако в условиях piriculum in mora, а говоря проще, "беги или умри", управление современной компанией требует других принципов.

От Agile для разработчиков к Business Agility Золотым стандартом разработки сегодня стал Agile, который направлен на дебюрократизацию процессов разработки, снижение рисков разработки, создание продукта в сотрудничестве с заказчиком и увеличение скорости вывода продукта на рынок. Доказав свою эффективность, Agile вышел за пределы команд разработчиков, эволюционировав сначала в Scaled Agile, а затем и в Business Agility. Business Agility – это новый прогрессивный подход к управлению всей компанией, а не только разработкой, вобравший в себя принципы

Lean Management, Agile, системного мышления и, наконец, клиент-ориентированного подхода в управлении, который позволяет сохранить гибкость и адаптивность бизнеса на любом этапе зрелости компании в условиях высокой неопределенности бизнес-окружения и переменчивости (волатильности) рынка. Почему это происходит? Внедряющие Business Agility компании демонстрируют: l улучшения в коммуникации и совместной работе команд за счет устранения разобщенности; l повышение вовлеченности сотрудников и, соответственно, скорости вывода продуктов на рынок и возврата инвестиций; l повышение мотивации сотрудников за счет понимания общей цели. Об этом нам говорит успех таких компаний, как Amazon, Apple, Facebook, Google, Microsoft, Netflix и Salesforce. Пандемия 2020 г., заставившая бизнес выйти из зоны комфорта и пересмотреть свои организационные процедуры, способствовала активному переходу компаний к более гибкому управлению на основе распределенных самоорганизующихся кросс-функциональных команд.

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

Компания сохраняет традиционную иерархию, но на нее органично накладывается виртуальная структура Value Stream Management. При этом потоки ценности могут быть как производственными, а именно создающими продукт (Development Value Streams), то есть непосредственно разработка ПО, так и операционными, обеспечивающими доставку продукта (Operational Value Streams), – маркетинг приложения, например. Это позволяет применить гибкий подход в управлении не только к разработке, но и ко всем процессам в компании, требующим такого подхода. Не существует единых практик и методов, которые могли бы помочь трансформировать организационную структуру компании из любой отрасли, однако в крупных цифровых компаниях наиболее проработанной методологией управления компанией в условиях Business Agility стал фреймворк SAFe (Scaled Agile Framework). Причем его используют не только разработчики ПО, но и финансовые организации, государственные органы и даже многие производственные компании, выпускающие вполне материальную продукцию – автомобили, самолеты, медикаменты и электронику. Этот фреймворк представляет собой набор шаблонов, практик и знаний, включая структурированное руководство по ролям и обязанностям, способы планирования работы и управления ею, которые опираются на принципы, ценности и компетенции. Поиск новых подходов к управлению связан с необходимостью ускорения поставки ПО, и здесь возникает вопрос: безопасность продукта – это опция, за которую надо платить отдельно, или производственный стандарт, неотделимый от других требований к качеству продукта?

Ремень безопасности: опция или стандарт? Ремень безопасности был запатентован в начале XIX века, но не получил широкого применения из-за неудобства его использования. Каких только отго-

• 39

WebControl 3/26/21 9:33 PM Page 40

ТЕХНОЛОГИИ ворок не приводили противники этого инструмента безопасности! Все изменилось в середине XX века, но, как ни странно, не из-за возросших рисков вследствие роста дорожного трафика. Толчком стало изобретение инженером компании Volvo современного динамического трехточечного ремня безопасности, которым стало удобно пользоваться. Сегодня им оборудуется каждый автомобиль, обязательность его использования установлена на законодательном уровне, и мы уже не представляем, что когда-то было иначе. Использование ремня безопасности стало частью нашей культуры пользования автомобилем. То же самое сейчас происходит в разработке продуктов. Способность компании быстро поставить новый продукт или новый функционал требует непрерывной циклической разработки, и традиционные подходы к сканированию релизного кода на наличие уязвимости существенно тормозят этот ритмичный процесс. Они, по сути, являются тем архаичным ремнем безопасности, существовавшим в автомобилях до изобретения инженера Volvo. Для обеспечения Business Agility пора переходить к новым инструментам и подходам в обеспечении безопасности программных продуктов, необходимо отходить от проверки на уязвимость в одной или двух точках к повышению уровня доверия ко всему процессу создания программных продуктов, того же от нас требуют и регуляторы. По сути, безопасность является одним из критериев качества программного продукта, и обеспечить ее без потери скорости выхода на рынок возможно, только интегрировав контроль безопасности на всех стадиях разработки продукта.

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

DevOps, оркестрация релизов, Shift Left и безопасность

Рис. 1. DevOps – это основа конвейера непрерывной поставки ПО. Источник: www.scaledagileframework.com/devops/

40 •

DevOps предназначен, по сути, для ускорения разработки и развертывания за счет автоматизации и слаженной работы разработчиков и инженеров. Фактически это именно те рельсы, по которым движется поезд создания ценности. Подход Business Agility основан на принципах Lean Agile (бережливый Agile, как бы непривычно это ни звучало), нацеленных на устранение непродуктивной деятельности, к которой относится и переделка кода, в том числе по причине его уязвимости и небезопасности. Подход Shift Left позволяет обеспечивать качество кода, включая его безопасность, на максимально ранних этапах разработки, начиная с выбора архитектуры, определения

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

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

Цикл безопасной разработки Обычно, говоря о DevOps, думают о CI/CD. Однако я считаю более правильным взгляд на DevOps как на процесс обеспечения всего жизненного цикла продукта, от идеи до вывода из эксплуатации. Именно этот взгляд мы можем увидеть в одном из наиболее проработанных фреймворков Lean Agile – Scaled Agile Framework (SAFe), который хорошо подходит как средним компаниям, так и транснациональным корпорациям и даже государственным структурам. Обратите внимание, Continuous Security (непрерывная безопасность) это не фаза DevOps, а его фундаментальный принцип, так же как контроль версий и непрерывное качество. Подумайте об этом… Современный подход говорит о четырех фазах DevOps: l Continuous Exploration (CE, непрерывное исследование), включающее исследование нужд потребителя и определение разрабатываемого функционала; l Continuous Integration (CI, непрерывная интеграция), в ходе которой происходит создание продукта; l Continuous Deployment (CD, непрерывное развертывание), во время которого разработанный функционал попадает в продсреду без участия инженеров; l Release on Demand (RD, релиз по требованию), то есть выпуск продукта тогда, когда возникает потребность в очередном релизе.

Continuous Exploration Большинство мер эффективно и целесообразно применять непосредственно на этапе разработки CI. Но при этом на этапе Continuous Exploration при разработке архитектуры критически важно смоделировать угрозы. Если моделирование угроз делать на более позднем этапе, то любые изменения кода или архитектуры потребуют намного больше времени или будут невозможны без глубокой переработки продукта. А это деньги!

Continuous Integration На этапе Continuous Integration обеспечение безопасности приложения начи-

WebControl 3/26/21 9:33 PM Page 41

www.itsec.ru

БЕЗОПАСНАЯ РАЗРАБОТКА

Continuous Deployment На этапе Continuous Deployment во время предрелизного тестирования очевидна потребность в тесте на проникновение. Пентестинг – это одна из немногих практик, которую сложно или практически невозможно полностью автоматизировать и реализовать на более ранних этапах разработки. Тем не менее даже здесь можно порекомендовать включить профессиональных пентестировщиков в команду разработки для проведения тестирования уже в Staging-среде на этапе Continuous Integration, а использование инструментов оркестрации релизов позволит значительно снизить транзакционные издержки при смещении Security Quality Gate на эту стадию..

Release on Demand На этапе Release on Demand безопасность готового продукта поддерживается посредством непрерывного мониторинга безопасности с помощью SIEM-решений и обработки данных командами ИБ. На этом этапе задействуются SOC, реагирование на инциденты, непрерывный мониторинг угроз, внешний аудит уязвимостей.

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

CodeScoring может быть использован на всех этапах конвейера DevOps: l на этапе Continuous Exploration он контролирует технический долг и анализирует состояние команды; l на этапе Continuous Integration/Continuous Deployment он идентифицирует лицензионные нарушения и контролирует количество и качество заимствованного кода; l на этапе Release on Demand CodeScoring предупреждает о новых уязвимостях, обнаруженных в компонентах Open Source уже после выхода продукта, и контролирует сложность решения с точки зрения управления рефакторингом продукта.

В заключение Безопасность по природе (Security by Nature) является фундаментом, обеспечивающим дальнейшую прочность и надежность продукта. Сегодня она становится частью культуры разработки организации, помогает избежать дополнительных затрат на безопасность, связанных с задержкой поставки ПО, переделкой кода и устранением уязвимостей, которых все так боятся. Этому способствуют, конечно же, и требования регуляторов обеспечению соответствующего уровня доверия к процессу разработки, и рост инцидентов кибербезопасности, и необходимость сокращения стоимости релиза, что, в том числе, является результатом своевременного контроля качества кода, неотъемлемой частью которого является контроль его безопасности. Я уверен, что нельзя рассматривать требования безопасности кода в отрыве от остальных требований к качеству разработки. Только при целостном и согласованном подходе к качеству, надежности и безопасности кода можно говорить о продуктах, качественных по природе. При использовании передовых практик DevOps и инструментов автоматизации интеграция в разработку требований к его безопасности происходит органично и необременительно. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Реклама

нается с инструментов SCA – анализа композиции кода Open Source, который должен стать первым шагом на пути к "безопасности по природе". Такие инструменты могут применяться на различных фазах разработки. Обычно проверки встраивают на входе в репозиторий или в скрипты сборки, но они могут встраиваться в IDE разработчика и предоставлять разработчикам обратную связь уже на стадии первичного кодирования. SCA – это универсальный инструмент декомпозиции, инвентаризации и контроля компонентов исходного кода, его можно использовать при любом уровне зрелости процессов обеспечения безопасной разработки. На начальных уровнях зрелости его применяют для анализа исходного кода во время статического тестирования и проверки всего кода Open Source. На более высоком уровне зрелости такие инструменты предоставляются каждому разработчику, они интегрируются в IDE разработчика, и анализ компонента Open Source происходит в момент добавления его в локальный репозитарий разработчика. Конечно же, кроме SCA, на этапе Continuous Integration должны использоваться различные инструменты и подходы, такие как плагины Security IDE, Security Code Review, парная работа разработчиков, статический и динамический анализ кода, фаззинг-тестирование, подписание кода, мониторинг инфраструктуры, антивирусная защита инфраструктуры и станций разработчика. Но, по моему мнению, невозможно выстроить адекватные процессы управления безопасностью, не поняв, из чего состоит система, то есть без полноценной инвентаризации исходного кода.

• 41

Kislitsyn 3/26/21 9:33 PM Page 42

ТЕХНОЛОГИИ

Проактивный поиск уязвимостей в исходном коде Владимир Кислицин, технический директор (CTO) Finsight Ventures

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

На практике далеко не каждая компания имеет правильное представление и

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

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

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

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

42 •

достучавшись до вашей камеры или микрофона.

В организации процессов разработки не должно быть компромиссов

Особенности организации проактивной разработки

В настоящее время бизнес все чаще основан на ИТ, и вполне целесообразно рассматривать разработку как самолет, на котором летит вся компания. В этой аналогии можно поставить вопрос таким образом: хотели бы вы искать компромиссы в безопасности полета? Думаю, ответ очевиден. К сожалению, на практике далеко не каждая компания имеет правильное представление и ресурсы для создания и поддержки нормального процесса проактивной разработки. А если ресурсы появляются, то не очень понятно, с чего и как начинать. Давайте попробуем разобраться с самого начала.

Быть проактивным – значит действовать сейчас для того, чтобы предотвратить проблемы в будущем. Если говорить о разработке, это означает писать код и строить архитектуру так, чтобы в будущем избежать неприятных сюрпризов. Именно проактивность часто становится большим препятствием на пути эффективного взаимодействия ИТ и бизнеса, ведь она влечет: l увеличение времени разработки, как следствие – ее стоимости; l повышение затрат на специалистов, понимающих принципы безопасной разработки и умеющих ее сопровождать; l повышение требований к четкости и слаженности процессов разработки, то есть в компании должны быть специалисты, создающие и поддерживающие эти процессы. Данные факторы рассматриваются в многочисленных компаниях как "избыточная" разработка, а написание кода в них начинает строиться по неправильной траектории: поверхностное ТЗ – беглый анализ – быстрая разработка – быстрое тестирование (иногда и вовсе без этого шага) – релиз – патчинг. Это порочный круг. В таких условиях практически любой задаче, решаемой дополнением кода в ПО, потребуется дальнейшая поддержка. В этом случае будет удачей, если между очередным патчем и новой проблемой не случится крупномасштабного инцидента (инъекции, утечки данных, накрутки исходящих звонков и т.д.).

Безопасная разработка на старте Если вы только стартуете и находитесь на этапе формирования процессов и архитектуры, как полностью с нуля, так и, возможно, начинаете новый проект на имеющейся инфраструктуре, то важнейшими факторами для проактивной безопасности будут бизнес-процессы разработки и ключевые этапы жизненного цикла любой задачи. Здесь неважно, по какой методологии вы будете работать, но важно соблюдать стандартные требования, в том числе: 1. Таск-трекинг. Желательно с возможностью формирования бизнес-процесса с разделением на подпроекты (Jira, YouTrack, Basecamp). Особенно важен момент именно с бизнес-процессом, так как при увеличении объема задач, как правило, постановка и анализ часто становятся поверхностными,

Kislitsyn 3/26/21 9:33 PM Page 43

www.itsec.ru

БЕЗОПАСНАЯ РАЗРАБОТКА

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

2. Жизненный цикл задачи. В качестве примера возьмем финтех-компанию средних объемов с командой разработки из 12 человек (Java/Angular), в которой он может выглядеть так: идея – анализ – сбор требований (формирование ТЗ) – определение исполнителя и сроков – согласование – разработка – внутреннее тестирование – внешнее тестирование – предрелизное тестирование – релиз – поддержка. Если у читателя возникает вопрос о том, где же здесь проактивность в безопасности разработки, то ответ довольно прост: от качества постановки задачи зависит большая часть ее дальнейшей жизни. Именно при анализе и сборе информации должны закладываться первоначальные требования к безопасности.

3. Назначение ответственных за каждый этап. Целью является не поиск виноватых, а четкое понимание задач и результатов, которых ждут коллеги. То есть при хорошо поставленном процессе для реализации конкретной задачи, помимо программистов, понадобится тестировщик – бизнес-аналитик (методолог), ответственный за задачу со стороны тех, кто ее поставил (эдакий локальный Product Owner). Дополнительным плюсом будет наличие в команде технического писателя и системного аналитика вкупе с архитектором для выстраивания правильных связей с уже имеющимся функционалом.

4. Требования непосредственно к разработке. Паттерн разработки, Code-Style, написание юнит-тестов (до или после написания основного кода), правила работы с контролем версий (правила ветвления и подтверждения изменений), Code Review и т.д. – практически все пункты являются залогом проактивной безопасности и, к сожалению, в полном комплекте используются только в 20–30% компаний. Стоит упомянуть, что львиной доли проблем в будущем можно избежать, если имеются подробные требования при постановке задачи, включая технический анализ, и хорошо знающий ваше ПО разработчик-техлид, выполняющий Code Review (рецензирование кода) при Merge

Request. Организация и осуществление процесса Code Review должны проходить в соответствии с устоявшимся в компании стилем и требованиями, заложенными техническим директором или техлидами команд. Бывали случаи, когда в компании код не принимался для слияния, если не был прокрыт тестами или хоть немного не соответствовал общей стилистике. Здесь выбор за вами – компромиссы или четкое соответствие всем требованиям. Проактивное устранение и предотвращение уязвимостей в коде особенно актуально на старте проекта или задачи. Со временем, начиная от постановки ТЗ и заканчивая сопровождением кода, вышедшего в релиз, и, соответственно, работой готового модуля, использование злоумышленниками потенциальных дыр в безопасности будет стоить дороже, а проактивность на этапах поддержки может и вовсе не сработать.

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

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

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

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

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

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

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

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

• 43

Kislitsyn 3/26/21 9:33 PM Page 44

ТЕХНОЛОГИИ Комментарий эксперта

Какой инструмент выбрать? У каждого своя правда

Дарья Орешкина, директор по развитию бизнеса компании Web Control

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

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

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

44 •

Написать приложение, которое будет работать в момент сдачи релиза, и наладить производство программного обеспечения, которое будет надежно эксплуатироваться в запланированные сроки, – две существенно разные задачи. Повышение качества кода и всевозможные его проверки требуют финансовых ресурсов, затрат времени, наличия компетенций, а также налаженного взаимодействия между командами разработки, информационной безопасности, юристами и, конечно, бизнесом. Не получится навязать разработчикам неудобный инструмент, он быстро окажется на свалке, несмотря на свою важность для задач других заинтересованных подразделений. Если же новый инструмент будет помогать мет используемых ресурсов, утечек памяти, определения ряда других уязвимостей. Статический анализатор можно представлять как автоматизированный процесс Code Review, с более эффективным проникновением (полный анализ всего кода, включая "мертвый"), но с отсутствующим прогнозом (не всегда такой анализ может увидеть утечку памяти, например), а также с частыми случаями нахождения ошибок вида false-positive – "подозрительных" мест, наличие или отсутствие ошибки в которых может точно определить только программист. Для разработчика, использующего, например, привычную для всех IDEA (и большинство других современных IDE), статический анализатор уже включен в базовый функционал среды разработки. В последнее время этот модуль значительно увеличил свою эффективность и как локальное решение (для конкретного разработчика) покрывает большую часть процесса анализа кода. Существенная сложность может заключаться в том, что анализатор IDE практически невозможно имплементировать в процесс непрерывной интеграции – CI/CD, а также в сбор статистики по анализу в разрезе отдела или департамента. Для таких задач подойдут standalone-решения: SonarQube, PMD, Checkstyle. Использование динамических анализаторов (таких как Valgrind, DynamoRIO и подобных) на практике встречается намного реже, скорее всего, по причине избы-

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

точности для большинства разрабатываемых приложений. В веб-приложениях динамический анализ полностью перекрывается функциональным тестированием, логами веб-окружения и профилированием с отладкой в IDE. Средства динамического анализа оправданны в конвейерной разработке крупных многопоточных приложений в больших количествах. Основное "направление" таких анализаторов – мониторинг и контроль утечек памяти в приложениях (особенно актуально при разработке на C/C++).

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

фильтрацию, сетевые антивирусы и различные системы предотвращения вторжений (IDS/IPS). Но не стоит забывать и про угрозы, которые могут приходить изнутри, – закладки в коде, считывание паролей сетевыми кейлоггерами, перенос на флешку дампа "боевой" базы данных и вынос ее за пределы компании с последующей продажей конкурентам или использованием в других целях. Меры, предпринимаемые для защиты от подобных атак, сильно варьируются в зависимости от специфики компании, ее культуры, внутренних процессов и имеющихся ресурсов. Учитывая скорость развития технологий, а также растущее количество внешних и внутренних угроз безопасности, совсем не лишним будет пересмотр подходов к процессам разработки, формированию ИТ-отделов и главных целей, которые преследуют команды в компании. Все это – подходы, процессы, инфраструктура разработки – должно быть пересмотрено с точки зрения безопасности. Быстрота работы приложения, удобство его интерфейсов отходят на второй план, когда дело касается утечки личной или корпоративной информации, а также финансового и репутационного ущерба. Если сегодня вы пересмотрите подход к разработке ПО в вашей компании, это будет главный вклад в проактивное устранение уязвимостей в будущем. l Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

Kokarev 3/26/21 9:33 PM Page 45

www.itsec.ru

ЗАЩИТА СЕТЕЙ

Использование Snort в режиме NIDS Ростислав Кокарев, главный специалист по внутреннему аудиту информационной безопасности департамента информационной безопасности компании Трансмашхолдинг

Д

анная статья описывает возможности, предоставляемые системой Snort в режиме NIDS (Network Intrusion Detection System, система обнаружения сетевых вторжений), включая дополнительные программные компоненты для улучшения базовой функциональности.

Архитектура Snort Snort является сервисом с открытым исходным кодом, распространяемым под лицензией GPL. Он был создан в 1998 г. Мартином Рошем, одним из известнейших людей в мире информационной безопасности, автором многих книг. Основной причиной создания системы Snort было отсутствие достаточно эффективного, тем более бесплатного, инструмента оповещения об атаках. Система Snort способна выявлять: l атаки на протоколы SNMP, Net-BIOS, ICMP; l атаки на веб-сервер (php, iss и т.д.); l атаки на протоколы SMTP, IMAP, POP3; l использование эксплойтов; l атаки на Telnet, DNS, FTP и т.д; l атаки DoS/DDoS; l атаки на базы данных SQL, Oracle и т.д. Архитектура Snort включает в себя несколько основных компонентов: библиотеку libpcap, декодер пакетов, препроцессор, детектор, базу правил и модули вывода информации. Так, библиотека libpcap позволяет перехватывать пакеты, поступающие на сетевую карту, до того, как они передаются в стек протоколов операционной системы. Можно отметить, что на основе данной библиотеки созданы и другие системы для мониторинга сети (например, снифер Wireshark). После перехвата пакет направляется в декодер, где из протоколов канального уровня, таких как Ethernet или 802.11, декапсулируются данные сетевого и транспортного уровня. Далее препроцессор подготавливает обработанные декодером данные для детектора. В Snort существует возможность настройки препроцессора и правил для увеличения быстродействия системы. Впо-

следствии детектор анализирует поступившие данные, ища в пакетах определенные правила или сигнатуры, находящиеся в базе. Правила состоят из описания угрозы и реакции при ее обнаружении. После завершения процедуры анализа Snort выводит необходимую информацию в требуемых форматах в log-/alert-файлы.

Snort может работать в трех режимах: 1. Режим системы обнаружения вторжений (перехват данных и анализ, автоматическая регистрация пакетов, если в правилах не указано иного).

2. Режим снифера (перехват и вывод данных).

3. Режим регистрации пакетов (перехват и регистрация данных в соответствующих файлах). Из дополнительных инструментов работы со Snort следует упомянуть Barnyard2, PulledPork, BASE и Snorby.

Barnyard2 является интерпретатором с открытым исходным кодом для обработки двоичных данных, предоставляемых Snort. Стандартные способы записи регистрируемых событий в Snort являются довольно ресурсоемкими, потому наилучший сценарий – использование для хранения базы данных MySQL с возможностью поиска и просмотра требуемых событий. Barnyard2 как раз и используется для загрузки событий в СУБД. Принципиальная схема взаимодействия выглядит так: производится настройка компонентов Snort для записи событий в двоичной форме и последующего перенаправления в Barnyard2 для дальнейшей чтения и записи в базу данных MySQL. PulledPork является скриптом, который загружает, устанавливает и обновляет правила для Snort из различных источников. Существует несколько наборов

данных, которые может загружать данный скрипт. Его также можно использовать для загрузки бесплатного набора правил сообщества Snort.

Правила Snort Snort использует простой в понимании и синтаксисе язык для написания правил, многие правила Snort пишутся буквально в одну строчку. Правила принципиально можно разделить на два основных вида: l бесконтекстные правила, создаются для каждого пакета отдельно; l контекстные правила препроцессоров. Правила состоят также из заголовка и опций. Заголовок включает в себя действие, протокол передачи, IP-адрес, а также сетевые маски и порты. Опции же включают в себя дополнительные критерии обработки правил и реагирующих действий. Данные параметры применяются для описания фильтрации сетевого трафика. Общая структура правил представлена в табл. 1. Заголовок правила должен содержать так называемое ключевое слово, определяющее действие, которое выполняется при совпадении всех заданных условий. Основные действия правил представлены в табл. 2. Существует возможность создания собственных типов правил (Ruletype), с помощью

Основной причиной создания системы Snort было отсутствие достаточно эффективного, тем более бесплатного, инструмента оповещения об атаках.

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

Рис. 1. Архитектура Snort

• 45

Kokarev 3/26/21 9:33 PM Page 46

ТЕХНОЛОГИИ Таблица 1. Структура правил Snort Заголовок правила Действие Протокол

Опции IP-адреса

Порт

отпра-

отпра-

вителя

вителя

Оператор

IP-адреса

Порт

Мета-

Полезная

Данные

получателя

получателя

данные

нагрузка

в заголовке реаги-

Правило рования

Таблица 2. Основные действия правил Snort

Вспомогательные компоненты

Действие

Описание

alert

Генерация оповещения с использованием указанного метода и передача информации о пакете в систему журналирования

log

Стандартное протоколирование информации о пакете

pass

Игнорирование поступающего трафика

activate

Генерация оповещения и включение указанного динамического правила

dynamic

Активация динамическим правилом

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

PulledPork

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

PulledPork – скрипт, помогающий Snort c загрузкой, установкой и обновлением наборов правил из различных источников.

PulledPork способен загружать несколько наборов правил, потому вы можете настроить его для загрузки бесплатного черного списка или же бесплатного набора от сообщества Snort. Для этого необходимо создать учетную запись на ресурсе snort.org и получить после регистрации уникальный код Oinkcode, который позволит загружать новые наборы правил.

Опции правил

Веб-интерфейс BASE

Опции правил являются ключевой частью правил Snort. Все опции можно условно разделить на несколько категорий: l General/meta-data – информация о правиле, не влияющая на детектирование; l Payload – опция, позволяющая просматривать поле данных пакета; l Non-payload – опция для наблюдения за служебными полями пакета; l Post-detection – опция-триггер, указывающая на то, что требуется совершить после срабатывания правила. Более подробные инструкции по формированию правил стоит смотреть в официальной документации сообщества Snort1.

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

BASE (Basic Analysis and Security Engine) – веб-интерфейс, который предназначен для анализа и визуализации событий, обнаруженных с помощью СОВ Snort. BASE был основан на проекте ACID (Analysis Console for Intrusion Databases). l

Рис. 2. Веб-интерфейс BASE

Более подробные инструкции по формированию правил стоит смотреть в официальной документации сообщества Snort.

Для того чтобы эффективно импортировать события Snort в базу данных MySQL, удобно использовать Barnyard2.

которых можно связать один или несколько модулей (Plugin). Данные типы впоследствии возможно будет применять как действия в правилах Snort. Следующее поле заголовка определяет протокол передачи данных. В настоящее время Snort способен различать и анализировать всего несколько типов протоколов: TCP, UDP, ICMP, IP. Однако уже в ближайшем будущем разработчики постараются включить также протоколы ARP, IGRP, GRE, OSPF, RIP и др. После протокола указываются соответствующие IP-адреса и порты. Здесь стоит отметить, что Snort не умеет определять адреса хостов по именам, а потому в правилах целесообразно указывать конкретные адреса или их диапазон. Заголовок "оператор" определяет направление трафика для данного правила с указанием IP-адреса и порта источ1

46 •

https://snort-org-site.s3.amazonaws.com/production/document_files

Ваше мнение и вопросы присылайте по адресу

is@groteck.ru

NEW_PROD 3/26/21 9:33 PM Page 47

www.itsec.ru

НОВЫЕ ПРОДУКТЫ И УСЛУГИ

Indeed Privileged Access Manager

Производитель: ООО "Индид" Назначение: программный комплекс для контроля и защиты доступа сотрудников к привилегированным учетным записям Особенности: комплекс получил усиленную защиту и самих серверов PAMсистемы; обновленная версия Indeed PAM 2.4, дополнена комплексом мер, направленных на обеспечение безопасности работы компонентов самой системы Возможности: теперь не требуется принимать дополнительные меры для обеспечения безопасности РАМ-системы с помощью групповых политик или других инструментов Характеристики: новая версия имеет важное обновление безопасности: jumpсерверы Indeed PAM получили активную защиту от несанкционированного подключения, запуска процессов и доступа к критичным файлам системы; регулирование списка разрешенных процессов и файлов доступно на этапе настройки системы и в процессе эксплуатации Ориентировочная цена: по запросу Время появления на российском рынке: март 2021 г. Подробная информация: indeedid.ru/indeed-privileged-access-manager Фирма, предоставившая информацию: компания "Индид" См. стр. 23

SafePhone MTD Edition

Производитель: НИИ СОКБ Сертификат: № 4157, выдан ФСТЭК России Назначение: автоматизация процессов безопасного централизованного управления мобильными устройствами компании Особенности: платформа EMM SafePhone сертифицирована ФСТЭК России, включена в реестр отечественного программного обеспечения Минцифры России, а также соответствует требованиям ГОСТ Р 57580.1–2017 "Безопасность финансовых (банковских) операций. Защита информации финансовых организаций"

Возможности: обеспечивает комплексную защиту информации и управление мобильными устройствами и приложениями организации. Продукт обеспечивает защиту мобильных устройств от несанкционированного доступа к корпоративным данным: l Обнаружение и удаление вредоносных (malware) и потенциально уязвимых (grayware) приложений и файлов l Управление устройствами (MDM) l Управление приложениями (MAM) l Управление контентом (MCM) Характеристики: SafePhone MTD Edition – платформа для управления мобильными устройствами, со встроенной библиотекой Kaspersky Mobile Security SDK SafePhone MTD Edition в дополнение к управлению устройством обеспечивает его антивирусную защиту.

SafePhone MTD Edition обеспечивает управление из единой консоли мобильными устройствами под управлением: Android, iOS, Windows, MacOS, Аврора Ориентировочная цена: по запросу Время появления на российском рынке: декабрь 2020 г. Подробная информация: mtd.safe-phone.ru Фирма, предоставившая информацию: НИИ СОКБ См. стр. 28, 29

m-TrusT Терминал

l Защита информации при ее передаче

по каналам связи

l Исключение доступа через общие

ресурсы

l Доверенный сеанс связи пользователя

с удаленными ресурсами

l Регистрация действий пользователя

Характеристики: процессор RK3399, совместим с последними версиями ядра Linux и поддерживает интерфейсы USB 3.0 и USB Type C, что обеспечивает высокий уровень вычислительной мощности при относительно низком энергопотреблении. Ресурсы терминала дают возможность обеспечить среду функционирования криптографии, позволяющую сертифицировать вариант исполнения СКЗИ (может быть различным) на m-TrusT на класс КС3. Дополнительно возможны: l Реализация поддержки SD-карт l Реализация блока защиты от инвазивных атак Удаленный доступ с защищенного терминала на базе m-TrusT может осуществляться с помощью встроенных средств, выбранных на этапе заказа: l Citrix ICA l Virtual Network Computing (VNC) l Free RDP Ориентировочная цена: зависит от состава компонентов в ОС и собственно ОС Время появления на российском рынке: 2021 г. Подробная информация: www.okbsapr.ru Фирма, предоставившая информацию: ЗАО "ОКБ САПР" См. стр. 21, 27

Центр-TrusT Производитель: ЗАО "ОКБ САПР" Сертификат: не подлежит сертификации, является СВТ Назначение: пользовательское автоматизированное рабочее место для автономной и удаленной работы Особенности: построен на платформе m-TrusT – специализированном микрокомпьютере Новой гарвардской архитектуры с аппаратной защитой данных. Обладает "вирусным иммунитетом". Предустановлены сертифицированные ФСТЭК и ФСБ России СЗИ (СДЗ, СЗИ НСД), ОС (опционально) и СКЗИ (опционально). По умолчанию предустановлена ОС из Реестра отечественного ПО (на выбор заказчика) Возможности: l Идентификация и аутентификация пользователя l Контроль целостности ПО l Доверенная загрузка ОС l Защита от несанкционированной модификации программ и данных l "Вирусный иммунитет"

Производитель: ЗАО "ОКБ САПР" Сертификат: не подлежит сертификации, является СВТ Назначение: пользовательское автоматизированное рабочее место для удаленной работы с загрузкой по сети Особенности: построен на платформе m-TrusT – специализированном микрокомпьютере Новой гарвардской архитектуры с аппаратной защитой данных. Обладает "вирусным иммунитетом". Предустановлены сертифицированные ФСТЭК и ФСБ России СЗИ (СДЗ, СЗИ НСД), ОС (опционально) и СКЗИ (опционально)

• 47

NEW_PROD 3/26/21 9:33 PM Page 48

НОВЫЕ

ПРОДУКТЫ И УСЛУГИ

Возможности: l Идентификация и аутентификация пользователя l Защищенная загрузка ПО по сети l Защита от несанкционированной модификации программ и данных l Удаленное администрирование загружаемых образов l "Вирусный иммунитет" l Защита информации при ее передаче по каналам связи (опционально) l Исключение доступа через общие ресурсы l Доверенный сеанс связи пользователя с удаленными ресурсами l Регистрация действий пользователя Характеристики: процессор RK3399, совместим с последними версиями ядра Linux и поддерживает интерфейсы USB 3.0 и USB Type C, что обеспечивает высокий уровень вычислительной мощности при относительно низком энергопотреблении. Ресурсы терминала дают возможность обеспечить среду функционирования криптографии, позволяющую сертифицировать вариант исполнения СКЗИ (может быть различным) на m-TrusT на класс КС3. Дополнительно возможны: l Реализация поддержки SD-карт l Реализация блока защиты от инвазивных атак Удаленный доступ с защищенного терминала на базе m-TrusT может осуществляться с помощью встроенных средств, выбранных на этапе заказа: l Citrix ICA l Virtual Network Computing (VNC) l Free RDP Ориентировочная цена: зависит от состава компонентов в ОС и собственно ОС Время появления на российском рынке: 2021 г. Подробная информация: www.okbsapr.ru Фирма, предоставившая информацию: ЗАО "ОКБ САПР" См. стр. 21, 27

Digital.ai (XebiaLabs DevOps Platform)

Фирма, предоставившая информацию: WEB CONTROL (официальный дистрибьютор в России) См. стр. 41

УСЛУГИ

Производитель: XebiaLabs, Inc Сертификат: изделие не подлежит сертификации Назначение: оркестрация инструментов и процессов DevOps, автоматизация развертывания релизов Особенности: l XebiaLabs предоставляет единую платформу для всех инструментов в вашем конвейере l Встроенные средства интеграции с распространенными (250+) инструментами DevOps l Простота и легкость развертывания, использования и масштабирования инфраструктуры выпуска ПО Возможности: l Ускоренный выпуск релизов l Оркестрация всех DevOps-инструментов и процессов, в том числе включая ручной режим l Автоматизация и "самообслуживание" развертывания l Обнаружение узких мест и предупреждение срыва сроков выпусков Характеристики: l Самостоятельный быстрый запуск кода в тестовой и производственной среде l Архитектура системы построена на основе Templates и Blueprints l Гибкая настройка процессов l Предназначено для средних и крупных компаний, которые управляют множеством релизов различных приложений в разных средах и инфраструктурах Время появления на российском рынке: февраль 2020 г. Подробная информация: xebialabs.com

Программа повышения квалификации "Администрирование средств защиты информации"

Отрасль: техническая защита информации, повышение квалификации Регион: Россия Описание: Продолжительность: 152 ак. ч. Форма обучения: очная или очнозаочная с применением дистанционных технологий. По окончании курса слушателям выдаются удостоверения МФТИ о повышении квалификации установленного образца. Программа повышения квалификации предусматривает изучение в том числе следующих тем: l Основные положения нормативно-правовых документов в области ТЗИ l Установка и настройка средств защиты информации на базе ОС Linux, в том числе в виртуальных средах l Системы централизованного удаленного управления ПАК доверенной загрузки и разграничения доступа. Меры по защите среды виртуализации и компонентов виртуальной инфраструктуры. Установка, настройка и администрирование ПАК "Аккорд-В". Установка и настройка "АккордWin32/64" и др. Фирма, предоставившая информацию: ОКБ САПР, ЗАО (совместно с Центром дополнительного профессионального образования МФТИ) См. стр. 21, 27

НЬЮС МЕЙКЕРЫ ИНДИД, ООО 121609, Москва, БЦ Крылатский, Осенний бульвар, 23, оф. 611 Тел.: 8 (800) 333-0906 E-mail: inbox@indeed-id.com indeed-id.ru См. стр. 23 НИИ СОКБ 117246, Москва, Научный пр-д, 17 Тел.: +7 (495) 646-7563 E-mail: info@niisokb.ru www.niisokb.ru См. ст. "Безопасность дистанционной работы: прогнозы и рекомендации" на стр. 28, 29 48 •

ОКБ САПР 115114, Москва, 2-й Кожевнический пер., 12 Тел.: +7 (495) 994-7262 okbsapr@okbsapr.ru E-mail: www.okbsapr.ru См. ст. "Инструменты контроля доступа для организации удаленной работы" на стр. 21 и ст. "Борьба с зараженными флешками в организации" на cтр. 27 СПЛАЙН-ЦЕНТР, ЗАО 105005, Москва, ул. Бауманская, 5, стр. 1

Тел.: +7 (495) 580-2555 E-mail: cons@debet.ru www.debet.ru, сплайн.рф См. стр. 15

WEB CONTROL 107023, Москва, ул. Электрозаводская, 24 Тел.: +7 (495) 925-7794 E-mail: info@web-control.ru web-control.ru См. стр. 41

Реклама

IB_Monitor 3/26/21 9:38 PM Page cov3

TB_Forum 3/26/21 9:38 PM Page cov4

2022

Реклама

15–17