Comments 17
Скажу даже больше, есть компании где отсутствуют специалисты по ИБ, соответственно защита софта, который разрабатывает компания ложится на разработчиков, а самое интересное что у заказчика тоже может не быть специалистов по ИБ или у ИТ специалистов заказчика уровень компетенции начинающего эникея. Проекты тоже принимаются на «высшем» уровне между руководителями компании исполнителя и заказчика, то есть конечного пользователя ставят перед фактом, когда уже систему внедряют. Некоторые дыры так и не бывают закрыты, годами, даже если заявить об угрозе, могут просто махнуть рукой типа «мол кто будет нас ломать, кому мы нужны» и т.д. При чем выше перечисленное не только на территории бывшего СССР, но и на технологично развитом Западе, везде где люди есть людская халатность.
Во всех местах где я работал тоже не было отдельных людей по ИБ. Мне интересно даже уднать, что они делают? За безопасность всего кода, серверного, БД, клиентских скриптов отвечали программисты и это как-то логично, не будут же мои код тотально пересматривать и переписываиь, а если ут, то зачем тогда программисты? Если за систему, то это администраторы, тогда зачем они нудны, если есть безопасники?
Специласты ИБ читают, проверяют и составляют. Читают они материалы по новым уязвимостям, проверяют сеть на старые и новые уязвимости, а составляют политики по противодействию этим самым уязвимостям. В это и проблема, что люди не понимают, зачем нужно ИБ если есть… У человека есть задачи и обязанности, и чем глубже он понимает свою сферу и чем больше у него объёма работ(обязанностей), тем меньше он может уделить времени другой области. Так вот ИБ это такая же часть системы как программисты, тестировщики, сетевики и сисадмины. Не возникает же вопрос «зачем нужны сисадмины, если всё что они администируют написали программисты, пусть они и занимаются администированием собственных продуктов?»
Работаю в крупной оутсорсинговой компании. Обслуживаем европейского заказчика. И Патчинг-процесс у нас устроен крайне забавно и мне за него стыдно…
В нашем распоряжении 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.
Вот.
В нашем распоряжении 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.
Вот.
Если они занимают такие посты в ит компаниях, значит это работает. По крайней мере пока. Да, потом наверняка будут проблемы, но так построены процессы к сожалению везде и всегда — "если жонглирующий костыляэми слон на моноцикле работает, то пусть работает". А вы ничего с этим поделать не можете(ведь даже названия компании не называете, что логично, потому что еще и крайним можете оказаться), поэтому советую вспомнить свою зону ответственности и забыть про остальное, по крайней мере до подходящего случая, когда вы сможете что то изменить.
Если они занимают такие посты в ит компаниях, значит это работает.Вы ошибаетесь. Это не работает, то есть совершенно. Деградация состояния ИТ от работы таких менеджеров просто налицо и четко видна по факту. В менеджмент массово пришли люди совершенно не заинтересованные в том, что у них реально происходит в ИТ, но крайне заинтересованные в выработке правильного впечатления об их работе у руководства. Вот этим они и занимаются все рабочее время. «Поглаживание» с нужными людьми и театральные представления о собственной важности и компетентности (по факту отсутствующей). Еще они очень заинтересованы в личном успехе: дети в зарубежных школах, машины, квартиры, дачи, иногда прислуга; и любят и умеют выставлять все это напоказ. Все остальное вне их интересов.
Да, увы, это не работает для инфраструктуры IT в целом, но ничего нельзя поделать. Так работает оутсорсинг.
По факту, с нашей стороны много менеджеров, со стороны заказчика много менеджеров. Главный смысл нашей работы (оутсорсинга) — сделать так, чтобы заказчик был удовлетворён. А кто наш заказчик? Кто является представителем? Правильно, такие же менеджеры, которые ничего не понимают в IT.
Они довольны в том случае (и платят много денег), если наши менеджеры (ничего не понимающие в IT) смогут убедить их в том, что мы всё делаем правильно. И если уважать мнение заказчика.
Для заказчика главное, чтобы всё работало. И он будет недоволен, если наш патчинг сломает ему приложение. Поэтому у нас патчинг не ломает приложения (т.к. много эксклудов на каждом сервере), и в целом есть патчинг-процесс. Менеджер (заказчик) доволен.
А если 'патчить по-правильному', то заказчик будет недоволен. Т.к. 'не по процессу', а ещё 'ваш патчинг сломал нам приложение'. И доказать ему ничего нельзя будет, т.к. он не понимает в IT.
Замкнутый круг…
По факту, с нашей стороны много менеджеров, со стороны заказчика много менеджеров. Главный смысл нашей работы (оутсорсинга) — сделать так, чтобы заказчик был удовлетворён. А кто наш заказчик? Кто является представителем? Правильно, такие же менеджеры, которые ничего не понимают в IT.
Они довольны в том случае (и платят много денег), если наши менеджеры (ничего не понимающие в IT) смогут убедить их в том, что мы всё делаем правильно. И если уважать мнение заказчика.
Для заказчика главное, чтобы всё работало. И он будет недоволен, если наш патчинг сломает ему приложение. Поэтому у нас патчинг не ломает приложения (т.к. много эксклудов на каждом сервере), и в целом есть патчинг-процесс. Менеджер (заказчик) доволен.
А если 'патчить по-правильному', то заказчик будет недоволен. Т.к. 'не по процессу', а ещё 'ваш патчинг сломал нам приложение'. И доказать ему ничего нельзя будет, т.к. он не понимает в IT.
Замкнутый круг…
1. Компания существует
2. Компания приносит прибыль своим владельцам
3. Никто кроме ограниченного и/или заинтересованного круга лиц не знает о состоянии ИБ
Все три условия выполняются, значит это рабочая схема. Я не говорю, что так должно быть, но такое встречается повсеместно. И пока петух не клюнет, ничего в этой компании не изменится.
Да не пришли они — всегда были. Это теплый ламповый Ой Ти пришел в наши жизни и существенно изменил правила игры. А эти самые менеджеры не привыкли менять парадигмы потому что так правильно, вот и живут по старым правилам. Сейчас ИТ все сильнее входит во все большее число сфер жизни, в этом и наше благословение — улучшение качества жизни, экономический рост, новые возможности; и проклятье — профессионалов с грамотным подходом к делу просто не хватает, а иногда их вытесняют дилетанты лишь благодаря экономии на таких вещах, как например, ИБ. И пока нажива на таких компаниях не станет скорее правилом, ничего не изменится. В государстве тут я надежды не вижу.
2. Компания приносит прибыль своим владельцам
3. Никто кроме ограниченного и/или заинтересованного круга лиц не знает о состоянии ИБ
Все три условия выполняются, значит это рабочая схема. Я не говорю, что так должно быть, но такое встречается повсеместно. И пока петух не клюнет, ничего в этой компании не изменится.
В менеджмент массово пришли люди совершенно не заинтересованные в том, что у них реально происходит
Да не пришли они — всегда были. Это теплый ламповый Ой Ти пришел в наши жизни и существенно изменил правила игры. А эти самые менеджеры не привыкли менять парадигмы потому что так правильно, вот и живут по старым правилам. Сейчас ИТ все сильнее входит во все большее число сфер жизни, в этом и наше благословение — улучшение качества жизни, экономический рост, новые возможности; и проклятье — профессионалов с грамотным подходом к делу просто не хватает, а иногда их вытесняют дилетанты лишь благодаря экономии на таких вещах, как например, ИБ. И пока нажива на таких компаниях не станет скорее правилом, ничего не изменится. В государстве тут я надежды не вижу.
Забавно что исследование не выявило ключевую, как мне кажется, причину задержки установи патчей: у крупных вендоров регулярно всплывают проблемные патчи (это я очень мягко написал). По-моему компании прикинули и пришли к выводу что подождать месяц пока «торопыги» оттестируют патчи менее рисковано чем жить под риком неустранненой проблемы.
Я тоже ожидал это увидеть на первом месте.
Не говоря уж о случающихся проблемах совместимости кода с обновлениями некоторых используемых сервисов/библиотек даже в пределах минорных версий. Обычно тогда скатывается до заморозки обновлений для этих сервисов, потому что времени на перепроверку (не говоря уж о корректировке) «уже сделанного» функционала никто не даёт.
Не говоря уж о случающихся проблемах совместимости кода с обновлениями некоторых используемых сервисов/библиотек даже в пределах минорных версий. Обычно тогда скатывается до заморозки обновлений для этих сервисов, потому что времени на перепроверку (не говоря уж о корректировке) «уже сделанного» функционала никто не даёт.
Современные компании реально не готовы (от слов: вообще, полностью и совершенно) к работе с ИБ. Как-то раз я работал в одной очень крупной немецкой компании. Для обеспечения ИБ были предприняты следующие шаги: всех ITшников обязали заботиться об ИБ, а вопрос, как это конкретно считался неполиткорректным и проявлением крайней нелояльности к компании, и наняли целого одного человека, который использовал «собственные методики» для обеспечения ИБ. Собственные методики в конце концов свелись к интригам и фактически угрозам низовым бизнес работникам, рисованию заумных схем, весьма профессиональному надуванию щек, произвольному отъему прав у самых беззащитных сотрудников IT (а после подъема шума права всегда возвращались, т.к. им просто становилось нельзя работать). И венцом усилий сотрудника ответственного за ИБ был выбор подарков руководству IT, как «людям другого уровня», на день рождения. В общем карьера менеджера по ИБ удалась. Предыдущий менеджер по ИБ копипастил случайные найденные статьи в Интернете по «обезопашиванию» различных OS и БД и не понимая их пытался заставить админов их выполнять. Когда админы предупреждали его чем это все закончится, он выражал крайнее недовольство и обвинял их в саботаже его усилий по налаживанию ИБ. Цирк с конями и лебедями.
— Шеф, у нас дыра в безопасности
— Слава богу, хоть что-то у нас в безопасности
— Слава богу, хоть что-то у нас в безопасности
Значимость патчей для безопасности сильно преувеличена, особенно для бэкофисного оборудования (недоступного напрямую из интернета или относительно публичных сегментов). Организационные меры важнее на порядок, а иногда на два порядка.
А вот для бизнеса простои и проблемы из-за патчей несут прямой убыток, иногда очень значительный. Так что всё правильно делают. А некоторые патчи или обновления версия полезно выдерживать месяцами, если не годами (некоторые обновление СУБД или серверов приложений).
А вот для бизнеса простои и проблемы из-за патчей несут прямой убыток, иногда очень значительный. Так что всё правильно делают. А некоторые патчи или обновления версия полезно выдерживать месяцами, если не годами (некоторые обновление СУБД или серверов приложений).
Сейчас, пожалуй, да. Но есть 2 тренда, которые напрочь это портят: во-первых, массовый исход уже не малого, а среднего бизнеса в облака (и вот у вас уже нет «недоступного напрямую»), во-вторых на горизонте IoT таки маячит — там все проблемы обновлений конечных устройств, просто еще на пару порядков хуже (например, Брюс Шнайер, часто об этом пишет в блоге и даже книгу собирается выпустить). Но с приходом этих трендов вопрос «почему админы не патчат» становится слегка бессмысленным.
А как относятся облака к патчам, например, прикладного софта? или бэкофисного? Никак не относятся, это разные задачи. Проблемы с безопасностью у прикладного софта как бы не более распространены, чем у системного. Патчить, наверно, надо. Но редко какая эксплуатация уязвимости по ущербу способна сравнится с кривым патчем, накатанным в пятницу вечером перед длительными праздниками.
Не говоря уже о проблемах с оборудованием после установки апдейтов firmware (в этом случае не напрасно есть золотое правило: работает — не трогай).
Не говоря уже о проблемах с оборудованием после установки апдейтов firmware (в этом случае не напрасно есть золотое правило: работает — не трогай).
В нашей конторке из 10тыс рабочих станций порядка 2тыс ещё на xp. При том что есть грамотные ибшники. Просто не надо недооуенивать бюрократию
А ведь я пытался всерьез читать статью до «Нехватка составит примерно 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.
Эта фраза выглядит высосанной из пальца. Если только нехватка 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.
Sign up to leave a comment.
Исследование: половина компаний патчит уязвимости в течение месяца — почему?