The following is a transcription of the Enterprise Security Experiences conference session held April 29 at EMA'98 in Anaheim, California.

From a policy perspective, you've got management practice statements, security policy, and we could go on and on and on about that particular topic. Management—we are all familiar with the politics and the turf wars. But these can be real show stoppers.

We're not going to address physical security. I'm certainly not going to address it in the presentation that I have. I'm going to give you a little bit of background, talk about security policy, the scope for security in our network and our enterprise services. We'll talk about some considerations in business drivers and wrap up with some key points.

Our network is the Treasury Communications System or TCS. It is private and encrypted. It is one of the largest private networks in the world and reputed to be the second largest private network in the United States. It encompasses both voice and data. In terms of data, we have over 8,000 locations. We have locations in over 160 countries, because part of the Treasury Department is the Customs Service, so you can imagine the need to communicate with Customs Services in all the different countries that people travel to.

In terms of voice, we do our own voice on our network. So that poses a distinct set of problems as well. We have 14 business units, the largest of which has a population of 93,000 employees and the smallest of which is 300. So we run the real gamut.

We do have other clients, mostly government agencies. However, there are two components of the Treasury Department that have direct connections to other non-federal agencies. Those are the Office of the Comptroller of the Currency (OCC) and the Financial Management Service (FMS). They maintain direct connections to the fed for obvious reasons. FMS cuts all the U.S. government checks, and OCC has an awful lot to do with bank regulation.

It is a heterogeneous environment and technology. I like to say that if there is a product or a piece of hardware that has been manufactured, whether it is manufactured now or was manufactured 10 years ago, we've got it on our network. The management of our network is outsourced. At the very basic level, I'd say it would be a fair statement to say about 50 percent of it at the very basic level is done by us. But the overall network management is contracted out.

Policy and scope says it all as far as I'm concerned for my part of this panel. For effective, enforceable security, you've got to have adequate tools and well-designed flexible enforced policy. Now that is really hard to achieve, but it can be done. And sometimes you have to be prepared for the fact that it might take a couple of years to institute, but it can be done.

Let's be very frank here. I mean, all it takes is one security incident and you've got everybody's attention. At the Treasury, every business unit has to maintain a connection to the enterprise network. Connections to other networks have to be accredited and certified and firewalled. If a business unit wants to have a connection out of the norm, they have to go to the CIO and obtain a waiver. Part of their solution has to involve accreditation and certification.

Now there are a lot of valid reasons to have outside connections. The most obvious one that pops to mind as part of the Treasury Department is the Secret Service and ATF. Sometimes in the performance of their duties, they need to be able to do their job and not be identified as who they really are. They don't want to hide behind our domain name, treas.gov. So they are an exception to the rule. And we have to be able to support them.

Access to the Internet has to be through the accredited and certified border firewall process. For business units, approximately a third of them do opt for a second firewall on the inside of the border. They do this mainly to protect their information from the rest of Treasury because, let's be frank again, the greatest threat is from within. Somebody threw out a statistic the other day that 80 percent of the threat is from within your organization. I know it is very high. I can't speak from personal experience that it is 80 percent. It could be higher than that.

So quite a few of our business units either consider it, or have implemented their own firewall solution, and that poses some problems. There is no way in an organization of 220,000 employees that you can get everybody to agree on any particular product. So that involves a challenge in terms of interoperability and integration.

Then there is the old waiver process, which is always an option. Dial-in is supposed to be authenticated via hard or soft token. Now, with an organization of 220,000 people, there is no way you can control everybody and have had incidents where we discover connections that are not certified and accredited. When my office does find out about them, we shut them down, but sometimes you don't know about them until there is an incident. Again, it has to do with control.

It is very difficult to control an organization that size. We haven't had any major incidents yet, knock on wood, that we haven't detected in enough time. We're always finding some up-start engineer or computer systems administrator who thinks that he or she has got the system licked, and gets his or her own connection to the Internet or whatever. Sooner or later, they get found out, usually through something very simple like Domain Name System (DNS).

Some mail from point A to point B won't resolve. We'll start taking a look at it and we'll find a back door, and that is how we detect it. Every employee and contractor that works at the Department of the Treasury is cleared at least at the basic secret level and quite often at the top secret level. It depends on the data, and the equipment, and the environment that they come in contact with.

We do have an Internet access policy at the Treasury Department and we do have a messaging policy in place. Now what we do is we provide an umbrella policy. We say this is how you access the Internet. What we leave up to our particular business units is for them to refine that policy. I'll give you an example.

In terms of Internet access, the policy is that we have seven best practices and levels of guidance. Basically we provide Internet access to all of our business units. One of our business units has a very, very, very restrictive add on policy, whereby they have their own firewall at their location, and restrict access to individuals who actually need it. They must be authenticated at the firewall at their local location.

That gives them, they feel, the ultimate level of control. You can go to the other end of the extreme. Our very largest business unit is the IRS, and that is the 93,000 person organization. They have unrestricted access so they hog a lot of bandwidth. They all want to get on, and they all want to get on at the same time.

One of the articles was written by myself and I basically pointed out in the article what the Treasury policy was. If you remove the word Treasury and government, I mean, our policy could apply to a lot of private sector organizations. As a matter of fact, that is what it was modeled after.

Another item that is very important is standards compliance. It makes things easier. There is no doubt about that. Some of the things that we look for are real directory services, X.509 version 3 support, and those types of things. You'll hear about some of these topics more specifically from some of the speakers on the panel.

Minimum encryption on our network in terms of security is to the tail circuit. Encryption of the tail circuit is at the option of the business unit. The more paranoid they are, the more they encrypt. We are a 24 x 7 operation and we have a guaranteed 99.997 percent availability on our network. Sometimes we don't reach that, but it's black and white on paper.

We do have service level agreements in place and there are penalties for not meeting the service level agreement on the part of the contractor. There are awards for exceeding the service level agreement. This is something that some of you that don't have these in place may want to think about, especially if you out source any kind of support that has to do with security, certificate authority, firewalls, Internet access, etc.

In terms of intrusion detection, we are in the process this year of putting in different kinds of intrusion detection. We do have automated intrusion detection software that comes from the vendor that manufactures the firewalls that we use at the border level. We do use off-the-shelf tools and proprietary tools. By proprietary, that could be anything from a script that we've written or that we've gotten from another organization.

We do have announced and unannounced attacks on the network. I'm sure there are a lot of attacks that we don't know about also. Another statistic that was thrown out at one of the sessions that I attended yesterday was that 99 percent of the intrusions on your network you never know about. I really wouldn't dispute that.

In a network our size, it is very, very difficult to monitor every single thing. There is only a staff of 22 people that performs this function on the enterprise level for our network. Now each one of our business units has their own Network Operations Center (NOC) and their own staff to do things of that nature. But, as you can imagine, with a network that large, the scope is daunting.

In terms of war stories, yes, we've been spammed. We've been spoofed. We've had denial of service attacks. The two most popular targets are the IRS and the ATF, as you might imagine. I found out a couple of weeks ago that somebody from our Public Affairs office wanted to register the domain name of treas.com. Since I'm the technical point of contact on the Internet, I looked it up and found out that it is an anti-IRS website. There is all sorts of interesting garbage on that website. Of course, you know, we can't get to the domain name now.

There are all sorts of other attacks. What we do is we have a security escalation team at the Treasury Department. We have what I call technoweenies or technocrats that work for me or support the team that I manage. We also use agents and inspectors. These are the guys that carry the guns and the badges.

The reason that we use these guys as part of our team is that there is federal legislation that prohibits somebody from attacking a government network or computer system and preventing the government from doing its job. That's not just a misdemeanor, its a felony and you can go to jail for that.

If we are attacked and we find the source of the attack, which is very difficult with spamming and spoofing, we go after them legally. We work with the Department of Justice Computer Crime Unit and we go after the people. They can seize the equipment and they can arrest attackers.

Our core enterprise service is our messaging backbone, which is a dual protocol backbone, public and private directory services. When the public directory is fully populated, this is going to pose some challenges. None of our business units want to publish their e-mail addresses on the public side for obvious reasons.

None of them want to publish their names on the outside for obvious reasons. So what we're going to is a positional standpoint. I won't be on the public side as Michele Rubenstein, but my position, Director of Electronic Messaging, would be listed. There might also be an e-mail address that is what I call positional, as opposed to by name. If somebody sends a message, there will be a mailbox that I'll have to check.

I was out of the country for six days last month where I didn't bring my computer. I didn't want to check my e-mail. When I came back, I had 1,843 messages. I don't want to add to that by having my e-mail address publicly held on the public directory. Private directory is different. I mean, there are people for legitimate reasons within the Department of Treasury that need to contact me.

Border firewalls: We have a lot of lessons learned from the attacks that we've had. It is really kind of interesting. We do a lot of auditing on our firewalls. We know where people have been and where they haven't been. They leave with cookies and everything else. People don't think sometimes. Even when they go out legitimately with forms filled out, their e-mail addresses are captured. All of a sudden people are starting to get a lot of junk mail.

I'm not just talking about from Hustler or Playboy, those sites are blocked, I'm talking about from other sites. To give you an example, HotMail. You can get free e-mail from HotMail. If you go out somewhere and HotMail has sold a list that has your name on it, anybody that wants to send a mass mailing which could fill your mailbox over the course of a week. That is a problem. If you're going to connect to the Internet, you've got to consider that.

Route DNS for Treasury—we manage that. We have an electronic commerce clearinghouse. The main idea behind it is we will pump any protocol in and be able to pump any protocol out. That is in support of mostly the electronic commerce initiatives. Certificate authority services, I think, the gentlemen on the panel are going to be discussing that. If there are any specific questions, we can cover that at the end of the panel and web server housing.

Lastly, just a reminder to everybody that security is not an illusion. It takes team work. You've got to get buy-in from the top. If you don't get buy-in from the top, it is not enforceable. Now, I'd like to turn the program over to Steve.

Most people realize that Lockheed Martin is a leader in satellite, missile, space, and military aircraft products, but few realize the commercial side of our corporation. We are involved in remediation of toxic sites; tracking and collection of dead beat dads, parking ticket collections, automated toll collection, commercial satellite operations, and cellular telecommunications. Our commercial arm continues to grow. What do all of these products and services from Lockheed Martin have in common? It is the need for security in all aspects of their Information Technology (IT) environment.

While any company can start by looking at what security requirements they have in general it is almost more critical to develop a security strategy in terms of the overall IT Enterprise Architecture. The security architecture is a critical component of this overall architecture. The overall enterprise architecture is driven from the business, as well as the economic environment and other factors. The business drivers along with these other factors leads to development of the IT architecture and eventually its standards, processes, and policies/procedures. While difficult to create an overall corporate IT architecture for a business, this size is seen as something vital to IT environments since it provides continuity, cost effectiveness, and cohesiveness. All operating companies are responsible for their own IT strategic plan, long range plans and other IT related documents which become input to the IT architecture. There is a review board that reviews all architectural changes, new and proposed standards, major initiatives, and potential IT architecture impacts.

People working together generating requirements, policies, and working projects is the key to the architecture and the overall security architecture. People drive the policy, and this is what the security organization addresses. In the following diagram the IT Architectural Framework is depicted with the security component expanded. In addition, there is a diagram covering some of the security organization responsibilities.

The security architecture is multi-layered covering the areas identified in the previous chart. In the diagram below one can see these layers and their corresponding areas of coverage. This architecture stops penetrations at a series of points within the overall IT infrastructure, thus providing stability to the global IT environment. While covering the obvious security issues such as firewalls, dial-in, and remote connectivity, it also covers encryption, compliance testing, and applications.

In this next diagram, a step more deeply into the security architecture, one can see the X.500 directory services component. While LDAP plays a key role at local sites the X.500 directory services plays a critical role at the corporate level of IT infrastructure components. The X.500 services are being designed to handle X.509 certificates along with other vital information about services and staff. This information is critical to security integrity. In addition to the directory services, the virus servers, firewalls, and remote access servers are shown.

As part of the overall security design we have encrypted point-to-point external data path encryption this secures data and information from site to site. Different sites go through a backbone and get encrypted from different spots. They go through hubs that are located in various locations around the country. The following diagram is a generic view of our firewall set-up. Notice these proxy servers, shown on the bottom, today each one of these is doing roughly 225,000 transactions per hour. This site firewall set up is distributed in three different sites; cumulatively we are looking at over 1.5M transactions per hour at peak. A dotted line across the middle depicts the demilitarized zone, say the boundaries between external and internal. You can see more or less a mirrored image between these two. We are using access cards for remote support; the server for this function is shown in this diagram. Each one of these security layers and its corresponding component was validated against current and planned requirements. Each selection once approved goes through a rigorous set of testing procedures.

In addition to the 3-layered security architecture we also have a three-tier virus protection that goes from firewall into the server and to the client. We have a corporate wide contract established for that software. As most have seen through articles or other presentations, Lockheed Martin has standardized on Microsoft Exchange (over 80,000 people deployed), but our corporate level architecture is comprised of DEC Alpha systems and related software which provides seamless integration between Exchange and other messaging, security, and application components. Currently in development is the hierarchy of the certificate authority. In our set-up, there is the root going to issuing servers, the secure socket layer, transmission going through the various servers. Note that we have application servers and program servers then right through and on into the clients.

When developing a security strategy, two areas that need to be considered are fingerprints for authentication and voice. These two areas of biometric technology may impact today's practices in the not so distant future. Smart cards are also getting a lot of publicity as well (both positive and negative). Regardless of bad or good the usage of these devices continues to grow, mainly in Europe. While still looking into the future for our security goal of single sign-on, and universal access, our approach is to stay very tactical using the leading edge technologies very selectively. The concept of limited exposure.

Cultural issues exist. When you come into mergers and acquisitions of companies it is often difficult to determine who is in charge of what. Sourcing is extremely critical, especially for a large corporation. A good example is Virtual Private Network (VPN) technology, testing has been occurring for some time, but when applied to our environment the claims of vendors often do not apply.

We have found that after serious planning, evaluation, approval and testing that a pilot along with a slow roll out are key for any new software or hardware. Heterogeneity and change are the few things that we can be assured of in a large corporation. Be aware of those limits. We get calls from vendors asking, well, what desktops do you have? I have easy answers: we have everything. He said, what protocols? Yes. We cover everything. That is reality.

We do have policies that cover audits, event detection, off-line auditing, and attack simulation, something that was mentioned earlier.

There is much work going on in the security arena with the IETF, within the government, and in vendor research labs. New versions come out continuously of software and hardware. The security organization has the authority to perform internal attacks and monitor traffic in order to meet company policies and protect corporate information. This was similar to others on the panel. In addition to commercially available security tools, we have written several of our own. The key thing to recognize is that just implementing the security controls is only part of the task, verification is required to complete the process. A consistent internal and external approach is required. This is one of those key points that receives funding because management realizes that a security architecture plan that covers the enterprise is not only critical, but is mandatory. Therefore, all those operating companies—those 700 sites—do have an integrated approach to the security.

I can't stress how important it is to create an architecture that stems from the top down when it comes to security, as opposed to letting everybody do their own thing. A robust security strategy is key to handling things such as the Internet, the web, and electronic commerce.

Challenges are numerous and come from all areas including:

1. Export controls—being an international company, just moving a lap top to another country to establish a secure conference between where our office is there and here is a tremendous problem. Encryption is included in this arena.
2. The auditing problems with Dynamic Host Configuration Protocol (DHCP).
3. What to do about Java and ActiveX?
4. Multi-media is extremely difficult to deal with on the security aspect, let alone the network aspect. Through all these challenges the security organization and those involved throughout the corporation with this challenge are meeting the requirements generated by our business needs. Security is not a technology that is rapidly deployed after just being announced, it one which requires a complete and thorough understanding. Thank you for your time.

I'm going to describe a little bit of background, outline the security vision, then take you through a very high level architecture. Then John gets the hard part about talking about the real world messaging implications of this sort of security architecture.

In terms of the security industry, a couple of the things are happening#151;there is a rush to move to the Internet and to move all the connections with our business partners, our customers, and within our branches. There is the perception that it is a good thing. We're moving to it quickly. Because of that, there are a number of solutions that we've readily adopted.

The most pervasive, though, is e-mail. Certainly there is a lot of interest in e-mail from our customers, particularly the retail customers. So we're grappling with how to deal with that on a very large scale. The firms that are members of the securities industry want to interoperate and would like to use the Internet. So we're trying to develop some standards that use Internet protocols and use certificate authority and digital certificate kinds of technologies in order to provide that in a secure way.

So we took those drivers and began to think about how could we distill a security vision. We've got the luxury now of having businesses interested in partnering with us. There is plenty of money to rush headlong into the Internet. One of the approaches my team has taken is to try to add value to the business transaction and make security a differentiator or at least an enabler. Does it better control something? This permits you to do new things that you couldn't do before and try to make paper and manual processes go away.

So this information security strategy is, at least for my counterparts in the industry, pretty similar. There is nothing here that is radical. But what is interesting, at least in terms of our security philosophy, is that there are so many of these elements that are touched by a public key infrastructure.

Notably, the e-mail part would utilize the underlying infrastructure services to do things like file encryption or S/MIME, automate business processes with electronic forms where the authentication of the user is essential, file encryption or file signing as a useful protection mechanism. Obviously, the Security Service Layer (SSL) kinds of things for browsers, and then a generic Application Program Interface (API) for enabling applications to begin to move towards single sign-on. I love the expression reduce sign-on. I've got to pick that one up, because I don't think we'll ever get to a single.

Another thing that is interesting is that the hard part is in the middle of the graphic. The directory and the public key stuff is fairly mature, or at least it is more mature than the authorization and entitlement components. So what we're trying to do is wrestle with how to pull all of that together and expose it as a layer.

Now [the next] graphic is a functional organization of how an information security officer might structure a group. The pieces that I'm interested in showing you is just how many of them interact with either messaging or messaging-like components. An example is a secure directory under of application security. We've worked with John's team on trying to expose different views of the directory and John has some examples of how far we've come along in that area.

We're becoming firewall experts, far more than we would perhaps like to be. What is interesting is that there is, you know, a necessary e-mail firewall. Again, John has some comments about that. So, without further ado, here is John Marshall.

So hopefully, at the end of this, what we'll have achieved is some level of understanding about the degree of cooperation needed between the security and messaging functions, and also focus a lot less on the technology, but more on the process.

There is certainly plenty here that will have been talked about before in other areas, but I guess I need to just reference the fact that certainly in an information intense business such as ours, e-mail surveillance and policy around use of e-mail is critically important. So much of what we do as a business is around information that is incredibly time-sensitive that this is a critical function.

The only thing I would add is that it is a good idea to have a policy. An even better idea is to be able to communicate it. Just one slight off the cuff idea about how to communicate this policy is we actually had our CEO have this policy stapled to everybody's payslips one month.

I think if you think about what that says, you know, payslip, e-mail policy, get paycheck, and follow e-mail policy. The other thing that we have stressed is that there is no right to privacy for information on the company's computer systems or through the company's computer systems. That is a distinct part of the policy, which we have made mandatory.

Now as a part of being able to implement this, we have a set up enabling us to do a little verification of actually what is going in and out of our firm. To give you an idea of the needle in a haystack problem here, we're talking about 50-80,000 messages a day and 10 gigabytes of data.

You need to focus on a trusted business process to know who are other people that should be using your facilities. What I would suggest is that really one of the main mainstays of security is a trusted business process around who should have access to your computer facilities, either within the firm or on the road, and all the various systems within that.

A little one-liner I was trying to create earlier goes something like this. There is nothing as dangerous as having a highly secure, fault-tolerant, reliable, managed, encrypted connectivity over a trusted link to a disgruntled ex-contractor. So what I would like to suggest, and something that we have actually managed to implement, is the concept of a unique identifier.

I would suggest that the characteristics of a unique identifier for everybody within your enterprise should be something on the lines of global relevance. It should be fully unique. It should follow that employee, consultant or temp from cradle-to-grave. It should be able to be published. Another characteristic of this identifier is that it should be driven by a highly critical process that everybody cares about. What I would suggest is called payroll. Now what are the benefits of doing this? Well, what I'm going to try and demonstrate in the next couple of slides is that you've got a huge domino effect of benefits based on the fact you can automate a lot of stuff.

So if you know that somebody has joined the firm, somebody has exited from the firm, you just hired a new contractor, you've just got a new temp in, the temp has disappeared, the contractor is gone, then all sorts of stuff can flow from there without human involvement. You don't want to hire a whole bunch of data base administrators or directory administrators and all that kind of stuff—once you have that process authenticated and automated throughout.

Links to physical security—I'll explain things like picture ID's, which physical security people do very well, can now be linked to your directory through this unique identifier. You can provide an audit trail of who did what when.

You have the starting of, as Ted mentioned earlier, a reduced sign-on. What we've actually managed to achieve is that we have a standardized client/server mechanism throughout the firm, which is the primary office automation computer vehicle, that a sign-in is the same and linked to your e-mail set up so that we can actually tell when you logged on this machine in this country, that location, on that Internet Protocol (IP) address, using that ID. That is also the same as your ID. if you logged in over a dial-up connection. We can actually trace your activities through the firm based back to that single ID.

The other thing it buys you is the ability to actually do directory synchronization. Not a whole lot of people's hands went up when we asked how many had a single directory. Therefore, you're all in the business of directory synchronization. Unless you have a unique identifier to do directory synch, you're in the business of finding another means of doing directory synch, normally around a unique name, which is normally a little difficult.

So, again, I would suggest the unique identifier have some critical components here. Here is one of the ideas that we developed using this concept. We have a client/server e-mail system throughout the firm. What I don't have is a lot of people setting up client/server accounts. What I do have is a knowledge of the fact that somebody joined the firm because through that trusted business process, I now have information about that employee through the unique identifier.

What I've now been able to do is automate account creation down to the guy who is setting up that new person's computer. I know about this person because directory information came through the trusted business process and is there when somebody joins the first day.

Now all I have to do is just say I want to create an account for this person. Done. The whole thing flows through. I don't have a central administration function of setting up e-mail accounts. I distributed that out to all the people who are close to the employees as they join. Therefore accounts get set up without a lot of central activity.

This is just really one example of how once you have this trusted business process, you can then automate and get out of the low value added business of administration. The other thing I just want to mention is, given the fact we have, again, that unique identifier we then hook into all sorts of other data.

We have information from the telephone operators and all sorts of other information. We then package this together and call it our directory system. We can then synchronize in all sorts of different places. You also get into a self-cleaning cycle. Because this thing is now the way that everybody finds information for the firm, then people have an incentive to get this right.

So if your location is wrong, if your phone number is wrong, if your fax number is wrong, you have a process to get it cleaned. Since everybody is using this, there is an incentive to constantly clean the data and get it better. This thing is on pretty much everybody's desktops in the firm. It is used 30,000 times a day and the information is pretty much 100 percent accurate. We don't publish paper directories any more. It is all electronic.

What this all really comes back down to is that there is really a combination of requirements here from a need to generate and provide a trusted information process around HR, physical security, which is that top layer, and the administrative organization, which doesn't have to be a centralized administrative organization. You can automate that and distribute it through the organization at appropriate levels.

You can then enable your directory and security management at the middle layer and down the bottom you then have the combination of security enabled applications and the best of all worlds—if you can have educated and enabled end-users. Thank you very much.

It is an order that has its headquarters at the ruins at the Temple of Salomon in Jerusalem. They take their name from that and call themselves the Knights Templar. The Knights Templar had a need that they filled during the Crusades.

That is, as Crusaders started out from Western Europe and they made their trek across Europe to the Middle East. They had to find a way of safely transporting their valuables, because as they made that long journey, there would be highwaymen along the way who would beat and rob them. In addition, some of their own fellow crusaders were less than honorable people.

What they would do is they would go to a Knights Templar fortress outside of Paris. Crusaders would deposit their valuables with these Knights Templar. The representative there would give a coded message to the crusader, and the crusader would take this coded message and when they arrived in Jerusalem, they would present that to a representative at the Knights Templar there. They would decode the message and give the crusader their funds minus a certain percentage for expenses.

This came to be a very lucrative profession for the Knights Templar. They, of course, were beyond reproach because they took the Catholic vows of the priesthood, which were of chastity and poverty. But it was nonetheless very lucrative for the order, because they took percentages of each one of these transactions, that took place as the crusaders deposited their valuables.

The Knights Templar branched off into other forms of commerce, protecting the routes and the crusaders along these routes. They set international exchange rates. They set monetary policy, because they determined the amount of gold that would be set in the coinage of many of the kingdoms in Europe at that time.

In fact, one might say that these Knight Templars performed many of the same types of functions that we associate with a modern central bank, such as the Federal Reserve. The Knights Templar thrived for approximately 200 years until there was a monarch that rose to power in France named Philip the IV. Philip the Fair he was called, because he was said to be the most handsome man in all the world.

Well, handsome or not, he also happened to be one of the most greedy men in all the world, because he had an insatiable appetite for military conquests and a lavish court lifestyle. So Philip the Fair had a campaign in which he systematically began defrauding his people. The first thing he did was he reduced the amount of gold in the coinage, and then he set about having a high taxation against the Lombard merchants, and issued a program of the Jews in which he robbed them of their possessions and drove them from France.

Yet this was not enough for him. The last group that he chose to pick on was the most powerful group of all, the Knights Templar. He trumped all sorts of outlandish charges against them and, at a moment of his choosing, he stormed this bastion outside of Paris, took the Knights Templar out, and burned them all at the stake.

A few years later, the Pope was forced to renounce this order because he wanted to keep peace within the Catholic Kingdom.

So why have I told you this fantastic story of the Knights Templar? What does that have to do with Public Key Infrastructure (PKI)? Well, like the Knights Templar, the Federal Reserve Bank of New York has a very important function which serves in today's monetary system.

We have certain missions that we perform which are crucial to the U.S. banking system and, I would argue, the international banking system at large. For example, we execute monetary policy for the Federal Reserve. Every six weeks, the Federal Reserve makes the headlines because they make the decision on interest rates. Well, the execution of whatever rate they set gets done by the Federal Reserve Bank of New York.

A second, very crucial mission that we perform is we do the foreign exchange rate intervention. So if the dollar needs to be propped up against the Deutsche Mark, or the Yen, we are the people who actually do that.

The third thing that the Federal Reserve Bank of New York does, which is very crucial to the U.S. banking system, is we do supervisory policy for the banks. Since New York is the financial center of the world, many of the major banks are in New York.

Now we take security very seriously at the Federal Reserve Bank of New York. Like other businesses, we're looking at providing applications on access through both the intranet and Internet because we provide many banking services. You might imagine that I enjoy history and I'll tell you one more historical analogy of the civil war.

It was in a particular battle when a General James Longstreet arrived on the scene. He came up with his plan for attack. He told all of his division commanders. As they were getting ready to leave, he said, wait. I'm going to tell you one other thing. This is apt advice for IT managers. That is why I pass it along to you. He said, don't attack until you are ready, and when you are ready, strike hard and fast. You should do the same thing when you're developing your Internet strategy.

So at the Federal Reserve Bank of New York, one of the things that we did was we formed a strategy task force known as the I*net solutions task force. I*net looks at both the Internet and intranet. So it was formed on the basis of what is it that we wanted to do using this new medium? What services did we want to provide and what were the security requirements?

Well, there are the traditional security requirements, which every security officer knows. That is, you need to have confidentiality. You need to have message integrity. You need to have continuity of operations. Now how do these particular security requirements manifest themselves in a PKI?

Well, first off, with digital signatures, you can provide for non-repudiation and message integrity. You can use encryption to provide for confidentiality. You can architect your system in such a way as to provide continuity of operations so that you have fail over systems.

So we did that. One of the things we did was we crafted a certification policy statement, a certification practices statement (CPS), which detailed what the technical controls that we would employ when using our certification authority (CA). We also architected what our network would look like in terms of how the directory would be positioned, how access control would be handled using X.509 certificates, how you would access mainframe legacy applications using this new technology of X.509 certificates.

What kind of policies would you have in place for proofing people? What kind of key escrow mechanisms would you use? We, for example, decided that we were going to use smart cards. We made that decision because, (1) it provided a second factor of authentication, and, (2) it helped guard against software-based attacks.

So smart cards became an integral part of our PKI as well. We looked at some of the applications. Some of the applications involve sensitive data in accordance with the missions that I told you about. But there are other things that we want to do as well, such as secure e-mail and secure web forms processing.

In my particular area, I am in charge of security. So whenever anyone needs access to mainframe applications, they fill out a paper form and they walk it over to our area, and we process that form by sending in the commands to the mainframe. So if we can do that electronically, where they just access a web form and they put a digital signature on it, and we have full autobility on the back-end side, then it makes it much easier. It becomes an issue of faster processing and better customer acceptance.

It is something that we take very seriously within our bank, because we want to provide service to our internal customers of the bank. So that, in a nutshell, is what we're doing at the Federal Reserve Bank of New York. As I said, we take security very seriously because, if we don't, because of our position in the international financial community, we may find ourselves like those Templars of old being taken out and burned at the stake. I thank you for your time this afternoon, and I'll turn it back over to Michele.