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

Question

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

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

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

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

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

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

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

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

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

Answer 4

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

I am neither a security expert, nor a compliance expert, nor a lawyer. Do not take this advice at face value. You should seek expert advice when dealing with confidential information.

Compliance and regulations.

I really cannot sum it up for you, please have a read: http://en.wikipedia.org/wiki/Information_privacy_law

United States: FISMA and FIPS

(Including but not limited to...)

Существуют стандарты и законы 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

Как мне начать с этого?

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

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

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

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

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

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

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

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

Answer 5

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

ура