To borrow and twist a phrase from John Donne: “No LAN is an island,” especially in the 21st century. Unless you’re dealing with heavily protected systems and networks, you either already have existing external, third-party — government-to-business (G2B) — connections or will in the not-too-distant future. Then there are the virtual workers to contend with who require access to information on your network no matter where they are physically located on (or off) the planet.
In this reality, it’s crucial to know how to apply policies, processes and technology to safeguard your networks.
Realities in a Flat World
When it comes to government dollars, budgets are tight. Monolithic, well-funded information technology departments, wielding universal control over the computing infrastructure, are a thing of the past — in part, because of the migration from centralized systems to distributed computing. The need to reduce costs and provide ubiquitous and immediate access to information resources, however, has also played a role in this transformation.
For example, when building a new application, do you hire a full programming staff in-house or do you outsource the development? Are you required to provide remote access to your employees? Do you need to staff a network operating center 24 x 7, or would it be more beneficial to work with a managed services provider? When reviewing your critical spend items for the coming year, you will probably be faced with similar questions.
The bottom line is that you know you’re going to need to create and manage external access to your internal systems and you need the tools and resources to do it as securely as possible.
Foundations in Policy
Solid IT security policies are the cornerstone of any G2B initiative. A good policy framework enables mandatory classification of data, which in turn enables the definition of risk categories and the creation of adequate protection mechanisms — all of which is mandatory. (See Appendix III to OMB Circular A-130 at OMB Circular A-130 and the Federal Information Security Management Act at Federal Information Security Management Act).
The first step is determining what you need to protect. You’ll need to look in all the places data “hides” on your network — possibly doing a full network discovery scan — and survey all your users. You may discover that there are critical systems and services on your network you never knew about (despite all the regulations and inventories). This step is extremely important because you need to classify all this data according to policy.
Once you know what you need to protect, you must decide on the level of restrictions to external access. For example, the Health and Human Services Department policy on network connections does not limit connectivity to only those networks with government-owned equipment. External and remote access is allowed as long as systems — whether they belong to HHS or a third party — have proper controls. The Food and Drug Administration has taken the opposite approach, establishing a policy that requires FDA-owned and -managed equipment as a prerequisite for connections. Your needs will probably fall somewhere in between and be dependent on your risk appetite.
Efficiency Through Process
Policies are only part of the solution to enabling external connections. Step two requires that you define and implement efficient processes to support your policies. Enabling connections can mean installing new circuits or expanding the number of routers. Firewalls will need new rules; accounts will need to be created; software may need to be distributed and installed; help desk staffs will need training and documentation.
Small failures or hiccups in any of these areas can translate into significant delays, which might do more than just frustrate users and project managers. You do not want your lack of effective processes to be the cause of a cost overrun on a critical project.
Whether it be virtual private network access for a user or full LAN interconnection, you need to a well-defined request mechanism in place, a solid review process to ensure all the necessary prerequisites are met, change approvals lined up and support mechanisms communicated to all internal and external parties.
Having these processes in place will give you ample time to review requests to ensure that any given connection meets all your security requirements, provide all the necessary details to the requesting parties and reduce the amount of time it takes to establish the link.
Security Through Technology
To fall back on a familiar metaphor, policy and processes are two legs of this three-legged stool. The third step, or leg, is technology, and it is no less important than the other two. It is vital that you define all the requirements for each of your connection types to pick the best technology to implement the solution. Failure to do so could result in choosing a product that cannot support your policies and processes. You might also limit your ability to use emerging technologies if you choose solutions that have limited operating system support.
Technology can also help you think outside of the box when designing solutions. You might be able to take advantage of a Secure Sockets Layer VPN that keeps external access at the application layer. If Web-based application-level access is too limiting, you can still avoid being in the software distribution business if you evaluate units that automatically deploy necessary client software on demand. Another option that should not be overlooked is the use of Remote Desktop Protocol connections to provide desktop application-only access in a highly controlled environment. Implementing such approaches will reduce the number of physical network connections and let you concentrate on managing security at the app level (which presents a whole host of other challenges).
Building your G2B strategy on a solid foundation of policy, process and technology will enable you to meet the connectivity needs of your users as efficiently, cost-effectively and — most important — as securely as possible.