A good exercise for any security admin is to map your security domains or zones. The idea is that a map of the inputs and outputs of your organization's data pathways will give you a clearer idea of the users, gateways, systems, and data that you are trying to secure. Unless you know about it, it's impossible to secure it. And, as the saying goes, a problem well defined is a problem half-solved.
Start with all of the ways that people can enter your environment: LAN, WAN, VPNs, Terminal Server, Citrix, RDP, Internet, wireless, smartphones, BlackBerrys, FTP, Telnet, point-to-point circuits, and so on. Then tie these entry points to all the user types: employees, consultants, business partners, remote employees, visitors, guests, vendors, business partners, auditors. Don't forget anonymous users if you have public Web sites and other non-authenticated assets. Save one big placeholder for outsiders, intruders, and unauthorized users.
[ Learn how to secure your systems with InfoWorld's Security Adviser newsletter. ]
Next, define all the places where your data resides, including file servers, Web servers, database servers, SharePoint servers, laptops, mobile computers, smartphones, SANs, NASes, midrange computers, mainframe computers, offline storage, tapes, and USB keys. Classify the different data repositories with basic data classification levels. If one bit of data is high business impact (HBI), then the whole server or database is HBI.
Now here's where the graphics come in. Using Microsoft Visio or some other drawing tool, draw the lines from the people over the entry points to the data they need to access. If you manage an organization of any decent size or complexity, your diagram will look as complicated and convoluted as any you have ever seen in your life. I've seen Visio diagrams of this roll out on plotter paper reaching several feet in each direction.
This, my friends, is the environment you are being asked to manage and protect. If this is your first time trying to do this exercise, think about how you were ever able to defend your environment without this big-picture look. Isn't it all much clearer now?
To defend appropriately, you must create virtual security domains that keep disparate roles from connecting to entry points and data sets that they should not access. How you accomplish it is different for each organization -- indeed, it's different for each entry point, user type, data repository, and data classification.
The next step is to come up with the various types of authentication you want to support (such as physical, simple log-on names and passwords, two-factor authentication, and so on) and which should be allowed for the various entry points, user types, data types, and data classifications.
Naturally, you must also determine how the various data should be protected. What data classification levels require what levels of protection? What data types should be protected by transport encryption? What types of data require encryption at rest? You need to answer all these questions to begin to tackle how to secure the various security domains.
Less is more secure
I find it immensely helpful to get rid of any assets that people aren't using or the business doesn't need. Review all the inventoried items and work with the business stakeholder to cut the non-essentials. If FTP isn't needed, get rid of it, and replace it with something more secure. If users don't need the data, delete it. If you can consolidate various entry points and authentication methods into fewer mechanisms, do so. Less is less complicated. Less is lower cost and easier to secure.
Finally, define all the ways to keep the various user types and security zones from encroaching on each other. Here you'll use routers, firewalls, access control lists, authentication, VLANs, IPSec, SSL, and all the other tools that let you define security domains. Creating security domains that stretch from the user type/entry point object to the final destination (system or data) is what you should strive to accomplish. It's nice to terminate a user's protected connection at a perimeter firewall or proxy, but much better to maintain that security domain all the way to the data. That way user types inside your perimeter have a harder time commingling in other security domains' data.
Of course, it's a huge project. You won't be able to do it all in one big push, but bite off what you can in a given year and try to accomplish it. What you can do will make your organization more secure. And what you can't do -- well, at least you'll have a clear view of your security challenges and the opportunities for improvement ahead.