DE{CODE}: обеспечение безопасности ваших сайтов WordPress в условиях роста числа глобальных кибератак

Опубликовано: 2023-02-12

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

Видео: Обеспечение безопасности ваших сайтов WordPress в условиях роста числа глобальных кибератак

Слайды сессии

Обеспечение безопасности ваших сайтов WordPress в условиях роста числа глобальных кибератак.pdf от WP Engine

Полный текст стенограммы

ЭРИК ДЖОНС : Добро пожаловать в DE{CODE}, и спасибо, что присоединились к тому, что обещает стать невероятным прорывом. Меня зовут Эрик Джонс, и я вице-президент по корпоративному маркетингу в WP Engine. Я очень взволнован тем, что сегодня модерирую эту дискуссию между Джо Салливаном, директором по безопасности Cloudflare, и Брентом Стэкхаусом, вице-президентом по безопасности WP Engine, которые имеют многолетний опыт работы в области безопасности.

Наше обсуждение «Обеспечение безопасности ваших сайтов WordPress в условиях роста числа глобальных атак на кибербезопасность» как нельзя более своевременно, учитывая, что количество кибератак не только растет, но и находится на рекордно высоком уровне. Джо, почему бы нам не начать с тебя? Я хотел бы услышать с широкой точки зрения, какие тенденции вы видите в ландшафте кибербезопасности.

ДЖО САЛЛИВАН : Конечно. Я рад присоединиться. Спасибо, что пригласили меня на этот разговор. Я тоже очень жду. Я думаю, что сейчас в мире безопасности есть две мегатенденции. Во-первых, это гораздо важнее в глазах всего мира.

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

Безопасность больше не является командой или концепцией, которая сидит в углу организации. Это занимает центральное место во всем, что мы делаем. Генеральные директора привлечены к ответственности. Советы задают трудные вопросы. Венчурные капиталисты не будут вносить свой вклад, если не увидят правильный уровень инвестиций.

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

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

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

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

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

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

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

ЭРИК ДЖОНС: Джо, в качестве дополнительного вопроса, что вы думаете о приоритизации всех тех конкретных проблем, которые есть у вас и у каждой организации по безопасности?

ДЖО САЛЛИВАН: Конечно. Я думаю, что это последний вопрос. Если бы у нас был неограниченный бюджет и неограниченное количество людей, которые могли бы выполнять работу, мы могли бы сделать все это. Но это не реальность любой организации на любом этапе ее развития.

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

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

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

ЭРИК ДЖОНС: Да, я думаю, вы наткнулись на ключевой момент в безопасности, не так ли? Что это то, за что мы все несем ответственность. Это общая ответственность всей организации. Он живет не только в команде безопасности. Он живет с каждым сотрудником в конкретной компании.

Брент, обращаясь к вам, с точки зрения WordPress, что общего, что отличается в WordPress и каковы наиболее уязвимые места, которые вы видите в ландшафте?

БРЕНТ СТЭКХАУЗ : Спасибо, Эрик, и спасибо за приглашение. Цените время, проведенное с Джо. Он много чего знает. Мы были вокруг квартала пару раз. Так что это увлекательно.

WordPress во многих отношениях — новости, как правило, хороши в том смысле, что WordPress Core отличается от всех плагинов, тем и других вещей в экосистеме WordPress. WordPress Core продолжает оставаться надежным и устойчивым к распространенным атакам.

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

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

А так зависит. Таким образом, по мере роста популярности WordPress и популярности экосистемы можно предположить, что злоумышленники будут продолжать наращивать свои усилия, потому что злоумышленники идут туда, где есть деньги, подобно тому, почему в Windows больше вредоносных программ, чем в Mac в целом. Это потому, что там след, и там деньги.

Таким образом, WordPress ничем не отличается, и по мере роста его популярности можно ожидать, что злоумышленники будут продолжать делать то, что он делает. Хорошая новость заключается в том, что по сравнению с тем, когда я запустил WP Engine четыре года назад, экосистема в значительной степени стала более здоровой.

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

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

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

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

ЭРИК ДЖОНС: Чтобы дважды щелкнуть что-то, что вы сказали о WordPress Core, что такого в самой природе программного обеспечения с открытым исходным кодом, что, возможно, помогает решить эту проблему, связанную с его безопасностью? Потому что я думаю, что это одно из тех заблуждений и мифов, что программное обеспечение с открытым исходным кодом каким-то образом не является фундаментально безопасным.

БРЕНТ СТЭКХАУЗ: Это отличный вопрос. И мне было бы интересно узнать мысли Джо по этому поводу. И не для того, чтобы бросать тебе вызов, Эрик, но я уже достаточно взрослый. Я видел, что то, что мы подразумеваем под открытым исходным кодом, довольно сильно изменилось с течением времени.

В свое время с открытым исходным кодом были очень известные проекты, такие как Apache, или, скажем, OpenSSH, или, скажем, Linux и тому подобное, и когда мы тогда говорили об открытом исходном коде, это то, что мы обычно имели в виду. ссылаясь на.

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

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

Потому что с открытым исходным кодом — я вспоминаю ваш вопрос, Эрик, о WordPress. Хорошо, что источник есть. Многие смотрят на это. Я думаю, что то же самое было и с Apache и тому подобными вещами. Все, что широко используется, будет тщательно изучаться как хорошими, так и плохими парнями, и я думаю, что это хорошо. Безопасность через неизвестность никогда не была хорошей практикой. Так что наличие кода — это здорово.

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

Несомненно, у них есть независимые исследователи, которые регулярно сообщают им о своих выводах. И умные команды принимают эти данные и поступают правильно. Я уверен, что они сами проходят тестирование на проникновение и т. д. Так что мы делаем похожие вещи в WP Engine, но это своего рода норма для курса.

Джо, есть мысли по этому поводу? Извини, что вмешиваюсь, Эрик, но…

ЭРИК ДЖОНС: Нет, это идеально.

ДЖО САЛЛИВАН: Я думаю, вы многого достигли в самых ярких моментах. Когда я думаю о программном обеспечении с открытым исходным кодом — когда я думаю о программном обеспечении из любого источника, я думаю, что мы должны оценить его, прежде чем внедрять в нашу среду. И иногда программное обеспечение с открытым исходным кодом будет лучшим выбором, чем проприетарное. Потому что знаешь что? Солнечный свет убивает инфекцию.

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

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

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

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

БРЕНТ СТЭКХАУС: Да, во многом это касается – и это термин для любителей риска – но и об уверенности. Какие гарантии мы можем получить для всего, что мы делаем, в техническом смысле, насколько безопасно, когда мы делаем A, B, C. И много гарантий, в зависимости от ситуации с закрытым исходным кодом, получить сложнее.

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

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

ЭРИК ДЖОНС: Итак, для разработчиков, которые там находятся, каковы те конкретные гарантии, которые вы оба ищете в компаниях? Если в этих проектах или частях программного обеспечения есть эти вещи, вы считаете их хорошими, немного более безопасными, чем они могли бы быть в противном случае.

БРЕНТ СТЭКХАУС: Хотите ответ на WordPress? Я отпущу Джо, если ты вообще хочешь начать.

ЭРИК ДЖОНС: Да, Джо, если бы вы могли представить, может быть, широкую перспективу, а затем, Брент, вы могли бы представить более конкретную перспективу WordPress.

ДЖО САЛЛИВАН: Да, с того места, где я сижу, я думаю об этом вопросе как покупатель и как продавец, потому что я работаю в Cloudflare, где люди внедряют наши продукты. И вопрос номер один, который возникает у любого клиента Cloudflare перед внедрением Cloudflare, заключается в том, стоит ли доверять Cloudflare? Потому что мы сидим перед всем их бизнесом. И это действительно рискованное место, чтобы положить кого-то, если вы не доверяете им.

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

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

Когда я говорю о сертификации, я имею в виду такие вещи, как SOC 2, SOC 2 Type II, как у WP Engine, или ISO 27001, или PCI. Когда вы слышите эти слова и сертификаты, вы должны подумать, что третья сторона использовала признанный набор стандартов, чтобы провести аудит этой компании и оценить, соблюдаются ли они всеми контрольными требованиями в этой области.

Итак, у каждого из нас — у Cloudflare есть отчет SOC 2 Type II, которым мы можем поделиться. WP Engine имеет отчет SOC 2 Type II, которым мы можем поделиться. И что приятно, когда я говорю Тип II, это означает, что это был не просто аудит на определенный момент времени. Это был длительный период времени.

Так, например, с нашим SOC 2 Type II это означает, что за последний год, в любой момент в течение того времени, для которого существует эта сертификация, мы соблюдали эти минимальные меры безопасности. Так часто этого достаточно для клиента. Например, у этой компании есть SOC 2 Type II. Хорошо, я буду им доверять.

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

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

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

ЭРИК ДЖОНС: И, Брент, возвращая вопрос к вам, что вы думаете об этом в контексте WordPress?

БРЕНТ СТЭКХАУС: Да, я думаю, это здорово. Когда люди рассматривают возможность расширения экосистемы WordPress, так сказать, с помощью плагинов и тем, нужно обратить внимание на пару вещей даже в бизнес-контексте или бизнес-уровне: насколько популярен данный фрагмент кода, плагин или тема? И могу ли я увидеть в их журнале изменений, что они регулярно обновляются, в том числе для обновлений безопасности?

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

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

Одна вещь, которую Джо затронул, и я тоже с вами немного поговорю, это то, что WP Engine также является как потребителем кода, так и производителем, поэтому мы также являемся поставщиком услуг и очень обеспокоены целостностью нашего сквозные усилия по развитию. И это постоянная проблема.

Таким образом, одна из вещей для наших разработчиков, работающих с сайтами WordPress, заключается в том, что они должны быть осведомлены, надеюсь, о контексте их организации в отношении рисков. Например, в какой они вертикали? Насколько терпима организация к происходящим плохим вещам? Определенные секторы или организации гораздо более восприимчивы к таким вещам, как DDoS-атаки и т. д.

Так что, думая об этом и потенциально кодируя эти вещи, вы не можете кодировать DDoS, но вы, безусловно, можете знать об этом и всплывать на поверхность. Я думаю, что это очень важно для разработчиков, которые поступают правильно.

ЭРИК ДЖОНС: Небольшое переключение передач, и с целью попытаться дать некоторые очень конкретные рекомендации, Джо, с точки зрения безопасности высокого уровня, что бы вы порекомендовали владельцам веб-сайтов, чтобы помочь укрепить свою безопасность?

ДЖО САЛЛИВАН: Да, как я думаю, унция профилактики стоит фунта лечения. И, в контексте безопасности, это означает выбор правильных инструментов и платформ, которые вы собираетесь использовать, прежде чем начать, а не пытаться что-то создать, и теперь давайте выясним, как мы настроим безопасность поверх этого.

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

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

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

Второе, о чем я бы подумал, это хорошо, у меня будет куча кода, обращенного к Интернету. Как противостоять атакам из Интернета? Должен ли я пойти на это? Брент упомянул атаки типа «отказ в обслуживании».

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

И затем, как третий столп, вероятно, о котором мы здесь не говорим, — как мне настроить ноутбуки и тому подобное?

ЭРИК ДЖОНС: И, Брент, может быть, переходя к вам, о каких конкретных вещах разработчики WordPress должны думать, чтобы создавать максимально безопасные сайты?

БРЕНТ СТЭКХАУС: Да, мой первый ответ — это интересно. Многое из того, о чем мы говорим, — это решение о том, когда строить, а когда покупать. Собираетесь ли вы создавать свои собственные плагины и все, что вы хотите сделать, чтобы расширить свою экосистему WordPress? Или вы собираетесь покупать так сказать даже если бесплатно?

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

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

Но помните о Топ-10 OWASP. OWASP Top 10, наверное, хорошо знаком нашей аудитории. Но, опять же, основы важны, как упоминал ранее Джо, и поэтому основы для разработчиков, безусловно, включают в себя Топ-10 OWASP.

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

Третий момент связан с проблемой цепочки поставок, о которой мы говорили. Кроме того, на GitHub есть несколько бесплатных функций, которые действительно могут сообщить вам об известных уязвимостях в исходных зависимостях. Так что Dependabot, бот зависимостей, — это отличная вещь, которую предоставляет GitHub, и вы обязательно должны включить ее в своих репозиториях. И он может автоматически создавать PR. И тогда у вас будет возможность объединить это, если вы считаете, что вам это нужно, чтобы ваши исходные зависимости, по крайней мере, не имели известных уязвимостей.

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

ЭРИК ДЖОНС: Полагаю, вопрос к вам обоим таков: что из того, что, по вашему мнению, происходит, не совсем в поле зрения прямо сейчас? И о чем должны думать люди, разработчики, владельцы веб-сайтов, чего они сейчас не делают? И это открытый вопрос для любого из вас.

БРЕНТ СТЭКХАУЗ: Ну, да, я хочу вмешаться, потому что Джо ранее ответил на вопрос об Окте. Итак, эта конкретная группа — это интересно. Так мы это уже видели. Так что я даже не могу сказать, что это почти сходит с ума.

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

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

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

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

ДЖО САЛЛИВАН: Да, я думаю, что еще один способ выразить то, что сказал Брент, немного другим тоном: я на самом деле не хочу, чтобы разработчики проводили много времени с хрустальным шаром, пытаясь предвидеть следующую проблему безопасности. Важнее правильно усвоить основы.

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

Но это не значит, что вы идете и покупаете продукт для блокировки программ-вымогателей. Вы возвращаетесь и делаете то же самое, что уже должны были делать, чтобы справиться с предыдущими угрозами. Что такое программы-вымогатели? Это вредоносное программное обеспечение, которое помещается в вашу среду.

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

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

ЭРИК ДЖОНС: Джо и Брент, большое вам спасибо за ваше мнение, ваше время и ваши советы сегодня. Так много о чем нужно подумать, чтобы правильно понять основы, важность прозрачности, на что обращать внимание с точки зрения страхования.

И затем, возможно, самое главное, что безопасность никогда не должна быть запоздалой. Вы должны сделать это встроенным с самого начала. Я призываю всех: если вы хотите узнать больше о предложениях безопасности WP Engine или Cloudflare, посетите наши веб-сайты. И, конечно же, в WP Engine у ​​нас есть множество информации о безопасности, доступной каждому в нашем Центре ресурсов, если вы заинтересованы в конкретной перспективе WordPress. Итак, еще раз, всем тем, кто настроился сегодня, спасибо за потраченное время и за то, что присоединились к нам сегодня.