Access Controls

 

Access Controls

Authentication deals with the who of security policy enforcement; access controls enforce the what andhow.

ACLs on Routers

Routers perform the major task of directing network traffic either to subnetworks they control or to other routers for subsequent delivery to other subnetworks. Routers convert external IP addresses into internal MAC addresses of hosts on a local subnetwork.

Suppose a host is being spammed (flooded) with packets from a malicious rogue host. Routers can be configured with access control lists to deny access to particular hosts from particular hosts. So, a router could delete all packets with a source address of the rogue host and a destination address of the target host.

This approach has three problems, however. First, routers in large networks perform a lot of work: They have to handle every packet coming into and going out of the network. Adding ACLs to the router requires the router to compare every packet against the ACLs. One ACL adds work, degrading the router's performance; as more ACLs are added, the router's performance may become unacceptable. The second problem is also an efficiency issue: Because of the volume of work they perform, routers are designed to perform only essential services. Logging of activity is usually not done on a router because of the volume of traffic and the performance penalty logging would entail. With ACLs, it would be useful to know how many packets were being deleted, to know if a particular ACL could be removed (thereby improving performance). But without logging it is impossible to know whether an ACL is being used. These two problems together imply that ACLs on routers are most effective against specific known threats but that they should not be used indiscriminately.

The final limitation on placing ACLs on routers concerns the nature of the threat. A router inspects only source and destination addresses. An attacker will usually not reveal an actual source address. To reveal the real source address would be equivalent to a bank robber's leaving his home address and a description of where he plans to store the stolen money.

Because someone can easily forge any source address on a UDP datagram, many attacks use UDP protocols with false source addresses so that the attack cannot be blocked easily by a router with an ACL. Router ACLs are useful only if the attacker sends many datagrams with the same forged source address.

In principle, a router is an excellent point of access control because it handles every packet coming into and going out of a subnetwork. In specific situations, primarily for internal subnetworks, ACLs can be used effectively to restrict certain traffic flows, for example, to ensure that only certain hosts (addresses) have access to an internal network management subnetwork. But for large-scale, general traffic screening, routers are less useful than firewalls.

Firewalls

A firewall is designed to do the screening that is less appropriate for a router to do. A router's primary function is addressing, whereas a firewall's primary function is filtering. Firewalls can also do auditing. Even more important, firewalls can examine an entire packet's contents, including the data portion, whereas a router is concerned only with source and destination MAC and IP addresses. Because they are an extremely important network security control, we study firewalls in an entire section later in this chapter.

Strong Authentication

 

Strong Authentication

As we have seen in earlier chapters, operating systems and database management systems enforce a security policy that specifies who—which individuals, groups, subjects—can access which resources and objects. Central to that policy is authentication: knowing and being assured of the accuracy of identities.

Networked environments need authentication, too. In the network case, however, authentication may be more difficult to achieve securely because of the possibility of eavesdropping and wiretapping, which are less common in nonnetworked environments. Also, both ends of a communication may need to be authenticated to each other: Before you send your password across a network, you want to know that you are really communicating with the remote host you expect. Lampson presents the problem of authentication in autonomous, distributed systems; the real problem, he points out, is how to develop trust of network entities with whom you have no basis for a relationship. Let us look more closely at authentication methods appropriate for use in networks.

One-Time Password

The wiretap threat implies that a password could be intercepted from a user who enters a password across an unsecured network. A one-time password can guard against wiretapping and spoofing of a remote host.

As the name implies, a one-time password is good for one use only. To see how it works, consider the easiest case, in which the user and host both have access to identical lists of passwords, like the one-time pad for cryptography from Chapter 2. The user would enter the first password for the first login, the next one for the next login, and so forth. As long as the password lists remained secret and as long as no one could guess one password from another, a password obtained through wiretapping would be useless. However, as with the one-time cryptographic pads, humans have trouble maintaining these password lists.

To address this problem, we can use a password token, a device that generates a password that is unpredictable but that can be validated on the receiving end. The simplest form of password token is a synchronous one, such as the SecurID device from Security Dynamics. This device displays a random number, generating a new number every minute. Each user is issued a different device (that generates a different key sequence). The user reads the number from the device's display and types it in as a one-time password. The computer on the receiving end executes the algorithm to generate the password appropriate for the current minute; if the user's password matches the one computed remotely, the user is authenticated. Because the devices may get out of alignment if one clock runs slightly faster than the other, these devices use fairly natural rules to account for minor drift.

What are the advantages and disadvantages of this approach? First, it is easy to use. It largely counters the possibility of a wiretapper reusing a password. With a strong password-generating algorithm, it is immune to spoofing. However, the system fails if the user loses the generating device or, worse, if the device falls into an attacker's hands. Because a new password is generated only once a minute, there is a small (one minute) window of vulnerability during which an eavesdropper can reuse an intercepted password.

Challenge–Response Systems

To counter the loss and reuse problems, a more sophisticated one-time password scheme uses challenge and response, as we first studied in Chapter 4. A challenge and response device looks like a simple pocket calculator. The user first authenticates to the device, usually by means of a PIN. The remote system sends a random number, called the "challenge," which the user enters into the device. The device responds to that number with another number, which the user then transmits to the system.

The system prompts the user with a new challenge for each use. Thus, this device eliminates the small window of vulnerability in which a user could reuse a time-sensitive authenticator. A generator that falls into the wrong hands is useless without the PIN. However, the user must always have the response generator to log in, and a broken device denies service to the user. Finally, these devices do not address the possibility of a rogue remote host.

Content Integrity

 

Content Integrity

Content integrity comes as a bonus with cryptography. No one can change encrypted data in a meaningful way without breaking the encryption. This does not say, however, that encrypted data cannot be modified. Changing even one bit of an encrypted data stream will affect the result after decryption, often in a way that seriously alters the resulting plaintext. We need to consider three potential threats:

·         malicious modification that changes content in a meaningful way

·         malicious or nonmalicious modification that changes content in a way that is not necessarily meaningful

·         nonmalicious modification that changes content in a way that will not be detected

Encryption addresses the first of these threats very effectively. To address the others, we can use other controls.

Error Correcting Codes

We can use error detection and error correction codes to guard against modification in a transmission. The codes work as their names imply: Error detection codes detect when an error has occurred, and error correction codes can actually correct errors without requiring retransmission of the original message. The error code is transmitted along with the original data, so the recipient can recompute the error code and check whether the received result matches the expected value.

The simplest error detection code is a parity check. An extra bit is added to an existing group of data bits depending on their sum or an exclusive OR. The two kinds of parity are called even and odd. Witheven parity the extra bit is 0 if the sum of the data bits is even and 1 if the sum is odd; that is, the parity bit is set so that the sum of all data bits plus the parity bit is even. Odd parity is the same except the sum is odd. For example, the data stream 01101101 would have an even parity bit of 1 (and an odd parity bit of 0) because 0+1+1+0+1+1+0+1 = 5 + 1 = 6 (or 5 + 0 = 5 for odd parity). A parity bit can reveal the modification of a single bit. However, parity does not detect two-bit errors—cases in which two bits in a group are changed. That is, the use of a parity bit relies on the assumption that single-bit errors will occur infrequently, so it is very unlikely that two bits would be changed. Parity signals only that a bit has been changed; it does not identify which bit has been changed.

There are other kinds of error detection codes, such as hash codes and Huffman codes. Some of the more complex codes can detect multiple-bit errors (two or more bits changed in a data group) and may be able to pinpoint which bits have been changed.

Parity and simple error detection and correction codes are used to detect nonmalicious changes in situations in which there may be faulty transmission equipment, communications noise and interference, or other sources of spurious changes to data.

Cryptographic Checksum

Malicious modification must be handled in a way that prevents the attacker from modifying the error detection mechanism as well as the data bits themselves. One way to do this is to use a technique that shrinks and transforms the data, according to the value of the data bits.

To see how such an approach might work, consider an error detection code as a many-to-one transformation. That is, any error detection code reduces a block of data to a smaller digest whose value depends on each bit in the block. The proportion of reduction (that is, the ratio of original size of the block to transformed size) relates to the code's effectiveness in detecting errors. If a code reduces an eight-bit data block to a one-bit result, then half of the 28 input values map to 0 and half to 1, assuming a uniform distribution of outputs. In other words, there are 28/2 = 27 = 128 different bit patterns that all produce the same one-bit result. The fewer inputs that map to a particular output, the fewer ways the attacker can change an input value without affecting its output. Thus, a one-bit result is too weak for many applications. If the output is three bits instead of one, then each output result comes from 28/23 or 25 = 32 inputs. The smaller number of inputs to a given output is important for blocking malicious modification.

A cryptographic checksum (sometimes called a message digest) is a cryptographic function that produces a checksum. The cryptography prevents the attacker from changing the data block (the plaintext) and also changing the checksum value (the ciphertext) to match.

question of the day

question of the day

Encryption

 

Encryption

Encryption is probably the most important and versatile tool for a network security expert. We have seen in earlier chapters that encryption is powerful for providing privacy, authenticity, integrity, and limited access to data. Because networks often involve even greater risks, they often secure data with encryption, perhaps in combination with other controls.

In network applications, encryption can be applied either between two hosts (called link encryption) or between two applications (called end-to-end encryption). We consider each below. With either form of encryption, key distribution is always a problem. Encryption keys must be delivered to the sender and receiver in a secure manner. In this section, we also investigate techniques for safe key distribution in networks. Finally, we study a cryptographic facility for a network computing environment.

Link Encryption

In link encryption, data are encrypted just before the system places them on the physical communications link. In this case, encryption occurs at layer 1 or 2 in the OSI model. (A similar situation occurs with TCP/IP protocols.) Similarly, decryption occurs just as the communication arrives at and enters the receiving computer. A model of link encryption is shown in Figure 2.

Figure 2  Link Encryption.

Encryption protects the message in transit between two computers, but the message is in plaintext inside the hosts. (A message in plaintext is said to be "in the clear.") Notice that because the encryption is added at the bottom protocol layer, the message is exposed in all other layers of the sender and receiver. If we have good physical security, we may not be too concerned about this exposure; the exposure occurs on the sender's or receiver's host or workstation, protected by alarms or locked doors, for example. Nevertheless, you should notice that the message is exposed in two layers of all intermediate hosts through which the message may pass. This exposure occurs because routing and addressing are not read at the bottom layer, but only at higher layers. The message is in the clear in the intermediate hosts, and one of these hosts may not be especially trustworthy.

Link encryption is invisible to the user. The encryption becomes a transmission service performed by a low-level network protocol layer, just like message routing or transmission error detection. Figure 3shows a typical link encrypted message, where the shaded fields are encrypted. Because some of the data link header and trailer is applied before the block is encrypted, part of each of those blocks is shaded. As the message M is handled at each layer, header and control information is added on the sending side and removed on the receiving side. Hardware encryption devices operate quickly and reliably; in this case, link encryption is invisible to the operating system as well as to the operator.

Figure 3  Message Under Link Encryption.

Link encryption is especially appropriate when the transmission line is the point of greatest vulnerability. If all hosts on a network are reasonably secure but the communications medium is shared with other users or is not secure, link encryption is an easy control to use.

End-to-End Encryption

As its name implies, end-to-end encryption provides security from one end of a transmission to the other. The encryption can be applied by a hardware device between the user and the host. Alternatively, the encryption can be done by software running on the host computer. In either case, the encryption is performed at the highest levels (layer 7, application, or perhaps at layer 6, presentation) of the OSI model. A model of end-to-end encryption is shown in Figure 4.

Figure 4  End-to-End Encryption.

Since the encryption precedes all the routing and transmission processing of the layer, the message is transmitted in encrypted form throughout the network. The encryption addresses potential flaws in lower layers in the transfer model. If a lower layer should fail to preserve security and reveal data it has received, the data's confidentiality is not endangered. Figure 5 shows a typical message with end-to-end encryption, again with the encrypted field shaded.

Figure 5  End-to-End Encrypted Message.

When end-to-end encryption is used, messages sent through several hosts are protected. The data content of the message is still encrypted, as shown in Figure 6, and the message is encrypted (protected against disclosure) while in transit. Therefore, even though a message must pass through potentially insecure nodes (such as C through G) on the path between A and B, the message is protected against disclosure while in transit.

Figure 6  Encrypted Message Passing Through a Host.

 

 

network architecture

 

Architecture

As with so many of the areas we have studied, planning can be the strongest control. In particular, when we build or modify computer-based systems, we can give some thought to their overall architecture and plan to "build in" security as one of the key constructs. Similarly, the architecture or design of a network can have a significant effect on its security.

Segmentation

Just as segmentation was a powerful security control in operating systems, it can limit the potential for harm in a network in two important ways: Segmentation reduces the number of threats, and it limits the amount of damage a single vulnerability can allow.

Assume your network implements electronic commerce for users of the Internet. The fundamental parts of your network may be

·         a web server, to handle users' HTTP sessions

·         application code, to present your goods and services for purchase

·         a database of goods, and perhaps an accompanying inventory to the count of stock on hand and being requested from suppliers

·         a database of orders taken

If all these activities were to run on one machine, your network would be in trouble: Any compromise or failure of that machine would destroy your entire commerce capability.

A more secure design uses multiple segments, as shown in Figure 7-20. Suppose one piece of hardware is to be a web server box exposed to access by the general public. To reduce the risk of attack from outside the system, that box should not also have other, more sensitive, functions on it, such as user authentication or access to a sensitive data repository. Separate segments and servers—corresponding to the principles of least privilege and encapsulation—reduce the potential harm should any subsystem be compromised.

Separate access is another way to segment the network. For example, suppose a network is being used for three purposes: using the "live" production system, testing the next production version, and developing subsequent systems. If the network is well segmented, external users should be able to access only the live system, testers should access only the test system, and developers should access only the development system. Segmentation permits these three populations to coexist without risking that, for instance, a developer will inadvertently change the production system.

Redundancy

Another key architectural control is redundancy: allowing a function to be performed on more than one node, to avoid "putting all the eggs in one basket." For example, the design of figure-1 has only one web server; lose it and all connectivity is lost. A better design would have two servers, using what is called failover mode. In failover mode the servers communicate with each other periodically, each determining if the other is still active. If one fails, the other takes over processing for both of them. Although performance is cut approximately in half when a failure occurs, at least some processing is being done.

Figure 1 Segmented Architecture.

Single Points of Failure

Ideally, the architecture should make the network immune to failure. In fact, the architecture should at least make sure that the system tolerates failure in an acceptable way (such as slowing down but not stopping processing, or recovering and restarting incomplete transactions). One way to evaluate the network architecture's tolerance of failure is to look for single points of failure. That is, we should ask if there is a single point in the network that, if it were to fail, could deny access to all or a significant part of the network. So, for example, a single database in one location is vulnerable to all the failures that could affect that location. Good network design eliminates single points of failure. Distributing the database—placing copies of it on different network segments, perhaps even in different physical locations—can reduce the risk of serious harm from a failure at any one point. There is often substantial overhead in implementing such a design; for example, the independent databases must be synchronized. But usually we can deal with the failure-tolerant features more easily than with the harm caused by a failed single link.

Architecture plays a role in implementing many other controls. We point out architectural features as we introduce other controls throughout the remainder of this chapter.

Security Threat Analysis in Network

 

Security Threat Analysis

Recall the three steps of a security threat analysis in other situations. First, we scrutinize all the parts of a system so that we know what each part does and how it interacts with other parts. Next, we consider possible damage to confidentiality, integrity, and availability. Finally, we hypothesize the kinds of attacks that could cause this damage. We can take the same steps with a network. We begin by looking at the individual parts of a network:

·         local nodes connected via

·         local communications links to a

·         local area network, which also has

·         local data storage,

·         local processes, and

·         local devices.

The local network is also connected to a

·         network gateway which gives access via

·         network communications links to

·         network control resources,

·         network routers, and

·         network resources, such as databases.

These functional needs are typical for network users. But now we look again at these parts, this time conjuring up the negative effects threat agents can cause. We posit a malicious agent—call him Hector—who wants to attack networked communications between two users, Andy and Bo. What might Hector do?

·         Read communications. The messages sent and received are exposed inside Andy's machine, at all places through the network, and inside Bo's machine. Thus, a confidentiality attack can be mounted from practically any place in the network.

·         Modify communications from Andy to Bo. Again, the messages are exposed at all places through the network.

·         Forge communications allegedly from Andy to Bo. This action is even easier than modifying a communication because a forgery can be inserted at any place in the network. It need not originate with the ostensible sender, and it does not require catching a communication in transit. Since Andy does not deliver his communications personally and since Bo might even never have met Andy, Bo has little basis for judging whether a communication purportedly sent by Andy is authentic.

·         Inhibit communications from Andy to Bo. Here again, Hector can achieve this result by invading Andy's machine, Bo's machine, routers between them, or communications links. He can also disrupt communications in general by flooding the network or disrupting any unique path on the network.

·         Inhibit all communications passing through a point. If the point resides on a unique path to or from a node, all traffic to or from that node is blocked. If the path is not unique, blocking it will shift traffic to other nodes, perhaps overburdening them.

·         Read data at some machine C between Andy and Bo. Hector can impersonate Andy (who is authorized to access data at C). Bo might question a message that seems out of character for Andy, but machine C will nevertheless apply the access controls for Andy. Alternatively, Hector can invade (run a program on) machine C to override access controls. Finally, he can search the network for machines that have weak or improperly administered access controls.

·         Modify or destroy data at C. Here again Hector can impersonate Andy and do anything Andy could. Similarly, Hector can try to circumvent controls.

We summarize these threats with a list:

·         intercepting data in traffic

·         accessing programs or data at remote hosts

·         modifying programs or data at remote hosts

·         modifying data in transit

·         inserting communications

·         impersonating a user

·         inserting a repeat of a previous communication

·         blocking selected traffic

·         blocking all traffic

·         running a program at a remote host

Why are all these attacks possible? Size, anonymity, ignorance, misunderstanding, complexity, dedication, and programming all contribute. But we have help at hand; we look next at specific threats and their countermeasures. Later in this chapter we investigate how these countermeasures fit together into specific tools.

Network Security Controls

 

Network Security Controls

The list of security attacks is very long, and the news media carry frequent accounts of serious security incidents. From these, you may be ready to conclude that network security is hopeless. Fortunately, that is not the case. Previous chapters have presented several strategies for addressing security concerns, such as encryption for confidentiality and integrity, reference monitors for access control, and overlapping controls for defense in depth. These strategies are also useful in protecting networks. This section presents many excellent defenses available to the network security engineer. Subsequent sections provide detailed explanations for three particularly important controls—firewalls, intrusion detection systems, and encrypted e-mail.

Artificial intelligence lab pratical -1

Write a PROLOG program for Family Relationship.

 

MOTILAL (SWARUPMATI)

 

 

 

 

       JAVAHARLAL                      VIJYALAKSHMI                                     KRISHNA

           (KAMLA)                                  (RANJIT)

 

           

 

      INDIRA                                               

      (FIROZ)

                                    TARA             LEKHA                        RITA

 

 

 

 

SANJAY                          RAJIV

(MENKA)                      (SONIA)

 

 

VARUN                          

 

             RAHUL               PRIYANKA

 

 

 

        father ("Motilal","Jawaharlal").

        father ("Motilal","Vijayalakshmi").

        father ("Motilal","Krishna").

        father ("Jawaharlal","Indira").

        father ("Ranjit","Tara").

        father ("Ranjit","Lekha").

        father ("Ranjit","Rita").

        father ("Feroz","Sanjay").

        father ("Feroz","Rajiv").

        father ("Sanjay","Varun").

        father ("Rajiv","Rahul").

        father ("Rajiv","Priyanka").

 

        wife_of("Swaruprani","Motilal").

        wife_of("Kamla","Jawaharlal").

        wife_of("Vijayalakshmi","Ranjit").

        wife_of("Indira","Feroz").

        wife_of("Maneka","Sanjay").

        wife_of("Sonia","Rajiv").

 

        female("Krishna").

        female("Priyanka").

        female("Lekha").

        female("Tara").

        female("Rita").

        female(X) :-

                wife_of (X,_).

 

        male("Varun").

        male("Rahul").

        male(X) :-

                husband_of (X,_).

 

        husband_of(X,Y) :-

                wife_of (Y,X).

 

        mother(X,Y):-

                wife_of (X,Z),

                father(Z,Y).

 

        parent(X,Y):-

                father(X,Y);

                mother(X,Y).

 

        child(X,Y):-

                parent(Y,X).

 

        son(X,Y):-

                child(X,Y),

                male(X).

 

        daughter(X,Y):-

                child(X,Y),

                female(X).

 

        brother(X,Y):-

                father(Z,X),

                father(Z,Y),

                male(X),

                not (X=Y).

 

        sister(X,Y):-

                father(Z,X),

                father(Z,Y),

                female(X),

                not (X=Y).

 

        uncle (X,Y):-

                parent(Z,Y),

                brother(X,Z);

                parent(Z,Y),

                sister(S,Z),

                husband_of(X,S).

 

        aunt (X,Y):-

                sister(X,Z),

                parent(Z,Y).

 

        aunt (X,Y):-

                wife_of(X,Z),

                uncle(Z,Y).

 

        ancestor(X,Y):-

                parent(X,Y).

 

        ancestor(X,Y):-

                parent(Z,Y),

                ancestor(X,Z).

 

        grand_father(X,Y):-

                parent(X,Z),

                parent(Z,Y),

                male(X).

 

        grand_mother(X,Y):-

                parent(X,Z),

                parent(Z,Y),

                female(X).

 

        cousin(X,Y):-

                parent(Z,X),

                parent(W,Y),

                brother(Z,W);

                parent(Z,X);

                parent(W,Y),

                sister(Z,W).

 

        nephew(X,Y):-

                male(X),

                uncle(Y,X);

                male(X),

                aunt(Y,X).

 

        niece(X,Y):-

                female(X),

                uncle(Y,X);

                female(X),

                aunt(Y,X).

 

OUTPUT:

18 ?- consult('pract1').

% pract1 compiled 0.02 sec, 452 bytes

true.

 

19 ?- grand_father('Motilal','Indira').

true

.

 

20 ?- grand_father(X,'Indira').

X = 'Motilal' ;

false.

 

21 ?- sister(X,Y).

X = 'Vijayalakshmi',

Y = 'Jawaharlal' ;

X = 'Vijayalakshmi',

Y = 'Krishna' ;

X = 'Krishna',

Y = 'Jawaharlal' ;

X = 'Krishna',

Y = 'Vijayalakshmi' ;

X = 'Tara',

Y = 'Lekha' ;

X = 'Tara',

Y = 'Rita' ;

X = 'Lekha',

Y = 'Tara' ;

X = 'Lekha',

Y = 'Rita'