Privacy New Buzz Word In Business World.

Recently I have gone through a traning program which is said to be standard ethical practices and in that traning some question arised related to privacy. Although organization are on document defining what is ethical and what is non ethical but how many of IT manager understand it. Key buzz word which is responsible for revolution in US healthcare sector is privacy. Lets understand this and its relevance in ethical part for IT managers.

Does information’s availability justify its use?

Governments collect massive amounts of data on individuals and organizations and use it for a variety of purposes: national security, accurate tax collection, demographics, international geopolitical strategic analysis, etc. Corporations do the same for commercial reasons; to increase business, control expense, enhance profitability, gain market share, etc. Technological advances in both hardware and software have significantly changed the scope of what can be amassed and processed. Massive quantities of data, measured in petabytes and beyond, can be centrally stored and retrieved effortlessly and quickly. Seemingly disparate sources of data can be cross-referenced to glean new meanings when one set of data is viewed within the context of another. In the 1930s and 1940s the volumes of data available were miniscule by comparison and the "processing" of that data was entirely manual. Had even a small portion of today’s capabilities existed, the world as we now know it would probably be quite different. Should organizations’ ability to collect and process data on exponentially increasing scales be limited in any way? Does the fact that information can be architected for a particular purpose mean it should be, even if by so doing individual privacy rights are potentially violated? If data meant for one use is diverted to another process which is socially redeeming and would result in a greater good or could result in a financial gain, does that mitigate the ethical dilemma, no matter how innocent and pure the motivation?

How much effort and expense should managers incur in considering questions of data access and privacy?

This is an issue with both internal and external implications. All organizations collect personal data on employees, data that if not properly safeguarded can result in significant negative implications for individuals. Information such as compensation and background data and personal identification information, such as social security number and account identifiers, all have to be maintained and accessed by authorized personnel. Systems that track this data can be secured, but at some point data must leave those systems and be used. Operational policies and procedures can address the proper handling of that data but if they’re not followed or enforced, there’s hardly any point in having them. Organizations routinely share data with each other, merging databases containing all kinds of identifiers. What’s the extent of the responsibility we should expect from the stewards of this data? Since there’s no perfect solution, where’s the tipping point beyond which efforts to ensure data can be accessed only by those who are authorized to do so can be considered reasonable and appropriate?

What can employers expect from employees with regard to nondisclosure when going to work for another firm?

Many people are required to sign NDAs (nondisclosure agreements) and noncompete clauses in employment contracts, legal documents that restrict their ability to share information with other future employers even to the point of disallowing them to join certain companies or continue to participate in a particular industry. What about the rest of us, who have no such legal restrictions? In the course of our work for employer A, we are privy to trade secrets, internal documents, proprietary processes and technology, and other information creating competitive advantage. We can’t do a brain dump when we leave to go to work for employer B; we carry that information with us. Is it ethical to use our special knowledge gained at one employer to the benefit of another? How do you realistically restrict yourself from doing so?

What part of an information asset belongs to an organization and what is simply part of an employee’s general knowledge?

Information, knowledge, and skills we develop in the course of working on projects can be inextricably intertwined. You’re the project manager for an effort to reengineer your company’s marketing operations system. You have access to confidential internal memoranda on key organization strategic and procedural information. To build the new system, you and your team have to go for some advanced technical training on the new technology products you’ll be using. The new system you build is completely revolutionary in design and execution. Although there are areas of patent law that cover many such situations, there’s not much in the way of case law testing this just yet, and of course laws vary between countries. Clearly, you’ve built an asset owned by your company, but do you have a legitimate claim to any part of it? Can you take any part of this knowledge or even the design or code itself with you to another employer or for the purpose of starting your own company? Suppose you do strike out on your own and sell your system to other companies. Is the ethical dilemma mitigated by the fact that your original company isn’t in the software business? Or that you’ve sold your product only to noncompeting companies? What if we were talking about a database instead of a system?
In a bygone era, there was less data to work with, and the only quality assurance that needed to be performed was on data…operations and procedures were manual, so it was the output of those functions that was most critical. Technology has enabled vastly more complicated and interconnected processes, such that a problem far upstream in a process has a ripple effect on the rest of the process. Sarbanes Oxley requires the certification of all internal controls in large part for this reason.

Does data gathered violate employee privacy rights?
Many organizations have started adding a credit and background check to the standard reference check during the hiring process. Are those organizations obligated to tell us they’re doing this and what results they’ve received? The justification for doing the credit check typically is that a person who can’t manage his or her own finances probably can’t be trusted with any fiduciary responsibility on behalf of the organization. Does this pass the smell test or is this actually an infringement of privacy? Performing these checks is a relatively recent phenomenon, brought on in part by the desire of organizations to protect themselves in the wake of the numerous corporate scandals of the past few years but also because technology has enabled this data to be gathered, processed, and accessed quickly and inexpensively. Is technology responsible for enabling unethical behavior?

Do employees know the degree to which behavior is monitored?
Organizations have the right to monitor what employees do (management is measurement) and how technology systems are used. It’s common practice to notify employees that when they use organizational assets such as networks or Internet access, they should have no expectation of privacy. Even without that disclaimer, they really don’t need the warning to know this monitoring is, or could be, taking place. Do organizations have an obligation to notify employees as to the extent of that monitoring? Should an organization make it clear that in addition to monitoring how long employees are using the Internet, it's also watching which Web sites they visit? If employees are told there’s no expectation of privacy when using the e-mail system, is it an ethical violation when they later find out the organization was actually reading their e-mails?

Security Policies

Recently I was doing an audit for one of the BS7799 Certified organization. But after reviewing their security policies I was just shocked. Its totally mesh and not easily understandable . But then how organization got an certification. Reason being their is hardly a qualified auditors and professional available in industry. Some say that put lots of tool to show to auditors some say that create lots of document to review . I think auditors should react on it because any control say that the reports and log should be easily tracible and give concise and required information when asked. Bye the way enclosed an example of policies a its writing trick here.

Security policies help you define the level of security that is acceptable in yourorganization; they set a standard of care for every employee (and contractor).Security policies help you plan. Without them, there would be no way to tell which securitydecisions help increase your security and which are wastes of time and money. Even worse,there would be no way to identify areas that were overlooked.

Contents of a Security Policy: A security policy is a document although typically approved at the highest levels, it is not a high-level document (like a Mission Statement). Your security policy defines the resources that your organization needs to protect and the measures that you can take toprotect them. In other words, it is, collectively, the codification of the decisions that went into your security stance. Policies should be published and distributed to all employees andother users of your system. Management should ensure that everyone reads, understands, and acknowledges their role in following the policies and in the penalties that violations will bring.

When separate policies deal with secure networks, publication of those policies should be restricted to individuals who have authorized access to those networks. Security policies should emphasize what is allowed, not what is prohibited. Where appropriate, examples of permitted and prohibited behavior should be supplied. That way, there is no doubt; if not specifically permitted by the security policy, it is prohibited. The policy should also describe ways to achieve its goals.

An example of a security policy for passwords. This example is divided into several sections.

Generic Description of a Security Policy’s

Overview Justifies the reason for the policy and identifies the risks the policyaddresses.

Purpose Explains why the policy exists and the goal that it is written toaccomplish.

Scope Defines the personnel covered by the policy. This might range from a single group in a department to the entire company.

Policy This is the policy itself. It is often divided into several subsections.Examples are commonly used to illustrate points.

Enforcement Defines the penalty for failure to follow the policy. It is usually written as “everything up to and including…” so that a series of sanctions canbe applied. Dismissal is typically the most severe penalty but, in a fewcases, criminal prosecution should be listed as an option.

Definitions Any terms that might be unclear or ambiguous should be listed anddefined here.

Revision History Dates, changes, and reasons go here. This ties into enforcement in thatthe infraction should be measured against the rules in place at the timeit occurred, not necessarily when it was discovered.

Creating Your Own Security Policy

Creating security policies is a four-step process:

• Decide on your level of trust.
• Define appropriate behavior.
• Create a policy review team.
• Use the work of others.

Step 1: Decide on Your Level of Trust Assuming that people will do the right thing is easy and tempting. Don’t let yourself take this shortcut. Spell out what is expected and what is prohibited. Decide on the controls youwill use to measure adherence to the good practices that you are about to define. (This applies to programs as well as people.) Specify repercussions that will follow if employeesdo not adhere to practices. Trust different employees in different ways. Those withunprivileged access are in a different category than those with high levels of accessprivilege.

Step 2: Define Appropriate Behavior Whether the topic is email usage, password policies, or keeping company secrets, yoursystem’s users and the people who evaluate them must know what is expected. Your policiesare necessary to support an HR action in the face of inappropriate behavior, or even toprosecute a criminal case in extreme examples.

Step 3: Create a Policy Review Team The members of this team are responsible for drafting new policies and revising existingones.

Step 4: Use the Work of Others The previous section gave a pointer to a set of policies suitable for a large company. A Google.com search turns up literally dozens of sample policies for sale. Amazon has several books. You should investigate these resources and find one that matches your organization’sprofile. This will save you significant amounts of work. Even more important, it will keep you from accidentally omitting vital areas from consideration.

Members of the Policy Review Team

Representative From Duties Management Someone who can enforce the policy. This is often a senior memberof the HR staff. Information Security Department Someone who can provide technical insight and research. User Areas Someone who can view the policies the way a user might view them. Legal Department Possibly part time, but someone who can review policies with respect to applicable laws. For multinational firms, this review is exponentially more complicated. Publications Someone who can make suggestions on communicating the policies to the organization’s members and getting their buy in. Also, a goodwriter is always helpful.

A Sample Security Policy (Password Policy Extracted From Book )

1.0 Overview

Passwords are an important aspect of computer security. They are the front line of protection for user accounts. A poorly chosen password may result in the compromise of Example Corporation’s entire corporate network. As such, all Example Corporation employees (including contractors and vendors with access to Example Corporation systems) are responsible for taking the appropriate steps, as outlined below, to select andsecure their passwords.

2.0 Purpose

The purpose of this policy is to establish a standard for creation of strong passwords, the protection of those passwords, and the frequency of change.

3.0 Scope

The scope of this policy includes all personnel who have or are responsible for an account(or any form of access that supports or requires a password) on any system that resides atany Example Corporation facility, has access to the Example Corporation network, orstores any non-public Example Corporation information.

4.0 Policy

4.1 General

• All system-level passwords (e.g., root, enable, NT admin, application administrationaccounts, etc.) must be changed on at least a quarterly basis.
• All production system-level passwords must be part of the Information SecurityDepartment administered global password management database.
• All user-level passwords (e.g., email, web, desktop computer, etc.) must be changedat least every six months. The recommended change interval is every four months.
• User accounts that have system-level privileges granted through group membershipsor programs such as “sudo” must have a unique password from all other accounts heldby that user.
• Passwords must not be inserted into email messages or other forms of electroniccommunication.
• Where SNMP is used, the community strings must be defined as something other thanthe standard defaults of “public,” “private” and “system” and must be different fromthe passwords used to log in interactively. A keyed hash must be used where available(e.g., SNMPv3).
• All user-level and system-level passwords must conform to the guidelines describedbelow.

4.2 Guidelines

A. General Password Construction Guidelines Passwords are used for variouspurposes at Example Corporation. Some of the more common uses include: user level accounts, web accounts, email accounts, screen saver protection, voicemail password, and local router logins. Since very few systems have support for one-time tokens (i.e., dynamic passwords which are only used once), everyone should be aware of how to select strong passwords. Poor, weak passwords have the following characteristics:

1. The password contains less than eight characters
2. The password is a word found in a dictionary (English or foreign)
3. The password is a common usage word such as:

• — Names of family, pets, friends, co-workers, fantasy characters, sports teams,etc.
• — Computer terms and names, commands, sites, companies, hardware,software.
• — The words “Example Corporation”, “EXMC”, “BigApple” or anyderivation.
• — Birthdays and other personal information such as addresses and phonenumbers.
• — Word or number patterns like aaabbb, qwerty, zyxwvuts, 123321, etc.— Any of the above spelled backwards.
• — Any of the above preceded or followed by a digit (e.g., secret1, 1secret)

Strong passwords have the following characteristics:

1. Contain both upper and lower case characters (e.g., a-z, A-Z)Strong passwords have the following characteristics:
2. Contain both upper and lower case characters (e.g., a-z, A-Z)
3. Have digits and punctuation characters as well as letters e.g., 0-9, mailto:!@#$%^&*()_+~-=\`{}[]:“;’<)
4. Are at least eight alphanumeric characters long.
5. Are not a word in any language, slang, dialect, jargon, etc.
6. Are not based on personal information, names of family, etc.
   

B. Password Protection Standards Do not use the same password for Example Corporation accounts as for other non-Example Corporation access (e.g., personal ISPaccount, option trading, benefits, etc.). Where possible, don’t use the same password for various Example Corporation access needs. For example, select one password for the Engineering systems and a separate password for IT systems. Also, select a separate password to be used for an NT account and a UNIX account. Do not share Example Corporation passwords with anyone, including administrative assistants or secretaries. All passwords are to be treated as sensitive, Confidential Example Corporation information.

List of don’ts:

• Don’t reveal a password over the phone to ANYONE
• Don’t reveal a password in an email message
• Don’t reveal a password to the boss
• Don’t talk about a password in front of others
• Don’t hint at the format of a password (e.g., “my family name”)
  Don’t reveal a password on questionnaires or security forms
• Don’t share a password with family members
• Don’t reveal a password to co-workers while on vacationIf someone demands a password, refer them to this document or have them call someone inthe Information Security Department.
• Do not use the “Remember Password” feature of applications (e.g., Eudora, OutLook,Netscape Messenger).Again, do not write passwords down and store them anywhere in your office.
• Do not storepasswords in a file on ANY computer system (including Palm Pilots or similar devices)without encryption.

Change passwords at least once every six months (except system-level passwords whichmust be changed quarterly). The recommended change interval is every four months. If an account or password is suspected to have been compromised, report the incident to theInformation Security Department and change all passwords. Password cracking or guessing may be performed on a periodic or random basis by theInformation Security Department or its delegates. If a password is guessed or cracked during one of these scans, the user will be required to change it.

C. Application Development Standards Application developers must ensure their programs contain the following security precautions.

Applications:
• Should support authentication of individual users, not groups.

• Should not store passwords in clear text or in any easily reversible form.

• Should provide for some sort of role management, such that one user can take overthe functions of another without having to know the other’s password.

• Should support TACACS+ , RADIUS and/or X.509 with LDAP security retrieval,wherever possible.

D. Use of Passwords and Passphrases for Remote Access Users Access to theExample Corporation Networks via remote access is to be controlled using either a onetimepassword authentication or a public/private key system with a strong passphrase.

E. Passphrases Passphrases are generally used for public/private key authentication. Apublic/private key system defines a mathematical relationship between the public key thatis known by all, and the private key, that is known only to the user. Without the passphraseto “unlock” the private key, the user cannot gain access. Passphrases are not the same as passwords. A passphrase is a longer version of a passwordand is, therefore, more secure. A passphrase is typically composed of multiple words.Because of this, a passphrase is more secure against “dictionary attacks.”A good passphrase is relatively long and contains a combination of upper and lowercaseletters and numeric and punctuation characters. An example of a good passphrase:“The*?#>*@TrafficOnTheBridgeWas*&#!#ThisMorning”All of the rules above that apply to passwords apply to passphrases.

5.0 Enforcement

Any employee found to have violated this policy may be subject to disciplinary action, upto and including termination of employment.

6.0 Definitions

Terms DefinitionsApplication Administration Account Any account that is for the administration of anapplication (e.g., Oracle database administrator,Notes administrator).

7.0 Revision History
Policies commonly apply to less than all sections of the organization. Policies on acquiring commercial software or running a test lab or training department apply only to segments ofthe company, whereas policies such as an Information Sensitivity Policy (deals with keeping confidential company information private) or Password Policies apply across the enterprise.

Example Security Policies Several model security policies are available on the web. A good starting place is RFC 2196, “Site Security Handbook,” which discusses all aspects of security policies, fromcontent development to implementation. Another source of sample policies comes fromSANS. The direct link is www.sans.org/newlook/resources/policies/policies.htm. If thelink breaks, key the title of the page, The SANS Security Policy Project, into the searchthis-site box on the SANS home page.

Effectively Implementing Your Security Policy When you develop policies, you need to balance productivity and security. The goal of all good employees is to get their work done. If you create a rule that the employee thinks is just in the way, that employee will either ignore it or bypass it. Sometimes, you can implement technical controls to make sure that policies are followed (password changeperiods, for example), but other times you cannot. (A rule about never giving your passwordto someone else cannot be enforced by software.) You must make security a part of the corporate culture. This does not have to be done in a punitive way.

Here are two examples. A company whose policy called for password-protected screen savers or locked workstations whenever an employee was not using the PC was enforced by having security staff (uniformed guards on patrol) write “tickets”—they looked like parking tickets—and taping them to the monitor. The tickets reminded the users of the rules. The guards were taught how to Ctl-Alt-Del and pick Lock Workstation, and were instructed to do so whenever issuing a ticket. Another company had guards walk around after the close of business looking for laptop sleft unattended. They took laptops they found and left a “luggage receipt” on the desk saying that the lost luggage could be claimed at the security station. Avoiding Failure One sure way to make a policy fail is to apply it unevenly. If certain people, because of their position or influence, can bypass policies with impunity, the policies will all become unenforceable. You must get management buy-in, even if doing so is painful.

Security and Risk

Recently I got lots of mail from few of my friens specifying that they are interested to write an policies for organization. Soe are interested to know specifically a security policies. Although I explained to then its anot as simple as they think . Their is lots of misconsecptions present in Industry related to Security.

First of all understand that Security is not a firewall or cryptography or a virus scanner; although, they are all components of a security solution. It is a process that examines and then mitigates the risks that arise from your company’s day-to-day activities.
Or
We can say that Its an Tools and techniques that prevent unauthorized people or processes from doing anything with or to your data, computers, or peripherals.
If you think that technology will solve your security problems, then you don’t understand security and you don’t understand your problems.

Security includes a necessary mindset for every employee and specified procedures to follow, in addition to technology, to minimize the risk.

Risks come in a wide variety of forms. Here are some examples:
• Loss of assets (theft)
• Service disruption (business interruption)
• Loss of reputation (disparagement)
• Expenses of recovery (profitability impact)
Shareholders expect managers to protect or enhance the value of the company. Security breaches that affect any of these items violate shareholders’ expectations.

Another kind of risk is just now emerging: the risk of running afoul of the law. Many new laws include punitive measures (usually fines). Three examples from the United States are Graham-Leach-Billey, which affects U.S. financial institutions and requires disclosure of privacy policies customers; the Health Insurance Privacy and Portability Act (HIPPA), which restricts disclosure of health-related data along with personally identifying information; and the Electronic Communications Privacy Act (ECPA), which specifies who can read whose e-mails under what conditions.

You (or your management) can take five approaches with regard to any risk:
• Accept the risk—You must accept the risks in the following two cases:
— You cannot do anything about the risk (for example, a vendor goes out of business or a product is dropped).
— The cost of mitigation is not economical.
• Defend against the risk—You can deploy firewalls, antivirus products, encryption technologies, and so on. You can also establish procedures and policies.
• Mitigate the risk—Even if you assume that there is no such thing as a web server that cannot be broken into, you still don’t have to just accept the risk. Some of the things you can do include the following:
— You can reduce the harsh effects of a successful break-in by being ready to reinstall the web server at a moment’s notice.
— You can take steps to maintain the web server’s security.
— You can regularly audit its contents.
— You can examine its logs.
• Pass on the risk—You can ensure against the risk (sometimes).
• Ignore the risk—This is the only foolish choice. Ignoring the risk is not the same as accepting it. Ignoring it is merely hoping that someone else will be attacked.

Three of these (accepting, mitigating, and passing on the risks) are examples of threat reduction techniques. Reducing the threat is made easier if the proper security stance is selected. With every defense, you will use one of the following approaches:
• Permit nothing (the paranoid approach).
• Prohibit everything not specifically permitted (the prudent approach).
• Permit everything not specifically prohibited (the permissive approach).
• Permit everything (the promiscuous approach).
Of these, the prudent choice makes the most practical sense and is the assumed approach of this book. It is the one that most vendors choose. For example, Cisco access lists automatically deny everything not specifically permitted.