the next step we want to look at is recovery,
so this really consists of restoring the integrity of the affected systems. So it's really returning the data systems and networks to that operational state, but also making sure that improvements and defenses improvements in um
controls and maybe surrounding processes are also made to prevent that incident from happening again.
So when we look at the primary objectives of recovery, a CZ, we said, restoring the integrity of the system but the implementing the proactive and reactive defensive measures, making sure all the data and systems are back in operational fat up back, operating in a normal fashion
and making sure that, um,
the complete resolution has been enacted, a system has not been left halfway recovered or only partially
responded to and then actually falling through with the life cycle of incident handling and closing the incident.
Now, depending on the situation,
there may be a recovery steps that are completed by
complete other parts of the organization.
So, for example, if you're rebuilding systems on service is that may be done by T organization by local system and network administrators. If you're looking at ensuring the data and the integrity of your data itself that may be
being performed by lines of business who actually owned the data.
So thinking about recovery very often the incident management team is not the group
that does the recovery steps, but those recovery steps
are an important part of the total response process. So you might see people break out and not just talk about response in general. But response and recovery is to separate things. Because of the fact of responses. Maur the containment eradication, the courses of action
part that is formed by another part of the organization. Do you two think about what actually works for your own organization?
ah system has been compromised by an intruder at the privileged access level where they had root or administrative access
rebuilding it may be the only way to ensure that all the malicious
code and any other um,
artifacts from the intrusion are removed.
Certainly, though, there are ways that intruders have too easily reinstall
the malicious code and malicious artifacts that they have
so really thinking through and understanding what the intruder did to ensure that you're choosing the right recovery strategy.
When we talk about verifying the system data,
that could be a massive undertaking. And again we said line of business might be Who has to do that? Because incident management capability probably will not understand and know
when the data has full integrity or not. That's going to be the data owners themselves.
As far as changing passwords for systems that could be very difficult to because of the fact of has have the eradication steps been done? Are you sure that all remnants of the intruder
have been removed? Are they and other systems? Do they have other tools where they're watching what's done? You don't want to change passwords and still have the intruder have access within your network to again capture those passwords and be able to gain access.
So when and how that's done could be a much more complicated process process and then also taking the opportunity during recovery to put in better security
controls, turn on logging. If it was, it was missing change. Organisational processes or procedures for house staff actually perform their functions, but related to
activities that allowed an intruder to gain access to your system's so thinking about how you improve your network and host security as part of your recovery strategy
and then making sure, as we said, that that recovery is finished, that all the steps have been taken, that the recovery has been documented and that all the right stakeholders, including management, victims of the attack owners of the system have been notified
when the recovery operations have been completed.
We've mentioned that there may be others involved in recovery. Usually that's information technology or local system administrators who may be actually rebuilding systems or changing ah software, hardware and network configurations. But if it's a large servicer or infrastructure disruptive disruption,
there may be a trigger into the business continuity operations where
there may be larger efforts that need to be undertaken to ensure the continued operation of organizational assets and service is so understanding how those other
organizational components get into the recovery process, ensuring that's been documented and that the right triggers have been documented and the flows work flows for when to engage or how to engage those other sections of the organization
have been institutionalized commune important part
In the whole response process.
We can look at kind of a very high level set of steps, knowing that each one of these steps has many sub steps in sub processes that could be taken but basically recommended steps to respond to, ah, compromise
begins with. If you have not encountered this,
activity, this malicious activity before then you want to consult your security policy, insult management for guidance on if this hits the level of being an incident and what type of
components within the organization should be involved? What types of things incident management team needs to do to execute response?
We've mentioned that documenting the steps you take in recovery is very important, including
any new information that you've learned any additional analysis that's done
regained control of the system,
this one of our containment options that we talked about.
as we analyze the intrusion
R analyze ah, breach or analyzed whatever malicious activity has occurred and try to understand what the points of access were, what systems were affected,
what data has been impacted, what operational service's have been impacted,
and then ensuring that you can contact anyone else that was involved,
especially any victim sites or any security organizations that may be experiencing the same thing. Sharing information with them, tow, understand? Do they do they know more than you found out about about this particular intrusion? Do they know about any mitigations that are out there
and then taking all the information that you've learned? Also, as part of your analysis, you look at on research mitigation strategies. And so we've just said that that can be part of why you would contact other security sites
using all that information, then to build those courses of action. The longer term recovering from from the intrusion. So recovering your systems and data, whether that's through rebuilding systems, changing passwords, installing
patches of any vulnerabilities that exist, and then improving the security of your system and networks with any new security strategies, any new defences and tools and a new policies and procedures, any new training for your staff or for your employees, and only when you
ah, full response has been done and that all malicious activity and access has been eradicated. Would you reconnect any system back to the network and active it to the Internet
and if needed, if this particular activity was not something that was within your security policy. As an incident, you may need to update your security policy itself.
Now, an interesting caveat. We talk about handling different types of incidents. But when we think about incident handling, what
would you do different if the perpetrator of this incident was an actual insider, meaning someone who has authorized access
to your networks and and systems and data as part of their job as either employee of your staff
or a former employee or a trusted business partner, such as a contractor or subcontractor? Someone in your your supply chain?
So how would this be different?
We need to think about what processes would need to be in place to properly handle
what we term insider threat incidents.
Andi, Who needs to be involved in handling such ancient incidents? And how does the normal incident handling process a change?
So when we think about handling an incident perpetrated by an insider,
again proactively would want to make sure that we thought about this and we have some policies and procedures in place. What some of those policies and procedures might outline or cover is who really needs to be involved to handle these type of insider threat incidents. It's
probably not the same group
people that handle normal technical incidents perpetrated by external parties. It might involve AH smaller group that might involve particular types of management. H r I T. And law enforcement liaisons or legal
be part of the team, and it might be
that you do not report these incidents in the incident tracking system. They might be handled through a different process.
Some organizations might handle it through their ah special human resource team. Some may handle through personal security or
some type of investigative unit, but it's probably handled in a more quieter manner,
and the documentation is probably done in a more restricted fashion.
Also, there may be different reasons why,
on procedures for pulling in h r I t. Legal war law enforcement.
should also determine
if anyone in the incident management team is even authorized to work with any of these other groups.
Um, the incident management team, maybe the group that actually collects the evidence of what may have been done by the insider.
But they're probably not the ones that execute the response strategy.
Sometimes the Incident Management Group or others in I t. May be involved to turn on specific monitoring. If someone is suspected of illegal activity or going against the security policies of the organization
and more evidence needs to be collected, there may be some
targeted monitoring in organizations where that gun it could be legally done. And, of course,
legal has to be involved in and management HR to ensure that it's done in a manner compliant with any laws were rules, regulations or mandates or internal security policies.
if any type of monitoring is done, who gets the results? How is that tracked and tell us that used in any type of incident handling again, even if that may be enacted by
members of the incident management team, they're probably in the long run, not involved in the follow up or response.
So having a process for how
you handle an incident perpetrated by an insider is another consideration in building your long term response processes.