Войти в систему
Войти с помощью соц. сетей:
После внимательного изучения видов инструментов проверки безопасности можно сделать вывод, что они делятся на DAST или SAST.
DAST означает динамическое (dinamic) тестирование безопасности приложений – взаимодействие с приложением в процессе его работы.
SAST означает статическое (static) тестирование безопасности приложений – изучение кода в том виде, в котором он написан или скомпилирован.
Как правило, инженеры по безопасности и программисты обнаруживают уязвимости в стороннем коде с помощью инструмента анализа состава программного обеспечения (SCA), который исследует библиотеки, платформы и зависимости на предмет того, входят ли они в заранее составленный список «известного уязвимого» ПО. Такой анализ считается статическим, поскольку инструмент SCA исследует библиотеки, вызываемые из написанного кода (в частности, из файла дескриптора проекта).
Инструменты SAST находят уязвимости в пользовательском коде, то есть в коде, написанном командой компании. SCA обнаруживает известные уязвимости во всем коде приложения, который был написан другими людьми (библиотеки, пакеты, платформы и т. д.). Такие части кода, как правило, называются «сторонние библиотеки». Найти уязвимости во всем приложении можно, только выполнив обе проверки.
Мы рассматриваем SCA или обнаружение уязвимостей в стороннем коде с точки зрения потребителя – программиста или инженера по безопасности, – поэтому нередко будем условно объединять его с остальной частью SAST – статическим тестированием безопасности приложений.
Инструменты DAST тестируют все приложение: и написанные командой компании, и сторонние части, поскольку они работают как единое целое.
Когда дело доходит до поиска ошибок, необходимо также провести ручной анализ. По части обнаружения уязвимостей опытный тестировщик или обзорщик кода превосходит любой инструмент. Часто при автоматизированном тестировании пропускаются недостатки бизнес-логики, которые могут причинить компании довольно много вреда. Следовательно, необходимо выделить в графике проекта достаточно времени и нанять квалифицированных специалистов по безопасности, чтобы обеспечить обнаружение максимального количества уязвимостей.
Вернемся к цели: техническая возможность находить уязвимости в написанном, выполняемом и стороннем коде. Если выявлять недостатки тремя различными способами, а не только одним, то получится более полная картина состояния безопасности приложений. Нередко компании полагаются только на один из этих трех столпов, что может быть следствием бюджетных ограничений, недостаточного количества сотрудников или отсутствия поддержки со стороны руководства. В таком случае следует выбрать тот метод, который обеспечивает наилучшую окупаемость инвестиций и вписывается в текущие процессы.
Если у вас когда-нибудь будет возможность пообщаться с опытным тестировщиком на проникновение, он в конце концов признается вам, что самое неприятное в его работе – это вернуться в приложение через год и найти точно такие же уязвимости в тех же системах. Год за годом ничего не исправляется. Компания нанимает тестировщика, чтобы просто поставить галочку о выполнении требования регламента (обычно PCI), совершенно не заботясь о реальном повышении безопасности приложения.
Нет смысла усердно работать над поиском уязвимостей, если их в дальнейшем не устранят. Необходимо позаботиться о наличии в компании людей, обладающих достаточным количеством времени, навыков и знаний для исправления обнаруженных проблем. Если у человека много времени, но нет опыта программирования, ему потребуется немало методической помощи и ресурсов. У высококвалифицированных и обученных людей, которые перегружены работой и уже близки к выгоранию, также не будет времени на устранение уязвимостей.
ПРИМЕЧАНИЕ. Компании добавляют дополнительные проверки безопасности в жизненный цикл разработки системы, исходя из самых лучших намерений, однако они не осознают, насколько тем самым могут увеличить объем работы. Очень важно, чтобы в графике проекта было выделено время на устранение проблем, а также чтобы сотрудники имели соответствующую подготовку для выполнения этой задачи.
Когда речь заходит о безопасности, необходимо иметь в виду, что разработчики программного обеспечения нуждаются в поддержке, так как обучение, получаемое на курсах программирования, в колледжах и университетах, часто не полностью соответствует требуемым знаниям и умениям. Необходимо обучить сотрудников имеющимся в компании стандартам, политикам или рекомендациям, чтобы они смогли создавать код, который отвечает всем требованиям.
Обучение может проводиться в виде семинара, обмена мнениями в обеденное время, онлайн- и офлайн-курсов, пятиминутного выступления на общем собрании персонала, занятий с приглашеным инструктором и т. д. Суть в том, что, если вам нужно, чтобы разработчики знали об определенном элементе управления безопасностью, способе защиты или методе кодирования, нужно помочь им эти знания приобрести. В противном случае одни сотрудники будут обладать всей необходимой информацией, а другие – нет, что обернется увеличением количества уязвимостей, связанных с обеспечением безопасности разрабатываемых продуктов.
Например, обеспечением справочными материалами может быть покупка книги по безопасности Java, если разработчики в основном используют этот язык в своей работе. Также разработчикам могут быть полезны подписки на видео, блоги, образцы безопасного кода и все то, что поможет им узнать, как сделать свою работу более безопасной.
СОВЕТ. Я создала академию и сообщество We Hack Purple (WeHackPurple.com) – организацию, которая занимается обучением безопасности приложений, безопасному кодированию, безопасности облачных вычислений и многому другому. Если вам нравится эта книга, возможно, вы захотите заглянуть к нам?
Войти с помощью соц. сетей: