Office of Compliance Programs

Information Security Training for Information Technology (I.T.) Professionals

Revised September 19, 2017

Introduction

The security of the information held by LSUHSC-NO is the responsibility of every member of the faculty and staff and every student. Because of your expertise, LSUHSC-NO faculty, staff and students look to you for advice on how best to secure this information.

Ubiquity of Computing

Today nearly everyone in the world has a smartphone connected to the Internet, with more computing power than all the computers it took to go to the moon put together. This unprecedented access to information and computing power has grown faster than the ability of most people, or our culture as a whole, to comprehend or manage. For example:

Individuals who would strongly object to their employer releasing information about them, freely post the exact same information on their social media account simply because the service asked them.
People readily make use of free online services and storage while giving little thought to where that information is being stored or who has access to it.
Faculty, staff and students make increasing use of personal devices for work and school purposes without considering the obligations that entails or the consequences if something goes wrong.

Exacerbating this problem is the number and variety of devices that can store and exchange data. Devices are no longer limited to desktops, laptops, printers, flash drives, phones and tablets. TVs, fitness trackers, watches, automobiles, medical instruments, and a whole host of other devices are being connected to the Internet.

Increasing Frequency and Sophistication of Attacks

Cybersecurity-related attacks have become not only more numerous and diverse but also more damaging and disruptive. New types of security-related incidents emerge frequently. It is estimated that for every minute that goes by an average 3,653 more records are breached.As more and more of our personal information is concentrated in large online data structures, it becomes more and more attractive to individuals and entities who would use that information for less than honorable purposes. Breaches at Target (retail), Yahoo (online services), Office of Personnel Management (government), Anthem (health insurance) Sony (entertainment), Equifax (credit services) and even the Democratic National Committee show that no sector of the economy or government is immune from malicious attacks.

Increasing Regulation of the Computing Industry

To combat these attacks and help the public better protect itself, federal and state governments have passed a number of laws aimed at improving protection of online information and mitigating the harmful effects when a breach occurs.Some of the laws that apply to LSUHSC-NO include but are not limited to:

The Health Insurance Portability and Accountability Act (HIPAA) - Health information
The Database Security Breach Notification Law (LA R.S. 51:3071 et seq.) - Financial Information
Privacy of Student Information (LA R.S. 17:3913 et seq.)
The Family Education and Right to Privacy Act (FERPA) - Student Information
The Gramm-Leach-Bliley Act (GLBA) - Financial Information

Many of these regulations carry significant penalties for failure to ensure the security of electronic information.

In addition, other security requirements may apply. For example, as credit, debit and other forms of electronic payment replace cash and checks, data systems containing payment information may need to comply with the Payment Card Industry Data Security Standard (PCI-DSS).

Managing the Risks

Given limitations on time, manpower and dollars, how does the I.T. department ensure the security of all the information entrusted to it? The answer is through a risk management process. A sound risk management process identifies priorities so that time, effort and funds can be allocate where they will do the most good.

The risk management process begins by asking the following questions:

What do I need to protect?
From what do I need to protect it?
How do I protect it?

What Do I Need To Protect?

Information is one of the most important assets of any organization.

What data does LSUHSC-NO hold?
How much of it is sensitive information requiring extraordinary protection?
Where is this data located physically?
What systems (applications, hardware, network infrastructure, etc.) support access to and use of the information?
What steps can be taken to mitigate those threats?

LSUHSC-NO's Document Retention Schedule contains a list of all the record types, both electronic and manual) that are held by the university. While this schedule may not contain all the detail needed, it can serve as an excellent starting point for an inventory of information to be protected.

Security Attributes of Data

Once data has been identified, its security attributes must be determined.There are three conflicting types. In order of importance, these attributes are:

Integrity, i.e. the information is accurate and complete. If the information is neither accurate nor complete, it does not matter whether it is available and presents no risk if confidentiality is compromised. (What are the consequences if the integrity of the data is compromised?)
Availability, i.e. being accessible and usable, on demand, by those individuals who have a demonstrated need for the information. If information cannot be made available to those who need it, when they need it, it is useless. (What are the consequences if the availability of the data is compromised?)
Confidentiality is the inverse of Availability i.e. being inaccessible to those individuals without a demonstrated need for the information. (What are the consequences if the confidentiality of the data is compromised?)

Striking a Balance

The security attributes of data are considered conflicting because any one cannot be improved without impinging on the other two. For example, confidentiality of the data can be improved by blocking all access to it. However, in that case, the data is not available to the individuals who need it and if the data is not reviewed, corrected and kept up to date, integrity of the data will suffer.

The relative importance of the integrity, availability and confidentiality attributes will vary with the type of information. For example, information regarding a University contract is a matter of public record. As a result, integrity and availability are ranked high while confidentiality is ranked low. On the other hand, information covered by attorney-client privilege would be ranked high in confidentiality and integrity but low in availability.

From What Do I Need To Protect It?

What are the threats to the security of that information?

Threats are anything that have the potential to adversely impact the security attributes of the information (e.g., the integrity, availability or confidentiality). Examples of threats (called threat sources) include but are not limited to:

Bad actors (hackers, thieves, vandals, etc.)
Natural disasters (fires, floods, hurricanes, tornadoes, etc.)
Hardware failures
Software errors
Error and omissions of employees and/or students
Infrastructure failures (loss of power, water, data connectivity, etc.)

A threat event is a particular instance of a threat. For example, hurricanes are a threat source while Hurricane Katrina hitting New Orleans and causing the levees to collapse is a threat event. While threat sources are ranked in terms of potential adverse impact on integrity, availability and confidentiality, threat events are ranked by likelihood of occurrence.

A vulnerability is a pre-existing condition that can exacerbate the adverse effects of a threat source or increase the likelihood of a threat event. For example, an unpatched programming flaw in an operating system may allow a hacker to achieve access to more targets allowing him to alter data, disrupt operations or expose information. The fact that a data center is located in a city that is below sea level, makes the possibility of flooding more likely. The adverse impacts of the threat sources, the likelihood of threat events and the effect of vulnerabilities are combined to determine the overall risk level.

Identification of threats and vulnerabilities is an ongoing process. Information about them can come from numerous sources including:

News reports of new threat sources or vulnerabilities
Change in information technology infrastructure, policies or procedures
Audits by external entities (e.g., penetration tests)
Threat events
Disaster recovery plan tests
Issues identified through various monitoring processes

As new threats or vulnerabilities are discovered, they must be assessed to determine the risk they represent. More information on conducting risk assessments can be found in NIST Special Publication SP800-30 Rev. 1 Guide for Conducting Risk Assessments.

How Do I Protect It?

The first step of in addressing the risks is to identify what, if any, safeguards can be taken to address the risk. There may be certain risks that cannot be addressed. For example, as a public institution, certain information about key personnel must remain a matter of public record in order to comply with state law. This information is a bonus for any would-be social engineer. In such cases, the University may choose to simply accept the risk as it is or it may transfer the risk via an insurance policy. Safeguards fall into one of three categories:

Administrative – Administrative actions, policies and procedures, to manage the selection, development, implementation, and maintenance of security measures to protect information and to manage the conduct of the university faculty, staff and students in relation to the protection of that information.
Physical - Physical measures to protect electronic information systems and related buildings and equipment, from natural and environmental hazards, and unauthorized intrusion.
Technical - Technological measures that protect electronic information and control access to it.

Administrative Safeguards

Administrative safeguards are steps taken to direct the actions and the behaviors of members of the University's workforce (faculty, staff and students) to help insure the security of the University's information and data systems. Administrative safeguards include, but are not limited to:

Policies

Acceptable Use
Password

Procedures

System configuration
Data backup and restore
Disaster Recovery Plan
Incident Response Plan
Access Provisioning/De-provisioning

Training

Social Engineering
Cloud Computing
Malware
Creating strong passwords
Physical security and encryption of endpoints

Physical Safeguards

Physical Safeguards are comprised of physical barriers, restraints and other processes to prevent damage or unauthorized physical access to data systems. These include but are not limited to:

Physical Inventory of Systems
Locks
Environmental Controls
Video Surveillance
Security Patrols
Key Control
Disposition of unused or obsolete equipment

Technical Safeguards

Technical safeguards are steps implemented via technology to protect information assets. Technical safeguards include but are not limited to:

Firewalls
Intrusion Detection Systems
Password requirements
Access limits
Patch management
Application Security Features
Logging of System Activity
Encryption
Idle Timeouts
Screen Lock Codes
System Configurations(Disabling used services, etc.)

More information on safeguards can be found in NIST Special Publication SP800-53 Rev. 4 Security and Privacy Controls for Federal Information Systems and Organizations.

Reducing Risk

Once safeguards have been identified, the next consideration is, which of the identified safeguards should be implemented. Reasons for not implementing a specified safeguard include that the cost of implementing and/or managing the safeguard would exceed any anticipated benefit or that that the safeguard would create other risks that exceed the risk being mitigated.

Once the appropriate combinations of safeguards have been selected to address the risk, an action plan is developed and the safeguards are implemented.

Once the action plan is completed and the safeguards are implemented, any remaining risk called residual risk must also be addressed. Residual risk consists of two components:

Any risk remaining after the safeguards have been implemented.
Any risk introduced by the safeguards themselves.

Residual risk is assessed in the same way the original risk. The risk can be:

Accepted as it is (e.g., if the risk is judged to be low or very low)
Transferred (e.g., via insurance coverage)
Addressed with additional safeguards

This process continues until all the risks have been reduced to a level that is acceptable to management.More information on information security risk management can be found in NIST Special Publication SP800-39 Managing Information Security Risk: Organization, Mission, and Information System View.

Incident Response

Preventive activities based on the results of risk assessments can lower the number of incidents, but not all incidents can be prevented. For that reason, computer security incident response has become an important administrative safeguard of information technology (I.T.) risk management processes. An incident response capability is necessary for rapidly detecting incidents, minimizing loss and destruction, mitigating the weaknesses that were exploited, and restoring I.T. services. Because performing incident response effectively is a complex undertaking, establishing a successful incident response capability requires substantial planning and resources. Continually monitoring for attacks is essential. Establishing clear procedures for prioritizing the handling of incidents is critical, as is implementing effective methods of collecting, analyzing, and reporting data. It is also vital to build relationships and establish suitable means of communication with other internal groups (e.g., human resources, legal) and with external groups (e.g., other incident response teams, law enforcement).

Understanding threats and identifying modern attacks in their early stages is key to preventing subsequent compromises, and proactively sharing information among organizations regarding the signs of these attacks is an increasingly effective way to identify them. Implementing the following requirements and recommendations should facilitate efficient and effective incident response.

Secure networks, systems, and applications.

The first line of defense against security incidents is preventing them from occurring in the first place. Preventing problems is often less costly and more effective than reacting to them after they occur. If security controls are insufficient, high volumes of incidents may occur. This could overwhelm the resources and capacity for response, which would result in delayed or incomplete recovery and possibly more extensive damage and longer periods of service and data unavailability. Thus, incident prevention is an important complement to an incident response capability. This is accomplished as a part of the risk management process described above.

Create, provision, and operate a formal incident response capability.

Establishing an incident response capability should include the following actions:

Creating an incident response policy and plan.
Developing procedures for performing incident handling and reporting.
Setting guidelines for communicating with outside parties regarding incidents.
Selecting a team structure and staffing model.
Establishing relationships and lines of communication between the incident response team and other groups, both internal (e.g., legal department) and external (e.g., law enforcement agencies).
Determining what services the incident response team should provide.
Staffing and training the incident response team.

Document guidelines for interactions with other organizations regarding incidents.

During incident handling, LSUHSC-NO will need to communicate with outside parties, such as other incident response teams, law enforcement, the media, vendors, and victim organizations. Because these communications often need to occur quickly, LSUHSC-NO should predetermine communication guidelines so that only the appropriate information is shared with the right parties. LSUHSC-NO should be generally prepared to handle any incident but should focus on being prepared to handle incidents that use common attack vectors. Incidents can occur in countless ways, so it is infeasible to develop step-by-step instructions for handling every incident. Different types of incidents merit different response strategies. Attack vectors include but are not limited to:

Email: An attack executed via an email message or attachment.
Web: An attack executed from a website or web-based application.
External/Removable Media: An attack executed from removable media (e.g., flash drive, CD) or a peripheral device.
Improper Usage: Any incident resulting from violation of LSUHSC-NO’s acceptable usage policies by an authorized user.
Loss or Theft of Equipment: The loss or theft of a computing device or media used by LSUHSC-NO, such as a laptop or smartphone.
Attrition: An attack that employs brute force methods to compromise, degrade, or destroy systems, networks, or services.

Emphasize the importance of incident detection and analysis.

In any organization, millions of possible signs of incidents may occur each day, recorded mainly by logging and computer security software. Automation is needed to perform an initial analysis of the data and select events of interest for human review. Event correlation software can be of great value in automating the analysis process. However, the effectiveness of the process depends on the quality of the data that goes into it. Establish logging standards and procedures to ensure that adequate information is collected by logs and security software and that the data is reviewed regularly. Create written guidelines for prioritizing incidents. Prioritizing the handling of individual incidents is a critical decision point in the incident response process. Effective information sharing can help you identify situations that are of greater severity and demand immediate attention. Incidents should be prioritized based on the relevant factors, such as the functional impact of the incident (e.g., current and likely future negative impact to business functions), the information impact of the incident (e.g., effect on the confidentiality, integrity, and availability of LSUHSC-NO’s information), and the recoverability from the incident (e.g., the time and types of resources that must be spent on recovering from the incident).

Use the "lessons learned" process to gain value from incidents.

After a major incident has been handled, hold a "lessons learned" meeting to review the effectiveness of the incident handling process and identify necessary improvements to existing security controls and practices. Lessons learned meetings can also be held periodically for lesser incidents as time and resources permit. The information accumulated from all lessons learned meetings should be used to identify and correct systemic weaknesses and deficiencies in policies and procedures. Follow-up reports generated for each resolved incident can be important not only for evidentiary purposes but also for reference in handling future incidents and in training new team members.

More information about incident response can be found in NIST Special Publication SP800-61 Rev. 2 Computer Security Incident Handling Guide.

Contingency Planning

Contingency planning refers to interim measures to recover information system services after a disruption and is another important administrative safeguard. Interim measures may include:

Relocation of information systems and operations to an alternate site
Recovery of information system functions using alternate equipment
Performance of information system functions using manual methods.

The following seven-step contingency planning process may be used to develop and maintain a viable contingency planning program for information systems. These seven progressive steps are designed to be integrated into each stage of the system development life cycle.

Develop the contingency planning policy statement.
Conduct a business impact analysis (BIA).
Identify preventive controls.
Create contingency strategies.
Develop an information system contingency plan.
Ensure plan testing, training, and exercises.
Ensure plan maintenance.

Develop the contingency planning policy statement.

To be effective and to ensure that personnel fully understand LSUHSC-NO’s contingency planning requirements, the contingency plan must be based on a clearly defined policy. The contingency planning policy statement should define LSUHSC-NO’s overall contingency objectives and establish the organizational framework and responsibilities for system contingency planning. Key policy elements are as follows:

Roles and responsibilities.
Scope as applies to common platform types and organization functions (i.e., telecommunications, legal, media relations) subject to contingency planning.
Resource requirements.
Training requirements.
Exercise and testing schedules.
Plan maintenance schedule.
Minimum frequency of backups and storage of backup media.

As information system contingency plans are developed, they should be coordinated with related campus-wide policies and programs, including information system security, physical security, human resources, system operations, and emergency preparedness functions. Information system contingency activities should be compatible with program requirements for these areas, and recovery personnel should coordinate with representatives from each area to remain aware of new or evolving policies, programs, or capabilities.

Conduct a business impact analysis (BIA).

The BIA characterizes the system components, supported mission/business processes, and interdependencies. The BIA purpose is to correlate the system with the critical mission/business processes and services provided, and based on that information, characterize the consequences of a disruption. The BIA results can be used to determine contingency planning requirements and priorities. Three steps are typically involved in accomplishing the BIA:

Determine mission/business processes and recovery criticality. Mission/Business processes supported by the system are identified and the impact of a system disruption to those processes is determined along with outage impacts and estimated downtime. The downtime should reflect the maximum time that LSUHSC-NO can tolerate while still maintaining the mission.
Identify resource requirements. Realistic recovery efforts require a thorough evaluation of the resources required to resume mission/business processes and related interdependencies as quickly as possible. Examples of resources that should be identified include facilities, personnel, equipment, software, data files, system components, and vital records.
Identify recovery priorities for system resources. Based upon the results from the previous activities, system resources can be linked more clearly to critical mission/business processes and functions. Priority levels can be established for sequencing recovery activities and resources.

Identify preventive controls.

In some cases, the outage impacts identified in the BIA may be mitigated or eliminated through preventive measures that deter, detect, and/or reduce impacts to the system. Where feasible and cost-effective, preventive methods are preferable to actions that may be necessary to recover the system after a disruption. Some common preventive measures are listed below:

Appropriately sized uninterruptible power supplies (UPS) to provide short-term backup power to all system components (including environmental and safety controls).
Gasoline or diesel-powered generators to provide long-term backup power.
Air-conditioning systems with adequate excess capacity to prevent failure of certain components, such as a compressor.
Fire suppression systems.
Fire and smoke detectors.
Water sensors in the computer room ceiling and floor.
Heat-resistant and waterproof containers for backup media and vital non electronic records.
Emergency master system shutdown switch.
Offsite storage of backup media, non electronic records, and system documentation.
Technical security controls, such as cryptographic key management.
Frequent scheduled backups including where the backups are stored (onsite or offsite) and how often they are recirculated and moved to storage.

Create contingency strategies.

Contingency strategies are created to mitigate the risks for the contingency planning family of controls and cover the full range of backup, recovery, contingency planning, testing, and ongoing maintenance. Backup and recovery methods and strategies are a means to restore system operations quickly and effectively following a service disruption. The methods and strategies should address disruption impacts and allowable downtimes identified in the BIA. A wide variety of recovery approaches may be considered, with the appropriate choice being highly dependent upon the incident, type of system, impact level, and the system’s operational requirements. Specific recovery methods should be considered and may include commercial contracts with alternate site vendors, reciprocal agreements with internal or external organizations, and service-level agreements (SLAs) with equipment vendors. In addition, technologies such as redundant arrays of independent disks (RAID), automatic failover, UPS, server clustering, and mirrored systems should be considered when developing a system recovery strategy. Several alternative approaches should be considered when developing and comparing strategies, including cost, maximum downtimes, security, recovery priorities, and integration with larger, organization-level contingency plans.

Develop an information system contingency plan.

Contingency plan development is a critical step in the process of implementing a comprehensive contingency planning program. The plan contains detailed roles, responsibilities, teams, and procedures associated with restoring an information system following a disruption. The contingency plan should document technical capabilities designed to support contingency operations and should be tailored to LSUHSC-NO and its requirements. Plans need to balance detail with flexibility; usually, the more detailed the plan, the less scalable and versatile the approach.

Generally there are three phases that govern actions to be taken following a system disruption:

The Activation/Notification Phase describes the process of activating the plan based on outage impacts and notifying recovery personnel.
The Recovery Phase details a suggested course of action for recovery teams to restore system operations at an alternate site or using contingency capabilities.
The Reconstitution Phase includes activities to test and validate system capability and functionality and outlines actions that can be taken to return the system to normal operating condition and prepare the system against future outages.

Plans should be formatted to provide quick and clear directions in the event that personnel unfamiliar with the plan or the systems are called on to perform recovery operations. Plans should be clear, concise, and easy to implement in an emergency. Where possible, checklists and step-by-step procedures should be used.

Ensure plan testing, training, and exercises (TT&E).

A contingency plan should be maintained in a state of readiness, which includes having personnel trained to fulfill their roles and responsibilities within the plan, having plans exercised to validate their content, and having systems and system components tested to ensure their operability in the environment specified in the plan. In addition, the effectiveness of the information system controls should be assessed. LSUHSC-NO should conduct TT&E events periodically, following organizational or system changes, or the issuance of new TT&E guidance, or as otherwise needed. Execution of TT&E events assists LSUHSC-NO in determining the plan’s effectiveness, and that all personnel know what their roles are in the conduct of each information system plan. For each TT&E activity conducted, results are documented in an after-action report, and Lessons Learned corrective actions are captured for updating information in the plan.

Ensure plan maintenance.

To be effective, the plan must be maintained in a ready state that accurately reflects system requirements, procedures, organizational structure, and policies. Information systems undergo frequent changes because of shifting business needs, technology upgrades, or new internal or external policies. Therefore, it is essential that the contingency plan be reviewed and updated regularly as part of LSUHSC-NO’s change management process to ensure that new information is documented and contingency measures are revised if required. A continuous monitoring process can provide LSUHSC-NO with an effective tool for plan maintenance, producing ongoing updates to security plans, security assessment reports, and plans of action and milestone documents. As a general rule, the plan should be reviewed for accuracy and completeness at an organization-defined frequency or whenever significant changes occur to any element of the plan. Certain elements, such as contact lists, will require more frequent reviews. The plans for moderate- or high-impact systems should be reviewed more often. At a minimum, plan reviews should focus on the following elements:

Operational requirements.
Security requirements.
Technical procedures.
Hardware, software, and other equipment (types, specifications, and amount).
Names and contact information of team members.
Names and contact information of vendors, including alternate and offsite vendor POCs.
Alternate and offsite facility requirements.
Vital records (electronic and hardcopy).

Because the contingency plan contains potentially sensitive operational and personnel information, its distribution should be marked accordingly and controlled. Typically, copies of the plan are provided to recovery personnel for storage. A copy should also be stored at the alternate site and with the backup media. Storing a copy of the plan at the alternate site ensures its availability and good condition in the event local plan copies cannot be accessed because of disaster. A record of copies of the plan and to whom they were distributed should be maintained. Other information that should be stored with the plan includes contracts with vendors (SLAs and other contracts), software licenses, system user manuals, security manuals, and operating procedures. Changes made to the plan, strategies, and policies should be communicated to and coordinated with the representatives of associated plans or programs, as necessary. Plan modifications should be tracked using a record of changes, which lists the page number, change comment, and date of change.

Coordination with associated internal and external organizations should occur frequently to ensure that impacts caused by changes within any organization will be reflected in the contingency plan. Supporting information should also be evaluated to ensure that the information is current and continues to meet system requirements adequately. This information includes the following:

Alternate site contract, including testing times
Offsite storage contract
Software licenses
MOUs or vendor SLAs
Hardware and software requirements
System interconnection agreements
Security requirements
Recovery strategy
Contingency policies
Training and awareness materials
Testing scope
Other plans (e.g., COOP, BCP)

Although some changes may be quite visible, others will require additional analysis. When a significant change occurs, the BIA should be updated with the new information to identify new contingency requirements or priorities. As new technologies become available, preventive controls may be enhanced and recovery strategies may be modified. Finally, plan maintenance should be continued as the information system passes through the Disposal phase of its life cycle to ensure that the plan accurately reflects recovery priorities and concurrent processing changes.

More information about contingency planning can be found in NIST Special Publication SP800-34 Rev. 1 Contingency Planning Guide for Federal Information Systems.

Custodial Role of the I.T. Department

As a member of I.T., you are responsible for protecting the Users’ data BY:

NOT Accessing User data unless it is required to accomplish your duties.
NOT Accessing User data without the appropriate approval from management or the User.
NOT Providing the Users’ data to others without the users’ knowledge and consent.

Evaluating the Issue

Many times users feel that just because computers or the World Wide Web are involved in an issue, that it is an I.T. problem. As a member of the I.T. staff, you need to be able to recognize when a problem or an issue can be addressed by the I.T. department and when an issue needs to be referred to another department or to upper management for action.

A good test is to ask yourself if the problem would still exist if computers or the web were not involved.

Don't be reluctant to contact your supervisor if you have concerns about whether an issue is truly an I.T. problem or whether it is better addressed by another area.

Scenario #1

A department head comes to you because a member of her staff erroneously emailed a patient's social security number to another employee who had no reason to view it. Is this an issue for I.T. to resolve or should it be referred to management or the Office of Compliance Programs?

Hover your mouse over or tap your finger on the box below to see the right answer. (Tap on any picture to make the answer disappear.)

Yes

Getting Help

If you have any questions, please contact the Office of Compliance Programs by:

Email: nocompliance@lsuhsc.edu
Phone: 504-568-5135
In Person: RCB, suite 807
Website