Another brick in the wall
Fighting a losing battle on the front lines of security

by Brian Martin
DSIC Security Group
July 2000

 Security? Oops!
 A hacker's hacker
 A losing battle
 Building the wall
 About the author

You sacrifice convenience for security and security for convenience. For which goal was your computer network built?

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.

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.

The advice everyone asks for
Between security consulting by day, and running a nonprofit security-oriented Web site at night, I get asked a lot of questions. The second most-asked question (after "How do I hack?" which is ignored) comes from system administrators all over, who ask: "How do I secure my system?"

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.

Planning considerations
Such a wide range of networks is out there that it becomes impossible to detail all the issues that will be important to your network. Not only is it beyond the scope of this article, but it is simply not feasible.

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.

Building the wall
It's a given that your network/security administrators are fighting a losing battle. They probably don't have the time, training, or resources to adequately secure your corporate network. I know this, because I spent the last five years being that outside consultant, working on networks like your own. For administrators, the hardest part of all this, usually, is getting management to allot you the time and resources to develop a plan. While it is probably not a good idea to grant every request made by your employees, it is downright foolish to stand in the way of implementing sound security policies and practices. Remember, security -- though difficult -- is possible. But you must build your security plan like you would build a wall: from the ground up, and brick-by-brick. Simple logic is all it takes -- and it's foolish to deny resources to your administrators, who are fighting the good fight after all.


About the author
Brian Martin of the DSIC Security Group has been involved in computers since the early 1980s. His experience spans from first-generation home computers to large scale servers powering the most current business applications. Working in the computer security industry for the past five years, he has provided security audit and penetration assessment for foreign banks, Fortune 500 companies, and the U.S. Department of Defense. He has provided training and consultation for the Federal Bureau of Investigation, Defense Criminal Investigative Services, and the National Security Agency. In recent months, Brian's articles focusing on security issues have been widely circulated on the Internet, corporate newsletters, and print magazines. You can contact him at

Appendix: Five steps to a plan -- security advice in a nutshell

Perhaps the single best piece of advice one could offer for most companies is to start broad and slowly focus in on the little things. This process can be broken down into five major steps.

Begin by defining the security philosophy and policy your company will adhere to. With this in mind, develop a plan to implement the policy on your network. Validate the proposed plan, and proceed to implementing the technical details that defend the network. Last, review the security policy as well as the entire network, checking to see if components were implemented correctly, and that all machines conform to corporate policy. All too often, administrators begin to attack the problem of network security at the technical detail level. This is like trying to plug holes in a near-collapsing dam, frantically filling one hole as three more spring open. Rather than playing catch-up on a failing dam, one should look at building a more solid wall from the foundation.

(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.

  1. allow richard telnet access
  2. allow 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.

  1. deny telnet access
  2. deny http access
  3. deny mail access
  4. allow ALL ALL access

The above example sets three specific rules that block incoming traffic. All other connections from any host are allowed to connect to the resources we share. In the case of repeated intrusion attempts against a network, it might be determined that blocking access to a particular host will deter further attempts (rule #1). If a back door is found in one of your Web products, it may be wise to block access to the people found exploiting it (rule #2). Thousands of pieces of junk mail delivered from the same domain can cause unneeded network congestion and lead to blocking a domain from sending mail (rule #3). All other traffic would be permitted to reach its destination.

Disclaimer: These are fictitious "rules" designed to illustrate the philosophy of security. Implementing rules such as these will vary widely depending on each company's needs, as well as the tools they use to enforce such traffic enforcement.

(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.