Как создавать безопасные системы. Краткое введение в SDL

При разработке любой программной системы, будь это простой вебсайт, десктоп-приложение или сложный трехзвенный комплекс, рано или поздно возникают вопросы безопасности. Нельзя исключить, что та система, которую вы разрабатываете, будет каким-то образом атакована. Причем, в зависимости от типа системы, ее сложности, применяемых технологических решений, векторы атак и их последствия могут иметь самый разный характер. Возможно, время от времени кто-то в команде проводит анализ безопасности разрабатываемой системы, проводится моделирование. Куда хуже если эти вопросы оставляются на потом. Результаты могут быть весьма плачевными, если вашу систему взламывают в режиме коммерческой эксплуатации и вам приходится впопыхах создавать исправления для обнаруженной бреши. Очевидно, что вопросы, связанные с безопасностью лучше решать, начиная с самых ранних этапов создания системы, таких как анализ требований и архитектурного моделирования. Но лучше всего это делать на всем жизненном цикле системы, интегрировав в процесс разработки специальные шаги, предназначенные для решения этих вопросов. Одним из таких процессов является Security Development Lifecycle – набор практик направленных на повышение безопасности разрабатываемых систем.

Что такое Security Development Lifecycle

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

Некоторые из этих практик сами по себе могут улучшить безопасность разрабатываемой системы. Но как показывает опыт, их применение в рамках процесса разработки позволяет значительно улучшить результат и снизить затраты.

Перед тем как внедрить SDL: Обучение

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

Безопасный дизайн

• Снижение областей атаки
• Глубокая защита
• Принцип наименьших привилегий
• Безопасность по умолчанию

Моделирование угроз, включая следующие темы:

• Обзор моделей угроз
• Влияние модели угроз на дизайн
• Ограничения для стиля кодирования, базирующиеся на модели угроз

Безопасное кодирование, включая следующие темы:

• Переполнение буфера (для приложений на C и C++)
• Ошибки целочисленной арифметики (для приложений на C и C++)
• Кросс-сайтовый скриптинг (для Веб-приложений)
• SQL-инъекции (для приложений взаимодействующих с БД)
• Слабая криптография

Тестирование безопасности, включая следующие темы:

• Различия между тестированием безопасности и функциональным тестированием
• Аудит рисков
• Методы тестирования безопасности

Обеспечение приватности, включая следующие темы:

• Типы приватной информации
• Приватность: лучшие практики дизайна
• Аудит рисков
• Приватность: лучшие практики разработки
• Приватность: лучшие практики тестирования

Конечно, при изучении этих тем необходимо учитывать роль (тестер, разработчик, менеджер, аналитик), тем не менее, очень важно чтобы все члены команды прошли этот тренинг.

Анализ требований: Что следует учитывать в контексте безопасности

Уже на уровне анализа требований к системе нужно учитывать важные аспекты, связанные с безопасностью. При этом важно разделять между собой «безопасные требования» и «требования безопасности». В SDL есть некоторый набор практик, и несколько таких из таких практик – «Анализ безопасности и приватности требований» может быть применена на этапе анализа требований. Эта практика предназначена для идентификации функциональных требований, у которых есть необходимость углубленного изучения вопросов связанных с безопасностью. Такой аудит может включать в себя следующую информацию:

1. Какая часть ПО требует анализа угроз перед релизом?
2. Какая часть ПО требует анализа дизайна в контексте безопасности?
3. Какая часть ПО требует дополнительного анализа угрозы проникновения независимой группой?
4. Есть ли дополнительные вопросы безопасности и риски, которые могут быть снижены?
5. Границы нечеткого тестирования в контексте безопасности.
6. Каков уровень угрозы разглашения приватных данных?

Дизайн с учетом безпасности

При дизайне приложений так же можно применить ряд практик, которые помогут повысить безопасность приложения. В первую очередь это снижение площади поверхности возможных атак (Attack Surface Reduction) и моделирование угроз. Несмотря на близкую взаимосвязь этих двух понятий, первый механизм подразумевает активное снижение возможностей злоумышленника на эксплуатацию неизвестных брешей в безопасности. Для снижения площади возможных атак можно применять механизмы послойной защиты и принципы наименьших привилегий. Моделирование угроз в свою очередь позволяет предположить, какие компоненты системы могут быть рассмотрены в качестве векторов атак. Удобным инструментом для моделирования угроз является Microsoft Thread Modeling Tool базирующийся на классификации STRIDE.

Реализация с учетом безопасности

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

Фаза верификации (тестирования) с учетом безопасности

На этой фазе возможно использование таких практик как динамический анализ кода (во время выполнения) который позволяет быстро выявить аномальное поведение функций, порчу памяти, использование привилегированных функций и другие критические проблемы. Одним из инструментов который может пригодится для решения этой задачи является AppVerifier. В дополнение к стандартным функциональным тестам так же следует добавить плавающее тестирование которое предназначено для проверки приложения в режиме ввода неверных данных, неправильно сформированных параметров и других условий которые могут привести к аномальному поведению но при этом все равно система должна быть в безопасном состоянии. Так же на этом этапе важным является проверка смоделированных векторов атак на предыдущих фазах для того чтобы убедиться в корректности сформированных моделей.

Фаза Выпуска с учетом безопасности

На этой фазе важно создание плана по реакции инцидентов связанных с безопасностью, в которых будет задекларирован порядок взаимодействия и реакции на выявленные угрозы или проникновение. Финальные релизы (RTM,RTW) должны соответствовать всем заранее обговоренным на стадии дизайна условиям безопасности перед развертыванием. Если это не так, даже при соблюдении всех функциональных требований, необходим повтор стандартного цикла разработки для фиксации проблем связанных с безопасностью.

Что дальше

Конечно, эта заметка раскрывает только самые основные аспекты SDL и для успешного применения требуется дополнительное изучение. Помочь в этом может центр безопасности MSDN.

Если вы хотите узнать более подробно о SDL, посмотрите завтра прямую трансляцию докладов конференции «Microsoft Secure Software Development Conference». В том числе там будут доклады Алекса Лукаса «Эволюция цикла безопасной разработки SDL», Гленна Питавея «Внедрение SDL».

990x.top

Простой компьютерный блог для души)

Windows SDK AddOn — что это за программа и нужна ли она?

Приветствую друзья! В Windows могут появиться программы, которые вы не устанавливали. Многих пользователей этим не удивишь, привыкли уже к такому беспределу)) Но откуда они берутся? Некоторые появились при установке других прог, некоторые установила сама Windows при обновлении, а третьи могут вообще быть вирусами или потенциально опасными, шпионскими там.. Но сегодня у нас пойдет речь про нормальную прогу для программистов))

Разбираемся

Windows SDK — пакет для создания приложений. В него входят новейшие заголовки, библиотеки, метаданные, и другие компоненты. Слово AddOn означает как дополнение, то есть дополнительный компонент.

Версия для Windows 10 позволяет создавать как классические, так и универсальные приложения.

Как я понимаю, классические приложения — это обычные привычные нам проги, которые можно скачать из интернета и установить. А вот универсальные — это уже метро-приложения, те самые модные плиточные проги, которые есть в меню пуск Windows 10, да и в Windows 8 они вроде тоже есть. Их еще можно скачать с магазина приложений (Microsoft Store).

Как пакет мог попасть на ПК:

1. Был скачан с офф сайта Майкрософт и установлен.
2. Был автоматически установлен как компонент Visual Studio (среда разработки для разработчиков).
3. Третий вариант — мое мнение. Если он вдруг появился сам по себе, то мог установиться как обновление. Второй вариант — появился после установки некоторой крупной программы.

Что интересно — разработка приложений UWP для десятки версии LTSB не поддерживается:

Инфа с офф сайта)

Версия для десятки, а точнее для билда 1809, содержит новые API-интерфейсы и обновленные средства для разработки приложений.

Вот картинка, видим что прога установлена среди остальных, но что главное — размер ее небольшой, всего 152 КБ:

Размер просто крохотный — поэтому можно оставить ее и не думать об удалении))

Тоже самое, но здесь прогу видим в списке окна Программы и компоненты:

Для вызова такого окна есть трюк — зажимаете Win + R, пишите команду appwiz.cpl, нажимаете ОК. В итоге откроется окно со списком установленного софта.

Установочное окно, где видим, то данная прога существовала еще во времена Windows XP:

Software Development Kit — набор средств разработки для программистов.

А вот и студия Visual Studio, где видим, что она при установке также может поставить Windows SDK:

Вывод — если вы программист — данный компонент у вас спокойно может быть.

Можно ли удалить данную программу?

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

Тем не менее, если вы хотите удалить прогу — лучше сначала сделать точку восстановления:

Зажимаете Win + R, пишите команду:

Команда откроет окошко Свойства системы.

Нажимаете ОК.
У вас откроется окно Свойства системы, здесь активируете вкладку Защита системы, где выбираете Системный диск и нажимаете Создать:
У меня кнопка неактивна, просто восстановление отключено. Но у вас — должна быть активна, в противном случае нажмите Настроить и включите восстановление.

Точку советую называть на понятном языке, например до удаления Windows SDK AddOn.

Теперь можете смело удалять Windows SDK AddOn, и даже другие проги, в том числе и системные. А если будут проблемы — при помощи точки восстановитесь до прежнего состояния ПК.

Лично я советую удалять только при наличии точки восстановления! Это важно!

Вывод

1. Windows SDK AddOn — компонент для программистов.
2. Для обычных юзеров не представляет никакой ценности.
3. Теоритически можно удалить. Но возможно он нужен для работы каких-то программ, учитывая небольшой размер — советую оставить его.

Что такое SDL?

Simple DirectMedia Layer (SDL) — это кроссплатформенная мультимедийная библиотека, реализующая единый программный интерфейс к графической подсистеме, звуковым устройствам и средствам ввода для широкого спектра платформ. Официально поддерживает такие операционные системы как: Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, и QNX. Приложения написанные с использованием SDL могут также работать и в следующих операционных системах: AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, и OS/2.

Использовать sdl вы можете соследующими языками программирования: Ada, C#, D, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, С++, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk и Tcl.

SDL распространяется по лицензии GNU LGPL второй версии. Эта лицензия позволяет вам свободно использовать SDL в комерческих программах.

Это официальное объяснение, теперь более понятное :). SDL — это библиотека которую вы можете использовать для создания 2d игр (и даже 3d).

Особенности
Независимость библиотеки от операционой системы и языка программирования
Внятная, понятная документация
Простая в использовании библиотека
Отрисовка графики через свой рендер, через OpenGL (что позволяет делать трехмерную игру) а при некотором старании и чтении документации с официального сайта возможность отрисовывать графику через DirectX.
Дополнительные библиотеки позволяющие расширить функциональность основной, такие как:
sdl image — позволяющая использовать разные графические форматы к примеру *.jpg или *.png.
sdl mixer — позволяет использовать разные звуковые форматы.
sdl net — повзоляет использовать сетевые возможности.
sdl rtf — позволит работать с тектовым форматом *.rtf. Например, можно будет записать в word’е справку и потом ее выводить в игре.
sdl ttf — позволяет использовать в игре любые ttf шрифты.
плюс разнообразные gui и оболочки для кода которые ожно найти на просторах интернета.