Incident Detection and Response

Por: Coursera . en: , ,

  • Module 1: Operate All-source Intelligence for Monitoring and Incident Detection
    • We saw in Chapter 5 the evolution from simple host-based intrusion detection, through network-based intrusion prevention and on to integrated security information and event management (SIEM) systems. Each step along this path was attempting to bring together every possible signal, from every element of an organization’s IT and OT architectures, and then analyze and exploit those signals to see if any were indicators of a possible attack or intrusion taking place. The goal of such a set of processes, the objective of gathering, collating and assessing all of that information, is to try to answer three questions: 
      What just happened to us? 
      What happened to us a while ago, but we didn’t notice it? 
      Is it too late to do anything about what happened in either case? 
      Part of that evolution to SIEMs and the next generation of intrusion detection and response systems (and the next generation after that) is the idea of all-source intelligence as the input and the process. This idea of using every possible piece of data from even the most unlikely of channels is nothing new; business forecasting and market analysis does it, national weather services do it and, of course, military and national security organizations have been doing it for years. These professions and many others know that transforming information into actionable intelligence, the kinds of conclusions and assertions on which leaders and managers can base their decision-making, requires as broad a spectrum of analysis approaches and ideas as the spread of the sources it observes. 

      All-source intelligence as a cybersecurity operation takes in far more than just monitoring. Monitoring in general involves observing the things you already know about: the systems, the endpoints, the people using them and the traffic on the networks. Monitoring is often about comparing observations to clip levels or alarm thresholds. As we’ll see, all-source intelligence as a process goes beyond monitoring; but it plays a vital role in enhancing the monitoring function, which still must be performed well. 

      No examination of monitoring or incident detection would be complete without looking at the compliance requirements that relate to it, and we’ll use that topic to bring the many threads of this module together. 
  • Module 2: Support Incident Lifecycle
    • An information security incident is a set of one or more events, or changes in the state of an information system, asset or architecture, which needs prompt and immediate security action to assess, contain, respond and recover from.  Well-prepared organizations can, with skill and luck, limit the damages to assets and the disruption to business processes that an incident might otherwise cause. Poorly prepared organizations are more likely to make serious mistakes in characterizing and handling an incident and may cause themselves more harm in the process. 

      Proper handling of information security incidents depends as much upon the day-to-day business processes as it does the specifics of the incident response processes. Incident detection, assessment, escalation, communication, recovery and learning from the event are activities typically integrated into the organization’s incident response process. Clarifying who does what in an incident and under what circumstances will greatly help the organization recover its business functions. The security professional should understand their legal and organizational responsibilities for incident management and be able to evaluate the activities and overall effectiveness of the organization’s incident response practice. 
  • Module 3: Understand and Support Forensic Investigations
    • Digital forensics investigation as a process and as a field of study is a fascinating and exciting combination of challenges. Those who participate in such investigations find that their creative skills, their attention to detail, and their innate curiosity will be stretched to the limit as they attempt to embrace the human, organizational and technical aspects of an information security incident. Those who support the investigators, either before or during the investigation, are equally challenged but in very different ways. The support team has tasks they must perform as part of providing services to the investigators, to organizational leaders and managers, and to end users in the organization and they must perform these tasks with rock-solid reliability and dependability to the best of their ability. Simply put, they must follow procedures and make sure that all of the required processes are followed, step by step, in detail. 

      Module 2 stressed the need for solid preparation and planning before the first incident occurs, and for a flexible, responsive and agile mindset to adjust those plans when that first incident does happen and shows the plans need to be changed. Preparing for incident investigation is a major part of what the security operations team needs to accomplish. 

      To put that preparation into perspective, this module will look in more detail at the investigative process itself. Along the way, we’ll highlight opportunities for the forward-thinking security professional to get the organization, its users, its IT and OT staff and its managers and leaders prepared to support different types of forensic investigations when and as they become necessary. 

      Module 3 will introduce some of the techniques of a digital forensics investigation. You may find them useful, and called for, as you’re troubleshooting an incident involving older technology systems (such as in OT architectures), or smaller, locally hosted SOHO or SMB environments. The same basic concepts still apply in the cloud and in the world of big data but scaling to that level requires a very different approach and mindset to thinking about forensics. Let’s take a closer look. 
  • Module 4: Chapter 7 Review
    • This chapter has shown how the focus, perspective and emphasis on incident detection and response have all shifted, and shifted dramatically, over the last decade or so. Previously, security professionals focused substantial efforts on identifying, enumerating and securing assets; they focused on hardening systems and networks. These were necessary efforts, but they sometimes meant that detecting a breach or intrusion was a lower-priority effort. Many of the headline-making cyber breaches and ransom attacks of the last few years show that attackers have taken advantage of the six to eight months it takes the average enterprise to notice that they’ve had (past tense) an intruder in their systems. This must change.
      All-source intelligence as a means of identifying and characterizing possible intrusions is proving to be a powerful way to gain insight about your systems and about detecting intrusions (or attempts to intrude into them). Combined with analytics for security, it’s also turning around a time-tested practice of being very selective in what events generate log signals, which signals get logged (and how often) and how log files are managed, collated and analyzed. Today’s security professional needs to be a bit more of a data scientist than they were in the past and perhaps more of an intelligence data analyst as well.
      We also looked at digital forensics, largely from the perspective of small systems rather than cloud-hosted, large, enterprise environments. Either way, in most cases, the investigation itself and the analysis of evidence is best left to the certified, trained, expert computer systems examiners to do; but as an on-scene security professional, having some background in what digital evidence might be, how it might be analyzed and what might be learned from it can help you better prepare the organization for when it has to call in the investigators.