 | Эта статья поднимает множество проблем. Пожалуйста, помогите улучшить его или обсудите эти проблемы на странице обсуждения . ( Узнайте, как и когда удалить эти сообщения-шаблоны ) ( Узнайте, как и когда удалить этот шаблон сообщения )
|
| Часть серии по |
| Информационной безопасности |
|---|
| Связанные категории безопасности |
| Угрозы |
|
| Защиты |
|
Гарантия безопасности программного обеспечения - это процесс, который помогает разрабатывать и внедрять программное обеспечение, которое защищает данные и ресурсы, содержащиеся в этом программном обеспечении и контролируемые им. Программное обеспечение само по себе является ресурсом и, следовательно, должно иметь соответствующую безопасность .
Поскольку количество угроз, направленных конкретно на программное обеспечение, увеличивается, необходимо обеспечить безопасность нашего программного обеспечения, которое мы производим или закупаем. «Зависимость от информационных технологий делает обеспечение безопасности программного обеспечения ключевым элементом обеспечения непрерывности бизнеса, национальной и национальной безопасности». [1]
Что такое гарантия безопасности программного обеспечения? [ редактировать ]
Software Security Assurance (SSA) - это процесс обеспечения того, чтобы программное обеспечение было разработано для работы на уровне безопасности, который соответствует потенциальному ущербу, который может возникнуть в результате потери, неточности, изменения, недоступности или неправильного использования данных и ресурсов, которые он использует, контролирует и защищает.
Процесс обеспечения безопасности программного обеспечения начинается с идентификации и категоризации информации, которая должна содержаться в программном обеспечении или использоваться им. Информация должна быть классифицирована в соответствии с ее конфиденциальностью . Например, в самой низкой категории влияние нарушения безопасности минимально (т. Е. Влияние на миссию, функции или репутацию владельца программного обеспечения незначительно). Однако для высшей категории удар может представлять угрозу для жизни человека; может иметь непоправимое влияние на миссии, функции, имидж или репутацию владельца программного обеспечения; или может привести к потере значительных активов или ресурсов.
После того, как информация классифицирована, можно разработать требования безопасности. Требования безопасности должны касаться управления доступом , включая доступ к сети и физический доступ; управление данными и доступ к данным; экологический контроль (электричество, кондиционирование воздуха и т. д.) и автономное хранение ; безопасность человеческих ресурсов; а также журналы аудита и записи об использовании.
Что вызывает проблемы с безопасностью программного обеспечения? [ редактировать ]
Все уязвимости безопасности в программном обеспечении являются результатом ошибок или дефектов безопасности в самом программном обеспечении. В большинстве случаев эти дефекты возникают по двум основным причинам: (1) несоответствие или невыполнение требований; и (2) ошибка или упущение в требованиях к программному обеспечению.
Несоответствие или невыполнение требований [ править ]
Несоответствие может быть простым - наиболее распространенным является ошибка кодирования или дефект - или более сложным (например, незначительная ошибка синхронизации или ошибка проверки ввода). Важным моментом в отношении несоответствий является то, что методы проверки и валидации предназначены для их обнаружения, а методы обеспечения безопасности предназначены для их предотвращения. Усовершенствования этих методов с помощью программы обеспечения безопасности программного обеспечения могут повысить безопасность программного обеспечения.
Ошибки или упущения в требованиях к программному обеспечению [ править ]
Наиболее серьезные проблемы безопасности с программными системами - это те, которые возникают, когда требования к программному обеспечению неверны, не соответствуют или неполны для системной ситуации. К сожалению, ошибки или упущения в требованиях выявить труднее. Например, программное обеспечение может работать точно так, как требуется, при нормальном использовании, но требования могут некорректно относиться к определенному состоянию системы . Когда система переходит в это состояние проблемы, это может привести к неожиданному и нежелательному поведению. Проблемы этого типа не могут быть решены в рамках дисциплины программного обеспечения; это происходит из-за сбоя в процессах системной и программной инженерии, которые разработали и распределили системные требования к программному обеспечению.
Деятельность по обеспечению безопасности программного обеспечения [ править ]
Существует два основных типа действий в рамках программы Software Security Assurance.
- Некоторые сосредотачиваются на обеспечении того, чтобы информации, обрабатываемой информационной системой, была присвоена надлежащая категория чувствительности, и чтобы соответствующие требования защиты были разработаны и соблюдались в системе.
- Другие сосредоточены на обеспечении контроля и защиты программного обеспечения, а также инструментов и данных поддержки программного обеспечения.
Как минимум, программа обеспечения безопасности программного обеспечения должна гарантировать, что:
- Для программного обеспечения была проведена оценка безопасности.
- Для программного обеспечения установлены требования безопасности.
- Требования безопасности установлены для процессов разработки и / или эксплуатации и сопровождения программного обеспечения (O&M).
- Каждая проверка или аудит программного обеспечения включает оценку требований безопасности.
- Имеется процесс управления конфигурацией и корректирующих действий, чтобы обеспечить безопасность существующего программного обеспечения и гарантировать, что любые предлагаемые изменения не приведут к непреднамеренным нарушениям безопасности или уязвимостям .
- Физическая безопасность программного обеспечения достаточна.
Строительство в безопасности [ править ]
Улучшение процесса разработки программного обеспечения и создание более качественного программного обеспечения - это способы повышения безопасности программного обеспечения за счет создания программного обеспечения с меньшим количеством дефектов и уязвимостей. Подход первого порядка состоит в том, чтобы идентифицировать критически важные программные компоненты, которые контролируют функции, связанные с безопасностью, и уделять им особое внимание на протяжении всего процесса разработки и тестирования. Такой подход помогает сосредоточить ограниченные ресурсы безопасности на наиболее критических областях.
Инструменты и методы [ править ]
Существует множество готовых коммерческих программных пакетов (COTS), которые доступны для поддержки деятельности по обеспечению безопасности программного обеспечения. Однако перед использованием эти инструменты необходимо тщательно оценить и гарантировать их эффективность.
Перечисление общих недостатков [ править ]
Один из способов улучшить безопасность программного обеспечения - лучше понять наиболее распространенные слабые места, которые могут повлиять на безопасность программного обеспечения. Имея это в виду, существует текущая программа на уровне сообщества под названием «Перечень общих недостатков» [2], спонсируемая корпорацией Mitre для выявления и описания таких недостатков. Список, который в настоящее время находится в очень предварительной форме, содержит описания общих слабых мест, ошибок и недостатков программного обеспечения.
Архитектура безопасности / анализ дизайна [ править ]
Анализ архитектуры / дизайна безопасности подтверждает, что проект программного обеспечения правильно реализует требования безопасности. Вообще говоря, есть четыре основных метода, которые используются для анализа архитектуры / дизайна безопасности.[3] [4]
Логический анализ [ править ]
Логический анализ оценивает уравнения , алгоритмы и управляющую логику разработки программного обеспечения.
Анализ данных [ править ]
Анализ данных оценивает описание и предполагаемое использование каждого элемента данных, используемого при разработке программного компонента . Особое внимание следует уделять использованию прерываний и их влиянию на данные, чтобы процедуры обработки прерываний не изменяли важные данные, используемые другими процедурами.
Анализ интерфейса [ править ]
Анализ интерфейса проверяет правильность проектирования интерфейсов программного компонента с другими компонентами системы, включая компьютерное оборудование , программное обеспечение и конечных пользователей .
Анализ ограничений [ править ]
Анализ ограничений оценивает дизайн программного компонента на предмет ограничений, налагаемых требованиями и реальными ограничениями. Дизайн должен учитывать все известные или ожидаемые ограничения на программный компонент. Эти ограничения могут включать в себя ограничения по времени, размерам и пропускной способности, ограничения входных и выходных данных, ограничения по уравнениям и алгоритмам, а также другие конструктивные ограничения.
Проверки, проверки и пошаговые инструкции безопасного кода [ править ]
Анализ кода проверяет, что исходный код программного обеспечения написан правильно, реализует желаемый дизайн и не нарушает никаких требований безопасности. Вообще говоря, методы, используемые при выполнении анализа кода, отражают методы, используемые при анализе проекта.
Проверки кода безопасности проводятся во время и в конце фазы разработки, чтобы определить, были ли выполнены установленные требования безопасности, концепции проектирования безопасности и спецификации, связанные с безопасностью. Эти обзоры обычно состоят из представления материала группе обзора. Проверки безопасного кода наиболее эффективны, когда они проводятся персоналом, который не принимал непосредственного участия в разработке проверяемого программного обеспечения.
Неофициальные обзоры [ править ]
Неформальные проверки безопасного кода могут проводиться по мере необходимости. Для проведения неформальной рецензии разработчик просто выбирает одного или нескольких рецензентов и предоставляет и / или представляет материал для рецензирования. Материал может быть как псевдокодом, так и рукописной документацией.
Официальные обзоры [ править ]
Формальные проверки безопасного кода проводятся в конце фазы разработки для каждого программного компонента. Заказчик программного обеспечения назначает группу формальной проверки, которая может принять или повлиять на решение «годен / не годен», чтобы перейти к следующему этапу жизненного цикла разработки программного обеспечения .
Инспекции и пошаговые инструкции [ править ]
Проверка защищенного кода или пошаговое руководство - это подробное изучение продукта на пошаговой или построчной ( исходного кода ) основе. Целью проверки или пошагового руководства безопасного кода является поиск ошибок. Как правило, группа, которая выполняет проверку или пошаговое руководство, состоит из коллег, занимающихся разработкой, проектированием безопасности и контролем качества .
Тестирование безопасности [ править ]
Тестирование безопасности программного обеспечения , которое включает в себя тестирование на проникновение , подтверждает результаты проектирования и анализа кода, исследует поведение программного обеспечения и подтверждает, что программное обеспечение соответствует требованиям безопасности. Специальное тестирование безопасности, проводимое в соответствии с планом и процедурами тестирования безопасности, устанавливает соответствие программного обеспечения требованиям безопасности. Тестирование безопасности фокусируется на обнаружении слабых мест программного обеспечения и выявлении экстремальных или неожиданных ситуаций, которые могут привести к сбою программного обеспечения и нарушению требований безопасности. Усилия по тестированию безопасности часто ограничиваются требованиями к программному обеспечению, которые классифицируются как «критические» элементы безопасности.
См. Также [ править ]
- Безопасность благодаря дизайну
- Компьютерная безопасность
- Техника безопасности
- Защита программного обеспечения
Ссылки [ править ]
- ↑ Карен Мерседес, Теодор Виноград «Улучшение жизненного цикла разработки для создания безопасного программного обеспечения». Архивировано 30марта 2012 г.в Wayback Machine , Центр данных и анализа программного обеспечения , октябрь 2008 г.
- ^ "Проект подсчета общих недостатков" . Проверено 26 августа 2010 года .
- ^ Тестирование безопасности веб-приложений
- ^ "Каталог слабых сторон архитектуры безопасности". Международная конференция IEEE по архитектуре программного обеспечения (ICSA), 2017 г. DOI: 10.1109 / ICSAW.2017.25.
