Successfully reported this slideshow.
Your SlideShare is downloading. ×

Incident Response

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
1. https://www.pradeo.com/en-US/mobile-threat-protection
2. https://prod-edxapp.edx-cdn.org/assets/courseware/v1/ff408544c...
From the 1988 “​Morris worm​” to ransomware cyberattacks like​ ​Petya​ and​ ​WannaCryp​ of
today, the number and sophistic...
the best qualities of each. Reference:​ ​Cyber Threat Modeling: An Evaluation of Three
Methods​. The strength and weakness...
Advertisement
Advertisement
Advertisement
Advertisement
Advertisement
Loading in …3
×

Check these out next

1 of 29 Ad
Advertisement

More Related Content

Slideshows for you (20)

Similar to Incident Response (20)

Advertisement

Recently uploaded (20)

Advertisement

Incident Response

  1. 1. 1. https://www.pradeo.com/en-US/mobile-threat-protection 2. https://prod-edxapp.edx-cdn.org/assets/courseware/v1/ff408544ce4048b480fb8506af 6f84c2/asset-v1:Microsoft+INF250x+2T2019+type@asset+block/Incident-Report-Fin al.pdf 3. Introduction “​Global Cyber Risk Perception Survey​,” a recent global survey by Marsh and Microsoft examines cyber risk concerns and management strategies. Over 1,300 executives from organizations of all sizes in a range of industries worldwide participated in the survey. "Two-thirds of survey respondents ranked cybersecurity as a top five risk management priority, but only 19% expressed high confidence in their organization’s ability to manage and respond to a cyber event, and only 30% have developed a plan to do so.” Besides the above finding, the following responses were also noted. ● Most respondents cited their IT departments as the main owner for cyber risk management. ● 75% selected “business interruption” as the most disruptive on the company’s bottom line. ● 20% of surveyed organizations do not have cyber insurance. ● 25% are unsure of the status of their cyber insurance policy if they have one. yberattacks often have a significant monetary impact on organizations. The level of creativity and innovation in the tenebrous cybersecurity world is growing unabatedly. Most executives have a deep understanding of their business and the importance of their assets; however, many don't understand cybersecurity or how hard it is to protect those assets from a cyber incident. Let’s define a cybersecurity incident. A security incident is an event that affects the confidentiality, integrity, or availability of information resources and assets in the organization. An incident could range from minimal impact to a major incident, where administrative access to enterprise IT systems is compromised (as happens in targeted attacks that are frequently reported in the press). A security incident frequently results in a breach of sensitive information, but it sometimes results in operational or data destruction instead. A breach of personal information has specific legal requirements in many jurisdictions.
  2. 2. From the 1988 “​Morris worm​” to ransomware cyberattacks like​ ​Petya​ and​ ​WannaCryp​ of today, the number and sophistication of cyberattacks will continue to grow. These types of incidents can become challenging to deal with for organizations that are not equipped or trained to deal with managing a major crisis operation. The following are some key takeaways from the ​Microsoft Enterprise Cybersecurity Group Detection and Response team​ that has worked extensively to help customers respond to and recover from these kinds of attacks. Cyber Threat Modeling Cyber Threat Modeling is a systematic method, or framework, to uncover and identify possible threats. Threat modeling allows you to apply a structured approach to security and to address the top threats that have the greatest potential impact to your organization. “Threat modeling is needed because of the dynamic nature of security. The attack and defense sides of security are constantly changing. As part of handling this change, organizations should continually reassess and evolve their defenses. This includes adopting continuous monitoring practices, security automation technologies, and threat intelligence feeds to detect new vulnerabilities and attacks in near-real-time, allowing rapid risk mitigation. Another key component of handling the constant change in security is having security metrics; these can be used for more informed decision making, again often relating to risk management in general and risk mitigation in particular” Ref: NIST SP 800-154 It is important to base the structured approach mentioned above on a standard process to not overlook serious threat scenarios. There are several threat modeling approaches that exist, and they typically fall into one of the following buckets: attacker point of view, systems point of view, or a company’s assets point of view. Some of the benefits of Cyber Threat Modeling include: ● Looking at your systems from an attacker’s viewpoint. This allows one to determine and prioritize what needs to be protected. ● Helping you to “think like an attacker” without being the attacker. How likely is it that this company will be attacked? ● Helping determine what mitigations should be in place. What are the consequences if an attack is successful on an asset? ● Helping you understand your attack surface and develop a plan to reduce it. Carnegie Mellon University (CMU) published a study of three frameworks that are considered by them to be "exemplar approaches” –​STRIDE​,​ ​Security Cards​, and​ ​Persona non Grata​. This blog post discusses how this evaluation will help develop a model that fuses
  3. 3. the best qualities of each. Reference:​ ​Cyber Threat Modeling: An Evaluation of Three Methods​. The strength and weakness of each method is reviewed in the referenced article. Stride The ​STRIDE​ method was developed by Microsoft and has been in use for many years. STRIDE is an acronym consisting of the following six categories: ● Spoofing identity​. An example of identity spoofing is illegally accessing and then using another user's authentication information, such as username and password. ● Tampering with data​. Data tampering involves the malicious modification of data. Examples include unauthorized changes made to persistent data, such as that held in a database, and the alteration of data as it flows between two computers over an open network, such as the Internet. ● Repudiation​. Repudiation threats are associated with users who deny performing an action without other parties having any way to prove otherwise—for example, a user performs an illegal operation in a system that lacks the ability to trace the prohibited operations. Nonrepudiation refers to the ability of a system to counter repudiation threats. For example, a user who purchases an item might have to sign for the item upon receipt. The vendor can then use the signed receipt as evidence that the user did receive the package. ● Information disclosure​. Information disclosure threats involve the exposure of information to individuals who are not supposed to have access to it—for example, the ability of users to read a file that they were not granted access to, or the ability of an intruder to read data in transit between two computers. ● Denial of service​. Denial of service (DoS) attacks deny service to valid users—for example, by making a Web server temporarily unavailable or unusable. You must protect against certain types of DoS threats simply to improve system availability and reliability. Elevation of privilege​. In this type of threat, an unprivileged user gains privileged access and thereby has sufficient access to compromise or destroy the entire system. Elevation of privilege threats include those situations in which an attacker has effectively penetrated all system defenses and become part of the trusted system itself, a dangerous situation indeed. STRIDE uses a checklist evaluation approach made from the above listed categories. Essentially, you look at each part of the service and determine whether any threats that fall into any of the STRIDE categories exist for that component or process. Since this process
  4. 4. has been used for several years there is a good knowledge base of potential threats for each category. Identification and prioritization of possible attacks on each asset or possible entry point starts the process. The goal of the process is to determine the risk associated with the identified item and to eliminate the threats. If it is decided to skip a protection, from a risk perspective this is valid if this decision is made on purpose, while being fully aware of all circumstances and by applying a different countermeasure, like detection. It is a utopian idea to think all recommendations can be fully applied; there is always a risk estimation to be made. As taught in other courses, risks can also be transferred, accepted, and ignored. Companies have limited investment dollars, which should be spent on protecting the highest priority assets. But that’s the hard part about coming up with a cybersecurity strategy – it needs to be directional and incorporate not only short-term wins but long-term investments. The model should be used as guidance. It is important to customize by individual organizations to best suit their risks, situations, and needs. Organizations will continue to have unique and variable risks – different threats, different vulnerabilities, different risk tolerances. How they implement the practices in the model to achieve positive outcomes will vary. Any model framework should not be implemented as an un-customized checklist or a one-size-fits-all approach for all critical infrastructure organizations. The National Institute for Standards and Technology (NIST) Cybersecurity Framework (CSF) nother standards-based framework that is available is the National Institute for Standards and Technology (NIST) Cybersecurity Framework (CSF) Subcategories. NIST’s mission is to develop cybersecurity standards for the United States government. Though they are originally aimed at government entities, they are used extensively across the private sector. NIST makes the content available in the public domain. To search for content available from NIST, go to https://www.nist.gov/publications/search?term_node_tid_depth%5B%5D=248731 In the image, we have listed four of the five core functions defined in NIST CSF. The missing function is Recover, which is covered in the Incident Response section in this module.
  5. 5. Each organization should customize the framework for implementation, by determining their vulnerabilities, risk tolerances, and potential threats. Organizations can determine activities that are important to critical service delivery and can prioritize investments to maximize the impact of each dollar spent. Ultimately, the framework is aimed at reducing and better managing cybersecurity risk. The framework complements an organization’s risk management process and cybersecurity program. The organization can use its current processes and leverage the Framework to identify opportunities to strengthen and communicate to its management cybersecurity risk while aligning with industry practices. Alternatively, an organization without an existing cybersecurity program can use the Framework as a reference to establish one. Just as the Framework is not industry-specific, the nomenclature of standards, guiding principles, and practices that it provides are not country or region specific. Organizations outside the United States may also use the Framework to strengthen their own cybersecurity efforts, and the Framework can contribute to developing a common language for international cooperation on critical infrastructure cybersecurity. The list below summaries the NIST documentation of the above four functions. Identify ● Identify: Asset Management​ - The data, personnel, devices, systems, and facilities that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to business objectives and the organization’s risk strategy. ● Identify: Business Environment​ - The organization’s mission, objectives, stakeholders, and activities are understood and prioritized; this information is used to inform cybersecurity roles, responsibilities, and risk management decisions. ● Identify: Governance​ - Resilience requirements to support delivery of critical services are established. ● Identify: Risk Assessment​ - The organization understands the cybersecurity risk to organizational operations (including mission, functions, image, or reputation), organizational assets, and individuals. ● Identify: Risk Management Strategy​ - The organization’s priorities, constraints, risk tolerances, and assumptions are established and used to support operational risk
  6. 6. decisions. ● Protect: Access Control​ - Access to assets and associated facilities is limited to authorized users, processes, or devices, and to authorized activities and transactions. ● Protect: Awareness and Training​ - The organization’s personnel and partners are provided cybersecurity awareness education and are adequately trained to perform their information security-related duties and responsibilities consistent with related policies, procedures, and agreements. ● Protect: Data Security​ - Information and records (data) are managed consistent with the organization’s risk strategy to protect the confidentiality, integrity, and availability of information also known as C.I.A.. ● Protect: Information Protection Process and Procedure​ - Security policies (that address purpose, scope, roles, responsibilities, management commitment, and coordination among organizational entities), processes, and procedures are maintained and used to manage protection of information systems and assets. ● Protect: Maintenance​ - Maintenance and repairs of industrial control and information system components is performed consistent with policies and procedures. ● Protect: Protective Technology​ – It seems redundant, but the systems tasked with ensuring the security and resilience of systems, and assets, need to be managed and monitored to assure they conform with policies, procedures, and agreements.
  7. 7. ● Detect: Anomalies and Events​ - Anomalous activity is detected in a timely manner and the potential impact of events is understood. ● Detect: Security Continuous Monitoring​ - The information system and assets are monitored at discrete intervals to identify cybersecurity events and verify the effectiveness of protective measures. ● Detect: Detection Processes​ - Detection processes and procedures are maintained and tested to ensure timely and adequate awareness of anomalous events. ● Response: Planning​ - Response processes and procedures are executed and maintained, to ensure timely response to detected cybersecurity events. ● Response: Communications​ - Response activities are coordinated with internal and external stakeholders, as appropriate, to include external support from law enforcement agencies. ● Response: Analysis​ - Analysis is conducted to ensure adequate response and support recovery activities. ● Response: Mitigation​ - Activities are performed to prevent expansion of an event, mitigate its effects, and eradicate the incident. ● Response: Improvements​ - Organizational response activities are improved by incorporating lessons learned from current and previous detection/response activities. After reviewing the functions listed in the previously of a security framework, it should be clear that a company’s Framework updating is not a one-time process. Just as
  8. 8. your company’s assets are not stagnant, neither are the hacker’s methods. Plan to repeat the process often. if you take an ongoing and systematic approach to securing your organization’s information systems, it’s reasonably unlikely that “script kiddies” will be able to compromise your systems. A diligent well-resourced defender is likely to be protected against all but the most highly resourced and persistent attackers. Introduction How prepared is your information technology (IT) department or administrator to handle security incidents? Many organizations learn how to respond to security incidents only after suffering attacks. By this time, incidents often become much costlier than needed. Proper incident response should be an integral part of your overall security policy and risk mitigation strategy. There are clearly direct benefits in responding to security incidents. Some of these benefits include the organization having a clear picture of how the breach occurred, how long the intruder was present within the organization’s information systems, and the steps that can be taken to ensure that attackers will not be successful leveraging similar techniques in the future. To successfully respond to incidents, you must: ● Minimize the number and severity of security incidents. ● Assemble the core Computer Security Incident Response Team (CSIRT). ● Define an incident response plan. ● Contain the damage. ● Minimize risks. Typical Attack timeline 1. First Host Compromised 2. Domain Admin Compromised (24-48 hours) 3. Data exfiltration 4. Attack Detected (Average 8 months) https://www.microsoft.com/en-us/download/details.aspx?id=36036
  9. 9. Prepare for a Security Incident Unfortunately, most organizations are likely to experience one or more major incidents in which an attacker has administrative control over the IT systems that enable your business processes and store your critical business data. ##Your company should: 1. Prepare for a Crisis​ – Reduce risk to your organization with key preparations. Review NIST Special Publication 800-184 “​Guide to Cybersecurity Event Recovery​.” 2. In a Crisis​ – Immediately limit potential damage to your organization. This includes tips and guidance for technical, operational, legal, and communications aspects of a major cybersecurity incident. While the following top-level tips and practices may be valuable in managing a crisis, each incident is unique and complex. For comprehensive guidance and specialized advice, we recommend that you should consider engaging professional assistance for an active major incident. In the following videos we continue looking at the Phases of Major Response. The following chart is discussed. Things to Remember while in an Incident
  10. 10. When (not if) a security incident does happen, you will need to ensure that its impact is minimized. To minimize the number and impact of security incidents, you should: ● Keep calm​ – The first reports are usually wrong. Making the right decision requires data. ● Do no harm​ – It is possible to stop a hacker attack by removing your systems from the network. You have stopped the attack, but you have essentially done a denial of service attack on yourself. In this case you have taken the wrong steps. ● Management Support​ - Gain management support for security policies and incident handling. ● Be Accurate​ – Confirm that anything you share publicly is correct and truthful. ● Get help when needed​ – Investigating and responding to attacks from sophisticated attackers benefits significantly from deep expertise and experience. ● Initiate your incident response team​ – Including your communications, legal, and HR teams, as per the plan. ● Implement your response plan​ – Stick to the plan. Recovery Preparations en an incident occurs, it is too late to develop the correct processes, log analysis, GDPR and other legal responses, data security, management responsibility, and communications strategy that will permit an enterprise to successfully recover from the incident. After defining the procedures and functions listed above, the incident response team should commence regular scenario-based training, besides Red team versus Blue team exercises described in course INF246x: Fundamentals of Cybersecurity. The goal of these training exercises is to validate procedures and processes, as well as refresh the team’s knowledge. Typically, these exercises will also highlight gaps and shine a spotlight on newly found dependencies. The following recovery processes should be part of the training exercises. Validated backup and recovery capability for critical data ● For example, preparing for a destructive attack that deletes or encrypts data (such as ransomware) requires that you have validated your ability to recover critical data using an offline and/or ransomware resistant backup capability (such as Microsoft Azure Backup). Create technical documentation/automation
  11. 11. ● Write and validate technical documentation (and/or automation) for procedures that are frequently required during a security incident, including: Compromised account recovery procedures that include consideration of​: ● Levels of confidence on account compromise (active attacker use, account credentials exposed on known compromised host, suspicious account behavior, etc.) ● How to validate whether accounts were tampered with using offline backups, change logs, or other systems of record ● Whether to reset password or rapidly recreate account ● How to handle potential conflicts/integration with the Identity Management system during any account recreation Compromised host recovery procedures for both workstations and servers​. This should include: ● Host OS (and Application) rebuild procedures ● System recovery procedures and criteria for when to recover vs. rebuilding of a system ● Performing password resets and​ ​C2 channel​ blocking alone is ineffective without also detecting and removing attacker malware from hosts. ● Network segregation and isolation procedures including the ability to: ● Search and monitor internet egress point logs for attacker Command and Control (C2) channels ● Block attacker C2 channels at internet egress points ● Isolate high value assets from other endpoints in the production environment (such as compromised workstations and servers) if feasible. Network segregation and isolation procedures including the ability to​: ● Search and monitor internet egress point logs for attacker C2 channels. ● Block attacker C2 channels at internet egress points.
  12. 12. ● Isolate High Value Assets (HVA) from other end points in the production environment (such as compromised workstations and servers), if feasible. Lesson Review - Hallmarks of a Strong Response Program Because of the complexity of modern organizations, the ideal response program will vary from industry to industry and organization to organization. The general attributes of a strong incident response and recovery program are: Strongly integrated with​: ● Business priorities and leadership ● IT Operations ● Business Continuity Management and Disaster Recovery ● Context from internal and external sources Continuous learning culture and processes​: ● Postmortems performed, and lessons learned integrated ● Regular exercises and red team validation Documentation​: ● High level of familiarity with response framework by all stakeholders ● Detailed technical recovery instructions (or automation) for IT and Security Professionals Technical Readiness for major incidents​: ● Access to technical proficiency with security systems and business critical systems ● Access to experience on operational, communications, and legal
  13. 13. ritical Success Factors Module Review Critical Success Factors ● Clear Plan and Limited Scope – Work closely with technical teams to build a clear plan with limited scope. While plans may change based on adversary activity or new information, you should work diligently to limit “scope creep” of additional tasks. ● Clear Plan and Ownership – Recovery operations involve many people doing many different tasks at once, so designate a clear project lead for the operation for crisp decision-making and good information to flow among the crisis team. ● Stakeholder communications – Work with communication teams to provide timely updates and active expectation management for organizational stakeholders. ● Know your capabilities and know your limits – Managing major security incidents is very challenging, complex, and new to many professionals in the industry. You should seriously consider bringing in expertise from external organizations or professional services if your teams are overwhelmed or aren’t confident in what to do next. ● Capture lessons learned – Build and continually improve role-specific handbooks for security operations, even if it’s your first incident without any written procedures. Additional References 1. Understanding the Role of Threat Modeling in Risk Management​, INFOSEC Institute, 2/28/2018 2. A Java library for parsing and programmatically using threat models on​ ​GitHub​. Supports Microsoft Threat Modeling Tool 2016 3. Threat Risk Modeling​, Open Web Application Security Project (OWASP).
  14. 14. 4. Guide to Data-Centric System Threat Modeling​, Draft NIST Special Publication 800-154 5. Incident Response Reference Guide​, Microsoft, EY, Edelman 6. Azure Security Center planning and operations guide Introduction Maintaining Confidentiality, Integrity, and Availability, also known as the CIA Triad, of an organization’s digital assets in today's hyper-connected, distributed, business environment is a true challenge. Doing so becomes even more difficult as the sophistication of hackers increases. One of the mainstays that many organizations include in their protection strategy is the creation of a Computer Security Incident Response Team (CSIRT). The CSIRT should be the focal point for dealing with computer security incidents in your environment. An incident begins when someone becomes aware of a potential incident. An incident is defined broadly in​ ​NIST SP 800-61​ as “a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.” The incident response process has several phases. The initial phase involves establishing and training an incident response team and acquiring the necessary tools and resources. During preparation, the organization also attempts to limit the number of incidents that will occur by selecting and implementing a set of controls based on the results of risk assessments. The major phases of the incident response process, as defined by NIST, are preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. The graphic below illustrates the incident response life cycle.
  15. 15. Observe that the process illustrated is not a linear, step by step process. Instead return arrows point to the need, in all but the simplest of cases, for incident responders to return to a previous stage. Note the Containment Eradication & Recovery phase has a looping arrow back to the Detection & Analysis phase to validate that the incident has been resolved. The intricate “dance” shown above is a normal process in a security incident response. Preparation Actions Your team should consist of a group of people with responsibilities for dealing with any security incident. Team members should have clearly defined duties to ensure that no area of your response is left uncovered. As detailed in the Carnegie Mellon University Software Engineering Institute’s “[Action List for Developing a Computer Security Incident Response Team (CSIRT)] (https://resources.sei.cmu.edu/asset_files/WhitePaper/2006_019_001_53104.pdf),” before the implementation of the CSIRT team the following actions should be addressed: ● Determine the mission, goals, and objectives of the CSIRT. ● Determine who is supported or served by the team. ● Obtain management buy in by C-level sponsors; this includes funding. ● Create a project plan. This should include the reporting structure, authority, and where the team fits within the company’s organizational structure. Also, it should include when the team will become operational. ● Determine the type and amount of security incident services that can be provided. Be realistic. The scope should be smaller when you first start up. ● Cross-train the CSIRT staff. Once the staff, and the resources needed to support the team, have been identified, cross-train to prevent a single point of failure. ● Define a workflow that includes roles and responsibilities of the team. Authority levels of team members is important to document. Solicit feedback on the team implementation plan. ● Create a taxonomy of terms to produce a shared understanding across the team. ● Continue to look for ways to enhance collaboration among team members and others in the security field.
  16. 16. Team Duties Assembling a team before an incident occurs is very important to your organization and will positively influence how incidents are handled. A successful team will: ● Monitor systems for security breaches​. Confirm that you have access to tools and skills that allow you to detect advanced attackers in your environment. These capabilities are constantly evolving, but an advanced program currently would include: ○ Event correlation and analysis ○ Integrated threat intelligence ○ User and Entity Behavioral Analytics ○ Ability to detect with both Indicators of Compromise for historical patterns and Indicators of Attack for evolving techniques ○ Machine learning analytics ● Serve as a central communication point​, both to receive reports of security incidents and to disseminate vital information to appropriate entities about the incident. ● Document and catalog security incidents​. ● Promote security awareness​ within the company to help prevent incidents from occurring in your organization. ● Support system and network auditing​ through processes such as vulnerability assessment and penetration testing. ● Learn about new vulnerabilities​ and attack strategies employed by attackers. ● Research new software patches​. ● Analyze and develop new technologies​ for minimizing security vulnerabilities and risks. ● Develop investigation and forensic capabilities​. Confirm that you have access to advanced tools and skills to investigate targeted attacks that include malware analysis and attack activity analysis that can produce a comprehensive attack timeline. You can get access to these capabilities by purchasing tools and hiring
  17. 17. analysts or you can retain access via external entities or professional services. ● Continually improve​ and update current systems and procedures. Team Preparations When you create a CSIRT, the team must be prepared to handle incidents. To prepare the team, you should: ● Train them​ on the proper use and location of critical security tools. You should also consider providing dedicated laptops that are preconfigured with these tools to ensure that no time is wasted installing and configuring tools, so they can respond to an incident. These systems and the associated tools must be properly protected when not in use. ● Assemble all relevant communication information​. You should ensure that you have contact names and phone numbers for people who need to be notified. This often includes members of the CSIRT, those responsible for supporting all your systems, and those in charge of media relations. You will also need details for your Internet service provider (ISP) and local and national law enforcement agencies. Discuss with your legal counsel about contacting local law enforcement before an incident happens. This will help you to ensure that you understand proper procedures for communicating incidents and collecting evidence. Legal counsel should be informed of any contacts with law enforcement. ● Validate backup and recovery capability​ for critical data; for example, preparing for a destructive attack that deletes or encrypts data, such as ransomware requires that you have validated your ability to recover critical data using an offline and/or ransomware resistant backup capability, such as Microsoft Azure Backup. ● Place all emergency system information in a central, offline location​, such as a physical binder or an offline computer. This emergency information includes passwords to systems, Internet Protocol (IP) addresses, router configuration information, firewall rule set lists, copies of certification authority keys, contact names and phone numbers, escalation procedures, and so on. This information must both be readily available and be kept extremely physically secure. ● Create technical documentation/automation​. Write and validate technical documentation (and/or automation) for procedures that are frequently required during a security incident, including: ○ Compromised account recovery procedures that include consideration of: ○ Levels of confidence on account compromise (active attacker use, account credentials exposed on known compromised host, suspicious account
  18. 18. behavior, etc.) ○ How to validate whether accounts were tampered with using offline backups, change logs, or other systems of record ○ Whether to reset password or rapidly recreate account ○ How to handle potential conflicts/integration with the Identity Management system during any account recreation. ● Compromised host recovery procedures for all computing systems​. This should include: ○ Host OS (and Application) rebuild procedures ○ Cleaning procedures and criteria for when to clean vs. rebuild (if “cleaning” a host is deemed acceptable at your organization) ○ Network segregation and isolation procedures including the ability to Search and monitor internet egress point logs for attacker Command and Control (C2) channels ● Network segregation and isolation procedures​, including the ability to: ○ Search and monitor internet outlet point logs for attacker Command and Control (C2) channels ○ Block attacker C2 channels at internet egress points ○ Isolate HVAs from other end points in the production environment (such as compromised workstations and servers), if feasible. he ideal CSIRT membership and structure depends on the type of your organization and your risk management strategy. However, the CSIRT should generally form part or all of your organization's security team. Inside the core team are security professionals responsible for coordinating a response to any incident. The number of members in the CSIRT will typically depend on the size and complexity of your organization. However, you should ensure that there are enough members to adequately cover all the duties of the team at any time. Establishing Team Roles A successful CSIRT team consists of several key members.
  19. 19. ● CSIRT Team Leader​. The CSIRT must have an individual in charge of its activities. The CSIRT Team Leader will generally be responsible for the activities of the CSIRT and will coordinate reviews of its actions. This might lead to changes in policies and procedures for dealing with future incidents. ● CSIRT Incident Lead​. In the event of an incident, you should designate one individual responsible for coordinating the response. The CSIRT Incident Lead has ownership of the incident or set of related security incidents. All communication about the event is coordinated through the Incident Lead, and when speaking with those outside the CSIRT, he or she represents the entire CSIRT. The Incident Lead might vary, depending on the nature of the incident and is often a different person than the CSIRT Team Leader. ● CSIRT Associate Members​. Besides the core CSIRT team, you should have several specific individuals who handle and respond to incidents. Associate members will come from a variety of different departments in your organization. They should specialize in areas that are affected by security incidents but that are not dealt with directly by the core CSIRT. Associate members can either be directly involved in an incident or serve as entry points to delegate responsibility to a more appropriate individual within their departments. The following are some suggested members and their roles. ● CSIRT Lead from Legal​ - Much of cybersecurity incident response preparation involves evaluating and managing legal risk. With no overarching cybersecurity law, counsel should draw from a patchwork of statutes (e.g., state notification statues), regulations, government enforcement proceedings, settlements, and guidance, and litigation trends to assess risk. The legal lead should determine whether they plan to involve law enforcement, so you can plan investigation and recovery procedures appropriately. ● CSIRT communications lead​ – See next lesson for details. ● IT Contact​ - This member is primarily responsible for coordinating communication between the CSIRT Incident Lead and the rest of the IT group. The IT Contact might not have the technical expertise to respond to the incident; however, he or she will be primarily responsible for finding people in the IT group to handle security events. ● Management​ - Depending on the incident, you might involve only departmental managers, or you might involve managers across the entire organization. The appropriate management individual will vary according to the impact, location, severity, and type of incident. If you have a managerial point of contact, you can quickly identify the most appropriate individual for the specific circumstances. Management is responsible for approving and directing security policy. Management is also responsible for determining the total impact (both financial and otherwise) of the incident on the organization. Management directs the Communications Officer regarding which information should be disclosed to the media and determines the
  20. 20. level of interaction between the Legal Representative and law enforcement agencies. CSIRT Communications ● CSIRT communications lead​. Appoint a communications lead to be part of the core incident response team and confirm that he or she understands the response process and cybersecurity. In the moment of a crisis, precious time and energy is spent identifying who is leading on communications and who will speak on behalf of an organization. There are unique nuances with communicating cybersecurity incidents and investigations that a strong communications lead must understand to be effective. By having him or her as part of the core team, communications and reputation management is more likely to be properly represented during the decision-making process. ● Develop a communications portion of existing incident response plans​, including clear ownership and approval processes. Many companies have technical incident response plans that outline how to investigate and remediate an issue. What’s often missing is a communications-centric portion to manage the complexity of deciding what to disclose to whom and when. ● Map the stakeholders​ that may need to receive communications regarding an incident, including customers, media, partners, regulators, employees and vendors. This includes confirming the company understands its contractual obligations to inform certain partners or customers. Often incidents may not require disclosure to regulators, but they still need to be shared with enterprise customers in a timely matter. Understanding these obligations ahead of an incident can save valuable time during a live incident. ● Develop draft media holding statements​ and other materials for the major types of incidents that are of most concern to your company. These statements are intended to be used with the press during the early stages of an investigation when many of the details of the issue are still unknown. It’s also important to develop key communications considerations for each of the incidents, which can help guide decision-making when an incident occurs. For example, if and under what circumstances the company would pay to remove ransomware and how would they position this decision to key stakeholders. Host a table top exercise​ with members from the entire incident response team to test how they would react to the media, customer, and regulator attention due to an incident. These tabletops are often best done in conjunction with outside legal counsel and are intended to focus on the non-technical aspects of incident response. Practice-SIR
  21. 21. Company Information The report begins with basic organizational information. Notice that the incident has been resolved. Some SIRs also have a unique ID like a globally unique identifier (GUID) associated with the report Incident-Overview In the Incident Overview section of the report, a high-level report of the incident is provided.
  22. 22. In the post analysis, Don Funk, is characterizing all the events and incidents that have been identified. The incident is being classified by A Datum standardized severity rating. Their ratings are based on the incidents impact or the degree of damage done to the organization. NIST recommends four categories in​ ​NIST SP 800-61​: None, Low, Medium, High. The fifth category, Very High, was added by A Datum to consider the effect on their suppliers and the stories they supply to. Some companies will rank the severity based on the cost of the recovery effort. What did you first notice was a possible issue?
  23. 23. Incident Report
  24. 24. In the Incident Report section, we characterize the effect of the incident on the organization and the actions taken to respond to the incident. Pertinent logs and services were reviewed that help determine the attack vector and to validate the incident.
  25. 25. The systems, functionality, and address can all help determine the target and possible network area that is not secure. Determine it sensitive information was stored in the database. Besides business impact, there are now privacy concerns. Legal needs to be alerted.
  26. 26. Plan to communicate the impact to staff, users, business owners, partners, and executive sponsors. Validate and Verify user accounts and permissions.
  27. 27. What data was accessed or exfiltrated during the security incident contributes to the severity of the incident. In NIST SP 800-61 a data impact categories rating scale is provided. Their categories are None, Privacy Breach, Proprietary Breach, Integrity loss. The categories and scale should all be customized to meet the business requirements of each company. An incident could potentially corrupt data for many months prior to discovery. It is, therefore, very important that as part of your incident response process, you determine the duration of the incident. (File/system integrity software and intrusion detection systems can assist you in this.) In some cases, the latest or even several prior backups might not be long enough to get to a clean state, so you should regularly archive data backups. Azure backup service is an excellent off-site function. The attacker might be an employee, contractor, temporary employee, or other insider within your organization. Without thorough, detailed documentation, identifying an inside offender will be very difficult. Proper documentation also gives you the best chance of prosecuting offenders. Trying to determine who attacked is a usually a very arduous effort. NIST in their Computer Security Incident Handling Guide​ states “Identifying and attacking host can be a
  28. 28. time-consuming and futile process that can prevent a team from achieving its primary goal – minimizing the business impact.” Estimate for the business impact. Attackers often use the same exploit and vulnerabilities on multiple system. Survey your environment to look for similar attacks. This is part of the lessons learned, recommended changes to improves organization security. Note additional funding is usually needed to apply recommendations.

×