Shira Roberts, Rita Sherrod, Lester Tucker
University of Maryland University College
CSEC 661 9040 (2185)
Digital Forensics Investigations
Table of Contents Abstract 3 Introduction 4 Cloud Computing Challenges 4 Response Readiness Plan 5 Coordination Plan 7 Structures and Competencies Required 7 Key Members 8 Cost & Effort – Will add info 10 Metrics – not sure if we SHOULD do it this way but I don’t see why not 11 Conclusion 16 References 18
This paper attempts to educate the reader on the importance of creating, maintaining and properly utilizing a response readiness plan, coordination plan as well as the metrics involved in the creation of the plans. The future is unpredictable however it doesn’t take a psychic to make a Large Environment aware that they will be under some form of cyber-attack at some point in time. know that your company will most likely be under attack.
A response readiness plan should effectively tell the organization what, when and how to protect the organization in a time of danger (or loss of data). A good coordination plan will integrate forensics into the response plan from the aspect of internet technology and spell out the details of what the team members functions will be, in regard to who, what, when, where and how. The metrics will properly establish a way to effectively measure the proficiency level of the people, processes and all technologies involved in the steps to achieve all performance level goals and objectives in order to return to operational status. . the technology. steps….
All Large Enterprise Environments should be prepared and ready with planned actions and directions, and a bonafide toolkit and most importantly “… a pre-determined incident response plan to follow…”, Branson et al (2005, p. 106). The last quarter century of the computer business world has seen a multitude of attacks that have currently resulted in “…an average of six significant security breaches each. In 68% of these incidents, the data exfiltrated from the network was serious enough to require public disclosure or have a negative financial impact on the company”, according to Mcafee, (2015). Mcafee reached out to over 1,100 organizations around the world and conducted over 500 interviews for a better understanding via research along with standing on its foundational data to find out more about “…attack methods, improving attack detection and incident response, and critical infrastructure security…”, per Mcafee, (2015).
There was a long range and wide number of findings, however the most striking thing that stood out the most was that “poor security practices [was] the biggest challenge in the face of increasingly sophisticated attacks.”. per Mcafee, (2015). There is no guarantee that your company will successfully come out of an incident unscathed, however having a response plan is better than no response plan. Aside from a plan, when you dig below the surface you must also have the proper tools and equipment to respond and trained personnel that know their job and when and what to do. An organization personnel should also have the knowledge to fully operate that equipment, along with proper certification that will backup up the their training and of course a plan and strategy.
There are many challenges that are common to Cloud Forensics however some of the most important are as follows. Data Identification is the ability to maintain accessibility to your resources along with the required permissions in case of a disaster or time of need, Cloud service permission is something that should be clarified prior to incidents and all abiding legalities spelled out. This can become a quite a challenge when data is located in a number of geographical locations which could easily increase the level of difficulty during an investigation. The area of Time Mismatch is also a problem, “Digital evidences collected had to be proven in courts against the intruder and this is a difficult and challenging task when two different logs for the same activity are placed at different locations with different time record.”, as well as different countries, according to Abdullah et al et al, (2014). Multi-tenancy is also a concern, when a single resource is used to access the cloud by many users, an intruder can also easily pose as someone else. Determining who is the actual owner of the data becomes a problem especially when it involves the service level agreements (SLA). It is almost impossible to “capture network traffic at its time flow in the Cloud due to the inaccessibility of a network. The entire network in the cloud belongs to the cloud service provider and digital investigators have no access to the network.”, per Abdullah et al et al, (2014). Privacy is actually considered one of the biggest challenges when it comes to the Cloud, largely due to the fact that data stored on one cloud could be moved to another so the ultimate responsibility for release of that information goes back to the cloud service provider. Lastly, a single user can also utilize more than one cloud service provider at one time. (Abdullah et al et al, 2014).
Now that we are aware of some of the challenges, that focus on what to do in preparation of the challenges. long with a broad scope of guidelines manuals and directives, a formal policy is necessary in order to provide clarity and guidance for an effective contingency plan, (Balaouras et al, 2009, p. 9). Though it is not mandatory it is highly recommended to use the NIST 800-86 as a guide, “Its focus is primarily on using forensic techniques to assist with computer security incident response,…” Chevalier, et al, (2006). Per NIST 800-86, implementation of the following should maintain efficiency, effectiveness and a great contingency plan:
· Organizations should ensure that their policies contain clear statements addressing all major forensic considerations, such as contacting law enforcement, performing monitoring, and conducting regular reviews of forensic policies and procedures.
· Organizations should create and maintain procedures and guidelines for performing forensic tasks, based on the organizations policies and all applicable laws and regulations.
· Organizations should ensure that their policies and procedures support the reasonable and appropriate use of forensic tools.
· Organizations should include various teams from and throughout the organization, such as legal advisors and physical security staff, in some forensic activities.
· Organizations should protect sensitive information and maintain certain records for audit purposes and may be required to notify other agencies or other impacted individuals.
· Organizations should ensure all incident handlers have expertise in information security and specific technical subjects, such as the most commonly used OSs, filesystems, applications, and network protocols within the organization.
· Organizations should ensure all more than one team member on and incident handling team, should be able to perform tasks of other members.
· All forensic team members should possess and have the ability to reach out to other team members within and those approved outsed to assist.
· In order to facilitate inter-team communications, each team should designate one or more points of contact and a a list of contact of expertise.
Moving forward, policies should clearly define the roles and responsibilities all a high-level members, who should be aware of the policies and able to address them as needed. Along with the assurance that training is maintained. It is strongly believed that the incorporation of forensic considerations into the information system life cycle can lead to more efficient and effective handling of many incidents. (Chevalier et al, (2006)
Addressing the Attack
The ability to respond to the incident will depend on the readiness of the team and their ability access and analyze the situation. After an attack, two main things should be addressed, what areas were affected and what can be done to stop further spreading, all simultaneously done in a timely manner, followed by determining when (actual time) the attack occurred, in order to prevent further damage, the NIST 800-61 proposing some valid information. However keep in mind, every precursor/indicator of an incident is not always completely accurate. In regards to a Large Enterprise environment, “Finding the real security incidents that occurred out of all the indicators can be a daunting task.”, per Cichonski, et al, (2012). An intrusion detection systems can produce false positives and in some cases even an accurate indicator doesn’t mean that an incident occurred, there can always be human error, a server crash or modification of files.
Once the team has recognized that an actual incident has occurred, an initial analysis should be done to “determine the incident’s scope, such as which networks, systems, or applications are affected; who or what originated the incident; and how the incident is occurring (e.g., what tools or attack methods are being used, what vulnerabilities are being exploited).”, per Cichonski, et al, (2012). Once enough information is gained, the data should be prioritized, for instance profiling which would “running file integrity checking software on hosts to derive checksums for critical files and monitoring network bandwidth usage to determine what the average and peak usage levels..” were. per Cichonski, et al, (2012). Network behaviors should be looked over to compare routine’s to gaps, for instance reviewing the log’s. If the log retention policy specified the amount of time data was to be maintained this could be extremely helpful when analyzing an attack. Some other steps are to keep all hosts clocks synchronized, maintain a simple knowledge base, don’t allow over complication of small techniques. Search Engine analyzation can be helpful as well as filtering data, “There is simply not enough time to review and analyze all the indicators; at minimum the most suspicious activity should be investigated.” per Cichonski, et al, (2012). One effective strategy is to filter out categories of indicators that tend to be insignificant.
· Run Packet Sniffers to Collect Additional Data. Sometimes the indicators do not record enough detail to permit the handler to understand what is occurring. If an incident is occurring over a network, the fastest way to collect the necessary data may be to have a packet sniffer capture network traffic. Configuring the sniffer to record traffic that matches specified criteria
“An incident response team that suspects that an incident has occurred should immediately start recording all facts regarding the incident.36 A logbook is an effective and simple medium for this,37 but laptops, audio recorders, and digital cameras can also serve this purpose.38 Documenting system events, conversations, and observed changes in files can lead to a more efficient, more systematic, and less error- prone handling of the problem.” per Cichonski, et al, (2012).
Recoverability from the Incident. The size of the incident and the type of resources it affects will determine the amount of time and resources that must be spent on recovering from that incident. In some instances it is not possible to recover from an incident (e.g., if the confidentiality of sensitive information has been compromised) and it would not make sense to spend limited resources on an elongated incident handling cycle, unless that effort was directed at ensuring that a similar incident did not occur in the future. In other cases, an incident may require far more resources to handle than what an organization has available. Incident handlers should consider the effort necessary to actually recover from an incident and carefully weigh that against the value the recovery effort will create and any requirements related to incident handling.
Table 3-2. Functional Impact Categories
Table 3-3 provides examples of possible information impact categories that describe the extent of information compromise that occurred during the incident. In this table, with the exception of the ‘None’ value, the categories are not mutually exclusive and the organization could choose more than one.
|None||No effect to the organization’s ability to provide all services to all users|
|Low||Minimal effect; the organization can still provide all critical services to all users but has lost efficiency|
|Medium||Organization has lost the ability to provide a critical service to a subset of system users|
|High||Organization is no longer able to provide some critical services to any users|
Table 3-4. Recoverability Effort Categories
Organizations should also establish an escalation process for those instances when the team does not respond to an incident within the designated time. This can happen for many reasons: for example, cell phones may fail or people may have personal emergencies. The escalation process should state how long a person should wait for a response and what to do if no response occurs. Generally, the first step is to duplicate the initial contact. After waiting for a brief time—perhaps 15 minutes—the caller should escalate the incident to a higher level, such as the incident response team manager. If that person does not respond within a certain time, then the incident should be escalated again to a higher level of man
3.3 Containment, Eradication, and Recovery
agement. This process should be repeated until someone responds.
3.3.1 Choosing a Containment Strategy
Containment is important before an incident overwhelms resources or increases damage. Most incidents require containment, so that is an important consideration early in the course of handling each incident. Containment provides time for developing a tailored remediation strategy. An essential part of containment is decision-making (e.g., shut down a system, disconnect it from a network, disable certain functions). Such decisions are much easier to make if there are predetermined strategies and procedures for containing the incident. Organizations should define acceptable risks in dealing with incidents and develop strategies accordingly.
Containment strategies vary based on the type of incident. For example, the strategy for containing an email-borne malware infection is quite different from that of a network-based DDoS attack. Organizations should create separate containment strategies for each major incident type, with criteria documented clearly to facilitate decision-making. Criteria for determining the appropriate strategy include:
· Potential damage to and theft of resources
· Need for evidence preservation
· Service availability (e.g., network connectivity, services provided to external parties)
· Time and resources needed to implement the strategy
· Effectiveness of the strategy (e.g., partial containment, full containment)
· Duration of the solution (e.g., emergency workaround to be removed in four hours, temporary workaround to be removed in two weeks, permanent solution).
In certain cases, some organizations redirect the attacker to a sandbox (a form of containment) so that they can monitor the attacker’s activity, usually to gather additional evidence. The incident response team should discuss this strategy with its legal department to determine if it is feasible. Ways of monitoring an attacker’s activity other than sandboxing should not be used; if an organization knows that a system has been compromised and allows the compromise to continue, it may be liable if the attacker uses the compromised system to attack other systems. The delayed containment strategy is dangerous because an attacker could escalate unauthorized access or compromise other systems.
Another potential issue regarding containment is that some attacks may cause additional damage when they are contained. For example, a compromised host may run a malicious process that pings another host periodically. When the incident handler attempts to contain the incident by disconnecting the compromised host from the network, the subsequent pings will fail. As a result of the failure, the malicious process may overwrite or encrypt all the data on the host’s hard drive. Handlers should not assume that just because a host has been disconnected from the network, further damage to the host has been prevented.
3.3.2 Evidence Gathering and Handling
Although the primary reason for gathering evidence during an incident is to resolve the incident, it may also be needed for legal proceedings.42 In such cases, it is important to clearly document how all evidence, including compromised systems, has been preserved.43 Evidence should be collected according to procedures that meet all applicable laws and regulations that have been developed from previous discussions with legal staff and appropriate law enforcement agencies so that any evidence can be admissible in court.
3.3.4 Eradication and Recovery
After an incident has been contained, eradication may be necessary to eliminate components of the incident, such as deleting malware and disabling breached user accounts, as well as identifying and mitigating all vulnerabilities that were exploited. During eradication, it is important to identify all affected hosts within the organization so that they can be remediated. For some incidents, eradication is either not necessary or is performed during recovery.
In recovery, administrators restore systems to normal operation, confirm that the systems are functioning normally, and (if applicable) remediate vulnerabilities to prevent similar incidents. Recovery may involve such actions as restoring systems from clean backups, rebuilding systems from scratch, replacing compromised files with clean versions, installing patches, changing passwords, and tightening network perimeter security (e.g., firewall rulesets, boundary router access control lists). Higher levels of system logging or network monitoring are often part of the recovery process. Once a resource is successfully attacked, it is often attacked again, or other resources within the organization are attacked in a similar manner.
Eradication and recovery should be done in a phased approach so that remediation steps are prioritized. For large-scale incidents, recovery may take months; the intent of the early phases should be to increase the overall security with relatively quick (days to weeks) high value changes to prevent future incidents. The later phases should focus on longer-term changes (e.g., infrastructure changes) and ongoing work to keep the enterprise as secure as possible
Because eradication and recovery actions are typically OS or application-specific, detailed recommendations and advice regarding them are outside the scope of this document.
3.4 Post-Incident Activity
3.4.1 Lessons Learned
One of the most important parts of incident response is also the most often omitted: learning and improving. Each incident response team should evolve to reflect new threats, improved technology, and lessons learned. Holding a “lessons learned” meeting with all involved parties after a major incident, and optionally periodically after lesser incidents as resources permit, can be extremely helpful in improving security measures and the incident handling process itself. Multiple incidents can be covered in a single lessons learned meeting. This meeting provides a chance to achieve closure with respect to an incident by reviewing what occurred, what was done to intervene, and how well intervention worked. The meeting should be held within several days of the end of the incident. Questions to be answered in the meeting include:
· Exactly what happened, and at what times?
· How well did staff and management perform in dealing with the incident? Were the documented
procedures followed? Were they adequate?
· What information was needed sooner?
· Were any steps or actions taken that might have inhibited the recovery?
· What would the staff and management do differently the next time a similar incident occurs?
· How could information sharing with other organizations have been improved?
· What corrective actions can prevent similar incidents in the future?
· What precursors or indicators should be watched for in the future to detect similar incidents?
· 3.4.3 Evidence Retention
· Review it
· 3.5 Incident Handling Checklist
· The checklist in Table 3-5 provides the major steps to be performed in the handling of an incident
Digital forensics is essentially viewed as an important part of incident response for the objective of post-incident inquiries in security architectures. Consequently, a proper coordination plan should be put in place to effectively integrate forensics into incident responses for large computing environments. During incident responses, there is a need for a highly coordinated team to work with digital forensic information that is collected from networks and systems with security implementations on all operational levels. It is important to preserve forensic artifacts. This can help to understand incidents and events in ways that can make it easier to address information security problems. Large enterprises normally gather gigabytes or even terabytes of data to support security intelligence. The reduced degree of interrogation of digital forensics in security architectural designs is another reason why it is faced with major challenges in today’s operating environment. Having a well-coordinated forensics team helps to intersect security intelligence and big data analytics in order to introduce the third domain for security and forensic integration.
The digital forensics project team will be comprised of a Project Leader, Information Security Auditors, and Forensic Investigators. Other members will include Human Resource Manager and individuals who will represent the organization’s employees. This team will be organized to ensure procedures are in place to support the needs of varying departments that work together. Therefore, part of the team’s mandate will be to respond promptly and efficiently in the event of an incident. The operational information security and forensics team will be tasked with knowing who they can contact in each department for assistance. The team will also have members from physical security and internal audit.
Project Team Leader
The project team leader is the main coordinator and leader who ensures the team delivers quality and effective plans. The person assigned to the team leader role will be responsible for planning, organizing, controlling, and coordinating the tasks that the whole team is responsible for (Bainey, 2004). The team leader will coordinate all the activities that the team implements in collaboration with other IT organizations, business groups as well as external parties. The selection and application of effective project management tools and control mechanisms, and determination of resources and costs for the project also falls within the team leader’s mandate. The team leader will recommend an appropriate staffing schedule for users, IT management, and business strategy groups. Further, the leader will ensure working knowledge of the forensic data management is maintained according to requirements that have been tailored to the needs of specific institutions’ information systems and subsystems and will design concepts and approaches that utilize relevant technologies (Beedubail, Choy, Hsiao, Raghavan & Vaideeswaran, 2016). The team leader will review project-related researches and make recommendations in coordination with external IT and business security experts to improve forensic data systems.
Forensic data analysis requires timely response to ensure business runs smoothly without cyber-attack interferences. As such, the project team leader will be in charge of scheduling all team operations so that system development and operating documentation are completed in a timely manner (Bainey, 2004). The project leader will administer change-development processes through proposing changes initiated through channels such as business management strategies, and technological integration that have been documented in the project resolution logs. The manager will govern risks by analyzing the impact of data management risks with regards to scope, schedules, and quality of the overall operation (Beedubail, Choy, Hsiao, Raghavan & Vaideeswaran, 2016). Risk government will be done in accordance with regular reports that will be submitted to the steering commission. The project team leader will source for funds and authorization from relevant committees.
Digital Forensic Investigator
The digital forensic investigator within the team is responsible for maintaining records and logs that the forensic information system will apply. The digital forensic investigator will archive original data and enhance visuals such as graphic images. The digital forensic investigator will source, sign, and obtain certificates such as X.509 throughout the project life circle (Bainey, 2004). The investigator will compile and calculate statistical logs and extract data from relevant system records. The digital investigator will assess available evidences of security breaches within the data systems with the aim of making recommendations so that appropriate conditions necessary for maximum forensic enhancements and production can be put in place. The investigator will compare, authenticate, and test the reliability of new and existing tools latest releases as well as standard scripting that will be applied throughout the project (Chan & Vasarhelyi, 2018). All samples of directory structures to be analyzed will be standardized and organized in the investigative server by the forensic investigator.
Information System Auditor
The third team member is the information system auditor. Assignee in charge will be responsible for examining and analyzing malware that have a high likelihood of interfering with operating systems of computers, information systems of client organizations, server logs and social medial platforms (Barbara, 2007). The system auditor will also be responsible for tackling dark web and nearby malicious online traffic that are capable of causing substantial harm. Investigation and analysis of the efficiency of all tools that are to be applied by the forensic investigator and other IT experts, and the integration of multipurpose data-collection environment will be conducted by the information system auditor. The auditor will also explore and compile reports of non-forensic tools that have been used in the client information systems and databases in order to make it easy for the team members and all relevant groups to understand possible security breaches within their databases (Chan & Vasarhelyi, 2018). The auditor will conduct frequent system audits on all transformational proposals and improvise audit models for current and prospective clients, automate appropriate audit procedures, and apply data modeling and analytics that can effectively monitor and test databases. The project auditor will frequently communicate with the project manager to express progress and loopholes that need to be sealed with regard to the nature of data flow in information subsystems (Chan & Vasarhelyi, 2018). The auditor shall ensure that team members are aware of the of activities of other groups related to the project, and device recommendation resources, cost estimates as well as developing phases for the project. The auditor will also form different malware-sensing dimensions and compile accurate timely reports to the project manager.
Conclusion I plan to blend this into Cost & Effort and delete it as a Conclusion
The digital forensic investigation team need at least three members namely the Project Team Leader, Digital Forensic Investigator, and Information System Auditor. The team manager will be in charge of coordinating all the activities that the team is tasked with, and communication with third parties and clients. In order to reinforce security intelligence, a Digital System Investigator will be required to ensure system intelligence and forensic investigation as well as big data analytics. The Information Systems Auditor will ensure that cyber security system is as secure as needed, as well as alerting all the parties involved of potential threats and loopholes that pose future security breaches.
Policies are generally made with the effects of cost involved, however there is usually a lack of documentation regarding the effort or amount of resources involved. When making decisions that are concerning the aspect of forensics, cost usually focuses on the tangible assets such as servers, data and equipment. An organization must also include other expenses such as training and labor costs.
Response Time. Personnel located on-site might be able to initiate computer forensic activity more quickly than could off-site personnel.
Metrics are critical in establishing a method to successfully measure the efficiency of people, processes, and technology involved in the response readiness plan. “Metrics are tools designed to facilitate decision making and improve performance and accountability through collection, analysis, and reporting of relevant performance-related data. IT security metrics must be based on IT security performance goals and objectives” (Swanson, Bartol, Sabato, Hash, & Graffo, 2003). There are four interdependent components involved in a security metrics program, which consists of results-oriented metrics analysis, quantifiable performance metrics, practical security policies and procedures, and strong senior management support (Swanson, Bartol, Sabato, Hash, & Graffo, 2003). The success of the security program, to include the successful implementation of a metrics program, is dependent upon obtaining senior management support. This will ensure that a top down approach to security will cause security to remain a primary focus within the organization. Security policies and procedures must also be enforced by authoritative figures within the organization, in order to enforce compliance. “Metrics are not easily obtainable if there are no procedures in place” (Swanson, Bartol, Sabato, Hash, & Graffo, 2003).
The selection of specific metrics is implemented in order to measure the efficiency and effectiveness of the security controls. Metrics will be implemented in a six phase cycle that consists of preparation of data collection, collecting and analyzing data, identifying corrective actions, development of a business case, resource acquisition, and applying any corrective actions (Swanson, Bartol, Sabato, Hash, & Graffo, 2003). The metrics developed below have been specifically selected to correspond to an incident response process initiating internally from an organization. The metrics established are not tool specific, but rather focus on the overall incident response process by establishing quantifiable data in order to measure efficiency and identify improvements for the overall process.
Metric 1: Time from compromise to discovery (Dwell Time)
Dwell time measures the length of time between the initial compromise and detection by an organization (security tool, SIEM, etc), (Mandiant, 2014). “The Dwell time metric can be broken down into the following components: Detect, Review, Analyze, Identify, and Notify (DRAIN) (Mandiant, 2014). Please see figure 1 below for a graphical representation of the measurement and benefits portrayed by DRAIN.
Figure 1: DRAIN Metric retrieved from Mandiant
The overall goal in detecting dwell time is to reduce the amount of time an attacker goes undetected in a network, minimize any lateral movement, and cease any unauthorized exfiltration of data. “This can only be assessed by tracing the threat back to its origin. Determine when and where the compromise came from, in addition to tracing those lateral movements” (Douglas, 2015). Security Analysts will analyze security tool that detected threat, annotate timestamp of event, and analyze what triggered the alert. Based on alert findings, analysts will access every device (IDS, IPS, Arcsight, etc) to analyze logs for timestamps indicating detection.
Metric 2: Ratio of automatic detection versus manual detection.
Determining the effectiveness of mechanisms and tools in place to rapidly detect an incident can be achieved via analyzing both automatic and manual detection tools. This metric is used to analyze which method results in a reduction of dwell time and increased detection rates. This metric is measured by establishing a “baseline for determining the ratio of detections the security stack produces versus the combined number of human detections received. To figure out the human detections, determine the number of staff detections (e.g. an employee recognizes that their machine is malfunctioning or an IT Admin recognizes that a system is performing in unusual ways) plus the number of external detections (e.g. the number of times you get a call from the FBI /IT Admins) plus the number of detections your Security Operations staff created by manually synthesizing data from your security stack and SEIM” (Cripe, 2017). A ratio can also be determined between the same types of detection methods (automated versus automated tools) in order to determine which tool may be more efficient in detection and reduction in dwell time. This can be achieved by utilizing two tools simultaneously to see which tool creates an alert faster, and which tool notifies security personnel more efficiently.
Metric 3: Rate of Decision to triage initiation.
Effectiveness of decision speed times are measured in order to determine the amount of time it takes to make a decision following the generation of an alert. This metric measures the amount of time a security analyst takes to determine whether an alert is a false positive or not, and determine if further action is warranted to include escalation and assignment of tasks. (Cornell, 2015).
Metric 4: Containment
This metric measures the time between validating an actual alert and mitigating the threat. Containment is measured by utilizing the following sub-components: collect, validate, and react (CVR) (Mandiant, 2014). Please see Figure 3 below for a graphical representation of the measurement and benefits of CVR, and Figure 4 for unit representation of formula derived.
Figure 3: CVR retrieved from Mandiant
Figure 4: Formula in units of measurement for DRAIN+CVR retrieved from Mandiant
Metric 5: Remediation response vs reimage
This metric measures business disruption occurred by an incident. “Business disruption can be quantified based on the staff role, affected device role and length of time for a response. Taking someone’s laptop for a day to reimage it is an inconvenience. Taking down a payment processing server is a substantial disruption – even when hot backups and clustered failovers are part of the solution” (Cripe, 2017). This metric will measure the amount of time it takes to reimage a device and configure the device for full functionality. The amount of time will also be measured from initiation of business disruption through the process of containing the incident, retrieving and implementing backups, until full restoration is achieved. This metric has to incorporate monetary and data loss values as well. This metric will dictate to an organization what situations warrant a reimage solution for faster availability, and which situations warrant a more lengthy remediation process.
Metric 6: Mean time to Incident Recovery (MTIR)
This metric measures the mean time from the moment an incident occurs to the moment it is recovered. Please see Figure 5 below for the proposed formula in calculating the MTIR.
Figure 5: Formula for calculating MTIR (Aziz, Malik, & Jung, 2016).
N equals the total number of recorded incidents, and the total unit of MTIR is recorded in a hours/incident formula. “Here, we say it is incident interval as it represents the
interval between the recovery and occurrence times for a particular incident. The
number of such intervals is equivalent to the number of incidents themselves” (Aziz, Malik, & Jung, 2016).
Metric 7: Mean time between Security Incidents (MTBSI)
This metric will calculate the mean time of occurrence between security incidents (Aziz, Malik, & Jung, 2016). This metric is valuable in establishing an estimated mean time of when a new incident occurs, and the last moment the previous incident was recovered. “The amount of time an organization or an IT team has to prepare resources, currently dedicated to the recovery of an existing incident, to be deployed for recovery from a new incident. We consider this metric to be an essential one as it provides some indication of the vulnerability organizations in situations where not enough resources are available to recover from security incidents” (Aziz, Malik, & Jung, 2016).
Please see Figure 6 below for proposed formula in calculating the MTBSI.
Figure 6: MTBSI formula (Aziz, Malik, & Jung, 2016).
“Where n equals the total number of recorded incidents and hence, there are n−
1 intervals between any two incidents. The unit of MTBSI is hours/incident
interval” (Aziz, Malik, & Jung, 2016). For instance, if the formula results in a 120mins/incident interval, responders will need to be prepared because the next incident is predicted to occur in approximately 2 hours. This metric will also ensure that responders have enough resources and personnel to respond to multiple incidents, and find where improvements need to be made to ensure readiness.
Metric 8: Percentages of tickets opened per Department
This operational metric evaluates the percentage of how many tickets are generated per department regarding security incidents. “Number of tickets at a given time or over a given time period; helps to identify trends, to predict which drive higher or lower ticket volume and to correlate scheduling of agents with high-volume time periods” (Aziz, Malik, & Jung, 2016). This metric can identify which areas in the organization are targeted more, and if additional security measures need to be implemented. This metric can be captured via a ticketing system such as Trackit or Service Now, which keeps a time log of the duration of work actively being performed by a technician.
At the end of the day a well “Documented, Actionable and Up-to-date.” plan (Balaouras, 2009, p. 6-7). The concepts and strategies listed will enable your team to effectively be prepared to respond to an impactful crisis. In past years “The security market in general focuses more on preventing threats from entering the network than on detecting and stopping data from being exfiltrated.”, Mcafee, (2015). The prevention of infectious and malicious data is very important, however organizations must also do their best to balance there defenses. A larger investment should be made into training employees to get the most out of them and to provide the most productivity for the organization.
There are a plefera of issues that can lead to data infiltration within your organizations cloud, therefore making sure a competent response team a vital resource. The response team should be well trained and ready with proper equipment in order to respond to incidents in a timely manner.
Abdullah, G., Ainuddin W., Ejaz A., Muhammad S., Mustapha B. Suleman K., (Sep, 2014). Forensic
Challenges in Mobile Cloud Computing. International Conference on Computer, Communication, and
Control Technology (14CT 2014). DOI 10.1109/14CT.2014.6914202 Retrieved from
Bainey, K. R. (2004). Integrated IT project management: a model-centric approach. London: Artech
Balaouras, S., Herald, A., Yates, S., (February 26, 2009). Businesses Take BC Planning More Seriously.
Barbara, J. J. (Ed.). (2007). Handbook of digital and multimedia forensic evidence. New York: Springer
Science & Business Media.
Beedubail, G., Choy, D. M. H., Hsiao, H. I., Raghavan, S., & Vaideeswaran, G. (2016). U.S. Patent No.
9,455,990. Washington, DC: U.S. Patent and Trademark Office.
Chan, D. Y., & Vasarhelyi, M. A. (2018). Innovation and practice of continuous auditing. In Continuous
Auditing: Theory and Application (pp. 271-283). Emerald Publishing Limited.
Chevalier, S., Dang, H., Grance, T., Kent, K. (Aug, 2006). NIST Special Publications 800-86. Guide to
Integrating Forensic Techniques into Incedent Response. Retrieved from
Cichonski, P., Grance, T., Millar, T., Scarfone, K., (2012). NIST Special Publications 800-61, Revision 2.
Computer Security Incident Handling Guide. Retrieved from
Mcafee, (2015). www.mcafee.com retrieved from
USED JUST NEED TO Alphabetize and put in order/edit
Aziz, B., Malik, A., & Jung, J. (2016). Check Your Blind Spots: A New Cyber-SecurityMetric for Measuring Incident Response Readiness. Retrieved July 24, 2018, from https://www.researchgate.net/publication/308697359_Check_Your_Blind_Spots_A_New_Cyber-Security_Metric_for_Measuring_Incident_Response_Readiness
Cornell, C. (2015, January 25). Five Key Metrics for Incident Response. Retrieved July 24, 2018, from https://swimlane.com/blog/five-metrics-for-incident-response/
Cripe, B. (2017, October 30). The New Metrics of Security Operations: Tracking [R]evolutionary Improvement In Efficiency and Effectiveness with Automated Detection & Response (ADR). Retrieved July 23, 2018, from https://www.fidelissecurity.com/threatgeek/2017/09/new-metrics-security-operations-tracking-revolutionary-improvement
Douglas, J. (2015). Cyber Dwell Time and Lateral Movement. Retrieved July 23, 2018, from https://www.raytheon.com/capabilities/rtnwcm/groups/cyber/documents/content/rtn_269210.pdf
Haustein, J. (2012, April 02). Incident Management Metrics. Retrieved July 24, 2018, from https://confluence.cornell.edu/display/itsmp/Incident Management Metrics
Mandiant. (2014). Using Metrics to Mature Incident Response Capabilities. Retrieved July 16, 2018, from https://www.nist.gov/sites/default/files/documents/2016/09/16/mandiant_rfi_response.pdf
Mason, S. (2014). Incident Response Metrics. Retrieved July 24, 2018, from http://seanmason.com/2014/07/14/incident-response-metrics/
Provenza, C. (2015). Cyber Security Assessment, Remediation, Identity Protection, Monitoring and Restoration Services RFI. Retrieved July 17, 2018, from https://www.dms.myflorida.com/content/download/122878/666969/Mandiant_FireEye_-_Response.pdf
Swanson, M., Bartol, N., Sabato, J., Hash, J., & Graffo, L. (2003). Security metrics guide for information technology systems. NIST Special Publication 800-55. doi:10.6028/nist.sp.800-55
MHA Consulting Team (Nov 8, 2016). MHA Consulting. Testing and Training for Business Continuity
or Disaster Recovery. Retrieved from https://www.mha-it.com/2016/11/training-for-business-