Как стать автором
Обновить
0
Panda Security в России и СНГ
Облачные решения безопасности, антивирусы

Zane Lackey: “Не следует инвестировать в безопасность, только чтобы соответствовать требованиям закона”

Время на прочтение 6 мин
Количество просмотров 2K
Автор оригинала: Panda Security


Роль руководителя по информационной безопасности постоянно повышается, переходя от традиционного «сторожа» к более универсальному общекорпоративному куратору вопросов безопасности. Сегодня наш гость – это Зейн Лаки (Zane Lackey), один из наиболее важных «белых» хакеров в мире, автор таких книг как «Mobile Application Security» и «Hacking Exposed: Web 2.0.». В настоящее время Лаки является соучредителем и руководителем по безопасности (CSO) в компании Signal Sciences, которая предлагает платформу по защите веб-приложений, а также членом совета директоров в Internet Bug Bounty Program и Open Technology Fund.

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

Мы начали свое интервью, вспомнив те времена, когда Зейн был «белым» хакером.

Panda Security (P.S.): Какие техники Вы используете для обнаружения уязвимостей и выявления угроз, чтобы избежать атаки?

Зейн Лаки (Z.L.): Возвращаясь к моим «пентестинговым» дням, которые уже были достаточно давно, наиболее распространенные вещи, которые я искал, — это аксиомы, которые были сделаны при разработке системы. Затем я искал те из них, что можно было бы нарушить. Встав на сторону защиты, я принял этот образ мышления, думая о том, как усилить команду разработчиков и команду DevOps. Это был один из самых серьезных выводов, которые я сделал для себя: переходя от «белого хакера», консультанта по безопасности, пентестинга к CISO и построению компании в сфере безопасности, я действительно сосредоточен на том, как дать команде инженеров максимально возможное видение того, что происходит при производстве.

P.S.: Как программы подобные Internet Bug Bounty помогают устранят обнаруживаемые уязвимости? Что Вы делаете после того, как обнаружена очередная дыра безопасности?

Z.L.: Я знаю, что в последнее время произошли некоторые изменения в программе Bug Bounty, поэтому я не хочу говорить что-либо, что может показаться некорректным здесь, но я думаю, что важно попытаться установить связь с исследователями, которые приходят. Потому что очень часто вы получаете отчет, который частично содержит или вообще не содержит информацию, которая необходима для воспроизведения инцидента. Поэтому, если есть возможность сказать: «Эй, вот пять битов информации, которые нам необходимы, чтобы мы могли адресовать это команде соответствующего сервиса или приложения», то это поможет коммуникациям с обеих сторон. И в то же время, пытаясь вернуться к исследователям, ведь это не только «черный ящик» для них. Пытаться быть максимально прозрачным и открытым для обеих сторон – вот то, что действительно приводит Bug Bounty к хорошему опыту, как для исследователей, так и для компаний, которые работают с ними.

Я думаю, любой, кто запускает свою программу Bug Bounty, старается видеть вещи со всех сторон. Вы видите все: от систем, о которых вы не знали, до практически всех типов уязвимостей, даже тех, про существование которых вы не подозревали. Поэтому я действительно твердо верю в ценность таких программ, и я думаю, что они очень хорошо дополняют пентестинг. Их сочетание действительно может помочь большинству программ безопасности. Причина, по которой я люблю программы Bug Bounty, где присутствует такое сочетание с пентестами, заключается в том, что такой подход позволяет вам ориентировать ваши пентесты на вполне конкретных областях вместо того, чтобы пытаться тестировать все подряд, на что может и не хватать времени. Так что вы можете использовать ваши программы bug bounty, чтобы попытаться получить широкий охват, и вы можете использовать свои пентесты, чтобы тщательно закрыть определенную область.

P.S.: Недавно NHS нанял хакеров для выявления кибер-угроз. Считаете ли Вы, что «этические» хакеры не заменимы в современных компаниях, чтобы избегать инцидентов безопасности и усиливать свою защиту?

Z.L.: В каждой организации необходимо думать о том, как люди на самом деле атакуют ваши системы. Итак, «белые» хакеры, пентестинг и bug bounty – это все части этого. Т.е. это не вся история, но они ее часть. Вы ведь не хотите делать безопасность только ради того, чтобы соответствовать каким-то требованиям законодательства, или только пытаясь проверить, насколько хорошо работают все имеющиеся модули защиты. Я призываю людей всегда иметь в виду одну вещь, когда они думают о создании программы безопасности: как хакер на самом деле мог бы атаковать мою организацию? И никогда не забывайте об этом, чтобы развивать свои имеющиеся программы защиты. Так что «белые» хакеры, программы bug bounty и все различные способы тестирования вашей системы могут стать очень мощным контуром обратной связи. Потому что они могут показать, когда ваши системы будут атакованы, «вот куда они пошли». И на этом можно сфокусировать ваши усилия по защите.
Так что, я действительно твердо верю в баланс нападения и обороны и их использования для развития друг друга, а не в попытки делать одно в изоляции от другого.

P.S.: Как Вы можете реализовывать DevOps, чтобы сделать компании безопаснее?

Z.L.: Я считаю, что использование DevOps и Cloud может сделать вас безопаснее. Причина этого кроется в том, что в любой методологии разработки у вас все равно будут уязвимости. Как только вы осознаете этот факт, то вы увидите простой логический вывод: технология разработки, которая позволит вам реагировать как можно быстрее, позволит вам стать более безопасным. В старой модели проблема заключалась в том, что не было возможности реагировать быстро. Вот почему DevOps, Cloud, и переход к Agility действительно могут сделать вас безопаснее.

P.S.: Какой урок мы можем извлечь из случаев массовой кражи данных подобно Equifax, которые произошли благодаря уязвимости веб-приложения?

Z.L.: Я бы сказал, что есть два вывода, которые мы должны сделать из нарушений целостности данных, наблюдающихся каждый день. Один из них заключается в том, что в 99% случаев причинами инцидентов являются вполне распространенные ошибки: слабый пароль, не обновленная система или приложение, заражение конечного устройства вредоносной программой и т.д. Поэтому, возвращаясь к предыдущему комментарию, я бы посоветовал всем организациям думать не о “безумных, спонсируемых государствами угрозах нулевого дня, которые являются очень сложными», а сосредоточить свое внимание на простых вещах: как вы контролируете вредоносные программы на ваших конечных устройствах? Как вы используете двухфакторную аутентификацию на всех ваших аккаунтах? И как вы обеспечиваете безопасность на уровне веб-приложений?

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

P.S.:Как Вы думаете, компании уже готовы к новому европейскому законодательству о защите персональных данных (GDPR)? Что они должны сделать, чтобы соответствовать всем требованиям этого нового закона и защитить свои данные?

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

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

P.S.: С точки зрения безопасности приложений, Вы предпочитаете безопасность за счет программирования изнутри или защиты извне?

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

Основное сходство, которое я вижу среди организаций, старающихся делать все правильно – это то, что они пытаются устранить ошибки еще до выхода своих приложений. Они признают, что уязвимости будут всегда, а потому они инвестируют серьезные средства в обеспечение видимости того, как эти сервисы могут быть атакованы при эксплуатации своих приложений, а потому пытаются предоставить эту видимость непосредственно разработчикам и командам DevOps. В итоге они могут эффективно использовать эту информацию и не полагаться целиком и полностью на специалистов по безопасности для защиты сервисов, которые они создают.
Теги:
Хабы:
+8
Комментарии 1
Комментарии Комментарии 1

Публикации

Информация

Сайт
www.cloudav.ru
Дата регистрации
Дата основания
Численность
Неизвестно
Местоположение
Россия

Истории