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

• Является ли используемый программой протокол хорошо известным и опубликованным?
• Доступно ли приложение, обслуживающее этот протокол, для всеобщей оценки его реализации?
• Насколько хорошо вы знаете эту службу и соответствующие программы?
• Как поддержка этой службы изменит архитектуру брандмауэра? Изменится ли система с точки зрения атакующих? Можно ли использовать новую службу для проникновения во внутреннюю сеть или для изменения тех или иных компонентов на хостах в ДМЗ?

При рассмотрении этих вопросов учитывайте следующее:

• «Защита за счет сокрытия деталей» — это вообще не защита. Неопубликованные протоколы часто изучались и взламывались злоумышленниками.
• Вопреки утверждениям сотрудников службы продаж, не все протоколы и службы разрабатывались с учетом защиты. Фактически, таких протоколов очень мало.
• Даже если проблемы защиты и учитывались, не во всех организациях есть квалифицированные специалисты по защите. И не все из тех, где таких специалистов нет, готовы подключать к проекту компетентных консультантов. В результате, компетентные и хорошо подготовленные во всех остальных отношениях разработчики могут создавать небезопасные системы.
• Чем меньше желание поставщика рассказать о деталях работы системы, тем вероятнее, что существуют проблемы защиты (или другие проблемы). Только поставщики, которым есть что скрывать, имеют основания скрывать проектные решения и особенности реализации.