www.itsec.ru № 1, март 2024 Издание компании УПРАвЛЕНИЕ УяЗвИмОСТямИ Спецпроект Спецпроект ЗАЩИТА ПЕРСОНАЛЬНЫХ ДАННЫХ ЖЕНСКИЙ ВЗГЛЯД НА ИБ ЭКоСИСтЕмы ИБ-рЕшЕНИЙ: тИпы И УроВНИ ЗрЕЛоСтИ КАтЕГорИроВАНИЕ по-хорошЕмУ: ЗА поЛГоДА, ЗА КВАртАЛ, ЗА мЕСЯц УпрАВЛЕНИЕ УЯЗВИмоСтЯмИ В НоВых рЕАЛИЯх поДхоДы К поИСКУ УЯЗВИмоСтЕЙ: хорошИЙ, пЛохоЙ, ЗЛоЙ СоВрЕмЕННыЕ тЕхНоЛоГИИ В рЕшЕНИЯх ДЛЯ УпрАВЛЕНИЯ УЯЗВИмоСтЯмИ ЗАщИтА пЕрСоНАЛьНых ДАННых по КоНтЕКСтУ пЕрЕДАчИ ИЛИ по СоДЕрЖАНИю? ЗАКоН оБ Ит-АУтСорСИНГЕ: КАК отрАЗИтСЯ НА ИБ? от чЕрНоГо ЯщИКА К проЗрАчНоСтИ: что CEO ДоЛЖЕН ЗНАть оБ ИБ Андрей Усенок Мы добились почти нулевого False Positive на WaF 8-9 октября 2024
Реклама
• 1 www.itsec.ru ИИ И КИИ Еще пару лет назад про Chat GPT и большие языковые модели (LLM) знали только энтузиасты систем на базе искусственного интеллекта. Сейчас же происходит настолько бурный рост этого сегмента, что мы уже не представляем себе мир без ИИ. Разумеется, это коснулось и информационной безопасности. Редкая конференция проходит без обсуждения применения искусственного интеллекта в ИБ. ИИ не только помогает в вопросах информационной безопасности, но и как новый объект защиты формирует огромный сегмент рынка ИБ – модели надо защищать, иначе вреда от них будет гораздо больше, чем пользы. l Защита выдаваемых данных, поскольку модели обучаются на большом немодерируемом объеме, и что именно выдаст система в ответ на промпт, заранее предсказать сложно. l Защита самой модели и выдаваемых ей результатов от специально сформированных промптов со стороны злоумышленников. l Использование моделей в качестве ассистентов для совершения киберпреступлений. Вопросами исследования безопасности больших языковых моделей уже занимаются несколько компаний на российском рынке. И их число будет расти. Несколько лет действует исследовательский центр доверенного искусственного интеллекта ИСП РАН, который ставит своей целью создание методик и программных и аппаратнопрограммных платформ для разработки и верификации технологий искусственного интеллекта с требуемым уровнем доверия. Вполне возможно, что в ближайшем будущем вопросы создания и использования систем на базе ИИ будут регулироваться примерно так же, как это происходит с персональными данными, объектами КИИ или криптографией. Тем временем многие LLM-модели лежат в свободном доступе, любой желающий может установить и использовать. А это значит, что вопрос защиты ИИ уже скоро станет массовым. Амир Хафизов, выпускающий редактор журнала “Информационная безопасность”
2 • СОДЕРЖАНИЕ 16 стр. 30 стр. 56 стр. 50 стр. ПРАВО И НОРМАТИВЫ Анастасия Заведенская Обзор изменений законодательства. Январь, февраль 2024 г. . . .4 В ФОКУСЕ КИИ Константин Саматов Комплексная защита КИИ на производственном объекте . . . . . . .8 Вячеслав Половинко Экосистемы ИБ-решений в России: типы и уровни зрелости . . .10 Федор Музалевский Категорирование по-хорошему: за полгода, за квартал, за месяц . . .12 Василий Савостьянов Dr.Web Industrial: защита серверов и рабочих станций в промышленных системах управления . . . . . . . . . . . . . . . . . . . . . .14 ПЕРСОНЫ Андрей Усенок Мы добились почти нулевого False Positive на WAF . . . . . . . . . . . .16 СПЕЦПРОЕКТ: УПРАВЛЕНИЕ УЯЗВИМОСТЯМИ Павел Попов Управление уязвимостями в новых реалиях: что изменилось и как перестроить процесс . . . . . . . . . . . . . . . . . . .20 Андрей Селиванов Приоритизация – ключ к эффективному управлению уязвимостями организаций в условиях большого количества активов . . . . . . . . . .22 Сергей Уздемир Управление уязвимостями: ожидание, реальность, рекомендации . .24 Александр Дорофеев Подходы к поиску уязвимостей: хороший, плохой, злой . . . . . . .26 Владимир Тележников Управление уязвимостями при разработке ОС Astra Linux . . . . . .27 Владимир Михайлов Современные технологии в решениях для управления уязвимостями . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28 Ольга Гурулева Главное, чтобы исследователь не ушел от нас с негативной реакцией . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30 Андрей Макаренко Управление уязвимостями с помощью ИИ . . . . . . . . . . . . . . . . . . . .32
• 3 Журнал "Information Security/Информационная безопасность" № 1, 2024 Издание зарегистрировано в Минпечати России Свидетельство о регистрации ПИ № 77-17607 от 9 марта 2004 г. Учредитель и издатель компания "ГРОТЕК" Генеральный директор ООО "ГРОТЕК" Андрей Мирошкин Издатель Владимир Вараксин Выпускающий редактор Амир Хафизов Редактор Светлана Хафизова Корректор Галина Воронина Дизайнер-верстальщик Ольга Пирадова Фото на обложке Юлия Полушкина Юрисконсульт Кирилл Сухов, [email protected] Департамент продажи рекламы Зинаида Горелова, Ольга Терехова, Татьяна Чаусова Рекламная служба Тел.: +7 (495) 647-0442, [email protected] Отпечатано в типографии ООО "Линтекст", Москва, ул. Зорге, 15 Тираж 5 000. Цена свободная Оформление подписки Тел.: +7 (495) 647-0442, www.itsec.ru Департамент по распространению Тел.: +7 (495) 647-0442 Для почты 123007, Москва, а/я 26 E-mail: [email protected] Web: www.groteck.ru, www.itsec.ru Перепечатка допускается только по согласованию с редакцией и со ссылкой на издание За достоверность рекламных публикаций и объявлений редакция ответственности не несет Мнения авторов не всегда отражают точку зрения редакции © "ГРОТЕК", 2024 СОДЕРЖАНИЕ Любовь Ермилова Управляем поверхностью атаки: лучшие практики и подводные камни . . . . . . . . . . . . . . . . . . . . . . . .33 Николай Степанов Attack Surface Management: с чего начинать управление уязвимостями . . . . . . . . . . . . . . . . . . .34 Таблица российских решений класса Vulnerability Management . .36 Эволюция систем управления уязвимостями. Круглый стол . . . .40 ТЕХНОЛОГИИ Юрий Иванов Новые горизонты защиты: как ИИ революционизирует информационную безопасность . . . . . . . . . . . . . . . . . . . . . . . . . . . . .46 Дмитрий Шпанько Рекомендации для роли ИБП в инфраструктуре информационной безопасности . . . . . . . . . . . . . . . . . . . . . . . . . . . . .47 СПЕЦПРОЕКТ: ЗАЩИТА ПЕРСОНАЛЬНЫХ ДАННЫХ Александр Клевцов Защита персональных данных по контексту передачи или по содержанию? . . . . . . . . . . . . . . . . . .50 Денис Лукаш Правовые риски взаимодействия с обработчиками в случае утечек персональных данных . . . . . . . . . . . . . . . . . . . . . . .52 Максим Захаров Закон об ИТ-аутсорсинге: зачем, для чего и как отразится на ИБ? . . .54 СПЕЦПРОЕКТ: ЖЕНСКИЙ ВЗГЛЯД Екатерина Старостина, Екатерина Бузаева Что такое "Женсовет по ИБ"? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .55 Женский взгляд на информационную безопасность. Круглый стол . .56 УПРАВЛЕНИЕ Евгений Сурков От "черного ящика" к прозрачности: что CEO должен знать об ИБ . . .62 КРИПТОГРАФИЯ Александр Подобных Управление уязвимостями в криптокошельках . . . . . . . . . . . . . . . .64 Блокчейн в России: взгляд сквозь призму практики. Круглый стол . . .66 НОВЫЕ ПРОДУКТЫ И НЬЮСМЕЙКЕРЫ Новые продукты . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .69 Ньюсмейкеры . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .70
4 • ПРАВО И НОРМАТИВЫ Доверенные ПАК В январе 2024 г. был опубликован ПНСТ 905-2023 "Критическая информационная инфраструктура. Доверенные программно-аппаратные комплексы. Термины и определения"1 , который вводится в действие 01.04.2024, срок его действия до 01.04.2027. Стандарт устанавливает термины и определения основных понятий, относящихся к доверенным программноаппаратным комплексам, применяемым на объектах критической информационной инфраструктуры. Термины, установленные стандартом, рекомендуются для применения во всех видах документации и литературы в области проектирования, разработки и изготовления доверенных программно-аппаратных комплексов и их компонентов, используемых в составе программноаппаратных комплексов, а также при разработке нормативных документов в указанной области. Так, например, согласно опубликованному предварительному национальному стандарту, доверенный программно-аппаратный комплексом (ДПАК) – это программно-аппаратный комплекс, соответствующий требованиям обеспечения технологической независимости критической информационной инфраструктуры, функциональности, надежности и защищенности. Перечни типовых объектов КИИ Минпромторгом России были опубликованы следующие перечни2 типовых КИИ, согласованные со ФСТЭК России: l Перечень типовых объектов КИИ, функционирующих в области химической промышленности. l Перечень типовых объектов КИИ, функционирующих в области горнодобывающей промышленности (в части руд, камней). l Перечень типовых объектов КИИ, функционирующих в области металлургической промышленности. l Перечень типовых объектов КИИ, функционирующих в области оборонной промышленности. На сайте Минпромторга России также доступна Инструкция по выполнению требований законодательства РФ о защите КИИ организациями, осуществляющими деятельность в сфере оборонной, металлургической и химической промышленности3 . Стоит отметить, что указанной инструкцией предусмотрено, что результаты выполнения работ, в том числе по процессу категорирования, необходимо направить в ФГУП "НПП "ГАММА". Минздрав России также по согласованию с ФСТЭК России утвердил Перечень типовых отраслевых объектов КИИ, функционирующих в сфере здравоохранения4 . Формы подтверждения соответствия информационных технологий и технических средств, предназначенных для обработки биометрических ПДн Приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 29.11.2023 № 1024 "О формах подтверждения соответствия информационных технологий и технических средств, предназначенных для обработки биометрических персональных данных, векторов единой биометрической системы, требованиям, определенным в соответствии с подпунктом "е" пункта 1 части 2 статьи 6 Федерального закона от 29 декабря 2022 г. № 572-ФЗ "Об осуществлении идентификации и (или) аутентификации физических лиц с использованием биометрических персональных данных, о внесении изменений в отдельные законодательные акты Российской Федерации и признании утратившими силу отдельных положений законодательных актов Российской Федерации", и о внесении изменений в приказ Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации от 12 мая 2023 г. № 453"5 официально опубликован 12 января 2024 г., вступил в силу с 23 января 2024 г. Приказом Минцифры России от 29.11.2023 № 1024 по согласованию с ФСБ России и Банком России утверждены: l форма подтверждения соответствия информационных технологий, предназначенных для обработки биометрических персональных данных, векторов единой биометрической системы; l форма подтверждения соответствия технических средств, предназначенных для обработки биометрических ПДн, векторов единой биометрической системы. Формы включают информацию о наименовании, типе, версии, модальности информационных технологий, модели и типе технических средств, а также об их разработчиках и производителях 4 • Обзор изменений в законодательстве обзоре изменений законодательства за январь 2024 г. рассмотрим предварительный национальный стандарт по доверенным ПАК, перечни типовых объектов КИИ от Минпромторга России и Минздрава России, а также формы подтверждения соответствия информационных технологий и технических средств, В предназначенных для обработки биометрических Пдн. Анастасия Заведенская, независимый эксперт по информационной безопасности Январь-2024 1 https://protect.gost.ru/document1.aspx?control=31&baseC=6&page=8&month=1&year=2024&search=&id=257135 2 https://minpromtorg.gov.ru/activities/vgpp/vgpp4/perechni-tipovyh-obektov-kii?utm_medium=letter&utm_source=letterevent&utm_campaign=letterevent_abiss_dig_13022024 3 https://minpromtorg.gov.ru/activities/vgpp/vgpp4/npa?pdfModalID=1891be71-c6fe-42fd-a23d-f52d98c8b96a&fileModalID=40c02104- d5df-452f-bec3-a935c3b40752 4 https://portal.egisz.rosminzdrav.ru/news/937 5 http://publication.pravo.gov.ru/document/0001202401120014?utm_medium=letter&utm_source=letterevent&utm_campaign=letterevent_abiss_dig_13022024 Фото: Анастасия Заведенская
• 5 ПРАВО И НОРМАТИВЫ www.itsec.ru Методика оценки показателя состояния защиты информации и обеспечения безопасности объектов КИИ Информационным сообщением ФСТЭК России от 12 февраля 2024 г. № 240/91/688 сообщается о разработке методического документа ФСТЭК России "Методика оценки показателя состояния защиты информации и обеспечения безопасности объектов критической информационной инфраструктуры Российской Федерации"6 . Документ определяет порядок оценки текущего состояния технической защиты информации, не содержащей сведений, составляющих государственную тайну, и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации в органах государственной власти и организациях, в том числе являющихся субъектами КИИ. Целью применения указанного методического документа является оценка степени достижения органами государственной власти и организациями минимально необходимого (базового) уровня защиты информации, не составляющей государственную тайну, и уровня обеспечения безопасности значимых объектов КИИ от наиболее распространенных угроз безопасности информации. Предложения по совершенствованию проекта методического документа принимались ФСТЭК России до 15 марта 2024 г. Проект Методики оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации также был размещен на официальном сайте ФСТЭК России7 . Методика разработана в целях реализации ФСТЭК России новых полномочий по осуществлению в пределах своей компетенции централизованного учета информационных систем и иных объектов КИИ по отраслям экономики, а также мониторинга текущего состояния технической защиты информации и обеспечения безопасности значимых объектов КИИ. Методика будет применяться: l ФСТЭК России – для мониторинга; l органом (организацией) – для оценки текущего состояния технической защиты информации и (или) обеспечения безопасности значимых объектов КИИ, а также оценки деятельности заместителя руководителя органа (организации), на которого возложены полномочия по обеспечению информационной безопасности, и (или) структурного подразделения, осуществляющего функции обеспечения информационной безопасности органа. При реализации методики должен быть рассчитан показатель защищенности – уровень КЗИ. Оценка уровня КЗИ включает: l сбор и анализ исходных данных, необходимых для оценки уровня КЗИ; l определение значений частных показателей безопасности КЗИ; l расчет значения уровня КЗИ и его сравнение с нормированным значением. Информационные системы, автоматизированные системы управления, информационно-телекоммуникационные сети, иные объекты информатизации и содержащаяся в них информация органа (организации) имеют минимально необходимый уровень защищенности от актуальных угроз безопасности информации, если значение уровня КЗИ соответствует нормированному значению: КЗИ = 1. Расчет уровня КЗИ проводится не реже чем один раз в квартал. Государственный контроль за обеспечением защиты государственной тайны В феврале 2024 г. ФСТЭК России представила для общественного обсуждения ряд проектов ведомственных приказов в части организации государственного контроля за обеспечение защиты государственной тайны: l "Об определении территориальных органов и структурных подразделений ФСТЭК России, должностных лиц ФСТЭК России и ее территориальных 6 https://fstec.ru/dokumenty/vse-dokumenty/informatsionnye-i-analiticheskie-materialy/informatsionnoe-soobshchenie-fstek-rossiiot-12-fevralya-2024-g-n-240-91-688 7 https://fstec.ru/dokumenty/vse-dokumenty/proekty/proekt-metodicheskogo-dokumenta-3 Реклама Февраль-2024 обзоре изменений законодательства за февраль 2024 г. поговорим о проекте Методики оценки показателя состояния защиты информации и обеспечения безопасности объектов КИИ от ФСТЭК России, проектах ведомственных приказов ФСТЭК России по части организации государственного контроля за обеспечением защиты государственной тайны, о новых стандартах в области безопасной разработки ПО, а также об изменениях в требованиях к форме квалифицированного сертификата ключа проверки электронной подписи (ЭП). В
6 • ПРАВО И НОРМАТИВЫ органов, уполномоченных на осуществление федерального государственного контроля за обеспечением защиты государственной тайны в пределах компетенции ФСТЭК России, а также должностных лиц ФСТЭК России и ее территориальных органов, уполномоченных совершать действия (принимать решения) при осуществлении федерального государственного контроля за обеспечением защиты государственной тайны в пределах компетенции ФСТЭК России"8 . l "Об определении перечня подлежащих проверке вопросов при осуществлении ФСТЭК России и ее территориальными органами федерального государственного контроля за обеспечением защиты государственной тайны в пределах компетенции ФСТЭК России"9 . l "Об утверждении порядка подготовки планов проведения ФСТЭК России и ее территориальными органами плановых проверок при осуществлении федерального государственного контроля за обеспечением защиты государственной тайны в пределах компетенции ФСТЭК России и оформления результатов проверки (в том числе требований к содержанию акта проверки)"10 . l "Об утверждении форм документов, используемых ФСТЭК России и ее территориальными органами при осуществлении и по результатам федерального государственного контроля за обеспечением защиты государственной тайны в пределах компетенции ФСТЭК России"11 . Стандарты по безопасной разработке В феврале 2024 г. были также официально опубликованы следующие национальные стандарты: l ГОСТ Р 712060–2024 "Защита информации. Разработка безопасного программного обеспечения. Безопасный компилятор языков С/С++. Общие требования"12 . l ГОСТ Р 71207–2024 "Защита информации. Разработка безопасного программного обеспечения. Статический анализ программного обеспечения. Общие требования"13 . ГОСТ Р 71206–2024 устанавливает общие требования к безопасному компилятору программ на языках С и С++. Целью работы безопасного компилятора является исключение внесения в бинарный код программы ошибок, которых не было в исходном коде программы и которые могут появиться в ходе компиляции, в том числе в ходе выполнения оптимизаций кода программы. Стандарт задает требования к динамической компоновке и загрузке программ, выполнение которых необходимо для поддержки ряда возможностей безопасного компилятора. Стандарт уточняет требования к мерам по разработке безопасного программного обеспечения, реализуемым при выполнении конструирования и комплексирования программного обеспечения, в части требований к используемым инструментальным средствам (безопасному компилятору). ГОСТ Р 71207–2024 описывает порядок внедрения и выполнения статического анализа, устанавливает требования к его выполнению, классификацию ошибок, находимых статическими анализаторами, а также требования к методам анализа, к инструментам статического анализа, к специалистам, участвующим в выполнении анализа, а также к методике проверки статических анализаторов на соответствие требованиям данного стандарта. Подразумевается, что стандарт предназначен: l для разработчиков статических анализаторов; l для разработчиков средств защиты информации, средств обеспечения безопасности информационных технологий; l для разработчиков программного обеспечения. Квалифицированный сертификат ключа проверки ЭП Приказ ФСБ России от 02.02.2024 № 50 "О внесении изменений в Требования к форме квалифицированного сертификата ключа проверки электронной подписи, утвержденные приказом ФСБ России от 27 декабря 2011 г. № 795"14 официально опубликован 5 февраля 2024 г. Приказ ФСБ России от 02.02.2024 № 50 вступает в силу с 1 сентября 2024 г. и действует до 1 сентября 2027 г. Приказом ФСБ России от 02.02.2024 № 50, в частности, будут внесены следующие изменения и дополнения: l квалифицированный сертификат также должен будет содержать информацию о сроке действия ключа электронной подписи, соответствующего уникальному ключу проверки ЭП, содержащемуся в данном квалифицированном сертификате; l определен общий вид квалифицированного сертификата на бумажном носителе для владельца – лица, замещающего государственные должности, государственные должности субъектов РФ, должностного лица государственных органов, органов местного самоуправления, их подведомственных учреждений, Центрального банка РФ; l определен общий вид квалифицированного сертификата на бумажном носителе для владельца – филиала (представительства) иностранного юридического лица. l 8 https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=145358 9 https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=145359 10 https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=145361 11 https://regulation.gov.ru/Regulation/Npa/PublicView?npaID=145362 12 https://protect.gost.ru/document.aspx?control=7&id=257755 13 https://protect.gost.ru/document.aspx?control=7&id=257752 14 http://publication.pravo.gov.ru/document/0001202402050048 Ваше мнение и вопросы присылайте по адресу [email protected] Изображение: playground.com
Реклама
Первое, с чего нужно начинать создание системы защиты, – это определение объектов защиты и состава мер, которые необходимо реализовать. Создание надежной комплексной системы защиты критической и н ф о р м а ц и о н н о й инфраструктуры крайне важно для бесперебойной деятельности предприятия и минимизации возможного ущерба. КИИ представляет собой совокупность объектов (автоматизированных систем), а также сетей связи, обеспечивающих взаимодействие этих объектов (систем). Основными объектами КИИ промышленных комплексов являются: l автоматизированные системы управления технологическими процессами (АСУТП); l вспомогательные информационные системы: системы мониторинга оборудования, MES (Manufacturing Execution System – система управления производственными процессами), ERP (Enterprise Resource Planning – система планирования ресурсов предприятия) и т.п.; l информационные системы персональных данных (достаточно редкий вид в рамках производственных объектов, но все же встречается). Говоря о комплексной защите, или, более правильно, комплексе мероприятий по защите объектов КИИ в рамках производственного предприятия, можно выделить следующие уровни защиты: 1. Защита от физического проникновения на объект. 2. Защита компонентов объектов КИИ. 3. Защита информации, обрабатываемой объектами КИИ и передаваемой между ними. 4. Регламентация процессов информационной безопасности. 5. Работа с персоналом. Безопасность объектов на каждом из указанных уровней обеспечивается путем реализации набора мероприятий (см. таблицу). Приведенный в таблице набор мер является ориентировочным и подлежит адаптации 8 • В ФОКУСЕ Комплексная защита КИИ на производственном объекте беспечение информационной безопасности объектов КИИ является одной из приоритетных задач любого современного производственного предприятия. Риски кибератак, утечки данных или сбоев в работе автоматизированных систем могут привести к остановке технологических процессов, нарушению О экологической обстановки и прямым финансовым потерям. Константин Саматов, руководитель комитета по безопасности КИИ, член Правления Ассоциации руководителей служб информационной безопасности Таблица Фото: Константин Саматов Уровень Набор мероприятий Защита от физического проникновения на объект l Установка систем видеонаблюдения, контроля доступа в помещения (на территорию производственного объекта), систем защиты периметра объекта (земельного участка) l Организация безопасного хранения носителей информации Защита компонентов: рабочие станции, сервера, сетевое оборудование, программно-логические контроллеры и т.п. l Организация контроля физического доступа к программно-аппаратным средствам объектов КИИ и линиям связи l Применение программных (программно-аппаратных) средств защиты информации (в т.ч. встроенных в общесистемное, прикладное программное обеспечение): межсетевые экраны, средства антивирусной защиты, средства идентификации и аутентификации и т.п. l Мониторинг и реагирование на инциденты информационной безопасности Защита информации l Категорирование (определение класса, уровня защищенности) систем, определение значимости обрабатываемой в них информации l Анализ угроз информационной безопасности и разработка (уточнение) моделей угроз безопасности l Разграничение доступа к информации различных видов/категорий l Резервное копирование информации l Шифрование конфиденциальных данных Регламентация процессов l Описание в локальных нормативных актах действий пользователей и администраторов по реализации мер защиты информации. Основными документами, регламентирующими вопросы защиты информации, могут быть "Политика информационной безопасности", "Инструкции администраторов безопасности", "Инструкции пользователей", "План обеспечения непрерывной работы и восстановления", "Регламент реагирования на инциденты ИБ", "Регламент по резервному копированию", "Матрица доступа персонала к ресурсам объектов КИИ", "Регламент антивирусной защиты" l Определение (закрепление) администраторов и администраторов безопасности
Создание эффективной системы защиты объектов КИИ является многоэтапным процессом, включающим в себя определение объектов защиты, аудит текущего состояния, проектирование, внедрение средств защиты и их ввод в эксплуатацию. в соответствии с актуальными угрозами информационной безопасности, применяемыми информационными технологиями и особенностями функционирования производственного объекта, с учетом требований следующих нормативных документов: l Приказ ФСТЭК России от 21.12.2017 № 235 "Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования". l Приказ ФСТЭК России от 25.12.2017 № 239 "Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации". l Приказ ФСТЭК России от 14.03.2014 № 31 "Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды". l Приказ ФСТЭК России от 18.02.2013 № 21 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных". Выше был указан ориентировочный набор мер для обеспечения комплексной защиты объектов КИИ на производственном объекте, теперь давайте рассмотрим алгоритм создания такой системы защиты. Алгоритм создания системы защиты Первое, с чего нужно начинать создание системы защиты, – это определение объектов защиты и состава мер, которые необходимо реализовать. Этому и была посвящена предыдущая часть статьи. Второе – это аудит, то есть оценка текущего состояния информационной безопасности с целью понять, что уже сделано (какие меры реализованы ранее), а что еще необходимо сделать для создания комплексной системы защиты информации1 . Третье – проектирование системы защиты, то есть разработка описания системы защиты, основанного на результатах аудита (понимании текущего положения дел) и включающего компоненты и функции, которые будут включены в систему, описание того, как они будут работать вместе, какие технологии и инструменты будут использоваться для ее разработки и поддержки. Четвертое – внедрение: закупка, установка и настройка средств защиты, образующих комплексную систему защиты информации. Пятое – ввод в эксплуатацию: проведение испытаний, опытной эксплуатации и ввод в промышленную эксплуатацию. Если необходимо создать комплексную систему безопасности с нуля или осуществить ее модернизацию (внесение существенных изменений), то все указанные пять этапов следует рассматривать как проект и применять для их реализации принципы проектного управления (обычно в таких случаях подходит "классическое" проектное управление, а не гибкие методологии). Когда система создана и функционирует, необходимо обеспечить ее дальнейшее сопровождение и совершенствование. Напомню знаменитый цикл Шухарта-Деминга: Планирование (Plan) – Выполнение (Do) – Контроль (Check) – Корректировка/Улучшение (Act). В рамках процессов сопровождения рекомендую обеспечить: l периодическое проведение анализа эффективности системы защиты информации и внедрение необходимых изменений; l учет изменений, трендов и развития технологий как в области автоматизации технологических процессов, так и информационной безопасности; l постоянное обновление программного и аппаратного обеспечения с целью закрытия уязвимостей и поддержания устойчивого функционирования; l проведение регулярных аудитов безопасности, включая различные виды тестирования на проникновение (внутренний нарушитель, внешний нарушитель). В заключение следует отметить, что создание эффективной системы защиты объектов КИИ является многоэтапным процессом, включающим в себя определение объектов защиты, аудит текущего состояния, проектирование, внедрение средств защиты и их ввод в эксплуатацию. Однако работа не заканчивается на этапе создания системы. Важно обеспечить ее постоянное сопровождение и совершенствование, что позволит своевременно реагировать на изменения в ландшафте угроз, закрывать новые уязвимости, следить за развитием технологий защиты и повышать общий уровень безопасности производственного предприятия. l • 9 КИИ www.itsec.ru Когда система создана и функционирует, необходимо обеспечить ее дальнейшее сопровождение и совершенствование. Ваше мнение и вопросы присылайте по адресу [email protected] Фото: playground.com 1 Подробнее о том, что такое аудит и как его проводить, можно посмотреть в статье https://lib.itsec.ru/articles2/focus/osobennosti-provedeniya-auditainformatsionnoy-bezopasnosti-obektov-kii
Потребность в таком агрегирующем термине, как "экосистема" ИБ-решений, очевидна. Логичным будет определить экосистему ИБ-решений как набор программных, программно-аппаратных продуктов (как правило, но не обязательно, мультивендорных) и организационных мер, составляющих единый комплекс (архитектуру) в составе СЗИ и иных классов решений (АСУ ТП, ИТ, физической безопасности и др.), функционирующих в целях достижения общей цели – повышения уровня защищенности защищаемого объекта (-ов), характеризующихся количеством включенных в экосистему продуктов, их типом, а также уровнем зрелости их функциональной совместимости, интеграции, производительности и надежности. Термин "экосистема" понадобился, чтобы каким-то образом зафиксировать тенденцию, демонстрирующую экономическое, партнерское и технологическое взаимодействие относительно разнородных вендоров на активно развивающемся рынке ИТ, ИБ, АСУ ТП. Предполагается, что данный термин может иметь временный характер, скорее служить "признаком времени", и, возможно,будет не так актуален для развитых зарубежных рынков. Иные рынки, в особенности западные, могут характеризоваться тем, что на них присутствуют вендоры гораздо больших размеров, сформированные за счет длительных периодов поглощений и диверсификации своих продуктов, которые предлагают масштабные комплексные решения под одним брендом. Для российского рынка такое положение дел актуально в гораздо меньшей степени, именно поэтому обсуждаемый термин и разные аспекты его применения (референсные архитектуры, модели, заявления о совместимости, интеграционные мультивендорные решения и др.) присутствуют и активно эксплуатируются производителями в ходе обсуждения своих и смежных продуктов. Крупные производители СЗИ на российском рынке (например, Positive, Kaspersky) по аналогии с зарубежными коллегами предлагают свои экосистемы в виде моновендорных решений для рынка, но даже они рассматривают и реализуют партнерские решения с другими вендорами СЗИ в попытке построения более емких экосистем ИБ – это связано с высокой динамикой и потенциалом роста рынка ИБ в целом. Построение и формирование экосистемы СЗИ-решений – крайне важный тренд, который позволяет преодолевать возникший технологический разрыв в сегментах ИБ и предлагать комплексные решения. Рассмотрим экосистемные решения именно в контексте рынка ИБ, во всех случаях будет присутствовать то или иное СЗИ, а дополнительный акцент в примерах экосистем будет сделан в том числе на практику применения однонаправленных шлюзов ("диодов", InfoDiode) в рамках построения экосистемных решений. Выделим несколько направлений группировки экосистемных решений. По количеству 1. Моновендорные. На них более подробно останавливаться не будем. Они характерны только для доминирующих вендоров ИБ на рынке, которых в настоящее время немного. 2. Два вендора. Достаточно частый случай для российского рынка. Кроме того, соответствует общей позиции вендоров – стараться практически полностью закрывать какой-то класс решений с привлечением минимального количества партнеров. Такие решения имеют под собой чисто экономическую основу, позволяют продвигаться вперед максимально быстро с минимальными трудозатратами. Двухвендорные решения имеют и свои минусы, так как со временем все равно тяготеют к классу мультивендорных решений, что требует управления рисками совместимости уже на этапе сотрудничества двух вендоров. 3. Мультивендорные. Полнофункциональные решения такого типа сейчас на российском рынке встречаются крайне редко, в основном касаются интеграционных аспектов. Примером такого решения может служить совместное внедрение ИБ-, ИТ- и АСУ-ТП-решений, одно из которых в силу своего объединяющего значения (например, SIEM) предполагает совместимость всех продуктов с этой системой. Таким образом, вендоры заявляют поддержку интеграции с данной системой своих продуктов (в случае с SIEM адаптируют под нее события безопасности своих систем). По типу решений 1. ИБ – ИБ. Экосистема реализуется, как правило, двумя или более вендорами – производителями СЗИ. Примером может служить применение IDS-решений совместно с однонаправленными шлюзами, интеграция между МСЭ и комплексными решениями по защите (центрами управления, антивирусами, DLPсистемами по протоколам ICAP и др). Несмотря на часто встречающиеся конкурентные области, такие экосистемы далеко не редкость на российском рынке. 2. ИБ – АСУ ТП (MES, ERP). Два или более вендора СЗИ и средств автоматизации технологических процессов, планирования и учета готовят экосистему для защиты определенных классов систем, сетевых сегментов, определенных типов пользователей, субъектов или объектов. Такие решения, как правило, имеют и отраслевую специфику, то есть учитывают особенность функционирования объекта в той или иной отрасли экономики (ТЭК, транспорт, генерация, добыча, металлургия, ВПК и др). Примером таких экосистем является совместимость конкретных SCADA-, OPC-, MES-, ERP-, Historian-систем с промышленными МСЭ-, IDS-системами, решениями по передаче данных указанных систем через однонаправленные шлюзы в менее доверенные сетевые сегменты. 10 • В ФОКУСЕ Экосистемы ИБ-решений в России: типы и уровни зрелости ермин "экосистема" активно используется в профессиональном ИБ-сообществе: все чаще звучат призывы двигаться к построению комплексных и полнофункциональных экосистем и решений в области ИБ, а также к их совместимости с иными классами решений. Между тем сама суть термина не определена Т и понимается многими участниками дискуссий интуитивно. Вячеслав Половинко, руководитель направления собственных продуктов АМТ-ГРУП Фото: АМТ-ГРУП
3. ИБ – ИТ. Два или более вендора СЗИ и ИТ-продуктов реализуют решения по взаимной совместимости в целях поддержки безопасного функционирования ИТ-решений и повышения уровня защищенности ИТ-инфраструктуры в целом. Примерами такой экосистемы являются совместные решения по виртуализации с дополнительными наложенными СЗИ, решения для банковского сектора по интеграции специализированных систем с однонаправленными шлюзами, решения по интеграции СКДПУ с элементами ИТ-инфраструктуры корпоративной сети, решения DCAP c конкретными версиями поддерживаемых операционных систем. По классу решений 1. ПО – ПО. Наиболее часто встречающийся вариант формирования экосистемы в силу большего присутствия на российском рынке именно программных СЗИ. Указанные выше примеры в большинстве своем демонстрируют именно такой подход к расширению экосистемы. 2. Аппаратные решения – ПО. Вариант совместной реализации, при которой вендоры ИБ и производители аппаратных решений реализуют и предлагают рынку доверенные ПАК, комплексы по физической изоляции сетевого периметра (однонаправленные шлюзы), кастомные платформы для реализации МСЭ в случае, когда производитель аппаратной платформы предоставляет серверную реализацию, а производитель СЗИ (ПО) использует ее для формирования итогового решения, проводит сертификацию и осуществляет дальнейшее внедрение и поддержку. Вне указанной выше типизации хотелось бы выделить наличие комплексных экосистемных решений, включающих систему организационных мер и нормативных требований, дополненную конкретными СЗИ. Такие решения, как правило, но далеко не всегда, формируются одним вендором и учитывают требования законов, касающихся защиты ОПО, КИИ, а также приказы профильных регуляторов, соответствие отраслевым стандартам. Речь в таких решениях идет о соответствии некоторым лучшим организационно-техническим практикам, международным и отечественным стандартам. Например, в таком типе экосистем речь может идти о предложении производителям СЗИ средств статического, динамического анализа кода, фаззинг-тестирования. Такие решения позволяют конечному вендору СЗИ полноценно реализовать принципы DevSecOps или SecurebyDesign и далее предлагать заказчикам продукты, которые подкреплены поддержкой стандартов и процессов в области ИБ. Прежде всего такие экосистемные решения встречаются в SOAR, SIEM и др. Экосистемы ИБ-решений имеют различия имеют не только по типам и классам взаимодействующих в них средств и решений, но и характеризуются разным уровнем зрелости. 1. Функциональный. На данном уровне подтверждается функциональная совместимость решений, фиксируется возможность совместного применения и отсутствие ф у н кц ион а л ьн ы х ошибок. Этот уровень экосистемы характерен для случая, когда вендор ИБ только выводит продукт на рынок либо информирует рынок о новых доступных сценариях совместимости. Такое информирование необходимо, чтобы специалисты ИБ при планировании проектов, а также проектировании комплексных ИБ-систем и систем защиты могли учитывать существующие тренды в отрасли и потенциальные возможности применения СЗИрешений в ближайшем будущем. 2. Подтверждение производительности и надежности. На данном уровне подтверждаются показатели надежности и производительности решений в составе экосистемы: фиксируются тайминги и детали поддержки конкретных протоколов, например в случае с однонаправленными шлюзами – это поддержка передачи протоколов семейства IEC в энергетике с учетом заданных ограничений передачи сигналов. Такой уровень развития экосистемы решений характерен для случая, когда фиксируется четкая потребность рынка в необходимости конкретных решений, но заказчики требуют достоверных данных о производительности решений и их соответствии параметрам функционирования конечных объектов, на которых предполагается внедрение СЗИ и смежных решений. Такой уровень экосистемы характеризуется тем, что многие решения проверяются уже совместно с экземплярами ПО заказчиков или непосредственно в рамках пилотных зон и проектов заказчиков. 3. Референсные архитектуры и модели. На таком уровне зрелости экосистемы решений ИБ фиксируются уже отработанные, функционально и производительно проверенные архитектуры, которые могут быть референсно предложены заказчику в виде апробированного комплекса решений. Причем могут выделяться архитектуры экосистем для разных отраслей экономики, учитывающие конкретную специфику внедрения и применения. В ряде случаев на данном этапе уже существует несколько примеров успешных внедрений, на которые производители могут ссылаться для демонстрации отраслевого опыта. 4. Отраслевой опыт реализации. Такой уровень зрелости экосистемы наступает, когда вендоры и их экосистема имеют массовое применение в той или иной отрасли и их архитектуры вполне могут рассматриваться как эталонные для применения и распространения, в том числе в случае, когда такие экосистемы и их архитектуры с минимальными изменениями могут переноситься на предприятия и организации других отраслей экономики (например, из добычи в металлургию, переработку, из финансового сектора в ритейл и т.п.). Большая часть производителей сегодня в рамках построения экосистем ИБ прошла первый уровень зрелости и находится на втором или третьем уровне, реализуя уже готовые и проверенные архитектуры на предприятиях и в организациях. Лишь небольшая часть – как правило, это характерно скорее для моновендорных экосистем – перешли к четвертому уровню и полноценно тиражируют свои экосистемные решения в рамках одной из отраслей или даже из отрасли в отрасль. Но наблюдаемая в отношении экосистемных ИБ-решений тенденция очевидна: стимулируемые рынком и требованиями регуляторов производители СЗИ и иных классов решений движутся к формированию устойчивых и проверенных типовых архитектур и экосистем, которые приходят на замену архитектурам, предлагавшимся рынку зарубежными вендорами в период их активного присутствия. Срок такой полноценной замены, без учета элементной базы, ПЛК, серверного оборудования, займет не менее трех лет. l • 11 КИИ www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ АМТ-ГРУП см. стр. 70 NM Реклама Фото: playground.com
Провести категорирование субъектам КИИ не самая сложная задача, если на нее есть время. А если есть еще и средства, то можно вообще ее не замечать. Но если об этом вспомнили внезапно (или того хуже – пришло срочное уведомление от регулятора), да еще и ресурсов на решение проблемы не слишком много, то важно все грамотно спланировать и сразу знать о нюансах, чтобы не терять время на них в процессе. Трудности категорирования В 2019 г. представители ФСТЭК говорили о том, что в России насчитывается до полумиллиона субъектов КИИ. Многие организации не считают себя субъектами КИИ, поэтому не выполняют требования, предъявляемые регулятором к этой категории. Усложняет дело информационное сообщение ФСТЭК России1 о том, что об отсутствии объектов КИИ или о том, что организация не является субъектом КИИ, уведомлять не надо. Главное, что нужно сделать каждому субъекту КИИ после того, как организация убедилась в этом статусе, – самостоятельно определить перечень своих объектов и провести их категорирование, в результате чего каждому объекту присваивается категория значимости либо обосновывается ее отсутствие. Это двухэтапный процесс. Оба этапа должны выполняться специальной комиссией, которую многим субъектам составить не из кого, так как зачастую в организации работает всего пять человек – еще одна трудность категорирования заключается в отсутствии людских квалифицированных ресурсов как в штате, так и на рынке. Процесс категорирования регламентируется 127 ПП РФ; основные шаги перечислены общими фразами, часть пунктов дана в виде рекомендаций и примеров, в которых не так просто разобраться, не будучи погруженным в контекст законодательства. Необходимо учитывать не только постановление правительства, но и положения 187-ФЗ и отдельных приказов ФСТЭК России, утверждающих, в частности, формы предоставления сведений. Без специальных знаний здесь не обойтись. Допустим, вам удалось решить проблему с кадрами. Далее необходимо выбрать технологические и бизнес-процессы. У крупных организаций это не вызывает сложностей. Небольшим субъектам потребуется понимание того, насколько детально надо прорабатывать классификаторы процессов или где это можно подсмотреть. Подобные трудности возникают почти на каждом шагу категорирования, вплоть до отправки документов во ФСТЭК России. Упомянутые трудности приводят к тому, что процесс затягивается. В настоящее время, по оценке RTM Group, не более 50% субъектов выполнили категорирование, не более 25% из них выполнили его корректно. Примерные оценки все же позволяют судить о масштабе проблемы: половина критической инфраструктуры в стране еще не категорирована, а это более 200 тыс. субъектов. Автоматизация в помощь Для того чтобы помочь субъектам КИИ справиться с требованиями регуляторов, на рынке есть специальные программы, при помощи которых можно разобраться с перечнем документов и пройти пошагово основные процедуры. Такие средства автоматизации применяются либо крупными компаниями, которым необходима работа в команде, либо мелкими фирмами, ищущими в платформах уровень компетенций. Сегодня подобный функционал можно обнаружить у таких сервисов, как SECURITM, АЛЬФА ДОК, MEDOED, НОТА КУПОЛ. Все они предлагают решить задачу категорирования по-разному, но заявляют о своем функционале автоматизации комплаенса по 187-ФЗ. Есть все основания полагать, что в ближайшее время будет всплеск интереса к таким инструментам: категорирования избежать не получится. Платформы автоматизации создаются, как правило, при поддержке экспертов в области ИБ и содержат обобщение не только нормативки, но и практики, например: l методики расчета (в частности, экономических показателей значимости); l нормативные классификаторы (ОКВЭД, БДУ, способы взаимодействия с сетями электросвязи); l экспертные классификаторы (бизнеси технологические процессы, обоснования неприменимости показателей значимости). Как правило, подобные платформы также предлагают элементы проектирования систем защиты, начиная от моделирования угроз и заканчивая обработкой выводов сканера уязвимостей. Однако для того, чтобы пользоваться ими эффективно, нужен некоторый опыт. Если нет квалифицированного специалиста, который разбирается в процессе категорирования и предъявляемых требованиях, процесс может затянуться. Сейчас мы поговорим о том, как можно справиться с задачами в условиях ограниченного времени. Категорирование за полгода Итак, в каких ситуациях начальнику службы информационной безопасности/системному администратору/юристу может понадобиться провести категорирование за полгода? Законодательно установлено ограничение на категорирование: один год с момента утверждения перечня объектов. Нельзя просто взять и откатегорировать свою 1С, надо еще внести ее в список. Для большинства субъектов срок в один год более чем достаточен, поэтому мы вообще не будем его рассматривать. В качестве самого простого варианта рассмотрим категорирование за полгода. Первое, что необходимо сделать, – создать комиссию в произвольной форме. Крайне желательно, чтобы ее 12 • В ФОКУСЕ Категорирование по-хорошему: за полгода, за квартал, за месяц ак с минимальными потерями провести категорирование КИИ, если у вас на него есть полгода, три месяца или три Кнедели? Федор Музалевский, директор технического департамента RTM Group Фото: RTM Group 1 https://fstec.ru/dokumenty/vse-dokumenty/informatsionnye-i-analiticheskie-materialy/informatsionnoe-soobshchenie-fstek-rossiiot-17-aprelya-2020-g-n-240-84-611
участники действительно были в курсе, какие обязанности на них возложены. В состав комиссии необходимо включить главного безопасника (информационной безопасности, а не физической), того, кто работает с системами (админа той же 1С), и представителя руководства компании. Дополнительно можно добавить кого угодно, даже подрядчика. Создание комиссии, если делать это без опыта и как следует, может занять до месяца, тогда пять месяцев останется на сам процесс. Следующий этап: составление перечня объектов КИИ. Важно учесть отраслевые перечни и постановление правительства № 127. Если не вдаваться в подробности, процесс для пары десятков объектов у исполнителя, как правило, занимает пару месяцев, особенно если компания, относящаяся к субъектам КИИ, территориально распределена. Третий этап: переход непосредственно к категорированию, которое включает в себя инвентаризацию серверов, рабочих мест, софта и прочего, что используется при работе объекта КИИ, а также расчет показателей значимости. На это может уйти около трех месяцев при условии, что исполнитель за предыдущие два познакомился со всеми, кто отвечает за работу условной 1С, АСУ ТП и всех остальных объектов. Важно назначить на это направление сотрудника, обладающего хорошими коммуникативными навыками. Итак, уложиться в полгода для среднего субъекта КИИ вполне реально без привлечения подрядчика, автоматизации и т.д. Причем из затрат будут только расходы на сотрудника, который этим будет заниматься, и накладные расходы на печать и отправку итоговых документов (ФСТЭК России принимает только бумагу и диски – никакого электронного документооборота). За три месяца В какой ситуации на категорирование может быть только три месяца? Чаще всего в одном из четырех перечисленных ниже случаях: 1. Вы пришли на новую работу, а там срок уже установлен до вас и заканчивается через три месяца. 2. Есть требование от регулятора или партнера по бизнесу уложиться в срок. 3. Руководство не совсем понимает трудоемкость и просто ставит задачу и срок, исходя из своих представлений. 4. Вы откладывали решение задачи, пока не осталось три месяца. Итак, что можно и нужно сделать? Во-первых, надо обзавестись материалами, а в идеале – советником. Как раз он и подскажет, кого включить в состав комиссии по категорированию, как донести до них значимость процесса и пр. Однако консультант – это дополнительные расходы, не менее 100 тыс. руб. Во-вторых, можно подумать об автоматизации процесса. О специально предназначенных для решения подобных задач сервисах мы рассказывали выше – попробуйте выбрать себе подходящий инструмент. Они в той или иной форме, более подробно, менее детально, но проводят по основным шагам. Не имея опыта и специальных знаний с подсказками специального ПО, в котором предусмотрена бесплатная версия, можно будет уложиться с первым объектом в месяц, ведь даже с подсказками все равно придется потрудиться над перечислением актуальных угроз и т.д. Но, например, другие десять объектов мы будем обрабатывать по одному в день, по аналогии с предыдущим. И так легко уложимся в три месяца. За… месяц?! Ну и самая сложная задача – категорирование за месяц. Обычно она возникает из-за перегрузки задачами специалиста, ответственного за категорирование, по недосмотру начальства или изза "попадания" на проверку прокуратуры. Отдельные письма ФСТЭК России также заставляют ускоряться до нескольких недель. Роль лица, на которое возложена ответственность за выполнение данных работ, незавидна, особенно если опыта в этом нет и иные задачи никто не снимал. Итак, в первую очередь необходимо заручиться поддержкой высшего руководства и соответствующими полномочиями – для создания комиссии. Чтобы всем было очевидно, что задача важна и распоряжения от ответственного за нее – приоритетны. Чтобы не возникало пререканий на местах и торможения процесса. Ну и консалтинг здесь уже не рекомендация, а скорее необходимость, ведь, не имея опыта, уложиться в срок самостоятельно практически нереально. Когда комиссия создана (рекорд в нашей практике – три часа при личном присутствии главного инженера завода), надо определиться с перечнем процессов предприятия и их критичностью. Здесь есть маленький лайфхак, который заключается в том, чтобы процессом назвать вид деятельности и указать соответствующий ОКВЭД. На полную отработку по всем уйдет несколько часов. В ряде случаев такой подход может не устроить ФСТЭК России, но даст фору по времени. Если работаете с подрядчиком и он использует такой метод, то требуйте от него согласия сопровождать вас до получения ответа из ФСТЭК России. После того как все процессы обработаны, нужно выбрать объекты для категорирования. Придется потратить неделю для пары десятков объектов – это та часть, в которой подрядчик может дать только "свободные руки", а средствами автоматизации будут формы для ввода данных. На данном этапе требуется максимальная вовлеченность представителей самого субъекта КИИ. После того как список сформирован, по правилам его необходимо отправить регулятору и ждать ответа. Но это может затянуться (от двух недель до двух месяцев), а времени нет. Что делать в такой ситуации? В принципе, хотя формально это и является нарушением, можно не отправлять список сразу, а послать его уже вместе с результатами категорирования. Итак, остается три недели на присвоение категории. Здесь автоматизация, как и подряд, уже необходимы. Исключение составляет вариант, когда работы выполняет подрядчик и он может работать сутками. Почему именно в таком цейтноте важна автоматизация? Потому, что ответы по составу систем, объему налогов, экологии и прочим моментам (а показателей значимости полтора десятка) будут поступать не в том порядке, в каком они должны вноситься в акты, и автоматизация позволит переключаться между полями ввода и не запутаться. Последнее не гарантировано, но точно лучше, чем с кучкой текстовых документов или таблиц. При цейтноте главное правило – давать тем, у кого запрашиваешь информацию, четкий срок и при нарушении сразу просить помощь руководства (помним, что мы ей заручились – иначе никак). И тогда за три недели заполнить данные вполне реально. Разумеется, в таком авральном режиме возможны ошибки и даже помощь подрядчика – не панацея. Если будет некорректно заполнена форма, за этим последует просьба уточнить сведения в десятидневный срок, а если просто забыть направить ее, то могут последовать более серьезные меры. Поэтому после отправки можно выдохнуть, но не расслабиться. Это же касается и варианта с подрядчиком. Таким образом, за полгода категорирование можно осуществить "между делом", за три месяца немного напрягаясь, и за месяц… Ну тоже завершить можно, хотя придется все делать в авральном режиме. Наш рекорд – проведение категорирования промышленного предприятия с 23 объектами (три оказались значимыми) за семь рабочих дней. Это оказалось возможным только благодаря трем условиям: 1. Вовлеченность руководства субъекта КИИ. 2. Опыт проведения подобных работ. 3. Применение базы знаний и автоматизации. Надеюсь, что в таких условиях вам работать не придется, а если такое и случится, то эти советы позволят хотя бы одной упаковке валерьянки остаться неначатой. l • 13 КИИ www.itsec.ru Ваше мнение и вопросы присылайте по адресу [email protected]
В отличие от корпоративного сегмента, где акцент, как правило, сделан на защите данных, в АСУ ТП приоритетом является обеспечение непрерывности и стабильности технологических процессов. Специфика защиты промышленного сегмента обусловлена возрастающей угрозой кибератак, направленных на нарушение его нормального функционирования. Это означает, что системы защиты АСУ ТП должны быть спроектированы с упором на минимальное воздействие на работу производства, но в то же время предоставляя эффективную защиту от возможных угроз. Применение современных антивирусных решений, а также систем мониторинга безопасности позволяет обнаруживать и предотвращать инциденты. Как раз таким решением является Dr.Web Industrial. Что делает Dr.Web Industrial Dr.Web Industrial разработан для защиты системной памяти, жестких дисков и съемных носителей компьютеров, работающих в промышленном сегменте под управлением операционных систем Windows и Linux, от угроз любого типа: вирусов, шифровальщиков, руткитов, троянских программ, шпионского и рекламного ПО, хакерских утилит и других вредоносных объектов из любых внешних источников. Одной из особенностей Dr.Web Industrial является режим функционирования, в котором обнаружение подозрительной активности не приводит к остановке непрерывного технологического процесса. Решение состоит из нескольких модулей, каждый из которых реализует свой аспект функциональности. Базовыми компонентами являются антивирусное ядро и вирусные базы, которые нетребовательны к системным ресурсам, ведь особенностью технологического сегмента является длительный срок эксплуатации и низкий темп внедрения инноваций, в результате чего там все еще много старых Windows. Одним из приоритетов для Dr.Web Industrial является поддержка старых ОС, начиная с Windows XP и Windows Server 2003. В последние годы мы также наблюдаем в отрасли постепенное смещение приоритетов в сторону импортозамещения и более широкого применения Linuxподобных систем. Полная поддержка Linux является важным приоритетом для Dr. Web Industrial. Компоненты продукта постоянно обновляются, а вирусные базы регулярно дополняются новыми сигнатурами. Для дополнительной защиты от неизвестного вредоносного программного обеспечения используются методы эвристического анализа, реализованные в антивирусном ядре. Dr.Web Industrial способен обнаруживать и удалять с компьютера нежелательные программы, включая рекламные программы, программы дозвона, программы-шутки, потенциально опасное ПО, программы взлома. Для обнаружения таких вредоносов и совершения действий над содержащими их файлами применяются стандартные средства антивирусных компонентов Dr.Web. Это базовая функциональность. Но ключевые особенности в Dr.Web Industrial формируют другие модули: l монитор файловой системы SpIDer Guard; l компонент защиты от вымогателей; l модуль поведенческого анализа. Разберем их более детально. SpIDer Guard: постоянная защита файловой системы SpIDer Guard – это монитор файловой системы, он защищает компьютер в режиме реального времени и предотвращает его заражение. SpIDer Guard стартует при загрузке ОС и проверяет все файлы при их открытии, запуске или изменении, а также отслеживает поведение запущенных процессов. Контроль мониторинга работы с файлами может быть настроен в один из трех режимов. 1. Обычный (он установлен по умолчанию), когда отслеживаются операции доступа к файлам (создание, открытие, закрытие и запуск файла): запрашивается проверка файла, доступ к которому был осуществлен, и по ее результатам, если обнаружена угроза, применяются действия по ее нейтрализации. До окончания проверки доступ к файлу со стороны приложений не ограничивается. 2. Усиленный контроль исполняемых файлов. Для файлов, не считающихся исполняемыми, мониторинг ведется в обычном режиме. Но для файлов, считающихся исполняемыми, при попытке доступа SpIDer Guard блокирует запрошенную операцию доступа до тех пор, пока не станут известны результаты проверки файла на наличие угроз. 3. "Параноидальный" режим блокирует запрошенную операцию до тех пор, пока не станут известны результаты проверки на наличие угроз. При настройках по умолчанию SpIDer Guard на лету проверяет на жестком диске только создаваемые или изменяемые файлы, но на съемных носителях проверяются все открываемые файлы. Кроме того, постоянно отслеживаются действия запущенных процессов на предмет выявления поведения, характерного для вирусов, и при необходимости блокирует эти процессы. По умолчанию SpIDer Guard запускается автоматически при каждом старте 14 • В ФОКУСЕ Dr.Web Industrial: защита серверов и рабочих станций в промышленных системах управления ункциональная роль систем автоматизированного управления технологическим процессом (АСУ ТП) на объектах критической инфраструктуры и промышленных предприятиях делает их мишенью для сложных комплексных кибератак, а также несанкционированного внутреннего вмешательства. Dr.Web Industrial предоставляет защиту серверов и рабочих станций в системах управления промышленными процессами. Ф Василий Севостьянов, начальник отдела технического сопровождения продаж ООО “Доктор Веб” Фото: Доктор Веб
операционной системы и не может быть выгружен в течение текущего сеанса работы. Входящий в состав Dr.Web Антируткит позволяет в фоновом режиме проводить проверку операционной системы на наличие сложных угроз и сигнализировать при их обнаружении. При включении данной настройки Антируткит Dr.Web будет постоянно находиться в памяти. В отличие от проверки файлов на лету, проводимой компонентом SpIDer Guard, поиск руткитов производится в системном BIOS компьютера и таких критических областях, как объекты автозагрузки, запущенные процессы и модули, оперативная память и др. Одним из ключевых критериев работы Антируткита Dr.Web является бережное потребление ресурсов операционной системы (процессорного времени, свободной оперативной памяти и др.) с учетом мощности аппаратного обеспечения. Превентивная защита от вымогателей Компонент "Защита от вымогателей" позволяет отслеживать процессы, которые пытаются зашифровать пользовательские файлы по известному алгоритму, свидетельствующему о том, что такие процессы являются угрозой безопасности компьютера. К таким процессам относятся троянцы-шифровальщики, которые блокируют доступ к данным, после чего вымогают деньги за расшифровку. Шифровальщики являются одними из самых распространенных вредоносных программ и ежегодно приносят большие убытки как компаниям, так и обычным пользователям. Основной путь заражения – почтовые рассылки, содержащие вредоносный файл или ссылку на вирус. Причем, по статистике компании "Доктор Веб", расшифровка поврежденных троянцем файлов возможна только в 10% случаев, поэтому наиболее эффективный метод борьбы с ними – предотвратить заражение. В последнее время число пользователей, пострадавших от данного типа вирусов, не только не снижается – оно увеличивается! Количество запросов в службу технической поддержки компании "Доктор Веб" на расшифровку данных идет на сотни, а иногда и на тысячи в месяц. Компонент "Защита от вымогателей" анализирует поведение подозрительных процессов, обращая внимание, в частности, на поиск файлов, чтение и попытки их модификации. Проверяются также следующие характеристики приложения: l является ли приложение новым; l как оно попало в систему; l где приложение расположено; l как оно называется; l является ли приложение доверенным; l есть ли у него действительная цифровая подпись от доверенного центра сертификации. Проверяется также характер запрашиваемой модификации файлов. При обнаружении признаков поведения вредоносной программы действия попытки модификации файлов со стороны проанализированного приложения блокируются. Превентивная защита: поведенческий анализ Компонент "Поведенческий анализ" позволяет настроить реакцию Dr.Web Industrial на действия сторонних приложений, не являющихся доверенными, которые могут привести к заражению компьютера, например на попытки модифицировать файл HOSTS или изменить критически важные ветки системного реестра. При включении этого компонента программа запрещает автоматическое изменение системных объектов, модификация которых однозначно свидетельствует о попытке вредоносного воздействия на операционную систему. Поведенческий анализ защищает от ранее неизвестных вредоносных программ, которые способны избежать обнаружения традиционными сигнатурными и эвристическими механизмами. Сигнатурный анализ и Origins Tracing В Dr.Web Industrial в качестве метода обнаружения в первую очередь применяется обычный сигнатурный анализ. Он основан на поиске в содержимом анализируемого объекта сигнатур уже известных угроз. Причем записи в вирусных базах Dr.Web составлены таким образом, что благодаря одной и той же записи можно обнаруживать целые классы или семейства угроз. Но также в решении реализован метод Origins Tracing – это уникальная технология Dr.Web, которая позволяет определить новые или модифицированные угрозы, использующие уже известные и описанные в вирусных базах механизмы заражения или вредоносное поведение. Она выполняется после сигнатурного анализа, позволяя выявить более "тонкие" угрозы. Использование технологии Origins Tracing позволяет значительно снизить количество ложных срабатываний эвристического анализатора. Применение машинного обучения Для поиска и нейтрализации вредоносных объектов, которых еще нет в вирусных базах, используется машинное обучение, причем распознавание вредоносного кода проводится без его исполнения, только на основе его метахарактеристик. Обнаружение угроз строится на классификации вредоносных объектов согласно определенным признакам. С помощью технологии машинного обучения, основанной на методе опорных векторов, происходит классификация и запись в базу фрагментов кода сценарных языков. Затем проверяемые объекты анализируются на основе соответствия признакам вредоносного кода. Технология машинного обучения автоматизирует обновление списка данных признаков и пополнение вирусных баз. Это существенно экономит ресурсы операционной системы, так как не требует исполнения анализируемого кода, а динамическое машинное обучение классификатора может осуществляться и без постоянного обновления вирусных баз, которое используется при сигнатурном анализе. Заключение АСУ ТП, как правило, оперируют в промышленных средах, где присутствуют физические узлы и компоненты, требующие специального внимания при проектировании системы защиты. Наличие специфического оборудования и технологических процессов требует особого подхода к анализу угроз и реализации мер по защите. Полностью российское решение Dr.Web Industrial учитывает эти особенности и позволяет обнаруживать подозрительную активность на серверах и рабочих станциях внутри промышленного сегмента сети, не приводя к остановке непрерывного технологического процесса. l • 15 КИИ www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ ДОКТОР ВЕБ см. стр. 70 NM Реклама Реклама 0+
– Андрей, как вы выбирали профессию, что вас привело в информационную безопасность? – Свой первый долгожданный компьютер я получил в седьмом классе. Как сейчас помню: в тот день, когда мне его купили, я шел домой и в лифте встретил какого-то мужчину, которого видел первый и последний раз в своей жизни, он на меня так посмотрел и непонятно почему сказал: "Ты, должно быть, классно разбираешься в компьютерах?". Мне показалось это совпадение очень странным и знаковым, ведь я как раз шел знакомиться со своим первым компьютером. В детстве все ощущения воспринимаются чуть ярче, чем во взрослой жизни, поэтому эта встреча наложила какой-то особый отпечаток на мой последующий выбор. К девятому классу я уже осознал, что дальше мне интересно будет заниматься именно компьютерными технологиями, но чем конкретно, на тот момент еще плохо понимал. Мне нравилось разрабатывать какие-то совсем простенькие программы на Visual Basic, что-то еще... Но уже тогда мне было ясно, что информационная безопасность – это трендовая область, потому что компьютеризация будет развиваться, все будет цифровизироваться. Это было видно и по государственным учреждениям, где всё больше и больше документы переводили с бумаги в цифру. В тот же год, в девятом классе, я определился с вузом, решил, что буду поступать в МИФИ. Наша школа достаточно активно с ними сотрудничала, и там как раз была кафедра информационной безопасности. Я целенаправленно готовился к поступлению только на эту кафедру и даже больше никуда не подавал документы. – У вас какая-то математическая школа была? – Нет, школа была обычная, но класс физико-математический. – С чего начался ваш карьерный путь? – Это достаточно интересная история. Учась на старших курсах, я успел поработать, постажироваться, в одном крупном российском банке. Не буду уточнять в каком, потому что история закончилась не очень хорошо, и вот почему: после стажировки я должен был оформиться в штат, пройдя собеседование у HR. Одним из вопросов, который мне задавали, был "Есть ли у вас сторонний проект?". Поскольку я интересовался программированием всегда и до сих пор продолжаю программировать в свободное время, то я ответил, что да, есть, и тут же увидел, как они изменились в лице. С того момента они мне не перезвонили, то есть я не попал в штат этого банка. Не могу сказать, что долго переживал, потому что не уверен, что мне было бы там комфортно, потому что там высокий уровень бюрократии – одна служебка, чтобы оформить какой-нибудь доступ, обрабатывается месяц; безопасников все не любят – без исключения. – В Авито у вас больше возможностей для творчества? – Безусловно. Я пришел в компанию в декабре 2014-го, до этого два года самостоятельно изучал различные языки программирования, фреймворки и технологии разработки и начал работать здесь middleразработчиком, девять месяцев писал на Python, пока руководитель не сказал: "Видел у тебя 16 • В ФОКУСЕ Мы добилсь почти нулевого false positive на WAF ндрей Усенюк, руководитель по информационной безопасности Авито, рассказал, как выстроить эффективную инфраструктуру безопасности и при чем тут Web Application Firewall, а также о том, как выбрать и “приручить” свой WAF, чтобы снизить риски атак А и утечек данных. Андрей Усенюк, руководитель по информационной безопасности Авито Фото: Юлия Полушкина
Мы используем подход secure by design и стремимся к тому, чтобы требования по безопасности закладывались в новые сервисы еще на этапе их проработки, до момента написания первой строчки кода. Из всех продуктов, которые мы посмотрели, у компании Вебмониторэкс показатель ложных срабатываний был на минимальном уровне, потому что в их платформе используется хитрая интеллектуальная система постаналитики. в резюме строчку, нам как раз нужно безопасность сделать". Тогда у Авито еще не было ни одного безопасника. Вот так, примерно с августа 2015-го, я сначала стал архитектором по информационной безопасности, а теперь занимаю позицию руководителя. – Какая архитектура безопасности сейчас выстроена в компании? – Безопасность Авито традиционно строилась на защите внешнего сетевого периметра и разделении ресурсов с разным уровнем доверия. Но незадолго до начала пандемии мы начали двигаться в сторону архитектуры Zero Trust и уже прошли часть этого пути. Внедрили персональные сертификаты для сотрудников, двухфакторную аутентификацию на всех доступных извне системах и ряд других вещей. Что касается разработки: мы используем подход secure by design и стремимся к тому, чтобы требования по безопасности закладывались в новые сервисы еще на этапе их проработки, до момента написания первой строчки кода. В этом нам помогает наша платформа, построенная на базе Kubernetes и PaaS собственной разработки, в который "зашиты" большинство наших проверок. "Выкатить" сервис мимо этих проверок просто невозможно. – Какая архитектура защиты ресурсов используется в вашем проекте и почему? Какая нагрузка на защищаемые ресурсы фиксируется вами сейчас, какой рост вы прогнозируете в ближайшие годы? – Это интересные вопросы. Сейчас мы фиксируем нагрузку порядка 9 млн внешних пользовательских запросов в минуту, в пике. Если говорить про прогнозируемую, то за последние годы мы проделали огромную работу с точки зрения повышения производительности наших продуктов, удалось добиться того, чтобы мобильное приложение, сайт не делали лишние запросы на наши сервера, поэтому за прошедший год мы не увидели огромного роста нагрузки. Если сопоставить рост пользовательской базы с трафиком, то увидим, что он не вырос, – это хороший момент, показывающий, что мы научились эффективнее использовать ограниченные ресурсы наших пользователей, мобильного Интернета и т.д. – Какие задачи вы хотели решить с помощью межсетевых экранов? Что послужило причиной внедрения этого решения? – В первую очередь нам был нужен инструмент для отслеживания атак. Думаю, что мы всегда будем использовать эшелонированную защиту, не полагаясь на какое-то одно средство, а имея несколько, на случай, если одно окажется неэффективным – выйдет из строя, например. Нам нужен был инструмент, который дополнил бы нашу систему защиты информации и позволил бы мониторить, отслеживать в реальном времени входящие на сайт запросы, какие из них вредоносные, а какие нет. И соответственно, этот инструмент должен блокировать на лету вредоносные запросы. Есть, конечно, альтернативные подходы к этой проблеме, например сетевые системы обнаружения вторжения, но поскольку наши продукты работают через веб, то в первую очередь мы обратили внимание именно на Web Application Firewall (WAF) – этот класс решений заточен под работу в таких условиях. – Каким образом вы выбирали вендора и продукт? – Несколько лет назад мы проводили достаточно крупное исследование рынка, в том числе смотрели на WAF от компании Вебмониторэкс и на несколько западных вендоров, которые считаются наиболее топовыми в этой области. Мы посмотрели четыре или пять разных продуктов, скрупулезно оценивая их: брали заведомо уязвимое приложение, разворачивали его, настраивали WAF, добавляли несколько опенсорсных списков с векторами атак, которые прогоняли относительно этого приложения, и смотрели, как то или иное решение класса WAF себя ведет, какие блокирует векторы, а какие не блокирует. Таким образом оценивались два параметра: полнота – сколько из атак каждый продукт смог найти и показать; ложное срабатывание – этот параметр мы еще дополнительно проверяли на реальном трафике, для нас это было важно, потому что Авито – сайт объявлений, где пользователи сами вводят произвольный контент. Довольно часто в этом контенте • 17 ПЕРСОНЫ www.itsec.ruФото: Юлия Полушкина
WAF, входящий в состав платформы "Вебмониторэкс", оказался оптимальным решением и с точки зрения функциональности, и с точки зрения нефункциональных требований производительности, и с точки зрения минимального количества ложных срабатываний, и с точки зрения стоимости. В нашем случае ценность внедрения решения класса WAF заключалась скорее не в оптимизации процессов или сокращении издержек, а в снижении рисков. С этой задачей WAF на платформе "Вебмониторэкс" справился. попадаются какие-то ключевые слова, которые WAF считает атакой, – важно, чтобы процент ложных срабатываний был минимальным. Из всех продуктов, которые мы посмотрели, у компании Вебмониторэкс показатель ложных срабатываний был на минимальном уровне, потому что в их платформе используется хитрая интеллектуальная система постаналитики, которая позволяет отсеивать большую часть ложных срабатываний. Помимо всего прочего, мы оценивали производительность, поскольку ресурс высоконагруженный – 9 млн запросов в минуту, необходимо, чтобы нагрузка на каждый из серверов, которые фильтруют трафик, не превышала определенный порог. В итоге WAF, входящий в состав платформы "Вебмониторэкс", оказался оптимальным решением и с точки зрения функциональности, и с точки зрения нефункциональных требований производительности, и с точки зрения минимального количества ложных срабатываний, и с точки зрения стоимости. – На этапе внедрения были какие-то сложности, которые пришлось решать параллельно? Как реагировала команда компании Вебмониторэкс на это? – У нас была и до сих пор остается специфичная конфигурация. Платформа "Вебмониторэкс" из коробки работает по принципу "есть веб-сервер, в который встраивается его модуль, а рядом на этом же физическом сервере должна находиться постаналитика, которая перерабатывает эти данные". Нам такая конфигурация не очень подходила, потому что мы придерживаемся очень четкого функционального разделения: один сервер должен выполнять одну функцию. Поэтому нужно было постаналитику с этого сервера вынести на отдельный сервер; учитывая наш масштаб, получается кластер серверов. На тот момент это была новая конфигурация для вендора, которую никто из их клиентов не использовал. Соответственно, они специально под нас "допилили" свой продукт, сделав возможным разнесение отдельных узлов. И сделали довольно быстро. До сих пор, положа руку на сердце, могу сказать, что ребята очень быстро реагируют на любые другие наши запросы. В основном мы скидываем им фолзы, для того чтобы они поправили в правилах, но и по функциональным темам тоже. – Насколько сложно проходило пилотирование внедрения платформы, какие процессы, отделы были задействованы? – Во внедрении участвовал отдел информационной безопасности, были активно вовлечены системные администраторы, поскольку продукт интегрируется глубоко в нашу платформу, наш балансировщик трафика – важный элемент инфраструктуры. На каждом этапе нам помогали и формировали требования, так как дальше им предстояло поддерживать этот продукт. Сейчас полностью справляемся сами, мы расширили отдел, наняв сисадминов и аналитиков, которые работают с интерфейсом платформы "Вебмониторэкс", поэтому другие отделы в эксплуатации не задействуем. – Как вы оцениваете результаты внедрения, удалось ли оптимизировать процессы и сократить издержки? – В первую очередь мы внедряли решение класса WAF, чтобы мониторить и блокировать вредоносные запросы – с этим WAF от компании Вебмониторэкс прекрасно помогает. Мы каждый день отслеживаем несколько тысяч, если не сотен тысяч, блокируемых вредоносных запросов. Вторая важная задача, которую мы решали, – это виртуальный патчинг. Поскольку достаточно часто в коробочных версиях программного обеспечения обнаруживают уязвимости, для которых нет патча, то, чтобы быстро снизить риск, не ожидая патча от вендора, мы используем виртуальный патчинг, исправляя найденную уязвимость быстрее. И последнее, специфичное для Авито, поскольку классифайд – это большая часть информации от пользователя, которую он вводит публично, но не только: есть, например, и внутренние идентификаторы пользователей, которые нам очень не хочется "светить" ни в коем случае, и мы воспользовались платформой "Вебмониторэкса" для того, чтобы такие ситуации отслеживать. Мы создавали в базе данных какие-то "канареечные" объявления пользователей, конкретные идентификаторы которых мы знали, а потом просто смотрели в исходящем трафике, видит ли WAF от компании Вебмониторэкс эти строки. Как только он их находил, мы понимали, что в этом месте может быть потенциальная утечка. Так он нам несколько раз помог. В нашем случае ценность внедрения решения класса WAF заключалась скорее не в оптимизации процессов или сокращении издержек, а в снижении рисков. С этой задачей WAF на платформе "Вебмониторэкс" справился. – Как внедрение повлияло на другие элементы инфраструктуры? – Наша инфраструктура изначально заточена под максимальную отказоустойчивость и производительность. Мы не допускаем ситуацию, в которой какойто функциональный узел инфраструктуры существовал бы в единственном экземпляре, это всегда кластер, всегда несколько таких экземпляров. И WAF не исключение. Платформа "Вебмониторэкс" предоставляется в виде модуля для веб-сервера Nginx, который мы активно используем. Соблюдая политику кластеризации, мы этот модуль внедрили на каждый из более сотни балансировщиков трафика. Благодаря гибкости продукта "Вебмониторэкс" был доступен наиболее естественный способ интеграции, чему мы очень рады. Если бы архитектура платформы была другой, то для нас внедрение прошло бы гораздо сложнее. Некоторые вендоры настаивали на том, что они предоставляют коробочную версию своего продукта либо вообще не программный продукт, а продукт на основе оборудования – ставьте его в свой дата-центр либо раскатывайте на отдельные сервера и через него весь трафик пропускайте. Для нас это было крайне неудобно, появлялись дополнительные затраты и точки отказа. С платформой "Вебмониторэкс" мы справились с задачей довольно быстро, каких-то проблем у нас с ней не возникло, просто появился дополнитель18 • В ФОКУСЕ
И я лично, и ребята из моей команды довольны поддержкой компании Вебмониторэкс, которая всегда оперативно реагирует на вопросы, учитывает пожелания и погружает нас в собственные планы, чтобы мы как клиенты понимали, куда они планируют развивать свою платформу, в какие сроки и как в этих планах учитываются наши потребности. ный модуль и очень небольшие изменения в конфигурации самого веб-сервера, поэтому внедрение прошло максимально просто. – Каким образом внедрение WAF позволило изменить уровень безопасности? – Как я уже упоминал, вопервых, мы успешно решили поставленные три задачи, что позволило снизить риски внешних атак. Сейчас WAF переведен в режим блокирования, то есть мы не просто отслеживаем и видим, кто нас атакует, но еще и эффективно боремся с атаками, блокируя запросы. Во-вторых, мы снизили риск утечек. И хотя сейчас мы используем для борьбы с утечками собственное внутреннее решение, тем не менее на момент внедрения WAF от компании Вебмониторэкс позволил снизить риски и защитить пользователей от мошенников за счет того, что парсеры потеряли некоторые возможности получения информации с нашей площадки. – Почему вы могли бы порекомендовать использовать платформу "Вебмониторэкс"? – На Авито, в силу специфики, находится огромное количество произвольного пользовательского контента – для большинства решений класса WAF на рынке, которые мы смотрели, это проблема. Потому что, как ни странно, часто в названиях коммерческих продуктов встречаются слова, которые содержатся и в векторах атак. У нас даже была подборка странных вещей, которые люди продают на сайте и на которые при этом Web Application Firewall триггерится, считая атакой. Для подавляющего большинства программных продуктов такая ситуация была проблемой, потому что у них не оказалось гибкости системы постаналитики, которая есть у платформы "Вебмониторэкс". С WAF компании Вебмониторэкс у нас порядка всего лишь 5–6 фолзов в неделю при трафике 9 млн запросов в минуту – это очень хороший результат. По данной причине это одно из немногих решений такого класса, которое вообще можем позволить себе использовать. И я лично, и ребята из моей команды довольны поддержкой компании Вебмониторэкс, которая всегда оперативно реагирует на вопросы, учитывает пожелания и погружает нас в собственные планы, чтобы мы как клиенты понимали, куда они планируют развивать свою платформу, в какие сроки и как в этих планах учитываются наши потребности. – Какие изменения в ИТландшафте Авито планируются в ближайшие несколько лет? – У нас есть пятилетняя стратегия развития информационной безопасности в компании. Из ключевых вещей, о которых можно и стоит рассказать: мы сейчас много инвестируем в Zero Trust. Не потому что это модный подход на рынке, про который все говорят, а потому что это действительно работающая технология. Особенно с момента начала пандемии, когда сильно увеличилось количество людей, работающих на удаленке. Zero Trust – один из главных фокусов нашей компании. С точки зрения внутренней инфраструктуры у нас появилась межсервисная аутентификация, авторизация, двухфакторная аутентификация в большинстве точек входа в инфраструктуру, а также появилась аутентификация сотрудников по сертификатам. В общем, появилось достаточно много пререквизитов для Zero Trust. Второе важное направление – Secure by Default. Как мы это пониманием? Для любого нового внедряемого компонента, будь то микросервис или коробочный продукт, у нас должны быть готовые требования по безопасности, которые любой разработчик, инженер может почитать и реализовать, не приходя за консультацией. Кроме того, у нас должна быть возможность автоматически проверять, что эти требования – мы их называем baseline – выполняются по всей инфраструктуре. Это позволит сильно повысить уровень безопасности и готовность к разным непредвиденным угрозам в будущем. l • 19 ПЕРСОНЫ www.itsec.ruФото: Юлия Полушкина Ваше мнение и вопросы присылайте по адресу [email protected]
Что нового в регулировании С начала 2022 г. многие российские компании столкнулись2 с беспрецедентным количеством кибератак на свою инфраструктуру. Первым полноценным документом в ответ на этот вызов стали "Критерии для принятия решения по обновлению критичного ПО, не относящегося к Open Source"3 Национального координационного центра по компьютерным инцидентам (НКЦКИ). Всего пять лет назад история о закладке в патче или в обновлении программного обеспечения могла показаться мифом. Сегодня же пользователи в России могут быть отключены от любого обновления или патча ПО по территориальному признаку. Поэтому НКЦКИ, в частности, отмечает4 следующее: l приведенный в документе алгоритм, призванный помочь специалистам принять решение об обновлении, является рекомендацией; l применяя алгоритм, нужно обязательно учитывать контекст организации: рекомендуемые решения подходят не для всех случаев; l ПО перед обновлением в продуктивной среде должно быть проверено на корректную работоспособность в тестовом сегменте; l если возможно препятствовать эксплуатации уязвимости наложенными средствами защиты, производить обновление не рекомендуется; l если специалисты в состоянии проверить обновление ПО на наличие недекларированных возможностей, то следует принимать решение по результатам собственного анализа; l не рекомендуется применять этот алгоритм для обновления ПО в АСУ ТП и мобильных ОС. Следующим важным документом стала "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств"5 Федеральной службы по техническому и экспортному контролю (ФСТЭК) России от 28 октября 2022 г. Главное отличие этой методологии – появление уникального идентификатора инфраструктуры, который указывает на частный уровень опасности уязвимостей, потому что у всех компаний есть неповторимые особенности, как у людей – отпечатки пальцев. Еще один важный документ – "Руководство по организации процесса управления уязвимостями в органе (организации)"6 издан ФСТЭК 17 мая 2023 г. Это уже полноценная методика, которая помогает рассчитать уровень опасности уязвимостей на основании предыдущего методического документа и определить срок и методы их устранения с учетом смежных процессов. (Не)уязвимое ПО Ключевой нюанс, отличающий процесс управления уязвимостями в России от VM в других странах, – массовое импортозамещение. В отличие от мировой практики российские разработчики редко публикуют информацию об уязвимостях, найденных в своем ПО. При этом многое в процессе управления уязвимостями приходится пересматривать "на живую". Например, в связи с тем, что злоумышленники часто угрожают корпорациям уничтожением инфраструктуры, последние не могут себе позволить ждать появления патча от вендора. В подобных случаях при появлении уязвимости на периметре нужно четко и быстро среагировать, принять компенсирующие меры. Многие отечественные разработчики ПО после получения сертификата ФСТЭК России считают свой продукт неуязвимым. Однако и в таких системах могут быть найдены уязвимости нулевого дня (0-day) – нужно не только оперативно устранять их, но и публиковать информацию для клиентов. При использовании в продукте решений Open Source или общедоступного инструмента клиенты также должны получить инструкции по устранению проблем. Некоторые виды ПО базируются на ядрах популярных Linux-систем, например Debian, CentOS, FreeBSD и RHEL. И тут возникает вопрос: что делать с их уязвимостями? Ведь операционная система переработана и уже отличается от той первоначальной, которую брали за основу. Можно просто взять известные уязвимости исходной ОС и начинать публиковать информацию о том, что есть и у ответвленного проекта (форка), но из-за изменений в системе не все недостатки будут совпадать. Что учесть в 2024 году Злоумышленники рано или поздно изучат уязвимые решения, обнаружат в них 0-day, а затем продадут информацию на черном рынке или будут использовать ее в целенаправленных атаках. Производители, которые не публикуют данные об уязвимостях и не выпускают обновления безопасности, усугубляют ситуацию. 20 • СПЕЦПРОЕКТ Управление уязвимостями в 2024 году: что изменилось и как перестроить процесс правление уязвимостями (Vulnerability Management) – важный аспект информационной безопасности. На первый взгляд, процесс стандартный везде: ведь злоумышленники, уязвимости программного обеспечения, неверно выстроенный патч-менеджмент есть повсюду. Однако в условиях всплеска числа кибератак, ухода зарубежных вендоров, импортозамещения ПО и обновления нормативно-правовой базы у процесса управления уязвимостями в России есть ряд важных особенностей. Разберем их и расскажем, как MaxPatrol VM1 помогает выстраивать процесс управления уязвимостями в компаниях с учетом этих нюансов. У Павел Попов, лидер продуктовой практики MaxPatrol VM, Positive Technologies Фото: Positive Technologies 1 https://www.ptsecurity.com/ru-ru/products/mp-vm/ 2 https://www.ptsecurity.com/ru-ru/research/analytics/cybersecurity-threatscape-2022/ 3 https://safe-surf.ru/upload/ALRT/ALRT-20220415.1.pdf 4 https://safe-surf.ru/specialists/news/678042/ 5 https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-28-oktyabrya-2022-g-2 6 https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-17-maya-2023-g
Эксперты Positive Technologies рекомендуют вендорам сотрудничать с исследователями безопасности, на раннем этапе анализировать код своих продуктов с помощью специальных средств и выстроить процесс поиска уязвимых мест в ПО. После обнаружения уязвимостей необходимо разработать патч, присвоить им идентификаторы (согласно CVE7 и (или) базе данных угроз ФСТЭК8 ) и опубликовать эту информацию. Если в конечном продукте используются решения Open Source, нужно сообщить о наличии или отсутствии в нем уязвимостей, чтобы клиенты смогли сосредоточиться на устранении реальных угроз. Даже если у производителя есть сильная команда ИБ, это не гарантия защиты от взлома. Вендору нужно постоянно проверять свою защищенность, используя предназначенные для этого системы и привлекая внешних исследователей. В идеале каждый производитель ПО должен запускать программы багбаунти, чтобы тестировать свою инфраструктуру, процесс выпуска ПО и конечные продукты. Такие программы помогут обнаружить уязвимости еще до начала реальных атак и защитить клиентов. Можно использовать решения Open Source или простые сканеры уязвимостей, если устраивает экспертиза и точность детекта. Но в случае последних компания должна быть готова выстраивать процесс еще в нескольких системах. Мы же рекомендуем переходить к построению результативной безопасности и использовать системы Vulnerability Management, например MaxPatrol VM9 . Продукт анализирует информацию об уязвимостях и выявляет трендовые, наиболее опасные для компании. Данные о них мы доставляем в MaxPatrol VM в течение 12 часов, что позволяет своевременно принять меры и защитить инфраструктуру компании. l Эксперты Positive Technologies проанализировали собственный опыт взаимодействия с вендорами в области раскрытия уязвимостей. Так, в 2022–2023 гг. 57% вендоров оперативно отвечали исследователям компании, при этом только 14% всех производителей программного обеспечения выпускали обновления в оптимально короткие сроки. Впервые обнаруженные недостатки безопасности, о которых производитель ПО не знает и для которых еще не существует исправлений, называются уязвимостями нулевого дня. Как только вендор узнает о таком недостатке, становится крайне важно своевременно выпустить исправление, поскольку задержки позволяют злоумышленникам все чаще эксплуатировать такие уязвимости в своих атаках. Число обнаруженных уязвимостей постоянно растет: в 2023 г. их количество (28 902) превысило показатели предыдущих двух лет на 42% и 14% соответственно. Кроме этого, каждый взлом и утечка обходятся бизнесу все дороже: средняя стоимость утечки, по данным IBM, за последние три года выросла на 15%, достигнув $4,45 млн. В связи с этим особое значение для укрепления защиты приобретает построение доверительных и прозрачных отношений между поставщиками ПО и исследователями ИБ. Промедление в ответственном раскрытии информации об уязвимостях чревато и ростом числа атак на цепочки поставок: за первые три квартала 2023 г. количество инцидентов, вызванных атаками подобного типа, выросло в два раза по сравнению с показателями за весь 2022 г. Positive Technologies придерживается принципов координированного раскрытия в случае обнаружения уязвимостей в продуктах вендоров. При таком формате ответственного разглашения в процессе участвуют не только исследователи и производитель ПО, но и регуляторы, и организации, которые выступают посредниками во взаимодействии с поставщиками. Основные проблемы при реализации принципов ответственного разглашения – недостаточная структурированность процессов взаимодействия вендоров с исследователями, а также непостоянство и задержки в отклике на сообщения о найденных уязвимостях. Специалисты Positive Technologies считают, что оптимальное время ответа вендора составляет от одного дня до недели: в такие сроки исследователям компании смогли ответить 57% вендоров. Эксперты рекомендуют вендорам придерживаться профессионального подхода: следовать политике ответственного разглашения, доверять исследователям безопасности и поддерживать с ними активную коммуникацию, информируя о каналах связи. Кроме того, специалисты советуют производителям ПО выпускать обновления безопасности и сообщать об этом в кратчайшие сроки, достойным образом поощрять исследователей за нахождение уязвимостей, чтобы мотивировать их к продолжению эффективного сотрудничества. Компаниям – пользователям ПО, в свою очередь, рекомендуется выстроить процесс управления уязвимостями, используя системы, предоставляющие информацию о трендовых уязвимостях (которые важно устранять в первую очередь); так, система MaxPatrol VM предоставляет такие данные в течение 12 часов. l • 21 Управление Уязвимостями www.itsec.ru Только 14% вендоров оперативно исправляют уязвимости, найденные исследователями безопасности Рис. 1. Схема работы работы MaxPatrol VM АДРЕСА И ТЕЛЕФОНЫ POSITIVE TECHNOLOGIES см. стр. 70 NM Реклама 7 https://cve.mitre.org/ 8 https://bdu.fstec.ru/threat 9 https://www.ptsecurity.com/ru-ru/products/mp-vm/
ПродуктR-VisionVM автоматическиоценивает каждуюуязвимость,чтобы определитьбизнес-рискии приоритетыдляисправлениясамыхкритичныхуязвимостей. 22 • СПЕЦПРОЕКТ По мере роста и масштабирования бизнеса увеличивается число активов, появляются новые системы и оборудование,авместесэтим растет и количество уязвимостей.Чтобыопределить,какиеуязвимости необходимо устранить сейчас,какиеможноотложить,а какиенетребуютвмешательства, необходимоихприоритизировать. Больше источников – больше информации об уязвимостях Для полного представления обовсехвозможныхуязвимостях взащищаемойсетиИБ-специалистам необходимо собирать данныеизнаибольшегоколичества систем, установленных в инфраструктуре организации. Агрегированныеданныеобактивах и уязвимостях можно группироватьианализироватьвединоминтерфейсеVM-системы. Для сбора информации об активахиуязвимостяхвR-Vision VM предусмотрен функционал сетевогосканера,атакжевозможность интеграции со множествомвнешнихсистем–сканерами уязвимостей и CMDBсистемами. Собранные активы классифицируютсяираспределяютсяпологическимгруппам согласно установленным правилам. ИБ-специалисты при работе суязвимостямимогутоперировать группами ИТ-активов, их критичностьюирасположением относительно защищаемого контура.Есливстроенныхинтеграцийнедостаточно,тоиспользуется дополнительный функционал конструктора интеграций, при помощи которого можно настроить взаимодействие практически с любой системой. Автоматическая приоритизация для оптимизации работы ИБ-специалиста В крупных компаниях количествообнаруженныхуязвимостей исчисляется сотнями тысяч.Поэтомувопросихобработкииустранениявстаетвсе острее из-за ограниченных ресурсовИБ-иИТ-подразделений. Цель приоритизации – сократитьтрудозатратыспециалистов ИБ путем фокусировки на самых критичных уязвимостях, так как устранить все уязвимости физически невозможно. 22 • Приоритизация – ключ к эффективному управлению уязвимостями организаций в условиях большого количества активов риоритизация уязвимостей – один из ключевых этапов процесса управления уязвимостями. Построение системы Пзащиты организации начинается с информации о ее активах. Андрей Селиванов, продукт-менеджер R-Vision VM Рис. 1. R-Vision VM: схема работы Фото:R-Vision
Для более удобного выстраивания процесса устранения уязвимостей в R-Vision VM встроена функция для распределения уязвимостей по уровням критичности. Уровни классифицируют уязвимости, которые в дальнейшем можно группировать для задач согласно принятым в организации SLA по их устранению. Для эффективного устранения уязвимостей VMсистема должна предоставлять ИТ-специалистам достаточный контекст по ним, чтобы минимизировать усилия по поиску и установке исправлений. Поэтому ИБ-специалистам необходима первоначальная разметка и расстановка первичных приоритетов, исходя из которых они могут быстрее и качественнее оценить критичность и распространенность каждой уязвимости в своей в сети. Ключевыми задачами при организации процесса управления уязвимостями являются оценка подразделением ИБ практической возможности использования уязвимости нарушителями и формирование задач на устранение не только на основании уровня критичности, но и факторов окружения, которые свойственны конкретной инфраструктуре. Продукт R-Vision VM автоматически оценивает каждую уязвимость, чтобы определить бизнес-риски и приоритеты для исправления самых критичных уязвимостей. Для этого есть метрика определения уровня критичности уязвимости – рейтинг. Формула расчета рейтинга присваивает каждой уязвимости приоритет, который основывается не только на базовых характеристиках уязвимости, таких как CVSS и наличие эксплойта, но и на критичности актива (или группы ИТ-активов, в которую входит актив), на котором была обнаружена уязвимость. Рейтинг уязвимости не является статичным. Он показывает уровень критичности уязвимости в зависимости от ее параметров и связанных с ней активов: в каком она статусе, где в данный момент находится уязвимый актив, какие компенсирующие меры приняты. Какие-то изменения характеристик уязвимости и актива будут снижать рейтинг опасности уязвимости, а какие-то – повышать, что будет своевременно сигнализировать о важности рассмотрения уязвимости и принятия соответствующих мер. Для более удобного выстраивания процесса устранения уязвимостей в R-Vision VM встроена функция для распределения уязвимостей по уровням критичности. Уровни классифицируют уязвимости, которые в дальнейшем можно группировать для задач согласно принятым в организации SLA по их устранению. В зависимости от рассчитанного рейтинга каждой уязвимости автоматически присваивается уровень критичности. Такая дополнительная разметка позволяет классифицировать уязвимости, что облегчает анализ в построенных графиках и отчетах. Эффективное устранение уязвимостей Недостаточно только детектировать и приоритизировать уязвимости, необходимо их устранять. Для этого ИТ-специалисты должны обладать корректной информацией о потенциальной опасности каждой отдельной уязвимости. R-Vision VM автоматически реагирует на появившиеся или ставшие критичными уязвимости: создает задачи или инциденты на устранение, назначает ответственных и сроки исполнения. Кроме того, в системе можно настраивать взаимодействие с Service Desk-системой. R-Vision VM создает задачу в тикетсистеме и поддерживает полную синхронизацию ее статусов, комментариев и изменений других полей, чтобы ИБ-аналитик смог оперативно отслеживать задачи. В R-Vision VM можно гибко настроить карточку уязвимости. Эта функция позволяет использовать дополнительные пользовательские поля, чьи значения могут быть учтены при автоматической приоритизации и реагировании на уязвимости. Многим компаниям, в том числе являющимся субъектами КИИ, регулярно рассылаются бюллетени от регуляторов с перечнем наиболее критичных уязвимостей, требующих немедленного реагирования. После проведения анализа полученных бюллетеней ИБ-специалист может использовать гибкий REST API R-Vision VM, чтобы добавить в пользовательские поля карточки уязвимости признак обязательности устранения. Впоследствии система учтет эту информацию при расчете рейтинга уязвимости, а также при автоматическом создании задачи или инцидента на устранение. Таким образом, R-Vision VM создает задачу или инцидент сразу при выявлении наиболее критичной уязвимости, которая актуальна на данный момент времени, как только она появится в системе. Для эффективного устранения уязвимостей VM-система должна предоставлять ИТ-специалистам достаточный контекст по ним, чтобы минимизировать усилия по поиску и установке исправлений. Устранение уязвимостей – трудоемкий процесс, который требует знаний и навыков в совершенно разных предметных областях. Благодаря правильно настроенным механизмам автоматической обработки и реагирования R-Vision VM помогает не только упорядочить процесс управления уязвимостями, но и значительно снизить нагрузку ИБ-аналитиков, а механизм автоматического реагирования на поступающие возможные угрозы обеспечит более быструю реакцию и повышение уровня безопасности в защищаемом контуре организации. l • 23 Управление Уязвимостями www.itsec.ru Рис. 2. Дашборд АДРЕСА И ТЕЛЕФОНЫ R-Vision см. стр. 70 NM Реклама
Методический документ ФСТЭК России по организации управления уязвимостями подлежит прямому применению в информационных системах государственных органов, субъектов критической информационной инфраструктуры, однако можно прогнозировать, что область его применения будет значительно шире. Несколько раньше в российской профессиональной сфере ИБ, как и во всем мире, аббревиатурой VM стали именовать сканеры безопасности с расширенными функциями аналитики и представления результатов. При продвижении этого класса продуктов акцент сместился в область прикладного расчета критичности уязвимостей и инструментов организации работ по их исправлению, отодвинув на второй план задачи детектирования и оценки применимости уязвимостей. Разберемся с ожиданиями и основными проблемами при реализации некоторых этапов цикла VM с использованием данных средств. Сканирование на наличие уязвимостей и оценка их применимости Зачастую приходится сталкиваться с мнением, что проблема достоверного детектирования уязвимостей ПО общего пользования для рабочих станций и серверов – вопрос тривиальный и давно решенный большинством производителей сканеров, тем не менее с этим нельзя согласиться, и вот почему. Несколько лет назад, когда в России преобладало зарубежное ПО именитых вендоров с устоявшейся культурой публикации уязвимостей, разработчикам сканеров при формировании правил детектирования уязвимостей приходилось решать множество сложных и порой противоречивых задач. Причина кроется в различных методах формирования правил проверок, и прежде всего это касается сложных продуктов с большим количеством заимствованных компонентов, в том числе Open Source, например операционных систем. Первый метод – "вендор всегда прав", то есть в список проверок включать только подтвержденные разработчиком уязвимости, формально дополняя их данными из официального ресурса (Банка данных угроз) ФСТЭК России. Однако этот метод сильно зависим от того, насколько оперативно и качественно разработчик подходит к публикации данных об уязвимостях своего ПО. Второй метод – экспертиза, основанная на декомпозиции ПО на компоненты, каждый из которых дает свое самостоятельное подмножество проверок. Например, если в составе продукта используется Open Sourсe, то список проверок формируется на основе данных Community, дополнительно учитывая базы данных эксплойтов, тематические форумы и полуофициальные источники. В теории это выглядит более привлекательным, но может привести к большому количеству ложноположительных детектирований, так как команда разработчиков сканера не всегда может достоверно определить степень модификации привлеченного (заимствованного) ПО и возможность эксплуатации уязвимостей дочернего компонента через функции родительского ПО и его окружения. Текущие реалии внесли свои особенности в процесс формирования правил детектирования уязвимостей: так, для большинства зарубежного ПО отсутствует техническая поддержка и, соответственно, официальное информирование об уязвимостях в виде бюллетеней безопасности. Появились сложности с формированием стендов для тестирования, связанные с невозможностью получения лицензий на ПО и оборудование. Российские решения привносят свою дополнительную специфику: l отсутствие или несовершенство практики публикации бюллетеней безопасности, в том числе оценки применимости заимствованных проприетарных и Open Source – компонентов, выпуска "пожарных" обновлений для наиболее критичных уязвимостей; l преобладание обновлений безопасности в виде новых версий ПО, что, вероятно, связано со сложностями процедуры внесения изменений в сертифицированные версии; l неточности в описаниях, некорректные ссылки на иностранные классификаторы CVE, CWE и экспертные базы. Все это приводит к тому, что два разных сканера могут давать различающиеся результаты поиска уязвимостей, и этот результат может отличаться (в большую сторону, если сканер использует декомпозиционный метод формирования правил проверок) от бюллетеней безопасности разработчика и баз данных регулятора, что, в сущности, нормально, так как детектирование той или иной уязвимости инфраструктурным сканером безопасности – это всегда некоторая вероятностная оценка, причем в процессе поиска потенциальных уязвимостей ошибочные оценки false positive лучше, чем false negative. В качестве рекомендаций можно выделить следующее: 1. Определить приоритет результатов автоматизированного детектирования и иных источников информации об уязвимостях для каждой платформы (ОС или аппаратной), а в идеале – для каждого используемого продукта в соответствии со степенью доверия к ним. По мнению разработчиков сканеров уязвимостей, приоритет сканера должен быть выше как минимум для: l зарубежных платформ и продуктов; l продуктов разработчиков, несистематически публикующих данные об уязвимостях; 24 • СПЕЦПРОЕКТ Управление уязвимостями: ожидание – реальность и рекомендации прошлом году ФСТЭК России разработала и утвердила методический документ по организации управления уязвимостями (VM)1 , который устанавливает цикл этапов работ по VM. Излагаемые в нем подходы универсальны для любых организаций и тесно пересекаются с зарубежными стандартами, в частности с ISO/IEC 27002, Control 8.8 – Management of Technical Vulnerabilities. В Сергей Уздемир, заместитель генерального директора по ИТ, АЛТЭКС-СОФТ Фото: АЛТЭКС-СОФТ 1 https://fstec.ru/dokumenty/vse-dokumenty/spetsialnye-normativnye-dokumenty/metodicheskij-dokument-ot-17-maya-2023-g
l ПО с открытым исходным кодом, в том числе встроенного или в составе репозиториев отечественных ОС. 2. Сравнивать результаты сканирования в разных режимах: агент/безагент, с привилегированными учетными данными/без учетных данных. 3. Использовать сканеры с базой уязвимостей в открытом формате OVAL, что облегчит разбор спорных детектов. Оценка уязвимостей Оценки по CVSS по базовым метрикам (Base Score), полученные из разных источников, могут существенно различаться, часто эта ситуация проявляется в случаях уязвимостей ядра Linux. Эксперты при формировании универсального описания могут повышать ее оценки, разработчики, наоборот, понижать. Рассмотрим конкретную уязвимость BDU:2022-05539 (CVE-2022-39842): RCEуязвимость функции pxa3xx_gcu_write ядра операционной системы Linux. Ее CVSS v.3 Base score в БДУ ФСТЭК России равен 9.8 (критический), а разработчики ОС оценили критичность этой уязвимости в своих дистрибутивах в широком диапазоне с преобладанием средних значений 6.1–6.5. Существует единство мнений, что в реальных условиях эксплуатации оценка по CVSS Base Score должна пересчитываться. Большим шагом в этом направлении является утвержденная ФСТЭК России Методика оценки уровня критичности уязвимостей…, в то же время ее применение может быть технически сложным. Оценки, связанные с определением доли уязвимых компонентов разного типа от общего числа, позволяют вполне достоверно оценить защищенность ИС в среднем, но могут серьезно понизить оценку единичной, но сверхкритичной RCE-уязвимости на сверхважном активе. Кроме того, для определения критичности по методике ФСТЭК нужно "в моменте" получить результаты сканирования всей ИС – в больших сетях это достаточно сложно, есть проблема устаревания результатов сканирования, что опять-таки может привести к неверным оценкам. В целом многие методики оценки уязвимостей, реализованные в том числе и в некоторых сканерах (VM-решениях), – это "надстройки над CVSS", в которых заложена концепция усреднения субъективных экспертных оценок отдельных метрик CVSS, которая потенциально может привести к пониженной оценке уязвимостей с большими возможностями эксплуатации. Общая рекомендация в оценке критичности звучит так: не ограничиваться только интегральной оценкой CVSS, но учитывать и отдельные метрики CVSS, другие атрибуты уязвимостей. Наиболее правильным будет формирование определения критичности на основе анализа рисков и угроз, связанных с эксплуатацией уязвимостей. Одним из простых и доступных вариантов переопределения оценки CVSS является ее пересчет на основе весовых коэффициентов, основанных на типе уязвимости (варианте эксплуатации). В частности, многочисленные экспертные "топы" (списки часто используемых уязвимостей) позволяют установить следующий рейтинг типов уязвимостей. 1. Remote Code Execution (удаленное выполнение кода). 2. Elevation of Privilege (повышение привилегий). 3. Authentication Bypass (обход аутентификации). 4. Security Feature Bypass (обход функций безопасности). Существуют более сложные математические модели и открытые проекты, такие как Vulristics, которые производят оценку уязвимостей на основе общедоступной информации об их атрибутах и эксплойтах. Установка приоритетов устранения Многие эксперты отмечают, что оценка CVSS и "границы" категорий критичности установлены таким образом, что для большого количества уязвимостей определяется критический или высокий уровень, особенно это характерно, когда оценка производится по СVSS v.2. В частности, на дату публикации материала в БДУ ФСТЭК России больше половины (55,9%) всех опубликованных уязвимостей имеет критическую и высокую степень опасности. Это приводит к тому, что приоритетному исправлению могут подлежать большинство детектированных уязвимостей, что не выглядит логичным. В то же время если мы проанализируем списки наиболее часто эксплуатируемых уязвимостей, например Top Routinely Exploited Vulnerabilities (CSA), Qualys Top 20 Most Exploited Vulnerabilities, Kaspersky threads, то увидим, что в них с регулярным постоянством попадают достаточно "старые" уязвимости не с самой высокой оценкой по Base Score, например CVE-2017-11882: Microsoft Office Memory Corruption Vulnerability, CVE-2017- 8570: Microsoft Office Remote Code Execution Vulnerability, которые имеют Base Score = 7.8. Таким образом, целесообразно дополнить основанный на CVSS принцип приоритизации уязвимостей дополнительными правилами, смысл которых будет заключаться в попытке выявления наиболее "эксплуатабельных" уязвимостей. Сканеры (VM-решения) и экспертные базы предоставляют достаточное количество атрибутов уязвимостей для организации подобного рода фильтрации. Примером может являться правило: критической считать любую уязвимость со следующими атрибутами: l тип уязвимости – Remote Code Execution, Elevation of Privilege, Authentication Bypass; l CVSS вектор атаки (AV) = N (сетевой); l CVSS влияние на другие компоненты системы (S) = С (оказывает); l CVSS доступность средств эксплуатации (E) = H (высокая). В завершение можно отметить тенденцию в западных VM-решениях, которые все больше становятся продуктами "для узкого круга лиц". При декларируемом выборе варианта приоритизации: с высоким рейтингом CVSS, с наиболее доступными эксплойтами, на основании прогнозирования атак, нейронных сетей и т.д., модели оценки уязвимостей в них скрыты, списки наиболее критичных уязвимостей приводятся без обоснования. Кроме того, включение функционала VM только в дорогие Enterprise-редакции или лицензионные бандлы серьезно ограничивает их применение даже на внутренних рынках. В России, с ее бурно растущей номенклатурой отечественного ПО, формирующейся культурой безопасной разработки, мы должны стремиться к другому результату – внедрению VM в максимально возможное число организаций на основе использования отечественных сканеров с открытыми базами проверок и метриками оценки и приоритизации уязвимостей, а также активной и координирующей роли регулятора в этом процессе. l • 25 Управление Уязвимостями www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ АЛТЭКС-СОФТ см. стр. 70 NM Реклама Изображение: АЛТЭКС-СОФТ
Рассмотрим подходы в той последовательности, в которой они появлялись как технологии. Использование скриптов Предполагает запуск сценариев, реализующих логику определения наличия уязвимостей. В простейшем случае в ходе выполнения скрипта осуществляется подключение к сетевому сервису, разбор его баннера с целью извлечения версии ПО и сравнение с заданными в скрипте значениями. Скрипт может также включать дополнительную логику взаимодействия с проверяемым узлом, например проверить, что бэкдор, связанный с уязимостью, не был активирован. В прародителе целого ряда коммерческих сканеров уязвимостей Nessus данный механизм реализован с помощью языка NASL, в известном сканере портов Nmap для этой цели поддерживается запуск скриптов на языке Lua (Nmap Scripting Engine). Запуск большого количества скриптов занимает продолжительное время, иногда даже несколько часов. Полнота сканирования полностью зависит от возможностей вендора по разработке и поддержанию в актуальном состоянии десятков тысяч небольших программ. Стоит отметить, что присутствует и риск нарушения работоспособности сервиса в случае, если скрипт пытается сымитировать реальную эксплуатацию уязвимости. Спецификация SCAP Была разработана американским NIST в далеком 2009 г., она определяет то, как перевести требования безопасности информации в формализованный вид – SCAP-контент. Для определения требований используются языки XCCDF (The Extensible Configuration Checklist Description Format) и OVAL (Open Vulnerability and Assessment Language). XCCDF используется для описания требований, а OVAL – для описания алгоритма проверки. Для проведения проверок используется SCAP-интерпретатор, который и составляет ядро сканера уязвимостей, использующего данный подход. К сожалению, заложенная гибкость привела к сложности и данная технология оказалась тяжелой в полноценной реализации задуманного. Так, вендоры, производящие решения на базе SCAP-интерпретаторов, редко когда заявляют о числе проверок, сопоставимом с количеством известных уязвимостей. Обычно речь идет о нескольких десятках тысяч проверок, в то время как общее количество уязвимостей уже превысило 160 тыс. Поиск уязвимостей по версиям ПО Стал возможен благодаря появлению множества баз данных уязвимостей в доступных для автоматического разбора форматах. Самыми известными являются БДУ ФСТЭК России, NIST NVD, базы компаний-разработчиков операционных систем. Версии установленного на узлах ПО можно определять как по сети, разбирая баннеры сетевых сервисов, так и анализируя установленные пакеты, подключившись с помощью протоколов, используемых для удаленного администрирования. Данный подход известен своей феноменальной скоростью поиска уязвимостей, так как "сканирование" в данном случае представляет собой всего лишь обращения к локальной агрегированной базе данных. Использование большого количества источников позволяет обеспечить практически 100%-ное покрытие известных уязвимостей. Выводы Если сопоставить ключевые характеристики рассмотренных подходов, то можно получить следующую картину, отображенную в таблице. Проведя такой анализ подходов, разработчики группы компаний "Эшелон" остановили свой выбор на варианте, связанном с поиском уязвимостей по версиям ПО, который и был реализован в Сканер-ВС 6. Решение позволяет проводить поиск уязвимостей сетевых сервисов на основе сетевого сканирования портов и уязвимостей системного и прикладного программного обеспечения, установленного в ОС семейств Linux и Windows, на основе инвентаризации ПО по протоколам SSH и WinRM. После сетевого сканирования или инвентаризации поиск уязвимостей занимает считанные секунды. Негативное воздействие на инфраструктуру полностью исключено. Источниками данных об уязвимостях для Сканер-ВС 6 являются БДУ ФСТЭК, NIST NVD, базы уязвимостей Astra Linux, РедОС, Ubuntu, Debian, RedHat и др. Обновления выходят ежедневно. Продукт разработан для функционирования в ОС Astra Linux 1.7. Поставка возможна как виде дистрибутива, так и в виде LiveUSB. Демоверсия Сканер-ВС 6 доступна в виде дистрибутива, Docker Compose и ISO-образа LiveUSB на сайте1 продукта. l 26 • СПЕЦПРОЕКТ Подходы к поиску уязвимостей: хороший, плохой, злой дром любого сканера безопасности является реализация механизма поиска уязвимостей. Кратко разберем распространенные подходы, используемые в сканерах уязвимостей, а именно применение скриптов, реализацию стандарта SCAP (Security Content Automa- Яtion Protocol) и поиск по версиям программного обеспечения. Александр Дорофеев, CISSP, CISA, CISM, АО “Эшелон Технологии” Таблица. Сравнение подходов к поиску уязвимостей АДРЕСА И ТЕЛЕФОНЫ "НПО "ЭШЕЛОН" см. стр. 70 NM Реклама Фото: АО "НПО "Эшелон" Поиск по версиям OVAL Скрипты Скорость выпуска обновлений Высокая Средняя Средняя Полнота покрытия уязвимостей Высокая Средняя Средняя Возможность сетевого сканирования без учетной записи Да Нет Да Возможность сетевого сканирования с учетной записью Да Да Да 1 https://scaner-vs.ru
• 27 Управление Уязвимостями www.itsec.ru Vulnerability Management (VM) – неотъемлемаячастьразработкиоперационной системы (ОС). Прежде всего работасуязвимостямиповышаетбезопасность, ведь любая уязвимость в ОСможетбытьиспользованазлоумышленниками для получения несанкционированногодоступа,выполненияпроизвольногокода,отказавобслуживании ит.д.Впроцессеразработкинеобходимо придерживаться требований регуляторов, особенно если операционная система используется в организациях, работающих с конфиденциальной информацией,персональнымиданными илигостайной,иприменяетсянапредприятияхКИИ. Как организован процесс VM при разработке программного продукта? Любойразработчикхочетсделатьсвое ПО более конкурентоспособным, добавитьвнегоновыефункцииихотябына шагопередитьколлегпорынку.Вэтом случае необходимо соблюсти баланс между инновационностью и безопасностью.Здесьнапомощьприходяттакие инструменты,каквнутреннийаудиткода, егостатическийидинамическийанализ, атакжедоскональноеследованиеметодикамистандартамилучшимпрактикам безопасной разработки. Желательно, чтобыпринципыбезопасностинарядус функциональными требованиями были изначально заложены на уровне архитектуры будущего продукта (Secure by Design). Анализуязвимостейведетсяещена этаперазработкиОС,апослевыхода релиза в продакшн и передачи его клиентам управление уязвимостями работает на всех уровнях. Обнаруживаются уязвимости двумя путями: с помощью работы внешних ИБ-исследователей,какотдельныхэнтузиастов, так и целых компаний, а также внутренние улучшения, вносимые самим вендором. Разработка программного продукта представляет собой перманентныйпроцесс,которыйвключаетв себядобавлениеновыхфункцийиразвитиеужесуществующих,что,всвою очередь, сопровождается экспертным анализом, ревью кода, обнаружением баговиуязвимостей. Разработкой защищенных дистрибутивовLinuxзанимаютсякрупныекомпании,такиежезадачирешаетикоманда по анализу защищенности ОС Astra Linux.Аудиткодаведетсянавсехэтапах разработки. ВпериодэксплуатациикомандаразработчиковОСв"ГруппеАстра"работает с большим числом баз уязвимостей,средикоторыхестьинепубличные. Прежде всего это собственная база компанииAVM(AstraVulnerabilityManagement).Внейразмещенаинформация о зафиксированных уязвимостях ОС AstraLinuxвразныегоды.AVMнетолько содержит информацию о разного рода уязвимостях, но и в автоматизированном режиме взаимодействует с другимибазами,атакжеобменивается данными с регулятором – ФСТЭК России. Информация, полученная из международныхбазданных,подвергаетсятщательномуанализунапредмет актуальности и степени критичности дляОСAstraLinux. Авторитетныймеждународныйисточникинформацииобуязвимостях–база данныхамериканскойкомпанииMITRE c идентификатором CVE (Common VulnerabilitiesandExposures)1 .Онасодержит наиболее полные сведения о слабых местахвоткрытомикоммерческомПО. Внеепересылаютзаписи онайденныхуязвимостях как независимые ИБисследователи,такисамиразработчики программныхпродуктов. При появлении записи в базе CVE модуль парсинга в автоматическом режимесобираетинформациюоновой уязвимости в других БД (в том числе вендорских),атакжеформируетсястандартизированная запись о ней в базе данных AVM. Далее к работе с этой записьюподключаютсяаналитики.Они обогащаютпаспортуязвимостиновыми сведениямииоценивают,насколькоэта уязвимостьактуальнадляОСAstraLinux. Еслипроведенныйанализподтверждает актуальность,тосоздаетсязадачаустраненияуязвимостипопринятому вкомпаниирегламенту.Задачадолжнасодержать информацию о версиях ПО, для которых данная уязвимость актуальна, ссылкунапатчотвендора,еслионуже выпущен,идругуюполезнуюинформацию,котораяпоможетразработчикукак можно скорее исправить актуальную уязвимость.Аналитикимогутвлиятьна степеньважностиисрочностиееустранения,атакжепроверяют,действительно ли она нейтрализована в выпущенном обновлении безопасности. Запись об устраненной уязвимости отправляется в БДУ2 ФСТЭКРоссии. ВитогенедостаткиПО,обнаруженные "Группой Астра" самостоятельно, фиксируются в собственной базе данных AVM с идентификатором ASE, а после их устранения информация об этом в обязательном порядке отправляется в БДУ ФСТЭК России. Уязвимость с идентфикаторомASEсбольшейдолей вероятности имеет отношение только к ОС Astra Linux и неактуальна для других ОС. Компания также подготавливаетдляклиентовипартнеровинформацию в машиночитаемом формате, которуюзаказчикииразработчикисканеровуязвимостеймогутиспользовать дляболееточногоанализазащищенностиОС.l Управление уязвимостями при разработке ОС Astra Linux правление уязвимостями играет ключевую роль в процессе разработки и эксплуатации любой операционной системы. У Владимир Тележников, директор департамента научных исследований “Группы Астра” АДРЕСА И ТЕЛЕФОНЫ "ГРУППА АСТРА" см. стр. 70 NM Реклама Фото:ГК"АСТРА" 1 https://cve.mitre.org/ 2 https://bdu.fstec.ru/regulations
Сканирование без нагрузки на хост Анализ активов инфраструктуры на предмет поиска уязвимостей является неотъемлемым этапом процесса управления уязвимостями. Процедура анализа является одним из основных камней преткновения при использовании VMрешений, поскольку часто создает высокую вычислительную нагрузку на активы и нагружает сеть инфраструктуры. Современный метод сканирования уязвимостей в VM-решениях стремится минимизировать нагрузку на активы. Это достигается переносом процесса обнаружения уязвимостей с актива на сервер VM-решения. Вся необходимая для сканирования информация собирается на хосте, а затем отправляется на VM-сервер, где и проводится аудит. Это избавляет от необходимости выполнять тяжелые процессы сканирования на самом активе и позволяет не влиять на работоспособность инфраструктуры. Такой подход заодно способствует эффективному использованию сетевых ресурсов, поскольку сбор и передача данных оптимизированы, что снижает нагрузку на сеть. Это важно в условиях сетей с ограниченной пропускной способностью или при сканировании больших сегментов инфраструктуры. Третье преимущество связано с ускорением самого процесса сканирования. Передача необходимых данных на сервер позволяет существенно сократить время выполнения процедуры выявления уязвимостей: в архитектуре VM-решения может быть предусмотрена параллельная обработка, алгоритмы быстрой проверки уязвимостей в базе данных (БДУ) и т.д. Такой метод обеспечивает быстрое обнаружение и реагирование на потенциальные уязвимости. Высокоскоростное сканирование В современных условиях скорость проведения сканирования уязвимостей становится критически важной, особенно в организациях с обширной инфраструктурой. Времена, когда сканирование всех хостов занимало несколько дней, ушли в прошлое. Современные методы сканирования предусматривают перенос аудита на сервер VM-решения, что позволяет проводить сканирование активов так часто, как это необходимо. Это позволяет сканировать отдельные сегменты инфраструктуры, например только определенные операционные системы или только сетевые устройства, сразу после возникновения новых уязвимостей. При этом достигается гибкость в проведении сканирования в любое время, избавляя от необходимости выжидать наступления технологических окон или нерабочего времени. Применение такого подхода позволяет проводить аудит инфраструктуры за минимальное время, предоставляя возможность получать актуальные отчеты по запросу в режиме реального времени, а не после завершения длительных циклов сканирования. Это важно для оперативного реагирования на уязвимости и обеспечения непрерывной безопасности с минимальными временными задержками. Обновление базы данных уязвимостей в реальном времени Эффективное функционирование решений для управления уязвимостями предполагает оперативное обновление своих баз данных уязвимостей. Это крайне важно для обеспечения быстрой реакции на постоянно меняющийся ландшафт угроз. Вендор VM-решения обязан стремиться к минимизации окна уязвимости, то есть временной задержки с момента появления информации о новой уязвимости до возможности ее обнаружения в защищаемой инфраструктуре. Это требует от него не только активного мониторинга новых уязвимостей, чтобы быть в курсе последних угроз, но и оперативности в процессе интеграции обновлений в систему. При этом поставка обновлений БДУ должна осуществляться автоматически, причем независимо от обновления самой VM-системы, инкрементально и в кратчайшие сроки – до того, как информация о новой уязвимости станет общеизвестной. Сканирование docker-образов без запуска контейнеров (в реестрах и CI/CD) В современных методах сканирования docker-образов акцент делается на обеспечении быстроты и безопасности, исключая при этом необходимость запуска контейнера. Другими словами, используется прямое взаимодействие с файловой системой образа: проводится сбор Software Bill of Materials (SBOM) и последующий анализ уязвимостей на основе полученной информации. Такой подход имеет два важных достоинства. Во-первых, отказ от необходимости запуска потенциально опасного контейнера устраняет потребность в создании песочницы для проведения сканирования, что способствует повышению безопасности процесса. Во-вторых, работа непосредственно с файловой системой образа существенно ускоряет процесс сканирования, поскольку не требуется время на запуск контейнера. Дополнительный эффект в повышении скорости аудита возникает при проведении пересканирования образов на основе ранее собранной информации. После первоначального сканирования и создания SBOM исчезает необходимость повторной загрузки образов из реестра для последующего анализа. Это сокращает временные затраты и оптимизирует процесс обновления данных о безопасности образов. 28 • СПЕЦПРОЕКТ Современные технологии в решениях для управления уязвимостями истемы управления уязвимостями играют критическую роль в обеспечении безопасности информационных систем предприятий. От решений класса Vulnеrability Management (VM) требуется постоянное совершенствование используемых подходов для более эффективного и безопасного выявления уязвимых мест инфраструктуры. Рассмотрим наиболее важные улучшения, которые реализованы в современных VM-решениях. С Владимир Михайлов, руководитель департамента перспективных проектов компании “Фродекс” Фото: Фродекс
Патч-менеджмент Эффективное VM-решение не ограничивается одним лишь процессом выявления уязвимостей, а предлагает инструменты для их устранения. Ключевым механизмом для этого является установка обновлений операционной системы и прикладного программного обеспечения. Важным компонентом этого процесса является наличие в VMпродукте функционала патч-менеджмента, который напрямую связан с выявленными уязвимостями. Такой функционал ускоряет достижение инфраструктурой необходимого уровня защищенности. Способность автоматически устанавливать обновления не только обеспечивает оперативное реагирование на новые угрозы, но и позволяет сократить окно уязвимости – период времени между обнаружением уязвимости и ее устранением. Дополнительным плюсом в контексте безопасности обновлений является проведение проверок по базам данных Федеральной службы по техническому и экспортному контролю (БДУ ФСТЭК). Это дополнительный уровень проверки, который обеспечивает соответствие установленных обновлений не только требованиям производителей, но и регуляторным стандартам безопасности, что поднимает уровень доверия к обновлениям и укрепляет общую защиту системы. Запуск в Kubernetes: горизонтальное масштабирование для сканирования огромных инфраструктур Для компаний с обширными инфраструктурами, насчитывающими десятки и сотни тысяч активов, критически важно иметь средства, способные обеспечивать оперативное сканирование и эффективную обработку огромных объемов накопленных данных. Эти данные включают в себя результаты сканирования, сгенерированные отчеты, а также карточки активов и другие сведения. Важным аспектом является возможность передачи таких данных в сторонние системы или предоставление аналитики в собственном интерфейсе. Современный подход предполагает для развертывания приложений использование оркестраторов, таких как Kubernetes или Docker Swarm. Этим достигается эффективное горизонтальное масштабирование компонентов продукта и динамическое выделение дополнительных ресурсов в моменты повышенной нагрузки на систему. Например, это может быть необходимо при сканировании больших сегментов инфраструктуры, запросах больших объемов данных через API, расчетах метрик приоритизации или генерации значительного количества отчетов. Этот подход не только обеспечивает адаптивность и эффективность в обработке масштабных задач, но также снижает вероятность простоев, улучшает производительность системы и зачастую является единственным способом оперативно обработать огромные объемы данных. Концепция "не навреди инфраструктуре заказчика" Поскольку различные компоненты решений класса Vulnerability Management непосредственно взаимодействуют с активами в виде агентов или обладают привилегированным доступом к ним (безагентное сканирование с использованием учетных записей), становится важным, насколько бережно развернутая система взаимодействует с инфраструктурой клиента. Современный подход к безопасности включает в себя внедрение в продукт специальных ограничений, реализующих принцип "не навреди" (not to damage first). Это означает, что система даже в случае компрометации должна предотвращать выполнение злоумышленником разрушительных действий. Применение специальных протоколов, предусматривающих встроенные механизмы контроля и предотвращения нежелательных операций, обеспечивают защиту взаимодействия с активами и между компонентами самой системы. Обязательным является введение мер безопасности, таких как ролевые модели доступа, защищенное хранение учетных записей, двухфакторная аутентификация, ограничения для API-токенов, контроль целостности обновлений и исполнимых файлов. Концепция "не навреди" создает дополнительный уровень безопасности, обеспечивая сохранность инфраструктуры клиента даже при наличии потенциальных внутренних угроз. Агентное сканирование внутри защищенного сегмента Ранее для проведения сканирования активов внутри защищенных сегментов требовалось предоставление сетевого доступа от VM-решения внутрь этого сегмента. Этот метод хоть и обеспечивал проведение сканирования, но также создавал определенные риски, связанные с потенциальным нарушением безопасности защищенного сегмента при открытии сетевого доступа. Современный подход к решению этой проблемы заключается в инициировании соединения от агента, работающего внутри защищенного сегмента, к VM-решению. Это позволяет поддерживать защищенность сегмента, не открывая внешний сетевой доступ. Такой метод не только соблюдает принцип "не раскрывай, если не требуется", но и обеспечивает сохранение уровня безопасности внутри защищенных сетей. Таким образом, соблюдается безопасность даже в процессе проведения сканирования, реализуя эффективный механизм взаимодействия между агентами и продуктом без нарушения защитных барьеров защищенных сегментов. Работа с любыми данными через REST API В современном бизнес-ландшафте многие крупные компании обладают значительными ресурсами и возможностями для создания собственных информационно-технологических процессов. Эти процессы, включая обнаружение и устранение уязвимостей в системах информационной безопасности, могут быть разработаны с учетом специфических требований и представлений компании. В некоторых случаях организации строят собственные схемы детектирования и устранения уязвимостей в соответствии со своими внутренними процедурами и стандартами безопасности. Для таких компаний становится критически важным наличие инструментария, который обеспечивает гибкость взаимодействия со своими данными и интеграцию с уже существующими процессами. VM-продукт, обладающий возможностью работы с данными через встроенный API, предоставляет необходимые возможности для таких клиентов, позволяя интегрировать VM-решение в свои собственные процессы и системы. А наличие в API дополнительных сервисов, реализующих логику обнаружения уязвимостей или работу с базой данных уязвимостей, дает возможность выстраивать свои процессы обнаружения уязвимостей и обогащения данных. Такой подход к разработке и внедрению VM-продукта позволяет клиентам максимально эффективно использовать собственные ресурсы, обеспечивая гибкость и индивидуальный подход к обеспечению информационной безопасности. Заключение Управление уязвимостями является одним из важнейших ИБ-процессов, поэтому в решениях класса Vulnerability Management необходима реализация подходов и технологий, которые будут способствовать эффективному обнаружению и устранению уязвимостей, а также максимально адаптироваться к особенностям и потребностям конкретной инфраструктуры. l • 29 Управление Уязвимостями www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ "ФРОДЕКС" см. стр. 70 NM Реклама
Я считаю, что BugBounty – наиболее эффективный метод сторонней ИБ-экспертизы. Для выхода на BugBounty мы выбрали сценарий с реализацией недопустимых событий, за достижение которых готовы платить. Перечень таких событий мы сформировали заранее и корректируем его по мере поступления отчетов. – Как вы оцениваете программу BugBounty для поиска уязвимостей в дистрибутиве операционной системы? – Хотелось бы начать с того, что мы как разработчик средств защиты информации обязаны выполнять нормативные требования регулятора – ФСТЭК России в части работы с уязвимостями. К моменту публикации программы BugBounty в нашей компании уже был выстроен соответствующий процесс, а дополнительно на договорной основе привлекались сторонние организации, которые проводили аудит кода операционной системы, так называемый заказной пентест. Это достаточно затратная инициатива, которая обходилась в серьезную сумму за каждый контракт. При этом результаты мы получали не самые впечатляющие, а выявленные недостатки не относились к интересующей нас области – средствам защиты информации в составе ОС. Выход на BugBounty позволил привлечь большой пул независимых исследователей различного уровня компетенций, которые осуществляют поиск уязвимостей в соответствии с нашими запросами, оформленными в виде оферты. Программа была запущена в августе 2023 г., и за это время мы получили уже 27 отчетов, 12 из которых признали полностью валидными, то есть отвечающими нашим требованиям. Проще говоря, мы получили в разы лучший результат, обнаружив для себя критически важные вещи. Так что это очень результативная программа. Более того, я считаю, что BugBounty – наиболее эффективный метод сторонней ИБ-экспертизы. – Какие типы уязвимостей чаще всего обнаруживаются с помощью BugBounty в вашем дистрибутиве операционной системы? – Astra Linux Special Edition является деривативом (дистрибутивом на основе) операционной системы с открытым исходным кодом Debian и содержит в своем составе заимствованные компоненты с открытым исходным кодом, в связи с чем объявлять программу поиска уязвимостей (CVE) было бы непродуктивно. Для выхода на BugBounty мы выбрали сценарий с реализацией недопустимых событий, за достижение которых готовы платить. Перечень таких событий мы сформировали заранее и корректируем его по мере поступления отчетов. Считаем данный подход наиболее эффективным, так как исследователь в своей работе может достигать того или иного события разными способами. И так мы устраняем не только выявленные ошибки, но и проделываем определенную работу по самому сценарию реализации. Таким образом, закрытие одного отчета позволяет устранить несколько потенциальных уязвимостей в системе. – Каков процесс управления и анализа полученных отчетов о найденных уязвимостях? – Как я уже говорила, до BugBounty в компании был выстроен процесс управления уязвимостями. Перед выходом в публичную плоскость мы по совету представителей площадки, компании BI.ZONE, опубликовали приватную программу, к участию в которой пригласили ограниченное количество исследователей. И хотя это не принесло какого-либо значимого результата, мы успели подготовиться и интегрировать процессы отработки отчетов, поступающих в рамках BugBounty, в корпоративные регламенты управления уязвимостями. Работает все это следующим образом: площадка проводит первичную проверку отчета (триаж) и в случае признания его валидным передает информацию нашей команде, в которую входят в том числе сотрудники департамента анализа безопасности. Они анализируют отчет, осуществляют необходимые действия в соответствии с процессом и организовывают полное сопровождение выявленной уязвимости, с момента поступления информации и до выпуска необходимого обновления. Таким образом, мы не тратим лишние ресурсы, не создаем параллельный процесс. Ничего радикально нового не произошло, просто ко всем используемым ранее источникам информации об уязвимостях добавился еще один. – Какие меры предпринимаются для быстрого реагирования и устранения обнаруженных уязвимостей? Какие есть особенности, если уязвимость критическая и исправить ее нужно во внеочередном порядке? – Мы обязаны соблюдать конкретные сроки устранения уязвимостей, которые устанавливает регулятор. Могу заве30 • СПЕЦПРОЕКТ Главное, чтобы исследователь не ушел от нас с негативной реакцией 2023 г. в “Группе Астра" была запущена корпоративная программа BugBounty. Это первый опыт среди российских разработчиков операционных систем. Ольга Гурулева, директор департамента информационной безопасности “Группы Астра”, ответила на вопросы о ходе программы и ее В результатах. Ольга Гурулева, директор департамента информационной безопасности “Группы Астра” Фото: Группа Астра
Если мы не принимаем уязвимость, необходимо грамотно и корректно объяснить причины отказа. И при этом важно, чтобы исследователь не ушел от нас с негативной реакцией. Особенность нашей программы BugBounty в том, что она охватывает конкретный перечень недопустимых событий. Мы планируем расширять этот перечень. рить, что эти сроки нами выдерживаются. – Какова роль внутренних команд безопасности в совместной работе с исследователями из BugBounty-программы? – Прежде всего они проводят валидацию отчетов, проверяют релевантность обнаруженной уязвимости. Второе направление – диалог с исследователем, который провел определенную работу и ожидает за нее вознаграждение. Иногда на этом пути возникают сложности, когда выясняется, что уязвимость невалидная или является дублем, в связи с чем мы не можем принять отчет к рассмотрению. Соответственно, нужно отработать возражения "белого" хакера. Если мы не принимаем от него уязвимость, необходимо грамотно и корректно объяснить причины отказа. И при этом важно, чтобы исследователь не ушел от нас с негативной реакцией. – Как происходит взаимодействие с исследователями в процессе решения обнаруженных проблем и устранения уязвимостей? – Взаимодействие происходит непосредственно на площадке BI.ZONE через соответствующий портал. После первичной обработки отчета и передачи его к нам в работу мы проверяем всю присланную информацию и уточняем какие-либо детали, если это необходимо. На протяжении всего этапа работы с отчетом оставляем комментарии и ведем диалог с исследователем. – Какие меры принимаются для обеспечения честности и справедливости в процессе награды и признания участников BugBounty-программы? – После того как отчет отработают эксперты нашего департамента анализа безопасности, в процесс включается комиссия по назначению выплат, где коллегиально рассматривается отчет исследователя и отзыв наших экспертов на него. На основании этих сведений принимается решение о размере вознаграждения. Любой субъективный фактор здесь полностью исключен. При возникновении конфликтной ситуации в первую очередь мы стараемся разрешить ее собственными силами. В сложных случаях привлекается арбитры, которыми являются представители площадки BugBounty – сотрудники BI.ZONE. Они максимально объективны, поскольку заинтересованы в популяризации и хорошей репутации как своей площадки, так и всего движения BugBounty в целом. – Каковы планы по дальнейшему развитию и улучшению BugBounty-программы в контексте обеспечения безопасности дистрибутива операционной системы? – Особенность нашей программы BugBounty в том, что она охватывает конкретный перечень недопустимых событий. Мы планируем расширять этот перечень. Сейчас для анализа предоставлены два защитных механизма ОС – мандатное управление доступом и замкнутая программная среда, и этот список будет пополняться. Нам не нужно проверять весь код ОС, мы заинтересованы в корректности работы ее защитных механизмов. Операционная система не единственный наш продукт, у нас есть и другое ПО, которое хочется охватить в рамках BugBounty. Например, один из следующих таких продуктов – платформа управления виртуализацией VMmanager компании ISPsystem. Коллеги уже имеют свою программу BugBounty, размещенную на собственном сайте, и мы хотели бы вывести ее на площадку BI.ZONE, чтобы поднять на новый уровень и привлечь еще больше исследователей. – Как взаимосвязаны процессы рБпо (разработка безопасного программного обеспечения) и BugBounty? Будет ли эффективна BugBounty без внедренных процессов рБпо? – Если предположить, что в компании процессов РБПО не существует и мы выпускаем продукт сразу на BugBounty, есть риск того, что багхантеры найдут достаточно большое количество уязвимостей, исправление которых волной захлестнет команду разработки, а совокупный размер выплат исследователям отразится на бюджете продукта. Все это, несомненно, повлияет на доработку имеющегося функционала, сдвинет Roadmap выпуска новых версий продукта, и в целом все это будет больше похоже на "выстрел в ногу". Станет ли в таком случае эффективной программа BugBounty? На мой взгляд, нет. Ведь РБПО – это не только выстраивание процессов, но и внедрение программных средств, например статических/динамических анализаторов кода, что позволяет выявлять часть уязвимостей еще на ранних стадиях разработки. А как показывает практика, исправление уязвимости после релиза обходится значительно дороже. l • 31 Управление Уязвимостями www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ "ГРУППА АСТРА" см. стр. 70 NM Реклама Фото: Группа Астра
Технологии искусственного интеллекта всего за год прошли путь от любопытных исследований до мощнейшего инструмента, массово внедрямого в информационные системы. Уже можно с уверенностью сказать, что внедрение технологий ИИ в инструменты информационной безопасности и, в частности, управления уязвимостями способно революционизировать область их применения и по-новому распределить задачи между оператором и системой. ИИ позволяет анализировать и обучаться на огромных объемах данных из разных источников, обеспечивает такую же (а иногда даже выше) точность выявления уязвимостей за меньшее время, автоматизирует распределение и обработку запросов при взаимодействии с другими подсистемами ИБ и ИТ для сбора дополнительных данных. ИИ готов работать с одинаковым уровнем эффективности в режиме 24х7х365. Непрерывная оценка уязвимостей и их устранение Проходят времена периодических проверок активов на уязвимости. В мире наблюдается активное движение в сторону постоянного мониторинга состояния безопасности в режиме реального времени. Обеспечить это можно сверхчастотным сканированием поверхности атаки на наличие уязвимостей и вредоносного ПО. Непрерывная оценка защищенности соответствует идее проактивной защиты и немедленного устранения уязвимостей. Использование искусственного интеллекта может существенно улучшить эффективность и результативность различных этапов этого процесса. Системы на базе ИИ могут автоматизировать сканирование на основе появления бюллетеней от производителей или информации об атаках на похожие компании, обогащение как на основании внутренних источников, так и внешних, приоритизацию и направление всех данных в ИТ-блок для исправления. Такой подход в режиме реального времени (или почти реального) позволит выявлять и устранять уязвимости практически сразу, как только они возникают. В результате окно уязвимости сводится к минимуму. Тренд второй. Управление активами и их приоритизация На фоне растущей сложности информационных инфраструктур управление активами уже стало важнейшим элементом систем Vulnerability Management. Сейчас, когда организации работают с множеством устройств, приложений и данных, функционирующих в различных средах, получение целостного представления о цифровом ландшафте стало необходимостью. Но не все активы равнозначны с точки зрения их важности для бизнеса и ИБ. Таким образом, к задаче идентификации добавляется проблема классификации активов, учитывая их важность и потенциальное влияние на работу организации и ее защищенность. Такая расстановка приоритетов позволяет сосредоточить усилия на устранении тех уязвимостей, эксплуатация которых представляет наибольший риск. Уже сейчас имеются инструменты в решениях VM c модулями машинного обучения, которые помогают расставить приоритеты не только по уязвимостям, но и по активам, чтобы команда ИБ могла сосредоточить свои усилия в первую очередь на наиболее важных из них. Тренд третий. Интеграция управления уязвимостями с DevOps Разрыв между разработчиками программного обеспечения и людьми, которые обеспечивают его безопасность в процессе эксплуатации, должен сокращаться. В ближайшие годы должны появиться инструменты, которые помогут обеим сторонам работать сообща. Речь идет как об инструментах, которые помогут найти и устранить проблемы в разрабатываемом ПО на раннем этапе, прежде чем оно станет доступно пользователям, так и о системах, которые, обнаружив уязвимость, оперативно доставят информацию о ней разработчикам, при этом подсветив проблемные места кода для быстрого исправления, или предложат способы компенсации на основе ИТ-ландшафта и используемых ИБ-решений. Причем все проверки и анализ на уязвимости должны проходить в автоматическом режиме. Традиционные методы сканирования, часто применяемые на этапе эксплуатации, оказываются недостаточно оперативными. ИИ может использовать передовые методы аналитики и машинного обучения не только для выявления уязвимостей, но и для вычисления тенденций, закономерностей, чтобы прогнозировать потенциальные уязвимости еще до того, как они появились, подключая разработчиков к проактивному исправлению. Заключение Использование искусственного интеллекта на стороне защищающихся и нападающих, усложнение ландшафта ИТинфраструктуры, размытие границ периметра компании должны учитываться в развитии решений управления уязвимостями с целью опережения возникающих угроз и защиты ценных активов организаций в быстро меняющемся ландшафте киберугроз. Однако крайне важно подчеркнуть, что ИИ следует рассматривать не как отдельное решение, а скорее как дополнительный компонент традиционных систем управления уязвимостями, дающий для экспертов возможность уменьшить вероятность ошибки, сокращения времени на реакцию, возможность спрогнозировать будущие изменения в системах для повышения их защищенности. l 32 • СПЕЦПРОЕКТ Управление уязвимостями с помощью ИИ роцесс управления уязвимостями играет важную роль в деле защиты инфраструктуры. Основой превентивной подготовки к атакам можно назвать управление (можно читать: выявление и устранение) уязвимостями, которое является эффективным инструментом уменьшения поверхности атаки, то есть сокращение векторов атаки злоумышленников. Передовые решения управления уязвимостями (Vulnerability Management) уже обеспечивают обогащение информации из разных источников об уязвимостях, выделяют в результатах сканирования наиболее важные и критичные для устранения уязвимости. Посмотрим, как функциональность ИИ в том виде, как мы понимаем ее сейчас, может поддержать и ускорить тренды развития систем класса Vulnerability Management в ближайшие годы. П Андрей Макаренко, руководитель отдела по развитию бизнеса Angara Security Ваше мнение и вопросы присылайте по адресу [email protected] Фото: Angara Security
• 33 Управление Уязвимостями www.itsec.ru "Человеческий фактор" и киберпреступники-разведчики Значительное число ИБ-инцидентов происходит из-за ошибок пользователейиотсутствияпривычкисоблюдать правила цифровой гигиены. Но при всей своей распространенности человеческий фактор – далеко не единственная лазейка для кибератак. И хакеры-одиночки,и кибепреступные группировки ведут активную разведку –ищутуязвимостив"оборонительных"редутахпредприятий,которыеони рассматриваютвкачествепотенциальныхжертв.Онипроизводятпоискучетных данных пользователей из числа сотрудников компаний, изучают сетевуюинфраструктуру,открытыепорты, незапароленные каналы входа с использованиемразличныхпротоколов. Более того, такие данные злоумышленникипродаютдругдругу. Для борьбы с подобными действиями многиеорганизациииспользуютпентесты, но это периодические мероприятия, а хакерскоенападение,темболеецеленаправленное, может быть осуществлено в любоймомент.Поэтомупомимопериодических тестирований на проникновение защищенногопериметраследуетиспользоватьспециальныйинструментарий,которыйведетпостоянныймониторингинфраструктурынапредметуязвимостей. Что такое ASM? Для осуществления мониторинга используютсяспециализированныерешения,такиекакASM-системы(AttackSurfaceManagement).Ониведутнепрерывное обнаружение, анализ и устранение уязвимостей защищенного периметра организации.Всеэтидействияосуществляются"сточкизренияхакера",тоесть исходя из того, насколько вероятно использованиеуязвимостикиберпреступникамидляосуществлениянападения. Задача ASM – поставлять службам информационной безопасности предприятия актуальную информацию о состоянииегоинформационнойинфраструктуры, имеющихся уязвимостях и путяхихустранения.Этивозможности ASMособенноактуальныдляорганизаций, которые имеют развитые ИТ, используют множество различных системисервисов. Некоторыеизнихмогутиметьнедостаточную защиту или использовать устаревшее ПО. Наконец, случается, чтоадминистраторыпросто"забывают" онекоторыхсистемах,которыепродолжаютработать,нонеиспользуютсякомпанией для решения повседневных задач. Что умеет ASM? Первая функциональность, которую обеспечивает ASM-решение, – непрерывный аудит внешних ресурсов. Эта задача особенно важна для компаний, которые активно используют для продвижениянарынкеипривлеченияклиентовинтернет-ресурсы. Созданиелендингадлярекламыи продажновогопродукта–обычнаяпрактика.Номногиеорганизации,ксожалению, забывают,чтоэтиресурсытребуютне меньшеговнимания,чем"основной"вебсайт.КонтрольмногочисленныхлендинговсуспехомосуществляютASM. В качестве примера можно привести опытоднойИТ-компании,котораяимеет широкую филиальную сеть. Ревизия интернет-ресурсовкомпании,проведенная с помощью ASM, показала, что ей принадлежалоболеесотниуженеактуальныхлендингов,причеммногиеизних содержалиформыдляотправкиклиентскихзаявок,которыечастоиспользуются хакерамикакплохоохраняемая"лазейка" винфраструктурупредприятия. ДругаякомпанияблагодаряASMобнаружилавсвоейинфраструктуре"забытую"подсеть,котораяпоявиласьпосле слияниясдругойкомпаниейиобъединенияресурсов. ASM не только ведет мониторинг ресурсов организации, но и проверяет их на уязвимость в режиме 24/7. При этомкаждаяизобнаруженныхуязвимостей оценивается с точки зрения ее актуальности. Решение находит ее в базезнанийMitreATT&CKиотправляет нанеессылкуадминистраторам,предупреждаяопотенциальнойугрозе. ЕщеоднафункциональностьASMсвязана с мониторингом дарквеба, важной части теневого онлайн-рынка, которая используется киберпреступниками для взаимодействияипродажискомпрометированныхданных.Дарквебчастоиспользуетсяприподготовкеатакнасамыеразныеорганизации,иупоминаниеназвания компаниивнем–поводдлятого,чтобы усилитьвниманиек защитекорпоративных информационныхресурсов. Наконец, ASM используется для настроексетевойинфраструктурыипроверки открытых портов. Такой аудит позволяет организации своевременно предотвращатьугрозы,связанныеспроникновением в охраняемый периметр черезвнешниересурсы. Обойтись без ASM? Конечно, организации могут и не использовать ASM для мониторинга своегоохраняемогопериметра.Втаком случае решение этой задачи ложится наплечиИБ-специалистовпредприятия, а следовательно, становится для них значительнойнагрузкой. Делонетольковобилииручныхопераций, которые нужно выполнить для проведениятакогомониторинга.Вкачестве примера можно привести необходимостьдобавлениявбелыйсписокIPадресовиспользуемыхсканеровуязвимости.Особенныхкомпетенций(иконспирации!)требуетработасдарквебом. Наконец, потребуется и аппаратная инфраструктура – как минимум один выделенный сервер в инфраструктуре предприятия,необходимыйдляразвертываниясканеров. Пожалуй, единственное достоинство самостоятельного мониторинга уязвимостей защиты – небольшой бюджет. Расходывэтомслучаемогутоказаться ниже, чем инвестиции в специальное ПО. Но и результативность самостоятельногомониторингапочтинаверняка окажетсятакойженебольшой.l Управляем поверхностью атаки: лучшие практики и подводные камни ем быстрее растет и расширяется организация, тем сложнее становится ИТ-структура и тем больше в ее системе защиты появляется уязвимостей, которыми могут воспользоваться Чхакеры. Любовь Ермилова, менеджер по развитию бизнеса компании MONT Ваше мнение и вопросы присылайте по адресу [email protected] Фото:????
Решение F.A.C.C.T. Attack Surface Management позволяет на основе данных из глобального графа собирать выборку активов, которые относятся к конкретному заказчику. Организация начинает расти. И поскольку этот процесс зачастую не всегда хорошо документируется, люди забывают актуализировать данные в сканере об активах. От общего к частному Attack Surface Management – относительно молодой продукт, он появился в 2021 г. В его основе лежит его более ранняя разработка инженеров F.A.C.C.T. – граф сетевой инфраструктуры, который показывает связь между доменами, IP-адресами, сервер-сертификатами, злоумышленниками, ВПО и другими цифровыми сущностями в глобальном Интернете. Изначально граф создавался для проведения расследований. Например, чтобы по известному домену, который использовали злоумышленники, сразу увидеть все актуальные связи: группировки, используемые TPP, командные центры, IP-адреса и многое, многое другое. Теперь решение F.A.C.C.T. Attack Surface Management позволяет на основе данных из этого глобального графа собирать выборку активов, которые относятся к конкретному заказчику. Именно эти активы будут считаться поверхностью атаки, причем данные будут автоматически обновляться вместе с общим графом киберразведки. Активами на поверхности атаки будет считаться то, что доступно извне: домены, IPадреса, порты, серверные сертификаты, формы логина. При этом ASM совсем не интересует инфраструктура компании внутри ее периметра. Несовершенные сканеры и человеческий фактор Практика показывает, что злоумышленникам неинтересно атаковать основной домен компании, ведь, скорее всего, он хорошо защищен, там установлено актуальное ПО и используются сложные пароли. Гораздо интереснее попробовать проверить какой-либо поддомен, который найдется в DNS, или отдельно стоящий почтовый сервер в другом домене, потому что неосновным активам обычно уделяется гораздо меньше внимания администраторов, вплоть до нуля. Долгое время сканеры уязвимостей были весьма простыми: в них заносился список доменов и IP-адресов, по которым проводилось периодическое сканирование. Такая схема прекрасно работает первые несколько месяцев: сканер находит уязвимости, люди их исправляют. Но потом организация начинает расти. И поскольку этот процесс зачастую не всегда хорошо документируется, люди забывают актуализировать данные в сканере об активах. Получается, что сканер показывает, что все отлично. И все счастливы до момента, когда происходит инцидент. А в процессе расследования выясняется, что просто забыли занести в сканер адрес новых активов – и они оказались в тени. Впрочем, в последнее время сканеры быстро эволюционируют, но по-прежнему часть задач для них остаются нерешаемыми. Attack Surface Management, самостоятельно находя новые активы, может через API автоматически дополнять в сканеры информацию о них. Такая схема уже намного более качественно защищена от человеческого фактора. А дополнительным плюсом, который дает Attack Surface Management, становится информация об утечках, упоминаниях в Дарквебе и вредоносном ПО. Эту информацию обычный сканер уже не может собрать, поскольку она поступает из базы системы кибберразведки F.A.C.C.T. Threat Intelligence, одной из лучших в России и даже в мире. Если ASM обнаруживает новый домен или поддомен, связанный с определенным клиентом, он предлагает включить эти активы в исследуемую поверхность атаки. Компания может либо проигнорировать новые активы, либо, наоборот, подтвердить, что они важны, а значит, должны быть включены в подсвечиваемую для компании часть общего графа. В таком случае Attack Surface Management будет более углубленно исследовать эти активы. Коррекция на пилоте Для Attack Surface Management проблема ложных срабатываний актуальна только во время пилота. Есть два типовых случая. Первый случай – когда Attack Surface Management показывает заказчику активы, которые ему не интересны. Бывает, 34 • СПЕЦПРОЕКТ Attack Surface Management: с чего начинать управление уязвимостями Как правило, проникновения в корпоративные сети не связаны с эксплуатацией уязвимостей нулевого дня или использованием сложных инструментов. Большинство взломов происходит из-за многочисленных неотслеживаемых уязвимостей периметра, таких как непропатченные серверы, некорректные конфигурации баз данных и неконтролируемые теневые ИТ. К Николай Степанов, руководитель направления F.A.C.C.T. Attack Surface Management Фото: F.A.C.C.T.
Важно понимать, что Attack Surface Management – это не строгий учитель, который стоит и требует, чтобы все проблемы были закрыты. Применять Attack Surface Management нужно, когда администратор не может назвать точное количество IP-адресов и поддоменов, находящихся у него в управлении. что от компании отделилась дочерняя структура и часть изначальной инфраструктуры перестала ей принадлежать. Во время пилота с клиентом определяются границы периметра, которые ему точно интересны. Через несколько итераций Attack Surface Management начинает показывать только то, что ожидает заказчик. Второй случай связан с индивидуальностью уровня критичности проблем для каждой компании. Для кого-то отсутствие записи DMARC для домена – это конец света, а где-то об этом вообще никогда не задумывались. Это, конечно, не в полном смысле ложноположительное срабатывание. Но для того чтобы Attack Surface Management корректно работал полностью автоматически, без эксперта, который верифицировал бы все результаты, в таких случаях подключаются разработчики и по запросу корректируют работу алгоритмов. Приоритизация уязвимостей Приоритизация уязвимостей происходит по четырем уровням: критичный, высокий, средний, низкий. У каждого раздела уязвимостей есть свои правила. Например, уязвимости выше 7,5 относятся к критическому уровню опасности. А проблемы с SPF- и DMARC- записями относятся к высокому уровню, поскольку очень много атак сейчас происходят через электронную почту с подменой отправителя, за что как раз и отвечает SPF-запись в DNS. Для разных инфраструктур одна и та же уязвимость может иметь разный уровень критичности. Сейчас ведется работа над тем, чтобы ввести в ASM систему тегов, которая позволить кастомизировать уровень критичности. Например, если для компании критично, что SSL-сертификат скоро истечет, она сможет это отметить. В Attack Surface Management есть специальный модуль, который автоматически переводит выявленные проблемы в список решенных. Например, если была обнаружена уязвимость, заказчик обновил ПО и три последующих дня проблема не проявляется. Сложнее дело обстоит с обнаруженными аккаунтами из утечек, потому что Attack Surface Management не может легально проверить, является ли все еще актуальной пара логина и пароля из утечки. Поэтому такие проблемы заказчик должен закрывать сам. Важно понимать, что Attack Surface Management – это не строгий учитель, который стоит и требует, чтобы все проблемы были закрыты. Это инструмент, который помогает специалистам определить, на что стоить обратить свое внимание. Сценарии развития Применять Attack Surface Management нужно, когда администратор не может назвать точное количество IPадресов и поддоменов, находящихся у него в управлении. То есть когда в инфраструктуре два IP-адреса и три домена, которые можно не задумываясь назвать, будет быстрее и дешевле все проверять вручную. Но как только начинаются сомнения, 23 домена у нас или 25, вот тогда Attack Surface Management и необходим. После начала использования Attack Surface Management для заказчика есть два типовых сценария развития. Первый – начинать смотреть во внешнюю историю: утечки, ВПО, Дарквеб. Эти три модуля подключаются из данных киберразведки. Если компании интересно идти в этом направлении, чтобы улучшить защиту от угроз, которые находятся не внутри его сети, а вовне, то для этого есть киберразведка F.A.C.C.T. Второй сценарий возникает, когда информации о внешних активах хватает и есть желание посмотреть, что происходит внутри периметра. В этом случае решением становится MXDR. Иногда возникает и третий сценарий – когда компания считает, что закрыла все уязвимости, просит проверить, насколько хорошо все защищено. Запрос аудита – это подход очень зрелых компаний, к нему надо тщательно готовиться. Эволюция систем класса ASM Мы видим два пути развития систем управления поверхностью атаки. Первым идут некоторые компании на российском рынке: система ASM автоматизирована, но на стороне вендора работает аналитик, который может готовить отчеты, подсказать или провести собственный анализ и т.п. Результаты при таком подходе оказываются более глубокими, но их подготовка занимает большее время и стоит дороже. Второе направление – это полная автоматизация, компания F.A.C.C.T. идет по этому пути. Все возможные сканеры уязвимостей собираются в единый комплекс и работают полностью автоматически, без участия человека. Цель такого подхода – ускорить процесс, сделать его более надежным и независимым от человека. Какое из этих направлений окажется более правильным и удобным для клиента, покажет время. Заключение Первое, что может взять компания, которая хочет заняться своей безопасностью, чтобы не тратить много финансов и человеческих ресурсов, – это система управления поверхностью атаки. Решение Attack Surface Management подходит компаниям любого размера и любой сферы деятельности. ASM "прокачает" экспертизу специалистов компании и сэкономит их время, необходимое для обнаружения и закрытия потенциальных уязвимостей и киберугроз. l • 35 Управление Уязвимостями www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ F.A.C.C.T. см. стр. 70 NM Реклама Рисунок: F.A.C.C.T.
36 • СПЕЦПРОЕКТ Таблица российских решений Название решения RedCheck Компания-разработчик, страна АЛТЭКС-СОФТ, Россия Компания, предоставившая информацию АЛТЭКС-СОФТ Год появления на российском рынке 2013 Поддержка интерфейса на русском языке Да Поддержка интерфейса на других языках Нет Сертификаты, патенты и лицензии Реестр российского ПО, сертификат соответствия ФСТЭК 4УД Позиционирование Система анализа и контроля защищенности со встроенным сканером уязвимостей Актуальная версия 2.7.0 Актуальная сертифицированная версия 2.6.9 Мониторинг и оценка Единый интерфейс для контроля и управления уязвимостями Да Встроенный сканер уязвимостей Да Поддерживаемые из коробки сканеры уязвимостей Нет Метод сбора информации Агентский, безагентский, в режиме pentest Настраиваемая карточка уязвимости Нет Расписание сканирований Да Определение методов и приоритетов Встроенная база уязвимостей Да Поддерживаемые сервисы для импорта уязвимостей Импорт описаний (правил определений) уязвимостей в формате OVAL Автоматическое обогащение уязвимостей Автоматическое обновление из репозитория описаний уязвимостей OVALdb, частота обновления – ежедневно Поддерживаемые типы активов Рабочие станции, серверы, внешние сервисы на периметре, сетевое оборудование, docker-образы, оборудование АСУ ТП Приоритизация уязвимостей Да Устранение и контроль Встроенные отчеты и дашборды Да Конструктор отчетов Да Контроль за устранением уязвимостей Да Централизованная установка обновлений (патч-менеджмент) Да, только Microsoft Таск-трекинг Нет Коробочная интеграция с ИБ-системами SIEM: Kaspersky KUMA, Neurodat SIEM, R-Vision, Security Vision Другие важные функции Обнаружение активов (Host Discovery) и их инвентаризация. Оценка соответствия политикам и стандартам ИБ. Контроль целостности файлов и папок. Аудит обновлений Архитектура и сопровождение Варианты использования Облако и On-premise Ролевая модель разграничения доступа Да Приобретение Модель тарификации Приобретение и подписная модель Факторы, влияющие на стоимость Редакция (набор функций), количество активов, количество служб сканирования Пробный период 1–12 месяцев по запросу Сайт с подробностями решения https://www.redcheck.ru/
• 37 УпраВление УязВимоСтями www.itsec.ru для управления уязвимостями Vulns.io Enterprise VM R-Vision VM Сканер-ВС 6 Фродекс, Россия R-Vision, Россия Группа компаний "Эшелон", Россия Фродекс R-Vision Группа компаний "Эшелон" 2022 2023 2007 Да Да Да Английский Английский Английский Реестр российского ПО, свидетельство о госрегистрации ПО Реестр российского ПО, сертификат ФСТЭК Реестр российского ПО, сертификат ФСТЭК 4УД Корпоративное решение для больших инфраструктур. Подходит для импортозамещения: сканирует и работает на любых российских ОС. Подходит для компаний, активно использующих контейнеризацию и оркестрацию Система автоматизации процесса управления уязвимостями. Выявляет уязвимости, агрегирует их в единой базе активов, приоритизирует и предоставляет функционал для контроля их устранения Универсальный инструмент для решения широкого спектра задач по тестированию и анализу защищенности информационных систем, а также контроля эффективности средств защиты информации 1.16.2 5.2 6 5.2 6 Да Да Да Да Да Да Нет R-Vision Vulnerability Scanner, MaxPatrol 8, MaxPatrol VM, RedCheck, Tenable SC, Nessus, Nexpose, Qualys, Skybox, OpenVAS, дополнительные интеграции по запросу Нет Агентский и безагентский Агентский и безагентский Безагентский Нет Да Да, управление ложными срабатываниями Да Да Да Да Да Да БДУ ФСТЭК, NVD, Zero Day Initiative, EPSS, источники Linux-дистрибутивов, ПО и сетевых устройств БДУ ФСТЭК, NVD, бюллетени вендоров БДУ ФСТЭК, NVD, базы вендоров ОС, включая российские Информация об активах, расшифровка CVSS, метрик вендоров, связь БДУ ФСТЭК Информация об активах, актуальные данные об уязвимостях Критичность активов, теги активов Рабочие станции, серверы, виртуальные машины, сетевые устройства, docker-образы Рабочие станции, серверы, внешние сервисы на периметре, другие активы Рабочие станции и серверы Да, в том числе по алгоритму ФСТЭК Да, автоматический расчет рейтинга по гибко настраиваемой формуле с возможностью дополнительной пользовательской настройки Да Да Да Да Нет Да,возможность создания пользовательских отчетов и графиков Да Да Да, синхронизация с внешними системами Да Да Нет Да Внешний Встроенный и внешний Внешний С любыми через REST API IRP, SOAR, TIP, SIEM, DLP, антивирусы SIEM Высокая скорость сканирования, инвентаризация активов, проверка обновлений по ФСТЭК, справочник уязвимостей, автоматическое обновление БДУ, мультитенантность, горизонтальное масштабирование, запуск в Kubernetes, API Формула расчета рейтинга. Политики управления уязвимостями. Автоматические действия над уязвимостями: создание задач или инцидентов, изменение статуса. Автоматическое создание задач и синхронизация с задачами ServiceDesk-системы Инвентаризация, подбор паролей, аудит Облако и On-premise On-premise On-premise Да Да Нет Подписная модель Приобретение Подписная модель Количество активов Количество активов, функциональная наполненность решения Количество активов 2 месяца В рамках пилотного проекта 2 месяца https://vulns.io https://rvision.ru/products/vm https://scaner-vs.ru/
38 • СПЕЦПРОЕКТ Название решения MaxPatrol VM Компания-разработчик, страна Positive Technologies, Россия Компания, предоставившая информацию Positive Technologies Год появления на российском рынке 2021 Поддержка интерфейса на русском языке Да Поддержка интерфейса на других языках Английский Сертификаты, патенты и лицензии Реестр российского ПО, сертификат ФСТЭК, патенты Позиционирование Единственное решение с доставкой данных о трендовых уязвимостях за 12 часов. Делает инфраструктуру труднодоступной для хакера, строит процесс управления уязвимостями Актуальная версия 2.0 Актуальная сертифицированная версия 2.0 Мониторинг и оценка Единый интерфейс для контроля и управления уязвимостями Да Встроенный сканер уязвимостей Да Поддерживаемые из коробки сканеры уязвимостей MaxPatrol VM Метод сбора информации Агентский и безагентский Настраиваемая карточка уязвимости Нет, только установка тегов Расписание сканирований Да Определение методов и приоритетов Встроенная база уязвимостей Да Поддерживаемые сервисы для импорта уязвимостей Уязвимости не импортируются, база наполняется экспертами PT ESC Автоматическое обогащение уязвимостей Информацией об активах Поддерживаемые типы активов Рабочие станции, серверы, внешние сервисы на периметре, облачные сервисы и др. Приоритизация уязвимостей Да Устранение и контроль Встроенные отчеты и дашборды Да Конструктор отчетов Да Контроль за устранением уязвимостей Да Централизованная установка обновлений (патч-менеджмент) Нет Таск-трекинг Внешний Коробочная интеграция с ИБ-системами IRP, SOAR, SIEM, EDR Другие важные функции Asset Management, Compliance Control, приоритизация по методологии ФСТЭК, отображение трендовых уязвимостей, установка на отечественные ОС с возможностью сканировать Windows-системы, веб-интерфейс, PDQL, контроль устранения уязвимостей, сканирование "черным" и "белым" ящиком Архитектура и сопровождение Варианты использования Облако и On-premise Ролевая модель разграничения доступа Да Приобретение Модель тарификации Подписная модель Факторы, влияющие на стоимость Количество активов, кластеризация, хостовые агенты Пробный период Демо-лицензия до 3 месяцев Сайт с подробностями решения https://www.ptsecurity.com/ru-ru/products/mp-vm/
• 39 Управление УязвимоСтями www.itsec.ru ScanFactory (Сканфэктори) Security Vision VM SECURITM ООО "Сканфэктори", Россия Security Vision, Россия ООО "СЕКЪЮРИТМ", Россия ООО Сканфэктори, Россия Security Vision ООО "СЕКЪЮРИТМ" 2021 2020 2021 Да Да Да Нет Английский, добавление любых языков Нет Реестр российского ПО Реестр российского ПО, сертификат соответствия ФСТЭК УД4, сертификат соответствия ОАЦ при Президенте Республики Беларусь Реестр российского ПО, свидетельство о регистрации прав на ПО Сканер внешнего периметра Средство обнаружения и устранения технических уязвимостей с применением гибкого платформенного подхода Центр управления всеми организационными процессами службы ИБ: риски, комплаенс, активы, VM, задачи, метрики, опросы 5.х 1.3.891 5.х Да Да Да Да Да Нет Security Vision Vulnerability Scanner, MaxPatrol 8, MaxPatrol VM, XSpider, Nessus, Nmap, Qualys, Redcheck, Tenable.IO, Tenable.SC, OpenVas, Scan Factory, Nexpose и др. Qualys, Nessus, RedCheck, Nmap (vulners.nse), OpenVas, Kaspersky, XSpider, MaxPatrol 8, MaxPatrol VM, Scan Factory Безагентский Агентский (опционально) и безагентский Безагентский Да Да Нет Да Да Нет Да Да Нет БДУ ФСТЭК БДУ ФСТЭК, NVD NIST, аналитические сервисы, бюллетени и базы вендоров и др. Нет CVE обогащаются БДУ, информация об активах Информацией об активах, рисках, инцидентах, событиях ИБ, внешние интеграции. Автоматическое обновление из репозитория, метрики, связь с БДУ ФСТЭК Информацией об активах, база CPE Внешние сервисы на периметре Рабочие станции, серверы, внешние сервисы на периметре, облачные сервисы и др. Рабочие станции, серверы, внешние сервисы на периметре, облачные сервисы и др. Да Да, со встроенным редактором расширенных возможностей для создания своих алгоритмов и дополнительной пользовательской настройки Да Да Да, с возможностью создания своих Да Нет Да, с расширенными возможностями Нет Да Да, интеграция с внешними системами Да Нет Да Нет Нет Встроенный и внешний Встроенный и внешний С любыми через REST API IRP/SOAR, TIP/UEBA, RM(риски), CM(комплаенс), AM(активы), BCM, КИИ (187-ФЗ), REST API, др. Собственный функционал IRP / SOAR Telegram-бот для уведомлений, верификация уязвимостей силами вендора Обнаружение активов и их инвентаризация. Применение внешних источников экспертизы. Управление политикой устранения. Расчет рейтинга. Автоматические действия над уязвимостями. Встроенные редактор для модификации метрик, конструктор коннекторов, редакторы объектов, аналитики и отчетов Объединение результатов инфраструктурных сканеров, сканеров кода, веб-приложений, периметра и облаков. Оценка уязвимостей через критичность систем и процессов, в т.ч. по Методике ФСТЭК. Механизмы принятия рисков. VM – компонент единой системы управления процессами ИБ SaaS и On-premise MSSP и On-premise Облако и On-premise Да Да Да Подписная модель Приобретение и подписная модель Приобретение и подписная модель Количество активов, наличие поддержки Продукты, коннекторы, режим резервирования. мультиарендность Вариант поставки (cloud/on-premise), модули, количество активов 2 недели 1–3 месяца, помощь экспертов Security Vision в пробном периоде. Community и marketplace для заказчиков Community-версия без временных ограничений https://scan-factory.ru https://www.securityvision.ru/products/vm/ https://securitm.ru Представленные в таблице данные предоставлены соответствующими компаниями. Редакция выполнила работу по сбору данных, но не проверяла их соответствие действительности.
Александр Дорофеев, Эшелон Технологии: Все зависит от того, как организация реализует оценку защищенности, являющуюся самой критичной операцией в управлении уязвимостями. Если оценка защищенности проводится на уровне сети, ОС, СУБД, WEB, прикладного ПО, а также в ходе оценки проверяется и навыки пользователей и аспекты физической безопасности, то тогда процесс Vulnerability Management позволит видеть общую картину подверженности организации угрозам информационной безопасности. Николай Казанцев, SECURITM: Корректно, ведь VM – это сканеры, а они видят только техническую часть вопроса. Уязвимости в широком смысле есть и в людях, и в процессах, и в архитектуре. VM – это лишь часть процесса управления рисками ИБ, хоть и очень важная. Часто техникоцентричные службы ИБ забывают об этом. Владимир Михайлов, Фродекс: VM дает картину уязвимостей, которые можно технически детектировать "здесь и сейчас" в инфраструктуре компании. При этом организация может быть подвержена нетехническим угрозам, которые VM определить не в состоянии (саботаж, внутренние учетки, архитектурные недостатки и пр.), но может подсветить слабые места инфраструктуры, устранение которых поможет минимизировать подверженность угрозам в целом. Роман Овчинников, Security Vision: И да, и нет. Как класс решения, Vulnerability Management показывает наличие "дыр" для реализации угрозы и позволяет организовать процесс их обработки. С другой стороны, данные решения не учитывают используемые СЗИ и другие контроли, которые влияют на возможность эксплуатации конкретной уязвимости. Для получения целостной картины нужен комплексный процесс, включающий получение информации из разных источников и реализацию процедур оценки рисков. Таким образом, сам по себе VM не позволяет показать целостную картину, но является неотъемлемой частью для ее создания. Константин Саматов, АРСИБ: Если процесс Vulnerability Management построен правильно, то это неверно, так как в рамках процесса управления уязвимостями должны происходить: l Во-первых, оценка применимости выявленных уязвимостей, в рамках которой учитываются угрозы и возможности их реализации (в самом начале процесса управления уязвимостями). l Во-вторых, применение компенсирующих мер для исключения возможности эксплуатации данной уязвимости при отсутствии возможности ее устранить (например, если отсутствуют соответствующие обновления программного обеспечения) – на завершающих стадиях процесса управления уязвимостями. Андрей Селиванов, R-Vision: Полнота общей картины защищенности организации зависит от степени покрытия ее инфраструктуры системами защиты. Одним из ключевых инструментов, позволяющих контролировать и минимизировать риски, связанные с ИБ, является Vulnerability Management. Цель VM – повышение общего уровня защищенности компании при помощи анализа и устранения конкретных уязвимостей. Однако для создания комплексной системы защиты информации необходимо использовать технологию VM в связке с остальными технологиями защиты информации, чтобы повысить уровень защищенности ИТ-инфраструктуры организации от потенциальных угроз. Сергей Уздемир, АЛТЭКС-СОФТ: В общем и в частности качество VM является "лакмусовой бумажкой" процессов, связанных с ИБ. В общем, потому что реализация VM находится в прямой зависимости от качества управления и взаимодействия всех служб организации, предполагает решение множества смежных задач. И частная оценка уязвимостей, как результат VM, может быть Корректно ли считать, что Vulnerability Management дает лишь ограниченный взгляд на картину уязвимостей, но не показывает общую подверженность организации угрозам? 40 • СПЕЦПРОЕКТ Эволюция систем управления уязвимостями. Круглый стол истемы класса Vulnerability Management (VM) постоянно развиваются. У них есть устоявшаяся, традиционная функциональность, но есть вызовы, на которые надо реагировать. По просьбе редакции журнала “Информационная безопасность” разработчики VM-решений поделились мнением о влиянии наиболее актуальных Стрендов на функциональность систем. Александр Дорофеев, генеральный директор АО “Эшелон Технологии” Владимир Иванов, основатель “Сканфэктори” Николай Казанцев, CEO SECURITM Николай Лишке, директор центра кибербезопасности АО “Эшелон Технологии” Владимир Михайлов, руководитель департамента перспективных проектов, “Фродекс” Андрей Никонов, главный аналитик, “Фродекс” Павел Попов, лидер практики продуктов для управления уязвимостями, Positive Technologies Константин Саматов, член Правления Ассоциации руководителей служб информационной безопасности Андрей Селиванов, продукт-менеджер R-Vision VM Николай Степанов, руководитель направления F.A.C.C.T. Attack Surface Management Дмитрий Овчинников, главный специалист отдела комплексных систем защиты информации, “Газинформсервис” Роман Овчинников, руководитель отдела исполнения Security Vision Сергей Уздемир, заместитель генерального директора “АЛТЭКС-СОФТ” по ИТ
трансформирована в интегральную оценку защищенности актива или всей ИС от угроз безопасности информации, связанных с эксплуатацией уязвимостей. По динамике этого показателя можно в том числе оценивать успешность выполнения требований ИБ в целом. Дмитрий Овчинников, Газинформсервис: Современный продукт VM выдает полную и объемную информацию про наличие существующих уязвимостей в сканируемых устройствах. Однако он не учитывает уязвимости нулевого дня, ошибки в настройках и человеческий фактор. Он не защищает от методов социальной инженерии. Правильнее считать VM одним из инструментов. Необходимо оперативно обновлять устройства, закрывать уязвимости и правильно интерпретировать полученную информацию. Павел Попов, Positive Technologies: Полный взгляд на картину уязвимостей – не то же самое, что понимание общей картины подверженности организации угрозам. Существует множество различных классов решений по информационной безопасности: SIEM, NTA, NGFW, EDR, СЗИ от НСД, САВЗ и многие другие. Но даже установка этих средств не может дать полную картину защищенности. Недостаточно купить, установить и корректно настроить систему. Дальше дело за процессами и экспертами, принимающими в нем участие. Согласованность всех этапов между заинтересованными лицами, использование эффективных инструментов, устранение уязвимостей, соблюдение договоренностей на исправление и контроль устранения могут дать реальный результат. Николай Степанов, F.A.C.C.T.: Корректно. Защита инфраструктуры – комплексный процесс, где каждое решение выполняет свою функцию. VM прекрасно подходит для компаний, которые могут их поддерживать, постоянно актуализируя список активов на сканировании. Но стоит также обратить внимание на различные утечки корпоративных учетных записей, тренинги сотрудников, защиту почты и т.д. Самая уязвимая часть в безопасности – это не компьютер, это человек. Сергей Уздемир, АЛТЭКС-СОФТ: VM это – непрерывный регламентированный цикл мероприятий, что не исключает немедленной экстраординарной реакции на особые обстоятельства. Они могут быть связаны как с защищаемыми активами (изменения в инфраструктуре, переход на новое ПО и оборудование), так и с переоценкой угроз (выявление новых уязвимостей или новых способов эксплуатации старых, трендовые уязвимости). Павел Попов, Positive Technologies: Абсолютно корректно! Сам процесс должен быть периодическим, так как уязвимости появляются каждый день, а ИТ-инфраструктура часто меняется. Существуют также трендовые уязвимости, которые выявляет система MaxPatrol VM. Информацию о них мы доставляем за 12 часов. Такие уязвимости злоумышленники уже используют в атаках или будут в ближайшее время, поэтому их нужно быстро устранять или принимать компенсирующие меры. Если их не обнаружить вовремя, то промедление может негативно сказаться на безопасности всей инфраструктуры. Владимир Михайлов, Фродекс: Сегодня это уже не так. Необходим непрерывный поиск и устранение уязвимостей с актуализацией при каждом изменении инфраструктуры, обновлении или изменении состава программного обеспечения и тем более при появлении информации о новых уязвимостях. Любой из этих триггеров должен автоматически запускать сканирование затронутого сегмента инфраструктуры, информировать ответственное лицо при обнаружении новых угроз, а в идеале – автоматически принимать меры для устранения. Александр Дорофеев, Эшелон Технологии: Все зависит от наличия специалистов и соответствующего инструментария. Применение современных VM-инструментов, например Сканер-ВС 6, позволяет узнавать о появлении новых уязвимостей на ежедневной основе, что в свою очередь, позволяет специалистам подразделений по информационной безопасности проактивно закрывать уязвимости и снижать риск подверженности атакам зловредов, использующих уязвимости. Андрей Селиванов, R-Vision VM: VM – циклический процесс сбора информации об активах и уязвимостях с последующей их приоритизацией и устранением. Цикличность процесса позволяет поддерживать модели активов в актуальном состоянии даже в условиях динамично изменяющейся корпоративной инфраструктуры. Николай Степанов, F.A.C.C.T.: В большей степени корректно. Если ваши администраторы не могут сказать точно, сколько доменов, поддоменов, IP-адресов они обслуживают, VM превращается из помощника во вредителя. Сканируя только часть инфраструктуры, он дает ложное чувство безопасности, а люди по своей природе могут забывать обновлять список для сканирования. Актуализация и проверка списков на сканирование должна быть регулярной (раз в день или хотя бы раз в неделю), чтобы VM не терял свою эффективность. Николай Казанцев, SECURITM: Мы узнаем об уязвимостях, когда о них узнает наш сканер, и в этом смысле, конечно, VM – процесс реактивный. Но ведь и превентивные меры никто Корректно ли считать, что Vulnerability Management носит периодический и реактивный характер в условиях динамично изменяющейся корпоративной инфраструктуры? • 41 Управление Уязвимостями www.itsec.ru Изображение: ГРОТЕК"
не отменял – сегментацию, WAF, SIEM, организационные процедуры тестирования новых систем и продуктов. Все это позволяет, не зная о наличии уязвимостей, снизить вероятность их эксплуатации или возможные негативные последствия. Подобные защитные меры выходят за рамки VM, но ведь и VM – это лишь часть общего процесса управления рисками ИБ, и рассматривать его нужно в комплексе со всеми другими защитными мерами. Константин Саматов, АРСИБ: Концептуально – это не так, процесс должен быть непрерывным. Однако на практике действительно в большинстве случаев выявление и устранение уязвимостей носит периодический характер, так как ресурсы ограниченны, а современные решения Vulnerability Management – это в основном сканеры уязвимостей, которые не могут автоматизировать все подпроцессы в управлении уязвимостями. В части реактивности и проактивности, по моим наблюдениям, все сугубо индивидуально, в каждой организации реализовано по-своему. Дмитрий Овчинников, Газинформсервис: Современные средства VM и автоматизация процессов позволяют проводить регулярные и частые сканирования, что позволяет получать актуальную информацию даже в условиях динамично изменяющейся корпоративной инфраструктуры. Надо помнить о том, что ИБ – это прежде всего непрерывный процесс, который надо поддерживать каждый день. Поэтому динамичные изменения не являются помехой для использования VM. Роман Овчинников, Security Vision: Периодический характер позволяет регулярно актуализировать информацию по всей инфраструктуре. Однако при использовании динамичной инфраструктуры необходимо дополнительно встраивать процедуры Vulnerability Management в DevOps-процессы компании. Такой подход позволит оперативно реагировать на возникающие угрозы, проявляющиеся при изменении ИТ-ландшафта. Сергей Уздемир, АЛТЭКС-СОФТ: Результатом использования решений класса VM является установление приоритетов исправления уязвимостей, а также контроль их устранения или реализации компенсирующих мер, таких как более строгое конфигурирование или сокращение поверхности атаки. Устранение уязвимостей – это не всегда именно ручное вмешательство, однако его реализация, как правило, лежит в области применения других систем, SCM или Patch Management. Роман Овчинников, Security Vision: ИТ-инфраструктура компаний даже среднего уровня зачастую представлена тысячами устройств разного вида (АРМ пользователей, серверы, сетевое оборудование и СЗИ, СХД и т.д.). Обеспечить качественное и своевременное исправление уязвимостей на таких масштабах ручным способом невозможно. Для этих целей используются различные средства автоматизации. Например, можно использовать интеграцию с репозиториями, где хранятся проверенные пакеты обновлений, в связке с решениями классов AM/ITAM/CMDB, что позволит запускать процессы устранения уязвимостей автоматизированно. Николай Лишке, Эшелон Технологии: В большинстве случаев – да. Даже если уязвимость можно закрыть, просто обновив пакеты определенного ПО, обновление необходимо протестировать и только затем принимать решение об установке в продуктивной среде. В случае, если требуется внедрять компенсирующие меры, без ручного вмешательства ИБи ИТ-специалистов не обойтись. Андрей Селиванов, R-Vision: Корректно выстроенный процесс VM предполагает автоматизацию на большинстве этапов циклов процесса. Однако полностью исключить ручное вмешательство на практике не представляется возможным. Особенно на этапах устранения уязвимостей, которые часто требуют тестирования работоспособности систем после установки обновлений, и в процессе приоритизации некоторых особо критичных уязвимостей, требующих срочного устранения. Николай Степанов, F.A.C.C.T.: Верно. Каждый бизнес имеет свои ограничения. VM должен показывать риски, а человек – принимать решение по работе с этими рисками. Случаются ситуации, когда риск ошибки во время исправления проблемы больше, чем если оставить проблему нерешенной. Константин Саматов, АРСИБ: Исправление выявленных уязвимостей в основном действительно осуществляется в ручном режиме. Современные решения Vulnerability Management зачастую лишь выявляют уязвимости, а установка обновлений или разработка и применение компенсирующих мер для нейтрализации уязвимости происходит уже при участии человека. Владимир Михайлов, Фродекс: В зрелых VM-решениях присутствует функционал Patch Management и даже автоматизация этого процесса. В зависимости от степени принятия рисков организация сама решает, как этим функционалом пользоваться, в ручном или автоматическом режиме. При этом нужно помнить о важности предварительной проверки процесса обновлений критичных ресурсов. Отчасти это решается заведением в VM-систему активовдвойников, позволяющих оперативно протестировать процесс обновления на точной копии критичного ресурса. Корректно ли считать, что в системах класса Vulnerability Management в большинстве случаев предполагается ручное вмешательство для исправления выявленных уязвимостей? 42 • СПЕЦПРОЕКТ Изображение: ГРОТЕК"
Павел Попов, Positive Technologies: Автоматизация, конечно, отличный подход, но давайте представим ситуацию: найдена критическая уязвимость ОС, на которой установлено бухгалтерское ПО. Проводится автопатчинг, после которого программа перестает работать, потому что бухгалтерское ПО не поддерживает новую версию ОС. И как часто бывает, бэкап делался полгода назад, а именно сегодня нужно проводить оплату. Кто будет виноват? Решение об устранении уязвимости принимает ИБ, тестирует обновление – ИТ. Никто не отменял процесс проверки и установки обновлений в ИТ-департаменте. А в какие сроки это все будет происходить, закладывается во время формирования процесса VM. Поэтому в большинстве случаев VM-процесс не исключает ручное вмешательство. Дмитрий Овчинников, Газинформсервис: Совсем не обязательно, что устранение уязвимостей будет производиться в ручном режиме. Зачастую современные средства автоматизации позволяют массово управлять обновлениями. Однако это не исключает тех случаев, когда какие-либо устройства или системы надо будет обновлять вручную. Это может быть связано со специфическим настройками, сбоями или характером работы самой системы. Сергей Уздемир, АЛТЭКС-СОФТ: Vulnerability Management решает проблему, если эти цепочки поставки (поставщики услуг, контрагенты, смежные системы) входят в защищаемый контур с общим управлением ИБ или они самостоятельно реализуют процесс VM, есть установленные критерии доверия и оценки соответствия (compliance) этого процесса. Павел Попов, Positive Technologies: Vulnerability Management позволяет искать известные уязвимости в том ПО, которое используется при разработке своих продуктов вендорами. Нужно также использовать продукты для анализа исходного кода. В идеале средство автоматизации поиска уязвимостей должно интегрироваться со средствами анализа исходного кода. Андрей Никонов, Фродекс: Можно выделить следующие механизмы VM-решения для защиты цепочек поставки: 1. Проверка обновлений программного обеспечения – VM-решение должно подсветить соответствующий статус обновления, например, по базе ФСТЭК России. 2. Сканирование docker-образов, используемых в организации для запуска приложений. 3. Сканирование зависимостей и сторонних библиотек (Dependency Check) при разработке ПО. Константин Саматов, АРСИБ: Vulnerability Management влияет на решение проблемы защиты цепочки поставок следующим образом. Во-первых, позволяет выявить уязвимости в программном обеспечении и компонентах информационного ресурса, поступающих от поставщиков. Во-вторых, управление уязвимостями включает в себя анализ и контроль цепочек поставки (как минимум какойто части этой цепочки), включая проверку безопасности поставщиков. В-третьих, управление уязвимостями способствует формулированию требований по безопасности для поставщиков, что помогает снизить риск внедрения уязвимых компонентов в цепочки поставки. Николай Лишке, Эшелон Технологии: Например, внедренный процесс VM в компании – разработчике ПО позволит находить и закрывать уязвимости в среде разработки, что, в свою очередь, снижает риск компрометации продуктов, которые поставляются этой компанией на рынок. Роман Овчинников, Security Vision: Первым шагом в обеспечении безопасности цепочки поставок является выявление любых потенциальных слабых мест в системе. Разработка и повсеместное внедрение процесса Vulnerability Management, включая процедуры приобретения и обновления ПО, позволит выявлять потенциальные угрозы. А использование данных TI в процессе Vulnerability Management дополнительно повысит эффективность и оперативность таких мероприятий. Дмитрий Овчинников, Газинформсервис: VM – это один из инструментов, который повышает защищенность компании. Надо не только выявлять существующие уязвимости в инфраструктуре, но и своевременно устранять их, проверять системы на наличие закладок и бэкдоров. Подобный подход снизит вероятность того, что через компанию смогут осуществить атаку на цепочку поставок. А вот от внешней атаки, совершенной подобным образом, будет защищать совершенно другой класс продуктов. Андрей Селиванов, R-Vision: Непрерывность работы всех бизнеспроцессов компании стоит на первом месте у бизнеса и является приоритетом среди задач ИБ-службы. Благодаря корректно выстроенному процессу VM совместно с другими процессами обеспечения ИБ в организации снижается общий уровень риска нарушения работоспособности бизнес-процессов, особенно тех, что прямо или косвенно связаны с работой ИТ-инфраструктуры компании. R-Vision VM помогает решать подобные задачи по защите цепочек поставок, имея функциональные возможности не только для построения карты взаимосвязей активов и бизнес-процессов, но и для оценки степени риска нарушения бизнес-процессов. R-Vision VM предоставляет возможность мониторинга состояния бизнес-процессов организаКаким образом Vulnerability Management решает проблему с защитой цепочек поставки? • 43 Управление Уязвимостями www.itsec.ru Изображение: ГРОТЕК"
ции, таким образом ИБ-служба может получать данные о реальном состоянии каждого процесса и своевременно оценивать уровень угрозы в случае обнаружения на них уязвимостей. Николай Степанов, F.A.C.C.T.: Сложный вопрос. Если у вас есть понимание, что ваш партнер плох в безопасности и вы можете ему помочь (сканируя его с его разрешения) – прекрасно. Впрочем, вы не обязаны это делать, и если что-то произойдет с вами, виноватым будет он. Но стоит ли чувство правоты тех нервов, денег и времени, которые потратятся во время инцидента? Если соседний дом горит, лучше помочь с тушением, чтобы потом не пришлось и у себя делать ремонт. Андрей Никонов, Фродекс: Принципы безопасной разработки основываются на опыте инцидентов с уязвимостями в приложениях. То есть всегда сначала находились и эксплуатировались уязвимости, а затем разработка менялась так, чтобы избегать их появления как можно раньше (shift left). И вряд ли это изменится в будущем – VM всегда будет подсказывать, как создавать более безопасное ПО. Кроме того, есть угрозы, которые не зависят от разработчиков, например ошибки конфигурирования систем и приложений. Роман Овчинников, Security Vision: Современные процессы безопасной разработки надежно связаны с устранением уязвимостей и не исключают друг друга. За счет гибкой интеграции ИТрешений и процессов ИБ можно достигнуть настоящей эффективности и создать экосистему, в которой решения будут дополнять друг друга. Поэтому актуальность применения VM не только не теряется, но глубже встраивается в DevSecOps. Павел Попов, Positive Technologies: Нет, так как безопасная разработка не может полностью закрыть появление новых уязвимостей в продуктах. Если была найдена новая уязвимость, а клиент не обновился на последнюю версию ПО, то необходима система, которая покажет эти уязвимости в конкретной версии продуктов. Кроме того, если относить конфигурационное несоответствие к процессу Vulnerability Management, то проверка по compliance control не закрывается безопасной разработкой. Андрей Селиванов, R-Vision: Безопасная разработка (DevSecOps) направлена на устранение уязвимостей еще на этапе разработки ПО, однако она не является гарантом обеспечения полноценной защиты. Злоумышленники непрерывно ищут новые уязвимости в популярном и широко распространенном ПО. Поэтому необходимо обеспечивать дополнительную защиту при помощи VM-систем, которые служат для обнаружения и устранения уязвимостей, помогая службам ИБ и ИТ снизить риски по их эксплуатации до минимума. Таким образом, наряду с DevSecOps внедренный процесс VM усиливает защиту от вероятных атак, которые могут повлечь за собой потери для бизнеса. Константин Саматов, АРСИБ: Нет, не потеряет. Следует учитывать, что, несмотря на большую пользу РБПО, полностью исключить наличие уязвимостей в исходном коде невозможно. Часть уязвимостей может появиться уже непосредственно в процессе эксплуатации информационного ресурса. Многие приложения используют сторонние компоненты, которые не всегда удается проанализировать разработчикам программного обеспечения. Ну и самое главное, управление уязвимостями не ограничивается только разработкой кода, оно также включает в себя оценку и защиту конфигураций и других сущностей. Дмитрий Овчинников, Газинформсервис: Продукты подобного класса никогда не потеряют своей актуальности. Человеку свойственно ошибаться, потому ошибки в ПО и ОС всегда были и будут. По мере того как сложность разрабатываемых программных продуктов растет, вероятность наличия в них уязвимостей тоже возрастает. Процесс налаживания безопасной разработки просто позволяет держать процент ошибок в допустимых пределах, но полностью не устраняет факторы их появления. Николай Лишке, Эшелон Технологии: Во-первых, не все организации – разработчики, не всем нужен AppSec и DevSecOps. Во-вторых, как может потерять актуальность один из компонентов с внедрением комплекса мероприятий, направленных на повышение защиты? VM является неотъемлемой частью, а возможно даже и базой для построения последующих мероприятий по обеспечению защищенной разработки. Мы не можем говорить о процессе безопасной разработки до тех пор, пока у нас не обновлены первичные инструменты разработки: GitLab, Nexus, Kubernetes. Сергей Уздемир, АЛТЭКС-СОФТ: Нет, не потеряет, одно не исключает другого. Работает принцип "доверяй, но проверяй". Более того, внедрение процессов безопасной разработки в условиях все возрастающей сложности и количества заимствованного (встроенного) кода и ПО не всегда приводит к уменьшению количества уязвимостей и их критичности, а скорее, является критерием качества процессов реагирования разработчиком на выявляемые ошибки и уязвимости, например насколько быстро они устраняются в обновлениях безопасности. Николай Степанов, F.A.C.C.T.: Пока системы пишут люди, люди будут делать ошибки. VM – это защита от таких ошибок. Роман Овчинников, Security Vision: Этот тренд уже прошел пик своей актуальности и подтверждается статистикой: формирование экосистем из решений одного вендора дополняется платформенным подходом. В рамках расширения функционала можно ожидать востребованность интеграции решений VM с процессами управления активами и инвентаризацией, комплаенса и оценки рисков, реагирования на инциденты и др. Андрей Селиванов, R-Vision: В будущем будет востребовано привлечение технологий ИИ к обработке и приоритизации уязвимостей в ИТ-инфраструктурах с большим количеством активов. Результатами такой обработки могут быть наиболее точно установленные уровни критичности уязвимости, вычисленные вероятности эксплуатации уязвимости, основанные на уже имеющихся данных об уязвимости и текущей конфигурации ИТ-инфраструктуры. В настоящее время активно прослеживается тренд на создание экосистем, в числе которых и системы класса VM. Например, связка решений VM и TIP дает возможность обогащать данные об уязвимостях сведениями из различных источников об угрозах. Такой комплекс систем будет выявлять попытки проникновения в системы, обнаруживать целенаправленные атаки на ранних этапах и позволит быть в курсе актуальных угроз. А сочетание решений VM и XDR помогает в обнаружении уязвимостей и автоматическом реагировании на них непосредственно на конечных устройствах. Какая новая функциональность будет востребована в системах Vulnerability Management в ближайшие 2–3 года? Есть ли тренд на слияние VM с другими классами ИБ-систем? Потеряет ли актуальность Vulnerability Management с повсеместным внедрением процессов безопасной разработки? 44 • СПЕЦПРОЕКТ
Сергей Уздемир, АЛТЭКС-СОФТ: Самая востребованная функция VM лежит не в плоскости VM как такового, а на уровень ниже – в области возможно более корректного и полного детектирования уязвимостей. Идея реализации VMрешения без сканера с базой уязвимостей несостоятельна. Поэтому наиболее востребованная функция VM-средств – это оценка применимости и критичности уязвимостей и их переопределение "на земле" в конкретных системах заказчиков, приоритизация устранения и оценка защищенности активов на ее основе. Тренд на слияние VM-решений с другими системами в настоящее время не наблюдается, хотя можно говорить о более тесной интеграции с SCM, SIEM, PM. Александр Дорофеев, Эшелон Технологии: VM-продукты будут обрастать аналитическими функциями, позволяющими ИБ-специалистам максимально быстро приоритизировать уязвимости в зависимости как от внешних факторов (CVSS, EPSS, наличие эксплойтов и т.п.), так и внутренних (доступность хоста из Интернета, критичность актива и т.п.). Возможности интеграции с внешними системами, такими как трекеры задач, SIEM, конечно, будут расширяться. Дмитрий Овчинников, Газинформсервис: По мере роста количества объектов защиты и усложнения корпоративных сетей, роста систем ИБ, применяемых для защиты, ключевым фактором будет являться возможность автоматизации, возможность встраивания процесса VM в другие системы ИБ. Кроме того, не надо забывать об удобстве использования. Возможно, в будущем это будет просто модулем в SOAR, но не все компании готовы тратить свой бюджет на подобные корпоративные игрушки. Поэтому для средних и небольших компаний продукт класса VM будет еще долго популярен. Возможно, самый успешный продукт перейдет в статус Open Source и будет доступен для всех, но такая модель распространения не всегда себя оправдывает для продуктов в части ИБ. Андрей Никонов, Фродекс: Могу озвучить функциональность, которая востребована уже сейчас: l автоматизация устранения уязвимостей; l глобальная база данных проверенных обновлений, поддерживаемая множеством VM-вендоров и регулятором; l рекомендательные системы, помогающие выполнять компенсирующие меры. Что касается слияния, то VM – это процесс, который довольно сложно встроить в ИБ-системы других классов. Такие попытки будут со стороны вендоров экосистем ИБ, но насколько они будут успешны, покажет время. Павел Попов, Positive Technologies: 1. ML – когда продукт сам подсказывает, куда смотреть, на чем делать акцент и как правильно работать с VM-системой. 2. 100%-е покрытие ключевых, целевых и периметровых систем пользователей в разрезе поиска уязвимостей. 3. Возможность ручного патч-менеджмента и работа ИТ- и ИБ-специалистов в одном продукте. Есть тренд на слияние с теми классами ИБ-систем, которые будут развиваться в следующих направлениях: l Появление автопилотов. Они объединяют несколько классов ИБ-решений в один большой продукт, который поможет закрыть большинство атак, направленных на инфраструктуру. l Интеграция с SIEM, EDR, Container Security и инструментами для поиска уязвимостей в исходном коде. Константин Саматов, АРСИБ: Решения Vulnerability Management в процессе функционирования собирают много сопутствующей информации (например, данные о конфигурации), которая может быть использована в иных системах. Поэтому запрос со стороны заказчика на возможность применения решений Vulnerability Management в других системах есть. Однако имеющиеся на рынке решения, как правило (по крайней мере, я пока не видел других), не позволяют автоматизировать обмен информацией с другими классами ИБ-систем. Николай Казанцев, SECURITM: 1. Агрегация. Инфраструктура, периметр, код, веб-приложения, облака – везде уязвимости. И чем больше размывается ИТ-ландшафт компании, тем важнее становятся инструменты для агрегации сведений об уязвимостях из различных источников (сканеров). 2. Обогащение и приоритизация. Уязвимостей бесконечно много, все не устранить. Нужно выбирать, и поэтому потребность в обогащении результатов работы сканеров, позволяющая ответить на вопрос "Что действительно важно?" будет только расти. Автоматическое обогащение как из внешней среды, так и из внутренней инфраструктуры компании, например, сведениями об ИТ-активах и инфраструктуре, позволяющими оценить реальные и маловероятные цепочки атак. Владимир Иванов, Сканфэктори: Управление уязвимостями – один из основных процессов в ИБ, на мой взгляд, не нуждается в серьезных изменениях, а лишь в автоматизации. На сегодняшний день вмешательство человека необходимо на каждом этапе – при поиске активов, сканировании уязвимостей, приоритизации результатов, создании человекопонятных рекомендаций, создании заявок на устранение, контроле устранения, отчетности. Думаю, в ближайшие годы мы увидим включение искусственного интеллекта на каждом этапе. Николай Степанов, F.A.C.C.T.: Мы видим, что сейчас VM пытаются решить две свои главные проблемы: l автоматическую актуализацию активов, сливаясь с другими решениями типа ASM; l узкий диапазон, пытаясь добавить в своей продукт различные проблемы, которые не являются уязвимостями (утечки, фишинг и т.п.). l • 45 Управление Уязвимостями www.itsec.ru Изображение: ГРОТЕК" Ваше мнение и вопросы присылайте по адресу [email protected]
– Чем вас привлекла область информационной безопасности и машинного обучения? – После окончания вуза я решил связать свою жизнь с наукой и поступил в аспирантуру. Успешно защитил кандидатскую диссертацию и на данный момент уже более 15 лет занимаюсь применением искусственного интеллекта в системах безопасности. Кибербезопасность стала неотъемлемой частью нашей повседневной жизни, и я видел в ней огромное поле для развития и применения моих навыков. С 2021 г. руковожу направлением машинного обучения в "АВ Софт". С командой решаем весьма специфические задачи: l обнаружение фишинга, спама, вредоносного ПО; l анализ поведения и выявление аномалий; l обеспечение безопасности моделей машинного обучения; l системы распознавания и синтеза речи; l системы генерации контента и др. Меня вдохновляет возможность применять инновационные подходы и технологии для решения сложных проблем в области кибербезопасности и мотивирует на постоянное обучение и развитие. – Какие инструменты и методы машинного обучения вы применяете в своей работе для ИБ? – Мы с командой стараемся использовать как SOTA-решения (State Of The Art, новые, передовые), так и проверенные и зарекомендовавшие себя алгоритмы. Например, в системе защиты от целенаправленных атак AVSOFT ATHENA для обнаружения и классификации вредоносных файлов мы используем как классические алгоритмы, построенные на признаках, так и более продвинутые техники с использованием компьютерного зрения на базе сверточных сетей (CNN) и трансформеров (Transformers) для анализа структуры файла. Для анализа аномального поведения сетевых узлов и пользователей мы используем методы кластеризации и ассоциативные правила. Мы также активно применяем технологии обработки естественного языка для анализа текстовых данных. В AVSOFT ATHENA машинное обучение – это полноценный инструмент проверки наравне с антивирусами и песочницами, он дополняет их и повышает точность вердикта, а также позволяет обнаружить 0-day-атаки, с которыми традиционные методы сигнатурного анализа не справляются. – Можете ли вы привести практические примеры использования машинного обучения? – Один из наших флагманских продуктов – AVSOFT KAIROS предназначен для защиты электронной почты от фишинга и спама. В основе его используются достаточно инновационные подходы и техники на базе ИИ. Так, например, для обогащения датасетов мы используем генеративные модели, в том числе и на базе технологий LLM (Large Language Model, большая языковая модель). Это позволяет улучшить качество обучения модели, так как мы можем предоставить ей больше разнообразных данных для анализа. Мы обучили антиспам-модель-трансформер на основе большого объема электронных сообщений, размеченных не только как спам/не спам, но и рассортированных по категориям. Кстати, для категоризации моделей мы использовали полуконтролируемое обучение и автоматическую разметку с использованием других моделей. Это позволило моделям адаптироваться к различным стилям фишинговых писем, а также выполнять их классификацию и понимать контекст. Однако мы понимаем, что спам обладает очень высоким дрейфом данных (Data Drift) и концепций (Сoncept Drift), что приводит к деградации защитных 46 • ТЕХНОЛОГИИ Новые горизонты защиты: как ИИ революционизирует информационную безопасность Юрий Иванов, технический директор ООО “АВ Софт”, руководитель направления машинного обучения, к.т.н. Фото: Софья Ларина
моделей с течением времени. Стоит учитывать, что у каждого заказчика спам носит индивидуальный характер и создание универсальной модели невозможно даже теоретически. Для решения этой проблемы мы внедряем в наши продукты технологию федеративного дообучения моделей в контуре заказчика. Такой подход дает возможность адаптировать наши модели под специфику инсталляции и трафик заказчика. Еще одной особенностью является использование технологий компьютерного зрения. В AVSOFT ATHENA и AVSOFT KAIROS мы извлекаем ссылки из QR-кодов, а также обнаруживаем различные визуальные атрибуты на сайтах, указывающие на наличие фишинга: логотипы формы авторизации, платежные формы и т.д. Мы стараемся придерживаться мультимодального подхода, который предполагает использование разных типов данных (изображения, текст, табличные данные) в едином прогнозе. Это позволяет нам создавать более интегрированные и адаптивные системы безопасности, способные эффективно защищать наших клиентов. Мы продолжаем развивать и совершенствовать этот подход, чтобы оставаться на передовой в борьбе с современными угрозами информационной безопасности. Стоит отметить, что мы очень много внимания уделяем оптимизации моделей. Наши модели работают не только с использованием GPU, но и на обычном серверном оборудовании, причем на очень больших потоках. Это важно, учитывая разнообразие аппаратных средств и их инфраструктурных особенностей у наших клиентов. – А ведь злоумышленники тоже могут использовать искусственный интеллект? – Действительно, злоумышленники тоже активно используют искусственный интеллект для улучшения своих атакующих методов. Например, они могут использовать алгоритмы машинного обучения для создания персонализированных фишинговых сообщений, которые труднее обнаружить традиционными методами. Они могут также применять алгоритмы генерации вредоносного кода или алгоритмы обхода систем обнаружения вторжений. Но благодаря средствам динамического анализа, используемым в AVSOFT ATHENA, мы и их успешно обнаруживаем. – Известно, что алгоритмы и модели ИИ могут быть подвергнуты атакам. Как ваша команда реагирует на эти вызовы? – Алгоритмы и модели искусственного интеллекта также могут быть подвергнуты атакам, и это представляет серьезную угрозу для безопасности. Злоумышленники могут пытаться искажать данные, используемые для обучения модели машинного обучения, с целью внедрения вредоносного поведения в модель. Иногда злоумышленники используют доступ к выходным данным модели машинного обучения, чтобы восстановить входные данные, используемые для обучения. Атаки на модели машинного обучения могут иметь серьезные последствия, включая утечку конфиденциальных данных, ошибочные решения в критических ситуациях или даже полную компрометацию системы безопасности. Для борьбы с такими угрозами необходимо постоянное обновление и улучшение методов защиты моделей машинного обучения. Наша команда принимает этот вызов очень серьезно и применяет ряд стратегий для защиты. 1. Разбиение моделей на ансамбли, а также регулярный мониторинг ответов модели в процессе обучения, чтобы предотвратить внедрение вредоносных данных. 2. Регулярное обновление обучающего набора данных и переобучение модели с использованием актуальных данных. 3. Использование техник аугментации и зашумления данных, чтобы увеличить разнообразие обучающего набора данных и сделать модель более устойчивой. Мы принимаем все необходимые меры для обеспечения безопасности наших моделей машинного обучения и защиты их от атак. Однако этот процесс носит динамический характер, и мы постоянно совершенствуем наши методы и стратегии. – Возникает ли у заказчиков вопрос доверия к моделям? А как вы справляетесь с этическими проблемами? – Вопросы доверия к моделям машинного обучения действительно волнуют наших заказчиков, особенно когда речь идет об установке наших систем "в разрыв". Мы придерживаемся принципа прозрачности и объяснимости. Наша команда работает над тем, чтобы модели машинного обучения были объяснимыми и понятными для наших заказчиков. Мы стремимся использовать методы, которые позволяют объяснить принципы работы моделей и логику принимаемых ими решений. В качестве таких средств мы используем надстройку для моделей в AVSOFT ATHENA и AVSOFT KAIROS – эксплайнеры и систему эвристик, позволяющих объяснить вердикты. Мы разбираем индивидуально все потенциальные случаи ложных срабатываний и всегда стремимся адаптировать наши методы и подходы к конкретным потребностям и ожиданиям наших заказчиков. – Заменит ли ИИ традиционные средства защиты или человека? – Мы видим ряд перспективных направлений в развитии технологий машинного обучения для кибербезопасности. Одним из таких направлений является автоматическое создание адаптивных систем безопасности, способных быстро адаптироваться к новым угрозам и изменяющимся условиям среды. Мы ожидаем развития методов обнаружения атак на основе анализа поведения пользователей и сетевых устройств. Несмотря на то что ИИ демонстрирует значительный потенциал в области кибербезопасности, вопрос о том, заменит ли он традиционные средства защиты или человеческий фактор, остается предметом обсуждения. Я больше придерживаюсь позиции о необходимости коллаборативности, сотрудничества человека и ИИ. Человеческий анализ и экспертиза остаются важными в контексте кибербезопасности, но с использованием ИИ человек может быстрее и эффективнее анализировать большие объемы данных и принимать обоснованные решения. Благодаря развитию технологии обработки естественного языка для анализа текстовых данных появляется возможность анализировать отчеты об инцидентах или сообщения в социальных сетях, с целью выявления потенциальных угроз. Такой перспективный подход позволяет предсказать инциденты еще до того, как они произойдут. – Какие рекомендации вы бы дали компаниям, стремящимся улучшить свою кибербезопасность с помощью ИИ? – В первую очередь я бы рекомендовал инвестировать в обучение и подготовку специалистов по анализу данных и машинному обучению. Важно также создать инфраструктуру для сбора и анализа данных, необходимых для обучения моделей машинного обучения. И конечно, не стоит забывать о постоянном мониторинге и обновлении систем безопасности с учетом последних достижений в области машинного обучения и кибербезопасности. Внедрение искусственного интеллекта в кибербезопасность требует комплексного подхода и внимательного планирования, но при правильном использовании может значительно улучшить защиту компании от киберугроз. Большое спасибо за интересное интервью и ценные рекомендации! l • 47 ТЕХНОЛОГИИ www.itsec.ru АДРЕСА И ТЕЛЕФОНЫ "АВ Софт" см. стр. 70 NM Реклама
Страшный сон любой службы ИБ – реализация сценария с отключением питания серверов, при том что холодный запуск информационных систем может потребовать не один час. Мы рекомендуем выбирать ИБП с некоторым запасом мощности, чтобы обеспечить возможность безопасного подключения дополнительной нагрузки без необходимости замены или модернизации ИБП. Существует стереотип, согласно которому информационная безопасность – это про непосредственную защиту данных, а источники бесперебойного питания (ИБП) не являются неотъемлемой частью решений по обеспечению безопасности информации. Такой взгляд приводит к недооценке роли и значимости ИБП в контексте ИБ-проектов. Мы не только покажем, как недостаточное внимание к ИБП может оказать существенное воздействие на безопасность информационных систем, но и предложим практические решения для эффективного включения ИБП в стратегии обеспечения ИБ. Роль ИБП в информационной безопасности Системы бесперебойного питания часто упускаются из виду в общей схеме информационной безопасности. Однако эти устройства являются неотъемлемой частью ИБ и незаменимым элементом надежной инфраструктуры. ИБП – это не просто источник питания, это решение, обеспечивающее бесперебойную работу сети в условиях проблем в подаче электроэнергии, скачков напряжения и других сбоев. Страшный сон любой службы ИБ – реализация сценария с отключением питания серверов, при том что холодный запуск информационных систем может потребовать не один час. Тезисно роль ИБП можно свести к трем моментам. 1. Резервное питание. В случае перебоев в подаче электроэнергии система ИБП немедленно подает питание в сеть от аккумулятора. 2. Предотвращение потери данных. В компьютерных системах резкое отключение питания может привести к потере несохраненных данных и поломке серверного оборудования. Системы ИБП обеспечивают достаточное резервное энергоснабжение, оставляя время на корректное завершение работы серверов или восстановление основного питания. 3. Защита оборудования. Системы ИБП также защищают сетевое оборудование от скачков напряжения, которые могут повредить эти дорогостоящие устройства, а также обеспечивают стабильное соединение с серверным оборудованием. Поэтому не стоит недооценивать важность роли ИБП в стратегии информационной безопасности. Особенности расчета ИБП в проекте Можно обеспечить защиту электропитания в любой отрасли на любом уровне инфраструктуры, от защиты отдельного устройства до защиты целого предприятия. Производитель без проблем подберет оборудование под любой запрос. Изначально в проекте есть вводные: потребляемая мощность, время резервирования при отключении питания, номинальное напряжение нагрузки и сети. Выбор конкретных устройств зависит от этих параметров и от особенностей задачи, ведь защитить рабочее место, маленькую серверную или все здание – разные вещи. Впрочем, есть две универсальные рекомендации, которые подтверждаются нашим опытом. Рекомендация: берите запас по мощности Мы рекомендуем планировать мощность ИБП с учетом возможного роста мощности нагрузки и небольшого запаса. При планировании системы бесперебойного питания необходимо учитывать не только текущие потребности в мощности, но и возможный рост нагрузки в будущем. Постепенное увеличение мощности оборудования, добавление нового оборудования или увеличение вычислительных мощностей может привести к увеличению нагрузки на ИБП. Учитывая этот потенциальный рост, мы рекомендуем выбирать ИБП с некоторым запасом мощности, чтобы обеспечить возможность безопасного подключения дополнительной нагрузки без необходимости замены или модернизации ИБП. Это позволит также компенсировать временные пики нагрузки, которые могут возникнуть в процессе работы оборудования. Например, при запуске некоторых устройств наблюдается кратковременное увеличение потребляемой мощности, которое может привести к срабатыванию защитных механизмов ИБП, если его мощность рас48 • ТЕХНОЛОГИИ Рекомендации о роли ИБП в инфраструктуре информационной безопасности современных системах информационной безопасности обеспечение непрерывности электроснабжения высококритичных систем является вопросом первостепенной важности. Сбои могут привести к серьезным последствиям, оказывая негативное воздействие на функционирование ИБ-систем и, следовательно, на общую безопасность данных организации. В Дмитрий Шпанько, директор по развитию, POWERCOM Фото: POWERCOM