Безопасность по замыслу в разработке программного обеспечения означает, что программные продукты и возможности разработаны с учетом основ безопасности .
Альтернативные стратегии, тактики и шаблоны безопасности рассматриваются в начале проектирования программного обеспечения, а лучшие выбираются и применяются архитектурой, и они используются в качестве руководящих принципов для разработчиков . [1] Также рекомендуется использовать стратегические шаблоны проектирования, которые оказывают благотворное влияние на безопасность, даже если эти шаблоны проектирования изначально не были разработаны с учетом требований безопасности. [2]
Secure by Design все больше становится основным подходом к разработке для обеспечения безопасности и конфиденциальности программных систем. При таком подходе безопасность учитывается и встроена в систему на каждом уровне и начинается с надежной архитектуры. Решения по проектированию архитектуры безопасности основаны на хорошо известных стратегиях, тактиках и шаблонах безопасности, определенных как многократно используемые методы для решения конкретных задач качества. Тактики / шаблоны безопасности предоставляют решения для обеспечения необходимой аутентификации , авторизации, конфиденциальности, целостности данных , конфиденциальности, подотчетности, доступности, безопасности и неотказуемости, даже когда система подвергается атаке. [3] Чтобы обеспечить безопасность программной системы, важно не только разработать надежную архитектуру безопасности (предназначенную), но также необходимо сопоставить обновленные стратегии, тактики и шаблоны безопасности с разработкой программного обеспечения, чтобы поддерживать постоянство безопасности.
Ожидайте атак
Следует предполагать наличие злонамеренных атак на программное обеспечение, и следует принимать меры для минимизации воздействия. Ожидаются уязвимости системы безопасности, а также недопустимый ввод данных пользователем . [4] Тесно связана практика использования «хорошего» дизайна программного обеспечения, такого как проектирование на основе предметной области или нативное облачное решение, как способ повышения безопасности за счет снижения риска ошибок, связанных с открытием уязвимостей, даже несмотря на то, что использованные принципы проектирования не были изначально задумано в целях безопасности.
Избегайте безопасности через безвестность
Как правило, хорошо работающие дизайны не полагаются на секретность . Часто секретность снижает количество злоумышленников за счет демотивации подмножества угроз. Логика заключается в том, что если для злоумышленника увеличивается сложность, то злоумышленник прилагает больше усилий для компрометации цели. Хотя этот метод подразумевает снижение неотъемлемых рисков, практически бесконечный набор действующих лиц и методов, применяемых с течением времени, приведет к сбою большинства методов секретности. Хотя это и не является обязательным, надлежащая безопасность обычно означает, что каждому разрешено знать и понимать дизайн, потому что он безопасен . Это имеет то преимущество, что многие люди смотрят на компьютерный код , что увеличивает вероятность того, что любые недостатки будут обнаружены раньше (см . Закон Линуса ). Злоумышленники также могут получить код, что также облегчит им поиск уязвимостей .
Меньше привилегий
Также важно, чтобы все работало с наименьшими возможными привилегиями (см. Принцип наименьших привилегий ). Например, веб-сервер , работающий от имени администратора («root» или admin), может иметь право удалять файлы и пользователей, которым не принадлежат. Недостаток такой программы может поставить под угрозу всю систему, в то время как веб-сервер, который работает в изолированной среде и имеет права только на требуемые функции сети и файловой системы , не может поставить под угрозу систему, в которой он работает, если только безопасность вокруг него не будет нарушена. сам тоже ущербный.
Методологии
Безопасный дизайн следует учитывать на всех этапах жизненного цикла разработки (независимо от выбранной методологии разработки ).
Существуют некоторые предварительно созданные методологии разработки Secure By Design (например, жизненный цикл разработки безопасности Microsoft ).
Жизненный цикл разработки безопасности Microsoft
Microsoft выпустила методологию и руководство, основанные на классической спиральной модели .
Стандарты и законодательство
Стандарты и законодательство существуют для поддержки безопасного проектирования, контролируя определение слова «безопасный» и предоставляя конкретные шаги для тестирования и интеграции безопасных систем.
Некоторые примеры стандартов, которые охватывают или затрагивают принципы Secure By Design:
- ETSI TS 103 645 [5], который частично включен в "Предложения правительства Великобритании по регулированию кибербезопасности интеллектуальных продуктов" [6]
- Серия ISO / IEC 27000 охватывает многие аспекты безопасного проектирования.
Архитектура сервер / клиент
В архитектурах сервер / клиент программа на другой стороне может не быть авторизованным клиентом, а клиентский сервер может не быть авторизованным сервером. Даже если это так, атака «человек посередине» может поставить под угрозу связь.
Часто самый простой способ нарушить безопасность системы клиент / сервер - не обращаться к механизмам безопасности, а вместо этого обойти их. Атака «человек посередине» - простой пример этого, потому что вы можете использовать ее для сбора деталей, чтобы выдать себя за пользователя. Вот почему важно учитывать шифрование , хеширование и другие механизмы безопасности в вашем проекте, чтобы гарантировать, что информация, собранная от потенциального злоумышленника, не позволит получить доступ.
Еще одна ключевая особенность системы безопасности клиент-сервер - это хорошие методы кодирования . Например, следование известной структуре проектирования программного обеспечения, такой как клиент и брокер, может помочь в разработке хорошо построенной структуры с прочной основой. Кроме того, если программное обеспечение будет изменено в будущем, еще более важно, чтобы оно следовало логической основе разделения между клиентом и сервером. Это потому, что если программист приходит и не может четко понять динамику программы, он может в конечном итоге добавить или изменить что-то, что может добавить брешь в безопасности. Даже при лучшем дизайне это всегда возможно, но чем лучше стандартизован дизайн, тем меньше шансов на то, что это произойдет.
Смотрите также
Рекомендации
- ^ "Каталог слабых сторон архитектуры безопасности". 2017 IEEE Международная конференция по разработке программного обеспечения архитектуры (ICSA) . DOI : 10.1109 / ICSAW.2017.25 .
- ^ Мэннинг (2019). Безопасность по дизайну . ISBN 9781617294358.
- ^ «Развитие языка шаблонов (для безопасности)». Вперед! 2012: Материалы международного симпозиума ACM по новым идеям, новым парадигмам и размышлениям о программировании и ПО : 139–158. Октябрь 2012 г. doi : 10.1145 / 2384592.2384607 .
- ^ Догерти, Чад; Сэйр, Кирк; Сикорд, Роберт С.; Свобода, Давид; Тогаши, Казуя (октябрь 2009 г.). «Шаблоны безопасного проектирования». DOI : 10,1184 / R1 / 6583640.v1 . Цитировать журнал требует
|journal=
( помощь ) - ^ «ETSI TS 103 645» (PDF) .
- ^ «Программный документ: предложения по регулированию кибербезопасности потребительских смарт-продуктов - призыв к просмотру» .
Внешние ссылки
- Безопасное программирование для Linux и Unix HOWTO
- Часто задаваемые вопросы по безопасному программированию UNIX
- 10 лучших практик безопасного кодирования
- Безопасность по принципам дизайна