Политика разработки безопасного программного обеспечения
Внедрение мер по разработке безопасного программного обеспечения (ПО) на всех этапах жизненного цикла (SDLC ─ Secure Software Development Lifecycle) является обязательным условием конкурентоспособности на рынке для компаний, занимающихся разработкой ПО. Наша компания внедрила в свой процесс разработки лучшие практики по организации процесса разработки безопасного ПО с целью предоставления более надежной и безопасной продукции нашим заказчикам. В частности, Infotecs SDLC (ISDL) учитывает требования регламентов ФСТЭК России, национального стандарта ГОСТ Р 56939-2016, международных стандартов серии ISO/IEC 27000, материалы OWASP, а также рекомендации NIST (например, NIST SP 800-64, SP 800-100).
ISDL ─ это комплексный процесс, затрагивающий всю организацию и включающий следующее:
Без эффективной программы обучения внедрить ISDL было бы невозможно. Мы разработали ряд корпоративных обучающих курсов, призванных восполнить недостающие знания в области защиты информации, обеспечить необходимую поддержку и повышение профессиональной квалификации сотрудников с учетом их обязанностей и зон ответственности в рамках ISDL. Помимо теоретических знаний по безопасности, наши обучающие курсы включают набор практических упражнений, которые так необходимы для технических специалистов.
Определение требований к продукту сводится к поиску компромисса между бизнес-потребностями заказчика и уровнем безопасности, необходимым для защиты его активов. Такого компромисса можно достичь только путем сбора и тщательного анализа требований рынка, соответствующих нормативно-правовых актов, а также стандартов и лучших практик.
Требования рынка
Сбор требований рынка включает выявление проблемы заказчика, которая может быть решена с помощью продукта или сервиса. На данном этапе важно прояснить множество деталей, например, тип защищаемых данных, необходимую функциональность продукта, возможные ограничения, связанные со средой функционирования продукта и так далее.
Нормативно-правовые акты
Учет всех действующих нормативно-правовых актов на раннем этапе способствует снижению расходов, рисков несоответствия, а также времени выпуска продукта на рынок в целом.
Стандарты и лучшие практики
Несмотря на то, что законодательство зачастую не требует явного соблюдения каких-либо стандартов и лучших практик, их применение остается важным условием обеспечения конкурентоспособности продуктов и компании в целом.
На данном этапе мы тщательно анализируем собранные требования с тем, чтобы определить, каким образом реализовать эти требования в продукте, а также определяем наиболее надежный и безопасный способ их реализации. Если мы планируем использовать программное обеспечение сторонних производителей, мы тщательно его проверяем, а также проводим анализ поверхности атак (в том числе, разрабатываем модель нарушителя) и разрабатываем модель угроз.
Анализ сторонних компонентов
При коммерческом использовании стороннего программного обеспечения мы обязуем партнеров в кратчайшие сроки уведомлять нас о выявленных уязвимостях для принятия необходимых мер по предотвращению их эксплуатации. Кроме того, мы автоматически отслеживаем информацию об уязвимостях, обнаруженных в программном обеспечении с открытым исходным кодом (если такое ПО используется в наших продуктах или мы планируем использовать его в будущем), чтобы своевременно вносить необходимые изменения.
Анализ поверхности атак
Цель такого анализа ─ выявить, к каким компонентам или функциям злоумышленник имеет доступ и, соответственно, может их использовать, и свести количество таких компонентов и функций к минимуму.
Разработка модели угроз
Разработка модели угроз ─ один из наиболее важных этапов разработки продукта с учетом безопасности. Мы разрабатываем модель угроз с учетом результатов, полученных на предыдущем шаге. Затем мы используем ее для определения необходимого уровня безопасности и последующего выбора соответствующих мер защиты, которые должны быть реализованы в продукте.
Безопасное программирование прежде всего направлено на предотвращение появления ошибок в коде на этапе разработки, что может быть достигнуто посредством:
- Внедрения строгого стандарта безопасного программирования и контролем его соблюдения посредством анализа кода;
- Внедрением современных инструментов автоматизации (статических анализаторов, компиляторов, систем контроля версий и т.д.) в среду разработки ПО.
Стандарт безопасного программирования
Мы разработали корпоративный стандарт безопасного программирования, внедрили его в наш процесс разработки ПО. Данный стандарт учитывается в программе обучения сотрудников и является обязательным для технических специалистов, участвующих в процессе разработки безопасного ПО.
Анализ кода
Анализ безопасности кода, выполненный экспертами по безопасности, и ревью кода позволяют устранять ошибки на самых ранних этапах разработки ПО. Эти методы достаточно эффективны для обнаружения как случайных, так и преднамеренных логических ошибок в коде.
Средства автоматизации
Процесс разработки ПО предполагает использование автоматизированных средств (компиляторов, систем контроля версий, анализаторов кода и т.д.), которые должны быть настроены надлежащим образом. Чтобы оставаться эффективными, эти инструменты должны своевременно обновляться, поэтому мы стараемся поддерживать актуальность версий средств автоматизации, используемых в нашей среде разработки.
Целью данного этапа является проверка того, что продукт отвечает требованиям спецификации и обеспечивает необходимый уровень безопасности. Для функциональной оценки продукта целесообразно проводить интеграционное, регрессионное и модульное тестирование. Одновременно, тестирование мер защиты, сканирование на наличие уязвимостей и тестирование на проникновение, представляют собой важную часть тестирования безопасности, выполняемого на этапе проверки.
Тестирование мер защиты
На данном этапе выполняется тестирование мер защиты, в рамках которого проверяется, что они разработаны надлежащим образом и действительно обеспечивают необходимый уровень безопасности.
Сканирование на наличие уязвимостей
Регулярное автоматизированное сканирование на уязвимости позволяет выявить и устранить уязвимости до выпуска продукта. На данном этапе также рекомендуется выполнить фаззинг тестирование, чтобы проверить, что программа корректно отвечает, как на ожидаемые, так и на случайные входные значения, - это позволяет идентифицировать ошибки переполнения буфера, проверки входных параметров и проблемы безопасности.
Тестирование на проникновение
Тестирование на проникновение, выполняемое экспертами по безопасности, позволяет эффективно выявлять сложные уязвимости и, следовательно, хорошо дополняет сканирование с помощью автоматизированных средств.
Выпуск продукта на рынок осуществляется только после успешного проведения финальной проверки безопасности (FSR – Final Security Review), выполненной командой разработки и экспертами по безопасности. Кроме того, мы разработали план реагирования на инциденты для устранения возможных проблем безопасности в наших продуктах. Мы также оказываем услуги технической поддержки (ссылка) и своевременно предоставляем заказчикам всю необходимую информацию о планируемых изменениях в продукте.
Финальная проверка безопасности / Сертификация
Основная цель финальной проверки безопасности – оценка готовности продукта и принятие решения о том, будет ли он выпущен на рынок. Такая проверка включает оценку безопасности продукта, а также, когда это необходимо, его сертификацию.
План реагирования на инциденты
Ни одна компания не хочет разрабатывать уязвимое программное обеспечение. Тем не менее, в процессе разработки невозможно полностью избавиться от ошибок, как и невозможно предотвратить появление новых уязвимостей. Поэтому наличие заблаговременно подготовленного плана реагирования на инциденты может существенно сэкономить время и деньги.
Управление конфигурацией и изменениями
Практически любой готовый продукт требует настройки для последующей работы в производственной среде. При этом, чтобы он продолжал обеспечивать необходимый уровень безопасности в процессе эксплуатации, состояние продукта нужно отслеживать, а также его необходимо своевременно обновлять (например, в связи с выпуском новой версии, необходимостью исправления ошибок и / или устранения обнаруженных уязвимостей).
Когда наступает время вывода продукта из эксплуатации (например, в виду его устаревания, необходимости обновления или по любым другим причинам), нельзя забывать о том, что защищаемая информация все еще должна оставаться защищенной. Для этого нужно заранее спланировать и разработать процесс вывода продукта из эксплуатации, принимая во внимание меры защиты, которые должны применяться для обеспечения безопасности при организации последующего хранения информации, удалении данных и аппаратного и программного обеспечения в целом.
Сохранение информации
Сохранение ценной информации подразумевает не только обеспечение доступности такой информации (например, когда это требуется по закону), но и обеспечение ее защиты в процессе и, если необходимо, после вывода продукта из эксплуатации.
Удаление данных
Для предотвращения разглашения защищаемой информации, необходимо уделять особое внимание методам и оборудованию, которые используются при удалении данных с носителя. Выбор соответствующих методов удаления защищаемой информации (путем перезаписи, размагничивания или уничтожения) должен осуществляться с учетом необходимого уровня безопасности.
Удаление аппаратного и программного обеспечения
Физическое уничтожение аппаратного обеспечения может потребоваться только в том случае, если защищаемую информацию невозможно удалить с помощью других средств.
В то же время настоятельно рекомендуется удалять устаревшее программное обеспечение, поскольку в противном случае его последующее использование может привести к возникновению новых рисков.