In a former life as well as my current one, we had a primary Information
Security officer, and myself acting as corporate firewall engineer. I found
that my own role was best performed as a network security "conductor" of the
"orchestra" of sysadmins who actually built and operated our Internet
systems. You build a mailing list and forward interesting stuff from
CERT/CIAC/Bugtraq/etc; you try to keep everyone informed, and guide them
along the way with reasonably well-stated firewall guidelines ("I'll do
this, I won't do that" with some give-and-take, and a little heartache over
the purity of the architecture). And you get involved with the business as
much as you can to spread the network security gospel.
At some level it becomes less of a pure technical security issue, and more a
social engineering challenge. Ultimately, it's all about risk management,
and minimizing your risk by maximizing the knowledge flow and relationships
that you build within the company. I recognized that generally I knew more
about network security and IP/TCP/UDP than the people running the systems,
and at some level you only get so much system security given the knowledge
of the folks involved. So you back it up with as much of a secure network
environment as you can negotiate v.s. the needs of the business, and make
sure that the top Security dog is on the same page as you are.
Ultimately you'll have an incident in spite of your best efforts -- no
matter how totalitarian you are in your security policies -- and the most
important thing is to educate everyone about the factors driving the
security architecture. Maybe you make fundamental changes in response to
the incident, or maybe you just try to educate everyone a little better, but
hopefully in either case learn something along the way.
dp