Программное обеспечение и безопасность - вы следуете определенным рекомендациям?

Question

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

Как вы подходите к этой теме в вашей организации?

Кроме того, мы пишем общедоступные веб-приложения в .NET 3.5, которые принимают платежи по кредитной / дебетовой карте.

Answer 1

Существует много разных способов нарушения безопасности. Вы можете ожидать бесконечных атакующих. Вы должны остановить их всех - даже атаки, которые еще не были изобретены. Это тяжело. Некоторые идеи:

1. Разработчики должны понимать хорошо известные правила безопасной разработки программного обеспечения. Говард и Ле Бланк «Написание безопасного кода» - хорошее начало.

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

3. Использовать контрольные списки, такие как OWASP (http://www.owasp.org/index.php/Main_Page).

4. Используйте независимую оценку (например, http://www.commoncriteriaportal.org/thecc.html). Даже если такая оценка слишком дорогая, составьте проект и документ, как если бы вы собирались ее использовать.

5. Убедитесь, что ваш аргумент безопасности выражен четко. Общие критерии Security Target - это хороший формат. Для серьезных систем также может быть полезно формальное описание. Будьте ясны в отношении любых предположений или секретов, на которые вы полагаетесь. Следите за тенденциями безопасности и часто пересматривайте угрозы и контрмеры, чтобы убедиться в их актуальности.

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

Answer 2

Попросите вашего QSA или ASV провести некоторое обучение для ваших разработчиков.

Answer 3

Безопасность в основном относится к одному или нескольким из трех доменов:

1) Внутренние пользователи

2) Сетевая инфраструктура

3) Сценарии на стороне клиента

Этот список написан в порядке серьезности, которая противоположна порядку вероятности нарушения. Вот правильные управленческие решения формируют очень широкую перспективу:

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

Сетевая инфраструктура является традиционной областью информационной безопасности. Два года назад эксперты по безопасности не рассматривали возможность искать средства управления безопасностью в другом месте. Некоторые основные стратегии заключаются в использовании NAT для всех внутренних IP-адресов, включении защиты портов в сетевых коммутаторах, физическом разделении служб на отдельном оборудовании и тщательной защите доступа к этим службам после того, как все скрыто за брандмауэром. Защитите свою базу данных от внедрения кода. Используйте IPSEC для доступа ко всем службам автоматизации за брандмауэром и ограничения точек доступа к известным точкам за IDS или IPS. По сути, ограничьте доступ ко всему, зашифруйте этот доступ и по сути доверяйте каждому запросу на доступ, который потенциально вредоносен.

Более 95% зарегистрированных уязвимостей безопасности связаны со сценариями на стороне клиента из Интернета и около 70% из этих целевых повреждений памяти, таких как переполнение буфера. Отключите ActiveX и требуйте прав администратора для активации ActiveX. Исправьте все программное обеспечение, которое выполняет любые сценарии на стороне клиента в тестовой лаборатории, не позднее, чем через 48 часов после выпуска исправлений от поставщика. Если тесты не выявили помех для конфигурации программного обеспечения, утвержденного компаниями, немедленно разверните исправления. Единственное решение для уязвимостей, связанных с повреждением памяти, - это исправление вашего программного обеспечения. Это программное обеспечение может включать: клиентское программное обеспечение Java, Flash, Acrobat, все веб-браузеры, все почтовые клиенты и т. Д.

Поскольку ваши разработчики соответствуют требованиям аккредитации PCI, убедитесь, что они и их руководство обучены понимать важность безопасности. Большинство веб-серверов, даже крупных корпоративных клиентов, обращенных к веб-серверам, никогда не исправляются. Для тех, кто исправлен, могут потребоваться месяцы для исправления после обнаружения уязвимости. Это технологическая проблема, но еще важнее то, что это грубая ошибка руководства. Веб-разработчики должны понимать, что сценарии на стороне клиента по своей природе открыты для эксплуатации, даже JavaScript. Эта проблема легко реализуется с появлением AJAX, поскольку информация может быть динамически введена анонимной третьей стороне в нарушение той же политики происхождения и полностью обойти шифрование, предоставляемое SSL. Суть в том, что технологии Web 2.0 по своей природе небезопасны, и эти фундаментальные проблемы не могут быть решены без ущерба для преимуществ технологии.

Когда ничего не помогает, наймите нескольких сертифицированных CISSP менеджеров по безопасности, которые имеют опыт управления, чтобы иметь возможность напрямую поговорить с руководителями вашей компании. Если ваше руководство не желает серьезно относиться к безопасности, ваша компания никогда не будет соответствовать требованиям PCI.