Our most positive experience has been other people's break-ins. We saw three network break-ins in our building over a three month period. After each break-in, the affected groups have had several days down-time, while system administrators re-install software and data from distribution media and backups. We have not observed any break-ins through our firewall in that period, but the firewall also has a downside. To date, we have spent more time developing our firewall than we would have spent recovering from those break-ins. However, we view firewall development as a time investment that will prove its worth as more break-ins occur around us; moreover, other research groups that choose to follow our firewall architecture need not invest time reinventing this particular wheel.
Our firewall policy has evolved over nearly two years, and we expect this evolution to continue. This evolution confirms an important tenet of firewall design: having established a firewall, one cannot become complacent. Evolution occurs because of three forces. First, new security concerns arise, whether as a result of CERT advisories, recent breakins at other sites, or even penetration of one's own site. Second, application requirements change over time. When a new networked application becomes commonplace, the firewall's packet filters must eventually be extended to support the new protocol. One might also eliminate support for applications that are no longer widely used. Third, user access requirements change. In particular, the need for flexible authentication for incoming access seems to increase over time. The most difficult element of this evolution has been trying to maintain the firewall's simplicity (and hence its maintainability and security) without compromising flexibility. This evolution has led us to the request-response policy that we aim to fully support.