Technical security management is looking at the technical environment and make sure that the mechanisms that are implemented have been implemented properly, that they perform correctly. The major focus is on the implementation of standards, as such, they should be uniformly implemented across the in-scope parts of the enterprise. And there should be a process for capturing and reporting any exceptions.

It ensures that key controls are continuously monitored and that whenever anything is unknown, unexpected, or out of bounds, that they're reported. It ensures logging is reliable and visible to all the parties who need that information. And it provides at the end, processes for decommissioning of assets.

Throughout, we have to assess resource levels on a regular repeat basis. We have to look at the financial, the human, and all technical resources. We have to look at budget and available money to make sure that they're allocated correctly, and try to resolve any discrepancies or gaps. We always have to ensure the resources align with the goals to ensure mission accomplishment.

Part of this will include checking staffing levels to make sure that the resources are being properly used, and that they are adequate, including the skills possessed by the staffing. We have to check and make sure that if current technology capacity is sufficient, that we have plans for its augmentation where necessary, replacement when necessary, or complete refresh when necessary to ensure that we stay on current and future needs.

A critical part of security operations management will be the development and implementation of an incident response plan. This IRP is the operational aspect of preparation for incidents that we know will occur, and that have the opportunity to cripple the organization to a small or great level.

We will of course, need to have a policy, a procedure or a set of procedures, as well as the resources to ensure that the incident response plan can be done properly, and cover all of those events which it is intended to cover. We will need to conduct exercises to rehearse the plan, ensuring that the plan is properly designed, and properly implemented, and actually works. This is to prepare the workforce to respond and assure that they are skilled and ready to do so when called upon.

So the elements of an incident response plan will include the preparation phase, in which we establish how we are going to handle incidents. The policy and warnings in systems and set those parameters. Establishes the communication plan to stakeholders, one aspect that is extremely critical. It develops the criteria for reporting incidents to authorities when that becomes necessary. We develop the processes for activating the incident management team.

We have to establish secure locations to execute the incident response plan. We also have be sure that any equipment or software resources are identified and made available. Then we move on to identification. It assigns ownership for a reported incident. Verifies the report is in fact an incident and not a false positive. It establishes the chain of custody of all the artifacts that will be generated during the process. And it provides for a triage process to determine the relative severity of the event.

Following identification will come the containment activities. This is where we activate the incident response team. We notify the appropriate stakeholders. We very quickly, or as quickly as necessary, get agreement on the appropriate actions to take given the nature of the event. It gets the IT representatives and the team members involved as necessary.

As the incident is dealt with, it obtains and preserves evidence. We document from the very beginning and takes backups as needed. And management communications to the public may have to be dealt with at this point. Step number four is eradication. We attempt to determine the root cause, but not at the risk of additional compromise or spread of the event.

We attempt to locate the most recent backups, which should be done on the established schedules. Once we've established what the root cause is, we make efforts to remove it or quarantine it. We try to amplify the defenses to make them more effective against spread or exacerbation. And then we perform a vulnerability analysis to determine how the root cause did its damage.

And our final phases are to recover, restoring operations. We validate the restoration, always having a policy of taking nothing for granted. We get the system owners to test their systems and make sure that they are back in a pristine state. And then we facilitate the system owners declaring normal operations once again, after the verification tests have come back and have proven that the systems are back in their normal operating state.

We always have to capture lessons learned because we have to report on what happened and how we dealt with it. The effect of the measures that were taken for the given event. The results after the plan was executed. Any issues that were encountered that were unexpected, especially if they were unexpected.

We have to examine these lessons learned for any sort of improvements that need to be made. The report is done and it presents the report to the relevant stakeholders. But the primary functions of the capturing of lessons learned is to see how we did in this event, and how we can do better in the future. We will always have to perform a business impact analysis. This needs to be done early in the cycle of any development or operation, and it may need to be done at periodic points following them.

At a minimum, the BIA needs to capture the following. It needs to determine the losses resulting from a function not being available, whatever may cause that lack of availability. We have to figure out how the loss will escalate over time, if indeed it will. Identify minimum resources necessary to recover from the loss event and prioritize the recovery if more than one asset is involved.

The BIA needs participation from all the relevant aspects of the business. That includes the business owners and any other stakeholders that require information. Typically there are three steps to a BIA. One is to gather the assessment material to identify the elements crucial to the organization's survival within the scope of the BIA. Analyze the information gathered, and document the results, and present recommendations for improvements.

So when a BIA is put together, it needs to follow good reporting and complete reporting practices. We start with a functional description of what is in scope. We have to talk about any dependencies, interdependencies between various assets, systems, networks, and other components. We have to describe what the impact profile is likely to be or what we estimate it to be. The operational impacts, financial impacts will also have to be stated.

If there is going to be a work backlog generated from an event causing this outage, we need to describe what that is and its criticality. We will also have to describe what recovery and technology resources will be required. As part of the workaround procedures that need to be expressed, it will be options for work-at-home. Shifting workload to other locations, other business office locations of the enterprise. How business records are going to be generated, kept, and reported. Regulatory reporting if need be. Work inflows. Business disruption experience. Any competitive analysis. Or any other issues or concerns that arise.

The point being to identify the impacts, how to compensate for them, and how to keep things as normal as reasonably possible given the conditions.

Without question, any incident response process requires that we develop an escalation process to ensure effective management. This needs to be one of the clearest processes we develop so that we can escalate, get other resources or management involved as may be required, sometimes at a moment's notice.

For each event type, it may require a different form of escalation process. And for each one of these, we need to call out who is responsible, at least one backup person to the primary, and how long we expect any such action to take before it's completed. If the action can't be executed, we need to start the next one and develop a workaround for the one that could not be executed.

Action escalation to make sure an alert is an attempt to respond within a period of time before things get out of control. Usually that means there is a predefined limit in which that response must take place. Beginning with alert, the notifications need to be sent out to various parties identified before incidents began to occur. And that will include senior management, the call-out for the recovery teams, possibly human resources, insurance companies, backup facilities, and other vendors and customers. And this will follow until the emergency has resolved or until last notification is sent advising everyone of an all clear. This will of course involve announcements through the help desk.

There should be processes complementary to our incident response for the help desk to follow to ensure that employees are able to notify anyone calling in to help them understand what is going on and what actions are being taken. This means of course there needed to be guidelines for spotting typical requests versus the actual incident reports so that we don't react to false positives. It reduces the risk of help desks being targeted for social engineering or for actions on false positives.

For every incident management, we have to develop response teams so that we can deal with unique scenarios of incidents and outages. To do this we should create a matrix to match teams to activities for which they are skilled and prepared. Common teams in the matrix may be up to 12 different teams. It just depends on the complexity of the enterprise.

Common teams usually include emergency action. These may deal with fires, or other first responder type of activities. A damage assessment team, which could be damage assessment for physical or electronic assets. There may be a relocation team if relocation becomes necessary.

A security team making sure that any security, either physical or IT, is being taken care of appropriately. And then an emergency management team and an executive management team to handle control of the entire incident response. This of course all needs to be prepared well in advance of any incident occurring. And that means we have to plan for the organization, training, and equipping of all the members chosen to be on the response staff.

Part of this will include developing test scenarios and running the teams through all the different steps for each of the different scenarios. We're trying to identify various confusion points, possible ambiguous or ill-defined procedures, any missing equipment or possible training, and any other resources that will be required before the incident occurs, and the incident resources are unavailable. At a minimum, each team should undergo induction so that they're trained in what to expect, what to do, and what their role will be.

Mentoring, those who have been through this before bringing along the newest ones, turning the junior ones into seasoned ones. This will require on-the-job training as we conduct various exercises through various scenarios. And then formalized training that will bring members up to the highest level of competency needed to do proper incident response for our enterprise. And now we've come to the end of our section. We'll stop here for a brief time. And then we will pick up with section 41, information risk management, metrics, monitoring, and reporting.