Strategies for a secure Network

Strategies for a secure Network: ­

Before you can decide on how to safeguard your network, you must identify what level of security you require, i.e. whether you want a lower, medium or a very tight security. (For example, famous personalities will require more life security - Y level, Z level etc., than a common man,) Once this job is done, you are ready to make your strategies to secure your network.

The various strategies used further to secure the network will include the following:

1. Host security - securing the prime, host machines by logically isolating them. In most situations, the network is not the resource at risk rather, it is the endpoints of the network that are threatened. Usually, there are bugs in the program for networks or in the administration of the system. it is this way with computer security, the attacker just has to win once. But networked machines are also not isolated. There are other machines which trust them in some fashion. It might re therefore a major risk that the intruder can compromise the entire system. He will now be able to attack other systems, either by taking over root, and hence the system's identity, or by taking over some user account. This is called transitive trust.

2. Authentication of users - checking the identity of valid users keeping the unauthorized users away.

3. Choosing good passwords & protecting them - A good password should be developed using various criteria & safeguarding it as well. Also making sure it is not reused & changed frequently.

4. Using firewalls & proxy servers while accessing Internet - using these tools to act like logical security guards to monitor traffic in & out of your local network (protected) & the Internet (unprotected). A Firewall is defined as a collection of components placed between two networks that collectively have the following properties:
1. All Traffic from inside to outside, and vice-versa must pass through the firewall.
2. Only authorized traffic as defined by the local security policy, will be allowed to pass.
3. The firewall itself is immune to penetration.

The reason that a firewall is more secure is simply

a.    It is not a general purpose host i.e. login, NIS are not necessary there.

b.    It gives professional administration.

c.    It is designed for the job.It has no normal users. So there is no passwords and associated risks. Without users, arbitrary changes can be made so that it would help security, without annoying a population of users.

DMZ's: (Demilitarized Zones):

Some servers are difficult to trust because of the size and the complexity of the code they run. Web servers for an example. If we place Web server inside the firewall then a compromise creates a launch point for further attacks on inside machines. If you place it outside, then you make it even easier to attack. The common approach is therefore to create a demilitarized zone (DMZ) between two firewalls.

A DMZ is an example of general philosophy of defense in depth. That is multiple layers of security always provide better shield. If an attacker penetrates past the first firewall he or she gains access to the DMZ, but not necessarily to the internal network. Without the DMZ, the first successful penetration could result in a more serious compromise.

5. Making use of Encryption techniques - used to encrypt the sensitive information to be sent out, making it harder to crack if intercepted. Involves using various algorithm based on the Data Encryption Standard for this purpose. Encryption is often considered as the ultimate weapon in, the computer security wars. It is a valuable tool but if used improperly it can hurt the real goals of the organization. Encryption is best used to safeguard file transmission, rather than file storage, especially if the encryption key is generated from a typed password. There are various encryption techniques like the Conventional Symmetric and Unconventional Asymmetric ones. The Asymmetric Encryption techniques use the Public/Private key concept. But even these have to be safeguarded from the potential attacker.

1.8 Ethics of Computer security: ­

While we are applying ourselves to keep our assets protected & secured, we must consider the ethics of computer security. These are the morals / principles to be followed while using computer security aspects. There may be several issues of security policy that may affect individuals outside the organization, even though the policy is formed for the organization. Also the consideration to the privacy of the individual should be made.

The ethical issues say even further that there is no harm in monitoring our own systems & equipments and that the counterattacking on the attacker is also possible in self-defense. In short, so long as we stay within the frame of law, computer security is ethical.

1. In a technological era, computer security is fundamental to individual privacy. A great deal of personal information is stored on computers. If these computers are not safe prying eyes, neither is the data they hold. Worse yet, some of the most sensitive data-credit histories, bank balances, and the like-lives on machines attached to very large networks.

2. Computer security is a matter of good manners. If people want to be left alone, they should be.

3. More and more modem society depends on computers, and on the integrity of the programs and data they contain. These range from obvious (financial industry) to the telephone industry controlled by network of computers to the life critical (medical devices). The problems caused by bugs in such systems can be devastating.

1.9 Security threats & levels:

There are various ways & means in which threats can be given to the security. Generally, the two main levels in which threats can be given to the system security are:

1. Inside attacks: Studies have shown that around 70% of the attacks come from someone within the organization or someone with inside information. This is because the insider has a better knowledge of your system's functioning & hence it is easier to attack. These may be either ex-employees or unsatisfied employees.

2. Attacks from outside: The outsiders who would attack your security may be either your competitors (desperately needing the sensitive internal information of your organization) or someone just making fun or trying out their luck or experimenting by disturbing your systems without any special reasons.

In general the natures of threats to the system security are found as:

(a) Threat to Availability - Information is not available whenever demanded.

(b) Threat to Integrity - someone has deliberately tampered the Information.

(c) Threat to Confidentiality - Information illegally accessed by someone.

(d) Threat to Authentication - Valid user identity is penetrated.

Levels of Security.

What does it mean for something to be "more sensitive" than something else?

We will use a somewhat simplified description of the U.S. Department of Defense (DoD) definitions of levels of security as an example.

It is a reasonably general model and similar to what is done in other contexts.

A security level (also known as classification), which might be an integer in some range, but in the U.S. DoD consists of one of the four ratings:

1. Unclassified,
2. Confidential,
3. Secret, and
4. Top secret,

where unclassified < confidential < secret < top secret.

1.10 Security Plan (RFC 2196)

Please refer to the folder RFC 2196 in MS Word for the complete version; however some main points are reproduced here

Important words to be remembered from the

Risk Assessment

General Discussion

One of the most important reasons for creating a computer security policy is to ensure that efforts spent on security yield cost effective benefits. Although this may seem obvious, it is possible to be mislead about where the effort is needed. As an example, there is a great deal of publicity about intruders on computers systems; yet most surveys of computer security show that, for most organizations, the actual loss from "insiders" is much greater.

Risk analysis involves determining what you need to protect, what you need to protect it from, and how to protect it. It is the process of examining all of your risks, then ranking those risks by level of severity. This process involves making cost-effective decisions on what you want to protect. As mentioned above, you should probably not spend more to protect something than it is actually worth.

A full treatment of risk analysis is outside the scope of this document. [Fites 1989] and [Pfleeger 1989] provide introductions to this topic. However, there are two elements of a risk analysis that will be briefly covered in the next two sections:

(1) Identifying the assets

(2) Identifying the threats

For each asset, the basic goals of security are availability, confidentiality, and integrity. Each threat should be examined with an eye to how the threat could affect these areas.

Identifying the Assets

One step in a risk analysis is to identify all the things that need to be protected. Some things are obvious, like valuable proprietary information, intellectual property, and all the various pieces of hardware; but some are overlooked, such as the people who actually use the systems. The essential point is to list all things that could be affected by a security problem.

One list of categories is suggested by Pfleeger: [Pfleeger 1989]; this list is adapted from that source:

1. Hardware: CPUs, boards, keyboards, terminals, workstations, personal computers, printers, disk drives, communication lines, terminal servers, routers.
2. Software: source programs, object programs, utilities, diagnostic programs, operating systems, and communication programs.
3. Data: during execution, stored on-line, archived off-line, backups, audit logs, databases, in transit over communication media.
4. People: users, administrators, and hardware maintainers.
5. Documentation: on programs, hardware, systems, and local administrative procedures.
6. Supplies: paper, forms, ribbons, and magnetic media.

Identifying the Threats

Once the assets requiring protection are identified, it is necessary to identify threats to those assets. The threats can then be examined to determine what potential for loss exists. It helps to consider from what threats you are trying to protect your assets. The following are classic threats that should be considered. Depending on your site, there will be more specific threats that should be identified and addressed.

Unauthorized access to resources and/or information

Unintended and/or unauthorized Disclosure of information

Denial of service

1.11 What Makes a Good Security Policy?

The characteristics of a good security policy are:

(1) It must be able to implement through system administration procedures, publishing of acceptable use guidelines, or other appropriate methods.

(2) It must be enforceable with security tools, where appropriate, and with sanctions, where actual prevention is not technically feasible.

(3) It must clearly define the areas of responsibility for the users, administrators, and management.

1.12 The components of a good security policy include:

(1) Computer Technology Purchasing Guidelines, which specify required, or preferred, security features. These should supplement existing purchasing policies and guidelines.

(2) A Privacy Policy which defines reasonable expectations of privacy regarding such issues as monitoring of electronic mail, logging of keystrokes, and access to users' files.

(3) An Access Policy, which defines access rights and privileges to protect assets from loss or disclosure by specifying acceptable use guidelines for users, operations staff, and management. It should provide guidelines for external connections, data communications, connecting devices to a network, and adding new software to systems. It should also specify any required notification messages (e.g., connect messages should provide warnings about authorized usage and line monitoring, and not simply say "Welcome").

(4) An Accountability Policy, which defines the responsibilities of users, operations staff, and management. It should specify an audit capability, and provide incident handling guidelines (i.e., what to do and who to contact if a possible intrusion is detected).

(5) An Authentication Policy which establishes trust through an effective password policy, and by setting guidelines for remote location authentication and the use of authentication devices (e.g., one-time passwords and the devices that generate them).

(6) An Availability statement, which sets users' expectations for the availability of resources. It should address redundancy and recovery issues, as well as specify operating hours and maintenance downtime periods. It should also include contact information for reporting system and network failures.

(7) An Information Technology System & Network Maintenance Policy which describes how both internal and external maintenance people are allowed to handle and access technology. One important topic to be addressed here is whether remote maintenance is allowed and how such access is controlled. Another area for consideration here is outsourcing and how it is managed.

(8) A Violations Reporting Policy that indicates which types of violations (e.g., privacy and security, internal and external) must be reported and to whom the reports are made. A non- threatening atmosphere and the possibility of anonymous reporting will result in a greater probability that a violation will be reported if it is detected.

(9) Supporting Information which provides users, staff, and management with contact information for each type of policy violation; guidelines on how to handle outside queries about a security incident, or information which may be considered confidential or proprietary; and cross-references to security procedures and related information, such as company policies and governmental laws and regulations.

There may be regulatory requirements that affect some aspects of your security policy (e.g., line monitoring). The creators of the security policy should consider seeking legal assistance in the creation of the policy. At a minimum, legal counsel should review the policy.

Once your security policy has been established it should be clearly communicated to users, staff, and management. Having all personnel sign a statement indicating that they have read, understood, and agreed to abide by the policy is an important part of the process. Finally, your policy should be reviewed on a regular basis to see if it is successfully supporting your security needs.

Keeping the Policy Flexible

In order for a security policy to be viable for the long term, it requires a lot of flexibility based upon an architectural security concept. A security policy should be (largely) independent from specific hardware and software situations (as specific systems tend to be replaced or moved overnight). The mechanisms for updating the policy should be clearly spelled out. This includes the process, the people involved, and the people who must sign-off on the changes.

It is also important to recognize that there are exceptions to every rule. Whenever possible, the policy should spell out what exceptions to the general policy exist. For example, under what conditions is a system administrator allowed to go through a user's files. Also, there may be some cases when multiple users will have access to the same userid. For example, on systems with a "root" user, multiple system administrators may know the password and use the root account.

Another consideration is called the "Garbage Truck Syndrome." This refers to what would happen to a site if a key person was suddenly unavailable for his/her job function (e.g., was suddenly ill or left the company unexpectedly). While the greatest security resides in the minimum dissemination of information, the risk of losing critical information increases when that information is not shared. It is important to determine what the proper balance is for your site.

1.13 Deny all/ Allow all

There are two diametrically opposed underlying philosophies, which can be adopted when defining a security plan. Both alternatives are legitimate models to adopt, and the choice between them will depend on the site and its needs for security.

The first option is to turn off all services and then selectively enable services on a case-by-case basis, as they are needed. This can be done at the host or network level as appropriate. This model, which will here after be referred to as the "deny all" model, is generally more secure than the other model described in the next paragraph. More work is required to successfully implement a "deny all" configuration as well as a better understanding of services. Allowing only known services provides for a better analysis of a particular service/protocol and the design of a security mechanism suited to the security level of the site.

The other model, which will here after be referred to as the "allow all" model, is much easier to implement, but is generally less secure than the "deny all" model. Simply turn on all services, usually the default at the host level, and allow all protocols to travel across network boundaries, usually the default at the router level. As security holes become apparent, they are restricted or patched at either the host or network level.

Each of these models can be applied to different portions of the site, depending on functionality requirements, administrative control, site policy, etc. For example, the policy may be to use the "allow all" model when setting up workstations for general use, but adopt a "deny all" model when setting up information servers, like an email hub. Likewise, an "allow all" policy may be adopted for traffic between LAN's internal to the site, but a "deny all" policy can be adopted between the site and the Internet.

Be careful when mixing philosophies as in the examples above. Many sites adopt the theory of a hard "crunchy" shell and a soft "squishy" middle. They are willing to pay the cost of security for their external traffic and require strong security measures, but are unwilling or unable to provide similar protections internally. This works fine as long as the outer defenses are never breached and the internal users can be trusted. Once the outer shell (firewall) is breached, subverting the internal network is trivial.

1.14 Who Should be Involved When Forming Policy?

In order for a security policy to be appropriate and effective, it needs to have the acceptance and support of all levels of employees within the organization. It is especially important that corporate management fully support the security policy process otherwise there is little chance that they will have the intended impact. The following is a list of individuals who should be involved in the creation and review of security policy documents:

(1) Site security administrator

(2) Information technology technical staff (e.g., staff from computing center)

(3) Administrators of large user groups within the organization (e.g., business divisions, computer science department within a university, etc.)

(4) Security incident response team

(5) Representatives of the user groups affected by the security policy

(6) Responsible management

(7) Legal counsel (if appropriate)

The list above is representative of many organizations, but is not necessarily comprehensive. The idea is to bring in representation from key stakeholders, management who have budget and policy authority, technical staff who know what can and cannot be supported, and legal counsel who know the legal ramifications of various policy choices. In some organizations, it may be appropriate to include EDP audit personnel. Involving this group is important if resulting policy statements are to reach the broadest possible acceptance. It is also relevant to mention that the role of legal counsel will also vary from country to country.

1.15 Security Incident Handling

This chapter of the document will supply guidance to be used before; during, and after a computer security incident occurs on a host, network, site, or multi-site environment.

The operative philosophy in the event of a breach of computer security is to react according to a plan. This is true whether the breach is the result of an external intruder attack, unintentional damage, a student testing some new program to exploit software vulnerability, or a disgruntled employee. Each of the possible types of events, such as those just listed, should be addressed in advance by adequate contingency plans.

Traditional computer security, while quite important in the overall site security plan, usually pays little attention to how to actually handle an attack once one occurs. The result is that when an attack is in progress, many decisions are made in haste and can be damaging to tracking down the source of the incident, collecting evidence to be used in prosecution efforts, preparing for the recovery of the system, and protecting the valuable data contained on the system.

One of the most important, but often overlooked, benefits for efficient incident handling is an economic one. Having both technical and managerial personnel respond to an incident requires considerable resources. If trained to handle incidents efficiently, less staff time is required when one occurs.

Due to the worldwide network most incidents are not restricted to a single site. Operating systems vulnerabilities apply (in some cases) to several millions of systems, and much vulnerability are exploited within the network itself. Therefore, it is vital that all sites with involved parties be informed as soon as possible.

Another benefit is related to public relations. News about computer security incidents tends to be damaging to an organization's stature among current or potential clients. Efficient incident handling minimizes the potential for negative exposure.

A final benefit of efficient incident handling is related to legal issues. It is possible that in the near future organizations may be held responsible because one of their nodes was used to launch a network attack. In a similar vein, people who develop patches or workarounds may be sued if the patches or workarounds are ineffective, resulting in compromise of the systems, or, if the patches or workarounds themselves damage systems. Knowing about operating system vulnerabilities and patterns of attacks, and then taking appropriate measures to counter these potential threats, is critical to circumventing possible legal problems.

The sections in this chapter provide an outline and starting point for creating your site's policy for handling security incidents. The sections are:

(1)          Preparing and planning (what are the goals and objectives in handling an incident).

(2)          Notification (who should be contacted in the case of an incident). Local managers and personnel - Law enforcement and investigative agencies - Computer security incidents handling teams - Affected and involved sites - Internal communications - Public relations and press releases

(3)          Identifying an incident (is it an incident and how serious is it).

(4)          Handling (what should be done when an incident occurs). - Notification (who should be notified about the incident)- Protecting evidence and activity logs (what records should be kept from before, during, and after the incident) Containment (how can the damage be limited) Eradication (how to eliminate the reasons for the incident) Recovery (how to reestablish service and systems)- Follow Up (what actions should be taken after the incident)

(5)          Aftermath (what are the implications of past incidents).

(6)          Administrative response to incidents. The remainder of this chapter will detail the issues involved in each of the important topics listed above, and provide some guidance as to what should be included in a site policy for handling incidents.

1 Preparing and Planning for Incident Handling

 Part of handling an incident is being prepared to respond to an incident before the incident occurs in the first place. This includes establishing a suitable level of protections as explained in the preceding chapters. Doing this should help your site prevent incidents as well as limit potential damage resulting from them when they do occur. Protection also includes preparing incident handling guidelines as part of a contingency plan for your organization or site. Having written plans eliminates much of the ambiguity which occurs during an incident, and will lead to a more appropriate and thorough set of responses. It is vitally important to test the proposed plan before an incident occurs through "dry runs". A team might even consider hiring a tiger team to act in parallel with the dry run. (Note: a tiger team is a team of specialists that try to penetrate the security of a system.)

 Learning to respond efficiently to an incident is important for a number of reasons:

i.              Protecting the assets which could be compromised

ii.            Protecting resources which could be utilized more profitably if an incident did not require their services

iii.           Complying with (government or other) regulations

iv.           Preventing the use of your systems in attacks against other systems (which could cause you to incur legal liability)

v.            Minimizing the potential for negative exposure

 As in any set of pre-planned procedures, attention must be paid to a set of goals for handling an incident. These goals will be prioritized differently depending on the site. A specific set of objectives can be identified for dealing with incidents:

i.              Figure out how it happened.

ii.            Find out how to avoid further exploitation of the same vulnerability.

iii.           Avoid escalation and further incidents.

iv.           Assess the impact and damage of the incident.

v.            Recover from the incident.

vi.           Update policies and procedures as needed.

vii.          Find out who did it (if appropriate and possible).

 Due to the nature of the incident, there might be a conflict between analyzing the original source of a problem and restoring systems and services. Overall goals (like assuring the integrity of critical systems) might be the reason for not analyzing an incident. Of course, this is an important management decision; but all involved parties must be aware that without analysis the same incident may happen again.

 It is also important to prioritize the actions to be taken during an incident well in advance of the time an incident occurs. Sometimes an incident may be so complex that it is impossible to do everything at once to respond to it; priorities are essential. Although priorities will vary from institution to institution, the following suggested priorities may serve as a starting point for defining your organization's response:

(1)       Priority one -- protect human life and people's safety; human life always has precedence over all other considerations.

(2)       Priority two -- protect classified and/or sensitive data. Prevent exploitation of classified and/or sensitive systems, networks or sites. Inform affected classified and/or sensitive systems, networks or sites about already occurred penetrations. (Be aware of regulations by your site or by government)

(3)       Priority three --protect other data, including proprietary, scientific, managerial and other data, because loss of data is costly in terms of resources. Prevent exploitations of other systems, networks or sites and inform already affected systems, networks or sites about successful penetrations.

(4)       Priority four -- prevent damage to systems (e.g., loss or alteration of system files, damage to disk drives, etc.). Damage to systems can result in costly down time and recovery.

(5)       Priority five -- minimize disruption of computing resources (including processes). It is better in many cases to shut a system down or disconnect from a network than to risk damage to data or systems. Sites will have to evaluate the trade-offs between shutting down and disconnecting, and staying up. There may be service agreements in place that may require keeping systems up even in light of further damage occurring. However, the damage and scope of an incident may be so extensive that service agreements may have to be over-ridden.

 An important implication for defining priorities is that once human life and national security considerations have been addressed, it is generally more important to save data than system software and hardware. Although it is undesirable to have any damage or loss during an incident, systems can be replaced. However, the loss or compromise of data (especially classified or proprietary data) is usually not an acceptable outcome under any circumstances.

 Another important concern is the effect on others, beyond the systems and networks where the incident occurs. Within the limits imposed by government regulations it is always important to inform affected parties as soon as possible. Due to the legal implications of this topic, it should be included in the planned procedures to avoid further delays and uncertainties for the administrators.

Any plan for responding to security incidents should be guided by local policies and regulations. Government and private sites that deal with classified material have specific rules that they must follow. The policies chosen by your site on how it reacts to incidents will shape your response. For example, it may make little sense to create mechanisms to monitor and trace intruders if your site does not plan to take action against the intruders if they are caught. Other organizations may have policies that affect your plans. Telephone companies often release information about telephone traces only to law enforcement agencies.

Handling incidents can be tedious and require any number of routine tasks that could be handled by support personnel. To free the technical staff it may be helpful to identify support staff who will help with tasks like: photocopying, faxing, etc.

1.15 Notes of Security breach incident: - containment

Containment

The purpose of containment is to limit the extent of an attack. An essential part of containment is decision making (e.g., determining whether to shut a system down, disconnect from a network, monitor system or network activity, set traps, disable functions such as remote file transfer, etc.).

Sometimes this decision is trivial; shut the system down if the information is classified, sensitive, or proprietary. Bear in mind that removing all access while an incident is in progress obviously notifies all users, including the alleged problem users, that the administrators are aware of a problem; this may have a deleterious effect on an investigation. In some cases, it is prudent to remove all access or functionality as soon as possible, and then restore normal operation in limited stages. In other cases, it is worthwhile to risk some damage to the system if keeping the system up might enable you to identify an intruder.

This stage should involve carrying out predetermined procedures. Your organization or site should, for example, define acceptable risks in dealing with an incident, and should prescribe specific actions and strategies accordingly. This is especially important when a quick decision is necessary and it is not possible to first contact all involved parties to discuss the decision. In the absence of predefined procedures, the person in charge of the incident will often not have the power to make difficult management decisions (like to lose the results of a costly experiment by shutting down a system). A final activity that should occur during this stage of incident handling is the notification of appropriate authorities.

1.16 Notes of Security breach incident: - Eradication

Eradication

Once the incident has been contained, it is time to eradicate the cause. But before eradicating the cause, great care should be taken to collect all necessary information about the compromised system(s) and the cause of the incident, as they will likely be lost when cleaning up the system.

Software may be available to help you in the eradication process, such as anti-virus software. If any bogus files have been created, archive them before deleting them. In the case of virus infections, it is important to clean and reformat any media containing infected files. Finally, ensure that all backups are clean. Many systems infected with viruses become periodically re-infected simply because people do not systematically eradicate the virus from backups. After eradication, a new backup should be taken.

Removing all vulnerabilities once an incident has occurred is difficult. The key to removing vulnerabilities is knowledge and understanding of the breach.

It may be necessary to go back to the original distribution media and re-customize the system. To facilitate this worst-case scenario, a record of the original system setup and each customization change should be maintained. In the case of a network-based attack, it is important to install patches for each operating system vulnerability, which was exploited.

1.17 Security  Approaches:

Security Models:

No security:

In this simplest case, the approach could be a decision to implement no security at all.

Security through obscurity:

In this model, a system is secure simply because nobody knows about its existence and content. This approach cannot work for too long, as there are many ways on attacker can come to know about it.

Host Security:

In this scheme, the security foe each host is enforced individually. This is a very safe approach, but the trouble is that it cannot scale well. The complexity and the diversity of a modem sites/organizations make the task even harder.

Network Security:

Host security is tough to achieve as organizations grow and become more diverse. In this technique, the focus is to control network access to various hosts and their services, rather than individual host security. 'This is a very efficient and scalable model.

1.18 Principles of Security:

The principle of confidentiality specifies that only the sender and the intended recipient should be able' to access the content of a message. Confidentiality gets compromised if an unauthorized person is able to access a message. Example of compromising the confidentiality of a message is shown.

Here, the user of computer A sends a message to the user of computer B. Another user C gets access to this message, which is not desired, and therefore, defeats the purpose of confidentiality.

This type of attack is called as interception.

Authentication

Authentications mechanisms help establish proof of identities. The authentication process ensures that the origin of an electronic message or document is correctly identified. For instance, suppose that user C sends an electronic document over the Internet to user B. However, the trouble is that user C had posed as user A when sent this document to user B. This type of attack is called fabrication.

Integrity

When the contents of a message are changed after the sender sends it, but before it reaches the intended recipient, we say that the integrity of the message is lost. If user C tampers with a message originally sent by user A, which is actually destined for user B. User B has no way of knowing tbt the contents of a the message were changed after user A had send it. User A also does not know about this change. This type of attack is called as modification.

Non-repudiation

There are situations where a user sends a message, and later on refuses that she had sent that message. The principle of non-repudiation defeats such possibilities of denying something, having done it.

Access Control

The principle of access control determines who should be able to access what. For instance, the employee within an organization may be able to see the data records in the database. But he may not be permitted to update. Whereas, an administrator may be able to view as well as update or modify the contents because of the authority that he has.

Availability

The principle of availability states that resources should be available to authorized parties at all times. For e.g. due to the intentional actions of another unauthorized user C, an authorized user A may not be able to contact a server computer B. This would defeat the principle of availability.

Such an attack is called interruption.

1.18 Types of attack

Attacks can be grouped into two types:

• Passive Attacks.
• Active Attacks.

Passive Attacks:

Passive attacks are those, wherein the attacker indulges in eavesdropping or monitoring of data transmission. In other words, the attacker aims to obtain information that is in transit. The term passive indicates that the attacker does not attempt to perform any modifications to the data. In fact, this is also why passive attacks are hard to detect. Thus, the general approach to deal with passive attacks is to think about prevention, rather than detection or corrective actions.

Passive attacks do not involve any modifications to the contents of an original message.

They can be classified into two sub categories:

a.         Release of Message Contents

b.         Traffic Analysis.

a. Release of Message Contents

When we send a confidential email message to our friend, we desire that only she be able to access it. Otherwise, the contents of the message are release against our wishes to someone else. Using certain security mechanisms, we can prevent release of message contents like, encoding messages using a code language, so that only desired parties may understand the message.

b. Traffic Analysis.

If many such messages are' passing though, a passive attacker could try to figure out the similarities between them to come up with some sort of pattern that provides her some clues regarding the communication that takes place. Such attempts of analyzing encoded message are the work of traffic analysis attack.

Active Attacks:

Unlike passive attacks, the active attacks are based on modification of the original message in some manner, or on creation of a false message. These attacks cannot be prevented easily. However, they can be detected with some effort and attempts can be made to recover from them.

These attacks can be in the form of interruption, modification and fabrication.

Interruption attacks are called as masquerade attacks.

Masquerade is cause when an unauthorized entity pretends to be another entity.

Modification attacks can be classified into replay attacks and alteration of messages.

In replay attack, a user captures a sequence of events, or some data units, and resends them. Alteration of messages involves some change to the original message.

Fabrication causes Denial of Service (DOS) attacks.

DOS attacks make an attempt to prevent legitimate users from accessing some services, which they are eligible for. For instance, an unauthorized user might send too many login requests to a server using random user ids one after the other in quick succession, so as to flood the network and deny other legitimate users an access to the network.

1.19 The Practical Side of Attacks

1. Application Level Attacks:

These attacks happen at an application level in the sends that the attacker attempts to access, modify or prevent access to information of a particular application, or the application itself. Example of this are trying to obtain someone's credit card information on the Internet, or' changing the contents of a message to change the amount in a transaction, etc.

2. Network level attacks:

These attacks generally aim at reducing the capabilities of a network by a number of possible means, These attacks generally make an attempt to either slow down, or completely bring to halt, a computer network. Note that this automatically can lead to application level attacks, because once someone is able to gain access to a network, usually she is able to access/modify at least some sensitive information, causing havoc.

1.20 Cookies:

Cookies are born as a result of specific characteristics of the Internet. The Internet uses HTTP protocol, which is stateless.

Suppose that the client sends an HTTP request for a Web page to the server. The web server locates that page on its disk, sends it back to the client, and completely forgets about this interaction. If the client wants to continue this interaction, it must identify itself to the server in the next HTIP request. Otherwise, the server would not know that this same client and sent an HTIP request earlier. Since a typical application is likely to involve a number of interactions between the client and the server, there must be some mechanism for the client to identify itself to the server each time it sends a HTIP request to the server. For this, cookies are used. They are a popular mechanism of maintaining the state information i.e. identifying a client to a server.

A cookie is just one or more pieces of information stored as text strings in a text file on the disk of the client computer i.e. Web browser.

1.21 Specific Attacks: - Sniffing (snooping) Spoofing.

On the Internet, computers exchange messages with each other in the form of small groups of data called as packets. A packet, like a postal envelope contains the actua1 data to be sent and the addressing information. Attackers target these packets, as they travel from the source computer to the destination computer over the Internet.

These attacks take two main forms:

(a) Packet Sniffing (also called as snooping)

(b) Packet Spoofing.

Since the protocol used in this communication is called as Internet Protocol (IP), other names for these two attacks are: (a) IP sniffing and (b) IP spoofing. The meaning remains the same.

(a) Packet Sniffing:

Packet sniffing is a passive attack on an ongoing conversation. An attacker need not hijack a conversation, but instead, can simply observe i.e. sniff packets as they pass by. Clearly, to prevent an attacker from sniffing packets, the information that is passing needs to be protected in some ways.

This can be done at two levels:

i.          The data that is traveling can be encoded in some ways.

ii.         The transmission link itself can be encoded.

(b) Packet Spoofing:

In this technique, an attacker sends packets with an incorrect source address. When this happens, the receiver i.e. the party who receives the packets containing a false source address would inadvertently send replies back to the forged address (called as spoofed address) and not to the attacker.

This can lead to three possible cases:

viii.        The attacker can intercept the reply- If the attacker is between the destination and the forged source, the attacker can see the reply and use that information for hijacking attacks.

ix.           the attacker need not see the reply-If the attacker's intention was a Denial of Service(DOS) attack, the attacker need not bother about the reply.     ,

x.            The attacker does not want the reply- The attacker could simply be angry with the host. So it may put that host's address as the forged source address and send the packet to the destination. The attacker does not want a reply from the destination, as it wants the host with the forged address to receive it and get confused.

(C) DNS Spoofing:

With DNS (Domain Name System), people can identify Websites with human readable names such as www.yahoo.com and computers C<lJ1 continue to treat them as IP addresses such as 120.9.32.23). For this, a special server computer called as DNS server maintains the mappings between domain names and the corresponding IP address. The DNS Server could be located anywhere. Usually, it is with the Internet Service Provider (ISP) of the users. With this background, the DNS spoofing attack works as follows:

i.              Suppose that there is user A whose site domain name is www.A.com and the IP address is 100.10.10.10. So, all the DNS servers entry is maintained as: www.A.com l00.10.10.10

ii.            The attacker B manages to hack and replace the IP address of A with his own ie. 100.20.20.20 in the DNS server maintained by the ISP of user C. Therefore, the DNS Server maintained by the ISP of A has the following entry: www.A.com l00.20.20.20

iii.           When C wants to communicate with A's site, the Web browser queries the DNS server maintained by the ISP for A's IP address, providing it the domain name. C gets the replaced i.e. (B's IP address) which is 100.20.20.20.

iv.           Now, C starts communicating with B, believing that he is communicating with A.

A protocol called as DNSSec (Secure DNS) is being used to overcome such attacks.

1.22 Chapter Summery:

§  Network and Internet Security has gained immense prominence in the last few years, as conducting business using these technologies has become very crucial.

§  The principles of any security mechanism are:

o   Confidentiality,

o   Authentication,

o   Integrity,

o   Non-repudiation,

o   Access control and

o   Availability.

§  Confidentiality specifies that only the sender and the intended recipients should be able to access the contents of a message.

§  Authentication identifies the user of a computer system, and builds a trust with the recipient of a message.

§  Integrity of a message should be preserved as it travels from the sender to the recipient. It is compromised if the message is modified during transit.

§  Non-repudiation ensures that the sender of a message cannot refute the fact of sending that message in case of disputes.

§  Access control specifies what users Can do with a network or an Internet system.

§  Availability ensures that computer and network resources are always available to the legitimate users. .

§  Attacks on a system can be classified into:

o   Interception,

o   Fabrication,

o   Modification, and

o   Interruption.

§  Attacks can also be classified into passive and active attacks.

§  In passive attacks, the attacker does not modify the contents of a message.

§  Active attacks involve modification of the contents of a message.

§  Release of message contents and traffic analysis are types of passive attacks.

§  Masquerade, replay attack, alteration of message and Denial of Service attacks are types of active attacks.

§  Another way to classify attacks is application level attacks and network level attacks.

§  Viruses, worms, Trojan horses, Java applets, and ActiveX control can practically cause attacks on a computer system.