Chunky chocolate chip. That’s the first thing that comes to mind when someone mentions cookies. Today’s article will contain two tips. The first is that you always use a glass that is wider than the cookie for dunking in milk; otherwise you’ll only have a small portion of the cookie dunkable at a time.

Now, on to the tip for which you’re probably reading this article. I’m sure that many people have read or heard opinions about cookies, how they are truly evil and can take over your life. There are a lot of free and inexpensive programs to eliminate or help control cookies, and the initial response when presented with an option to accept a cookie is usually not to do so. But what information are cookies actually gathering? Are cookies really dangerous? And the most important question is should you care?

The first thing to consider is what are valid uses of cookies.

When browsing to a web mail site such as Yahoo or Hotmail, a cookie can be used to remember your login name. This can save you the trouble of typing it in again. Cookies will also usually be used to store authentication information for a session. What this means is that while you are browsing back and forth in your web mail session, a cookie can make sure that you won’t have to trouble yourself typing in your password each time you go back and forth between viewing your list of emails, address book, and sending mail options.
When browsing to a news site, cookies can be used to keep track of the types of news that you prefer, so as to present you with your preferred types of news (sports, world, technology, etc) automatically.
Any time that a web site remembers something about you, it is probably a cookie that is enables it to do so.
Now that we’ve acknowledged that there are benevolent and theoretically useful reasons for using cookies, there are two major points that must also be considered before coming to a conclusion (other than the conclusion that chunky chocolate chip are the best kind).

Almost all functions that are associated with cookies can be replicated using other technologies. Cookies may be among the easiest ways to do things, but they are not absolutely necessary for a web site to function.
The grand majority of cookies that will end up on your computer will not be from the web sites (and servers) that you browse to.
Lets take an example. Having just enabled the option in my browser to ask every time a server attempts to save a cookie, I browsed to one of the sites on which I like to read IT news. Normally I set my browser to never accept cookies, so I was expecting to get one or two from the site (for my username and viewing preferences). Imagine my astonishment to get cookies from three servers that are in no way related to the site that I was browsing, in addition to two from that site.

Further investigation (viewing the source of the page in my browser, and looking up the companies who ran the servers that sent the cookies) yielded the fact that the advertising banners on the site were being pulled from other servers (run by marketing companies), and those servers were submitting the cookies.

Going back and forth to different pages within the site, and monitoring any addition to or query of the cookies in question revealed that the information of what pages and what banners I viewed and clicked was being sent back to the servers. Being as the cookies were stored on my computer, this also applied to any later times when I closed my browser, restarted it, and went back to the site.

How does this affect most people? The grand majority of the population probably doesn’t care. Marketing companies will continue to collect data about their online habits including browsing, shopping, and any other related activities, and it will probably never become apparent to them. For organizations with privacy policies or those people like me who feel that their privacy is violated, there are not very many things that can be done about it other than not to accept cookies. Some content filtering firewalls have the ability to strip cookies from any browsing, some personal firewall software packages claim to be able to only allow cookies that will not include personal information, but in the end the only thing that can ensure that cookies will not be used to violate your privacy is not to accept them.

For most sites, one can get by easily without having to accept any cookies. Approving cookies on a case-by-case basis will increase the amount of effort that a person will have to put into their online experience, and will probably be too much for most. One option available in the latest revision of some browsers is to only accept cookies from sites that are specifically browsed to, although that does not prevent the owners of these servers from collecting information about an individual. While organizations can implement technologies to enforce the security and privacy of users, what individuals do is up to them, and unfortunately we are once again witness to a situation where we see the conflict between security and ease of use.

Demilitarized zones, quarantine zones, sanitary zones, external protected zones, screened subnets. These are all terms used to describe a network that is somewhere between the wild west of the internet, and the (supposedly) safe firewalled network on which you will do most of your work.

The most common use of these zones is to position servers that will have to be accessed by both internal and external systems. Let us take an e-commerce web server as an example. Following are a list of the connectivity requirements and concerns for the web server:

People on the internet need to be able to connect to it (otherwise the company isn’t going to make any money).
It must be protected from the crackers who will try to attack it from the Internet.
The web server needs to be able to communicate with a database server that is located on another segment or in another zone.
The internal web team needs to be able to update the site.
The internal operations team needs to be able to manage the server.
The server must be protected from internal personnel with malicious intent.
What this means, is that somehow we have to separate the web server, the database server, the operations personnel, the web personnel, the rest of the organization, and the internet from each other, while still allowing them all to communicate in a limited manner. This may seem like it will take a lot of time and effort, but keep in mind that it only needs to be set up once. When planning for a new network, or migrating from an old architecture, setting up an architecture that will enable good segmentation practices and separation of duties will save you a lot of trouble later on.

The diagram below is one possible example of a network architecture that can apply to most small to medium sized networked environments – including the above example.
The first thing that I would like to point out is that this is a logical diagram. It doesn’t mean that I suggest a separate firewall for each internal zone, only that the zones be logically separated. A single firewall could act to separate all of the internal zones, although it will have to have a lot of network interfaces!

Security professionals will argue whether it is best to have one firewall (a good practice would be two firewalls in a failover configuration) to which all networks (or zones) connect, or whether there should be separate firewalls for each segment. Since I’m the one writing this tip, you get to read my opinions, but always remember that nobody is infallible, and not all situations and networks are the same.

If you want to go along with the exercise that I often use in courses that I teach, you can print a copy of that diagram, and prepare a bunch of post-it notes with the labels listed alphavetically below. If you don’t have the time or the post-it notes, then you can use your imagination. Each label will be placed into a zone, and in doing so we are going to set up an efficient and well segmented network.

Administration users
Authentication server
Bastion host
CVS server
Database server
DNS server (external)
DNS server (internal)
File server (general use)
File server for administrative personnel
File server for IS/IT department
File server for sales personnel
Groupware server
Internal DNS server
IS/IT system administrators
Log server
Mail server (antivirus relay)
Mail server (external relay)
Mail server (internal server)
Marketing users
Research and development users
Sales users
VPN server
Web design users
Web server

First, we will consider the servers that need to be accessible to the internet, and will not require regular updating or access to internal resources. These will be servers like external DNS or a bastion host. These can be placed in either of the screened subnets, or one of the DMZ zones. The important thing to note is that these servers are cut off from the rest of the network. There will likely be a firewall rule or router access control list preventing all access to them except for what is absolutely required. Administration of these servers will likely occur via SSH or another secure protocol.

The second DMZ zone will contain zervers that will require connectivity to one of the internal zones. The mail relay will have to connect to the mail antivirus server, internal mail, or groupware server. The web server will have to connect to the database server.The VPN server might need to connect to the internal authentication server. All of the servers will need to connect to the log server. I’m sure you can think of more..

On the internal networks, we have a series of firewalls (or interfaces into the same firewall) that will serve to separate all of the user and server groups. The first internal zone will be dedicated to servers that will be communicating to hosts in the DMZ we described in the last paragraph. Here we will have the internal mail server, the database server, the authentication server, the log server, and a few others. Note that there are no users in this zone. Users and server should always be separated.

The second internal zone will be used for servers that do not need external connectivity. The file server and CVS server are good examples. Keep in mind that the firewall rules protecting each zone will limit who and/or what will have access to each server from each other zone. The file server from internal zone 2 may need to contact the authentication server situated in internal zone 1, but should never initiate a connection to any host in a DMZ or external screened subnet. The firewall rules will ensure that this does not and can not happen.

We are now left with a few internal zones. We will use these zones for our user groups. System administrators and IS/IT personnel usually have no need to access marketing data, so we definitely won’t put the marketing file server into the IS/IT zone. IS/IT personnel will however be making regular user of their own file server, and might be transferring huge files (system images, and their MP3 collections) so in this case there might be a business case for placing the IS/IT file server in the same zone as the users. The firewall protecting this zone will be configured to prevent anyone from outside the zone from accessing this server. Now remember, this is only one possible scenario. All of the file servers could be placed in the internal zone 2, where the rest of the internal-use-only servers are located.

Being as technical people and sales people tend to have an inherrant disslike of each other, the sales and markettng department will also get their own zone, and that firewall will be configured to prevent remote control software from being used by the IS/IT personnel. This way, there can be no practical jokes played by one department on another. Is this starting to make sense?

So what happens when you run out of zones? The first option is to add another network card or interface to a firewall, and branch a zone off of that. Keep in mind that it is ver easy to add more zones, as the firewalls will probably (hopefully) be using a routing protocol to keep track of what IP addresses go where.

This last diagram depicts a network architecture of a very extensive internal network that has been expanded as described above.
Stay tuned for future tips where I’ll discuss virtual private networks (VPNs) how to link multiple internal zones over public untrusted networks, and the major issues that you’ll likely run into during your product selection and implementation.

One of the first areas of policy that gets considered from both a technical and administrative point of view is the type of authentication mechanisms to be put in place in an organization. From the policy perspective, one would want to ensure that that the IS/IT departments have sufficient support to ensure that they can enforce strong authentication. This raises the question of how strong should passwords be, and what types of policies should exist other than password strength?

First, one should consider the users. It is not reasonable to expect a user to remember a twenty character complex passphrase with letters, numbers, symbols, and control characters. Users will also be inclined to write down their passwords in easy to find places such as below their keyboards, or on post-it notes on their monitors.

Next, one must consider from a technological perspective, how difficult is it to brute-force or crack a password given sufficient information about it (such as a hash of the password). There are many different opinions on this matter, but most technologists will agree that the minimum safe password is eight characters, with a mixture of case, numbers, and symbols. A password of twelve or sixteen characters would be better, but again one must consider the users.

This leads us to policy #1:
Passwords must be a minimum of eight characters, and must contain at least one upper case character, one lower case character, one number, and one symbol.

Now that we have defined a basic password policy, there should be a series of supporting policies. Building off the common practice by users of placing their password on a post-it note, it would of course be best to disallow passwords from being written at all, but that can be very difficult to enforce.

A possible policy #2 could be:
A password must not be written or stored in a location (physical or logical) in which personnel other than the password owner have access.

Changing a password regularly is also a very important issue. If people were to keep the same password forever, then in the case where someone’s password was compromised, it would remain forever compromised. The life of a password is a cause for a lot of arguments in IS/IT environments. Users want to wait as long as they can before changing a password, as remembering something new can be difficult. Administrators would like new passwords to be issued or generated on a weekly basis, as that decreases the possibility that someone who has acquired a password could make use of it for any duration of time.

One of the more common durations for passwords is in the following sample policy:
All user passwords must be changed every 45 days. New passwords may not be the same as any previously used password.

The last consideration in this week’s tip is whether or not a password is enough to protect very sensitive or critical resources. In the area of authentication, mechanisms can be divided into three areas:

Something you know, which would be a password or pin number.
Something you have, such as a smart card or token.
Something you are, such as biometric thumbprints, iris scans, or voice signatures.
Multiple authentication mechanisms (often called multi-factor authentication) are a lot stronger than single factor authentication. In order to bypass or break into a multi-factor authenticated system, an attacker would have to both compromise a password, as well as physically steal a smart card or token, and/or cut off someone’s fingers.

A policy to support this could be:
All systems containing information that is classified as sensitive, and systems that are critical to business continuity must utilize strong multi-factor authentication systems.

The authentication section of a security policy should contain a lot more details about how passwords are stored, managed, how authentication systems should function, be audited, how logs should be stored, and many other factors. The four basic policies mentioned above are a good start, but you still have a long way to go before you have a complete policy.

Until recently, the term separation of duties has been associated to accounting and audit. Separation of duties means that one person’s work must serve as a complimentary check on another’s. Implied in this definition is the concept that no one person should have complete control over any transaction from initialization to completion.

Enter the world of information technology. Historically, the system administrator had full responsibility and privileges to act as he saw fit in maintaining stability, availability, integrity, and confidentiality of information systems. Today, those responsibilities are divided among system and security administrators, who report to IT and/or security managers. An experienced system administrator, and an experienced security administrator will often perform the same functions, but for different reasons. As an example, let us consider a new server installed with a default configuration. When asked what is the first thing one should with the server, both system and security administrators will usually reply, “patch the server, and shut down unused services”. The system administrator’s reasoning will be related to the allocation of resources (memory and processor time) from services that do not need to be running to important services. The security administrator’s reasoning will be related to the protection of the server as a whole – for every service that is running, there is at least one additional avenue of attack against that server. The same functions are undertaken, but for different reasoning.

The management personnel to whom the system and security administrators report will not necessarily have to understand the technological intricacies of what is being done, but will have to have a much greater understanding of the risk analysis and management processes. A risk analysis is an evaluation of the potential risks associated with a particular environment, the potential consequences, and an association of costs to both preventative and responsive measures. The information obtained through a properly effectuated risk analysis can be critical in assigning resources to the right situations. For example, let us consider one system that if damaged would cost the company $10,000 to recover from the incident. Preventative measures would cost the company $20,000 per year. The chances of this type of damage occurring are low, but can be expected to occur once per year. Based on pure costs, it makes more sense to spend $10,000 per year on recovery as opposed to $20,0000 per year on preventative measures. Unfortunately, risk management is not that simple. As part of the risk assessment, there will also be consequences to having one system damaged. There may be the possibility for a chain reaction in systems crashing, there may be a loss of reputation or value in the eyes of the public or shareholders if a system should go down, and there may be many more factors influencing the decision of how to manage this risk. IT and security management personnel must understand the risk assessment and management processes, and must be able to apply this understanding to their information technology environments in order to ensure that these environments are being protected and managed as efficiently, securely, and cost effectively as possible.

When a decision has to be made regarding implementing a security product or solution, there has been a lot of emphasis over the past year put into fully integrated products. If one must implement a firewall to protect internal resources, an intrusion detection system, a VPN to allow external users to access internal resources, and a proxy content filter to allow internal users to access the internet in a less risky manner, one has two methodologies to choose from.

The first method adheres to the principle of separation of duties, in that each function (firewall, VPN, IDS, and proxy) will be a separate product running on a separate platform or device. From a security perspective, each device has only the services running that are absolutely required for operation. The firewall will not allow user connections, the VPN will be protected by the firewall, and will only have a few select services running, the IDS will not be exposed to the internet, and will be manageable only from a trusted network, and the proxy will be on a separate network (often called a demilitarized zone or DMZ) and will have the sole function of handling user connections to the internet. From the risk management perspective, each device is independent of the others, and one failing will not significantly impact another beyond network availability (should the firewall fail). From the resource utilization perspective, this method will likely use more time for implementation, training, maintenance, and as there are four separate devices, it will probably cost more.

The second method, which violates the separation of duties principle, seems to be where many software and device vendors are gearing their products, in that a single device will be able to offer all the services that one wants. From a security perspective, this one device is going to be running many different services, and a compromise of one could lead to a compromise of the entire system. The firewall will (hopefully) be configured to protect all the other services, but the first step in (almost) every compromise is connecting to the system. As there will be services available to both the public and local users, that first step can be easily achieved. Another security consideration is the intrusion detection system. If it is located on the same device as the other services, should an attacker compromise the system, he would be capable of modifying logs and disabling the IDS from watching his future activities. From the resource utilization perspective, this method will likely be a lot simpler to manage, there will be an easy to use graphical interface to all the services, and a single administrator can be expected to gain a significant level of understanding of the system very quickly. A single device, even with multiple software services running on it, will probably be significantly less expensive that four separate devices and their respective software.

From the risk manager’s perspective, there are a lot of factors to consider in this scenario, and not all of them are technical. With one device, should there be a hardware failure, what recovery scenarios will be available? How difficult will it be to train personnel on using the system, and should said personnel leave the company, what would the cost be for training of new personnel? What are the risks associated to having one or more components of the solution hacked or compromised? What are the risks associated to having one or more components of the system brought down for a period of time? What are the recovery times for each of these scenarios?

I hope that these questions have provided you with an insight into the minds of system and security administrators and managers, and the challenges that they face in their jobs. In future articles, I will delve into the depths of the security mentality, and hope to give you a much greater understanding of the threats to today’s information systems.

Jeffrey Posluns is the founder of SecuritySage, a leading-edge information security and privacy consulting firm, where he provides information security management consulting services, and heads the company’s HYPERLINK “http://www.securitysage.com/guides” anti-spam group. Jeffrey has over twelve years experience specializing in information security auditing and technologies, and has extensive expertise in the analysis of hacker tools and techniques, intrusion detection, security policies, forensics, and incident response. Prior to SecuritySage, Jeffrey founded and co-founded several e-commerce and security initiatives, where he served as President and/or Chief Technology Officer. He holds the CISA, CISSP, ISSAP, ISSMP, SSCP, CCNP, and GSEC certifications, and is a trainer for the CISSP curriculum.

The phrase “separation of duties” is most often associated to the business practice of separating job functions among various individuals. Among other benefits, this can help prevent malicious actions from occurring and help catch those that do occur. The same theory can apply to information systems and servers. In the case of a Web server and e-commerce infrastructure, separation of duties can be critical to the integrity and protection of information.

A Web server is simply a computer that is set up with a process that will receive requests for Web content, and provide that content to the requestor. Integrated into that system can be software or additional processes to perform authentication, authorization and transaction processing.

Let us begin by considering authentication. When a user browses to a Web page and wants to identify him or herself, he must type in a username and password. The service or process that will store the list of usernames and passwords and tell the Web service whether the user’s credentials are correct should be very well protected. As we’ve seen in the past few years, there have been a fair number of attacks on Web services (like Microsoft IIS and Apache). If a Web service is attacked and compromised, and the authentication service is on the same server as the process that provides Web content, then the list of usernames and passwords could easily be stolen. If the authentication service is running on a separate server (not running a Web service), then an attacker would have to mount a second attack for a separate type of service. This adds additional requirements to the attack, which is likely to make it much more difficult to execute successfully.

Authorization controls will ensure that authenticated users can only access the information that is associated to their profiles or accounts. Authorization data will usually be stored in the same location as the resources that are going to be accessed. In the case of most Web services, the process that runs the service will have an account on the server. The default for this account is often the root, administrative, or system user account. In the case where an attack is successful against a Web service, if it is running as a privileged user, then the attacker (operating as the Web process) might be able to do a significant amount of damage to the system. If separation of duties is implemented properly, the Web service would run as a non-privileged user. In that case, should the service be attacked and compromised, the attacker will be able to do very little outside of the normal functions of the service. This means that the attacker could change Web pages (deface the site), but would have a much harder time making critical changes to the system, or manipulating authentication or authorization information outside the domain of the Web service.

Transaction processing systems are a requirement for electronic commerce. A user must be able to submit personal data such as billing or financial information; the server must be able to store and perform operations securely using this information. If separation of duties is enforced, the database where this information is stored should be on a separate system from the Web service. As in the situation of authentication information, this information should be very well protected. If customer data is located on the same system as the Web service, a compromise of one service can lead to a compromise of others.

The disadvantage of separating processes between servers is the additional cost associated with more hardware and increased time spent by system or network administrators on multiple systems. Any situation where there is more than one publicly available service running on a server should be very carefully evaluated, as separating the processes can increase the overall security of the implementation, but can add a lot of additional overhead.

One of the first areas of policy that gets considered from both a technical and administrative point of view is the type of authentication mechanisms to be put in place in an organization. From the policy perspective, one would want to ensure that that the IS/IT departments have sufficient support to ensure that they can enforce strong authentication. This raises the question of how strong should passwords be, and what types of policies should exist other than password strength?

First, one should consider the users. It is not reasonable to expect a user to remember a twenty character complex passphrase with letters, numbers, symbols, and control characters. Users will also be inclined to write down their passwords in easy to find places such as below their keyboards, or on post-it notes on their monitors.

Next, one must consider from a technological perspective, how difficult is it to brute-force or crack a password given sufficient information about it (such as a hash of the password). There are many different opinions on this matter, but most technologists will agree that the minimum safe password is eight characters, with a mixture of case, numbers, and symbols. A password of twelve or sixteen characters would be better, but again one must consider the users.

This leads us to policy #1:
Passwords must be a minimum of eight characters, and must contain at least one upper case character, one lower case character, one number, and one symbol.

Now that we have defined a basic password policy, there should be a series of supporting policies. Building off the common practice by users of placing their password on a post-it note, it would of course be best to disallow passwords from being written at all, but that can be very difficult to enforce.

A possible policy #2 could be:
A password must not be written or stored in a location (physical or logical) in which personnel other than the password owner have access.

Changing a password regularly is also a very important issue. If people were to keep the same password forever, then in the case where someone’s password was compromised, it would remain forever compromised. The life of a password is a cause for a lot of arguments in IS/IT environments. Users want to wait as long as they can before changing a password, as remembering something new can be difficult. Administrators would like new passwords to be issued or generated on a weekly basis, as that decreases the possibility that someone who has acquired a password could make use of it for any duration of time.

One of the more common durations for passwords is in the following sample policy:
All user passwords must be changed every 45 days. New passwords may not be the same as any previously used password.

The last consideration in this week’s tip is whether or not a password is enough to protect very sensitive or critical resources. In the area of authentication, mechanisms can be divided into three areas:

Something you know, which would be a password or pin number.
Something you have, such as a smart card or token.
Something you are, such as biometric thumbprints, iris scans, or voice signatures.
Multiple authentication mechanisms (often called multi-factor authentication) are a lot stronger than single factor authentication. In order to bypass or break into a multi-factor authenticated system, an attacker would have to both compromise a password, as well as physically steal a smart card or token, and/or cut off someone’s fingers.

A policy to support this could be:
All systems containing information that is classified as sensitive, and systems that are critical to business continuity must utilize strong multi-factor authentication systems.

The authentication section of a security policy should contain a lot more details about how passwords are stored, managed, how authentication systems should function, be audited, how logs should be stored, and many other factors. The four basic policies mentioned above are a good start, but you still have a long way to go before you have a complete policy.

Antivirus software is very much like a vaccine that you will have a doctor administer to you. You will receive a vaccine for a known sickness, which will usually prevent you from catching that particular sickness. Likewise, antivirus software will have a set of virus definitions. These definitions are for known viruses, and there are thousands of them. Whenever a new virus comes out, or is developed, antivirus vendors can take a few days (and sometimes even a few weeks) to put out a new set of virus definitions for your antivirus software. Until the new definitions are installed, your computer can be susceptible to that new virus.

Updating your antivirus software is as easy as clicking on the auto-update or live-update buttons in the software menus, or downloading an update file and executing it. Some products will schedule automatic updates for you, but it is always a good idea to manually run updates once a week. Remember that if you are downloading an update file manually, only download it from your vendor’s web site. Never trust an update file that has been emailed to you. Different vendors have different methods of updating their software and virus definitions, so consult your software documentation, instruction booklet, or technical support if you don’t know how to update yours.