Information Security: The Big Picture – Part II

1 Information Security: The Big Picture - SANS GIAC © 2000 1 Information Security: The Big Picture – Part II Stephen Fried 2 Information Security: The Big Picture - SANS GIAC © 2000 2 International Standards & Policies • Trusted Computer System Evaluation Criteria (TCSEC – Orange Book) (1985) • Trusted Network Interpretation (TNI) (1987) •ITSEC In most industries there is a common set of rules and procedures that govern that industry. The rules may be imposed by the industry itself or they may be imposed by governmental and legal requirements. Examples of such standards in the US would be the Uniform Commercial Code that governs commercial transactions across the United States, or various national and local building codes that govern how structures are to be built. Many attempts have been made to standardize the practices and policies across the security industry as well. Unfortunately, because the information security field has been constantly evolving over the last several decades, there has been no unified consensus on what constitutes good security practice, how those practices should be defined, and how security should be measured. However, over the years several attempts have stood out as having considerable merit and weight, and thus have risen to the level of standards. In some areas, such as government computer security, these standards are mandatory. A side effect of these has been that private industry has picked up on them as well. One of the first standard attempts was the Trusted Computer System Evaluation Criteria, or TCSEC. It is also known as the Orange Book, because of the bright orange cover in its original printing. The TCSEC was developed by the US government in the 1980’s to provide a standard for manufacturers as to what security features to build into new government systems. It was also used as an evaluation criteria for the government to determine the degree of trust that can be placed in a computer system. The TCSEC divided security into four levels, labeled A through D. Some of the levels had several different sub-levels, so the highest rating a system could achieve was A1, while the lowest was level D. Despite several problems with certifying and implementing the requirements in systems that were actually usable, the TCSEC served its intended purpose for many years. One shortcoming of the TCSEC was that it was valid only for stand-alone computers. If a computer was connected to a network it was no longer eligible for TCSEC evaluation. Thus, in 1987 the US Government developed the Trusted Network Interpretation to the TCSEC, or TNI. The purpose of the TNI was to provide interpretations of the TCSEC for trusted computer and communication network systems. One aspect of the TCSEC that gained wide criticism was that it addressed primarily confidentiality issues and largely ignored integrity and availability issues. In addition, the TCSEC was a US government effort. Many countries, particularly in Europe, felt it did not address international issues. As a result, several European countries developed the International Technology Security Evaluation Criteria, or ITSEC. The ITSEC combined the Orange Book criteria with several of its European counterparts. In addition, it covered the integrity and availability issues that the TCSEC lacked. 3 Information Security: The Big Picture - SANS GIAC © 2000 3 International Standards & Policies • Common Criteria • BS7799 The Common Criteria represents the outcome of international efforts to align and develop the existing European and North American security evaluation criteria. The Common Criteria project harmonizes ITSEC, the CTCPEC (from Canada) and US Federal Criteria (FC) into the Common Criteria for Information Technology Security Evaluation (CC). The purpose of the Common Criteria is to evaluate products and systems and for stating security requirements in a standardized way internationally. It is increasingly replacing national and regional criteria with a worldwide set accepted by the International Standards Organization. Like the TCSEC, the Common Criteria has seven assurance levels, labeled EAL1 up to EAL7. Each level has a rough counterpart in the TCSEC. Currently, government agencies from Canada, France, Germany, the Netherlands, the United Kingdom and the United States sponsor the project. The latest version has now been ratified as ISO standard 15408. The latest entry in the standards effort has come from the United Kingdom. The BS7799 standard was developed in 1995 to provide a comprehensive set of controls comprising the best practices in information security. It is intended to serve as a single reference point for identifying the range of controls needed where information systems are used in industry and commerce. The latest revision to BS7799 was published in 1999. Of all the international standards efforts, BS7799 seems to be gaining the most support globally. 4 Information Security: The Big Picture - SANS GIAC © 2000 4 Due Care • Legalese – Conducting business in a non-negligent manner – Doing what any “reasonable person” would do under similar circumstances – Usual and customary conduct • English – Doing what everyone else does that is prudent and common to protect your interests In many aspects of security, you will meet up with the concept of due care. You can see some of the legal definitions in the slide, but, in short, due care is the concept of implementing security measures that are generally accepted to be prudent and common. If everybody is doing something, you should be doing it, too. Why is due care important? It gives you basic legal protection against negligence. If you have a security incident and, for some reason, you get sued, you will need to be able to show that you at least took the generally accepted and reasonable steps to secure your systems and information. This doesn’t mean you need to have done everything possible and installed all the latest and greatest security mechanisms, you just have to have taken the generally reasonable precautions. Proving your due care efforts will not guarantee that you will successfully defend against any lawsuits. It only means that you will probably not lose outright. Practicing Due Care standards also does not mean that you will have an extremely effective security defense. Remember, due care means you have taken basic, minimally accepted steps. It does not mean that you have done all you could have done. To have an effective security program you will have to do everything you can do to ensure complete coverage of all aspects of security protections. Due care is a good place to start, but you don’t want to stop there. 5 Information Security: The Big Picture - SANS GIAC © 2000 5 Policies • The cornerstone of your security effort • Should reflect your security stance • Let people know what’s expected • Define Rules of the Road – Responsibility – Accountability –Consequences • Should reflect your organization • Should change as circumstances change All organizations need to have a security policy. The security policy is where you define how your organization feels about security and how those feelings affect the members of the organization. In effect, the security policy becomes the cornerstone of the security effort. The security policy should reflect your security stance. Do you support strong, restrictive security efforts (as most corporations do) or is your environment more open (like many academic environments)? These answers will have a bearing on your overall stance and be reflected in your policies. Security policies also let people know what is expected of them. You can’t hold people responsible for following the rules if they don’t know what those rules are. Clearly defined policies, when combined with an effective awareness program, will go a long way toward enhancing your security efforts. Security policies effectively define the rules of the road for your organization. First, they define who has responsibility for what activities and who needs to take action based on those responsibilities. Second, they define who has accountability for activities. Often, the people or groups responsible for executing a function are acting on behalf of another group that has ultimate ownership and accountability for that activity. Your policies should acknowledge this duality and account for it. Finally, the policies should explain the consequences for not following the policies. These consequences may be monetary fines, disciplinary action, or even civil or criminal penalties. Your security policies should ultimately be a reflection of your organization, and you can learn a lot about an organization by examining its security policies. You can tell what areas are important to the organization and what areas they are less concerned about. You can learn if they are a permissive company or a restrictive one. You can tell how they feel about Internet access, personal use of e-mail and computers, handling of sensitive information, and a whole host of other organizational traits. No matter how much effort you put into creating your security policies, and how complete you may feel they are, you must leave room for change. Organizations change over time, and the way you feel about some aspects of security may not be the way you feel a year or two from now. You need to leave room in your policies for change. This change can come from within the security organization or it may come from your user or business partner community. Whatever the source, you need to account for change in your policies. 6 Information Security: The Big Picture - SANS GIAC © 2000 6 Security Through Obscurity • Hiding security mechanisms in an attempt to keep it secure • Use trade secrets, patents, NDAs, etc. • Will only delay, not stop, attacks – The Bad Guys already know how to get in – Provides a false sense of security • Be cautious, but not paranoid • Best security is open, available, and verifiable Many people believe that security is all about secrecy. The belief is that the more you keep information about your security mechanisms hidden, the harder it will be for potential attackers to be successful. This is commonly called “Security Through Obscurity.” We see this in many examples in real life. Software companies won’t discuss the details of their product’s security for fear it will be attacked. And some companies won’t discuss their security policies for fear of giving away company secrets. There are other ways to keep security information secret. Many products that use proprietary algorithms will use patents or trade secret laws to hide their mechanisms. Some companies use Non- Disclosure Agreements to protect their security processes from disclosure, and the list goes on. However, these efforts fail to realize one of the basic truths about security and security mechanisms: sometimes the best security mechanism is one that is out in plain view for all to see. The best security in use today, from locks, to access controls, to encryption systems has been used for a number of years. It has been reviewed by experts numerous times and been continuously refined based on their findings. There are no secret keys, no back doors, and all known attacks have been documented and hopefully corrected. Hiding the security mechanisms will only delay the bad guys for a while, if at all. Worse yet, reliance on Security Through Obscurity provides a false sense of security for the user. They may feel they are protected by the so-called “secret formula,” but in reality they are relying on a possibly unproven technology or mechanism. The moral of this story is that customers, vendors, and users of security should be cautious about the secrecy of the mechanisms. They should have a solid understanding of how it works and have a high comfort level that the mechanism fits its security needs. But they shouldn’t be too paranoid about the secrecy of the process. Again, the best security available is open and available. It has been verified by experts in the field and enjoyed extensive use and testing. Avoid Security Through Obscurity as much as possible. 7 Information Security: The Big Picture - SANS GIAC © 2000 7 Business Continuity Planning • “What if something bad happens?” • Business Continuity vs. Disaster Recovery • Multiple layers, multiple plans • Y2K – The Ultimate BCP An important part of your operational strategy should be the formulation of a business continuity plan. The business continuity plan answers the question, “What if something bad happened to my business?” The “something bad” may vary. It can be as simple as a disk crash or as serious as a large building fire, but it means some sort of interruption to your business, and you better be prepared. My office building sits right next to a major interstate highway in New Jersey. Three or four times a year some clown driving a tanker truck of dangerous chemicals decides to flip over his rig on the highway. Occasionally, we even have to evacuate the building until the chemicals are cleared away. Does my facility have a business continuity plan? You bet! Would we be able to continue our operation in the event we were not able to return to the building for a few days? Yes, we would. A well-planned business continuity plan enables you to anticipate emergencies instead of just reacting to them. You may often hear the terms “Business Continuity” and “Disaster Recovery” used interchangeably, and in many cases they mean virtually the same thing. However, there is a slight difference between the two. The term “Business Continuity” refers to the activities required to keep your organization running during a period of displacement or interruption of normal operations. Even if your building burns down, your customers still need their orders filled and your creditors still want their money. You need to be able to get back into operation as quickly as possible. That’s business continuity. “Disaster Recovery” is the process of rebuilding your operation or infrastructure after the disaster has passed. It is linked to your business continuity plan, but it is a separate and distinct process. Once you have enacted your business continuity plan to keep your business running during and after the disaster, you enact your disaster recovery plan to begin the process of getting your business back into “normal” operation. Business continuity planning can be an extremely complex task. For one thing, there are often multiple layers of planning. Starting simply, you may have a plan for a disk or tape failure in your data center. Next, you might plan for a major application to crash, potentially losing vital information. Next, you may plan for a major building fire or explosion in your data center. Then, things get interesting. What if there is a nuclear explosion and your town is uninhabitable for the next century or so? A wild example? Not if you work for the Chernobyl Power and Light Company. What if a truck bomb explodes in front of your building, killing dozens of your employees. Sound farfetched? Not if you work for the Federal government in Oklahoma City. True, these may not be everyday occurrences, but depending on your business, your location, or any number of other factors you may have to take these types of situations into account. A complete, well-thought-out business continuity plan will have multiple layers and multiple plans to handle a wide variety of situations. Perhaps the most widely known business continuity plan was the Y2K effort. Unless you have been living in a cave for the past five years or so, you know all about the Y2K planning effort. Many of you were probably involved in these efforts at your jobs. A major part of Y2K planning was preparing for the worst. What if the power failed? What if the communication lines went dead? All these scenarios had to be examined and dealt with, making Y2k possibly the largest business continuity planning effort in history. 8 Information Security: The Big Picture - SANS GIAC © 2000 8 BCP Steps 1. Define Scope 2. Business Impact Analysis (BIA) 3. Recovery Strategy 4. Recovery Plan 5. Implement the Plan 6. Test the Plan 7. Modify the Plan (continuously) There are a number of basic steps that have to be performed in order to create a good business continuity plan. First, you have to define the scope of the plan. Are you worried about a single application failure or a major network outage? If you make the scope too small you will need a separate plan for each individual element in your operation or organization. If you make the scope too large you risk getting bogged down in too much detail and interdependency between parts of the plan. Next, you must perform a Business Impact Analysis, or BIA. The BIA will help you determine the actual impact to your business the defined disaster will have. The BIA should account for all the processes and organizations upon which the target area relies as well as all the processes and organizations that rely on the target for their own operation. Once you have completed the BIA, you will have a good idea how much effort you need to put into business continuity plans for the target area as well as the areas of dependent operations. Next you need to define your recovery strategy. This is the statement of overall intent with respect to business continuity. Do you intend to recover fully or just write-off the lost part of the business? Do you want to use fully-redundant systems or just a few cold spares? These issues define how you will approach your BCP and DR efforts. Next you will develop the actual business continuity plan. This is the tactical, step by step process for enabling your business to continue during an emergency. In the plan you will define who is responsible for what activities, when those activities should take place, and how they should operate. The plan should be clear enough that anyone can pick it up and begin implementing it. Next, you need to implement the plan. No, this doesn’t mean creating an actual disaster to see if your plan works, but it does mean putting everything in place to make sure you are ready. Make sure people know what their responsibilities are and make sure all the resources and equipment you need to enact the plan are in place before you need them. When the disaster hits it is too late. Next, you need to test the plan. Again, you don’t need to create a real disaster, but you can simulate one well enough to see if your plan works. Test if the right people are in the right place at the right time, and make sure they have all the resources they need to get the job done. Testing the plan is the only way to ensure all will work well when an actual disaster strikes. Once you test the plan you will undoubtedly find things that did not go strictly according to plan. Or, you may find that some conditions have changed since the plan was originally developed. For these reasons you need to continuously modify the plan, keeping up to date with whatever changes need to be accounted for. By following these simple steps, you will be well on the way toward creating a robust business continuity plan. 9 Information Security: The Big Picture - SANS GIAC © 2000 9 User and Role Based Security (1) • User Based – Access is assigned per user – Easy to understand – Good for small groups of users & objects • Role Based – Access is assigned by “roles” – Better for large numbers of users/objects There are many methods of assigning access to systems and information in a computer system or network. One method is called “User Based” security. In user based security, each user is given a unique identity in the system. Each time the user tries to access an object, for example a file or a disk drive, the user’s identity is checked against a list of the users that are allowed to access that object. If the user is on the list, they pass. If the user is not on the list, their access is denied. User based security works well in a variety of situations. It is also the easiest to understand. For each object, all you need to do is come up with a list of people that are allowed to access that object. Unfortunately, user-based access security begins to break down when you reach a high level of objects and a large number of people that need to access those objects. For example, suppose you have ten users and ten objects that they need to access. In the worst case (assuming you want the tightest security possible) you would need 100 specifications (10 * 10) to make sure you covered each person and each object. Maybe a hundred isn’t that bad, but if you have 150,000 users and a couple of hundred thousand objects, it gets unmanageable pretty fast. One answer to this problem is called “Role Based” security. With role-based security, each user is assigned not only an ID on the system, but also a role to play. Each object is then given a list of what user roles are allowed to access that object. For example, suppose you had roles for Secretary, Engineer, and Accountant. Each user in your system would be assigned to one of those three roles. Each object in the system would then be tagged as being accessible by Secretaries, Accountants, or Engineers. You will still need to tag each item as to which role is permitted access, but role-based access makes it a lot easier. Using our previous example of ten users and ten objects, we will now split the users into the 3 roles. Assuming there are 3 secretaries, 3 engineers, and 4 accountants, each object will then only need at most 3 entries, one each for Secretaries, engineers, and accountants. This leaves a maximum of 30 entries, rather than the 100 in the previous example. 10 Information Security: The Big Picture - SANS GIAC © 2000 10 User and Role Based Security (2) • As people change jobs, “roles” change • As people enter and leave organization, roles are assigned and removed • As objects and applications change, roles can be re-assigned accordingly One of the big advantages of role-based security is that by assigning someone to a particular group, access permissions to objects can be automatically assigned without changing any of the permissions on the objects themselves. If a file is permitted to be viewed only by the Accountant group, by assigning a user to the Accountant group you are automatically giving them permission to that file. The better you determine and assign your roles, the better you can control access to your resources. Second, as people change jobs and roles in your organization their access changes automatically. When the secretary gets promoted to the Accounting department, by changing their role from Secretary to Accountant, you automatically give them access to a completely different set of objects quickly and easily. Third, as people enter and leave the organization, their role in the access control mechanism will be fairly straightforward and clear. Depending on the job they are doing, you assign them a role and off they go. There is no need to determine what resources they need to access, that has already been predetermined. Finally, as objects and applications change, you can change the user roles that are allowed to access those objects and applications. If you decide that the Engineers no longer need access to an object, you don’t need to figure out what users are Engineers, you just remove access to the Engineer role. Role-based security is not the last word in access control, but when used effectively it can be a valuable tool in controlling access to resources on your network. [...]... everything Hdr Data Information Security: The Big Picture - SANS GIAC © 2000 29 The data packet has two basic parts, the header and the payload The header is the part of the packet that contains information about the packet itself – where it has come from, where it is going, and what kind of information it contains The payload is the data or information the packet is carrying There is a lot of information. .. you pull the string tight and talk into one of the cans, the sound can be heard through the other can The can you talk into is the transmitter, the can you listen from is the receiver, and the string is the medium How does it work? The sound waves from your voice make the can vibrate That vibration is transferred through the string and sent to the other can The receiving can then repeats the vibrations... simultaneously The diagram in the slide illustrates this point The two phones in the picture need to communicate The call goes to the Central Office and the switch at the CO creates a circuit (here labeled Circuit 1) between the two phones The circuit stays active until the call is completed Plain and simple The next time the two phones need to communicate, the call once again goes to the central office... represented a different phone When a person needed to make a call, they would contact the operator at the central office and tell them the name of the person they wanted to talk to The operator would then connect the caller’s plug to the plug of the person being called and, voila!, they were talking The concept here is a change in the nature of the call Before, you had fixed endpoints and a dedicated line... hooked to the same CO, there needed to be a way to allow people connected to different COs to talk to one another This was done by hooking the COs together The diagram shows how this setup worked Call #1 in the diagram shows the simplest scenario A person connected to the CO wants to talk to another person on the same CO The operator at that CO connects the lines for the two phones and off they go Call... represent that string It then sends those ones and zeroes to the modem The modem then converts the digital information into an analog format Once the data is converted to an analog format, it is sent over the phone line to the receiving modem The receiving side does just the opposite of the sending side It takes the analog signal from the phone line and converts it back to the digital form that computers... of these forms can be distilled down to the basic “cans and string” model 15 Early Telephone Communications Information Security: The Big Picture - SANS GIAC © 2000 16 The next stop on our tour of communications is simple phone transmission In many ways, it is the same as the Cans and String model, except the cans are replaced by the phones and the string is replaced by copper wire Like the can, the. .. need three elements – a transmitter, a medium, and a receiver The transmitter is the device that creates the communication The medium is the device that carries the communication from the source to the destination The receiver is the device that receives the communication Without these three elements there is no communication Basic communication can best be demonstrated through the use of two cans... telephone picks up the voice of the person making the call It then transmits that voice over the copper wire medium to the receiving phone on the other end Just like the Cans and String model, we have a transmitter, a medium, and a receiver There is a slight difference with phone over Cans and String With the Cans and String, only one person can talk at a time Otherwise the sound gets garbled on the string... at another CO The first person contacts the operator at his CO and tells her he needs to talk to a person in another city The operator looks up the CO where the second person is located and contacts the operator at that CO Once the second operator is called the connection is patched through to the second CO The second operator looks up what plug belongs to the person being called and patches the line . Information Security: The Big Picture - SANS GIAC © 2000 1 Information Security: The Big Picture – Part II Stephen Fried 2 Information Security: The Big. call, they would contact the operator at the central office and tell them the name of the person they wanted to talk to. The operator would then connect the