/ PxHere / PD
Компании слишком долго устанавливают патчи
Опрос Kollective проводился среди руководителей IT-отделов. 45% респондентов из крупных корпораций (у которых больше 100 тыс. сетевых терминалов) ответили, что для установки патча им нужно примерно 30 дней. Еще 27% сказали, что иногда на установку обновлений у них уходит несколько месяцев.
В условиях растущего числа киберугроз, подобный подход видится неприемлемым. По данным Symantec, в прошлом году количество атак вирусов-вымогателей увеличилось на 36%. При этом известно, что каждый день появляется более 230 тыс. образцов вредоносных программ.
В связи с этим за последние два года время на установку патча, которое есть у компании до того, как уязвимостью воспользуются злоумышленники, сократилось на 29%. Однако простое обновление безопасности по-прежнему остается одним из наиболее эффективных способов защиты. Во многих взломах и сливах данных хакеры используют уязвимости, для которых уже был выпущен патч.
ServiceNow провели опрос среди 3 тыс. специалистов по ИБ со всего мира и выяснили, что 56% компаний могли избежать слива информации в прошлом, если бы вовремя установили нужно обновление. Примером может быть масштабное хищение персональных данных у бюро Equifax в США. Тогда в сеть утекли ПД более 140 млн. американцев.
Этого инцидента можно было избежать, если бы специалисты бюро кредитных историй вовремя установили «заплатку». Хакеры использовали уязвимость во фреймворке Apache Struts (CVE-2017-5638), связанную с ошибкой в обработке исключений. Патч для этой уязвимости был выпущен за два месяца до атаки на Equifax.
Почему задерживают обновления
1. Нехватка сотрудников. Отделы информационной безопасности страдают от недостатка квалифицированных специалистов. По данным некоммерческой организации ISACA, к 2019 году в индустрии будет наблюдаться дефицит сотрудников по ИБ. Нехватка составит примерно 2 млн человек.
Это уже напрямую влияет на защиту организаций от кибератак. В исследовании McAfee от 2016 года четверть респондентов сказала, что недостаток экспертов по ИБ в их фирме стал причиной утечек данных.
2. Неэффективное управление установкой патчей. Однако расширение штата ИБ-специалистов в компании не всегда приводит к увеличению надежности ИТ-инфраструктуры. В ServiceNow отмечают, что повышения безопасности ждать не стоит, пока не будут модифицированы бизнес-процессы, связанные с патчингом.
На скорости закрытия уязвимостей сказывается большое число ручных процессов. Есть компании, которые для управления патчингом до сих пор используют Excel. Одна компания из Fortune 100 даже сформировала целый отдел из сотрудников, ответственных за управление электронными таблицами с данными об уязвимостях — они пишут туда, есть ли патч, кто его устанавливает и т. д.
По словам вице-президента по облачным исследованиям в Trend Micro Марка Нунниховена (Mark Nunnikhoven), именно отсутствие автоматизации процессов обновления ИТ-систем в компаниях стало одной из главных причин широкого распространения WannaCry.
3. Сложность приоритизации обновлений. По мнению издания CSO, ещё одна причина медленного обновления систем — слишком большое количество патчей. Специалистам по безопасности сложно расставлять приоритеты и решать, какие из них нужно установить раньше других. Даже в случае с Spectre и Meltdown специалисты высказали противоположные мнения: одни эксперты предлагали подождать, а другие торопились установить патчи побыстрее.
Ситуацию усложняет и медленное пополнение баз данных с уязвимостями. К августу этого года в базы CVE и NVD не попали более 3 тысяч угроз из тех, что были обнаружены с января по июнь 2018. Почти половина из них получила высший рейтинг опасности по CVSSv2.
4. Сложность установки. В компании Barkly провели опрос на тему установки обновлений Meltdown и Spectre среди специалистов по ИБ. 80% респондентов посчитали процесс установки патчей для закрытия уязвимостей в чипах Intel «неясным».
«Когда появились Meltdown и Spectre, не было удобной тестовой утилиты для выявления этих уязвимостей. Со временем утилиты начали появляться, но гарантировать их надежность было нельзя, — рассказывает Сергей Белкин, начальник отдела развития 1cloud. — Позже в Microsoft предложили метод проверки, но и он был довольно сложен. Однако потом появились решения (в частности, для ряда дистрибутивов Linux), позволяющие выяснить, подвержена система Meltdown и Spectre или нет, одной командой в консоли».
Как повысить скорость обновлений
1. Автоматизировать установку патчей. Автоматизация процесса обновления упрощает задачу администраторам и конечным пользователям. Система сама скачивает патчи из интернета, а сисадмину остается следить за процессом установки. Это особенно важно для облачных провайдеров, так как в их ведении находится огромное количество «машин».
Существуют инструменты (к примеру, HPE Server Automation), которые централизованно обновляют операционные системы на серверах ЦОД. Они позволяют выбрать необходимые патчи, предлагаемые поставщиком ОС. Еще с их помощью можно настроить сам процесс установки, например, чтобы исключить обновления, не подходящие для конкретной среды.
2. Обучать сотрудников. Важную роль в обеспечении безопасности данных играют люди. Потому нужно повышать осведомленность ИТ-специалистов и рядовых сотрудников компании, вкладывать средства и время хотя бы в проведение курсов базовой кибергигиены.
/ Flickr / Kelly / CC
В целом для лучшего усвоения знаний о безопасности данных можно использовать самые разные методы, например геймификацию. Австралийское подразделение PricewaterhouseCoopers проводит среди своих клиентов игру Game of Threats, когда в особом симуляторе соревнуются команды «хакеров» и «защитников системы».
3. Вкладывать больше средств в кибербезопасность. По оценке Gartner, в 2018 году расходы организаций на кибербезопасность увеличатся на 12,4% в сравнении с прошлым годом. Фирмы будут тратить больше денег на автоматизацию процессов и новые технологии защиты данных, чтобы специалисты по ИБ могли работать эффективнее.
Что дальше
Медленная установка обновлений безопасности — это системная проблема. И, вероятно, она будет доставлять «неудобства» еще довольно долгое время, особенно в свете обнаружения новых крупных уязвимостей процессоров, например Foreshadow. Однако если больше компаний начнет оперативно устанавливать патчи, то это положительно скажется на всей экосистеме и значительно снизит число утечек персональных данных. Подобных той, что произошла с Equifax.
Еще пара постов из корпоративного блога 1cloud:
Комментарии (17)
vodopad
15.09.2018 21:13Работаю в крупной оутсорсинговой компании. Обслуживаем европейского заказчика. И Патчинг-процесс у нас устроен крайне забавно и мне за него стыдно…
В нашем распоряжении 500+ Linux-серверов. У каждого сервера есть своё расписание патчинга (первый вторник месяца в 21:00, третья среда месяца в 15:00 и т.д.) и патчится он может максимум раз в месяц.
В начале месяца мы формируем патчинг-репорт для каждого сервера примерно такого вида (кастомными python-скриптами):
raw.githubusercontent.com/4815162342lost/linux_patching_prepare_steps_automation/master/screenshots/Screenshot%20from%202017-07-10%2000-00-44.png
raw.githubusercontent.com/4815162342lost/linux_patching_prepare_steps_automation/master/screenshots/Screenshot%20from%202017-07-10%2000-01-02.png
И если у сервера есть хотя бы 1 патч, то он будет патчится в этом месяце. Если нет — то подождёт следующего.
После сбора патчинг-листа и формирования списка серверов для патчинга начинается патчинг. И выполняется он полностью руками…
Но, что самое интересное: все 'потенциально-опасные' пакеты исключаются из патчинга. Например, если на сервере база данных Oracle или любое другие приложение, использующее java, java сразу заносится в эксклуды и не обновляется никогда. Если это веб-сервер, то httpd, nod*, nginx сразу заносятся в эксклуды. Если python-приложение — то python; mysql и т.д. Хотя мы каждый раз создаём снепшоты и хранятся они аж две недели. И ещё почти все серверы у нас CentOS\RHEL, где в принципе шанс что-то сломать крайне мал, т.к. дистрибутив крайне консервативный. Сделано это для того, чтобы заказчик не пришёл к нам с претензиями, что после нашего патчинга у него поломалось приложение. Естественно, при таких условиях ни о какой безопасности речи не идёт.
Со Spectre\Meltdown ситуация вышла забавной. Сначала патчинг полностью саморозили на 2 месяца. На третий месяц разрешили патчить тестовые серверы. Примерно через пол года подошли к prod. Через 9 месяцев, наконец-то, разрешили патчить все серверы… И знаете почему? Потому что 'а если упадёт производительность, что мы будем делать?'. Аргументы типа 'патчи отключаемые, мы можем загрузиться на старое ядро, восстановится со снепшота' для них не являлись аргументами. Кроме того, у заказчик свободных ресурсов очень и очень много, почти на каждом сервере load avg 0.05 или меньше, CPU utilization 3-10% максимум… (у нас свои серверы в DC, о ресурсах никто не заботится, всё железо просто простаивает). Риски были мизерными.
И да, у нас тоже есть отдельная команда для патчинга. Которым занимается менеджер, не имеющий никакого отношения к IT.
А знаете, кто принял решение о заморозке патчинга? и в целом, кто выстроил такой процесс? Наши любимые тим. лиды, проблем-менеджеры и менеджеры со стороны заказчика. Да, у нас очень много менеджеров. И знаете, что их всех объединяет? То, что они мало что понимают в IT и не смогу даже залогинтсья в консоли. А ещё их объединяет то, что именно они принимают все важные решения. И они отвечают за безопасность. И никто на них не может повлиять.
Поэтому в моём случае проблема в другом. Проблема в некомпетентных людях, занимающие руководящие должности в IT.
Вот.x67
16.09.2018 01:34Если они занимают такие посты в ит компаниях, значит это работает. По крайней мере пока. Да, потом наверняка будут проблемы, но так построены процессы к сожалению везде и всегда — "если жонглирующий костыляэми слон на моноцикле работает, то пусть работает". А вы ничего с этим поделать не можете(ведь даже названия компании не называете, что логично, потому что еще и крайним можете оказаться), поэтому советую вспомнить свою зону ответственности и забыть про остальное, по крайней мере до подходящего случая, когда вы сможете что то изменить.
fivehouse
16.09.2018 13:12Если они занимают такие посты в ит компаниях, значит это работает.
Вы ошибаетесь. Это не работает, то есть совершенно. Деградация состояния ИТ от работы таких менеджеров просто налицо и четко видна по факту. В менеджмент массово пришли люди совершенно не заинтересованные в том, что у них реально происходит в ИТ, но крайне заинтересованные в выработке правильного впечатления об их работе у руководства. Вот этим они и занимаются все рабочее время. «Поглаживание» с нужными людьми и театральные представления о собственной важности и компетентности (по факту отсутствующей). Еще они очень заинтересованы в личном успехе: дети в зарубежных школах, машины, квартиры, дачи, иногда прислуга; и любят и умеют выставлять все это напоказ. Все остальное вне их интересов.vodopad
16.09.2018 14:43Да, увы, это не работает для инфраструктуры IT в целом, но ничего нельзя поделать. Так работает оутсорсинг.
По факту, с нашей стороны много менеджеров, со стороны заказчика много менеджеров. Главный смысл нашей работы (оутсорсинга) — сделать так, чтобы заказчик был удовлетворён. А кто наш заказчик? Кто является представителем? Правильно, такие же менеджеры, которые ничего не понимают в IT.
Они довольны в том случае (и платят много денег), если наши менеджеры (ничего не понимающие в IT) смогут убедить их в том, что мы всё делаем правильно. И если уважать мнение заказчика.
Для заказчика главное, чтобы всё работало. И он будет недоволен, если наш патчинг сломает ему приложение. Поэтому у нас патчинг не ломает приложения (т.к. много эксклудов на каждом сервере), и в целом есть патчинг-процесс. Менеджер (заказчик) доволен.
А если 'патчить по-правильному', то заказчик будет недоволен. Т.к. 'не по процессу', а ещё 'ваш патчинг сломал нам приложение'. И доказать ему ничего нельзя будет, т.к. он не понимает в IT.
Замкнутый круг…
x67
17.09.2018 01:471. Компания существует
2. Компания приносит прибыль своим владельцам
3. Никто кроме ограниченного и/или заинтересованного круга лиц не знает о состоянии ИБ
Все три условия выполняются, значит это рабочая схема. Я не говорю, что так должно быть, но такое встречается повсеместно. И пока петух не клюнет, ничего в этой компании не изменится.
В менеджмент массово пришли люди совершенно не заинтересованные в том, что у них реально происходит
Да не пришли они — всегда были. Это теплый ламповый Ой Ти пришел в наши жизни и существенно изменил правила игры. А эти самые менеджеры не привыкли менять парадигмы потому что так правильно, вот и живут по старым правилам. Сейчас ИТ все сильнее входит во все большее число сфер жизни, в этом и наше благословение — улучшение качества жизни, экономический рост, новые возможности; и проклятье — профессионалов с грамотным подходом к делу просто не хватает, а иногда их вытесняют дилетанты лишь благодаря экономии на таких вещах, как например, ИБ. И пока нажива на таких компаниях не станет скорее правилом, ничего не изменится. В государстве тут я надежды не вижу.
tbp2k5
15.09.2018 23:24Забавно что исследование не выявило ключевую, как мне кажется, причину задержки установи патчей: у крупных вендоров регулярно всплывают проблемные патчи (это я очень мягко написал). По-моему компании прикинули и пришли к выводу что подождать месяц пока «торопыги» оттестируют патчи менее рисковано чем жить под риком неустранненой проблемы.
Leozaur
16.09.2018 02:40Я тоже ожидал это увидеть на первом месте.
Не говоря уж о случающихся проблемах совместимости кода с обновлениями некоторых используемых сервисов/библиотек даже в пределах минорных версий. Обычно тогда скатывается до заморозки обновлений для этих сервисов, потому что времени на перепроверку (не говоря уж о корректировке) «уже сделанного» функционала никто не даёт.
fivehouse
16.09.2018 01:12Современные компании реально не готовы (от слов: вообще, полностью и совершенно) к работе с ИБ. Как-то раз я работал в одной очень крупной немецкой компании. Для обеспечения ИБ были предприняты следующие шаги: всех ITшников обязали заботиться об ИБ, а вопрос, как это конкретно считался неполиткорректным и проявлением крайней нелояльности к компании, и наняли целого одного человека, который использовал «собственные методики» для обеспечения ИБ. Собственные методики в конце концов свелись к интригам и фактически угрозам низовым бизнес работникам, рисованию заумных схем, весьма профессиональному надуванию щек, произвольному отъему прав у самых беззащитных сотрудников IT (а после подъема шума права всегда возвращались, т.к. им просто становилось нельзя работать). И венцом усилий сотрудника ответственного за ИБ был выбор подарков руководству IT, как «людям другого уровня», на день рождения. В общем карьера менеджера по ИБ удалась. Предыдущий менеджер по ИБ копипастил случайные найденные статьи в Интернете по «обезопашиванию» различных OS и БД и не понимая их пытался заставить админов их выполнять. Когда админы предупреждали его чем это все закончится, он выражал крайнее недовольство и обвинял их в саботаже его усилий по налаживанию ИБ. Цирк с конями и лебедями.
Ad3pt
16.09.2018 10:01— Шеф, у нас дыра в безопасности
— Слава богу, хоть что-то у нас в безопасности
evilgeek
16.09.2018 10:24Значимость патчей для безопасности сильно преувеличена, особенно для бэкофисного оборудования (недоступного напрямую из интернета или относительно публичных сегментов). Организационные меры важнее на порядок, а иногда на два порядка.
А вот для бизнеса простои и проблемы из-за патчей несут прямой убыток, иногда очень значительный. Так что всё правильно делают. А некоторые патчи или обновления версия полезно выдерживать месяцами, если не годами (некоторые обновление СУБД или серверов приложений).speshuric
17.09.2018 00:39Сейчас, пожалуй, да. Но есть 2 тренда, которые напрочь это портят: во-первых, массовый исход уже не малого, а среднего бизнеса в облака (и вот у вас уже нет «недоступного напрямую»), во-вторых на горизонте IoT таки маячит — там все проблемы обновлений конечных устройств, просто еще на пару порядков хуже (например, Брюс Шнайер, часто об этом пишет в блоге и даже книгу собирается выпустить). Но с приходом этих трендов вопрос «почему админы не патчат» становится слегка бессмысленным.
evilgeek
17.09.2018 10:33А как относятся облака к патчам, например, прикладного софта? или бэкофисного? Никак не относятся, это разные задачи. Проблемы с безопасностью у прикладного софта как бы не более распространены, чем у системного. Патчить, наверно, надо. Но редко какая эксплуатация уязвимости по ущербу способна сравнится с кривым патчем, накатанным в пятницу вечером перед длительными праздниками.
Не говоря уже о проблемах с оборудованием после установки апдейтов firmware (в этом случае не напрасно есть золотое правило: работает — не трогай).
mspain
16.09.2018 12:38В нашей конторке из 10тыс рабочих станций порядка 2тыс ещё на xp. При том что есть грамотные ибшники. Просто не надо недооуенивать бюрократию
speshuric
17.09.2018 00:24А ведь я пытался всерьез читать статью до «Нехватка составит примерно 2 млн человек».
Эта фраза выглядит высосанной из пальца. Если только нехватка 2 млн, то сколько всего их надо? 5? 10? К каждому админу по безопаснику? Проверил источник по ссылке, но нет, переведено правильно: «But the global shortage of cybersecurity professionals will reach 2 million by 2019, according to ISACA, a global non-profit IT advocacy group.»
Стоп, а что за ISACA? Погуглил. А… они же продают услуги по сертификации, обучению и консалтингу. Ну-ну.
На самом деле дефицит есть. Только дефицит не «безопасников с сертификатами», а дефицит средней компетентности в ИБ в ИТ. Этот дефицит не перекрыть отдельными cybersecurity professionals.
Anshi85
Скажу даже больше, есть компании где отсутствуют специалисты по ИБ, соответственно защита софта, который разрабатывает компания ложится на разработчиков, а самое интересное что у заказчика тоже может не быть специалистов по ИБ или у ИТ специалистов заказчика уровень компетенции начинающего эникея. Проекты тоже принимаются на «высшем» уровне между руководителями компании исполнителя и заказчика, то есть конечного пользователя ставят перед фактом, когда уже систему внедряют. Некоторые дыры так и не бывают закрыты, годами, даже если заявить об угрозе, могут просто махнуть рукой типа «мол кто будет нас ломать, кому мы нужны» и т.д. При чем выше перечисленное не только на территории бывшего СССР, но и на технологично развитом Западе, везде где люди есть людская халатность.
Listrigon
Во всех местах где я работал тоже не было отдельных людей по ИБ. Мне интересно даже уднать, что они делают? За безопасность всего кода, серверного, БД, клиентских скриптов отвечали программисты и это как-то логично, не будут же мои код тотально пересматривать и переписываиь, а если ут, то зачем тогда программисты? Если за систему, то это администраторы, тогда зачем они нудны, если есть безопасники?
hostname
Специласты ИБ читают, проверяют и составляют. Читают они материалы по новым уязвимостям, проверяют сеть на старые и новые уязвимости, а составляют политики по противодействию этим самым уязвимостям. В это и проблема, что люди не понимают, зачем нужно ИБ если есть… У человека есть задачи и обязанности, и чем глубже он понимает свою сферу и чем больше у него объёма работ(обязанностей), тем меньше он может уделить времени другой области. Так вот ИБ это такая же часть системы как программисты, тестировщики, сетевики и сисадмины. Не возникает же вопрос «зачем нужны сисадмины, если всё что они администируют написали программисты, пусть они и занимаются администированием собственных продуктов?»