Security? Oops!
In the realm of human endeavor, there is usually a simple logic applied to the process of building things. This logic is seen in the way houses, computers, a even cans of mandarin oranges are built. We do not near completion of the production of these items only to attempt to squeeze in some vital element that was meant to be first. Foundations are not built after finishing the roof, processors are not seated after the case has been secured, and oranges are not added after the can has been sealed. Yet, when security is considered, this simple application of logic seemingly fails on a majority of computer networks.

We must identify one caveat when addressing this issue. Most computer networks (especially the Internet) were first designed with an open philosophy -- one of sharing information freely with anyone who needed it. Security was the little known hobby of a few geeks who enjoyed the cat and mouse game of "hacking" and securing machines. It's hard to pin down exactly when security became the big push in corporate America, but I think it safe to say it publicly surfaced in the last three or four years.

A hacker's hacker In the 1980s, the term "hacking" meant finding clever solutions to difficult problems, or discovering ways to work around situations that were difficult to solve. When the term hacker was bestowed upon you, it was a title of honor. It was high geek praise, and respect from your peers. It wasn't until almost a decade later that it took on a negative connotation.

Just as the Internet had been, five- and ten-year-old corporate networks, when new, were built for connectivity and convenience. As a general rule, you sacrifice convenience for security and security for convenience. The more unrestricted the access you enjoy, the less security is present on the network. Networks built from the ground up with all aspects in mind, especially security, enjoy a stronger foundation.

A losing battle
The real suffering surrounding network security can be found in the system administrator population, which is now playing catch-up. For years, the cries from above were for functionality. Integrate this, introduce this new technology, give us the ability to read sensitive corporate mail from our personal American Online (AOL) accounts. Management worldwide didn't care how things were done or what changes had to be made, they just wanted everything to be easy!

With the media and fledgling security companies preaching about the benefits of and need for good security, administrators are scrambling. Armed with a new corporate directive, administrators must weed through hundreds of self-proclaimed experts and thousands of inadequate Web sites to find pieces of the security puzzle. Missing the overall philosophy of security, they often become consumed with nit-picky details and technical countermeasures that are not always appropriate for their network. Network administrators today are simply fighting a losing battle, plugging each springing hole in their dam.

Of course, this question is the subject of entire books and Web sites, so a single e-mail response is typically lacking, to say the least. Even if there was no other evidence, the large volume of e-mail I get asking about security advice tells me that networks are behind the curve in security measures.

If you're reading this article, you may already have a production network up and running right now -- putting you at a serious disadvantage. Every passing day brings the possibility of your insecure network being compromised.

While implementing a plan for securing an existing network, you must consider the machines currently deployed. Have any of them been victim to a past compromise? Has an intruder buried himself deep enough so that new security measures will not keep him out? Has an employee with legitimate access secretly backdoored your systems, undermining any new security patches you will install? As a security bricklayer, ask yourself how the wall was built, if you used the right materials, and if there was a bad brick that will undermine the strength of the wall.

One section of the security plan must address these questions and provide policy to deal with cases such as these. Because of these concerns, your task of security will be daunting. For those implementing security policy on a new network, you are exempt from these bad questions! However, you must build the wall from the ground up using the right tools, materials, and techniques, lest it fall at the worst possible time.

For the lucky few who are designing a network from the ground up, the good news is that you can design it in such a way that security should never be a problem or concern for you. Whether it is a completely new network, or additional subnets to your existing corporate structure, implementing security policy from the beginning will alleviate a lot of headaches down the road. Performing consistent upgrades and security patch installation can turn the job of security from a full-time gig into an hour-a-day task. The time gained from this prior planning allows network administrators to spend more time on critical areas as needed. They can also dedicate more time to thorough analysis of logs, implementation of more advanced security measures, and browsing favorite (er, work-related) Web sites.

Resources

(1) Security philosophy and policy
Security can be boiled down into two major philosophies, each of which will guide network security policy. It is usually fairly obvious which will be more appropriate to your network, but the choice may not necessarily be black and white. Companies that offer public services outside of their internal network may adopt on philosophy for those machines, while adopting the other for important resources.

That which is not explicitly allowed, is denied.

Simply put, if you do not go out of your way to explicitly and intentionally allow a particular user or service, then the traffic to your network is denied. For the most part, this is the philosophy that all networks should take. Another way of looking at this is to close all resources from the start, and slowly open them as needed to continue network functionality.

Example:
1. allow richard telnet access
2. allow business.partner.com ftp access
3. allow group_admins oracle access
4. deny ALL ALL access

In the example above, we see three specific rules allowing a person(s) to access specific network resources. Incoming traffic is checked against each rule one at a time. If it doesn't match the first three, it then matches the final rule denying the traffic. This security philosophy defaults to the most secure posture for your network, and is ideal for corporate networks with an Internet presence.

That which is not explicitly denied, is allowed.

Opposite of the other philosophy, this one is intended for open networks that share resources with almost anyone. This philosophy is best suited for public resources found at colleges, search engines, etc.

Example:
1. deny hacker8.com telnet access
2. deny danise.net http access
3. deny aol.com mail access
4. allow ALL ALL access

(2) Developing a plan
This stage of network security will often be the most lengthy and difficult phase. In a seemingly never ending game of proposal and revision, the plan for addressing the security needs of your company must be detailed, precise, and thorough. It must cover all aspects of the company resources, not just network-connected computers. Issues such as physical security, employee awareness, and administrator training must also be covered.

Who will be involved?

The plan must include everyone that will be involved in the project. This includes company employees as well as outside consultants. It should be thorough and list which phases of the plan will be implemented, and the people involved. Assign a point of contact (POC) at each phase that will answer questions and make decisions if something is unclear.

What will be done?

List details when each aspect of security is outlined (physical, training, network). This includes the actual policy that will dictate what is done to a machine or resource to make it secure. Include whom will train employees, what material will be covered, what types of controlled access will be installed, and which vendor will be utilized. Include also the amount of money will it take, and where it will come from.

What timeframe is needed?

Give each phase of the security plan adequate time to be completed. It is important that this timeframe reflect the best estimate to finish the job. If the deadlines are impossible to meet, the entire plan will take on a negative and burdening feel from the first missed deadline. It is important not to over-estimate the time so that those involved do not lose focus of the long-term goals.

(3) Validate
In the ideal security plan, validation occurs at every stage of the game. Because time and resources are often sparse, this cannot necessarily happen. If this is a problem you foresee, there are at least two phases where validation must occur; validation of the security plan and review of the finished product. Validation is essential to ensure integrity is maintained throughout the security process. Validation may come in different forms depending on the resources available to you. If the entire plan for security is developed in-house, you should seek external security consultants to review your plan and make suggestions. Just because they review the plan does not mean they have to be involved in implementation down the road.

You should make sure to choose reputable and knowledgeable consultants to review this plan. If the security plan is developed by a mix of outside consultants and inside staff, seek validation by conducting a peer review (others knowledgeable about security but not necessarily on this project) or hiring third-party consultants. Hiring additional consultants to audit the first set may be expensive, but the results can often be staggering.

(4) Implementing the technical details
At this point, you should be breaking out the old jargon dictionary and reviewing terms like SSH, HTTPS, FWTK, and more. Administrators of each machine take the time required to implement the policy set forth in this process. If the security plan is thorough and your technical staff is capable, this phase of the operation should go smoothly and quickly.

Each system is analyzed for security weaknesses, and each vulnerability is fixed. This analysis includes concerns for both local and remote users. Always keep in mind that security threats may come from internal users (yes, your employees) just as quickly as external hackers. Company firewalls have their rule sets checked, router configurations reviewed, and operating system patches updated. All of your administrator's time spent reading security Web sites and mail lists should pale in comparison to your corporate security plan. Sites and lists can typically offer a good idea of security vulnerabilities and patches, but can lack the whole picture that brings it together for your organization.

(5) Review
When the security concerns have been discovered and the policy implemented, it is important to review and validate the work done. It is critical that you warn your staff of this stage in advance. Explain to them that this step is not being taken because of a lack of trust in them, but is simply a method for making sure that all phases of the project have been completed. We all know that in large companies, the signals can get crossed, leading to confusion about who did what. This stage of review is simply a tool to make sure everyone completed the required task and the network is secure.

The final step in implementing a security plan should be a real-world test of your network. Contact employees at random to ensure that everything is still working properly. Securing networks has a nasty habit of turning off services or denying access to legitimate employees. The goal is to achieve a secure network and maintain all functionality needed to conduct business. If your budget allows, hire a quick and dirty third-party penetration assessment of your network.