Безопасная разработка для промышленных предприятий: вы спрашивали — мы отвечаем

Эксперт AKTIV.CONSULTING рассмотрел актуальные вопросы, связанные с отраслевой спецификой и нюансами внедрения безопасной разработки программного обеспечения (БРПО) для предприятий из сфер промышленности.

24 августа прошел вебинар «Безопасная разработка для промышленных предприятий». Если вы пропустили, запись вебинара доступна по ссылке.

До и во время вебинара участники активно задавали вопросы, которые для удобства мы собрали в отдельный материал.

1. Александр С. — Расскажите про требования к процессам безопасной разработки, необходимость и достаточность различных видов анализа кода?

Ответ: В самом минимальном объеме проверки безопасности для значимых объектов критической информационной инфраструктуры (ЗО КИИ) состоят из трех инструментальных проверок: статического и динамического анализа, а также фаззинг-тестирования. Мы также рекомендуем использовать дополнительно (либо предусмотреть в будущем) такие важные элементы, как композиционный анализ и логгирование процессов сборки ПО.

2. Алексей — С чего начать выстраивание процесса безопасной разработки?

Ответ: Это зависит от специфики проекта. Если вы из финансовой организации, то у вас, с высокой долей вероятности, высоконагруженные приложения, и, как следствие, используются заимствованные компоненты и библиотеки (open source). В данном случае можем рекомендовать внедрение следующих процессов по критериям эффективности и простоты внедрения:

1. Управление требованиями к ПО и обеспечение прослеживаемости.
2. Автоматизация модульного и регрессионного тестирования.
3. Логгирование процесса сборки приложения и его архивное хранение.
4. Тестирование на проникновение (развертывание специализированного стенда).
5. Композиционный анализ ПО.
6. Развитие практик секьюрити в команде разработки (обучение, специализированные сервисы и т. п.).

3. Павел И. — Какие есть стандарты для построения безопасной архитектуры?

Ответ: Если говорить именно о стандартах безопасной архитектуры как таковых, то рекомендуем обратить внимание на различные «вендорские» материалы и гайды. К примеру, от команды GitLab или некоммерческих объединений вроде OWASP SAMM.

Из отечественной регуляторики советуем подождать публикации проекта стандарта «Информационная технология. Методология разработки доверенных систем. Конструктивная информационная безопасность» от ТК 362. Данные стандарты разрабатывает один крупный вендор, и, возможно, там будет несколько интересных для вас архитектурных шаблонов, которые окажутся полезны при разработке ПО.

4. Андрей С. — Какие конкретные требования предъявить для безопасной разработки, обмена и ввода информации?

Ответ: Однозначно необходима проверка пользовательского ввода, а также методы «программирования с защитой», о которых я говорил на вебинаре. К ним можно отнести:

• проверку диапазона значений переменных, их достоверности (в т.ч. физический смысл);
• методы разделения параметров «только для чтения» и параметров «для чтения—записи»;
• проверку самим ПО своей конфигурации, включая наличие и доступность внешних АС и инфраструктурных сервисов.

Но тут нужно отталкиваться от вашего программного комплекса, его особенностей и специфики разработки.

5. Андрей С. — Как организовать безопасную передачу кода от команд разработки на контроллеры АСУ ТП?

Ответ: Для точного ответа на данный вопрос требуется больше конкретики. Предположим, необходимо из корпоративного сегмента от команды инженеров-программистов передать код на контроллеры в технологическом сегменте. Для этого нужно решить две основные задачи: обеспечить целостность кода и его конфиденциальность. Целостность можно обеспечить контрольными суммами или электронно-цифровой подписью, а конфиденциальность — записью файлов на зашифрованный носитель, и подключение его на инженерную рабочую станцию, с которой осуществляется прошивка контроллера. В линейке продукции нашей материнской компании есть аналогичные решения. К примеру, «Рутокен Диск», в котором доступ к содержимому осуществляется только после ввода пинкода.

6. Степан Х. — На какие метрики можно ориентироваться при проведении проверок на безопасность прикладного ПО (статический анализ, динамический анализ и т.д)? В рамках Приказа ФСТЭК № 239 не приведены объемы необходимых к выполнению испытаний.

Ответ: В техническом комитете 362 разрабатываются проекты стандартов, где как раз приведены данные параметры. На сайте ФСТЭК России раньше можно было ознакомиться с первыми редакциями этих проектов. Предлагаю дождаться выхода окончательных редакций.

7. Евгений У. — Какие есть решения для композиционного анализа?

Ответ: Среди решений по композиционному анализу есть множество как opensource-решений (к примеру, SCA OWASP Dependency-Check или Continuous SBOM Analysis Platform OWASP Dependency Track), так и коммерческих решений, в том числе и отечественных. Сами приложения выполнены как в виде консольных приложений, так и с графическим интерфейсом, визуализацией графа зависимостей и т.д. Выбор решения зависит от вашего проекта и условий.

8. Сергей Е.— Вы сказали, что микропрограммный код не анализируется. На основании чего вы так считаете?

Ответ: Немного не так выразился: ФСТЭК России не предъявляет требований к его анализу и обеспечению безопасности. Если посмотреть 239 приказ ФСТЭК РФ, то там отдельно описывается микропрограммный код и отдельно прикладное ПО. И вот к прикладному ПО в пункте 29.3 как раз предъявляются требования по проведению проверок безопасности. Там приведены инструментальные и организационные меры, а также меры поддержки жизненного цикла. Микропрограммный код, то есть прошивки на оборудование, ФСТЭК России пока проверять не будет.

9. Сергей Е. — Что такое специфические языки программирования (о которых вы упоминали)?

Ответ: К примеру, это языки стандарта МЭК 61131-3 (текстовые и графические языки, ADA, уже устаревшие стандарты некогда распространенных ЯП и т. д.).

10. Дмитрий Б. — Какие инструменты статического и динамического анализа должны применяться для языков МЭК? Приведите, пожалуйста, конкретные примеры.

Ответ: Мне известно немецкое решение CODESYS Static Analysis. Но не уверен, представлено ли оно сейчас на нашем рынке. Можете обратиться к дистрибьюторам или посмотреть информацию на сайте производителя.

11. Станислав Г. — Не услышал рекомендаций участия в публичных Bug Bounty программах, только про заказной пентестинг. Есть причины, по которым рекомендуете только пентестинг?

Ответ: Скажем так, тематика Bug Bounty имеет несколько тонких моментов, которые не до конца урегулированы с ФСБ России и ФСТЭК России. Из практики: раньше я работал на предприятиях оборонной и атомной промышленности, и там такие публичные программы не имеют повсеместного распространения. Сейчас из регуляторов активно развивает платформу Bug Bounty для ГИСов Минцифры. Также существуют различные киберполигоны как образовательные платформы, так и как состязательные элементы на некоторых мероприятиях, иногда их делают связанными именно с тематикой технологических объектов. Но я не встречал макеты реальных платформ, на которых себя выставляют условные промышленные гиганты.

12. Вера Г. — Есть ли проблема подготовки кадров по защите данных от угроз в организации?

Ответ: Вопрос не только в подготовке кадров, но и в их наличии. «Кадровый голод» — проблема достаточно острая. Многие интеграторы и вендоры активно вкладывают свои ресурсы в самостоятельную подготовку специалистов и работают со студентами старших курсов.

#Безопасная разработка