Re: Too Many Exceptions in the Firewall

[Gary Flynn <flynngn () JMU EDU>]

David Buckley wrote:

> How are you dealing with these issues? Do you have a policy that
> addresses this?

We also restrict inbound connections by default but approve
exceptions on individual request.


> Do you have SLA’s that address this?

No, but we generally turn around requests within 8 working hours
and often faster.


> How do you reveal the responsibility for the data to the department?

Our audit department has contracted with a third party to run
quarterly "open port" audits. The report goes to our audit
department who follows up with departments outside IT. Its
primarily a service audit with a little vulnerability
assessment thrown in.

We plan on making roll-up reports visible to department heads
that contain things like vulnerability scan summaries and
number and type of Internet exposed systems.


> Has anyone delegated firewall exceptions to the discretion of the
> department? Does that work well?

Firewall exceptions here are generally based on individual requests
and are granted by default with few exceptions. Doing that is how
we were able to go from a default permit to a default deny access
policy last November. Better to have four hundred systems exposed
to the Internet intentionally than four thousand unintentionally.


> What other protections do you have in place to augment the security for
> the exceptions?

We try and provide guidance on ways to minimize exposed ports
and ways to provide the desired functionality in alternate
ways. For example, if we get a request for remote desktop type
applications, we strongly encourage use of our VPN though we
don't require it.

Some ports are blocked even for "exposed" systems.

Our IPS devices help lower risk associated with exposed systems
as do various monitoring systems.

We are presently modifying our vulnerability scanning and
reporting procedures and will put more emphasis on exposed
systems. We'll probably tie a vulnerability scan and local
run of something like MBSA or CIS benchmarks to the exposure
request process in the future.

Internal network ACLs are being reviewed with the thought of
limiting access of exposed systems to sensitive areas and
providing a more stringent approval process if the request
comes from someone with elevated or sensitive access
privileges or needs.


> Also, if anyone has transitioned from perimeter firewalls to a more
> layered approach, please describe your migration steps.

We've had internal network access controls since we've had a
routed network with major increases in 1996 dealing primarily
with data center access and again in 2003 dealing with
cross-campus access.

Starting two years ago, a few sensitive administrative desktop
areas have been sealed off from other areas of campus with
default deny access policies. Other sensitive administrative
desktop areas have had their access restricted to web only
Internet access. A few have had their Internet access cut
off entirely inbound and outbound.

In general, migration steps include traffic analysis, threat
analysis, needs assessments, and communications with
affected parties. Generally, its a case of removing
unnecessary access ( hence unnecessary risk ). Generally, the
changes have been untroublesome and welcomed by the
participants though it results in some extra administrative
and support overhead and inconvenience and delays when
changes occur ( e.g new desktops, new systems, new
services, moves ).




--
Gary Flynn
Security Engineer
James Madison University
www.jmu.edu/computing/security