Безопасность благодаря дизайну
 | Эта статья содержит инструкции, советы и инструкции . ( июнь 2022 г. ) |
Задуманная безопасность в разработке программного обеспечения означает, что программные продукты и возможности разрабатываются с учетом фундаментальной безопасности .
Альтернативные стратегии, тактики и шаблоны безопасности рассматриваются в начале разработки программного обеспечения, а лучшие из них выбираются и реализуются в архитектуре, а также используются в качестве руководящих принципов для разработчиков . [1] Также рекомендуется использовать стратегические шаблоны проектирования, которые оказывают благотворное влияние на безопасность , даже если эти шаблоны проектирования изначально не были разработаны с учетом безопасности. [2]
Secure by Design все чаще становится основным подходом к разработке, обеспечивающим безопасность и конфиденциальность программных систем. При таком подходе безопасность рассматривается и встроена в систему на каждом уровне и начинается с разработки надежной архитектуры. Решения по проектированию архитектуры безопасности основаны на хорошо известных стратегиях, тактиках и шаблонах безопасности, определяемых как методы многократного использования для достижения конкретных проблем качества. Тактики/шаблоны безопасности предоставляют решения для обеспечения необходимых требований аутентификации , авторизации, конфиденциальности, целостности данных , конфиденциальности, подотчетности, доступности, безопасности и неотказуемости, даже когда система подвергается атаке. [3] Чтобы обеспечить безопасность программной системы, важно не только разработать надежную предполагаемую архитектуру безопасности, но также необходимо сопоставить обновленные стратегии, тактики и шаблоны безопасности с разработкой программного обеспечения, чтобы поддерживать постоянство безопасности.
Ожидайте атак [ править ]
Следует предполагать, что вредоносные атаки на программное обеспечение имеют место, и принять меры для минимизации последствий. Ожидаются уязвимости безопасности, а также неверный ввод данных пользователем . [4] Тесно связана с этим практика использования «хорошего» проектирования программного обеспечения, такого как доменно-ориентированное проектирование или облачное проектирование , как способ повышения безопасности за счет снижения риска ошибок, связанных с открытием уязвимостей, даже несмотря на то, что используемые принципы проектирования изначально не были задуманы для обеспечения безопасности. целей.
Избегайте безопасности через неизвестность [ править ]
Как правило, хорошо работающие проекты не обязательно должны быть секретными . Часто секретность уменьшает количество злоумышленников, демотивируя часть группы угроз. Логика заключается в том, что если злоумышленник усложнится, то возросшие усилия злоумышленника по компрометации цели обескуражят его. Хотя этот метод подразумевает снижение присущих рисков, практически бесконечный набор субъектов угроз и методов, применяемых с течением времени, приведет к сбою большинства методов секретности. Хотя это и не является обязательным, надлежащая безопасность обычно означает, что каждому разрешено знать и понимать конструкцию, поскольку она безопасна . Это имеет то преимущество, что многие люди смотрят на компьютерный код , что повышает вероятность того, что любые недостатки будут обнаружены раньше (см. закон Линуса ). Недостатком является то, что злоумышленники также могут получить код, что облегчает им поиск уязвимостей для использования. Однако обычно считается, что преимущества открытого компьютерного кода перевешивают недостатки.
Наименьшее количество привилегий [ править ]
Также важно, чтобы все работало с наименьшими возможными привилегиями (см. принцип наименьших привилегий ). Например, веб-сервер , работающий от имени пользователя-администратора («root» или «admin»), может иметь право удалять файлы и пользователей. Таким образом, ошибка в такой программе может подвергнуть риску всю систему, тогда как веб-сервер, который работает в изолированной среде и имеет привилегии только для необходимых функций сети и файловой системы , не может поставить под угрозу систему, в которой он работает, если не обеспечена безопасность вокруг него. само по себе тоже ошибочно.
Методологии [ править ]
Безопасное проектирование должно учитываться на всех этапах жизненного цикла разработки (какая бы методология разработки ни была выбрана). Существуют некоторые готовые методологии разработки Secure By Design (например, Microsoft Security Development Lifecycle ).
Стандарты и законодательство [ править ]
Существуют стандарты и законодательство, которые помогают безопасному проектированию, контролируя определение понятия «безопасность» и предлагая конкретные шаги по тестированию и интеграции безопасных систем.
Некоторые примеры стандартов, которые охватывают или затрагивают принципы Secure By Design:
- ЕТСИ ТС 103 645 [5] который частично включен в «Предложения правительства Великобритании по регулированию кибербезопасности потребительских интеллектуальных продуктов». [6]
- Серия стандартов ISO/IEC 27000 охватывает многие аспекты безопасного проектирования.
Архитектуры сервер/клиент [ править ]
В архитектурах сервер/клиент программа на другой стороне может не быть авторизованным клиентом, а сервер клиента может не быть авторизованным сервером. Даже если это так, атака «человек посередине» может поставить под угрозу связь.
Зачастую самый простой способ нарушить безопасность клиент-серверной системы — это не бросаться в глаза механизмам безопасности, а обойти их. Атака «Человек посередине» является простым примером этого, поскольку вы можете использовать ее для сбора данных, чтобы выдать себя за пользователя. Вот почему важно учитывать в своем проекте шифрование , хеширование и другие механизмы безопасности, чтобы гарантировать, что информация, полученная от потенциального злоумышленника, не позволит получить доступ.
Еще одной ключевой особенностью проектирования системы безопасности клиент-сервер являются хорошие практики кодирования . Например, следование известной структуре проектирования программного обеспечения, такой как клиент и брокер, может помочь в разработке хорошо построенной структуры с прочным фундаментом. Более того, если программное обеспечение будет изменено в будущем, еще более важно, чтобы оно соответствовало логическому принципу разделения между клиентом и сервером. Это связано с тем, что если программист приходит и не может четко понять динамику программы, он может в конечном итоге добавить или изменить что-то, что может добавить брешь в безопасности. Даже при самом лучшем проекте такая возможность всегда существует, но чем лучше стандартизация проекта, тем меньше шансов, что это произойдет.
См. также [ править ]
- Компьютерная безопасность
- Стандарты кибербезопасности
- Закалка
- Несколько независимых уровней безопасности
- Безопасно по умолчанию
- Безопасность через неизвестность
- Обеспечение безопасности программного обеспечения
Ссылки [ править ]
- ^ Сантос, Джоанна К.С.; Таррит, Кэти; Мирахорли, Мехди (2017). «Каталог слабых мест архитектуры безопасности». Международная конференция IEEE по семинарам по архитектуре программного обеспечения (ICSAW) , 2017 г. стр. 220–223. дои : 10.1109/ICSAW.2017.25 . ISBN 978-1-5090-4793-2 . S2CID 19534342 .
- ^ Дэн Берг Джонссон; Дэниел Деогун; Дэниел Савано (2019). Безопасный дизайн . Публикации Мэннинга. ISBN 9781617294358 .
- ^ Хафиз, Мунавар; Адамчик, Пол; Джонсон, Ральф Э. (октябрь 2012 г.). «Развитие языка шаблонов (для безопасности)». Материалы международного симпозиума ACM «Новые идеи, новые парадигмы и размышления о программировании и программном обеспечении» . стр. 139–158. дои : 10.1145/2384592.2384607 . ISBN 9781450315623 . S2CID 17206801 .
- ^ Догерти, Чад; Сэйр, Кирк; Сикорд, Роберт С.; Свобода, Давид; Тогаши, Казуя (октябрь 2009 г.). «Шаблоны безопасного проектирования». дои : 10.1184/R1/6583640.v1 .
{{cite journal}}: Для цитирования журнала требуется|journal=( помощь ) - ^ «ETSI TS 103 645» (PDF) .
- ^ «Аналитический документ: Предложения по регулированию кибербезопасности потребительских интеллектуальных продуктов – запрос мнений» .
