In a recent explanation about the RSA breach, Rick Wanner wrote on the Internet Storm Center (ISC) Diary:

The traditional paradigm of a well protected perimeter with a soft

inside should be dead.  There are just too many ways to circumvent the

perimeter, spear phishing being just one.

He then goes on to say:

Many have been advocating for years moving the prevention and detection

closer to the data.  There are a lot of approaches that can be used

here, but in my mind it begins with segregating servers from the desktop

LAN and controlling access to these protected enclaves as thoroughly or

better as we do our perimeters today.  It means classifying your data

and installing protection and detection technologies appropriate to the

sensitivity of the data.

This goes along with what I said in my SQL Connections SQL Server security presentation. The majority of users who need to access SQL Server only need to be able to connect to two things:

• The TCP port SQL Server is listening on. (TCP/1433 by default, but TCP/variable for a named instance)
• The SQL Server Listener Service/SQL Browser Service if they are trying to connect to a named instance (UDP/1434)

Otherwise, they don't need to touch SQL Server. Therefore, if we can isolate SQL Server better via the following mechanisms, the less likely it will be breached:

• Hardware firewall
• Access rules on routers/switches
• Windows firewall
• IPSEC policy on SQL Server

There are some servers/worsktations that a SQL Server will need to connect to beyond these ports if it is on the domain:

• Domain Controllers
• DNS Servers (if these aren't being run from the Domain Controllers in Integrated Mode)
• Backup Servers (if another technology/mechanism isn't being used)
• Application Servers
• DBA workstations (possibly both RDP and NetBIOS/SMB)

A diagram to describe this type of network security was this one:

Most infections start at user workstations. So it only makes sense to block off traditional attack vectors by firewalling off access to only what's necessary. Yes, this is harder. But it doesn't have to be a lot harder. For instance, if you can't decide the exact subset of user workstations that need access, or if it is too costly to do (based on the estimated cost for an exposure), then simply block off the client VLANs such that they can only connect to SQL Server on the ports listed above. This prevents worms that might attack via NetBIOS, scans that use pings (ICMP) to try and recon for juicy targets, etc. There are just too many ways to get inside a firewall and launch an attack from there. Therefore, what we're needing is additional barriers within the internal network, but not barriers that prevent reasonable access.