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.
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.
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.
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:
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).
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:
Information is one of the most important assets of any organization.
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.
Once data has been identified, its security attributes must be determined.There are three conflicting types. In order of importance, these attributes are:
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.
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:
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:
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.
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 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:
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:
Technical safeguards are steps implemented via technology to protect information assets. Technical safeguards include but are not limited to:
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.
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:
Residual risk is assessed in the same way the original risk. The risk can be:
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.
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.
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.
Establishing an incident response capability should include the following actions:
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:
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).
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 refers to interim measures to recover information system services after a disruption and is another important administrative safeguard. Interim measures may include:
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.
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:
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.
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:
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:
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.
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:
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.
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.
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:
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:
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.
As a member of I.T., you are responsible for protecting the Users’
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.
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.)
If you have any questions, please contact the Office of Compliance Programs by: