15.5 FRAMEWORK FOR SECURITY FEEDBACK

Your risk reduction efforts will include selection of controls that can range from policies and secure operating procedures to technical controls such as anti-virus capability or intrusion protection systems. Whatever the suite of controls happens to be, information security managers need to be able to get feedback from these controls in order to measure whether or not they are operating effectively and providing the degree of security they were designed to provide. Also, feedback from these controls can disclose inappropriate activity, intrusions and other policy violations. Every organization should have a framework in place for ensuring that feedback is obtained on a regular and timely basis such that adjustments can be made if systems are not performing as anticipated and actions can be taken if malicious or inappropriate activity is detected . Each of these activities is required under the HIPAA security rules in the following sections:

164.308 (a)(1)(D): Information system activity review
164.308 (a)(6): Security incident procedures
164.308 (a)(8): Evaluation
164.312 (b): Audit controls

15.5.1 Information System Activity Review

Your organization may already have controls in place or new controls may be instituted to remediate weaknesses uncovered in the risk analysis. Whatever the case may be, these controls are of little use unless someone is monitoring then and sifting through the feedback they provide. For example, your firewall rule set should be reviewed to determine what activity it is logging. Such as review may prompt you to adjust the firewall's properties to fine tune the information being logged at the firewall. Once you are satisfied with what your firewall is capturing in terms of logging data, someone should be assigned the responsibility of reviewing that data on a regular basis. The firewall is a good place to detect suspicious activity. Also, a rise in the amount of certain types of traffic may be an indication of a problem that should be looked at more closely.

Intrusion detection systems may be a useful source of information as well. Typically, such systems will alert administrators if suspicious traffic is detected, but regular reviews of activity may reveal patterns that may not necessarily set off an alarm but could be an indication of malicious activity nonetheless. Intrusion detection systems can be of the host based variety or network based. In either case, logs should be reviewed on a regular, recurring basis. One other thing to be mindful of as you review and assess log data is to get an understanding of patterns of activity over a period of time. In other words, learn to recognize what is normal and what conditions spark various patterns of activity. For example, in many organizations the end of the fiscal quarter will typically generate a flurry of activity around accounting and financial systems. Understanding these normal patterns may help security practitioners identify activity that may be unusual or abnormal. Such activity may be perfectly legitimate , but it may also be worth following up on. Another good practice to engage in with respect to intrusion detection systems is to correlate suspicious activity or alarms with vulnerability assessment information. For example, if you receive an alarm of an attack against a device or series of devices on a network segment, correlating that event with vulnerability assessment data may help determine if any of those devices were actually vulnerable to that type of attack. Obviously, an attack against a system that is vulnerable will receive a higher degree of priority over an attack against a system that is not vulnerable. In the latter case, even though the system came under attack, it was likely not successful.

Other controls should be monitored on a frequent and regular basis as well. Especially access controls. Since the primary focus of the HIPAA rules is protection of healthcare or patient information, monitoring access controls will quickly reveal if policy has been violated. With respect to access controls, consider capturing the following information:

User account accessing the information, network resource or application
Time and date of login
If accessing a remote system, the location from which the access attempt took place
Login success/failure
Objects, resources or applications accessed in the login session

15.5.2 Security Incident Procedures

Incident handling is an important part of managing risk in an organization. Often times, an organization will invest in security infrastructure only to find that it doesn't really know what to do when these devices indicate a possible intrusion or malicious activity. Having a good set of incident handling procedures can mean the difference between being able to gather good, solid electronic evidence that won't be thrown out if the case were to go to court , or having to let a perpetrator that caused a substantial amount of damage to your organization go because the evidence was inadmissible. Most incidents will not rise to such a level, but it is good to be prepared just in case. In most cases, having good incident handling procedures will enable the organization to react to situations in a more timely manner and quickly bring the right personnel and resources to bear so that damage may be minimized to the extent possible and interruptions to operations are not impacted as greatly.

First off, there should be a formal process for logging an incident once it is detected. Many organizations choose to leverage their existing infrastructure for this if they are running helpdesk or call center functions. Once the incident is logged, it should receive a tracking or case number so that any activity associated with remediation or resolution of the incident can be recorded. When an incident is opened, an escalation process should be invoked in which the persons receiving the call are trained on who to contact and what resources may be required depending upon the nature of the incident. If the incident is of sufficient severity or magnitude, a law enforcement agency may have to get involved. Under such circumstances, the incident handling policy should define the circumstances under which such a decision is made and who is authorized to make the call.

Every incident should be tracked though to its conclusion, at which time, the case is formally closed. Closing a case, however, does not signal the end of activity related to the case. When a case is closed, it is good practice to hold what is sometimes referred to as a 'post mortem' session in which all the parties involved in resolution of the incident meet to discuss how it was handled. Such a meeting has the potential to turn into a finger pointing session, so it is extremely important that a strong leader facilitate the session and that the scope of the meeting is clearly defined and adhered to. The focus of the meeting should be to determine how effectively the incident was handled. Some of the items to consider would be as follows :

Were the right resources called in?
Were these resources called in a timely manner?
Are there any other resources that could have helped handle the situation more effectively?
Were the right persons contacted?
Were these persons contacted and involved in remediation efforts in a timely manner?
Did law enforcement agencies have to get involved?
Was the cause properly identified?
Was the root cause identified?
Was the root cause of the problem resolved?
What was the extent of the damage?
Is there a potential for a similar problem to happen again?
Was the fix effective?
Do policies, practices or procedures have to be revised?

This is a sampling of the issues such a meeting might cover. Each organization should settle on its own set of issues to cover. In any case, the agenda should be defined prior to the meeting and the meeting should not be allowed to stray beyond its scope. At the conclusion of the meeting, it is good practice to keep a log of the lessons learned as a result of the incident so that future incidents can be handled more effectively.

The information security management team should get regular reports on incidents so that it knows what incidents are open and which ones have been closed. Management should also be kept abreast of the performance of its security controls. Management may wish to work with Information Systems Security Officers and the Security Practitioners to come up with an effective set of metrics in order to measure the effectiveness of security controls.