Security Policies and Procedures

Security Policies and Procedures
Minder Chen, Ph.D.

References Information Security Management Handbook, 4th edition, edited by Micki Krause and Harold F. Tipton. The SANS Security Policy Project Sample Policies and Procedures

Policy and Procedure A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an “Acceptable Use” policy would cover the rules and regulations for appropriate use of the computing facilities. A standard is typically a collections or system-specific or procedural-specific requirements that must be meet by everyone. For example, you might have a standard that describes to how to harden a Windows NT workstation for placement on an external (DMZ) network. People must follow this standard exactly if they wish to install a Windows NT workstation on an external network segment. A guideline is typically a collection of system specific or procedural specific “suggestions” for best practice. They are not requirements to be met, but are strongly recommended. Effective security policies make frequent references to standards and guidelines that exist within an organization.

Information Security Management Handbook, Fourth Edition by Micki Krause (Editor), Harold F. Tipton (Editor) The CISSP Prep Guide: Mastering the Ten Domains of Computer Security by Ronald L. Krutz, Russell Dean Vines, Edward M. Stroz CISSP All-in-One Exam Guide by Shon Harris

SANS Security Policy Project at http://www. sans
Policy Primer at Sample Policies and Procedures at HIPAA FAQ at

Microsoft Resources Microsoft Virus Safety Line Email Web Sites
In the U.S PC SAFETY Outside the U.S. please contact your local Microsoft subsidiary To Report Suspected Vulnerabilities in Microsoft Products – Microsoft Security Response Center Web Sites Microsoft Security Toolkit Windows Update

Executive Order on Critical Infrastructure Protection Executive Order Critical Infrastructure Protection in the Information Age By the authority vested in me as President by the Constitution and the laws of the United States of America, and in order to ensure protection of information systems for critical infrastructure, including emergency preparedness communications, and the physical assets that support such systems, in the information age, it is hereby ordered as follows:

Section 1. Policy. (a) The information technology revolution has changed the way business is transacted, government operates, and national defense is conducted. Those three functions now depend on an interdependent network of critical information infrastructures. The protection program authorized by this order shall consist of continuous efforts to secure information systems for critical infrastructure, including emergency preparedness communications, and the physical assets that support such systems. Protection of these systems is essential to the telecommunications, energy, financial services, manufacturing, water, transportation, health care, and emergency services sectors.

Level 2 - Major Enterprises
2.1. Responsibility: Who in an enterprise should be responsible for IT security? How often should that person brief the CEO? What role should the Board of Directors play in oversight of IT security? Should the Board require an outside audit and, if so, how often and from whom? 2.2. Best Practices: Where should the CEO, Board and/or auditors obtain guidance on best practices or standards to use in IT security self-evaluations and IT security policy development? 2.3. Disclosure: What information about IT security should the corporation disclose to its stockholders, to its creditors, to its auditors, to its Board 2.4. Enterprise Wide IT Security Policy: Should enterprises be required by their Boards of Directors or Auditors to have a regularly updated policy statement on IT security practices? Should enterprises be required by Boards and Auditors to employ software to enforce their IT policy? 2.5. Awareness: Should enterprises require employee participation in regular IT security awareness training? Where should enterprises obtain assistance in developing such training?

Continued… 2.6. Insider Threats: How can a balance be struck between preventing insiders from damaging the enterprise by mis-using its IT systems, and respecting the legitimate privacy concerns of employees? 2.7. Partners and Supply Chain: What IT security risks does an enterprise run from its relationships with its partners and supply chain? How can those relationships enhance or degrade IT security? 2.8. Event Reporting: What IT security events should an enterprise report and to whom? 2.9. Threat and Vulnerability Information: How should an enterprise learn about and decide how to react to IT security threats and vulnerabilities? How can an enterprise evaluate the numerous software "patches" distributed to it by its IT vendors? IT Vendors: To what extent should an enterprise "out source" its IT security functions? How can IT security vendors be evaluated? How can an enterprise act to improve the security of the IT products and services it procures? 2.11. Risk Management and Insurance: How can an enterprise evaluate the appropriate level of IT security spending or the return on investment in IT security? What role can insurance play in IT security for an enterprise?

Ten Immutable Laws of Security
If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore If a bad guy can alter the OS on your computer, it’s not your computer anymore If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore If you allow a bad guy to upload programs to your web site, it’s not your site anymore Weak passwords trump strong security A machine is only as secure as the administrator is trustworthy Encrypted data is only as secure as the decryption key An out of date virus scanner is only marginally better than no virus scanner at all Absolute anonymity isn't practical, in real life or on the web Technology is not a panacea Law #1: If a bad guy can persuade you to run his program on your computer, it's not your computer anymore. It's an unfortunate fact of computer science: when a computer program runs, it will do what it's programmed to do, even if it's programmed to be harmful. When you choose to run a program, you are making a decision to turn over control of your computer to it. Once a program is running, it can do anything, up to the limits of what you yourself can do on the machine. It could monitor your keystrokes and send them to a web site. It could open every document on the machine, and change the word "will" to "won't" in all of them. It could send rude s to all your friends. It could install a virus. It could create a "back door" that lets someone remotely control your machine. It could dial up an ISP in Katmandu. Or it could just reformat your hard drive. That's why it's important to never run, or even download, a program from an untrusted source – and by "source", I mean the person who wrote it, not the person who gave it to you. There's a nice analogy between running a program and eating a sandwich. If a stranger walked up to you and handed you a sandwich, would you eat it? Probably not. How about if your best friend gave you a sandwich? Maybe you would, maybe you wouldn't – it depends on whether she made it or found it lying in the street. Apply the same critical thought to a program that you would to a sandwich, and you'll usually be safe. Law #2: If abad guy can alter the operating system on your computer, it's not your computer anymore. In the end, an operating system is just a series of ones and zeroes that, when interpreted by the processor, cause the machine to do certain things. Change the ones and zeroes, and it will do something different. Where are the ones and zeroes stored? Why, on the machine, right along with everything else! They're just files, and if other people who use the machine are permitted to change those files, it's "game over". To understand why, consider that operating system files are among the most trusted ones on the computer, and they generally run with system-level privileges. That is, they can do absolutely anything. Among other things, they're trusted to manage user accounts, handle password changes, and enforce the rules governing who can do what on the computer. If a bad guy can change them, the now-untrustworthy files will do his bidding, and there's no limit to what he can do. He can steal passwords, make himself an administrator on the machine, or add entirely new functions to the operating system. To prevent this type of attack, make sure that the system files (and the registry, for that matter) are well protected. (The security checklists on the Microsoft Security web site will help you do this). Law #3: If a bad guy has unrestricted physical access to your computer, it's not your computer anymore. Oh, the things a bad guy can do if he can lay his hands on your computer! Here's a sampling, going from Stone Age to Space Age: He could mount the ultimate low-tech denial of service attack, and smash your computer with a sledgehammer. He could unplug the computer, haul it out of your building, and hold it for ransom. He could boot the computer from a floppy disk, and reformat your hard drive. But wait, you say, I've configured the BIOS on my computer to prompt for a password when I turn the power on. No problem – if he can open the case and get his hands on the system hardware, he could just replace the BIOS chips. (Actually, there are even easier ways). He could remove the hard drive from your computer, install it into his computer, and read it. He could make a duplicate of your hard drive and take it back his lair. Once there, he'd have all the time in the world to conduct brute-force attacks, such as trying every possible logon password. Programs are available to automate this and, given enough time, it's almost certain that he would succeed. Once that happens, Laws #1 and #2 above apply He could replace your keyboard with one that contains a radio transmitter. He could then monitor everything you type, including your password. Always make sure that a computer is physically protected in a way that's consistent with its value – and remember that the value of a machine includes not only the value of the hardware itself, but the value of the data on it, and the value of the access to your network that a bad guy could gain. At a minimum, business-critical machines like domain controllers, database servers, and print/file servers should always be in a locked room that only people charged with administration and maintenance can access. But you may want to consider protecting other machines as well, and potentially using additional protective measures. If you travel with a laptop, it's absolutely critical that you protect it. The same features that make laptops great to travel with – small size, light weight, and so forth – also make them easy to steal. There are a variety of locks and alarms available for laptops, and some models let you remove the hard drive and carry it with you. You also can use features like the Encrypting File System in Windows 2000 to mitigate the damage if someone succeeded in stealing the computer. But the only way you can know with 100% certainty that your data is safe and the hardware hasn't been tampered with is to keep the laptop on your person at all times while traveling. Law #4: If you allow a bad guy to upload programs to your web site, it's not your web site any more. This is basically Law #1 in reverse. In that scenario, the bad guy tricks his victim into downloading a harmful program onto his machine and running it. In this one, the bad guy uploads a harmful program to a machine and runs it himself. Although this scenario is a danger anytime you allow strangers to connect to your machine, web sites are involved in the overwhelming majority of these cases. Many people who operate web sites are too hospitable for their own good, and allow visitors to upload programs to the site and run them. As we've seen above, unpleasant things can happen if a bad guy's program can run on your machine. If you run a web site, you need to limit what visitors can do. You should only allow a program on your site if you wrote it yourself, or if you trust the developer who wrote it. But that may not be enough. If your web site is one of several hosted on a shared server, you need to be extra careful. If a bad guy can compromise one of the other sites on the server, it's possible he could extend his control to the server itself, in which he could control all of the sites on it – including yours. If you're on a shared server, it's important to find out what the server administrator's policies are. (By the way, before opening your site to the public, make sure you've followed the security checklists for IIS 4.0 and IIS 5.0). Law #5: Weak passwords trump strong security. The purpose of having a logon process is to establish who you are. Once the operating system knows who you are, it can grant or deny requests for system resources appropriately. If a bad guy learns your password, he can log on as you. In fact, as far as the operating system is concerned, he is you. Whatever you can do on the system, he can do as well, because he's you. Maybe he wants to read sensitive information you've stored on your computer, like your . Maybe you have more privileges on the network than he does, and being you will let him do things he normally couldn't. Or maybe he just wants to do something malicious and blame it on you. In any case, it's worth protecting your credentials. Always use a password – it's amazing how many accounts have blank passwords. And choose a complex one. Don't use your dog's name, your anniversary date, or the name of the local football team. And don't use the word "password"! Pick a password that has a mix of upper- and lower-case letters, number, punctuation marks, and so forth. Make it as long as possible. And change it often. Once you've picked a strong password, handle it appropriately. Don't write it down. If you absolutely must write it down, at the very least keep it in a safe or a locked drawer – the first thing a bad guy who's hunting for passwords will do is check for a yellow sticky note on the side of your screen, or in the top desk drawer. Don't tell anyone what your password is. Remember what Ben Franklin said: two people can keep a secret, but only if one of them is dead. Finally, consider using something stronger than passwords to identify yourself to the system. Windows 2000, for instance, supports the use of smart cards, which significantly strengthens the identity checking the system can perform. You may also want to consider biometric products like fingerprint and retina scanners. Law #6: A machine is only as secure as the administrator is trustworthy. Every computer must have an administrator: someone who can install software, configure the operating system, add and manage user accounts, establish security policies, and handle all the other management tasks associated with keeping a computer up and running. By definition, these tasks require that he have control over the machine. This puts the administrator in a position of unequalled power. An untrustworthy administrator can negate every other security measure you've taken. He can change the permissions on the machine, modify the system security policies, install malicious software, add bogus users, or do any of a million other things. He can subvert virtually any protective measure in the operating system, because he controls it. Worst of all, he can cover his tracks. If you have an untrustworthy administrator, you have absolutely no security. When hiring a system administrator, recognize the position of trust that administrators occupy, and only hire people who warrant that trust. Call his references, and ask them about his previous work record, especially with regard to any security incidents at previous employers. If appropriate for your organization, you may also consider taking a step that banks and other security-conscious companies do, and require that your administrators pass a complete background check at hiring time, and at periodic intervals afterward. Whatever criteria you select, apply them across the board. Don't give anyone administrative privileges on your network unless they've been vetted – and this includes temporary employees and contractors, too. Next, take steps to help keep honest people honest. Use sign-in/sign-out sheets to track who's been in the server room. (You do have a server room with a locked door, right? If not, re-read Law #3). Implement a "two person" rule when installing or upgrading software. Diversify management tasks as much as possible, as a way of minimizing how much power any one administrator has. Also, don't use the Administrator account – instead, give each administrator a separate account with administrative privileges, so you can tell who's doing what. Finally, consider taking steps to make it more difficult for a rogue administrator to cover his tracks. For instance, store audit data on write-only media, or house System A's audit data on System B, and make sure that the two systems have different administrators. The more accountable your administrators are, the less likely you are to have problems. Law #7:Encrypted data is only as secure as the decryption key. Suppose you installed the biggest, strongest, most secure lock in the world on your front door, but you put the key under the front door mat. It wouldn't really matter how strong the lock is, would it? The critical factor would be the poor way the key was protected, because if a burglar could find it, he'd have everything he needed to open the lock. Encrypted data works the same way – no matter how strong the cryptoalgorithm is, the data is only as safe as the key that can decrypt it. Many operating systems and cryptographic software products give you an option to store cryptographic keys on the computer. The advantage is convenience – you don't have to handle the key – but it comes at the cost of security. The keys are usually obfuscated (that is, hidden), and some of the obfuscation methods are quite good. But in the end, no matter how well-hidden the key is, if it's on the machine it can be found. It has to be – after all, the software can find it, so a sufficiently-motivated bad guy could find it, too. Whenever possible, use offline storage for keys. If the key is a word or phrase, memorize it. If not, export it to a floppy disk, make a backup copy, and store the copies in separate, secure locations. (All of you administrators out there who are using Syskey in "local storage" mode – you're going to reconfigure your server right this minute, right?) Law #8: Anout of date virus scanner is only marginally better than no virus scanner atall. Virus scanners work by comparing the data on your computer against a collection of virus "signatures". Each signature is characteristic of a particular virus, and when the scanner finds data in a file, , or elsewhere that matches the signature, it concludes that it's found a virus. However, a virus scanner can only scan for the viruses it knows about. It's vital that you keep your virus scanner's signature file up to date, as new viruses are created every day. The problem actually goes a bit deeper than this, though. Typically, a new virus will do the greatest amount of damage during the early stages of its life, precisely because few people will be able to detect it. Once word gets around that a new virus is on the loose and people update their virus signatures, the spread of the virus falls off drastically. The key is to get ahead of the curve, and have updated signature files on your machine before the virus hits. Virtually every maker of anti-virus software provides a way to get free updated signature files from their web site. In fact, many have "push" services, in which they'll send notification every time a new signature file is released. Use these services. Also, keep the virus scanner itself – that is, the scanning software – updated as well. Virus writers periodically develop new techniques that require that the scanners change how they do their work. Law #9:Absolute anonymity isn't practical, in real life or on the web. All human interaction involves exchanging data of some kind. If someone weaves enough of that data together, they can identify you. Think about all the information that a person can glean in just a short conversation with you. In one glance, they can gauge your height, weight, and approximate age. Your accent will probably tell them what country you're from, and may even tell them what region of the country. If you talk about anything other than the weather, you'll probably tell them something about your family, your interests, where you live, and what you do for a living. It doesn't take long for someone to collect enough information to figure out who you are. If you crave absolute anonymity, your best bet is to live in a cave and shun all human contact. The same thing is true of the Internet. If you visit a web site, the owner can, if he's sufficiently motivated, find out who you are. After all, the ones and zeroes that make up the web session have be able to find their way to the right place, and that place is your computer. There are a lot of measures you can take to disguise the bits, and the more of them you use, the more thoroughly the bits will be disguised. For instance, you could use network address translation to mask your actual IP address, subscribe to an anonymizing service that launders the bits by relaying them from one end of the ether to the other, use a different ISP account for different purposes, surf certain sites only from public kiosks, and so on. All of these make it more difficult to determine who you are, but none of them make it impossible. Do you know for certain who operates the anonymizing service? Maybe it's the same person who owns the web site you just visited! Or what about that innocuous web site you visited yesterday, that offered to mail you a free $10 off coupon? Maybe the owner is willing to share information with other web site owners. If so, the second web site owner may be able to correlate the information from the two sites and determine who you are. Does this mean that privacy on the web is a lost cause? Not at all. What it means is that the best way to protect your privacy on the Internet is the same as the way you protect your privacy in normal life - through your behavior. Read the privacy statements on the web sites you visit, and only do business with ones whose practices you agree with. If you're worried about cookies, disable them. Most importantly, avoid indiscriminate web surfing - recognize that just as most cities have a bad side of town that's best avoided, the Internet does too. But if it's complete and total anonymity you want, better start looking for that cave. Law #10:Technology is not a panacea. Technology can do some amazing things. Recent years have seen the development of ever-cheaper and more powerful hardware, software that harnesses the hardware to open new vistas for computer users, as well as advancements in cryptography and other sciences. It's tempting to believe that technology can deliver a risk-free world, if we just work hard enough. However, this is simply not realistic. Perfect security requires a level of perfection that simply doesn't exist, and in fact isn't likely to ever exist. This is true for software as well as virtually all fields of human interest. Software development is an imperfect science, and all software has bugs. Some of them can be exploited to cause security breaches. That's just a fact of life. But even if software could be made perfect, it wouldn't solve the problem entirely. Most attacks involve, to one degree or another, some manipulation of human nature – this is usually referred to as social engineering. Raise the cost and difficulty of attacking security technology, and bad guys will respond by shifting their focus away from the technology and toward the human being at the console. It's vital that you understand your role in maintaining solid security, or you could become the chink in your own systems' armor. The solution is to recognize two essential points. First, security consists of both technology and policy – that is, it's the combination of the technology and how it's used that ultimately determines how secure your systems are. Second, security is journey, not a destination – it isn't a problem that can be "solved" once and for all; it's a constant series of moves and countermoves between the good guys and the bad guys. The key is to ensure that you have good security awareness and exercise sound judgment. There are resources available to help you do this. The Microsoft Security web site, for instance, has hundreds of white papers, best practices guides, checklists and tools, and we're developing more all the time. Combine great technology with sound judgment, and you'll have rock-solid security.

Ten Immutable Laws of Security Administration
Nobody believes anything bad can happen to them, until it does. Security only works if the secure way also happens to be the easy way. If you don't keep up with security fixes, your network won't be yours for long. It doesn't do much good to install security fixes on a computer that was never secured to begin with. Eternal vigilance is the price of security. There really is someone out there trying to guess your passwords. The most secure network is a well-administered one. The difficulty of defending a network is directly proportional to its complexity. Security isn't about risk avoidance; it's about risk management. Technology is not a panacea Law #1: Nobody believes anything bad can happen to them, until it does. Many people are unwilling partners in computer security. This isn't because they're deliberately trying to endanger the network – they simply have a different agenda than you do. The reason your company has a network is because it lets your company conduct business, and your users are focused on your company's business rather than on the vagaries of computer security. Many users can't conceive why someone might ever go to the trouble of sending them a malicious or trying to crack their password, but an attacker only needs to find one weak link in order to penetrate your network. As a result, relying on voluntary measures to keep your network secure is likely to be a non-starter. You need the authority to mandate security on the network. Work with your company's management team to develop a security policy that spells out specifically what the value of the information on your network is, and what steps the company is willing to take to protect it. Then develop and implement security measures on the network that reflect this policy. Law #2: Security only works if the secure way also happens to be the easy way. As we discussed in Law #1, you need the authority to mandate security on the network. However, the flip side is that if you turn the network into a police state, you're likely to face an uprising. If your security measures obstruct the business processes of your company, your users may flout them. Again, this isn't because they're malicious – it's because they have jobs to do. The result could be that the overall security of your network would actually be lower after you implemented more stringent policies. There are three key things you can do to prevent your users from becoming hackers' unwitting accomplices. Make sure your company's security policy is reasonable, and strikes a balance between security and productivity. Security is important, but if your network is so secure that nobody can get any work done, you haven't really performed a service for your company. Look for ways to make your security processes have value to your users. For instance, if you have a security policy that calls for virus signatures to be updated once a week, don't expect your users to do the updates manually. Instead, consider using a "push" mechanism to do it automatically. Your users will like the idea of having up to date virus scanners, and the fact that they didn't have to do anything makes it doubly popular. In cases where you must impose a restrictive security measure, explain to your users why it's necessary. It's amazing what people will put up with when they know it's for a good cause. Law #3: If you don't keep up with security fixes, your network won't be yours for long. It's a fact of life: software contains bugs. Some of these bugs involve security, and there's a huge number of disreputable people actively searching for them in the hope of using them against you. No matter how secure your network is today, it could all change overnight if a particularly serious vulnerability is discovered. It could even happen if a series of less-serious vulnerabilities are discovered that can be used in tandem, in an attack that's greater than the sum of its parts. It's vital that you stay on top of the tactical world of security, and plug the holes in your armor whenever you find one. The good news is that there are a lot of tools to help you do this. Security mailing lists like NTBugTraq, BugTraq and Win2kSecAdvice are a great way to learn about the latest attacks. In addition, many software vendors (including Microsoft) have developed security response processes to investigate and fix vulnerabilities. Make sure you check for new bulletins frequently. (Microsoft provides a notification service that enables subscribers to receive all security bulletins via within minutes of publication, and also has developed a tool that lets IIS 5.0 servers constantly verify that the latest patches are installed). And don't forget service packs -- they're one of the best ways to ensure that you're as secure as possible. Law #4: It doesn't do much good to install security fixes on a computer that was never secured to begin with. Imagine you're a Visigoth and you're reconnoitering a castle that you and the rest of the horde plan to sack and pillage. From your hideout in the woods, you see that there's a veritable army of serfs performing maintenance on the castle's defenses – they're patching chinks in the mortar, sharpening the points on the chevaux-de-frise, and refilling the vats of boiling oil. Now you sneak around to the back of the castle and discover – that there is no back of the castle! They never built it! How much good is all that maintenance on the front of the castle going to do when you and the horde attack from the rear? Similarly, what good are security patches if you've got a weak administrator password on your domain controller? Or if you've shared out your web server's hard drive to the world? Or if you've enabled the Guest account on your company's payroll server? The time to lock down a machine is before it's ever connected to the network. If this sounds like too much work, consider that, if a bad guy compromises the machine, you're going to need to rebuild it anyway. Microsoft provides security checklists that make it easy to lock down your machines, as well as a security lockdown tool that you can use to automatically secure IIS 5.0 web servers. It doesn't get much easier than that. Law #5: Eternal vigilance is the price of security. OK, so you read Laws 3 and 4 and patted yourself on the back. You've done everything right -- you secured your machines before putting them into production, you've got the latest service pack installed, and you've been diligently applying security patches. You must be secure, right? Well, maybe, but maybe not. Even under these conditions, a malicious user could attack your network. For instance, he could mount flooding attacks, and simply send huge numbers of legitimate requests to a server in order to use all of its resources. Or he could conduct brute-force password-guessing attacks. Neither security patches nor machine configurations can totally prevent attacks like these, because the bad guy's activities, although malicious, aren't invalid. You do have a weapon, though – the event logs. They'll give you information about who's using system resources, what they're doing, and whether the operation succeeded or failed. Once you know who's doing what, you can take appropriate action. If someone is flooding your system, you can block requests from their IP addresses. If someone is trying to brute-force your accounts, you can disable ones that are at risk, set up "honey traps" to catch him, or increase the lockout interval on the accounts. In sum, the event log lets you gauge the health of your systems, and determine the right course of action to keep them safe. Be careful when configuring the event logs – you can easily audit so many events that you'll exceed your ability to analyze the data. Carefully plan what events you need to log, and whether you need to audit only successes, failures or both. The security checklists include suggested settings in this regard. Finally, keep in mind that the data won't do any good unless you use it. Establish procedures for regularly checking the logs. If you've got too many machines to check them all yourself, consider buying a third-party data mining tool that will automatically parse the logs for known indicators that your system is under attack. Law #6: There really is someone out there trying to guess your passwords. Passwords are a classic example of the truism that your system is only as secure as the weakest part of your defenses. One of the first things an attacker may test is the strength of your passwords, for two reasons: They're extraordinarily valuable. Regardless of the other security practices you follow, if a bad guy can learn just one user's password, he can gain access to your network. From there, he has a perfect position from which to mount additional attacks. Passwords are "low-hanging fruit". Most people pick lousy passwords – they'll pick an easily guessed word, and never change it. If forced to pick a more-difficult password, many users will write it down. (This is also known as the "yellow sticky pad" vulnerability). You don't have to be technical whiz to crack someone's account if you already know their password. Unless you can enforce a strong password policy, you'll never secure your network. Establish minimum password length, password complexity, and password expiration policies on your network. (Windows 2000, for instance, will let you set these as part of Group Policy). Also, use account lockout, and make sure you audit for failed logon attempts. Finally, make sure that your users understand why it's a bad practice to write their passwords down. If you need a demonstration, get management approval to periodically walk through your users' offices, and check for the dreaded sticky note with a password written on it. Don't do an intrusive search, just check the top desk drawer, the underside of the keyboard, and the pull-out writing table that's found on many desks. If your company is like most, you'll be amazed how many you'll find. In addition to strengthening the passwords on your system, you may also want to consider using a stronger form of authentication than passwords. For instance, smart cards can significantly improve the security of your network, because the person must have both a PIN and physical possession of the card in order to log on. Biometric authentication takes this security to an even higher level, because the item that's used to log on – your fingerprint, retina, voice, etc. – is part of you and can't ever be lost. Whatever you choose, make sure that your authentication process provides a level of security commensurate with the rest of your network's security measures. Law #7: The most secure network is a well-administered one. Most successful attacks don't involve a flaw in the software. Instead, they exploit misconfigurations – for example, permissions that were lowered during troubleshooting but never reset, an account that was created for a temporary employee but never disabled when he left, a direct Internet connection that someone set up without approval, and so forth. If your procedures are sloppy, it can be difficult or impossible to keep track of these details, and the result will be more holes for a bad guy to slither through. The most important tool here isn't a software tool – it's procedures. Having specific, documented procedures is an absolute necessity. As usual, it starts with the corporate security policy, which It should spell out, at a broad level, who's responsible for each part of the network, and the overall philosophy governing deployment, management and operation of the network. But don't stop with the high-level corporate policy. Each group should refine the policy and develop operating procedures for their area of responsibility. The more specific these procedures are, the better. And write them down! If your procedures exist only as oral tradition, they'll be lost as your IT personnel changes. Next, consider setting up a "Red Team", whose only job is to scour the network for potential security problems. Red Teams can immediately improve security by bringing a fresh set of eyes to the problem. But there can be a secondary benefit as well. Network operators will be much more likely to think about security in the first place if there's a Red Team on the prowl – if only because nobody wants the Red Team showing up at their office to discuss the latest security problem they found. Law #8: The difficulty of defending a network is directly proportional to its complexity. This law is related to Law #7 – more complex networks are certainly more difficult to administer – but it goes beyond just administering it. The crucial point here is the architecture itself. Here are some questions to ask yourself: What do the trust relationships between the domains in your network look like? Are they straightforward and easily understood, or do they look like spaghetti? If it's the latter, there's a good chance that someone could abuse them to gain privileges you don't intend for them to have. Do you know all the points of access into your network? If one of the groups in your company has, for instance, set up a public FTP or web server, it might provide a back door onto your network. Do you have a partnership agreement with another company that allows their network users onto your network? If so, the security of your network is effectively the same as that of the partner network. Adopt the phrase "few and well-controlled" as your mantra for network administration. Trust relationships? Few and well-controlled. Network access points? Few and well-controlled. Users? Few and well-controlled – just kidding! The point is that you can't defend a network you don't understand. Law #9: Security isn't about risk avoidance; it's about risk management. One of the most often-cited truisms in computer security is that the only truly secure computer is one buried in concrete, with the power turned off and the network cable cut. It's true – anything less is a compromise. However, a computer like that, although secure, doesn't help your company do business. Inevitably, the security of any useful network will be less than perfect, and you have to factor that into your planning. Your goal cannot be to avoid all risks to the network – that's simply unrealistic. Instead, accept and embrace these two undeniable truths: There will be times when business imperatives conflict with security. Security is a supporting activity to your business rather than an end unto itself. Take considered risks, and then mitigate them to the greatest extent possible. Your network security will be compromised. It may be a minor glitch or a bona fide disaster, it may be due to a human attacker or an act of God, but sooner or later your network will be compromised in some fashion. Make sure you have made contingency plans for detecting, investigating and recovering from the compromise. The place to deal with both of these issues is in your security policy. Work with corporate management to set the overall guidelines regarding the risks you're willing to take and how you intend to manage them. Developing the policy will force you and your corporate management to consider scenarios that most people would rather not think about, but the benefit is that when one of these scenarios occurs, you'll already have an answer. Law #10: Technology is not a panacea. If you've read The Ten Immutable Laws of Security, you'll recognize this law – it's the final law on that list as well. The reason it's on both lists is because it applies equally well to both network users and administrators, and it's equally important for both to keep in mind. Technology by itself isn't enough to guarantee security. That is, there will never be a product that you can simply unpackage, install on your network, and instantly gain perfect security. Instead, security is a result of both technology and policy – that is, it's how the technology is used that ultimately determines whether your network is secure. Microsoft delivers the technology, but only you and your corporate management can determine the right policies for your company. Plan for security early. Understand what you want to protect and what you're willing to do to protect it. Finally, develop contingency plans for emergencies before they happen. Couple thorough planning with solid technology, and you'll have great security.

Security Services (OSI definition)
Access control: Protects against unauthorized use Authentication: Provides assurance of someone's identity Confidentiality: Protects against disclosure to unauthorized identities Integrity: Protects from unauthorized data alteration Non-repudiation: Protects against originator of communications later denying it Source:

Three basic building blocks are used:
Security Mechanisms Three basic building blocks are used: Encryption is used to provide confidentiality, can provide authentication and integrity protection Digital signatures are used to provide authentication, integrity protection, and non-repudiation Checksums/hash algorithms are used to provide integrity protection, can provide authentication One or more security mechanisms are combined to provide a security service

10 Domains of Computer Security
Domain 1 addresses access control. Access control consists of all of the various mechanisms (physical, logical, and administrative) used to ensure that only authorized persons or processes are allowed to use or access a system. Three categories of access control focus on: (1) access control principles and objectives, (2) access control issues, and (3) access control administration. Domain 2 addresses communications security. Communications security involves ensuring the integrity and confidentiality of information transmitted via telecommunications media as well as ensuring the availability of the telecommunications media itself. Three categories of communications security are: (1) telecommunications security objectives, threats, and countermeasures; (2) network security; and (3) Internet security.

Continued… Domain 3 addresses risk management and business continuity planning. Risk management encompasses all activities involved in the control of risk (risk assessment, risk reduction, protective measures, risk acceptance, and risk assignment). Business continuity planning involves the planning of specific, coordinated actions to avoid or mitigate the effects of disruptions to normal business information processing functions. Domain 4 addresses policy, standards, and organization. Policies are used to describe management intent, standards provide a consistent level of security in an organization, and an organization architecture enables the accomplishment of security objectives. Four categories include: (1) information classification, (2) security awareness, (3) organization architecture, and (4) policy development.

Continued… Domain 5 addresses computer architecture and system security. Computer architecture involves the aspects of computer organization and configuration that are employed to achieve computer security while system security involves the mechanisms that are used to maintain the security of system programs. PC and LAN security issues, problems, and countermeasures are also in this domain. Domain 6 addresses law, investigation, and ethics. Law involves the legal and regulatory issues faced in an information security environment. Investigation consists of guidelines and principles necessary to successfully investigate security incidents and preserve the integrity of evidence. Ethics consists of knowledge of the difference between right and wrong and the inclination to do the right thing.

Continued… Domain 7 addresses application program security. Application security involves the controls placed within the application program to support the security policy of the organization. Topics discussed include threats, applications development, availability issues, security design, and application/data access control. Domain 8 addresses cryptography. Cryptography is the use of secret codes to achieve desired levels of confidentiality and integrity. Two categories focus on: (1) cryptographic applications and uses and (2) crypto technology and implementations. Included are basic technologies, encryption systems, and key management methods.

Continued… Domain 9 addresses (computer) operations security. Computer operations security involves the controls over hardware, media and the operators with access privileges to these. Several aspects are included — notably, operator controls, hardware controls, media controls trusted system operations, trusted facility management, trusted recovery, and environmental contamination control. Domain 10 addresses physical security. Physical security involves the provision of a safe environment for information processing activities with a focus on preventing unauthorized physical access to computing equipment. Three categories include: (1) threats and facility requirements, (2) personnel physical access control, and (3) microcomputer physical security.

Vulnerabilities The Twenty Most Critical Internet Security Vulnerabilities (Updated): The Experts’ Consensus, Version January 30, 2002 Copyright , The SANS Institute at ICAT Top Ten List

The 20 Most Critical Internet Security Vulnerabilities
G1 - Default installs of operating systems and applications G1.1 Description G1.2 Systems impacted: G1.3 CVE entries: G1.4 How to determine if you are vulnerable: G1.5 How to protect against it G2 - Accounts with No Passwords or Weak Passwords G3 - Non-existent or Incomplete Backups G4 - Large number of open ports G5 – Not filtering packets for correct incoming and outgoing addresses G6 - Non-existent or incomplete logging G7 - Vulnerable CGI Programs Plus 6 Windows and 7 Unix Vulnerabilities

Log (Audit Trail) One of the maxims of security is, "Prevention is ideal, but detection is a must." As long as you allow traffic to flow between your network and the Internet, the opportunity for an attacker to sneak in and penetrate the network, is there. New vulnerabilities are discovered every week, and there are very few ways to defend yourself against an attacker using a new vulnerability. Once you are attacked, without logs, you have little chance of discovering what the attackers did. Without that knowledge, your organization must choose between completely reloading the operating system from original media, and then hoping the data back-ups were OK, or taking the risk that you are running a system that a hacker still controls. You cannot detect an attack if you do not know what is occurring on your network. Logs provide the details of what is occurring, what systems are being attacked, and what systems have been compromised. Logging must be done on a regular basis on all key systems, and logs should be archived and backed up because you never know when you might need them. Most experts recommend sending all of your logs to a central log server that writes the data to a write once media, so that the attacker cannot overwrite the logs and avoid detection.

Ports That Are Commonly Probed and Attacked
Blocking these ports is a minimum requirement for perimeter security, not a comprehensive firewall specification list. A far better rule is to block all unused ports. And even if you believe these ports are blocked, you should still actively monitor them to detect intrusion attempts. A warning is also in order: Blocking some of the ports in the following list may disable needed services. Please consider the potential effects of these recommendations before implementing them. Keep in mind that blocking these ports is not a substitute for a comprehensive security solution. Even if the ports are blocked, an attacker who has gained access to your network via other means (a dial-up modem, a Trojan attachment, or a person who is an organization insider, for example) can exploit these ports if not properly secured on every host system in your organization.

Ports Login services-- telnet (23/tcp), SSH (22/tcp), FTP (21/tcp), NetBIOS (139/tcp), rlogin et al (512/tcp through 514/tcp) RPC and NFS-- Portmap/rpcbind (111/tcp and 111/udp), NFS (2049/tcp and 2049/udp), lockd (4045/tcp and 4045/udp) NetBIOS in Windows NT (tcp and udp), 137 (udp), 138 (udp), 139 (tcp). Windows 2000 – earlier ports plus 445(tcp and udp) X Windows /tcp through 6255/tcp Naming services-- DNS (53/udp) to all machines which are not DNS servers, DNS zone transfers (53/tcp) except from external secondaries, LDAP (389/tcp and 389/udp) Mail-- SMTP (25/tcp) to all machines, which are not external mail relays, POP (109/tcp and 110/tcp), IMAP (143/tcp) Web-- HTTP (80/tcp) and SSL (443/tcp) except to external Web servers, may also want to block common high-order HTTP port choices (8000/tcp, 8080/tcp, 8888/tcp, etc.) …

Top 50 Security Tools

A Security Policy Framework
Policies define appropriate behavior. Policies set the stage in terms of what tools and procedures are needed. Policies communicate a consensus. Policies provide a foundation for HR action in response to inappropriate behavior. Policies may help prosecute cases.

An intrusion is somebody (A. K. A
An intrusion is somebody (A.K.A. "hacker" or "cracker") attempting to break into or misuse your system. The word "misuse" is broad, and can reflect something severe as stealing confidential data to something minor such as misusing your system for spam (though for many of us, that is a major issue!). An "Intrusion Detection System (IDS)" is a system for detecting such intrusions. IDS can be broken down into the following categories:

Risk Profiling Matrix Risk Profile Matrix Threats: Rating Visibility Score None identified as active; exposure is limited 1 Very low profile, no active publicity Unknown state or multiple exposures 3 Middle of the pack, periodic publicity Active threats, multiple exposures 5 Lightning rod, active publicity Consequences Sensitivity No cost impact; well within planned budget; risk transferred Accepted as cost of doing business; no organization issues Internal functions impacted; budget overrun; opportunity costs Unacceptable Business Unit management impact; good will costs External functions impacted; direct revenue hit Unacceptable Corporate Management impact; business relationships affected Total Score: Rating: Multiply Threat rating by Visibility rating, and Consequences rating by Sensitivity rating. Add the two values together: * : Low Risk * : Medium Risk * : High Risk

Stay Secure Identify the risks Put attacks in perspective
Store information securely Perform reliable and secure backups Transfer information securely across hostile networks Understand Public Key Infrastructure (PKI) and its limitations Protect against network threats Set up firewalls Deal with denial of service attacks Understand online commerce and privacy

Importance of Security Policies
Security policies are an absolute must for any organization. They provide the virtual glue to hold it all together. Policies lay the ground-work. Imagine a small city that did not have any rules? What would life be like? The same applies to your organization .

Initial step is to determine who gets access.
Who and What to Trust Trust is a major principle underlying the development of security policies. Initial step is to determine who gets access. Deciding on level of trust is a delicate balancing act. Too much trust may lead to eventual security problems Too little trust may make it difficult to find and keep employees or get jobs done How much should you trust people regarding to their access or usage of computer and network resources? Before we begin our discussion about policies, lets talk a little about trust. Trust is a central theme in many policies. Some policies may not be written because there is trust that people will do the right thing. Then on the other hand, some policies are needed because we know people don.t always do the right thing. Ideally you want to trust all resources, but that is unrealistic. Buggy hardware and software are commonplace. Try to implement controls and procedures to minimize the impact when a failure does occur. Trust of employees and users develops over time. Different categories of employees should be trusted at different levels. Ensure level of access is commensurate with level of trust.

Trust everyone all of the time:
Possible Trust Models Trust everyone all of the time: easiest to enforce, but impractical one bad apple can ruin the whole barrel Trust no one at no time: most restrictive, but also impractical difficult to staff positions Trust some people some of the time: exercise caution in amount of trust given access is given out as needed technical controls are needed to ensure trust is not violated When looking at trust, you have three basic models . those listed above. It is not very common to find organizations that follow the model of trusting everyone all of the time. In today.s world it is just not possible. On the same token the model of trusting no one at no time is also not that common. This model is mostly found in high level security government organizations. The most common model is to trust some of the people some of the time and to build trust over time. Also keep in mind that it may be appropriate to apply different trust models to different parts of the organization.

Why the Political Turmoil?
People view policies as: an impediment to productivity measures to control behavior People have different views about the need for security controls. People fear policies will be difficult to follow and implement. Policies affect everyone within the organization. My experience in the field has consistently shown that security policies tend to elevate the level of tension in any given situation. It basically boils down to the fact that people don.t like rules and don.t like to be restricted in their activities. One reason for the tension level is that everyone tends to view security needs differently: .Users are concerned about being able to get their work done without a lot of controls. .System support personnel are concerned about the ease of managing systems under tight control. .Management is concerned about costs versus protection. Getting all sides to agree about the elements of a policy is nearly impossible. It is always best to try to reach a .win-win. compromise.

Who Should Be Concerned?
Users - policies will affect them the most. System support personnel - they will be required to implement, comply with and support the policies. Managers - they are concerned about protection of data and the associated cost of the policy. Company lawyers and auditors - they are concerned about company reputation, responsibility to clients/customers. Basically, everyone should be concerned security policies because everyone is affected by them to some extent. The system users are typically affected the most as they see the policies as a set of rules to regulate their behavior and make it more difficult for them to accomplish their job. The people who have to support the infrastructure are concerned since they are the ones who have to implement and comply by many of the policies. For example, a policy that requires all Solaris hosts to be installed according to a baseline security standard would require more work on the part of the system administrators. Not only for the initial install, but also for the upkeep of the system.

The Policy Design Process
Choose the policy development team. Designate a person or a group to serve as the official policy interpreter. Decide on the scope and goals of the policy. Scope should be a statement about who is covered by the policy. Decide on how specific to make the policy not meant to be a detailed implementation plan don’t include facts which change frequently Ideally, you should have a formal policy design process that is consistently followed for all security policies. The process would specify who develops the initial draft of the policy, which groups are required to review each policy, the required approval process and finally the implementation process. The SAGE booklet .A Guide to Developing Computing Policy Documents., recommends: a senior level administrator a member of management who can enforce the policy a member of the legal staff a representative from the user community someone with good writing skills The size of the policy design group will depend on the size and scope of the policy. Small scale policies may only require one or two people while large scale policies may require a team of 5-10.

The Policy Design Process
A sample of people affected by the policy should be provided an opportunity to review and comment. A sampling of the support staff effected by policy should have an opportunity to review it. Incorporate policy awareness as a part of employee orientation. Provide a refresher overview course on policies once or twice a year. If at all possible, notify people in advance that a new policy is being developed and explain why the policy is needed. Prior to deploying a new policy, allow people one-two weeks to review and comment. People given responsibility in a policy should also have the authority to carry out their responsibilities.

Basic Policy Requirements
Policies must: be implementable and enforceable be concise and easy to understand balance protection with productivity Policies should: state reasons why policy is needed describe what is covered by the policies define contacts and responsibilities discuss how violations will be handled This page discusses some basic rules for policies. While many of these may seem obvious, it is necessary to point them out. When planning policies, some organizations will go overboard with policies and come up with something that will be impossible to implement and comply with. The bottom line for policies is they must take into consideration the balance of protection with the level of productivity hit. You also want policies to be concise and easy to read and understand. Our goal at Cisco is to keep policies to 2 pages or less, if at all possible. We do have a few policies which are 4 or 5 pages. One thing to keep in mind when developing a policy is how it will effect legacy systems and other infrastructure that is already in place. Once the policies are fully approved, they should be made available to all users who are affected. Finally, all policies should be updated annually to reflect changes in organization or culture.

Level of Control Security needs and culture play major role.
Security policies MUST balance level of control with level of productivity. If policies are too restrictive, people will find ways to circumvent controls. Technical controls are not always possible. You must have management commitment on the level of control. One of the major goal of a policy is to implement control. Deciding on the level of control for a specific policy is not always clear-cut. The security needs and the culture of the organization will play a major role when deciding what level of control is appropriate. If you make policies too restrictive or too hard to implement and comply with, they will either be ignored (not implemented) or people will find a way to circumvent the controls in the policies.

Policy Structure Dependent on company size and goals.
One large document or several small ones? smaller documents are easier to maintain/update Some policies appropriate for every site, others are specific to certain environments. Some key policies: acceptable use remote access information protection perimeter security baseline host/device security There are potentially dozens of policy topics that may be appropriate for most mid to large size organizations. Some of Cisco.s major policies: Acceptable Encryption Application Service Providers Acceptable User Acquisition Assessment Audit Risk Assessment Information Sensitivity Password Laptop Security DMZ Equipment Extranet Host Security Lab Security Anti-Virus Router/Switch Wireless Communications Remote Access VPN

The Acceptable Use Policy
Discusses and defines the appropriate use of the computing resources. Users should be required to read and sign account usage policy as part of the account request process. A key policy that all sites should have. Example policies and procedures can be found on the SANS web site at: The Acceptable Use policy is probably one of the most important policies a site can have. For educational and government organizations, it is basically a .must have.. Without such a written policy, management and support staff have nothing they can reference when attempting to punish an employee/guest who has violated the acceptable, safe computing practices.

Should discuss acceptable non-business uses of the resources.
Some Elements Should state responsibility of users in terms of protecting information stored on their accounts. Should state if users can read and copy files that are not their own, but are accessible to them. Should state level of acceptable usage for electronic mail, internet news and web access. Should discuss acceptable non-business uses of the resources. Some example text from a AU policy might read: .Users are responsible for protecting any information used and/or stored on/in their accounts at <company name>. Consult the user guide for guidelines on protecting your account and information using the standard system protection methods or by use of encryption software such as PGP. Company or third party confidential information should not be be stored or transmitted to non<company name> hosts.. .Users shall not attempt to access any data or programs contained on <company name> hosts for which they do not have authorization or explicit consent from the owner of the data/information, or from an appropriate level of management..

Remote Access Policy Outlines and defines acceptable methods of remotely connecting to the internal network. Essential in large organization where networks are geographically dispersed and even extend into the homes. Should cover all available methods to remotely access internal resources: dial-in (SLIP, PPP) ISDN/frame relay telnet/ssh access from internet cable modem/VPN/DSL Example Text: 1. It is the responsibility of <Company Name> employees, contractors, vendors and agents with remote access privileges to <Company Name>'s corporate network to ensure that their remote access connection is given the same consideration as the user's on-site connection to <Company Name>. 2. General access to the Internet for recreational use by immediate household members through the <Company Name> Network on personal computers is permitted for employees that have flat-rate services. The <Company Name> employee is responsible to ensure the family member does not violate any <Company Name> policies, does not perform illegal activities, and does not use the access for outside business interests. The <Company Name> employee bears responsibility for the consequences should the access be misused. 3. Please review the following policies for details of protecting information when accessing the corporate network via remote access methods, and acceptable use of <Company Name>'s network: a. Acceptable Encryption Policy b. Virtual Private Network (VPN) Policy c. Wireless Communications Policy d. Acceptable Use Policy 4. For additional information regarding <Company Name>'s remote access connection options, including how to order or disconnect service, cost comparisons, troubleshooting, etc., go to the Remote Access Services website.

Should define who can have remote access.
Some Elements Should define who can have remote access. Should define what methods are allowed for remote access. Should discuss who is allowed to have high speed remote access such as ISDN, frame relay or cable modem. extra requirements appropriate use Should discuss any restrictions on data that can be accessed remotely. More Example Text: Requirements Secure remote access must be strictly controlled. Control will be enforced via one- time password authentication or public/private keys with strong pass-phrases. For information on creating a strong pass-phrase see the Password Policy. 2. At no time should any <Company Name> employee provide their login or password to anyone, not even family members. 3. <Company Name> employees and contractors with remote access privileges must ensure that their <Company Name>-owned or personal computer or workstation, which is remotely connected to <Company Name>'s corporate network, is not connected to any other network at the same time, with the exception of personal networks that are under the complete control of the user. 4. <Company Name> employees and contractors with remote access privileges to <Company Name>'s corporate network must not use non-<Company Name> accounts (i.e., Hotmail, Yahoo, AOL), or other external resources to conduct <Company Name> business, thereby ensuring that official business is never confused with personal business. 5. Routers for dedicated ISDN lines configured for access to the <Company Name> network must meet minimum authentication requirements of CHAP.

Information Protection Policy
Provides guidelines to users on the processing, storage and transmission of sensitive information. Main goal is to ensure information is appropriately protected from modification or disclosure. May be appropriate to have new employees sign policy as part of their initial orientation. Should define sensitivity levels of information. Even though it may seem like common sense to protect company private information, many employees don.t take the time to consider the sensitivity level of much of the information they see. If possible, attach a level rating to information sent out via and interoffice mail. Employees who work exclusively on a laptop need to be more cautious of protecting information stored on that system. Especially when traveling, where the likelihood that strangers will gain access to the laptop or steel the laptop is dramatically higher.

Should define who can have access to sensitive information.
Some Elements Should define who can have access to sensitive information. "need-to-know" special circumstances non-disclosure agreements Should define how sensitive information is to be stored and transmitted (encrypted, archive files, uuencoded, etc). Should define on which systems sensitive information can be stored. Example Text: All <Company Name> information is categorized into two main classifications: • <Company Name> Public • <Company Name> Confidential <Company Name> Public information is information that has been declared public knowledge by someone with the authority to do so, and can freely be given to anyone without any possible damage to <Company Name> Systems, Inc. <Company Name> Confidential contains all other information. It is a continuum, in that it is understood that some information is more sensitive than other information, and should be protected in a more secure manner. Included is information that should be protected very closely, such as trade secrets, development programs, potential acquisition targets, and other information integral to the success of our company. Also included in <Company Name> Confidential is information that is less critical, such as telephone directories, general corporate information, personnel information, etc., which does not require as stringent a degree of protection.

Some Elements Should discuss what levels of sensitive information can be printed on physically insecure printers. Should define how sensitive information is removed from systems and storage devices: degaussing of storage media scrubbing of hard drives shredding of hardcopy output Should discuss any default file and directory permissions defined in system-wide configuration files. More Example Text: A subset of <Company Name> Confidential information is "<Company Name> Third Party Confidential" information. This is confidential information belonging or pertaining to another corporation which has been entrusted to <Company Name> by that company under non-disclosure agreements and other contracts. Examples of this type of information include everything from joint development efforts to vendor lists, customer orders, and supplier information. Information in this category ranges from extremely sensitive to information about the fact that we've connected a supplier / vendor into <Company Name>'s network to support our operations. <Company Name> personnel are encouraged to use common sense judgment in securing <Company Name> Confidential information to the proper extent. If an employee is uncertain of the sensitivity of a particular piece of information, he/she should contact their manager

The Perimeter Security Policy
Describes, in general, how perimeter security is maintained. Describes who is responsible for maintaining it. Describes how hardware and software changes to perimeter security devices are managed and how changes are requested and approved.

Some Elements Should discuss who can obtain privileged access to perimeter security systems. Should discuss the procedure to request a perimeter device configuration change and how the request is approved. Should discuss who is allowed to obtain information regarding the perimeter configuration and access lists. Should discuss review cycles for perimeter device system configurations. There are very few valid reasons why a member outside of the security and network support staff would need access to firewall configuration information. Perimeter device configuration information should never be stored on, or transmitted to systems of general availability, and they should almost never be printed in hardcopy form. In a large organization, it might be useful to have all firewall configuration changes reviewed by a small group of people who are responsible for security.

Virus Protection and Prevention Policy
Provides baseline requirements for the use of virus protection software. Provides guidelines for reporting and containing virus infections. Provides guidelines for several levels of virus risk. Should discuss requirements for scanning attachments. Should discuss policy for the download and installation of public domain software. Example Text: All <Company Name> PC-based lab computers must have <Company Name>'s standard, supported anti-virus software installed and scheduled to run at regular intervals. In addition, the anti-virus software and the virus pattern files must be kept up-to-date. Virus-infected computers must be removed from the network until they are verified as virus-free. Department managers are responsible for creating procedures that ensure anti-virus software is run at regular intervals, and computers are verified as virus-free. Any activities with the intention to create and/or distribute malicious programs into <Company Name>'s networks (e.g., viruses, worms, Trojan horses, bombs, etc.) are prohibited, in accordance with the Acceptable Use Policy. Refer to <Company Name>'s Anti-Virus Recommended Processes to help prevent virus problems. Noted exceptions: Machines with operating systems other than those based on Microsoft products are excepted at the current time.

Virus Protection and Prevention Policy
Should discuss frequency of virus data file updates. Should discuss testing procedures for installation of new software.

Discusses password construction rules.
Password Policy Provides guidelines for how user level and system level passwords are managed and changed. Discusses password construction rules. Provides guidelines for how passwords are protected from disclosure. Discusses application development guidelines for when passwords are needed. Discusses the use of SNMP community strings and pass-phrases. As a minimum, you should have a password management policy or procedure which describes how often passwords are changed and how you track who has what passwords. Example text: All system-level passwords (e.g. root, enable, NT admin, application administration accounts, etc.) must be changed on at least a quarterly basis. All production system-level passwords must be part of the InfoSec administered global password management database. All user-level passwords (e.g., , web, desktop computer, etc.) must be changed at least every six months. The recommended change interval is every four months. User accounts which have system-level privileges granted through group memberships or programs such as "sudo" must have a unique password from all other accounts held by that user.

Other Important Policies
A policy which addresses forwarding of to offsite addresses. A policy which addresses wireless networks. A policy which addresses baseline lab security standards. A policy which addresses baseline router configuration parameters. A policy which addresses requirements for installing devices on a dirty network. These are just a few examples of the types of policies that may apply to different organization. The policy development area is certainly one area where .one size does not fit all.. The culture of the organization will have large impact on the types of policies that are implemented and how they are enforced.

Security Procedures Policies only define "what" is to be protected.
Procedures define "how" to protect resources and are the mechanisms to enforce policy. Procedures define detailed actions to take for specific incidents. Procedures provide a quick reference in times of crisis. Procedures help eliminate the problem of a single point of failure (e.g., an employee suddenly leaves or is unavailable in a time of crisis). Procedures are equally important as policies. Often the polices define what is to be protected and what are the ground rules. The procedures outline how to protect the resources or how to carry out the policies. For example, a Password Policy would outline password construction rules, rules on how to protect your password and how often to change them. The Password Management Procedure would outline the process to create new passwords, distribute them as well as the process for ensuring the passwords have changed on critical devices. There will not always be a one-to- one relationship between policy and procedures. In the next few pages we will review just a few of the important procedures that almost every organization needs.

Configuration Management Procedure
Defines how new hardware/software is tested and installed. Defines how hardware/software changes are documented. Defines who must be informed when hardware and software changes occur. Defines who has authority to make hardware and software configuration changes. The configuration management procedure would typically be defined at the department level or at the corporate level. Even if there is a corporate CM procedure, individual groups may choose to have their own. The CM procedure should define the process to document and request configuration changes of all scales (from a simple router installation to a major firewall ACL change). Ideally, there is a central group that review and approves of all change requests. A CM process is important for several key reasons: .Documents changes made. Provides an audit trail .Documents that possible system down-time so that when the change is made it is not seen as a system problem. .Provides a way to coordinate changes so that one change does not severely impact another change.

Defense in Depth security model
A key component of this model is that the loss or failure of a single component does not compromise the entire information infrastructure. Critical systems should be fault tolerant and have hot-standbys available. There should also be strong configuration management controls. Good configuration management practices will limit system changes that may trigger false alerts or failures. Each system needs established baseline standards. Documentation of initial configurations should be supplemented by a system that details all patches; updates and other modification made to each machine.

DMZ has evolved, however, to mean an isolated network segment for providing services to untrusted systems. Today the term is most often used by IT professionals to refer to a network segment between two firewalls (see "sandwich DMZ"), or a "dead-end" or "wing" network connected to a firewall (see "Single-Firewall DMZ"). Other common names for a DMZ are services network and atrium.

Solution for Systems Architecture: Internet Data Center

Data Backup and Off-site Storage Procedures
Defines which file systems are backed up. Defines how often backups are performed. Defines how often storage media is rotated. Defines how often backups are stored off-site. Defines how storage media is labeled and documented. The backup and off-site storage policy may be required due to customer commitments. The number of people who can request off-site backup tapes should be kept to a minimum. You should try restoring from backup media on a regular basis to test integrity of backup methods. Part of the backup procedure may be in the form of a program or script which automates the process of performing backups.

Incident Handling Procedure
Defines how to handle anomaly investigation and intruder attacks. Defines areas of responsibilities for members of the response team. Defines what information to record and track. Defines who to notify and when. Defines who can release information and the procedure for releasing the information. Defines how a follow-up analysis should be performed and who will participate. A incident handling procedure is a definite must for all organizations. It is impossible to outline responses for all incidents, but you should cover the major types of incidents that might occur. Some example types might include: network port scan, denial of service attack, compromised host, compromised account, and inappropriate use. You should identify one person to act as a liaison to outside agencies.

RFC2196 - The site security procedures handbook at
Policy Resources RFC The site security procedures handbook at Some useful web sites: csrc.nist.gov/isptg/ It is difficult to find general resources for business oriented policies. Many companies consider their security policies to be sensitive information

Policies are a crucial part of the infrastructure.
Recap Policies are a crucial part of the infrastructure. Trust is frequently an issue. Key policies: acceptable use policy remote access policy information protection policy perimeter security management policy Key procedures: CM procedure incident handling procedure

Policy, Standard, and Guideline
A policy is typically a document that outlines specific requirements or rules that must be met. In the information/network security realm, policies are usually point-specific, covering a single area. For example, an “Acceptable Use” policy would cover the rules and regulations for appropriate use of the computing facilities. A standard is typically a collections or system-specific or procedural-specific requirements that must be meet by everyone. For example, you might have a standard that describes to how to harden a Windows NT workstation for placement on an external (DMZ) network. People must follow this standard exactly if they wish to install a Windows NT workstation on an external network segment. A guideline is typically a collection of system specific or procedural specific “suggestions” for best practice. They are not requirements to be met, but are strongly recommended. Effective security policies make frequent references to standards and guidelines that exist within an organization.

Security Is an Industry Problem
Number of incidents MandrakeSoft Linux 7.2 33 SCO Open Server 5.0.6 21 Windows 2000 24 Sun Solaris 8.0 24 RedHat Linux 7.0 28 “The conclusion here is that there is obviously a comparable number of security problems with the various flavors of Linux, as well as Sun’s Solaris, as there are with Windows NT 4.0 and Windows 2000.” John McCormick, TechRepublic, Inc., September 24, 2001, based on data provided by Security Focus Bugtraq

Security in a Complex World
Security is a process that tries to secure a complex system of many entities: People (culture, knowledge) Process (procedures, guidelines) Product/Technology (hardware, software, networks) The entities interact in rich and unpredictable ways Security will fail if only focusing on part of the problem Products and technology are neither the whole problem nor the whole solution

People, Process, Product challenges?
Products lack security features Products have bugs Many issues are not addressed by technical standards Too hard to stay in the know and up-to-date Designing for security Roles & responsibilities Auditing, tracking, follow-up Calamity plans Staying up-to-date with security development Product Process People Lack of knowledge Lack of commitment Human error

Why Is It Hard to Get Secure? Customers Need Our Help
More than 50% of the customers affected by Code Red were not patched in time for Nimda I didn’t know which patches I needed I didn’t know where to find the updates I didn’t know which machines needed the update We updated our production servers, but the 4,000 rogue servers got infected If customers had used the IIS 5.0 lockdown tool (and added no other patches or updates) in December of 2000, there were only two very minor vulnerabilities that would have affected them The product update failed because the people and process wasn’t there to implement the fix

STPP: “Get Secure” Free Virus Support Hotline Now
1-866-PCSAFETY ( ) Security Assessment Program Offering Now Available immediately through MCS/PSS Microsoft Security Toolkit Now Server oriented security resources for server admins New server security tools and updates, Windows Update bootstrap client for Windows 2000 Enterprise Security Tools December RTM Server security configuration scanner SMS security patch rollout tool Windows Update Auto-update client (Group Policy-enabled)

STPP: “Stay Secure” Windows 2000 Security Rollup Patches December 2001
Bundle all security fixes in single patches Reduces reboots and administrator burden Windows 2000 Service Pack (SP3) February 2002 Provide ability to install SP3 + security rollup with a single reboot Federated Corporate Windows Update Program February 2002 Allows enterprise to host and select Windows Update content Enhanced Product Security Ongoing Provide greater security enhancements in the releases of all new products, including the Windows .NET Server family

Microsoft Security Toolkit
Gets Windows NT and 2000 systems to a secure baseline, even in disconnected nets Automates server updates One-button wizard and SMS Scripts Updates and Patches Includes all Service Packs and critical OS and IIS patches through 10/15 Tools HFNetChk IIS Lockdown URLScan SMS Install Scripts Windows Update client for Windows 2000

Security Response Process
Product Team Security Team Mailing lists (NTBugTraq, BugTraq, etc) Microsoft Technical Support Security web sites Vulnerability Reports Triage Approximately 90% culled Repro Develop Patch/Workaround Knowledge Base Premier Customer Alert Security Bulletin Develop Documentation Test Development Practices Product Security Notification Service Mailing Lists site Distribute fix and information

The Challenge of Security
Internet-enabled businesses face challenges ensuring their technologies for computing and information assets are secure, fast and easy to interact with. The right access to the right content by the right people Provide services… Web access, , file access, messaging while protecting your assets. Financial data, CPU cycles, network resources, intellectual property, customer information Business Requirements Intellectual properties must be secure Employees must have rapid access to information Distributed environments must be managed using consistent policy The environment must be based on open standards All computing information environments are different, and therefore all organizations must develop their own strategies, goals, and plans for deploying ISA Server. The following are some of the most critical business considerations at Microsoft, which ITG took into consideration when formulating its strategy, goals, and plans to deploy ISA Server internally: Customer needs must be met. Microsoft is committed to developing solutions that satisfy customer needs. One such need is a reliable and scalable solution that will enable businesses to communicate with customers and partners using the Internet. To stand behind this commitment, Microsoft developed ISA Server and then kicked off an internal initiative to ensure that the product would be the most secure and scalable enterprise firewall and Web cache ever released. To assure that problems with the product were resolved before release, ITG and the product-development team created a tight feedback loop to communicate at every step in planning and deploying the beta release of ISA Server at Microsoft. Intellectual properties must be secure. Microsoft’s intellectual properties are its greatest asset, and ITG must keep these assets secure. For this reason, ITG is extremely careful to avoid compromising the company’s security. Before the beta release of ISA Server was deployed in Microsoft’s production environment, a team of security analysts reviewed the planning documents and then deployed a small test infrastructure based on those plans to determine if the environment could be compromised with commonly used techniques. They found that it could not. They also found that it was sufficiently secure to deploy at the edge of the internal network, where it would communicate directly with servers on the Internet. Employees must have rapid access to information. Information is of value only insofar as it can be used to support the day-today decision making of employees and executives. Information must be accessible to employees as quickly as they can process it to ensure that business is carried out at “the speed of thought.” Rapid access to information over the Internet and information shared on the Intranet are crucial business requirements. The Internet has dramatically changed the way Microsoft employees do their everyday jobs. For example, information within the company is provided almost exclusively in electronic, HTML-based form. Most line-of-business applications used at Microsoft now leverage Internet Information Server (the Web server built into Windows 2000 Server), SQL Server 2000, and Internet Explorer 5.5. The widespread use of HTML-based content at Microsoft has made ISA Server an ideal solution for securing information and accelerating access to that information. Distributed environments must be managed using consistent policy. Although most Microsoft employees work at or near corporate headquarters, others are distributed around the world. Employees in all areas of the company need secure and rapid access to the Web and shared information via the Internet regardless of where they work. Managing a geographically distributed environment must be quick and easy, and it is especially important that ITG be able to apply policy consistently to assure the internal environment is secure. Internet access points are available at many locations throughout Microsoft, allowing a geographically dispersed workforce to take advantage of them. As of this writing there are twenty-two such access points, all of which must be securely monitored and maintained while allowing employees secure and fast Internet access. The environment must be based on open standards. The day-to-day management of Microsoft’s internal computing information environment is simplified thanks to the continual support of many third parties. ITG relies on the dedication and day- to-day support of many solution providers to reduce support costs, improve security, and make the internal environment easier to manage. As a best practice, the technical skills and support tools that are core competencies of third parties are viewed as cost- effective alternatives to internal development. For this reason it is vital that the environment be based on open standards so that third parties can extend the environment to satisfy changing business conditions.

Life Was Much Simpler Back Then…
Mainframe Terminal access “Glass house” Physical security, limited connectivity

Life Was Much Simpler Back Then…
Client-Server LAN connectivity File/print services Limited external access

Life Became Complex After Internet
The Internet “Always on” , instant messaging The Web Then the world became complex and difficult…

Security Breaches Have Real Costs
Business Impact According to the Computer Crime and Security Survey 2001, by the Computer Security Institute (CSI) and the FBI: Quantified financial losses of at least $377M, or $2M per survey respondent 40% detected system penetration from the outside; up from 25% in 2000 94% detected computer viruses; 85% detected them in 2000 InformationWeek estimates: Security breaches cost businesses $1.4 trillion worldwide this year 2/3 of companies have experienced viruses, worms, or Trojan Horses 15% have experienced Denial of Service attacks Security Breaches Have Real Costs Source: Computer Security Institute (CSI) Computer Crime and Security Survey 2001 Source: InformationWeek.com, 10/15/01

High Profile Security Threats
Hostile Code Viruses Worms Trojan horses Denial of Service Web page defacement Eavesdropping, Interception Identity theft Viruses: Code that replicates itself (example: Melissa) Worms: Code that makes its way through existing code Trojan Horses: From Greek mythology, code that is disguised and is executed or activated on a certain date or by a certain activity Denial of Service: Potentially overloading and locking up a system so that others cannot gain access; also, modification of access rights to prevent others from gaining access Web page defacement: Replacing web pages or re-routing urls Eavesdropping and Interception: Via wireless or wired networks, “listening” to the wire and capturing data as it is transmitted Identity theft: False credentials, using false IP addresses or authentication credentials/passwords And, note that the punishment for the Anna Kournikova virus was only 50 days of community service. Common Methods of Cyber-Crimes

Recent Threats: Nimda, Code Red
Nimda: spread by browsing an infected site or opening an infected message Code Red: infected Web servers and granted administrative access Others: Denial of Service, Defacement Some survived Nimda and Code Red: Organizations that were up to date on patches and security fixes stayed secure Organizations which “locked down” their systems withstood threats

Security Framework Process Technology People Planning for security
Prevention Detection Reaction Process Technology Baseline technology Standards, Encryption, Protection Product security features Security tools and products Dedicated staff Training Security - a mindset and a priority External people People

Security in a Complex World
Security requires a framework composed of: Process (procedures, guidelines) Technology (hardware, software, networks) People (culture, knowledge) Security will fail if only focusing on part of the problem Technology is neither the whole problem nor the whole solution

Security Process Guidance
Based on British Standard 7799, included in Internet Data Center guide, a 4-phase process: Assess Define security requirements Perform analysis of current and desired states Design Develop security solution Utilize Defense in Depth framework Deploy Test and implement Define and document policies, standards, procedures Manage Operational management Review and reassess on a regular basis Security must be an on-going process and practice. New vulnerabilities and hacker threats are constantly cropping up, and hackers frequently take advantage of organizational changes which may present open security holes. Using the continuous process of assessing, designing, deploying, and managing for security will help to ensure that you have your infrastructure covered. One example to note is that hackers often prey upon organizations which have recently acquired other organizations, as the disparate security systems and procedures may provide for hacking opportunities.

Internet Data Center Guide – Security
Examples of topics included in Internet Data Center guide: Defense in Depth strategy Common Hacker Methods and Prevention Best practices for security IIS Windows 2000 Active Directory Design and Security Policies Best practices for application security Authentication

Industry-wide security design methodology of layering defenses:
Defense in Depth Industry-wide security design methodology of layering defenses: Perimeter defenses Network defenses Host defenses Application defenses Data and resources Provides a method and framework for designing security into infrastructure Prescriptive guidance and detail included in Microsoft Internet Data Center design guide

Deploying Secure Infrastructure
Internet Deploying Secure Infrastructure ISA Server: Enterprise Class Firewall Application level filtering .NET Enterprise Server integration with Windows security At each level, the sale has to be focused one level deeper since each level relies on the one below for buying advice. Each sale also needs to consider that there is a bottom up driver through the IT needs and objectives of the organization. Windows security features: Authentication ACLs Active Directory

Security Tools In addition to product features, Microsoft has provided security-specific tools: IIS (one button) Lockdown Tool Configures server to be immune to many attacks Disables unneeded services Restricts access to system commands HFNetCHK Administrator server scanning tool to ascertain patch status across servers URLscan tool ISAPI filter to run on server Blocks URLs that “look like” attacks Can be configured to support server configuration Microsoft personal Security Advisor Ascertains patch status of individual workstation

Security Depends on People
9% 29% 14% 10% 8% 6% 4% 3% From Information Security Magazine July "Top Obstacle is Budget: What is the SINGLE greatest obstacle to achieving adequate infosecurity at your organization?" Security must be a conscious priority Budget Constraints Lack of Senior Management Support Lack of Employee Training / End-User Awareness Lack of Competent Infosecurity Personnel Lack of Internal Policies Lack of Centralized Authority Technical Complexity Unclear Responsibilities Lack of Good Security Products Other

Product-Level Technology
Windows: Active Directory, authentication, secure protocol support ISA Server: Enterprise firewall and application filtering .NET Enterprise Servers: integration with Windows security features: authentication, secure protocol support

HIPAA HIPPA stands for Health Insurance Portability and Accountability Act. Passed in 1996, HIPAA is designed to protect confidential healthcare information through improved security standards and federal privacy legislation. It defines requirements for storing patient information before, during and after electronic transmission. It also identifies compliance guidelines for critical business tasks such as risk analysis, awareness training, audit trail, disaster recovery plans, information access control, and encryption. These security standards for information access control and encryption may have the most significant impact on how the industry conducts its business.

Complying with Security Standards
There are more than sixty-eight information security conditions in three areas that must be met to ensure compliance with HIPAA. These areas are: Technical Security Services: user authorization and authentication, access control and encryption Administrative Procedures: formal security planning, record maintenance and audits Physical Safeguards: security to building, privacy for office and workstations that handle patient information

Elements Covered by Security Policies
access controls – usually descriptions of logon warning screens on a computer and access lists for dedicated computer rooms, non-disclosure agreements. system backups – by whom, how often and where stored (offsite is best). incident handling – what should be reported, to whom, what will be the response, by whom. virus protection – mandatory installation of, how often updated (automatic or manual), virus incident handling. unauthorized access – who is allowed to access the company's computer assets and LAN monitoring – stating who will monitor the network for internal and external intrusions, and users for violations of security policies, who has access to intrusion detection devices, who will review and/or disseminate the logs. encryption – what is the company standard encryption methodology, when will encryption be used and by whom. digital signatures – what is the company standard, when will digital signatures be used and by whom.

Continued… web presence – what is and is not allowed to be placed on a public web server and who is allowed to publish disposing of resources – how to, by whom passwords – duration, number of and what type of characters, who must use passwords, for what and when, how to create. (UNI-C) use of personal resources within the company – allowed or not allowed, if so, under what conditions inspections and reviews – of what resources, how often, conducted by whom entertainment software, games, etc. – allowed or not allowed, if allowed when can be used. removal media - CDs, floppy disk, for personal or company use and usage marked freeware or shareware - authorized or not, if authorized, under what conditions. Excellent definitions of both shareware and freeware can be found on the Internet (CFS) software copyrights – software copyright laws are very stringent (SIIA), who will be liable if a copyright is violated, who is responsible to ensure copyrights are not violated.

Continued… personnel/physical security – what happens if a system containing sensitive information is moved out from a locked door. vendor responsibilities – what rules will a vendor follow when using a company IS asset or when using its own assets on company premises. public disclosure – who can release information to the public and under what restrictions. And what about non-disclosure agreements for employees as well as vendors. computer room facilities/areas – IS Security personnel should be involved in the design stage of new computer room facilities in order in insure safeguards to protect company IS assets. system configuration change – changes that alter the security profile (risk) of a company IS asset should not be instituted without consulting IS Security personnel first.

Continued… audit of IS Security compliance – who will audit for compliance? (the Audit Department), how will the audit be conducted. An excellent source for auditing criteria is the Information Systems Audit and Control Association (ISACA™). They publish several auditing guidelines, some free for downloading. security awareness and training – mandates an IS Security awareness training program, indicates who should attend this training, how often training will be conducted and what will be included in the training. inventory of IS assets –who should keep an inventory of all the company's IS assets, who should have access to that inventory, is it available to the risk management/audit teams documentation – to support risk management what support documentation should be maintained, by whom and how (electronically, etc.), i.e. risk assessment, countermeasures, test results documentation, standard operating procedures(SOPs), disaster recovery/ contingency plans.

Business Mission is Critical
Today, information is the axis on which your agency revolves. When information is unavailable to an organization, it is at risk of losing its competitive edge. Technology disruption . . . Leads to lost . . . Decision Capability Constituency Data Productivity Poor Service data Credibility Source: Availability and Continuity of Operations for Web Infrastructures Bob Barr, Director, Government Marketing, Dell Computer Corporation, February 6, 2002

Drivers for Continuity Services
Seventy-two percent (72%) of companies do not have a business continuity plan. Fifty percent (50%) of companies who experience a major disruption are no longer in business 1 to 2 years later. Business interruptions cost billions of dollars in lost revenue and penalties. System outages and downtime have an especially large effect on e-businesses: For example, eBay lost 28% of its market capitalization following a 22-hour outage, a decrease of over $3B. Forrester Research estimates that Amazon.com would lose $4.5M in revenue in 24 hours of downtime. Yahoo would lose $1.6M for 3 hours; companies as large as Intel and Cisco would lose $35M, $33M, and $30M in 24 hours, respectively. Most downtime is not attributable to a “disaster”: 40 percent of downtime is caused by application failures (e.g., performance issues or "bugs") 40 percent by operator error or lack of procedures 20 percent by system or environmental failures. Overall, less than 5 percent of application downtime is attributable to disasters.

Downtime - Planned & Unplanned
Goal 100 % Uptime Lost Time Factors Planned Unplanned Maintenance Backup Upgrades Transitions Human Error Fire, Catastrophe Equipment Failure

The Cost of Downtime Information inaccessibility causes inefficiencies that translate into lost dollars. Industry Cost Average Cost Per Industry Business Function Range Per Hour Hour of Downtime Financial Brokerage Operations $5.6 – 7.3 Million $6.45 Million Financial Credit Card Sales $2.2 – 3.1 Million $2.6 Million Financial ATM Fees $12,000 – 17,000 $14,500 Media Pay-Per-View $67,000 – 233,000 $150,000 Media Tele-Ticket Sales $56,000 – 82,000 $69,000 Retail Home Shopping (TV) $87,000 – 140,000 $113,000 This slide provides some additional cost of downtime examples. These examples are based on an analysis by Contingency Planning Research and quoted in the December 15, 1995 issue of Datamation. (Note to presenter: these examples are also quoted by EMC Corporation in their white paper titled “Business Continuance - Resuming Online Operations Before the Dust Settles.” This white paper describes the Symmetrix Remote Data Facility and can be found in the Enterprise Storage Reference Pack.) Challenge: The previous chart showed the cost of downtime during a single outage of $450,000 for the securities industry. This shows $6.45M per hour. Are these figures inconsistent? Response: No, not necessarily, although they are from different sources. One would expect companies with the highest cost of downtime to invest in high availability, even fault tolerance. Thus, the average length of an outage could be quite small compared to situations where normal availability is employed. Retail Home Catalog Sales $60,000 – 120,000 $90,000 Transportation Airline Reservations $67,000 – 112,000 $89,500 Transportation Package Shipping $24,000 – 32,000 $28,000

The Causes of Downtime When a failure occurs, it makes an impact. Whether or not downtime is the result depends on how well information is protected. Causes of Failure Examples Impacts… Component failure Bad memory chip, fan, power, HDD, data path, controller Platform, data Software defects/failures Driver hangs, OS hangs/reboots, virus, file corruption Platform, data, applications Planned administrative downtime Upgrade components, firmware, drivers, O/S, software Platform, data, applications Operator error Accidental file deletion, unskilled operation, guessing Platform, data, applications System outage/maintenance Software/systems requiring reboot, system board failure Applications Building/site disaster Fire, storms, collapse, explosion, and other localized disasters Site Metropolitan disaster Earthquake, hurricanes, floods, other regional natural catastrophes Site

Foundations for Business Continuity
Business Continuity means… Continuing with your Business Highly Available Systems Maintaining the availability of systems critical to ongoing agency operations during a system failure or service outage… People Disaster Recovery Systems Business Continuance Plan Recovering from unplanned, catastrophic events or disasters in an orderly, timely, appropriate manner based on the risk, costs and importance of the business system… Security Protecting people, processes and technology from threats in order to avoid a disruption of normal business operations… Technology Processes

Traditional Definitions of Availability
Utmost Reliability, Data Integrity and Security built in, 24x7 systems monitoring, business continuity services As systems approach 100% uptime, costs begin to skyrocket, demonstrating diminishing returns on your investment. While continuous business operation is often desired, solutions guaranteeing zero-downtime are often cost-prohibitive, especially after weighing all risks of failure and determining what kind of downtime is acceptable for your needs. $1OM Avg Syst Price Contiguous Processing Redundant Architectures Specialized Logic and Components Multiple Machines with Recovery Mechanisms, 24x7 proactive & reactive support $1M Fault Tolerant $1OOK Redundant system components, RAID for Data Fault Resilient High Availability $1OK Commercial Availability O.1 1 1O 1OO Downtime Hrs./Syst/Yr 99.999% 99.99% 99.9% 99.0% System Availability

Reality Check on Availability
Goal of availability planning is to balance cost, complexity, and flexibility in delivering the desired fault tolerance/recovery solution Majority of agency requirements are not at the highest levels of availability Assessment typically shows a varying level of availability requirements within an agencies IT infrastructure Implementing and guaranteeing higher end/ multiple 9’s availability is usually cost prohibitive to agencies is unrealistic in majority of environments due to complexity of implementation can be marred/ruined by simple human error or delay

The Continuity Continuum
Maintaining the availability systems critical to ongoing government operations during a system failure or service outage. Recovering from unplanned, catastrophic events or disasters in an orderly, timely, appropriate manner based on the risk, costs and importance of the business system Site/ Datacenter Failover Re-route data to replication/mirrored sites Commercial Recovery Sites Resuming in hot, cold, mobile or host facilities Site Beyond the Building Redundant Systems/Load Balancing Server, Storage, Network availability Clustering/Application Failover Continuous application access Application System Interaction Data Beyond the Box SAN, NAS & DAS Continuous data access Backup and Restore Real-time tape backup, Off-site storage Infrastructure Accelerators DellPlus Enterprise/client images Platform In the Box High Availability Server Systems Hot- swappable, redundant components with Mission-critical support Rapid Equipment Replacement Vendor services and financing programs Increasing cost, functionality and complexity

Building Blocks of High Availability
Availability scales through the continuum, addressing the causes of downtime and recovery at each level. Site  Beyond the Building ATTRIBUTES Custom Solution Site Replication Mirroring Stretch Clustering WAN load balancing Multi-tier Infrastructure Phone Home Systems Site Planning, Design & Implementation Change Management Optional HA Guarantee or Service Level Agreement Remote Monitoring Storage Service Provider On-Site Engineers/Parts Premium Support Disaster Recovery for Off-site Back-ups Application  System Interaction ATTRIBUTES HA Clustering Redundant Networks Application Failover/Restart Data Switchover Database Recovery Application Checking Network Load Balancing O/S Advancements Security/Virus Integration Application Monitoring Planned Online Upgrades Consulting Services Optional HA Guarantee Remote Monitoring Enh. /Premium Support Data  Beyond the Box ATTRIBUTES Redundant Data Paths Redundant Controllers Storage Area Networks Network Attached Storage Online Tape Backup Database Replication Online Volume Expansion Snapshot Copy Server Based RAID External SCSI Enclosure External Fiber Enclosures Enhanced Support Platform  In the Box ATTRIBUTES Hot Plug Devices Hot Plug Adapters ECC Memory Remote Management UPS Redundant Devices Enhanced Support Provide examples Components Data System Infrastructure REDUNDANCY LEVELS Increasing cost, functionality and complexity

Building Blocks of Disaster Recovery
Disaster Recovery scales through the continuum, to address recovery time objectives (RTO) for each level of failure… Site  Beyond the Building ATTRIBUTES Site Planning Design & Implementation Site Replication Hot site service Cold site service Mobile site service Disaster Recovery for Off-site Back-ups Off-site Data Storage Electronic Vaulting Consulting Services Application  System Interaction ATTRIBUTES Application Service Provider Application Failover/Restart Data Switchover Database Recovery Security/Virus Integration Application Monitoring Consulting Services Data  Beyond the Box ATTRIBUTES RAID Hot plug drives Tape Backup Database Replication Roll back/Roll forward Snapshot Copy Storage Mirroring Platform  In the Box ATTRIBUTES System Diagnostics Online Serviceability Reboot on Failure Remote Management Spare parts inventory Vendor rapid ship & deploy Lease\Financing programs Enhanced Support Hardware Data System Infrastructure FAILURE LEVELS Increasing cost, functionality and complexity

Small Organization Continuity Scenario
Business Continuity Plan Directly attaches to network Expandable up to 7.44TB capacity Hot swap drives and components Internal SCSI disks RAID 0, 1, 5 Business Continuity Plan Mobile and Workstation Users Expansion enclosures… Network Attached Storage (NAS) VA UPS Backup agent Tape autoloader GB capacity 8-36GB/hour Servers File/print Messaging/ Database Web serving Applications Clients Tape Backup Rack form factor Redundant power supplies, fans, NICs Hot swap drives and components Internal disks RAID 5 VA UPS Network/Communications SCSI Power Fractional T1 or T3 (ADSL backup)

Mid-Sized Organization Continuity Scenario
Business Continuity Plan Business Continuity Plan Tape autoloader 4TB capacity 80-216GB/hour Directly attaches to network Expandable up to 7.3TB capacity Hot swap drives and components Internal Fibre channel disks RAID 5, 1, 0 Mobile and Workstation Users Expansion enclosures… Network Attached Storage or Storage Area Network Tape Backup Mini-Library VA UPS Backup agent Redundant Servers Active-Passive Active-Active Production Servers File/print Messaging/ Database Web serving Applications Clients Automatic application failover Transparent to end-users Planned maintenance & upgrades Rack-dense form factor Redundant power supplies, fans, NICs Hot swap drives and components Internal disks RAID 0/5 VA UPS Network/Communications Fibre channel Power T1 or T3 (SDSL or Fractional T1 backup)

Large Organization Continuity Scenario
Business Continuity Plan Business Continuity Plan Tape autoloader 14.4 TB capacity GB/hour Fully redundant storage, 64 servers Expandable up to 8.7TB capacity Hot swap drives and components Internal disks RAID 5 Mobile and Workstation Users Expansion enclosures… Storage Area Network (SAN) Tape Backup Library VA UPS Backup agent Redundant Servers Active-Passive Active-Active Production Servers File/print Messaging/ Database Web serving Applications Clients Automatic application failover Transparent to end-users Planned maintenance & upgrades Rack-dense form factor Redundant power supplies, fans, NICs Hot swap drives and components Internal disks RAID 0/5 ,000 VA UPS Network/Communications Fibre Channel Power T1 or T3 (SDSL or Fractional T1 backup)

Enterprise Continuity Scenario
BCP Value Add Mid-range NAS High-end SAN Disaster Tolerant

N-Tier Architecture Add hardware where scale needed
Redundancy decisions made at each tier Simplified application development model Integrate Web technologies into legacy systems web services application data The flexibility of the Wintel architecture is critical to our implementation. We found that a traditional UNIX mid to high-range environment would bind us to large investments upfront and to a less flexible hardware and software architecture for the future. Bring web capabilities to legacy data.

Industry Perspective “The N-tier architecture is the best strategy for agility, multiple points of interaction, and site-level availability without a single point of failure.” – Meta Group “By partitioning Website functions into components that reside separately on different systems, enterprises can achieve greater availability, scalability, and flexibility.” Gartner Group Industry view of significance of scalable architecture. “Flexibility and improved high availability are both promoted by multi-tier computing architecture.” -- IDC

History of Dell.com 1994/95 1996 1997 1998 1999 2000 Q1 $1M/day
400,000 visits/week Q1 $5M/day Q2 $6M/day Q3 $10M/day Q4 $14M/day Q1 3,000 Q2 5,750 Q3 8,500 Q4 12,000 1,500,000 visits/week Q1 $18M/day Q2 $30M/day Q1 19,000 Q2 27,000 3,000,000 visits/week Q3 $35M/day Q4 $40M/day Q3 35,000 Q4 40,000 Q1 $40M/day Q2 $50M/day Q1 45,000 50,000 + Pages 4,000,000+ visits/week 50+% Total Revenue Launched E-commerce Launched Online Configurator Launched Premier Pages Launched Don’t walk through the data on this chart in it’s entirety. Thought it important to point out when we started scaling from single-tiered architecture to n-tiered – probably about Significant that our decisions for scalability in ‘94-95 came true for us in 97. 10K users on dell.com at any given moment. 80,000 visits/week

Basic Infrastructure web app data
This breaks down how our architecture is set up.

Site Architecture Hardware – Dell on Dell
Entire site runs on Dell hardware Development – Microsoft COM/DCOM Windows 2000, IIS, Commerce Server, SQL Website – Internally hosted and supported Multiple data center locations Eliminate “single points of failure” Resources – MS Trained and Certified MCSE, MCSD, MCP, etc. Might point out that we have 2 data center locations – but not where they are located for security reasons. Might point out that there are significantly more MS trained and certified IT personnel than UNIX based – speaks to TCO and dependency management. Some say 7 to 1 trained MS to Sun/Unix – not substantiated. MCSE: Microsoft Certified Systems Engineer MCSD: Microsoft Certified Solution Developer MCP: Microsoft Certified Professional

Server Utilization 10 static content web servers
Static HTML pages 120+ application servers Load Balanced with PowerApp.Big-IP Segmented by function and responsibility 50+ database servers Segmented by application support 160+ “non-production” backend servers Mirrors, staging, backup, prototype, & testing Load balancing works effectively for us. Flexibility of n-Tier architecture enabled us to add Big.IP server later in cycle. Big.IP – load balancing at the highest level (Level 7) where applications reside – turnkey device with optimized embedded load-balancing function for balancing multiple applications. Clustering on the back-end where apps are talking to data layer.

Availability 99.9985% 99.9985% = 6-7 minutes down time
99.999% = 4 minutes down time, plus magnitude of cost compared to 99.99% = approx. 1 hour The point of this slide is about how an organization can reach nearly 5 9s with a Dell/Microsoft environment and that they don’t have to go with a Tandem or Sun environment to get stellar reliability. Microsoft does guarantee 5 9s with the Datacenter offering, but there are too many variables to quantify the cost difference between 4 9s and 5 9s.

Web Servers Front-end web servers hold static content
Microsoft Windows 2000 Advanced Server Microsoft Internet Information Server 5.0 (IIS) Network Load Balancing (NLB) Provide access to applications Multiple mirrored copies of content PowerEdge 2550 servers (10) 2 processors, 512MB RAM, 5x9GB disk, RAID 5 The 10 web servers are all configured exactly the same. At any given time, there is only about 50 users difference between these servers. Customer information is backed up frequently – mirrored – most dynamic tier.

Availability: Web Services
Cisco Distributed Director Make point of our low-end servers are utilized for this layer and the round robin approach to load balancing via Cisco DD. This is the presentation services – customer facing layer. An example of how much flexibility this gives us – we add more web servers to support DHS business when necessary due to web traffic from end users. Static Layer uses “round robin” load balancing from the Cisco DD and all ten 2550 servers provide the same service. Loss of any server is not noticed by the site and can be easily replaced.

Application Servers Microsoft Commerce Server 2000
Separate servers by function Load Balanced “clusters” Smooth Scaling as needs arise Provides views “into” data layer Index and search Usage analyst Commerce applications Personalization and membership Content Deployment Service Custom developed components PowerEdge 4400 & 2450 servers (120+) 2 processors, 1-2GB RAM, 6x9GB disk, RAID 5 Make the point of clustering being utilized and our mid-range servers at this layer Servers in this layer.

Availability: Application Layer
The application layer uses both Windows clustering technology (Windows 2000 Advance Server - 2 node clustering) and intelligent load balancing “NLB” to provide high availability of applications as well as improved response time. Examples of applications are this layer: Enterprise Back-Up services, Intranet services, Configurator, Premier pages. Government example - applying for driver’s license online application.

Database Servers Microsoft SQL Server 2000
Standardized on one relational database Microsoft Cluster Server (MSCS) High performance ADO and Active Server Pages (ASP) Tight integration with Microsoft tools PowerEdge 6450 & 8450 servers (50+) 2-8 processors, 2-16GB RAM, 6x9GB RAID 5 External Storage when required Point out that this is tier is where we use our high end servers and external fibre channel storage. 50+ Database Servers ADO – stands for Active X Data Objects

Availability: Data Layer
PowerVault 6450 Data Base reliability is provided by utilizing RAID (Redundant Array of Independent Disk) 1 & 5 SAN Utilizing Fiber Channel Technology, offers high availability by providing redundant components including Host Bus Adapters, switches and RAID controllers within the storage array. PowerVault 650 PowerVault 630 We have worked to design and implement scalable high performance systems to handle the largest of computing jobs that are imaginable. Utilizing Dell’s high end servers and storage with all the bells and whistles – RAID, SAN, Fibre channel storage. Data center calibre. In fact, we believe that all computing jobs will be tackled by these open industry standard-based computing solutions.

Availability: Hardware
Redundant / Hot Swappable Power Supplies Fans Hard Drives – Replaced before failure through pre-failure warranty program * System Backplane supports hot plug – hard drive support Battery Backed Cache Dual embedded NICs with fail-over support * Self Monitoring Analysis, and Reporting, Technology (SMART) function sends notice to administrator that a hard drive is getting ready to fail The fast rise of commerce is what makes reliability a key part of the E-infrastructure. This is where you should talk to Dell’s reliability. Reliability is no longer just a concern of the IT organization. It is critical to customer satisfaction, and ultimately, to the bottom line and success of any organization. Three years ago, if a Web server went down, customers became frustrated; maybe the CIO heard about it; and more than likely, the CEO didn't hear about it. But today, if a Web site goes down, all hell breaks loose inside a company; and certainly, the CEO hears about it. More likely than not, if it is a large company, it's on CNN or CNBC.

Availability: System Mgmt.
Server & Application monitoring & alerting NetIQ AppManager® Dell OpenManage ISP and internal network operations Overall site performance reporting Keynote Systems Application Load testing Mercury Interactive LoadRunner® “Click stream” capture & analysis

Continuity of Operations
(Disaster Recovery)

Data Center Site Redundancy Primary data center has dual power feeds Two Different Power Companies Battery backup and generator power Multiple ISP connectivity Physical access restricted Data Back Up and Retrieval Data is Backed Up to disk then tape Tape Stored offsite – daily rotation 2 centers – can’t disclose locations. Physical location considerations Weather related Terrorist/hacker related Dual power feeds (two power companies) 10 minute window lost if entire data center went away – customer data

IDS Web Servers SQL Servers Data Center 1 Router FW FW ISP 1,2,3 3 x DS3 Cisco DD App Servers Corporate Network DMZ Web Servers ISP 4,5,6 3x DS3 SQL Servers Multiple ISP providers set up No “plug-in” power – never experience interruptions. Cisco DD FW FW Router Data Center 2 IDS App Servers

Web Infrastructure Security
Routers Follow rules based traffic acceptance Allow for minimum ports open (ex. HTTP, FTP, SSL) Firewalls DMZ-based architecture no sacrificial “honey pot” systems Servers Integrate NTFS security and Access Control Lists Limited "administrator" access to production servers Focus on good planning, not fancy technology Monitoring, Alerting, and Auditing Stay current on service-packs, patches, and hot fixes Year-round internal and external audits Two firewalls to get to data. CPU utilization per data center: Never above 35% Windows runs best at 70% So if one data center goes down, can pick up the load of the other center.

Security Policies and Procedures

Similar presentations

Presentation on theme: "Security Policies and Procedures"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Security Policies and Procedures

Similar presentations

Presentation on theme: "Security Policies and Procedures"— Presentation transcript:

Similar presentations

About project

Feedback