Безопасность приложений - Application security

Эта статья может потребоваться реорганизация для соответствия требованиям Википедии рекомендации по макету. Пожалуйста, помогите редактирование статьи для улучшения общей структуры. (Август 2016 г.) (Узнайте, как и когда удалить этот шаблон сообщения)

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

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

Условия

• Актив. Ценный ресурс, такой как данные в базе данных, деньги на счете, файл в файловой системе или любой системный ресурс.
• Уязвимость. Слабость или пробел в программе безопасности, которые могут быть использованы угрозами для получения несанкционированного доступа к активу.
• Атака (или использовать). Действие, предпринятое для нанесения вреда активу.
• Угроза. Все, что может использовать уязвимость и получить, повредить или уничтожить актив.

Методы

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

• Проверка безопасности Whitebox или проверка кода. Это инженер по безопасности, глубоко разбирающийся в приложении, вручную просматривая исходный код и замечая недостатки безопасности. Путем понимания приложения могут быть обнаружены уникальные уязвимости приложения.
• Аудит безопасности Blackbox. Это возможно только при использовании приложения, тестирующего его на уязвимости безопасности, исходный код не требуется.
• Обзор дизайна. Перед написанием кода проработка модель угрозы приложения. Иногда вместе со спецификацией или дизайнерским документом.
• Инструменты. Существует множество автоматизированных инструментов, которые проверяют недостатки безопасности, часто с более высоким уровнем ложных срабатываний, чем при участии человека.
• Скоординированные платформы уязвимостей. Это хакерские решения безопасности приложений, предлагаемые многими веб-сайтами и разработчиками программного обеспечения, благодаря которым люди могут получить признание и компенсацию за сообщения об ошибках.

Правильное использование этих методов на протяжении всего жизненный цикл разработки программного обеспечения (SDLC) обеспечение максимальной безопасности - это роль группы безопасности приложений.

Угрозы и атаки приложений

Согласно шаблонам и практике Повышение безопасности веб-приложений В книге представлены классы распространенных угроз и атак безопасности приложений:

В OWASP сообщество публикует список из 10 основных уязвимостей для веб-приложений и описывает передовые методы обеспечения безопасности для организаций, стремясь создать открытые стандарты для отрасли.^{[1][рекламный источник? ]} По состоянию на 2017 год организация перечисляет основные угрозы безопасности приложений следующим образом:^[2]

Безопасность мобильных приложений

Ожидается, что доля мобильных устройств, обеспечивающих функциональность открытой платформы, в будущем будет увеличиваться. Открытость этих платформ предлагает значительные возможности для всех частей мобильной экосистемы, предоставляя возможность гибкого предоставления программ и услуг = опции, которые могут быть установлены, удалены или обновлены несколько раз в соответствии с потребностями и требованиями пользователя. Однако открытость влечет за собой ответственность, и неограниченный доступ к мобильным ресурсам и API со стороны приложений неизвестного или ненадежного происхождения может привести к повреждению пользователя, устройства, сети или всего перечисленного, если не будет управляться подходящими архитектурами безопасности и сетевыми мерами предосторожности. Безопасность приложений в той или иной форме обеспечивается на большинстве мобильных устройств с открытой ОС (ОС Symbian,^[3] Microsoft,^{[нужна цитата ]} Заваривать, так далее.). В 2017 году Google расширил Программа вознаграждения за уязвимости для защиты уязвимостей, обнаруженных в приложениях, разработанных третьими сторонами и доступных через Google Play Store.^[4] Отраслевые группы также создали рекомендации, включая Ассоциация GSM и Открытая платформа мобильных терминалов (OMTP).^[5]

Существует несколько стратегий повышения безопасности мобильных приложений, в том числе:

• Белый список приложений
• Обеспечение безопасности транспортного уровня
• Надежная аутентификация и авторизация
• Шифрование данных при записи в память
• Песочница приложений
• Предоставление доступа к приложению на уровне API
• Процессы, привязанные к идентификатору пользователя
• Предопределенные взаимодействия между мобильным приложением и ОС
• Требование ввода данных пользователем для привилегированного / повышенного доступа
• Правильная обработка сеанса

Тестирование безопасности приложений

Методы тестирования безопасности ищут уязвимости или дыры в безопасности в приложениях. Эти уязвимости оставляют приложения открытыми для эксплуатация. В идеале тестирование безопасности проводится на протяжении всего жизненный цикл разработки программного обеспечения (SDLC), чтобы можно было своевременно и тщательно устранять уязвимости. К сожалению, тестирование часто проводится в конце цикла разработки. С ростом Непрерывная доставка и DevOps как популярные модели разработки и развертывания программного обеспечения,^{[6][рекламный источник? ]} модели непрерывной безопасности становятся все более популярными.^{[7][рекламный источник? ][8][рекламный источник? ]}

Сканеры уязвимостей, а точнее сканеры веб-приложений, также известные как тестирование на проникновение инструменты (т.е. этический взлом tools) исторически использовались организациями безопасности в корпорациях и консультантами по безопасности для автоматизации тестирования безопасности HTTP-запросов / ответов; однако это не заменяет необходимость фактического обзора исходного кода. Проверка физического кода исходного кода приложения может выполняться вручную или автоматически. Учитывая общий размер отдельных программ (часто 500 000 строк кода и более), человеческий мозг не может выполнить всесторонний анализ потока данных, необходимый для того, чтобы полностью проверить все обходные пути прикладной программы и найти точки уязвимости. Человеческий мозг больше подходит для фильтрации, прерывания и составления отчетов о выходных данных автоматических инструментов анализа исходного кода, доступных на рынке, в отличие от попыток проследить все возможные пути через скомпилированную базу кода, чтобы найти уязвимости на уровне первопричины.

Есть много видов автоматизированных инструментов для выявления уязвимостей в приложениях. Некоторые из них требуют большого опыта в области безопасности, а другие предназначены для полностью автоматизированного использования. Результаты зависят от типов информации (источник, двоичный код, HTTP-трафик, конфигурация, библиотеки, соединения), предоставляемой инструменту, качества анализа и объема обнаруженных уязвимостей. К распространенным технологиям, используемым для выявления уязвимостей приложений, относятся:

Статическое тестирование безопасности приложений (SAST) - это технология, которая часто используется в качестве инструмента анализа исходного кода. Метод анализирует исходный код на наличие уязвимостей до запуска приложения и используется для усиления кода. Этот метод дает меньше ложных срабатываний, но для большинства реализаций требуется доступ к исходному коду приложения.^[9] и требует экспертной конфигурации и большой вычислительной мощности.^{[10][рекламный источник? ]}

Динамическое тестирование безопасности приложений (DAST) - это технология, которая может находить видимые уязвимости, вводя URL-адрес в автоматический сканер. Этот метод хорошо масштабируется, легко интегрируется и работает быстро. Недостатки DAST заключаются в необходимости экспертной настройки и высокой вероятности ложных срабатываний и отрицательных результатов.^[9]

Интерактивное тестирование безопасности приложений (IAST) - это решение, которое оценивает приложения изнутри, используя программное обеспечение. Этот метод позволяет IAST сочетать сильные стороны методов SAST и DAST, а также обеспечивает доступ к коду, HTTP-трафику, библиотечной информации, внутренним соединениям и информации о конфигурации.^{[11] [12]} Некоторые продукты IAST требуют атаки на приложение, в то время как другие могут использоваться во время обычного тестирования качества.^{[13][рекламный источник? ][14][рекламный источник? ]}

Защита приложений

Достижения в профессиональном Вредоносное ПО ориентированные на Интернет. Клиенты онлайн-организаций столкнулись с изменениями в требованиях к дизайну веб-приложений с 2007 года. Обычно предполагается, что значительный процент пользователей Интернета будет скомпрометирован через вредоносное ПО и что любые данные, поступающие с зараженного хоста, могут быть испорчены. Таким образом, безопасность приложений стала проявляться в более совершенных системах защиты от мошенничества и эвристического обнаружения в бэк-офисе, а не в коде на стороне клиента или веб-сервера.^{[15][рекламный источник? ]} По состоянию на 2016 год самозащита приложения во время выполнения (РАСП) технологии разработаны.^[9][16] RASP - это технология, развернутая в среде выполнения приложения или вместе с ней, которая инструментирует приложение и позволяет обнаруживать и предотвращать атаки.^[17][18]

Скоординированное раскрытие уязвимостей

Координационный центр CERT описывает скоординированное раскрытие уязвимостей (CVD) как «процесс уменьшения преимущества злоумышленника при устранении уязвимости информационной безопасности». ^[19] CVD - это итеративный, многоэтапный процесс, в котором участвуют несколько заинтересованных сторон (пользователи, поставщики, исследователи безопасности), у которых могут быть разные приоритеты и которые должны работать вместе для устранения уязвимости. Поскольку в процессах сердечно-сосудистых заболеваний участвует множество заинтересованных сторон, управление информацией об уязвимости и ее устранении имеет решающее значение для успеха.

С операционной точки зрения, многие инструменты и процессы могут помочь при ССЗ. К ним относятся электронная почта и веб-формы, системы отслеживания ошибок и Скоординированные платформы уязвимостей.^[20]

Стандарты и нормы безопасности

• CERT безопасное кодирование
• CWE
• ДИСА-СТИГ
• Закон Грэмма-Лича-Блайли
• Медицинское страхование Портативность и Акт об ответственности (HIPAA)
• ИСО / МЭК 27034-1: 2011 Информационные технологии. Методы обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и концепции.
• ISO / IEC TR 24772: 2013 Информационные технологии. Языки программирования. Руководство по предотвращению уязвимостей в языках программирования путем выбора и использования языков.
• Специальная публикация NIST 800-53
• OWASP
• Стандарт безопасности данных PCI (PCI DSS )
• Закон Сарбейнса-Оксли (SOX)
• ETSI ТС 103 645 ^[21]

Смотрите также

• Поверхность атаки портфеля приложений
• Контрмера
• Безопасность данных
• Безопасность базы данных
• ГЕРАС-АФ
• Информационная безопасность
• Жизненный цикл разработки надежных компьютерных систем безопасности
• веб приложение
• Фреймворк веб-приложений

Рекомендации