В отчете упоминались следующие пугающие факты:
• типичная организация полагалась на 7601 программный продукт (то есть источник программного обеспечения или компонент) и использовала 18 614 разных версий (то есть частей программного обеспечения);
• из этих компонентов у 7,5 % содержались известные уязвимые места, примерно 66 % были известны более двух лет, и никаких мер по их устранению предпринято не было.
Последний факт подтверждается и в исследовании Дэна Джира и Джоша Кормэна: они показали, что из всех открытых проектов с известными уязвимыми местами, зарегистрированных в Национальной базе, проблемы с защитой были устранены только у 41 % и в среднем на выпуск патча требовалось 390 дней. Для уязвимых мест с наивысшей степенью опасности (уровень 10 по шкале CVSS[164]) исправление заняло в среднем 224 дня[165].
Обеспечьте безопасность программной среды
На этом шаге мы должны сделать все возможное, чтобы наши среды были надежны и устойчивы, а связанные с ними риски — минимальны. Хотя мы уже могли создать понятные и хорошие конфигурации, нужно обязательно встроить средства мониторинга и контроля, чтобы все экземпляры в эксплуатации соответствовали этим конфигурациям.
Для этого мы создадим автоматизированные тесты, проверяющие, что у средств обеспечения устойчивости конфигураций, настроек безопасности баз данных, длин ключей и многого другого выставлены верные параметры. Кроме того, мы используем тесты для сканирования сред на известные уязвимые места[166].
Другое направление проверки безопасности — анализ того, как работают реальные среды (другими словами, «как есть», а не как «должно быть»). Примеры инструментов этого направления — Nmap, следящий за тем, что открыты только нужные порты, и Metasploit, проверяющий, что все типичные уязвимые места сред закрыты, например с помощью симуляции SQL-инъекций. Результаты применения этих инструментов должны храниться в общем репозитории и в процессе функционального тестирования сравниваться с предыдущими версиями. Это поможет быстро отследить любые нежелательные изменения.
Практический пример
Автоматизация проверок на соответствие требованиям с помощью Compliance Masonry, сделанное группой 18F для федерального правительства
В 2016 г. федеральные государственные учреждения США должны были потратить на информационные технологии 80 миллиардов долларов. Вне зависимости от учреждения, чтобы перевести систему в эксплуатацию, нужно было получить специальное разрешение на использование от соответствующего органа. Законы и требования в исполнительной власти состоят из десятков документов. В сумме они насчитывают более 4000 страниц, усеянных непонятными аббревиатурами вроде FISMA, FedRAMP и FITARA