Непрерывное сканирование

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

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

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

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

Необходимо непрерывно выполнять сканирование. Нельзя останавливать этот процесс.

Технический долг

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

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

Инвентаризация

К важнейшим мероприятиям по обеспечению безопасности можно отнести создание списка всех приложений компании, которое иногда проводится в рамках «управления портфелем приложений». Без полного и актуального реестра невозможно быстро и эффективно реагировать на инциденты или другие проблемы, так как непонятно, все ли активы компании охватывает мониторинг инструментами SAST, DAST либо IAST, а также другие мероприятия по обеспечению безопасности. По определению, неполная инвентаризация приводит к неполному покрытию средствами безопасности.

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

Реестр должен включать следующую информацию:

• название приложения или API;

• тип приложения, API, веб-приложения, SaaS-продукта и т. д.;

• URL-адрес для эксплуатации;

• URL-адрес для разработки;

• ссылку на местоположение кода;

• контактную информацию команды, ответственной за данное приложение;

• уровень чувствительности данных, используемых в приложении;

• специфику технологического стека (язык, платформа);

• местоположение приложения (облако/локально/ВМ или имя контейнера);

• все остальное, что, по вашему мнению, может быть полезной информацией.

ИНВЕНТАРИЗАЦИЯ

Боб узнал, насколько сложно выполнить инвентаризацию, во время ведения проекта по управлению портфелем приложений. Ему действительно пришлось помучиться с этим проектом, хотя ему в помощь предоставили дорогостоящего консультанта, нанятого компанией специально для этой задачи. Было проведено большое количество интервью и опросов, заполнено множество чек-листов, однако в конце Боб не мог отделаться от ощущения, что этот процесс нужно было автоматизировать. Компания заплатила консультанту целое состояние за проведение опроса всех разработчиков, результатом которого стала лишь вычурная таблица Excel. Боб думал, что в актив компании входило более 200 приложений, однако консультант объяснил ему, что нашлись доказательства существования только 72 из них.

Для Боба так и осталось загадкой, сколько же их было на самом деле…

Другие полезные привычки

Ниже перечислены еще несколько полезных привычек типичного IТ-специалиста, заботящегося о безопасности.

Политики

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