Как инженерия безопасности меняет индустрию кибербезопасности
29 марта 2023 г.Ранее я подробно рассказывал о развитии кибербезопасности и переходе от обещаний к доказательная безопасность. В этой части я подробно расскажу об одной из тенденций, связанных с этой трансформацией, а именно о развитии техники безопасности.
Переход от безопасности, основанной на обещаниях, к безопасности, основанной на доказательствах, и эволюция ИТ
Когда я говорю о развитии кибербезопасности, я в основном имею в виду изменение нашего подхода к этому. До недавнего времени мы думали об этом как о функции и предполагали, что безопасность — это проблема инструмента: если вы купите «правильный» продукт безопасности «нового поколения» от ведущего поставщика, вы будете в «безопасности».
Теперь, после многих лет наблюдения за тем, как этот подход не оправдал возложенных на него надежд, мы начинаем понимать, что безопасность — это процесс, а не функция. Мы вырабатываем системное убеждение, что нам нужно вернуться к основам: собрать данные о безопасности в одном месте, понять, что происходит в нашей среде, узнать, что представляет собой нормальная деловая практика в нашей организации и что может быть признаком компрометации, определить, как для обнаружения вредоносного поведения и принятия соответствующих мер. Вместо виджета, который при включении активирует непроницаемый защитный щит, опытные специалисты по безопасности смотрят на безопасность через призму уровней и задач, которые необходимо выполнить.
<цитата>"Лучший способ создать систему безопасности – создать ее на основе средств контроля и инфраструктуры, которые можно наблюдать, тестировать и улучшать. Он не основан на обещаниях поставщиков, которые следует принимать за чистую монету. Это означает, что точный набор вредоносных действий и поведения, от которых вы защищены, должен быть известен, и вы должны иметь возможность протестировать и доказать это. Это также означает, что если вы можете описать что-то, что хотите обнаружить и предотвратить, вы сможете применить это в одностороннем порядке без вмешательства поставщика. Например, если инженер по безопасности прочитал о WannaCry, у него должна быть возможность создать собственную логику обнаружения, не дожидаясь дня или двух, пока их поставщик не выпустит новую версию».
Еще один фактор, меняющий способ обеспечения безопасности, — это эволюция ИТ, свидетелями которой мы стали в последнее десятилетие. Было время, когда опыта работы в сфере ИТ было достаточно, чтобы начать работу в качестве специалиста по безопасности, поскольку он давал базовое понимание того, как работают различные элементы инфраструктуры, взаимодействуют друг с другом и что необходимо для их защиты.
Автоматизация ИТ и распространение облачных технологий абстрагируют многое из того, что происходит в фоновом режиме, что усложняет разработку ментальных моделей ИТ-инфраструктуры и понимание того, как ее защитить. Чтобы преуспеть в безопасности сегодня, необходимо понимать локальную инфраструктуру, различные компоненты облачной инфраструктуры, а также конвейеры инфраструктуры как кода и DevOps, и это лишь некоторые из них. По мере усложнения ИТ возрастают требования к людям, отвечающим за обслуживание, администрирование и понимание этой сложности.
К другим факторам, ускоряющим изменение наших подходов к обеспечению безопасности, относятся:
– Слабая корреляция между результатами и расходами на безопасность
– Бизнес требует измеримых результатов,
– Возрастающая сложность безопасности и клиентских сред
– Распространение инструментов безопасности,
– Растущая зрелость специалистов по безопасности,
– Рост страховых взносов,
- Появление нового поколения поставщиков услуг,
– Появление поддерживающей экосистемы поставщиков,
- Создание систем безопасности и
- Поддержка инвесторами доказательной безопасности.
Кибербезопасность будущего будет очень похожа на разработку программного обеспечения
Разработка программного обеспечения как модель кибербезопасности
Кибербезопасность зародилась в хакерских кругах — среди технически подкованных людей, интересующихся продуктами и инструментами обратного проектирования, переделкой и взломом того, что считалось неуязвимым. Затем пришли несколько поставщиков средств безопасности, чтобы пообещать безопасность, сказав: «Мы предупредим вас, когда произойдет что-то плохое, просто попросите кого-нибудь проверить предупреждения». Пораженные перспективой такой простоты, мы начали нанимать аналитиков безопасности для отслеживания предупреждений. Сегодня, десятилетие или около того спустя, мы видим, что должны вернуться к основам. Этот взгляд, очевидно, является чрезмерным упрощением, но правда в том, что нам нужно вернуть хакеров в индустрию. Правда в том, что кибербезопасность будущего будет очень похожа на разработку программного обеспечения.
Разработка программного обеспечения предлагает нам отличную модель: бизнес-аналитики и менеджеры по продуктам работают между бизнесом и технологиями — они разговаривают с клиентами, понимают и оценивают бизнес-требования, переводят их в технические требования и определяют приоритетность этих требований для разработки. Я часто слышу, как службы безопасности обвиняют в том, что они не разговаривают с клиентами и недостаточно понимают бизнес. Хотя мнение справедливо, я думаю, что люди, делающие такие заявления, упускают суть: критика технических специалистов по безопасности за непонимание бизнеса сродни критике внутренних инженеров за то, что они не умеют проводить интервью с пользователями. Истина проста: если бы бэкенд-инженеры хотели проводить интервью с пользователями, они бы не выбрали бэкенд, а вместо этого стали бы UX-дизайнерами.
Нам нужны службы безопасности, чтобы лучше понимать бизнес, в этом нет никаких сомнений. Но мы не можем решить проблему, отправив всех из ИТ и службы безопасности, чтобы начать опрос сотрудников по всей компании (хотя мы должны поощрять налаживание отношений). Вместо этого нам нужен эквивалент бизнес-аналитиков и менеджеров по продуктам в области безопасности, чтобы заполнить пробел. .
Принципы разработки программного обеспечения для кибербезопасности
Инженерия программного обеспечения предлагает отличный набор инструментов, концепций, принципов и ментальных моделей, которые разделяют кибербезопасность завтрашнего дня.
<цитата>Во-первых, безопасность завтрашнего дня будет представлять собой безопасность как код.
Теперь, когда мы получаем все в виде кода — политики в виде кода, инфраструктура в виде кода, конфиденциальность в виде кода, обнаружения в виде кода и т. д. — мы можем развертывать, отслеживать и тестировать изменения в состояние безопасности организации и откатывать их по мере необходимости. Это, в свою очередь, означает подход, который можно протестировать и подтвердить, что еще больше укрепит точку зрения о безопасности, основанной на доказательствах. Подобно тому, как это работает в разработке программного обеспечения, теперь вы можете запускать автоматические тесты безопасности, чтобы увидеть, как будет вести себя ваша система, и нанять специалиста по обеспечению качества (например, тестировщика проникновения), чтобы выйти за рамки автоматов и искать крайние случаи, не покрытые автоматизацией. .
Во-вторых, кибербезопасность будущего будет основываться на непрерывном мониторинге, непрерывном развертывании и частых повторениях. Уровень безопасности организации не является статичным, он меняется каждую секунду, и скорость, с которой он изменяется, увеличилась с появлением облака. Через несколько секунд после развертывания нового покрытия обнаружения и реагирования среда организации изменилась бы: сотни виртуальных машин были запущены в облаке, а на конечных точках были установлены десятки новых приложений SaaS, и это лишь некоторые из них. Оценка безопасности и охват не могут оставаться статичными — они должны развиваться по мере развития самой организации. Таким образом, безопасность — это процесс, а не функция, процесс, основанный на постоянной оценке и постоянном совершенствовании системы безопасности организации.
В-третьих, индустрия завтрашнего дня должна будет делать что-то в масштабе, ориентируясь на API. Прошли те времена, когда специалистам по безопасности приходилось входить в десятки инструментов, чтобы вручную настраивать некоторые конфигурации и, тем более, вручную развертывать решения безопасности. Все должно выполняться в масштабе машины через API.
В-четвертых, кибербезопасность увидит, как мир коммерческих инструментов сосуществует и тесно интегрируется с миром открытого исходного кода. Хотя в течение некоторого времени это имело место в разработке программного обеспечения со всеми коммерческими инструментами разработки программного обеспечения, использующими библиотеки и компоненты с открытым исходным кодом, в кибербезопасности открытый исходный код часто рассматривается отдельно от рынка поставщиков. Ранее я подробно изучал роль открытого исходного кода в кибербезопасности и вижу, что эта роль растет по мере развития отрасли. Поставщики кибербезопасности не смогут уйти, просто создав коммерческие версии инструментов с открытым исходным кодом; им нужно будет опираться на лучшее и добавить реальную ценность, помимо заявления о том, что «мы не являемся открытым исходным кодом», и демонстрации своего сертификата соответствия SOC 2.
Применение инженерного подхода к безопасности означает сосредоточение внимания на улучшении процессов непрерывной защиты, а не на проверке соответствия требованиям. Это позволяет группам безопасности предоставлять технические решения и создавать масштабируемые инструменты, прежде чем рекомендовать нанимать больше людей, что, в свою очередь, позволяет им достигать большего с меньшими затратами. Все эти факторы в совокупности делают подход к безопасности, основанный на фактических данных, который я подробно обсуждал ранее, неизбежным; вопрос больше не в том, если, а в том, когда (ответ: это уже происходит).
Место безопасности в жизненном цикле продукта
Когда мы думаем о безопасности, один из вопросов, который первым приходит на ум, звучит так: "Какое место в жизненном цикле разработки программного обеспечения она занимает?". Хотя это правильный вопрос, сам по себе жизненный цикл разработки программного обеспечения создает яркие пятна вокруг того, что происходит с программным обеспечением в дикой природе. Чтобы правильно обсудить роль инженерного подхода к кибербезопасности, необходимо рассмотреть жизненный цикл продукта в целом, включая то, как создается программное обеспечение, а также то, что происходит после того, как оно начинает использоваться в производственной среде.
Исторически безопасность была изолирована от команды разработчиков, создающей продукт, и в результате она рассматривалась как последний шаг для обеспечения «соответствия» перед выпуском. Конечно, безопасность была не единственной частью жизненного цикла разработки программного обеспечения (SDLC), которая существовала как разрозненная; так же как и управление продуктом (PM), дизайн, инжиниринг (часто разделенный на front-end и back-end) и обеспечение качества (QA), и это лишь некоторые из них.
До принятия Agile, в котором зародилась идея межфункциональных команд, разработка программного обеспечения выглядела примерно следующим образом:
- Менеджер по продукту пишет требования и отправляет их дизайнерам.
- Дизайнеры создавали макеты и отправляли их команде разработчиков.
- Внутренние инженеры выполняли свою часть работы и отправляли оставшуюся часть команде разработчиков.
- Затем готовый продукт был отправлен на проверку в отдел контроля качества.
Поскольку на правильном этапе не были задействованы нужные люди, этот традиционный, так называемый водопадный подход привел к большому количеству потерь, неэффективности, переделок и неверных решений. Agile с его фреймворками Scrum и Kanban привел к коротким итерациям и частому выпуску кода, и, что наиболее важно, создал кросс - функциональные продуктовые команды, в которых PM, дизайнер, инженеры-программисты и QA будут работать вместе. С практической точки зрения это означало, что инженеры-программисты и QA будут предоставлять отзывы о требованиях и проектах до того, как они будут сочтены готовыми к разработке, а PM/QA будут вносить свой вклад по мере создания продукта, уменьшая необходимость последующего выбрасывания кода. и повторите то, что уже было «сделано».
Agile не решил всех проблем. В частности, с появлением DevOps инженеры DevOps оказались лишенными какого-либо контекста в отношении того, чем занимаются продуктовые группы, что сделало их работу реактивной и сложной. В конце концов, лучшие практики организационного проектирования догнали друг друга, и недавно, в 2019 году, Мануэль Паис и Мэтью Скелтон опубликовали, на мой взгляд, наиболее эффективное руководство по проектированию технологических команд — Team Topologies: Организация бизнес- и технологических групп для быстрого выполнения. В своей книге Мануэль и Мэтью рассматривают общие проблемы организационного дизайна, делятся передовым опытом в отношении успешных командных моделей и взаимодействий, а также рекомендуют способы оптимизации потоков создания ценности для технологических компаний.
До недавнего времени служба безопасности отставала от того, чтобы стать частью организации разработки, существующей как разрозненный контрольно-пропускной пункт, который, в лучшем случае, дает добро на выпуск релизов и назначает новые тикеты командам разработчиков, обычно помечаемым как «самый высокий приоритет». ». Хотя это по-прежнему наблюдается во многих организациях, в последние годы подход к безопасности начал меняться. Мы наблюдаем рост DevSecOps как ответ безопасности на DevOps, и по мере того, как безопасность встраивается в конвейеры CI/CD, ее роль меняется с соответствия требованиям на обеспечение защиты. Что касается разработки новых продуктов, безопасность действительно начинает напоминать разработку программного обеспечения.
В будущем мы, вероятно, продолжим видеть группы безопасности, работающие как автономные подразделения внутри своих организаций. Тем не менее, все больше и больше уязвимостей, связанных с приложениями, будут обрабатываться теми, кто создает продукт и имеет больше всего информации о коде, — инженерами-программистами. Группы безопасности будут выступать в качестве консультантов для групп разработчиков продуктов, подобно той роли, которую сегодня играют инженеры по надежности платформ и сайтов.
Инженерный подход к инфраструктуре и операциям безопасности
Хотя, как правило, легко представить, как может выглядеть инженерное мышление в отношении безопасности, когда мы говорим о разработке программного обеспечения, это может быть намного сложнее, когда мы рассматриваем инфраструктуру безопасности и операции, которые происходят изо дня в день. , после и вне разработки программного обеспечения. Во многом это связано с тем, что безопасность приложений является частью жизненного цикла разработки программного обеспечения, и венчурные облачные стартапы активно ищут способы защитить свой код и сделать это масштабируемым образом.
По сравнению с этим мало обсуждалось использование инженерного мышления, подходов и структур к операциям по обеспечению безопасности, обнаружению и реагированию, обработке инцидентов, цифровой криминалистике и другим областям безопасности. Эти жизненно важные компоненты процессов кибербезопасности компании рассматриваются как внутренние части, которые могут хорошо выполнять свою работу, если в сети развернуты «правильные продукты» и есть несколько человек, которые контролируют эти продукты. Что наиболее важно, командам безопасности постоянно не хватало ресурсов, и они были поглощены тушением последних пожаров, что лишало их возможности сосредоточиться на упреждающем построении защиты.
Излишне говорить, что этот подход оказался ограничивающим и часто пагубным для позиции организации в области безопасности. Хотя у меня нет доказательств, подтверждающих это заявление, я бы предположил, что большинство (если не все) компаний, о которых сообщалось в новостях как о взломах за последние несколько лет, действительно использовали новейшие и лучшие инструменты в своих системах. среда. Тот факт, что эти инструменты не смогли защитить бизнес от инцидентов безопасности, ни в коем случае не означает, что они плохо справляются со своей задачей (как раз наоборот). Вместо этого я думаю, что эти события подчеркивают, что ни один продукт не является пуленепробиваемым, несмотря на то, что может предложить маркетинг поставщика, и чтобы защитить наш бизнес и наших людей, мы должны изменить подход к безопасности.
Использование инженерного мышления для обеспечения безопасности означает несколько вещей, в том числе:
* Признание того, что инструменты — это всего лишь инструменты, и рассмотрение основ кибербезопасности как практической области, помимо выбора поставщика. Это означает задавать такие вопросы, как «Что я должен сделать, чтобы обезопасить свою организацию? Какие риски мне грозят? Какие вредоносные действия могут иметь место в моей среде? Как я их обнаруживаю? Как я буду реагировать, когда они будут обнаружены?», вместо «Какой инструмент я должен купить, чтобы защитить свою организацию?» * Вооружившись этим пониманием, компании должны применять этот подход на практике, гарантируя, что они имеют полную видимость в своей среде («единая панель»), в том, что они обнаруживают и как они это делают (знание того, какие обнаружения работают в их окружающей среды, что именно они обнаруживают и как они это обнаруживают), а также возможность тестировать свою защиту воспроизводимым образом. * Понимание того, что многие компоненты операций по обеспечению безопасности могут и должны быть автоматизированы, и поиск способов создания масштабируемых способов обеспечения защиты организации. На практике это означает использование обнаружения как кода, инфраструктуры как кода и других подходов, которые доказали свою эффективность и масштабируемость в других областях технологий. Когда команда обнаруживает новые уязвимости и вредоносное поведение, у них должны быть инструменты для реагирования на них таким образом, чтобы исключить необходимость завтра вручную применять ту же реакцию к той же уязвимости.
Исторически сложилось так, что большая часть знаний о безопасности находилась в головах опытных практиков, которые «были там, делали это». По мере взросления отрасли нам необходимо искать способы систематизировать эти знания и сделать их общедоступными, проверяемыми и доступными для использования и улучшения для организаций по всему миру. Кибербезопасность всегда будет искусством, поскольку она имеет дело с творческим, умным противником. Однако это также должно стать наукой, если мы хотим продолжать расширять нашу базу знаний и делать киберзащиту доступной для организаций, которые не могут позволить себе нанять «лучших из лучших» в этой области. Применение научно обоснованного инженерного подхода к обеспечению безопасности позволит специалистам по безопасности создавать системы и процессы для последовательного выполнения своей работы.
Расцвет техники безопасности и то, как она меняет кибербезопасность завтрашнего дня
Эволюция техники обнаружения и появление технологии обнаружения как услуги
В последние несколько лет при обнаружении угроз большое внимание уделялось прозрачности. Проблема привлекла внимание специалистов по безопасности, основателей стартапов, отраслевых аналитиков и многих других. В 2022 году два бывших аналитика Gartner Антон Чувакин и Оливер Рочфорд написали мини-статью под названием «О доверии и прозрачности в обнаружении», которая начинается следующим образом: «Когда мы обнаруживаем угрозы, мы ожидаем знать, что мы обнаруживаем. Звучит до боли очевидно, правда? Но нам совершенно ясно, что на протяжении всей истории индустрии безопасности так было не всегда. Некоторые из нас помнят первые дни появления сетевых IDS, системы обнаружения вторжений поставлялись без того, чтобы клиенты могли видеть, как обнаружения сработали. Рынок заговорил, и все эти поставщики мертвы и похоронены Snort и его потомками, которые открыли свои сигнатуры обнаружения как для просмотра, так и для модификации. ” Этот пост в блоге будет полезен всем, кто интересуется этой темой.
Среда каждой организации уникальна в своем роде, и ее уникальность только возрастает с ростом SaaS и появлением специализированных инструментов почти для всего. У каждого отдела в организации есть десятки инструментов, которые он использует для управления своей работой (представьте только количество приложений, разработанных для замены использования электронных таблиц только для отделов маркетинга, управления персоналом, финансов, продуктов и операций). Вдобавок ко всему, почти каждая компания, достигшая определенного уровня роста, разрабатывает свои собственные внутренние приложения, чтобы сэкономить на сценариях использования, уникальных для ее операций, бизнес-модели или стратегии выхода на рынок.
Уникальность среды каждой организации означает, что и способ проникновения злоумышленников в каждую организацию, и способ, которым защитники смогут обнаружить вредоносное поведение в этой среде, будут разными. С практической точки зрения, чтобы специалисты по безопасности могли решить проблему обнаружения чего-то уникального для среды своей организации, им необходимо создать логику обнаружения для этой конкретной среды.
Поставщики средств защиты, обещающие полную защиту для всех и каждого, представляют собой отличный базовый уровень (как и антивирус), но их недостаточно для компаний, которым есть что терять.
За последние 10 лет технология обнаружения сильно изменилась, так как люди, которые занимались этим для сами засвидетельствовали десятилетие. В упомянутой выше статье Зак Аллен, директор по исследованиям в области безопасности в Datadog, описывает, как подход «чем больше, тем лучше» к созданию контента для обнаружения превратился в зрелое осознание того, что нам нужен высококачественный, всеобъемлющий контент для обнаружения, а не просто «больше обнаружений». ". Инженеры по обнаружению, которых раньше считали "волшебниками", которые "спускаются со своего шпиля и проповедуют миру свои последние открытия, присутствующие на Blackhat и DEFCON", теперь являются одним из многих типов инженеров по безопасности.
Говоря об инженерии обнаружения, Зак заключает:
<цитата>«Вы не можете написать об обнаружении для своего продукта сетевой безопасности, если у вас нет экспертов по сетевой безопасности. То же самое относится и к обнаружениям на конечных точках, в облаке, в приложениях и на хостах. Это похоже на то, как группа специалистов по данным создает модель машинного обучения для выявления астмы у пациентов. Однако они забыли пригласить врача, чтобы показать им, как пациенты с пневмонией будут давать модели ложные срабатывания. Вам нужны специалисты в предметной области. Это не изменилось в отрасли, и не должно. Что изменилось, так это то, что этим экспертам нужна прочная основа в принципах разработки программного обеспечения. Вы не можете масштабировать все эти обнаружения и развертывать их в современной среде, управлять спринтами (да, это разработка программного обеспечения :)) или писать модульные, интеграционные и регрессионные тесты без большого количества тел или автоматизации. Я могу с уверенностью сказать, что мой босс предпочел бы услышать, что я могу решить проблему с помощью программного обеспечения, а не путем найма большего количества людей».
Я вижу два признака того, что инженеры по обнаружению превратились в отдельную и четко определенную профессию: растущее число мероприятий, таких как DEATHCon (технические средства обнаружения и Hunting Conference), беседы и тренинги в Black Hat, BSides и других собраниях практиков, а также начало определения стадий зрелости, которые проходят организации при ее внедрении. Матрица зрелости инженерных систем обнаружения, составленная Кайлом Бейли, является лучшей попытаться измерить возможности и зрелость функции в организациях.
По мере того, как все больше и больше организаций понимают, что логика обнаружения не подходит для всех, а поставщики систем безопасности вряд ли смогут выполнить свое обещание «обеспечить безопасность всех», мы начинаем видеть стартапы в области кибербезопасности, которые специализируются на создании средств обнаружения. содержание. Вместо того, чтобы просто инициировать оповещения, эти компании делают содержание самого правила видимым и редактируемым, что позволяет командам безопасности понять, что именно обнаруживается в их среде, как именно это обнаруживается и какие сценарии или оповещения будут запущены, когда это произойдет. обнаружен. Двумя примечательными примерами стартапов в этой области являются SOC Prime и SnapAttack, которые поддерживают де-факто стандартный язык для написания контента для обнаружения — Sigma. Вместо того, чтобы обещать полное покрытие, эти поставщики предоставляют компаниям возможность доступа к страховому покрытию на полностью прозрачной основе с оплатой по факту использования.
Не только организации могут приобрести стандартное покрытие обнаружения у поставщиков, специализирующихся на разработке средств обнаружения, но теперь они могут поручить своим поставщикам услуг безопасности создавать логику предупреждений, адаптированную к их среде. Хотя это не то, что предлагают сегодня все поставщики, я думаю, что именно к этому движется отрасль, поскольку фирмы, занимающиеся консультированием по вопросам безопасности и управляемым обнаружением и реагированием, стремятся добавить больше ценности, помимо выбора поставщика и мониторинга предупреждений. Вскоре технология обнаружения как услуга станет стандартом для поставщиков услуг безопасности.
Примечательно, что изменение ожиданий клиентов также меняет методы работы поставщиков систем безопасности, таких как обнаружение и реагирование конечных точек (EDR) и расширенное обнаружение и реагирование (XDR). Часто начинавшиеся как «черные ящики», которые запускают общую логику обнаружения, встроенную для всех своих клиентов, теперь они также предлагают клиентам возможность писать свои собственные обнаружения поверх них. Новые поставщики, такие как LimaCharlie, где я руковожу продуктом, Panther и совершенно новая категория так называемого Open XDR, также предлагают полную информацию о покрытии безопасности организации (не только настраиваемые правила, но и все обнаружения, которые выполняются в организации).
Растущее значение техники безопасности
В качестве примера я использую технику обнаружения; мы наблюдаем большой толчок в сторону инженерии во всех областях безопасности. С инфраструктурой как кодом управление инфраструктурой теперь принадлежит инженерам, а не ИТ. Таким образом, навыки разработки программного обеспечения становятся необходимым условием безопасности.
С появлением облака принципы и методы разработки программного обеспечения теперь лежат в основе того, как предоставляется инфраструктура, как применяются политики и конфигурации безопасности, как тестируется и исследуется состояние безопасности компании, как внедряются и отслеживаются изменения в конфигурациях безопасности и т. д. . В то время как инженеры DevOps отвечают за выделение ресурсов и управление инфраструктурой, инженеры по безопасности, сочетающие в себе глубокие инженерные знания и глубокое понимание безопасности, идеально подходят для ее защиты.
Сегодня большинство профессионалов в области кибербезопасности приобрели свои навыки в области ИТ, разрабатывая сетевые архитектуры, предоставляя брандмауэры и управляя политиками брандмауэров, а также выполняя другие задачи, критически важные для поддержания работы ИТ на предприятии. К сожалению, многие люди, отвечающие за безопасность, имеют лишь самое базовое представление о программной инженерии, что не позволяет им развивать навыки, необходимые им в мире, где все — инфраструктура, политики, обнаружения и т. д. — существует в виде кода. Вполне естественно, что, когда базовая инфраструктура находится в коде, специалистам по безопасности необходимо научиться программировать. То же самое верно для автоматизации и использования API: поскольку подавляющее большинство технических задач теперь решаются в масштабе через API (включая работу, которая раньше выполнялась вручную в самих командах безопасности), нам нужны люди, которые понимают, как проектировать, безопасно использовать и списывать API.
Ожидается, что группы инженеров по безопасности выйдут за рамки оперативного контроля за инженерными решениями проблем безопасности. По мере того, как все больше и больше организаций понимают, что готовые инструменты безопасности не учитывают уникальность их потребностей и сред, те, у кого есть необходимые ресурсы и поддержка, чтобы серьезно отнестись к усилению своей системы безопасности, начинают выходить за рамки настройки коммерческих продукты. Хотя в некоторых случаях инструмент, приобретенный у поставщика систем безопасности, можно использовать как есть, чаще всего он требует некоторой настройки для удовлетворения уникальных потребностей организации. Однако мы наблюдаем постоянно растущее понимание, особенно среди крупных предприятий, обрабатывающих большие объемы данных, и облачных компаний, что коммерческие инструменты не в состоянии удовлетворить множество потребностей и требований безопасности. Эти компании начинают создавать некоторые элементы своего стека безопасности собственными силами, делегируя проектирование и разработку этих решений внутренним архитекторам безопасности и инженерам по безопасности.
Том Товар из Appdome в своем недавнем подкасте предположил, что мы можем разделить организации по безопасности на три категории:
- Традиционные группы безопасности, состоящие из технически сильных профессионалов в области безопасности, обладающих глубокими знаниями в области безопасности и соответствия требованиям, а также передовых методов для обеих сторон.
- Команды специалистов по безопасности, в состав которых часто входят исследователи и архитекторы безопасности, которым поручено проектирование систем, оценка продуктов, тестирование на проникновение и т. д.
- Кибербезопасность и инженерные организации, обладающие «хардкорными» инженерными талантами, способными создавать и предоставлять решения по обеспечению безопасности для современных организаций.
Я рассматриваю эти категории не как разные стадии зрелости, а как эволюцию с точки зрения потребностей организации. Облачные компании начинают создавать группы инженеров по безопасности, предназначенные для тесного сотрудничества с DevOps, разработкой программного обеспечения и разработкой продуктов. При этом многие элементы, которые традиционно принадлежали командам ИТ и безопасности, теперь принадлежат командам DevOps и инженерам по безопасности. Эта модель, которая опирается на строителей — талантливых инженеров, способных создавать решения для обеспечения безопасности, — нужна не каждой организации. Однако по мере того, как все больше и больше компаний переходят на облачные технологии с первого дня, по мере того, как их среды становятся все более уникальными благодаря распространению инструментов SaaS, и по мере того, как все больше специалистов по безопасности осознают ценность безопасности, адаптированной к их потребностям, мы увидим огромное переход к технике безопасности.
На момент написания этой статьи мы видим, что передовой опыт организационного проектирования не поспевает за развитием техники безопасности. С практической точки зрения это означает, что, хотя группы инженеров по безопасности имеют свои собственные инструменты, за управление которыми они несут ответственность, кажется, что между инженерами по безопасности и инженерами по программному обеспечению/DevOps, а также командами операционной безопасности возникает много конфликтов, связанных с правами собственности. Справедливо сказать, что на сегодняшний день в каждой организации, которой посчастливилось иметь команду инженеров по безопасности, форма этой команды выглядит несколько иначе. Организационные конфликты и неясные сферы собственности — естественные шаги в формировании любой новой дисциплины, поэтому то, что мы видим, органично и ожидаемо.
Изменение характера роли аналитика безопасности
По мере того, как кибербезопасность становится кодом, становится все труднее и труднее тем, кто не кодирует. Я говорю об изменении роли аналитиков по безопасности.
Аналитики безопасности, традиционно подразделяемые на уровень 1 (специалист по сортировке), уровень 2 (операторы реагирования на инциденты) и уровень 3 (эксперт-аналитик), играют важную роль в команде центра управления безопасностью (SOC). Благодаря последним достижениям в области автоматизации форма этой роли начала меняться.
Прежде всего, по мере того, как службы безопасности ищут способы повышения эффективности и производительности, все больше и больше процессов и процедур в SOC, которые раньше выполнялись вручную, автоматизируются. Во-вторых, развитие искусственного интеллекта (ИИ) обещает устранить необходимость вручную сортировать тысячи предупреждений — возможно, это одна из самых больших проблем, с которыми сталкиваются службы безопасности. На сегодняшний день ИИ еще не выполнил свое обещание по автоматизации безопасности, но в конечном итоге это произойдет. Вероятно, раньше, чем нам хотелось бы представить, мы обязательно увидим битву ИИ с противниками, обучающими свои собственные модели и оборону — своими. Помимо футуристических картинок, аналитикам SOC придется приспосабливаться к меняющейся форме безопасности.
Из-за двух факторов, описанных выше, аналитики SOC (особенно те, кого традиционно называют «Уровнем 1») должны начать осваивать новые навыки. Наиболее важным техническим навыком является программирование, и аналитики понимают это, как показано голосом аналитика SOC. исследование по заказу Tines в 2022 году.
В отрасли достаточно паникеров, предполагающих безрадостное будущее аналитиков, но я вижу это по-другому. Роль не уходит, но ее форма и объем будут меняться. В прошлом работа аналитика сводилась главным образом к знанию того, как использовать определенные продукты безопасности. Теперь безопасность начинают рассматривать не как проблему инструмента, а скорее как проблему подхода. Кроме того, инструменты безопасности становятся коммерциализированными и стандартизированными, так что все они работают одинаково: если аналитик использовал один EDR, скорее всего, ему не потребуется много времени, чтобы изучить другой. Какие именно продукты аналитик использовал в прошлом, станет менее важным, чем его понимание основ безопасности. Аналитики, которые хотят оставаться актуальными по мере развития отрасли, должны будут стать более техническими. Хотя не каждый будет и должен стать инженером, все более и более важным будет понимание того, как субъекты угроз видят мир и как проводятся атаки.
Я думаю, что будущее аналитиков в области безопасности будет похоже на будущее специалистов по обеспечению качества (QA) в разработке программного обеспечения. Подавляющее большинство заданий по контролю качества больше не выполняются вручную и требуют использования инструментов автоматизации, языков и фреймворков. Больше всего платят те, кого Amazon и многие другие компании теперь называют «инженерами-испытателями» — инженерами-программистами, специализирующимися на тестировании функциональности продукта и API-интерфейсов. Ручной QA все еще существует, но его трудно найти, роли невероятно конкурентоспособны, и, поскольку предложение квалифицированных работников значительно превышает спрос, они получают самую низкую компенсацию. Механический турок Amazon кардинально меняет правила игры, еще больше снижая стоимость контроля качества. Система обеспечения качества не умерла, но сильно изменилась (и, что особенно важно, для ее изменения не понадобились передовые технологии искусственного интеллекта и машинного обучения).
Стек безопасности будущего
По мере того, как специалисты по безопасности становятся более техническими, они начинают понимать, что ни один поставщик не может обещать «безопасность» и «защиту» как функцию. Традиционно большинство коммерческих инструментов безопасности абстрагировали базовые уровни от групп безопасности и предлагали представление высокого уровня в виде предупреждений и отчетов, в которых резюмировалось, что произошло. Организации, которым требовалась видимость базовых уровней инфраструктуры безопасности и данных на уровне событий, были вынуждены использовать инструменты с открытым исходным кодом или создавать инструменты с нуля.
Поскольку подход DevSecOps требует наблюдения за базовыми уровнями безопасности, стек безопасности будущего будет сильно отличаться от того, что мы видим сегодня, когда смотрим на так называемые карты рынка кибербезопасности. Прежде всего, мы будем видеть все больше и больше нейтральных решений, которые могут быть использованы практиками для опроса своих систем, получения полной информации об их среде и построения системы безопасности с учетом их потребностей. Эти инструменты будут работать прозрачно, а выполняемую ими работу будет легко протестировать и проверить. Важно отметить, что мы увидим сочетание коммерческих решений и решений с открытым исходным кодом, которые можно заставить работать вместе для решения задач безопасности организации. В центре безопасности будут процессы и специалисты по безопасности, а не «продукты», поскольку инструменты — это всего лишь инструменты; важно то, как они используются и для чего они используются.
В последние несколько лет мы стали замечать, что все больше и больше лидеров в области безопасности отвергают идею слепого доверия поставщикам: это подход, который мы продвигаем в LimaCharlie, где я руковожу продуктом, а также подход, принятый другими решениями нового поколения, такими как SOC Prime, Panther, Prelude и большинство недавно - Интерпрес, и это лишь некоторые из них.
На изображении ниже представлен список современных компаний и инструментов с открытым исходным кодом, которые используют инженерный подход к безопасности, основанный на фактических данных. Она не претендует на исчерпывающую полноту (существует множество других отличных инструментов, соответствующих вышеперечисленным критериям), и это не традиционная «карта рынка».
Сокращение дефицита талантов
Чтобы нанять талантливых специалистов, бизнесу необходимо изменить методы работы
Команды службы безопасности, защищающие предприятия от злоумышленников, испытывают стресс, недоукомплектованы персоналом, им недооценивают и недоплачивают. Реальность такова, что хакерские группы лучше любой корпорации привлекают специалистов с глубокими техническими знаниями. Они платят им без налогов и намного больше, чем любое предприятие. Они предлагают отличный баланс между работой и личной жизнью, острые ощущения от взлома и чувство достижения. Большинство из них на 100% анонимны. Нет необходимости накапливать бесполезные сертификаты и платить несколько сотен долларов каждые несколько лет, чтобы поддерживать их в актуальном состоянии, и не нужно иметь дело с рекрутерами, кадрами, базовым обучением по соблюдению нормативных требований, политикой на рабочем месте, юридическими вопросами, соблюдением нормативных требований, расчетом заработной платы и требовательным начальством. в довершение всего. Если это звучит так, как будто я рекламирую работу на противника, это вовсе не мое намерение, и правда в том, что все это не ново для опытных специалистов по безопасности. Я просто демонстрирую, что для того, чтобы нанять великих талантов, бизнес должен работать лучше.
Эта публикация в сочетании с тем фактом, что многие из самых лучших специалистов по безопасности не чувствуют мотивации иметь дело с бюрократией работы в крупных корпорациях, рисует мрачную картину текущего рынка труда.
Было бы неэтично и неверно предполагать, что у меня есть список быстрых и простых решений, поэтому мы, как отрасль, должны найти их вместе. Мы можем начать с отказа от требования «5 лет опыта работы» для вакансий начального уровня и развивать это по мере продвижения, устраняя предубеждения и улучшая наш процесс найма.
Привлечение инженеров-программистов к обеспечению безопасности
Поскольку все, что связано с безопасностью, превращается в код, одним из редко обсуждаемых каналов привлечения талантов в области кибербезопасности может стать разработка программного обеспечения. Некоторые утверждают, что, возможно, легче научить инженеров безопасности, чем технических специалистов по безопасности, разрабатывающих программное обеспечение. Хотя я не тот человек, чтобы судить о правильности этого утверждения, я видел достаточно разработчиков программного обеспечения, превращающихся в специалистов по безопасности, чтобы знать, что этот путь реален.
Задача заключается в том, чтобы сообщить о том, что кибербезопасность — это перспективная карьера для выпускников программных инженеров, предоставить им необходимую подготовку (добавление углубленных курсов по кибербезопасности к программам компьютерных наук) и разработать значимые карьерные пути для них. свой путь в кибербезопасности. Это поднимает вопрос о компенсации за многие должности начального уровня в области кибербезопасности, которыми могут командовать новые выпускники: если человек может получить свою первую работу в области программного обеспечения, которая оплачивается на 20-40% выше, чем все, что ему предлагают в области безопасности (если он может даже пройти собеседование ), вся идея заставить инженеров-программистов заниматься безопасностью разваливается.
Обучение нового поколения инженеров по безопасности
Много говорят о нехватке специалистов в области кибербезопасности, и легко заметить море новых участников, обещающих решить эту проблему. От 6-недельных учебных курсов по кибербезопасности до онлайн-курсов, а также новых дипломов в колледжах и университетах — каждый хочет получить свой кусок пирога в «обучении будущему безопасности». Соблазнительно думать, что все, что нам нужно, это привлечь больше старшеклассников и взрослых, готовых сменить профессию, взволнованных безопасностью, и зарегистрироваться в этих программах, и через 3-5 лет у нас все готово, я вижу, что проблема становится намного глубже.
Если вы посмотрите на подавляющее большинство образовательных программ, то заметите, что в их учебных планах отсутствует инженерная составляющая. Я не тратил достаточно времени на сбор данных, поэтому мои наблюдения на эту тему довольно анекдотичны, но вот что я вижу:
* Большинство буткемпов настолько короткие и настолько высокоуровневые, что было бы неразумно полагать, что они могут дать своим выпускникам какие-либо глубокие знания в отрасли. Я встречал много замечательных профессионалов в области безопасности, которые прошли учебные курсы. Однако они стали великими не потому, что попали на буткемп, а благодаря тому, что делали вне его. Я не утверждаю, что эти короткие иммерсивные курсы бесполезны. Чтобы проиллюстрировать то, что я пытаюсь донести, я призываю вас задуматься о том, почему существует так много 4-8-недельных буткемпов, обучающих фронтенд-разработке, и так мало 4-8-недельных тренингов, обучающих бэкенд-разработке. Ответ прост, потому что внутренняя разработка, как и безопасность, требует глубокого понимания глубоко технических теорий и концепций, а также способности обрабатывать эти концепции и реализовывать их в коде часто без какой-либо визуальной обратной связи. Я официально заявляю, что вы не можете научить этому за то же количество времени, которое требуется, чтобы научить людей создавать простой веб-сайт. * Многие университетские программы, особенно на уровне магистратуры, больше сосредоточены на написании политик, чем на развитии практических навыков. Даже те из них, которые более глубоки и практичны, имеют тенденцию быть тем, чем является университетское образование в целом — слишком старыми, слишком теоретическими и слишком поверхностными. Безопасность развивается ежедневно, ежедневно появляются новые эксплойты, новые уязвимости, новые векторы атак и новые технологии. Университетские программы должны пройти длительные утверждения, строгие академические обзоры и оценки, настолько, что к тому времени, когда программа утверждается, в ней говорится о новостях шестимесячной или более давности. Есть несколько замечательных учителей и инструкторов, которые усердно работают, чтобы идти в ногу с отраслью и обучать своих студентов полезным, практическим и актуальным навыкам. Мы все должны быть глубоко благодарны за их работу, но стоит сказать, что эти люди не работают в русле самой системы образования, а скорее обходят ее ограничения, принося пользу ученикам и обществу. * Сертификаты кибербезопасности не отражают навыков и опыта, необходимых рынку. Я не собираюсь уменьшать количество усилий, которые люди вкладывают в них, и я не утверждаю, что они не представляют никакой ценности. Вместо этого я имею в виду, что, за очень, очень немногими исключениями, эти сертификаты предлагают теоретические концепции и заставляют людей чувствовать, что они знают, как должна обеспечиваться безопасность, не давая никаких реальных навыков для ее выполнения. Пока злоумышленники углубляются в код и ищут способы обойти средства контроля, использовать уязвимости и украсть данные, мы, кажется, всерьез думаем, что можем остановить их, научив людей писать политики и сдав экзамены с несколькими вариантами ответов по облачной безопасности. . Представьте, что вас оперирует кардиохирург с «сертификатом на сердце», который в жизни не делал ни одной операции (не могу).
Все это долгий путь к тому, чтобы сказать, что сегодняшние лучшие специалисты по безопасности не выходят из университетов, и ни то, что кажется, не придет завтра. Люди, которые становятся передовыми профессионалами в области инженерии безопасности, приходят с практической работы в тестировании на проникновение, в вооруженных силах, АНБ и других государственных учреждениях с сильными наступательными компонентами. Они исходят от опытных команд безопасности на облачных предприятиях, которые серьезно относятся к безопасности. Они самоучки перед своими компьютерами, на соревнованиях CTF (захват флага) и на таких мероприятиях, как Open SOC, Black Hat, DefCon и т. п.
Чтобы сформировать будущее безопасности и ликвидировать нехватку кадров, мы не можем сидеть и надеяться, что достаточно целеустремленных людей найдут способ обучиться навыкам, которые им необходимы для обеспечения безопасности наших людей, бизнеса и стран. Надежда — это не стратегия, равно как и 6-недельные буткемпы; нам необходимо создавать системы и институты, чтобы ликвидировать пробел в технической кибербезопасности. Безопасность сложна. Обучение безопасности тоже сложно, но это необходимо. Соблюдение нормативных требований и написание политик важны, но сами по себе они не помогут нам защитить наши сети от злоумышленников — невероятно талантливых, высококвалифицированных, мотивированных и хорошо оплачиваемых.
Хотя нам нужно найти способы вовлечь инженеров-программистов в кибербезопасность, нам также нужны узкоспециализированные специалисты по безопасности, чтобы приобрести инженерные навыки. Хотя не каждый специалист по реагированию на инциденты, цифровой криминалистике и безопасности конечных точек станет инженером, почти всем будет полезно знать основы разработки программного обеспечения и свободно владеть такими языками, как Python. Принятие инженерного подхода к операциям по обеспечению безопасности позволит нам автоматизировать ручные операции по реагированию на инциденты и постоянно создавать масштабируемые способы защиты периметра организации, уделяя больше времени проактивному созданию средств защиты. Для этого образование в области кибербезопасности должно начать включать курсы по разработке программного обеспечения так же, как программы по разработке программного обеспечения и компьютерным наукам должны обучать основам безопасности.
Заключительные мысли
Действительно, не существует панацеи, которая решит все наши проблемы с безопасностью, и увеличение числа инженеров по безопасности также не поможет. Однако применение инженерного подхода к безопасности может помочь нам обеспечить безопасность программных продуктов с самого начала, ускорить развитие отрасли и подготовить наши операции по обеспечению безопасности к будущему.
Нехватка талантов, безусловно, станет препятствием. Однако только потому, что у нас нет необходимых ресурсов, мы не можем и не должны отказываться от жизнеспособного решения сложной проблемы. Также ясно, что мы должны изменить нашу практику найма и переоценить критерии, используемые для определения будущих лидеров безопасности. Мы получаем то, для чего оптимизируем. Каждый день злоумышленники тратят бессчетное количество часов на изучение новых технологий, реинжиниринг программного обеспечения, которое мы создаем, и поиск уязвимостей в коде. Если мы посмотрим на объявления о вакансиях в области безопасности, легко сделать вывод, что мы надеемся остановить злоумышленника, пройдя тесты с несколькими вариантами ответов и получив сертификаты, которые сильно отличаются от навыков, необходимых для понимания того, как работает код и как его защитить.< /p>
Я убежден, что инженерный подход к кибербезопасности неизбежен. Мы уже начинаем видеть признаки его роста, и с этого момента он будет только ускоряться. Вопрос в том, как быстро мы сможем построить инфраструктуру для его развития? Если история нас чему-то и научила, так это тому, что состояние практики кибербезопасности в целом отстает на годы от последних и величайших докладов, сделанных на DefCon, Black Hat и им подобных. Нам предстоит увидеть, какие события изменят отрасль дальше.
Основное изображение для этой статьи было создано с помощью генератора AI-изображений через подсказку "кибербезопасность".
Оригинал