Модель угрозы

Question

Я нахожусь в процессе написания документа модели угрозы для одного из приложений, которое я размещаю. Это веб-сайт Apache, который позволяет пользователям входить в систему, создавать свои виджеты, добавляя некоторые наиболее продаваемые продукты и т. Д. Может кто-нибудь дать мне указателио том, как начать с этого?

Frontend использует javascript + perl, backend - cpp.Мы принимаем конфиденциальную информацию от пользователя, такую ​​как его имя, SSN и т. Д., И мы храним идентификатор сеанса магазина

• Какими способами я могу определить дыры в безопасности в моем приложении?Как мне начать с этого?
• Какие области должны быть частью документа?
• Какие угрозы, такие как DoS и т. Д., О которых мне следует прочитать?

Answer 1

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

Надлежащий анализ дерева угроз начинается с ряда плохих результатов («утечка конфиденциальных данных», «серверы, похищенные для размещения вредоносных программ / рассылки спама / быть частью ботнета / чего бы то ни было»), компания, обманутая использованием украденных данных кредитной карты ", и вы можете думать больше) и работает в обратном направлении: что было бы необходимо для того, чтобы это произошло? Часто вы обнаружите, что у каждого плохого исхода будет несколько обязательных разрешающих событий - причинная цепь - и сравнивая их, вы сможете выявить слабые места и тщательно спланировать свою защиту.

Answer 2

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

Answer 3

Я не специалист по безопасности, но вот мои два цента.

1) Вы можете спокойно считать javascript небезопасным, поскольку на самом деле не контролируете его выполнение.

2) Итак, часть perl - это первая линия защиты. Для начала прочитайте perldoc perlsec .

Необходимо проверить Perl-код, содержащий eval, обратные пометки, system и open (всегда используйте открытый аргумент дерева, просто чтобы быть уверенным).

Также код, в котором отсутствуют строгие / предупреждения, следует пересмотреть и, в идеале, переписать.

Любые данные, которые не были тщательно проверены на достоверность, являются подозрительными. Конечно, ни один необработанный ввод (кроме файлов пользователя, которые хранятся только в системе) никогда не попадет на ваш сервер.

3) Из моего недавнего опыта:

• у нас была десериализация JSON, основанная на подаче входных данных в регулярное выражение и затем eval его использовании. Мне удалось передать код Perl через. FAIL .

• у нас был фрагмент кода, который был неясным, строгим, не содержал никаких комментариев и полагался на определенное поведение внешних программ, которое заставляло нас использовать устаревшую версию ssh. FAIL . (Я признаю, что не смог переписать его).

• у нас было open (FD, "$file");. Хотя ведущие / и .. были удалены из файла $ file, очевидно, он не был проверен на наличие символа канала (|). Вместо имени файла может быть предоставлена ​​тщательно созданная команда. FAIL . Всегда используйте открытый с тремя аргументами. То же самое относится к system / exec: только вариант @array в порядке, не полагайтесь на глупость ls '$file'.

Буду признателен за дополнения и / или исправления от других людей.

Answer 4

Отказ от ответственности:

Я не являюсь ни экспертом по безопасности, ни экспертом по соответствию, ни юристом.Не принимайте этот совет за чистую монету.При обращении с конфиденциальной информацией вам следует обратиться за советом к специалисту.

Соответствие нормативным требованиям.

Я действительно не могу подвести итог для вас, пожалуйста, прочитайте: http://en.wikipedia.org/wiki/Information_privacy_law

США: FISMA и FIPS

(включая, но не ограничиваясь ...)

Существуют стандарты и законы http://en.wikipedia.org/wiki/Federal_Information_Security_Management_Act_of_2002 http://en.wikipedia.org/wiki/Federal_Information_Processing_Standards

FIPS 199: http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

FIPS 200: http://csrc.nist.gov/publications/fips/fips200/FIPS-200-final-march.pdf

Вернуться к вопросу ...

Мы принимаем конфиденциальную информацию от пользователя, такую ​​какего имя, SSN и т. д.

FIPS 199 и 200 дадут вам хорошие отправные точки для оценки того, что необходимо сделать.

Какие способы я могу определитьдыры в безопасности в моем приложении?

• Платите экспертам за проверку вашей стратегии.
• Платите экспертам за ручное тестирование
• Платите хакерам за ответственное раскрытие.
• Посмотрите на базу данных Common Vulnerabilities and Exposures (CVE): https://cve.mitre.org/
• Посмотрите набаза данных эксплойтов: http://www.exploit -db.com /

например, для perl ... https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=perl

Как начать сthis?

Начните с этого определения информационного управления (IG): http://searchcompliance.techtarget.com/definition/information-governance

Оцените, как используется информация и где.

Записать тесты на проникновение дляВаше собственное программное обеспечение, использующее соответствующую информацию из базы данных CVE / exploit.

Какие области должны быть частью документа?

Я считаю, что при использованииДиаграмма архитектуры системы полезна для определения того, какие части нужно тестировать независимо и изолировать;и какие границы защищать.

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

Каковы некоторые изугрозы, такие как DoS и т. д., о которых мне следует прочитать?

Они перечислены в базах данных CVE / Exploit.

Answer 5

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

Приветствия