Могут ли программисты писать безопасный код?

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

В этом видеоролике Денис Батранков рассказывает о том, как современные методы тестирования помогают находить уязвимости в программном коде до того, как они станут проблемой. Также узнаете о таких инструментах, как DAST, SAST и RASP, которые выявляют слабые места в приложениях на ранних стадиях.

Расшифровка видео

Начало
0:02
[музыка]
0:03
[аплодисменты]
0:08
[музыка]
0:10
Здравствуйте я Денис транков более 30
0:13
лет занимаюсь практической
0:14
информационной безопасностью и делюсь
0:15
Свами знаниями даже до физических лиц
0:18
докатились атаки на уязвимости и каждый
0:20
из нас в курсе про проблемы с
0:21
безопасностью Проблема в том что все
0:24
уязвимости написаны или самими
0:25
программистами или вызваны неверными
0:28
настройками понятно что не на
Мы хотим от программистов, чтобы они сразу писали без уязвимостей
0:30
мы с вами как потребители в реальности
0:32
хотим чтобы мы не правили уязвимости
0:34
постфактум А их сразу не писали
0:36
программисты и не делали ошибок
0:38
администраторы Как выглядит сейчас
0:41
появление программного продукта
0:42
разработчики пишут Исходный код и
0:44
размещают репозиторий код проверяется
0:47
автотесто затем код компилируется и
0:49
размещается в тестовой среде в тестовой
0:51
среде он запускается и проходит проверки
0:54
И если всё хорошо то его отдают
0:56
заказчикам и затем код снова
0:58
дорабатывает и так по циклу который
1:00
называют Continuous integration и
1:02
Continuous Delivery или сокращённо CCD
1:05
часть приложений мы с вами используем
1:07
лично банковские приложения социальные
1:09
сети маркетплейсы заказываем такси и
1:13
берём на прокат самокаты и в этих
1:14
приложениях как клиентской части на
1:16
смартфонах так и в части расположенной у
1:18
поставщика сервиса часто находят
1:21
уязвимости как с этими уязвимостями
DevSecOps позволяет контролировать уязвимости в коде
1:23
бороться часто на конференциях приводят
1:25
примеры кода который выложен на
1:27
публичный репозитории вместе с логинами
1:29
и паролями для дост
1:30
а ведь они должны быть секретом и уже
1:32
этот пример показывает что должен быть
1:34
кто-то кто хотя бы такие простые ошибки
1:37
программистов может контролировать
1:39
например известна история что
1:40
программист uber выложил на github
1:42
вместе с исходным кодом логин ий пароль
1:45
Его пароль Подошёл к другим системам
1:46
uber и у них много что угнали Что такое
1:50
devs и как он помогает разработчикам
1:52
devs выделяется в отдельную концепцию
1:55
потому что для разработчика безопасность
1:57
чаще всего открове очень мистов кто
2:00
столкнулся с реальными взломами и ещё
2:02
меньше тех кто как-то от этого пострадал
2:05
Ну то есть когда у компании штраф 60.000
2:07
руб за утечки то Это слабо мотивирует
2:08
кого-то вообще задумываться о
2:10
безопасности что реально кто-то будет
2:12
мне в поле ввода кавычки вставлять Да
2:14
ладно и вторая вещь безопасность до сих
Shift left заставляет исправлять уязвимости при написании кода
2:17
пор была наложенной Windows увези мости
2:20
Окей поставим сверху защиту на сайте с
2:23
WordPress постоянной уязвимости Окей
2:25
поставлю перед сайтом защиту А сейчас
2:28
дошло что проще всего защи уже сделать в
2:30
самом продукте компании серьёзно
2:32
вкладываются В безопасность разработки
2:34
если разрисовать слева направо процесс
2:36
разработки где слева начало а справа
2:39
готовый продукт то перемещение фокуса на
2:42
Начало этой картинки называют
2:43
по-английски Shift L и это термин вы
2:46
будете часто слышать он означает что
2:49
ваша компания разработчиков Молодец
2:51
правильной компании в принципе уже есть
2:53
тесто функциональности и поиска багов и
2:56
по сути нам можно добавить тест
2:58
уязвимости е и в это процес а Shift Left
3:01
смотрит ещё дальше на тот момент когда
3:04
сама уязвимость создаётся
3:07
программистом раньше приложения были
3:09
монолитные А сегодня они состоят обычно
3:12
из нескольких микросервисов Ну то есть
3:14
из набора приложений или контейнеров
3:16
которые обычно друг с другом
3:18
обмениваются данными сегодня во многих
3:20
компаниях используется кубернетес и
3:22
располагаются приложения в облаках В
3:24
итоге у хакеров всё больше точек для
3:26
атаки что меняется при переносе фокуса
3:29
на момент программирования сегодня в
3:31
каждой компании внедряется культура где
3:33
каждый программист понимает что
3:34
Безопасность – это его обязанность для
3:37
этого будете проводить обучение и
3:39
проводить долгие беседы традиционно
3:41
разработчики фокусируются на
3:42
функциональности и производительности
3:44
вопросы безопасности на себя раньше
3:46
брали специализированные команды и в
3:48
итоге продукты всё равно выходили с
3:50
уязвимостями и решением этой проблемы
3:52
является Осознание программистами своей
3:54
ответственности за выпуск качественного
3:56
кода это сложно воспитание идей
Культура организации меняет культуру разработки
3:59
безопасно у разработчика ещё
4:00
экономически выгодно потому что
4:02
исправление уязвимости на самом раннем
4:04
этапе снижает затраты на это исправление
4:06
и также ускоряет процесс разработки
4:08
изменение культуры разработчика не
4:10
происходит мгновенно это требует времени
4:12
терпения постоянных усилий со стороны
4:14
всей организации Однако преимущество
4:16
которое это изменение может принести
4:19
стоит того кому безопасный код интересен
Кому безопасный код интересен
4:22
в первую очередь в команде есть
4:23
специалисты по безопасности которые
4:25
проводят аудиты кода идентифицируют
4:27
уязвимости и показывают способы их
4:28
устранения и вопс инженерам интересно
4:31
Чтобы внедряемые ми код был без
4:32
уязвимостей потому что вся их
4:33
инфраструктура более стабильна
4:35
разработчики которым интересен карьерный
4:37
рост будут проявлять инициативу по
4:39
изучению и применению Практик
4:40
безопасного написания кода часто среди
4:42
программистов выделяют роль Security
4:44
Champion Это парни которые берут на себя
4:46
часть функций по проверке безопасности
4:48
кода сегодня появились ещё и требования
4:50
регуляторов по внедрению Практик
4:51
безопасного написания кода и в вашей
4:53
команде в этом случае появляются
4:55
ответственные за соблюдение этих
4:56
требований в идеале каждый член команды
4:59
должен иметь основные знания по
5:01
безопасности исходного кода в своей
OWASP – обучение, лучшие практики и инструменты AppSec
5:03
работе Вы можете обращаться к наработка
5:05
avas Open Web Application Security
5:07
Project – это международная
5:09
некоммерческая организация нацеленная на
5:11
улучшение безопасности программного
5:13
обеспечения Авас работает над
5:15
разработкой и распространением
5:16
бесплатных и открытых инструментов
5:18
документации стандартов и методик в
5:20
области безопасности веб-приложений aasp
5:22
предоставляет проверенные временем
5:24
методики и лучшие практики для
5:25
разработки тестирования и обслуживания
5:27
безопасных веб-приложений Вы можете
5:29
использовать образовательные материалы и
5:31
программы для повышения уровня знаний и
5:33
навыков вашей команды по вопросам
5:35
безопасности один из самых известных
5:37
проектов aasp – Это топ 10 уязвимости
5:39
веб-приложений или aasp Top 10 который
5:42
регулярно обновляется этот список
5:44
представляет собой обобщение наиболее
5:46
критических уязвимостей безопасности
5:47
веб-приложений оно основано на данных от
5:50
организаций и экспертов по безопасности
5:52
по всему миру а vasp Top 10 служит
5:54
отличным ориентиром для руководителей по
5:56
безопасности при планировании стратегии
5:58
защиты и веб-приложений используя
6:00
ресурсы avas Вы можете лучше понять
6:02
текущие угрозы и определить на что ваша
6:05
организация должна сосредоточить свои
6:07
усилия в области безопасности А что
Virtual Patch защищает от существующих уязвимостей
6:09
делать если мы знаем что в приложени
6:11
есть уязвимость а нам надо его срочно
6:14
запускать продуктив Часто мы вынуждены
6:16
запускать приложение в котором есть
6:17
уязвимости бизнесу важнее работать на
6:20
уязвимом чем не работать Совсем в этом
6:22
случае безопасники включают наложенные
6:24
средства обычно используется intrusion
6:26
prevention System или Application
6:28
Firewall это компоненты защиты в которых
6:31
заложены знания о том как будет
6:32
атаковать хакер в момент атаки хакер
6:34
создаёт какой-то поток трафика эти
6:36
устройства этот поток трафика видит и
6:38
блокирует хакеру даже кажется что узмо
6:40
сито и нет поэтому такой подход к защите
6:43
часто называют Virtual Patch потому что
6:45
реально код не обновлён мы ещё ждём патч
6:48
от программистов я вас ещё не загрузил
Все подходы к AppSec
6:50
чтобы сделать код более безопасным
6:52
применяются Различные подходы проверки
6:54
кода перед выкладкой в репозиторий
6:56
Source composition analysis Static
6:58
Application Security Test
7:00
App sec sec кода и управление секретами
7:05
это будет один поставщик или несколько и
7:08
цель каждого этого подхода помочь
7:10
выявить уязвимость как можно раньше в
7:12
цикле разработки са – это метод анализа
Что делает SAST
7:15
исходного кода байт кода или бинарного
7:17
кода приложений на предмет уязвимости
7:19
безопасности без запуска приложения са
7:22
используется для раннего обнаружения
7:23
усти в коде что позволяет разработчикам
7:26
исправлять их на ранних стадиях
7:28
разработки програмного
7:30
статический анализатор часто
7:31
встраивается прямо вде и показывает
7:33
программисту сразу что он написал
7:35
уязвимость также они могут встраиваться
7:37
в процесс компиляции кода и выдавать
7:39
точки с возможными уязвимостями
7:40
статическим анализаторам сложнее всего с
7:43
языком c c+ plus и ассемблера и проще с
7:46
Java Go и другими скриптовые языками
7:49
инструменты sast могут генерировать
7:51
ложные положительные результаты требуя
7:53
от команды разработчиков дополнительных
7:54
усилий на проверку и анализ результатов
7:57
поэтому сас рекомендуется использовать
7:59
вместе с другими методиками проверки
8:01
безопасности кода Ну то есть са может
8:03
найти 23.000 уязвимостей и вам что-то с
8:07
этим надо делать Итак Dust это метод
Что делает DAST
8:11
тестирования безопасности приложений
8:12
который осуществляется во время
8:14
выполнения приложения с внешней точки
8:16
зрения этот метод позволяет обнаруживать
8:18
уя змо и проблем безопасности в реальном
8:21
времени когда приложение запущено и
8:22
работает динамический анализатор кода
8:24
пытается подавать различные входные
8:26
параметры например SQL команды и
8:28
заполняет по разм по вода и смотрит Что
8:31
происходит с самим приложением поскольку
8:33
Dust выполняет тестирование с точки
8:34
зрения потенциального атакующего оно
8:36
может эффективно выявлять уязвимости
8:38
которые могут быть
8:40
эксплуатировали тестируется приложение
8:42
Прямо во время работы поэтому может
8:44
обнаруживать уязвимости и проблемы
8:46
конфигурации которые проявляются только
8:48
во время выполнения Dust может
8:50
использоваться для тестирования
8:51
веб-приложений независимо от языка
8:53
программирования и технологии на которых
8:54
они построены результат Dust можно
8:56
использовать для включения Virtual Patch
8:58
например на Web Application Firewall
9:01
динамический анализатор очень гармонично
9:03
всегда используется со статическим
9:05
анализатором чтобы приоритизировать
9:06
уязвимости и исправлять сначала те
9:09
которые реально можно эксплуатировать
9:11
иаст – это современный метод
Что делает IAST
9:13
тестирования безопасности который
9:14
сочетает в себе элементы статического и
9:17
динамического анализа безопасности
9:19
приложений яст предназначен для работы в
9:20
режиме реального времени обеспечивая
9:22
анализ приложения изнутри во время их
9:24
исполнения этот подход позволяет
9:26
обнаруживать и диагностировать
9:27
уязвимости на более глубоком уровне чем
9:29
Dust и при этом быть более релевантным
9:32
контексту выполнения чем sast iast
9:34
особенно полезен в Ile и devops средах
9:36
где важна скорость и автоматизация
9:38
процессов разработки существует ещё
Что делает RASP
9:40
подход runtime Application Security
9:42
protection rasp Он позволяет обернуть
9:44
опасные куски кода специальными
9:46
проверками безопасности то есть не Ваш
9:48
программист эти проверки пишет что в
9:50
общем всего со страны было бы неплохо А
9:52
специальна утилита ASP интегрируется с
9:54
приложением или средой выполнения и
9:57
может обеспечивать непрерывную защиту
9:58
приложения угроз раз представляет собой
10:01
мощный инструмент для защиты приложений
10:03
он обеспечивает защиту приложений в
10:04
реальном времени от угроз и Атак не
10:05
требуя вмешательства со стороны
10:07
пользователя или администратора
10:09
благодаря тесной интеграции с
10:10
приложением ра может точно
10:12
идентифицировать и блокировать атаки
10:14
минимизируя ложное срабатывание раз
10:17
может предотвратить эксплуатацию даже
10:18
тех уязвимостей которые не были заранее
10:21
исправлены в коде приложения важно
10:23
отметить что несмотря на свои
10:24
преимущества ни один из методов
10:26
тестирования безопасности не может
10:28
гарантировать 100 процентную защиту от
10:30
всех видов уязвимостей лучшей практикой
10:33
является использование нескольких
10:35
инструментов и подходов в сочетании для
10:37
достижения максимальной безопасности
10:40
приложений А как убедиться в
Безопасность сторонних библиотек
10:42
безопасности сторонних библиотек это
10:44
реально сложный и важный вопрос в
10:46
компании нужно реализовать Software
10:48
composition analysis sca процесс
10:50
автоматизированного тестирования
10:52
используемые для идентификации
10:54
уязвимости и безопасности в компонентах
10:55
третьих сторон таких как открытые
10:57
исходные коды библиотеки зависимости
11:00
интегрированные в программное
11:01
обеспечение и инструменты сканируют код
11:03
программного обеспечения для создания
11:05
инвентарного списка всех компонентов
11:07
открытого исходного кода и их
11:08
зависимостей Затем они сопоставляют эти
11:11
компоненты с базами данных известных
11:17
уязвимостей источники для выявления
11:19
потенциальных уязвимостей также
11:21
проводится анализ лицензий для выявления
11:23
возможных юридических и соответствующих
11:25
рисков Убедитесь что вы используете
11:28
библиотеке из надж источников таких как
11:30
официальные репозитории или сайт
11:32
разработчиков избегайте сомнительных
11:34
источников если возможно Проведите
11:36
ручной аудит исходного кода библиотеки
11:38
чтобы выявить потенциальные уязвимости
11:40
особенно если библиотека будет
11:41
использоваться в критически важных или
11:44
высоконагруженных частях вашего
11:45
приложения Рассмотрите возможность
11:47
использования библиотеки в изолированной
11:49
среде или сандбокс чтобы минимизировать
11:51
риски для остальной части системы
11:53
проверьте насколько регулярно библиотека
11:55
обновляется и поддерживается
11:57
разработчиками отсутствие регулярных
11:59
Лени может указывать на то что
12:00
уязвимости не устраняются своевременно
12:03
Используйте инструменты для анализа
12:04
уязвимости чтобы понять какие другие
12:06
библиотеки и версии требуются для работы
12:08
в выбранной библиотеки Убедитесь что эти
12:11
зависимости также безопасны и актуальны
12:13
полностью исключить все риски при
12:15
использовании сторонних библиотек
12:16
невозможно но следуя вышеописанным шагам
12:19
можно значительно снизить потенциальные
12:21
угрозы безопасности важно сегодня
Безопасность инфраструктуры SIAC
12:24
упомянуть Security infrastructure S
12:28
подход к управлению инфраструктуры
12:30
безопасности через код аналогичной
12:32
практики infrastructure S Code в области
12:35
управления it инфраструктурой этот
12:38
подход позволяет организациям определять
12:40
и реализовывать меры безопасности в виде
12:42
кода который может быть версионирование
12:51
и обновления безопасной инфраструктуры
12:54
для реализации cac используются
12:56
различные инструменты и технологии такие
12:58
как форм enb chef Pet автоматизация
13:02
позволяет быстро развёртывать и
13:03
масштабировать инфраструктуру
13:05
безопасности в соответствующее с
13:07
изменяющимися требованиями и условиями
13:09
Используйте скрипты и инструменты
13:12
автоматизации для развёртывания и
13:14
настроек мер безопасности таких
13:16
продуктов как межсетевые экраны система
13:18
обнаружения и предотвращения вторжений
13:20
политик доступа и так далее способность
13:23
скриптов и конфигурации безопасности
13:25
приводить инфраструктуру в желаемое
13:26
состояние при каждом выполнении
13:29
независимо от текущего состояния системы
13:31
является важной для вас поэтому обратите
13:33
внимание на Security infrastructure As A
13:36
Cold у вас наверняка возникает вопрос с
Начните с методологии BSIMM
13:39
чего же начать А Начать нужно с
13:41
организации процессов провести аудит
13:43
ситуации выбрать какие процессы
13:45
необходимо внедрить Какие изменить а
13:47
какие остановить В общем оценить
13:49
зрелость текущих процессов безопасной
13:51
разработки и обозначить дальнейшие шаги
13:54
в светлое будущее Application Security и
13:57
всей компании и тут на помощь нам
13:59
приходят фреймворки по безопасной
14:01
разработке Существует множество
14:03
методологий для оценки зрелости компании
14:05
в части осек например aasp Sam deson
14:08
openam Microsoft sdl и bsim Я рекомендую
14:12
ознакомиться с Building Security and
14:14
maturity Model bsim это методология
14:17
оценки процессов безопасной разработки
14:18
программного обеспечения в организации
14:21
благодаря данной методике можно
14:22
определить На какой стадии находятся
14:24
текущие процессы и какая отправная точка
14:26
к повышению уровня зрелости есть в вашей
14:29
организации Какая экспертиза у
14:31
сотрудников и какие подходы к разработке
14:34
чтобы дать вам время на повторение
14:35
изучение этой информации прощаюсь с вами
14:38
и желаю безопасного будущего С вами был
14:41
Денис транков эксперт по информационной
14:43
безопасности компании Позитив
14:45
Technologies Всего доброго До новых
14:47
встреч
14:50
[музыка]

Поделиться: