discussing security

An Interview with Char Sample and Mark Teicher

Editor's note: This interview was conducted electronically over the summer among Rob Kolstad, Char Sample, and Mark Teicher.

Char Sample <[email protected]> is Manager, Price Waterhouse LLP, Enterprise Security Solutions.

Mark Teicher <[email protected]> is an Internet and firewall security solutions consultant with over eight years of experience.

Rob What do you consider a secure environment?

Mark This could be a whole article in itself. Different environments require different definitions of a so-called "secure environment." Secure environments for an engineering firm are different from a military/government type of establishment. Engineering firms may require employees to wear name tags, and military/government establishments may require you to wear a name badge, including a picture ID, fingerprint, and color coding. This is just the tip of the iceberg for my definition of a secure environment or my consideration of a secure environment.

Everyone has an idea of what a secure environment should be, but that is based on what those people have observed in their work and what they see, what they hear, and what the industry is leading us to believe. In the business world, companies and industries define their own ideas of what is a secure environment. In defining a secure environment, one must consider the people, the hardware/software, the physical plan, and the underlying mission or business model of the company in order to clearly define what the company/industry requires in terms of a secure environment.

Most of my work over the last few years has been examining physical security. Physical security, in my mind, is where most of the inadequacies start. If a company wants to secure what is inside, but would like it to be convenient for employees to arrive and leave as they please, then compromises must be made. Regrettably, too many companies do not think about security until something traumatic happens (i.e., employee goes postal, a very high level person is let go, or someone who knows a lot about the company leaves). Security should be on the forefront of a company's mind, not just an afterthought.

There are risks at each level in trying to secure an environment. It ends up being about what you are trying to protect, from whom you want to protect it, what information you are trying to protect, and how much are you willing to invest to protect that information.

The one environment that I characterize as meeting my level of security requirements is probably Fort Knox, a high-level military installation protecting the gold supply of the United States. The vault room that holds most of the gold allows only a few select people in and out. Clearances must be sought and justified, security officers are informed, ID cards are marked, and on and on. Think about what they are trying to protect, how much they spend to protect it, and how they protect it. If people thought about what the military/government does to protect its gold supply, they might have a better idea of the scope of the security problem.

Char Wow! Talk about a broad question!

A secure environment is really a difficult thing to define. Not only that, but its definition varies based on security needs. An argument can be made that there is no such thing as a really secure environment. Instead, there are certain levels of risk, which we are all content to live with, within our own environments.

Of course, each person is unique, and each person has his or her own definition of a secure environment. Translating all of these definitions into a coherent policy to form one secure environment is bound to leave some people less than thrilled.

For example, let's look at Company A, a large multinational corporation that decides to launch an Internet initiative. Because many different departments are affected by this initiative, meetings are held and everyone provides input. In these meetings, various interests and concerns are voiced. These interests and concerns may range the entire spectrum of "nothing connects" to the other extreme of "everything connects." The final decision usually falls in the middle of the extremes; therefore, neither side is 100% happy or 100% disappointed. However, both sides must change their present policies to accommodate the new policy.

Enclaves within our environment can be made secure, but they, too, have to interface with the less secure. This is where issues of multiple levels of trust usually come into play. How do we deal with multilevels of trust and moving between these levels? In short, which path do we follow: risk avoidance or risk management?

The short answer is both. We don't take foolish risks (risk avoidance), but we may allow for some things we are not 100% comfortable with in order to simplify our lives.

For example, I'll use my house (because it's easy to understand and it drives my husband nuts whenever I use the house example). My house may be in most cases a protected environment. I have locks on the doors and windows, a canine alarm system, and the construction is pretty decent. The house has withstood some strong storms and some rather significant snowfalls. However, should a twister come by, maybe only certain sections (protected enclaves) of my house would end up intact.

The same concept applies to the business world. An entire entity is practically impossible to protect, especially in the case of large corporations. However, one can still have protected enclaves within the corporation.

Let's go back to Company A. Perhaps the payroll group is requesting absolutely no connectivity while R&D is requesting full open connectivity. Furthermore, suppose the compromise leads us to authenticated connectivity for specified services. Here we have a policy that is in the middle of the two extremes. The group that wants no connectivity may now want to purchase additional protections. The group that wanted full open connectivity may now find itself trying to "go around" the security controls. In a large business, this behavior is very difficult to control.

In the business world, the environment encompasses management, employees, the physical plant, all assets, and the interaction among these items (which would also include business processes). The "enclaves" are defined within the processes. Within the enclaves there exist management, employees, physical objects, logical objects, and interaction among these items. By examining not only objects but also the interaction between those objects, we are able to provide a systems approach to dealing with the issue.

A systems approach, when performed properly, should take into account all needs, and address not only all of the needs but also any interactions between objects. The whole picture must be examined and addressed. Addressing the security of these items to the acceptable level of risk is dependent upon the policies (defined in processes). Here is where some places use security matrices to assist in this process.

A security matrix requires the site to list all assets in one column and all of the risks associated with those items in the top row. Controls for each risk are numbered and defined outside of the matrix. Within the matrix, the controls associated with the risk are matched with the item and placed in the box.

Security matrices are a good tool to assist in this; however, there is a strong need for up-front planning in all aspects of security. The security matrix requires the planners to be aware of all of the potential risks. If the planners are unaware of a particular risk, then it will not make it onto the matrix; therefore, there is no way of being able to control the aforementioned risk. Additionally, these matrices require periodic reviewing and updating as new risks emerge. This is particularly true in the case of software, but certainly not limited to that area.

Good security planning is part of a design process. Unfortunately, this is an area that could use some improvement. TQM and some other quality programs were supposed to fix this, but I have yet to witness it. Quality programs concern themselves with the processes in place and rely on those to achieve quality. This is an inductive approach. Good security would demand both an inductive and deductive approach.

Unfortunately, my experience has shown me that, when faced with the cost of doing security right, many places balk and do a cost/benefit analysis without thoroughly addressing the risk analysis. The outcome then becomes one where security is compromised from the start. When this happens, you can be sure that political and financial concerns will win over security concerns. Of course, when an incident occurs, the business is willing to throw all sorts of money at the problem to make it go away. I call this the "stupidity tax."

A truly secure environment employs checks and balances for all processes and transactions in addition to using processes and procedures to minimize impact when breaches occur. That said, actually implementing a truly totally secure environment across a large organization is at best a difficult and complex task that is never static and darned near impossible to enforce.

Rob How do you go about evaluating all of the items listed above?

Mark Most organizations try to establish the ability of defining a single enterprisewide policy that integrates all aspects of network and physical security. Sometimes this a very hard scope in itself to define.

This type of evaluation takes on many challenges, taking into account the nature of the business model of that particular client, their working environment, their modes of communication, and so on Some of the initial steps include defining access control, authentication, connection control, auditing, enterprisewide management, and communication between departments.

Access control decides what people have access to what rooms and what devices and the level of access they have. Authentication means verifying that the user does indeed have access to hardware/software and the particular room and verifying that the user is who he or she claims to be (e.g., "show me your ID").

Connection control defines who has connections to what machines or what rooms within in particular environment. Auditing defines the level of accountability or alerts that one environment may have in place to detect an intruder or what people are actually doing within a particular environment. Enterprise-wide management defines who has what power to decide on a particular network/security policy and has the power to enforce it when things go awry. Communication between departments defines the channels of talkability or conversation across departments to ensure that one department is not doing something another department may be doing. All of the above listed items play into the role of evaluating a secure environment.

Char First, begin by asking, "What is it I am trying to accomplish here?" Otherwise, project scope will kill you. This first step is an iterative process when defining enclaves, components, and interactions within the environment.

Next, I'd ask how would I plan on getting from here to there based first on needs and then possibly address desires. "What tools (products) are available to assist in this journey?" Here is where a security consultant needs to look at the tools and ask, "How do these tools really work" (and not just reading the glossies or a matrix either)?

For example, let's take a look at firewalls. Datacomm did their throughput study, but they were not consistent in the comparisons. Throughput can be affected by the following: hardware capacity, speed of the line, operating system, and the efficiency of the actual software being tested. However, not all firewalls support the same platforms. Yet, when the testing was completed, Datacomm placed the results in a nice and pretty matrix. Information was reduced to a sound bite.

Once the knowledge of how the tools work is in place, you will move on to the question of why was the tool designed to work this way ­ which in turn should lead to a bunch of "what ifs."

For example, let's revisit our firewalls. Various firewall types were initially designed to address a set of security needs. As the industry changed, the firewalls began pulling on their designs without re-examining the basic foundations. Basic packet filtering firewalls became "stateful," and proxy firewalls began employing packet-filtering capabilities. A matrix will show that the major firewall vendors all offer proxying and packet filtering. However, if the site wishes to use packet filtering, the consultant's job would require that they provide a packet-filtering solution, not a proxy solution, which can be modified.

Firewalls are moving toward a middle ground of becoming hybrid, but I have not yet seen a "true" hybrid firewall emerge in the market. The funny thing is that a hybrid firewall makes a lot of sense because most sites security needs fall somewhere in the middle of the two extremes.

Rob What type of solutions do you provide or experience do you bring with you?

Mark Internet security and security itself comprise ever-evolving fields. Some new company is always claiming, "We can now protect your site better than our competitors" or "Buy our product and be secure on the Internet." If you really want to be secure, refer to Marcus Ranum's ultimate firewall (a pair of wirecutters).

In actuality, companies want Internet access and a secure environment. How do I give them that warm and fuzzy feeling? I talk with the customers and ask them about their business model: how their business is defined, the projections of growth in certain areas, the projections in network exposure, capability, growth, and redundancy. All these items factor in to a best fit, best product(s), best architecture, and best solutions concept. There are many different solutions and many different approaches in developing solutions.

Evaluating every approach or solution can be costly and very time-consuming, but I like to provide unique and feasible solutions and not vaporware. Usually about once a month, I evaluate some new vendors' products or check some of the various security mailing lists so I can give the customer many solutions but not very complicated ones.

Steve Bellovin and Bill Cheswick emphasize that one should never develop a security plan or policy that is very complicated. Try to keep things simple and logical, not overly complex. Having spent some time on both the development and users side of the house implementing what I helped develop, I found it quite enlightening that sometimes the integrity and coding of a firewall/Internet product can be scrutinized by a customer's vision of what a firewall/Internet product should do and shouldn't do. I attempt to alert them about the security implications of all the known variables and let them decide. Sometimes it works; sometimes it doesn't.

Char This is tough. It almost sounds like a chance to plug my employer's service line. Seriously, the experience of having installed 150 firewalls (most of them Gauntlet) and having to do some strange things in order to make the firewall fit the site's needs, along with the experience of coding, gives me a slightly different perspective.

Having spent time in the coding environment at large defense contractors, I know a few things about how code gets written. Too often, it is not a pretty process. I have also worked in the commercial world coding, and some of the practices there are even worse because there is no time for official reviews and walkthroughs. Coders will do whatever it takes to make something work; this generally does not translate into secure coding practices.

The same can be said for installers. Often when onsite, the customers may not have a complete understanding of how the firewall was designed to work. Once the firewall has been installed, the customers see firsthand how the security policy is being enforced. This sometimes conflicts with their perception of how the firewall should work, so they want the firewall configuration modified.

The best that I personally can supply is a working brain. By that, I mean most people search for criteria on something to understand how it is supposed to work. I balance that against the needs and provide a solution. When consulting, your first duty is to the customer (obviously), and the customer's first duty is to the business. Therefore, a good consultant will first try to understand the business, next the soft issues (personalities, political agendas, etc.) along with how they interact before making any recommendations.

Matching criteria without asking "how," "why," and "what if" is not a great model in the security world. Breaches in security occur when users (both invited and uninvited) start asking these same questions.

I am a strong proponent of good planning. Good, sound planning heads off many of these problems before they have a chance to happen. Additionally, good planning requires a good review cycle. The best plans need to be periodically updated.

Rob What problems have you found?

Mark The problems I encounter most frequently are political, management intervention, management cluefulness, and technical expertise. I think Char is going to tackle the political piece of this question. I will tackle the management intervention, management cluefulness, and technical expertise of this question.

Some of the installs and solutions I have provided over the years usually get blocked by management intervention. Management sometimes tries to step in during the installation or implementation of a firewall and Internet solution in order to keep their fingers in the pie. Management usually does not have the knowhow or care about where the solution is going to be installed, but usually cares about, "How is this going to affect my management team or budget?"

Recently, I installed a firewall and Internet solution where this did happen. Firewall and Internet solution were installed. We were installing a logging machine inside the firewall perimeter but ran into problems with management intervention of the "that should not go here or it will affect business" variety. Our logging machine was never installed, and we could no longer keep track of the traffic or audit trail of the firewall properly due to the incident.

This also brought out the notion of "management cluefulness" because management did not know enough of the technology to understand that auditing/logging is important for many reasons. Again, this also displays the example of how management simply did not have the expertise to fully understand how the installation/implementation would affect their life, but expected it to be a very simple affair, just like plugging in a kitchen appliance.

Char Many times, the problems I have encountered have been political. The person who is responsible for securing the environment knows all too well of the risks associated with the environment. However, if that person cannot convey this knowledge to management in the language that management understands, the security person's knowledge is worthless to the company. The company needs to hear about risks and costs associated with the risks. Simply explaining in detail a risk to a manager is not sufficient; he or she needs to hear the cost (financial and legal) associated with the particular risk along with the cost to mitigate that risk.

Another problem I have encountered is that in most of the places I have installed firewalls, the buying decision is usually not made by the person who works with the equipment. The buying decision comes from management and purchasing. If decision makers are not very technical, they can be taken in by aggressive marketing and end up forcing a product on the administrator.

When I was first installing firewalls, I used to say the criteria for a successful install is if the "big guy" can surf and read his email, he doesn't care about anything else. This is not entirely true. These are simply the yardsticks that make people feel good. Most managers are not going to run a port scan to see if the firewall is in. They want to know that business can resume.

The criteria for a successful firewall install unfortunately have nothing to do with security and everything to do with keeping a business functioning. The management does not want to hear that certain holes had to be punched into a firewall to make some of the other services work ­ that is until they buy some penetration services. Then they want to make sure they are 100% secure in the controlled environment against ISS, SATAN, or Ballista. In this case, they are testing to see if that $20,000 spent on securing the site will withstand a scan that the box was programmed to protect against anyway.

I find this thinking a bit shortsighted. If I had purchased a firewall for my site and I wanted to validate it, I would take a systems approach to evaluating it. This would involve inductive reasoning (attestation, validation, and verification) and deductive reasoning (scanning tools). To do one without the other lacks a certain completeness. I would want to examine the sources for the security code (under NDA, of course) and determine whether the code is security proactive or security reactive.

Security proactive code would be cleanly and simply coded in compliance with good coding practices. Variables would be checked, and there would be handlers for unexpected conditions. This code cannot only withstand known attacks, but would also be positioned to withstand many unknown attacks. (A good example of security proactive code would be smap/smapd. By allowing only certain commands, smap/smapd started with a proactive premise. A user who tried to issue a command that was not supported simply received an error response. Smap/smapd is now over three years old and has had some modifications, but the basic idea still works. During those three years, there have been problems found with sendmail, and many of them had no effect on smap/smapd. Now that is security proactive code!

On the other hand, security reactive code would be able to withstand known attacks. However, this code may not be in compliance with good coding practices. Unexpected conditions may result in a security problem (breach). This code would not be positioned to withstand unknown attacks. It may withstand them and it may not, a prediction cannot be made. (I will not give examples of security reactive code here because that could open up a whole can of worms; however, I think the readers can figure out what I am referring to by simply reversing the criteria in the prior paragraph.)

Finally, all of this needs to be done within the context of the business. I don't run a business; therefore, I don't have to worry about the bottom line. If I did, maybe I'd be a little more willing to go with some quick fixes.