Information Security: The Big Picture – Part V

Chia sẻ: Huy Hoang | Ngày: | Loại File: PDF | Số trang:25

Thêm vào BST

Báo xấu

109
lượt xem 7
download

Information Security: The Big Picture – Part V

Mô tả tài liệu

Download Vui lòng tải xuống để xem tài liệu đầy đủ

The World Wide Web has become the de facto communications medium for the Internet. Millions of people use it every day to get information, communicate with coworkers, buy and sell goods, entertain themselves, and keep up to date with current events. However, most of these people have very little knowledge about how the web actually works. On this slide we will give you a brief introduction to the web and tell you everything you always wanted to know about the web but were afraid to ask. All in less than three minutes....

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Information Security: The Big Picture – Part V

Information Security: The Big Picture – Part V Stephen Fried Information Security: The Big Picture - SANS GIAC © 2000 1 1
Agenda • General Security Introduction • Telecommunications Fundamentals • Network Fundamentals • Network Security • World Wide Web Security • Information Secrecy & Privacy • Identification and Access Control • Programmatic Security • Conclusion Information Security: The Big Picture - SANS GIAC © 2000 2 If you are taking this course you undoubtedly know about the World Wide Web. As valuable, as useful, and as important to our everyday lives as the web has become, it is full of security issues and problems. This section will examine those issues. 2
Everything You Always Wanted to Know About Web Communications… • Servers and Clients • HTTP and HTML • Stateless Communications • Retrieving Information – GET • Sending Information – POST Information Security: The Big Picture - SANS GIAC © 2000 3 The World Wide Web has become the de facto communications medium for the Internet. Millions of people use it every day to get information, communicate with coworkers, buy and sell goods, entertain themselves, and keep up to date with current events. However, most of these people have very little knowledge about how the web actually works. On this slide we will give you a brief introduction to the web and tell you everything you always wanted to know about the web but were afraid to ask. All in less than three minutes. All computers on the web fall into one of two categories: clients or servers. Let’s start with servers. A server is a computer that contains some sort of information that an organization wants to distribute. The server runs a special piece of software, called a web server, that takes requests from other machines, figures out what the request is for, finds the answer to the request, and sends it back to the requesting machine. That’s basically all a server does. The client machine is the machine that is doing the requesting. The client runs a piece of software called a “Web browser”, or just browser for short. Browsers take input from users, convert that input into a language the server will understand, send it off to the server over the network, and waits for the reply. When the server sends the reply, the browser will format it and display it for the user. Simple as that. OK, it’s not really all that simple. There may be a lot of processing that goes on behind the scenes. For example, the server may have to contact other computers to get the information the client needs, or the client may have to run some other programs in order to properly interpret the response from the browser, but here you have the basics: Client sends request, server responds to request. The way clients and servers communicate on the Web is through a protocol called HTTP – the HyperText Transfer Protocol. Like any other protocol, HTTP is just a set of standards, conventions, and notations the two systems must understand in order to communicate. The HyperText Markup Language, or HTML, is the actual language used to develop web pages. HTML uses a set of special notations, called tags, to tell the browser how to display a page, including things like where to center text, what fonts to use, where to place images on a page, and so on. If you want to see examples of HTML, most browsers allow you to view the HTML source code for any page it displays. Communication on the Web is called “stateless.” This is because each interaction between clients and servers is an independent transaction. For example, each time you click on a web page you are starting a completely new interaction between your browser and the server. If you click on 12 different links on a page your browser will make 12 different connections to the server. There is no information about the state of any previous transactions carried over from one transaction to the next. That’s why it is called “stateless.” We will see in the next slide how servers and clients can be tricked into carrying state information between transactions. There are two types of transactions that browsers can request of servers. They are called GET and POST. A GET transaction asks the server to get some information and send it back to the browser. When you click on a simple link on a web page you are typically issuing a GET transaction request. A POST transaction allows the browser to send some information to the server, usually information from a form the user fills out. POST transactions send the information from the browser to the server. The server will then act on the input and send any results back to the client. Generally, users don’t have control over whether clicking on a link on a web page will initiate a GET or POST transaction. That decision is already coded into the web page itself. 3
HTML Security • Reading HTML Source • Hidden Fields • Server Side Includes Information Security: The Big Picture - SANS GIAC © 2000 4 Given the open nature of the HTTP protocol, it is easy to start seeing some of the negative security issues that surround its use. On this slide we will examine some of these problems. The easiest way to learn HTML is to examine the HTML source code of any page you happen to visit. Most browsers have an option to let you view the HTML source of the current page you are viewing. From there you can see all the code, fields, tags, and other HTML elements that make up the page. You may also see some unexpected things. Many developers put information into source code that is never meant for public viewing, thinking that regular people will never see it. When you view the code you may see things like variable names and data values that are used internally by the web site’s programs. You may see references to the names of the site’s developers or internal information about the organization that is running the server. You may see references to directory names where files are stored on the web server. There may be references to user IDs or passwords for different services on the machines. If the server is using JavaScript or some other scripting language you may see code paths that refer to options that the user would not normally see. All this information can give an attacker a clue as to the underlying structure and organization of the server in order to plan an attack. And it’s all there free for the looking. Many web pages, particularly those that use input forms, make use of a feature of HTML called Hidden Fields. Like their name implies, hidden fields reside on a web page form but they are hidden from view when the page is displayed. Hidden fields are typically used as a method for carrying information from one form to another without requiring the user to re-enter the information on each form. However, hidden fields can also contain values not entered by the user. For example, when a user enters a user ID on a web form, the server might look up the user’s Social Security Number and place that in a hidden field for later use. If you look at the HTML source for the page with the hidden field you will see that information. Unfortunately, so will anyone else that may be sniffing the network when that page is transmitted. Another neat tool is the use of a technology called Server Side Includes. Server Side Includes are small pieces of code that are embedded in HTML documents. When a Web server begins to display a web page it will go line by line through the code interpreting the HTML commands. When it comes upon a Server Side Include line it stops and does whatever the include says. For example, it might insert text from a different file like a copyright notice or policy statement. It might insert today’s date and time to be displayed on the page. Or, and this is the scary part, it might run a separate program and insert its output into the HTML document. This is scary because if the included program has a bug, or the attacker can manipulate the program to run some malicious code, the potential exists for the attacker to compromise the server and gain unauthorized access or obtain confidential information. Now, despite these shortcomings, and some others we will examine shortly, nobody is saying that we should do away with HTML. But security practitioners need to take extra care when developing, implementing, or reviewing HTML systems to reduce the likelihood that information in source code or the use of hidden fields and server side includes do not have a negative effect on the server or the organization. 4
Input Validation • All programs are driven by their input – “garbage in, garbage out” • Normal input -> normal results • Abnormal input -> unknown results • No validation in standard HTML • Need to check all form input before processing Information Security: The Big Picture - SANS GIAC © 2000 5 Many web pages use forms or some other user input as a way of interacting with the user. The user may need to enter a term for searching or enter a user ID and password to gain entry to a particular site. Or, more commonly, the user will need to enter information into a form like a credit card number or merchandise numbers. The server will then send this information to some other program for processing. The processing program, like any other computer program, relies on this input to drive its functions. There is an age-old axiom in computers that says “garbage in, garbage out.” This means that if the user enters bad input into the program they will get bad output. Computer programs by and large don’t handle bad input very well. They do great with normal, expected input. As long as the user works with the program in the ways that the designer anticipated, everything goes along just fine. But when a user acts in a way that the designer did not anticipate, either accidentally or maliciously, the program will not act predictably. In fact, the results of this action are generally unknown. If you haven’t figured this out already, computer security people hate when things act in unknown, unpredictable ways. That’s because it makes it difficult, if not impossible, to protect the system. SYN floods, fragmentation attacks and the Ping of Death are all examples of what happens when a system receives input it did not expect. Plain vanilla HTML also has no built-in methods for validating user input. There are no variable checks or data validation rules built into HTML to prevent bad input from happening. If you are using a scripting language to develop your pages you can build validation routines into your forms, but if you want to stick with plain HTML you are out of luck. That’s why you need to pay particular attention to any web pages, or any program for that matter, that requires user input. You need to ensure that all input is validated for correctness. What does “validated” mean? It means that you need to check that the input is correct for the type of information being requested. If you are looking for a Social Security number, make sure that there are no letters entered by the user. If you are requesting a piece of text that should be 10 characters long, make sure the user doesn’t enter 500 characters of text. Beyond simple type and length validation, you also need to check the input to see if it matches the type of information you are expecting. For example, if you normally only sell 2 or 3 of a particular items is it normal for a user to order 999 of that item? Is the name on the customer’s credit card different from the name on the shipping address? Things like this can be a clue to possible unauthorized activity or fraud. 5
Cookies • HTTP is “stateless” – no context information • Cookies provide “state” and context • Can only hold information you’ve given to server • Can only be exchanged with originating server or domain • Beware of cross-site sharing (e.g. DoubleClick) • Can block cookies if desired Information Security: The Big Picture - SANS GIAC © 2000 6 One of the interesting things that we mentioned before about the HTTP protocol is that it is stateless. By “stateless” we mean that each transaction is an independent unit with no relation to any transactions that came before or after it. When you request a web page your computer connects to the server, gets the page, then closes the connection. The next time you request a page your computer makes a new connection to the server. Unfortunately, many web applications, like shopping or information retrieval systems, require that information be passed from one page to the other. How do you accomplish this in a stateless system? The answer is a protocol called “cookies.” A cookie is a small piece of information that a server will send to a browser. What does this information contain? Well, almost anything the server wants it to. It might be the product numbers and prices for things you want to order from a site. It might be your user ID or customer number on a particular site. It can be anything that the site needs you to store from page to page. Cookies are actually a pretty neat technology, and nicely solve a major problem in the original HTTP protocol. However, many people don’t like cookies. There are a couple of reasons for this. The first is that the user has no control over the information stored in cookies. Since the content of the cookie is controlled by the server you have no way of knowing what’s in it. Also, if a site puts sensitive information in a cookie, like a Social Security number or a credit card number, unless they take steps to hide that information (using encryption, for example) that information will be available to everyone on the network as the cookie is transmitted back and forth between the browser and the server. Some people object to cookies on privacy principles. They believe that cookies are somehow magically taking information from you or your computer and spreading that information around the Internet. Most of these fears are based on a lack of understanding of how cookies really work. First off, cookies can only contain information that you’ve already given to the web server or the company you are dealing with. There is no way the site can know your home address or credit card number unless you have already given it to them. So you’ve already given up some of your privacy before the cookies even entered into the picture. Secondly, cookies can only be sent to and from the server or domain that originally created the cookie. There is no way that a cookie from xyz.com can be shared with a server from abc.com. This last point, however, while technically true, has found a wrinkle lately. It is true that one company’s server can not share a cookie with another company’s server. But what if one company were able to distribute cookies on ALL servers? This is exactly what a company called DoubleClick has done. You’ve probably seen their advertisements on web pages you’ve visited. DoubleClick rents space on web pages for advertisements. So, for example, when you visit the web page for acme.com you will see an ad that is actually generated by DoubleClick from the DoubleClick server. The cookies generated by that ad are shared between the browser and DoubleClick, not the browser and Acme. Then, when you go to widgets.com you may see another DoubleClick advertisement. Again, you will share a cookie with DoubleClick, not Widgets.com. In this way, the DoubleClick service can begin to collect information on what sites you have visited over the Internet. Many privacy advocates are extremely worried about this practice. If you are really worried about cookies you can take steps to protect yourself. In most browsers you can set an option to prevent the downloading of cookies to your browser. There are also a number of shareware add-on utilities that let you selectively block cookies based on various criteria. 6
SSL • Protocol for encrypting network traffic • Operates at Transport Layer • Operates on port 443 • How it works – Client connects to server – Server indicates need for SSL – Client and server exchange crypto keys – Secure session begins • Not a guarantee of security Information Security: The Big Picture - SANS GIAC © 2000 7 Plain, generic HTTP is fine for open, non-secret communications, but some applications require more privacy than that provided by HTTP. For example, you may want to keep your credit card information or information about your bank accounts secret over the Internet. For these types of applications, there is the Secure Socket Layer protocol, or SSL. SSL is a general-purpose protocol for encryption of network traffic. Although it is most commonly associated with HTTP traffic, SSL operates at the Transport Layer of the TCP/IP stack and can be used with many different application protocols. Any program that uses TCP can be modified to use SSL. General HTTP traffic typically operates on port 80. When SSL is enabled on a connection it usually runs on port 443. When a client connects to a web server, the server will generally indicate whether SSL is required for that page. If it is required, the client and the server will negotiate to determine what type of encryption the session will use. Generally, the strongest algorithm that the two programs support will be selected. The client and the server will then exchange encryption keys. These are the codes that will enable the two to encrypt messages back and forth. Once the keys have been exchanged, all further communications between the client and the server are encrypted. I have left out a LOT of detail here about the specifics of the key exchange and the use of certificates to validate the identity of the client and the server, but most of it is unimportant in order to gain a high-level understanding of the process. What’s important to remember is that all sensitive information that is to be transmitted over the web should require SSL to be enabled. You can tell if SSL is enabled on a web page by looking at the bottom of your browser. In Internet Explorer there will be a small icon of a lock in the lower right corner. In Netscape there will be a small lock in the lower left corner. Other browsers may have other indicators, but they all mean the same thing – your information is being protected with encryption. Please note that the use of SSL does not guarantee that your information is secure from all prying eyes. SSL only secures data in transit over the network. Even then, it is possible that someone will capture the information as it is transmitted and decrypt the packets. The likelihood is reduced, particularly if you are using strong encryption, but it is possible. Also, SSL does not protect your information once it reaches the destination computer. If that computer stores the information in a publicly accessible area or an attacker gains unauthorized access to that computer, your information is still vulnerable. 7
Secure Electronic Transactions (SET) • Developed by Visa, MasterCard, Microsoft, Netscape • Specific-purpose protocol • Secures credit and debit card transactions • Services provided – Authentication – Confidentiality – Message Integrity – Linkage Information Security: The Big Picture - SANS GIAC © 2000 8 Protocols like SSL are designed to be general purpose protocols. This means that they can be used in a variety of applications under a variety of different circumstances. In some instances, however,it is better to have an application-specific protocol. This is a protocol that is designed with a particular purpose in mind. Such an application is the exchange of credit and payment information over the Internet. This type of information can be highly sensitive and the need to keep it confidential is great. For this reason the Secure Electronic Transaction protocol, or SET, was developed. SET was developed by a number of large players in the credit card and computer industries, including Visa, MasterCard, Microsoft, and Netscape. It was designed to handle the specific problems of transmitting credit and debit card information. For example, SET handles issues like validating credit card numbers, checking the customer’s authorization to use the credit card, authorizing the transaction with the bank, and processing the transaction. SET provides an integrated system that handles the entire transaction, including card authorization and finalization of the sale. SET has a number of mechanisms that protect the customer, the merchant, and the bank. For example, the protocol hides the actual credit card number from the merchant, instead sending it directly to the bank. Also, the bank does not know the actual merchandise purchased by the customer, protecting the privacy of the customer’s purchases. SET provides four basic services that protect transactions. Authentication: All the parties to the transaction are authenticated using digital signatures. We will learn more about digital signatures later when we discuss cryptography. Confidentiality: The transaction is encrypted so that Internet eavesdroppers can not capture the data and discover the details of the transaction. Message Integrity: The transaction can not be tampered with by attackers. Thus, they can not alter the account numbers or payment amounts involved in the transaction. Linkage: SET allows a message sent by one party to the transaction (either the customer, the merchant, or the bank) to contain an attachment that can be read only by another specified party. This allows the first party to verify that the attachment is correct without being able to read the contents of the attachment. This is very important for the privacy reasons stated above. SET has many advantages over plain SSL in that it covers the entire transaction from end to end. If plain SSL were used, the credit and validation information would be exposed at many different points along the way, leaving the information available for attackers or data thieves. This is, in fact, what happened in 1994 when an attacker broke into the Netcom Internet Service Provider and stole thousands of credit card numbers that were stored on Netcom’s computers. Although it seems like the perfect answer to credit exchanges on the Internet, use of SET in the real world has been slow in coming. Hopefully, in the near future, its use will increase as more companies implement it as part of the on-line ordering systems and more customers see its advantages and begin demanding it for their personal transactions. 8
Common Gateway Interface (CGI) • Allows web pages to do something instead of just returning pages • Extends the capabilities of a web server • Creates many exposures on server – Leaking information – Performing unauthorized transactions – Executing unintended programs • Common Mistakes – Misuse of command interpreters – Bad memory management – Passing unchecked parameters to system Information Security: The Big Picture - SANS GIAC © 2000 9 For all the hype surrounding it, HTTP is still pretty much a dumb protocol. By that I mean it really only does one thing – once you make a request for a web page, HTTP gets the page from the server and delivers it to your browser. Not too exciting, huh? Well, early users of the Web didn’t think so either. They wanted a way to interact with Web servers. They wanted the servers to do something instead of blindly returning pages. To make that happen, they invented the Common Gateway Interface, or CGI. CGI is a method of extending the web server’s abilities by executing programs on the server and returning the results back to the user. CGI scripts can generate pages dynamically based on the information obtained during their execution. Some examples of CGI programs that have been written include database transaction systems, computer games, financial transaction systems, and even vending machine ordering. However, CGI is a very primitive process for handling such interaction, and it may create a large number of vulnerabilities on the server in which it is used. For example, if the results of the CGI execution are not filtered before being sent to the user, the use of CGI programs can lead to the leakage of information about the system or its data. Because CGI has few built-in data checking mechanisms, it can be relatively easy for a user to falsify the information sent to the CGI program, increasing the potential for the execution of unauthorized or fraudulent transactions. Finally, since many CGI programs use underlying command interpreters (like Perl or a UNIX shell), the potential exists for an attacker to run programs not intended by the designers of the system. This is a popular method of gaining unauthorized administrative access on web servers. There are several common mistakes that many CGI developers make when writing their programs. The first is misuse of command interpreters. As mentioned before, many CGI programs use command interpreters that are called by the CGI program. Since there is no direct linkage between the CGIO program and the command interpreter, the interpreter has little way of validating the information it is being sent. If an attacker can find a way to pass random system commands to the interpreter they have the potential to successfully compromise the computer. Another common mistake is the lack of attention paid to memory management. As we will see later on when we discuss buffer overflows, a common method of attack is to send a program more information than it was designed to handle. If the information reaches a certain peak, or if it is carefully crafted, it has the ability to crash the server, often leaving the attacker with administrator privileges on the computer. Also, if the program itself does not pay close attention to the resources it is using, it can potentially consume all the available resources of the computer, again leaving it exposed to compromise. The final common mistake, and the one that is also the most preventable, is passing unchecked user input to CGI programs. Many of the most successful attacks have been based on the fact that a CGI program did not check the information entered by the user. In some cases, users are able to enter privileged system commands as input to web forms and the computer will blindly execute them without even a virtual glance. CGI programs can add a great deal of flexibility to your web site. But, like any enabling technology, it has a negative side that must be checked before proceeding blindly with its implementation. Also, CGI is a relatively old protocol, designed back when the web was still in its infancy. There are more modern alternatives to CGI that have addressed some of CGIs shortcomings. Unfortunately, they have also introduced some of their own. 9
Active Content • Programs that interact in a network environment • Java • ActiveX • Balancing risks vs. gain Information Security: The Big Picture - SANS GIAC © 2000 10 It used to be that computer programs were fairly simple. You ran them, they did some work on your computer, you got the results, and you were done. Then as network computing took off, we began to see client/server programs. You ran them, they interacted with a server somewhere on the network, they did the work on the server, you got the results, and you were done. Then with the advent of the web, we started seeing the use of CGI programs to do the work. However, with both client/server and CGI, much of the work was being done on the remote computer. This placed a very heavy burden on the server. It would be nice if the work could be performed locally on your machine, just like in the olden days. The server wouldn’t be so burdened and you could probably get the work done faster. Enter Active Content. “Active Content” is a term commonly used for program code that is embedded in the contents of a web page. When the page is accessed by a web browser, the embedded code is automatically downloaded and executed on the user’s workstation. Other terms that are sometimes used to describe active content include executable content, active code, or mobile code. Active Content can be thought of as CGI: The Next Generation. Two of the most common examples of active content are Java and ActiveX. Java is a programming and execution environment originally developed by Sun Microsystems. It was designed for developing programs that run on many different types of devices. One of the features of Java’s portability is that a special type of Java program, called an applet, can be embedded in a web page’s HTML code and run on a user’s machine. ActiveX is the term Microsoft uses for its active content components. ActiveX components are called “controls” and, like Java, are downloaded to the user’s computer where they are executed. What do Java applets & ActiveX controls do? Well, almost anything their designer can dream of. They can show 3-D animations, play videos, run simulations, wander through file systems, e-mail your friends, delete files, send your secret information to attackers, launch denial of service attacks, spread viruses… well, you get the picture. Active content can be extremely useful for unleashing the power of network communications, but there are a lot of security risks involved with these technologies. Because they run locally on your computer, they can often do almost anything you can do as an ordinary user. Of course, all these technologies claim to have security mechanisms to prevent evil things from happening, but almost all of them have flaws or bugs that allow bad things to happen anyway. We’ll examine the security models of Java and ActiveX in the next few slides. If running these types of programs is risky, why do it at all? Well, because they are so cool. And that’s basically what it comes down to. Many of these programs do incredibly useful, valuable, or entertaining things. The value they may add to an application or a web site is extremely high to users of the program. This points to one of the classic tradeoffs in security: balancing the risks of an action against the benefits of that action. We’ve all heard of the experiment where the mouse was given an electric shock every time it tried to get some cheese. Despite the risk of the shock the benefit of the cheese was so important to the mouse it was willing to risk it. It would be easy to tell people “turn off all active content in your browser” and many security people do just that. But that is unrealistic in today’s world. What is a more realistic approach is to turn off active content for most sites. When you have a site that you really need or want access to, turn it on temporarily for that site. Then, turn it off again when you leave the site. It’s a bit cumbersome, but it does give a nice balance of security and convenience. 10
Java & JavaScript • Java – executable code • JavaScript – instructions embedded in HTML • Security Model – Execution in a controlled environment (the “sandbox”) – Local apps have more access than network apps – Byte Code Verifier, Class Loader & Security Manager enforce security Information Security: The Big Picture - SANS GIAC © 2000 11 Java and JavaScript may sound similar, but in fact they are two different technologies. Java is a programming environment whose programs are compiled and distributed as bytecodes. The bytecodes are platform independent, so any computer with a Java runtime environment can execute the program regardless of the underlying platform or operating system. JavaScript, on the other hand, was designed to be embedded in HTML code. JavaScript is well suited for runtime interaction with a user, like dialog boxes, forms, etc. Java was designed with a security model in mind. The model states that remote code must run in a controlled, restricted environment. That environment is often called the “sandbox.” The sandbox limits what Java programs (or applets, as they are called) can do. For example, Java applets can not read, write, or delete files on the client system, create directories, obtain file information, create network connections to any machine other than that from which it came, or accept network connections. And these are just a few of the restrictions. Java doesn’t have to be run across the network, however. One of the great promises of Java is that it can be distributed as a regular software program. It can be installed on a user’s local disk and run as an ordinary application. In this mode, Java applications have greater access to network and system resources. The thinking behind this model is that a user can not verify the authenticity of an application located on a web server across a network, but that he or she should be aware of applications that they voluntarily load on their system. There are three components of Java security. The byte code verifier checks the bytecode for format, syntax, and correctness. The Class Loader installs Java components (called classes) and ensures that they are valid and do not interfere with each other. Finally, the Security Manager restricts the way an applet can operate and prevents dangerous operations. Despite the formal security model and the sandbox concept, Java programs and applets are not entirely secure, and, as with everything else, attackers have found a way around Java’s security features. However, it is still light years ahead of anything that came before it in terms of active content security. 11
ActiveX • Downloadable components to provide functionality • Can perform any action as user • “Security” comes from code signatures • Based on trust of developer/signer Information Security: The Big Picture - SANS GIAC © 2000 12 ActiveX is Microsoft’s technology answer to active content. In the ActiveX model, a web page has a number of objects called controls. When a user accesses a web page, the controls are downloaded to the user’s computer and executed. Like Java applets, ActiveX controls can be quite useful and entertaining. Unlike Java, however, ActiveX has no built-in security model and no restrictions on what actions can be performed. When an ActiveX control is downloaded to a user’s computer, it begins executing as that user. So, anything the user is able to do, like open and close files, delete directories, access the network, etc, the ActiveX control is able to do as well. This does not bode well for security. “Well,” you might say to yourself, “Microsoft certainly wouldn’t put out a technology that is that potentially dangerous without having some sort of security in front of it.” According to Microsoft, they did. What Microsoft did was to have each ActiveX control digitally signed by its publisher. The idea is that when a control is ready to run, a dialog box pops up telling you the name of its publisher and asking if you want to trust a control from that publisher. If you say “yes” the code will run. If you say “no” the code will not. The Microsoft folks say that this puts the amount of trust each user wants directly in the hands of the user. Unfortunately, most average users don’t understand the abstract security concepts of code signing, delegated trust and active controls. When they get to a web page that says “Click here to see the dancing pigs,” and then see the silly dialog box pop up, they don’t know who the publisher is, and no reason to think the control has any malicious intent. They just know they want to see the dancing pigs! And they want to see them so much that they just find the dialog box annoying. You can see where I am going with this. If people were aware of the security threats hostile ActiveX controls could introduce in their environment, and were knowledgeable about who the good and bad publishers are, the code signing approach might work. But in reality, it does little more than create a false sense of security for users. 12
Databases on the Web • Many Internet systems are just internal systems made public • Never designed with “outsiders” in mind • Databases contain valuable information • Attackers love valuable information • All Internet systems are vulnerable Information Security: The Big Picture - SANS GIAC © 2000 13 It’s no secret that over the last few years companies have rushed to get on the Internet. It is no longer a question of whether a company should be on the web, it’s how soon can they get there and what type of information their site should contain. In the beginning, most organization web sites were simply electronic versions of company brochures with product information, catalogs, etc. However, sites recently have become increasingly sophisticated. Many company sites allow you to order products, check order status, update customer and billing information, and offer all sorts of other interactive activities. The way most companies did this was not to build all new systems to support their web activities. No, most of them did this by opening up their internal systems to a web audience. This strategy sounds good from a development perspective. After all, why redevelop a million dollar ordering and billing database system when, for a fraction of that amount, you can just develop a web front end that will allow your customers to interact with your existing system? From a business perspective this makes perfect sense. But from a security perspective it is a nightmare. Why? Well, for one thing, most internal database systems were built with an internal audience in mind. Certain assumptions are made as to the knowledge and skill level of the user with respect to the information being handled. Once you open up these systems to people without knowledge of your systems and information, you begin to see problems that were never anticipated by the system’s designers. Second, most internal database systems were designed with the idea that internal people could be trusted. After all, our own people are OK, right? There may be some security controls, like IDs or passwords, but very often this is the extent of the security. Preventative measures like limiting the amount and type of information a person can see or tracking unauthorized or unusual activity are rarely put in place. Why would you need them when the assumption is that internal people can be trusted? Well, as we have seen previously, that is not always the case. But even if this assumption is correct, it falls flat when you begin to open up these databases to an Internet audience, many of whom may even be out to intentionally do you harm. Third, your internal organizational database systems contain a great deal of valuable and confidential information. Information that, if it got into the wrong hands, could have serious consequences for your business, your employees or your customers. And the sad fact is that attackers just love valuable information. It’s what they live for. So by simply having this information available presents an inviting target to an information thief. The final fact is that simply by being on the Internet your systems are vulnerable. If I’ve done nothing else in this course, I’ve tried to impress this fact upon you. So when you combine all these facts it leads to a single conclusion. Using internal database systems on the Internet presents some serious security concerns. You need to take special care with these systems to make sure they are as protected as possible, have as tightly controlled access as possible, and are monitored and maintained as much as possible. Use access control, authentication, firewalls, tripwires, anything at all you can think of to keep your information and systems safe and secure. 13
Risks of On-Line Commerce • Unauthorized Access • Fraud • Vandalism • Privacy Concerns • Similar to risks in real life Information Security: The Big Picture - SANS GIAC © 2000 14 As useful as on-line commerce may be, and as lucrative as it is for companies engaging in it, there are many risks involved from the perspectives of both the merchant and the customer. Some of these risks are unique to the on-line area while others are the same risks that we find in everyday life. First, there is the risk of unauthorized access. If you have a site that restricts areas of the system to only authorized uses,r you run the risk that an attacker will gain access to one of those areas. Or worse yet, there is the risk that one of your customers will gain access to an area of your service reserved for another customer. If, for example, you give different prices to different customers, this can be a big problem. Access can be controlled by the use of passwords or, better yet, token authentication, but it will always be a risk that you need to watch closely. The second risk is fraud. There have been many theories about whether the risk of fraud is higher or lower on the Internet. I feel that the risk of fraud is much higher on the Internet because of the nature of the relationship between the customer and the merchant. Many Internet transactions are generally anonymous. There is no prior relationship between the customer and the merchant. And, given all that we have learned about identification and address spoofing, there is generally no way to authenticate the identity of the customer or, sometimes, even the vendor. Because of the highly automated nature of most web transactions, it is becoming all too easy to fraudulently order goods and service over the Internet. Another problem is the risk of vandalism. If someone wants to vandalize my corner store they have to show up in person with their spray cans or their explosives and do their damage. On the Internet, however, vandalism can be performed from across the globe, anonymously, and with little fear of getting caught. Privacy concerns also abound in the on-line commerce area. What happens to my personal and financial information as it travels on the Internet? Will the company protect it once they get it? Are my browsing and purchasing habits being shared with other companies? Is it safe to give my credit card information to a company I’ve never dealt with before that may not even have a physical location? In the next section we’ll talk at length about privacy concerns on the Internet. Having said all this, however, we must take a look at how these concerns relate to similar concerns in real-life activities. Certainly, problems like fraud, vandalism and privacy enter into everyday, real-life transactions. Are those risks much greater just because they are on-line? Should I be less concerned about giving my credit card to the gas station attendant than I am about entering it onto a web page? You should probably treat both with equal concern. And as the web and Internet commerce become more and more a part of our everyday life, the two will become intertwined so much as to eventually have no essential difference. 14
Agenda • General Security Introduction • Telecommunications Fundamentals • Network Fundamentals • Network Security • World Wide Web Security • Information Secrecy & Privacy • Identification and Access Control • Programmatic Security • Conclusion Information Security: The Big Picture - SANS GIAC © 2000 15 When many people think of security they think of secrecy. In this section we will examine the secrecy and privacy. We will learn about cryptography, digital signatures, certificates, privacy and privacy policies. 15
Encryption • Scrambling information into a form that’s unreadable • Decryption – changing it back to a readable form • Process is enabled by using a “key” • Originally used for military applications • Now used for many non-military purposes Information Security: The Big Picture - SANS GIAC © 2000 16 Encryption can be an extremely complex topic to cover in depth, and a complete tutorial of the subject is far beyond the scope of this course, but there are a few basic concepts that any information security professional needs to be aware of in order to effectively perform his or her security functions. Encryption (also known as cryptography) is the act of scrambling information into a form that is unreadable by anyone except those who know how to unscramble the information. The scrambling process is enabled through the use of a special piece of information called a “key.” Much like the key that is used to lock and unlock a door, an encryption key contains the information that the encryption process uses to begin encoding the information. When the time comes to descramble the information, a key is once again used to enable this process. The descrambling process is more commonly known as “decryption.” Encryption can come in many forms. Many of us used a primitive form of encryption in school when we passed notes in class and used special codes so the teacher wouldn’t know what we were talking about. Baseball coaches use encryption when they give hand signals to batters and base runners on the field. And secretaries use encryption when they use shorthand to record dictated notes. While these examples may be somewhat whimsical, they are all examples of the use of encryption – scrambling information so it is unreadable unless you know how to descramble it. The teacher in class can’t read the passed note, the opposing baseball team can’t read the coach’s hand signals, and the secretary’s boss can’t read the shorthand notes unless they first learn the codes being used. In a more true to life example, governments and armies have long used encryption to hide their plans and communications from opposing forces. From the earliest schemes, like simple letter substitutions, to the use of the modern complex mathematical algorithms, encryption techniques have a long history of military and governmental use. In the past 30 years, however, encryption technology has found its way into use in many aspects of the lives of normal citizens, even if we do not know it. When we take money out of an ATM machine, the machine uses encryption to safely transmit information back to the home office of the bank. Encryption is also built into many cellular telephones in use today. When you purchase something on the Internet, the site you purchase from probably uses encryption to secure the information traveling between your PC and the web site. Encryption software is now available for use on your personal computer to protect the information stored on your hard disk or the e-mail you send. And some operating systems now have information encryption capabilities built right in, making it easier than ever to secure your information. The next few slides will discuss some of the more prevalent topics associated with encryption. 16
Basic Uses For Encryption • Secrecy • Authentication • Non-repudiation • Thwarting information attacks – Session Hijacking – Man in the Middle Information Security: The Big Picture - SANS GIAC © 2000 17 When most people think of encryption they think of keeping secrets. Certainly that was one of the earliest uses of encryption and continues to be one of the most prevalent uses. But encryption has many more uses than merely secrecy. On this slide we will examine some of those uses. As I said before, secrecy has always been a primary use for encryption. Armies and governments around the world have used encryption literally for centuries to keep secrets from the enemies (and sometimes even their friends). “But,” you may say, “I am not a government nor an army. Why do I need encryption?” There may be several reasons. Let’s start with the simple ones. Suppose you are the CEO of a large company, the Bajoran Widget Company. You have been thinking about merging with your largest competitor, the Ferengi Alliance. You want to send e-mail to the CEO of Ferengi discussing the merger, but you don’t want the information leaking to the press. You can use encryption to scramble the information. So even if the e-mail is intercepted, nobody will be able to use it. Or, on a more practical level, suppose Alice and Bob wish to discuss their political views about their country’s government. Unfortunately, their government has outlawed political speech and they can go to jail if they are caught having the discussion. Certainly they would want to keep their communications private so as to stay out of jail. By using encryption they can carry on the exchange of their political views without making those views available outside their own private conversation. More recent methods of encryption can be used to verify the identity of a person, a process known as authentication. Using a type of encryption known as public key cryptography (which we will discuss in more detail later). Alice and Bob can have their conversation as previously described. But in addition, Alice can verify that any messages she receives from Bob really were sent by Bob, and Bob can verify that messages he receives really came from Alice and not an imposter or government agent. This can be a very valuable tool when applied to areas like financial transactions or legal contracts, where verifying the sender of information can be extremely important. This type of sender verification can also be used if the alleged sender of a piece of information denies having sent it at all. Going back to the corporate merger example, suppose the Bajoran CEO and the Ferengi CEO are using encryption to exchange messages. The Bajoran CEO offers $3 billion to buy the Ferengi company and the Ferengi CEO accepts. If the time comes for the final payment and the Bajoran CEO claims to have only offered $3 million, not $3 billion, the Ferengi CEO can use encryption algorithms to prove the Bajoran CEO offered the higher amount. Finally, encryption can be used effectively to thwart many types of computer and network attacks. For example, if Alice and Bob are using encryption in their communications, attacks like Session Hijacking and Man in the Middle will be much more difficult to carry out. This is because each of them relies on the ability to observe the information stream, if even for a short time, before beginning the attack. If the connection is using encryption, the data stream will be filled with seemingly random information and will be of little use to the attacker. It is important to note that not all types of encryption have all these capabilities. Which features are available depends heavily on the type of encryption being used, how it is used, and the circumstances of its use. In the next few slides we will look at different types of encryption, how they operate, and how they can be used to protect communication and information. 17
Symmetric Cryptography • A.K.A. Secret Key Cryptography • Uses the same key for encryption and decryption • Advantage: very fast • Disadvantage: key distribution Information Security: The Big Picture - SANS GIAC © 2000 18 The most basic form of cryptography is called symmetric cryptography. Symmetric cryptography uses the same key for both the encryption and the decryption operation, hence the two operations are said to be symmetric. Symmetric cryptography is also called Secret Key Cryptography. In symmetric cryptography, if Alice wants to send a message to Bob she selects a key to encrypt the information. She then sends the message to Bob. Bob then uses the same key to decrypt the message. It’s clean, and it’s simple. Because of the mathematics involved, symmetric cryptography is also very fast, making it ideal for encrypting large amounts of information or encrypting information in real-time like phone or network communications. However, you can probably already spot a basic problem with symmetric cryptography. Alice and Bob must manage to come up with a way of sharing the key with each other without anyone else finding out what the key is. Now, if Alice and Bob live close to each other they can meet privately in a park, but if they are thousands of miles apart, this becomes more difficult. Key distribution is a basic drawback of symmetric cryptography. 18
Symmetric Cryptography Alice Bob “The key is ‘XYZZY’ “ Encrypt Decrypt “Hello” “Hello” JGS^&*#*s(& XYZZY XYZZY XYZZY XYZZY Information Security: The Big Picture - SANS GIAC © 2000 19 The picture in this slide illustrates how symmetric cryptography works in practice. First, Alice and Bob select a key to use for the encryption, as shown in the top half of the picture. Here the key they select is “XYZZY” Then, Alice wants to send an encrypted message to Bob. The message she wants to send is “Hello.” OK, not exactly top secret stuff, but this is just an example. Anyway, Alice sends her message through the encryption process using the key “XYZZY.” The encryption process scrambles the message into a sequence of seemingly random information. The encrypted message is then sent to Bob’s computer. The encryption process on Bob’s computer takes the encrypted message and again applies the “XYZZY” key to it to decrypt the message. If all goes well, the original “Hello” message should appear on Bob’s computer. If Bob wants to send an encrypted message back to Alice, he simply reverses the process with his computer doing the encryption and Alice’s computer handling the decryption chores. 19
Asymmetric Cryptography • A.K.A. Public Key Cryptography • Each person has 2 keys – public & private • Enables secrecy, authenticity, non-repudiation • Advantages: Key distribution • Disadvantages – Key Management – Speed Information Security: The Big Picture - SANS GIAC © 2000 20 In contrast to symmetric cryptography’s use of a single key for all parties involved in the communication, asymmetric cryptography uses two keys for each person – a private key, which is known only to that person, and a public key, which is published and made public for everyone to see. The mathematics involved ensure that a message encrypted with one key in the pair can only be decrypted using the other key on the pair. It’s the use of the two-key system which gives asymmetric cryptography the more commonly known name of public-key cryptography. Because half of the key pair is made publicly available for all to see, public-key cryptography does not suffer from many of the key distribution problems that symmetric cryptography has. If Alice wants to send Bob a message, she simply looks up his public key in a directory of everyone’s public keys, and encrypts the message with that key. When Bob receives the message he uses his private key (which is known only to him) to decrypt the message. There is no need for Alice and Bob to exchange keys in private as there is with symmetric cryptography. Public key cryptography also has many other properties that make it ideal for many applications. In addition to keeping information secret. It can be used to verify the identity of the sender of a message, and can be used to refute a denial by the sender of having sent the message in the first place. If you look back to the Bajoran Widget Company merger with the Ferengi Alliance you will see an example of these properties in action. However, despite all the great properties public-key cryptography has, it still has several drawbacks. First, although the key distribution problem is easier with public key cryptography, the issue of key management becomes larger. How do you list everyone’s public keys? If someone loses their keys, how do you tell everyone else to stop using it as well? How do you verify that a public key really belongs to a particular person? All these issues must be dealt with in order to implement a successful public key system. Another disadvantage with public key systems is that they are much slower than symmetric encryption systems. This makes them generally unsuitable for encryption of large amounts of information or encryption where speed is important like real-time communications. However, this may be overcome somewhat by using a combination of the two types of encryption. First, you create a key for use with a symmetric encryption system. Then, you can distribute that key using a public key encryption system. Once the recipient has the key, you then use a symmetric encryption system to encrypt the remainder of your message. Confused? Don’t feel bad. Encryption, particularly public key encryption can be a difficult topic to understand, but I believe you now have the basics to begin learning more. Encryption is becoming more and more of a requirement for serious information security applications; a solid understanding of how it works is definitely in order. There are just a couple of more points about encryption that you should be aware of. These points are discussed in the next few slides. 20

CÓ THỂ BẠN MUỐN DOWNLOAD