RMAS: Best Practices

RMAS Best Practices

RMAS has provided some Best Practices for assisting departments in establishing and maintaining standard business practices and internal controls. These Best Practices are not intended to be all inclusive and departments are encouraged to review all business procedures to identify risks and establish effective controls to mitigate those risks.

Financial & Operational Controls
Petty Cash
Account Reconciliation
Cash Receipts
Pcard
Travel & Reimbursement

Information Systems
Software Licensing
Password Management
User Management
Antivirus Management
Change Control
Computer and Network Security Best Practices
Credit Card Transactions Best Practices

Insurance
Automobiles
Alcohol/Liquor Liability
Builder's Risk
Personal Property
Claims
Contracts/Agreements
Equipment/Contents
Buildings/Property

FINANCIAL CONTROLS

PETTY CASH (rev. 7/03)

Petty Cash is the most liquid asset of an organization and is easily misappropriated if business processes and controls are not established. See Petty Cash policy at http://vpf-web.harvard.edu/documents/.

The following best practices should be established:

Petty cash should only be used for small dollar reimbursements, generally not to exceed $25, e.g. employee taxis, postage, office supplies, delivery charges, etc
Petty cash should not be used as an operating fund, e.g., should not be used to pay vendors for goods or services, employee salaries, wages, loans, or advances
Petty cash fund should be sufficient to cover reimbursements for a one month period. In general, petty cash funds should not exceed $100
One employee should be assigned responsibility as custodian of the fund. The tub financial dean or equivalent must approve custodians
Petty cash should be maintained in a secure location under the control of the custodian e.g., strong box or safe
Custodian should be responsible for reviewing receipts and dispensing funds
Custodian should maintain a Petty Cash Log including receipts for each disbursement. All disbursements should state business purpose, reimbursee, and date
Petty Cash Log should be complete - petty cash on hand plus receipts should always equal the original petty cash fund
Custodian should replenish the fund when cash balance is low
Prior to replenishing the fund, the custodian should make sure that cash on hand plus receipts equals the original balance of the fund. A supervisor or manager should approve the replenishment request
Custodians should close inactive petty cash funds
Local unit management should perform unannounced petty cash audits

ACCOUNT RECONCILIATION (rev. 7/03)

Reconciliation is the process of comparing the local unit's financial transactions to the general ledger. Reconciliation reduces the risk of inaccurate financial reporting. Local units should reconcile all transactions each month including payroll, web voucher, PCard, accounts receivable, cash receipts, and journals. Monthly reconciliations should be documented and reviewed and approved by local unit management.

CASH RECEIPTS (rev. 7/03)

Cash and check receipts are subject to misappropriation if not adequately controlled.

Best practices include:

Separation of duties, employees receiving and depositing cash and checks should not approve Credit Vouchers
Maintain log of cash and checks received, including copies of checks
Provide receipts to the payer, whenever possible
Restrictively endorse checks "For deposit only-Harvard University Local Unit Name" upon receipt
Establish a process for a supervisor to approve all Credit Vouchers
Safeguard cash and checks in a locked area prior to deposit
Make frequent deposits (at least weekly)
Obtain receipt for cash deposited directly with the bank
Maintain copies of Credit Vouchers in sequential order
Review and reconcile detailed listings to copies of Credit Vouchers each month

See additional cash management policy and procedures at Cash Management Series http://vpf-web.harvard.edu/documents/.

PCARD (rev. 7/03)

University policy governs the use of Harvard's Purchasing Card (PCard). See Purchasing Card Manual at http://able.harvard.edu/pcard/manual/. The program was implemented in 1997 as a cost effective method to purchase and pay for small dollar transactions. The intent was to pay vendors faster and reduce University administrative costs.

Best practices include:

Cardholders should:

Attend training and sign a cardholder agreement outlining their responsibilities
Keep the card in a safe location at all times
Use the card for Harvard business purposes only
Notify vendors of the University’s tax exemption
Edit transactions in the settlement system each week by including business purpose and modifying general ledger coding
Obtain receipts and submit them to the reviewer each week
Review monthly statement from GE Capital and reconcile transactions

Cardholders should not:

Share their card with other employees
Make personal purchases
Split transactions with the vendor
Purchase restricted commodities including out of town travel and meals, unincorporated vendors, and gifts over $75

Reviewers should:

Review all transactions prior to the weekly PCard sweep
Ensure spending is in support of University business and in compliance with policies and procedures
Ensure cardholders have provided adequate documentation to support business purpose
Check general ledger coding for accuracy
Compare detailed listings to the settlement system to detect unreviewed transactions
Maintain receipts in compliance with University record retention policies
Collect cards from terminated employees and notify/send cut up card to Tub and Central PCard Administrators

TRAVEL AND REIMBURSEMENT (rev. 7/03)

Employee travel and reimbursement transactions must be managed to meet operational needs and compliance requirements. Travel expenses must comply with University policies and procedures. These policies should be applied consistently to all travelers. See Harvard University Travel and Entertainment Policy and Reference Manual at http://www.travel.harvard.edu/.

Employee reimbursement transactions must also comply with IRS accountable plan rules regarding substantiation and timing. Certain expenses are personal in nature and are not reimbursable or are reimbursable only when specific criteria are met and financial dean or equivalent approval is obtained. See Reimbursements- Travel and Non-Travel Policy and University-wide Business Expense Policy at http://vpf-web.harvard.edu/documents/. In addition, sponsored travel may have separate requirements. Contact the Office for Sponsored Research for specific policies and procedures regarding sponsored travel.

The following best practices should be established:

Local units should contact your tub finance office to arrange Travel and Reimbursement Policy training
Employees should comply with University Travel and Reimbursement Policies
Frequent travelers should use the Corporate Card (AMEX)
Travelers should book airline travel through the Harvard Travel Center or one of Harvard’s preferred travel agencies
Local units should have a process to approve employee travel and reimbursements
Reimbursements must be submitted within 60 days from date of expenditure. Exceptions require approval of the financial dean or equivalent.
Travel expense reports should be reviewed for accuracy and reasonableness including accurate coding of transactions
Original receipts and other supporting documentation must be submitted for all transactions greater than or equal to $75. Tubs may set a lower dollar threshold.
Missing Receipt Affidavits must be competed where applicable and signed by both the traveler and approver
Business purpose must be documented and include who incurred the expense, what the expense entailed, why this is a Harvard expense, when the expense occurred, and where the trip took place
Travelers do not use first class travel without prior written approval from the President, Dean or Vice President
Travel advance requests should be necessary and reasonable
Travel advances should be settled in a timely manner
Administrators should review and reconcile detailed listings monthly

INFORMATION SYSTEMS

PASSWORD MANAGEMENT (rev. 02/21/06)

The conscientious management of password practices is a critical element for information security. Passwords are the keys that control system access. Adhering to secure password procedures will help reduce the compromise of user accounts on the University’s systems.

Since today's computing technology environments are increasingly interconnected (networked), and sophisticated password cracking programs are freely available to anyone, the compromise of any single computer system or account through the revelation or theft of a single password can place whole communities of data in jeopardy. Adopting and abiding by secure password procedures have become a vital and shared computer responsibility.

Best practices for secure password management include the following points:

Never share passwords with anyone. For example: Never share your password with administrator or support staff requesting it to solve an urgent problem. (This also means that the administrator or support staff should never ask a user for their password. Have the user login if necessary.)

Password complexity: Establish policy and train users on choosing strong, hard to guess, passwords.

Passwords should be a minimum length of eight characters.
Passwords should be a combination of upper and lower case letters including at least one numeric and/or special character.
Passwords must contain at least five different characters.
Passwords should NOT be names, words, or anything else easily guessed by those who know you.
Passwords should NOT contain more than four consecutive numbers.
Passwords should NOT be a date.
Passwords should NOT be based on a single word, or consist of two words separated by a space, hyphen, or underscore character.

Risk Management and Audit Services recommends invoking systemically enforced password complexity options where available on servers and applications.

As mandated by University security policy, use Personal Identification Number (PIN) to protect applications with access to confidential information whenever possible. See http://www.security.harvard.edu

Default passwords: Establish procedures for management of default passwords.

System Administrators must change default passwords on all system accounts before connecting a server to the network.
Users should always change any passwords they were given for initial access the first time they use a system.

Password Changes: At a minimum, users should abide by the University security policy (see http://www.security.harvard.edu ). The policy mandates that users change passwords where required by law, contract, or other external rules. Examples include, but are not limited to, the Health Insurance Portability and Accountability Act, the Gramm-Leach-Bliley Act, and Payment Card Industry Standards.

The University security policy also mandates password changes where someone can create an entity that can receive payments from Harvard and then authorize such payments.

In addition to University policy, Risk Management and Audit Services recommends that server administrators should change their passwords at least once every 90 days.

In lieu of password changes, a multi-factor security authentication mechanism such as SecurID or biometrics could be used. Multi-factor authentication employs the concept of ‘what you know’ (your password) combined with one or both of the following: ‘what you have’ (your token such as a smart card) and ‘what you are’ (your finger print or eye scan). The university PIN system is being enhanced to support smart cards.

Password reuse: Do not reuse passwords within 12 months where password changes are required.
Compromised passwords: Change a password as soon as there is any suspicion that it has been compromised.
Password Protection: Train users to keep their passwords secure. Users should:

Avoid writing down passwords (If you must write a password down, keep them on your person or locked in your desk. If electronically saved they should be in a file using a secure encryption technology.)

For additional information regarding the University’s password management security policy, see http://www.security.harvard.edu.

SOFTWARE MANAGEMENT

A good software management program includes keeping track of the organization's software use and documentation and providing training and awareness to staff on software use and copyright laws. By closely monitoring the organization's software use and documentation the organization is better able to control software costs, increase interoperability and productivity, and monitor compliance with copyright laws.

For instance, by having a master list of all software and its users it is easier to identify commonly used software. Purchases can be consolidated to take advantage of volume discounts. In addition, interoperability can be improved when staff use the same version of software. Also, if one department has a need for a software package, the master software list can be reviewed to see if the software is being used elsewhere in the organization. Furthermore, an effective software management program would place an organization in a better position, if they were to face a software audit by any outside agency.

Best Practices for implementing a software management program are:

Develop an awareness program that educates users on copyright laws and what their responsibility is for compliance.
Develop and document a software compliance statement.
Create and maintain a central file for ownership documentation.
Create and maintain a software log.
Perform an annual self-audit.

USER MANAGEMENT

User Management is one component of a conscientious information security policy for systems. It involves rules for granting access, and procedures for granting, changing and deleting access for users of a system. While the formality and numbers of people involved will vary, best practice in implementing a user management program will include:

1. Develop an access policy and strategy for implementation.

Develop, approve and implement formal information access criteria
Develop, approve and implement standard user access profiles based upon the system owner's information access criteria. Test each standard user profile before implementing into production. This ensures that the functionality of user access profile agrees with the system owner's access criteria.
Systems should be designed so that the default access is either NO ACCESS or the lowest level of access ever granted. This will help ensure that additional access privileges aren't given out inadvertently.

2. Procedures for granting new users access to the system.

Identify who should have access.
Identify what data the individual should see. For example: only data for a certain department or certain types of data (names and addresses but not salary).
Identify what the individual can do with the data. Access should be based on what is required for them to do their job. Some examples of things to consider:
Read only access versus ability to create or change.
Ability to create versus ability to approve.
Highly sensitive functions, should be restricted to a few individuals.
Ability to change some data but not all fields.
Who can approve requests for new users.
Ensure that each user access request is documented, validated and approved prior to be implemented.

3. Procedures for dealing with changes to access privileges.

Forms and processes for requesting changes.
Who approves changes.

4. Procedures for monitoring systems usage and reviewing access privileges when:

Users don't use the system for a prolong period ( what's considered prolong will vary from system to system)
Users change responsibilities.
To facilitate ongoing review department mangers may be asked to review current users on a periodic basis. The period used, quarterly, monthly, etc. would be determined by the rate of change of the user population and the sensitivity of the system involved.

5. Procedures for disabling system access when users no longer have a need for it.

Inclusion of system access removal on a termination checklist.
The periodic manual review mentioned above could also help to catch users who no longer need access.
Where feasible, periodically monitor the effective termination of users by electronically comparing their current system access privileges to their current organizational roles within the human resource system.

ANTIVIRUS MANAGEMENT

This Best Practice is intended to describe processes that IT support organizations should follow. The section on user awareness and education would be a general interest to anyone who uses computers in their work.

Background

Computer viruses can destroy software and data and bring down entire networks.

During 2002, viruses grew at a rate of around 600-700 new ones each month and growth is expected to continue at this rate for 2003. Nine out of last year's top 10 viruses were spread by email on Microsoft Windows platforms.

Policies and procedures should be in place to protect against contamination from these viruses.

These policies and procedures should contain sufficient information to prevent destruction of data and systems by viruses. They should include user awareness and education, virus prevention and virus containment program.

User Awareness and Education

Users are a key component in an antivirus defense program. Increasing users’ knowledge on how to prevent or detect viruses lowers the risk of contamination.

The following are guidelines on user awareness:

Stress the potential damage from viruses, explaining that viruses can trigger harmful events. When a virus is stopped damage is minimized.
Encourage responsible use of software. Stress the importance of keeping original “clean” program disks in a secure location.
Provide clear instructions on back up procedures including accountability and storage location.
Stress avoidance of situations with possible outside contact with viruses such as sharing diskettes and downloading on-line files.
Stress that any e-mail that arrives with an attachment only, or with an attachment from an unknown source, should not be opened and should be deleted immediately and appropriate personnel notified. Many virus writers are interested in creating the next super Windows worm, spread by email or instant messaging, as these mass-mailing viruses carry the greatest impact.
Explain that there will be false alarms, but that these are preferable to the danger of real virus damage.

All users should be informed about virus symptoms including:

Any unusual message, music, or graphic displays.
Significant extension of the time it takes to access a diskette.
Significant and unusual reductions in free space or available RAM.
Strange behavior in Microsoft Word, Excel or other applications that support macros.
Change in the size of files and their contents. · Unexplained system interruptions.

Virus Prevention

Install antivirus software on all servers and desktops.
Update virus definitions at least monthly.
Where possible, configure software to update virus definitions on desktops without requiring user intervention.
Install antivirus software on email servers to block or remove email with file attachments that are commonly used to spread viruses, such as .vbs, .bat, .exe, .pif and .scr files before forwarding to users.
Keep up-to-date on security patches that cover up holes exploited by viruses.
Turn off and remove all unneeded services. (i.e. ftp, telnet, and web server). These services are avenues of attack. If they are removed, blended threats have less avenues of attack and you have fewer services to maintain through patch updates.
If a blended threat exploits one or more network services, disable, or block access to, those services until a patch is applied.
Enforce a password policy. Complex passwords make it difficult to crack password files on compromised computers. This helps to prevent or limit damage when a computer is compromise
Subscribe Network Administrators to UIS’s NetManager Listserv.

Virus Containment

Incident handling procedures for users in the event of a contamination

Notify your IS support function
Avoid doing work on the infected machine until it can be cleaned up.

Incident handling procedures for IS organizations in the event of a contamination

Who to notify
Notify UIS-NSIRT
Users
What steps to perform to contain the virus
Shutdown of as much of the network as is necessary to reasonably assure that the virus is contained.
Scan and disinfect the system until a pre-infection baseline is reached and the system runs clean.

CHANGE CONTROL

Change Control is the process that management uses to identify, document and authorize changes to an IT environment. It minimizes the likelihood of disruptions, unauthorized alterations and errors.
The change control procedures should be designed with the size and complexity of the environment in mind. For example, applications that are complex, maintained by large IT Staffs or represent high risks require more formalized and more extensive processes than simple applications maintained by a single IT person. In all cases there should be clear identification of who is responsible for the change control process.

A change control process should consider the following elements:

Change Request Initiation and Control

Impact Assessment

Control and documentation of Changes

A brief functional description of the change
Date the change was implemented
Who made the change
Who authorized the change (if multiple people can authorize changes)
What technical elements were affected by the change e.g., program modules, database tables or fields, screens and forms

Documentation and Procedures

Authorized Maintenance

Testing and User signoff

Testing Environment

Version Control

Emergency Changes

Distribution of Software

Hardware and System Software Changes

If a vendor supplies patches, they should be reviewed and assessed for applicability and potential impact to determine whether their fixes are required by the system.

Computer and Network Security Best Practices (3/15/04)

A comprehensive best practices by University Technology Security Officer, Scott Bradner

Background:

There are over 50,000 computers connected to the Harvard networks. Most of these computers have been the targets of an attack from the Internet or from someplace else at Harvard at some point in the past and it is reasonable to expect that Harvard's computers will continue to attract the attention of computer hackers. Computer operating systems, even for personal computers, have progressed to the point that almost all computers can be accessed remotely, too often without the owner's permission. In addition, email-based attacks have become all too common.

There are a number of reasons that people attack Harvard computers. Some people seem to get a thrill out of breaking security and, sometimes, wreaking havoc on systems they break into. While these attacks can be very disruptive and annoying they are not as dangerous as attacks where the purpose is to find or modify information.

There are a number of computers (we can call them "target computers") at Harvard that contain information that might be of interest or use to computer hackers or even to terrorists. They include computers with information about the existence, location, or properties of biological, radiological, or chemical materials that could be a used to attack individuals or facilities. In addition, there are many computers connected to the Harvard network that contain personal information about individuals including faculty, staff, students, alumni and others including research subjects.

It is not enough to just focus in on these "target computers." Any compromised computer on the Harvard network can be used to launch attacks on other computers at Harvard or elsewhere. Compromised computers can also be setup by an attacker to be a repository of illegal copies of copyrighted material or of pornography. Harvard's Internet connections are very high speed and thus creating such a repository on the Harvard network provides for very good service to its users.

Over the years the computer and networking industry has developed a series of "best practices" to help minimize the chance that a computer will be compromised, or if it is, minimize the chance that the computer could be used to attack other computers. They are called "best practices" (or BPs) for ease of reference, not to claim that they represent the absolutely best way to protect computers. Even if they may not be perfect, following these best practices will significantly improve the security of your computers.

The following best practices should also be followed for all computers connected to the Harvard University data networks to minimize the chance that the computers could be compromised, or if they are compromised, minimize the chance that they could be used to attack other computers at Harvard or elsewhere on the Internet. Specific best practices that should be emphasized for computers that might be targets of special interest to hackers or terrorists are noted under the heading "target computers". It is still a good idea to follow as many of these practices as possible for all computers. In the case of target computers, there must be very good reasons to not follow any of them.

Best practices for computer operation:

Principle: ensure that the software on computers is secure and the machines are operated in a way to minimize the chance of a security breach.

COP1: The software on any computer connected to the Internet or an internal network must be kept up to date with regard to security patches; default account passwords must be changed and all other normal good computer security practices must be followed. The computer manager should do a weekly review of security alerts or subscribe to appropriate security mailing lists.

COP2: Only people with a specific need to use a particular computer should have accounts on it.

COP3: Shared use of a single computer account must not be permitted. Passwords for individual accounts must never be shared or recorded in some common place. Support staff should never ask a user for a password, even to solve an urgent problem. (Have the user login if need be.)

COP4: Passwords must not be written down, never be a name or a word in a dictionary, should be at least 8 characters long, and should include at least one number or special character. If software is available on the computer to enforce the use of good passwords, it should be enabled.

Best practices for computer setup:

Principle: Utilize secure access technology and limit access to those individuals who must have it.

SET1: If the operating system includes firewall functionality, it should be configured to permit incoming session establishment only to the TCP and UDP ports for the specific services that will be run on the particular computer.

SET2: All unneeded services should be disabled and their server software prevented from running.

SET3: All systems offering services over a network should also make use of the network service wrappers recommended by the CERT (http://www.cert.org) and software, such as Tripwire, to monitor the integrity of the software on the system.

Target computers:

SET4: Computers that could be target computers should be connected to a network if the ability to only connect to them via a network or their ability to connect to other network resources is a required part of their operation. Likewise, they should be visible to the Internet only if Internet connectivity is required for their operation.

SET5: Computers that could be target computers that must be connected to a network should be dedicated to a specific purpose. They should not be used as general-purpose servers and should not have any services enabled on them other than the services specifically required. For example, potential target computers should not also be operating as email servers or web servers.

SET6: Access to these computers should be limited to local console access or authenticated and encrypted network-based access. Specifically, services such as telnet and ftp should be disabled so that access requires the use of secure communications technologies such as SSL/TLS or SSH.

SET7: The use of smart cards for user authentication of system administrators is encouraged where computers contain particularly sensitive information or provide core university services.

SET8: Logs should be maintained of everyone who accesses a target computer, any incorrect access attempts, and the log should be monitored for evidence of brute force attacks. The logs should be maintained on a computer other than the one being monitored.

SET9: Backup copies of all key system files, especially files containing access control lists, certificates, certain configuration files and application image files, should be maintained so that a compromised system can be recovered quickly.

Best practices for network architecture and configuration:

Principle: Isolate computers as fully as possible while permitting access for specific functions. Minimize the chance that communication with such computers can be usefully monitored.

ARCH1: To minimize the chance that communications to and from a computer can be overheard, each computer must be plugged into its own port on an Ethernet switch (not a hub) and all other computers in the same group should also be individually connected to switch ports instead of Ethernet hubs. Ethernet switches segment network traffic and ensure that traffic destined for a particular computer does not get forwarded to other computers where it might be monitored

Target computers:

ARCH2: To restrict the connectivity to target computers to legitimate users, Access Control Lists (ACLs) should be configured in the Ethernet switch or in the router connecting the switch to the rest of the network. The ACLs should by default block access for all protocols and for all TCP and UDP ports on the target computers. ACLs can then be added for each computer offering a network accessible service to enable access to just those applications that have been authorized to be run on that computer. Where possible, these ACLs should enable access only to the selected applications from the specific IP addresses of specific computers in those cases where the number of users is small and where the location of the users are known and fixed. Access through a router to a target computer by a non-secure service should never be possible. (For example, SSH and SSL are secure services, telnet and non-SSL web are not and should be blocked.)

ARCH3: Use of firewalls in addition to router-based filtering is highly recommended to effectively segregate & secure data, applications, and web access components so as to minimize the vulnerability of critical components. Such firewalls should include features such as monitoring for viruses in incoming email or web traffic. Firewalls are most effective when they are between all possible attackers and the potential target -- this means that they should be located between a group of computers offering network-based services and the rest of the school network. This will deal with a situation where an attack is coming from a compromised local computer or from a legitimate user of a local computer. It should be noted that historically, the majority of network attacks are perpetrated by people working for the attacked company.

Best practices for network operation:

Principle: Network operators should monitor network activity for signs of attack and take action in the absence of the operators of a compromised computer.

NOP1: The operators of school or University backbone networks should run intrusion detection systems to scan for signs of network-based attacks on computers connected to the University networks.

NOP2: In cases of emergency, network operators should block some or all network traffic to or from a computer that the operators have reason to think may be under attack or has been compromised and is being used to attack other computers.

NOP3: Operators of school or University backbone networks should also, with prior permission from system owners, conduct vulnerability scans of computers connected to University networks to be sure that the software on the computers is up to date.

NOP4: The response to any security incident should consistently follow a predetermined checklist that includes steps to end the incident, repair the damage, prevent a repeat attack, and scan for new vulnerabilities.

Credit Card Transactions Standards

Background

Increasingly many Harvard units are accepting credit cards either over the web or via fax or telephone. Unfortunately that allows these units to be perfect targets for bankcard fraud. Scamsters are taking advantage of the fact that they can operate anonymously. They know that many of the credit card features that prevent fraud in the physical world do not apply in the card-not-present environment. We must understand that there is a greater need for protection against fraud exposure and associated losses. This is primarily because card-not-present merchants can be held financially responsible for a fraudulent transaction, even if the card Issuer has approved it. Below are guidelines Harvard has established for protecting credit card data and transactions.

Credit Card Authorization Online Verification

Schools and departments that are planning to accept credit cards must contact Cash Management at extension 5-4397. Cash Management will work with you to set up both the credit card merchant account and the bank account. Cash Management will also provide you with procedures to process your credit card transactions and help you develop procedures to manage these activities.
Departments or schools that have existing applications that accept credit card data must be compliant with Payment Card Industry (PCI) Data Security Standards
Departments and Schools that desire to start accepting online transactions should have the verification take place through Harvard's credit card authorization server. The server will be responsible for maintaining compliance with PCI data security requirements and with standards for fraud prevention established by Cash Management. Your application or web site will receive an authorization code or a rejection code. You can also receive a profile number that you can use to identify the customer for future transactions, refunds, or partial credits. Please note that your local business practices and website that links to the server also must conform to PCI standards.
Using this method means that Harvard University never actually retains the credit card information and does not have to deal with the security of this sensitive data. Customer charge backs can also be processed through the server.

Phone, Mail, And Fax Credit Card Transactions

If you accept credit cards either over the phone, mail or via fax, you will need to do one of the following:
- Lease a point of sale terminal that allows you to enter credit card account numbers and expiration dates. The terminal uses the phone line or encrypted Internet connections to contact a service provider that will authorize the transaction. Work with cash management to use our preferred vendors.
- If you have a CyberSource account for use on a website you may use their virtual terminal
- Develop an application that your staff can use to enter transactions through the server described above. This is the preferred method because you don't have to store credit card information electronically.

Physically Swiping Credit Cards

Lease a point of sale terminal that allows you to enter credit card account numbers and expiration dates. The terminal uses the phone line or encrypted Internet connections to contact a service provider that will authorize the transaction. Work with cash management to use our preferred vendors.

Data Protection

Credit card providers have combined their individual specific security rules into the PCI Data Security Standard. These rules are designed to prevent abuse of the data and protect the consumer from some forms of identity theft. Failure to follow these requirements can involve severe penalties, including fines and prohibition from further acceptance of the credit cards. The PCI standards involve 12 requirements outlined in 6 sections. They are summarized below but more detail can be found at this on Visa's website. (www.visa.com)

Build and Maintain a Secure Network
1. Install and maintain a firewall configuration to protect data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
1. Protect stored data
2. Encrypt transmission of cardholder data and sensitive information across public networks
Maintain a Vulnerability Management Program
1. Use and regularly update anti-virus software
2. Develop and maintain secure systems and applications
Implement Strong Access Control Measures
1. Restrict access to data by business need-to-know
2. Assign a unique ID to each person with computer access
3. Restrict physical access to cardholder data
Regularly Monitor and Test Networks
1. Track and monitor all access to network resources and cardholder data
2. Regularly test security systems and processes
Maintain an Information Security Policy
1. Maintain a policy that addresses information security

Compliance Certification

Visa and MasterCard require compliance with PCI standards. Additionally, they require that larger vendors (which includes Harvard) must be certified to be compliant by an approved third party vendor. The certification process requires completion of an annual questionnaire and quarterly remote vulnerability scans. All outward-facing IP addresses as well as URL's on network segments that have servers that accept, store or transmit credit card numbers must be tested and certified.
Harvard has selected TrustWave Corporation to perform these tests. TrustWave provides test results directly to Bank of America, who is our acquiring bank for credit cards. Bank of America is responsible for reporting our compliance status to Visa and MasterCard.
If you are using third party service providers in whole or in part to accomplish on line acceptance of credit cards, you may need to obtain a copy of their compliance certificate. Please check with Cash Management to see if the University already has received compliance certificates from your vendor.
Cash Management coordinates the compliance efforts. Cash Management will pay for the first year cost of compliance.

Transaction Monitoring

You should perform the following monitoring on credit card transactions
- Look for returns or charge backs. This is where the cardholder has disputed the charge. A large number of these might indicate that your site is being used for fraudulent activities. A large percentage of these might also subject you to additional fees from the bank.
- Perform daily reconciliations between what your local system is recording and the bank is posting. Cash management can provide online tools that will help you do this.

Disclosure of Potential Breaches

In 2003, a California State Law went into effect that requires disclosure from companies in the event of unauthorized access of non-public customer information. The law applies if there are any California residents in your database. The law is triggered by any incident in which customer data is "reasonably believed" to have been compromised. There is an exemption in the law if the data is encrypted.

VISA and MasterCard require merchants to have an incident response team to deal with potential breaches of credit card data. Harvard Policy is that any security incident or potential breach involving systems that accept, process or store credit card information must be immediately reported to Cash Management. Cash Management will involve a credit card incident response team comprised of representatives of Cash Management, UIS Network Services, RMAS, & OGC. This team will work with your local business and technical people in investigating and remediating the situation. Cash management will be responsible for notifying our acquiring bank of any breaches. Local units will be responsible for any fines or penalties resulting from breaches of their data.

Local Policies

You should carefully consider your business needs and develop policies on the following issues:
- Charge backs: How will you handle complaints that the charge was not legitimate? What investigation, if any, will you do? Who needs to be notified?
  
  If you are experiencing frequent charge back complaints or suspect fraud, you need to contact Cash Management @ 5-4397
- Data Access: There should be very few people that have access to credit card data after the transaction has been authorized. Other authorized users should either not see any data or see a masked number with only the last 4 digits visible.
- Passwords: Ensure that any passwords that protect credit card data are different from other passwords you have and are hard to guess and not written down and left unsecured. PCI also requires that passwords require periodic changing.
- Retention: You should have a local data retention policy that determines how long you retain credit card information. Keep cardholder information storage to a minimum. Limit your storage amount and retention time to that which is required for business, legal, and/or regulatory purposes, as documented in your data retention policy.
  - Electronic - Ideally credit card numbers will not be stored locally in electronic form. If your business requires that you temporarily store credit card account numbers then they should be securely disposed of when they are no longer needed. It is permissible to retain the last four digits of the credit card number.
  - Paper - Federal and credit card association require merchants to retain the original signed credit card merchant slip for 2 years. These should be kept locked on site for 2-3 months and then placed in archives for the remainder of the 2 years. They should be securely destroyed directly from archives.
- Changes: Before making any changes to your technical architecture or business practices regarding credit cards you should insure that you would still be in compliance with PCI data security requirements. Your change control process should include having a direct scan done by TrustWave on your new environment prior to placing it into production.

INSURANCE

AUTOMOBILES

University-owned vehicles can only be used for business purposes and cannot be used for personal use. An authorized driver must be an employee of the University, at least 18 years old and must possess valid and applicable licenses.
Departments should have written policies for use of personal vehicles for business purposes. (Employee's insurance primary and not all losses/costs are reimbursable).
Use the University Corporate Rate with Hertz and Budget for Rental Vehicles whenever possible since this rate includes all necessary liability insurance.

ALCOHOL/LIQUOR LIABILITY

Any University location selling liquor must be specifically list on the Liquor Policy in order to be insured or must using a caterer with Liquor Liability Insurance (need to obtain proof of insurance).
Employees need to adhere to applicable laws pertaining to not serving minors and not serving those intoxicated at business functions where alcohol is dispensed.

BUILDER'S RISK

Departments undergoing Capital Project Renovations or high exposure renovations must purchase Builder's Risk Insurance for the period of construction/renovation.
All contractor's must provide a Certificate of Insurance evidencing General Liability, Workers' Compensation and Automobile Liability Insurance.

PERSONAL PROPERTY

Inform employees that the University is not responsible for personal property brought into the workplace.

CLAIMS

Educate employees about procedures to follow in the event someone is injured on the premises.
Provide training to employees to respond to emergency situations involving property damage to University buildings.

CONTRACTS/AGREEMENTS

Prior to signing, have all contracts and written agreements reviewed by the Insurance Department and Office of the General Counsel for appropriate wording for indemnification and hold-harmless clauses.

EQUIPMENT/CONTENT

Take necessary precautions to protect University property from loss using appropriate storage and security methods.
Obtain Equipment/Content Insurance to protect against losses due to theft and for items on loan, rent, lease or exhibit.

BUILDINGS/PROPERTY

Notify the building manager and appropriate personnel of any potential risk or exposure to the building and surrounding grounds.