This chapter examines security incidents of different severity levels and appropriate enterprise responses. Incident severities are divided into four categories: false alarms, minor incidents, major incidents, and disasters. The process of responding to a major incident intrusion response has three priorities: detection, analysis and escalation.
The IDS might alert the company of the attack, the IT security staff would get a report, they would need to respond to the call, and then proceed to analyze the intrusion to understand the situation. If it is a major matter, it must be escalated to the CSIRT or Business Continuity Team. The next step is to prevent further damage from occurring, and the fundamental method of control is to disconnect the server from the local network. Once the attack is contained, companies need to prepare for the recovery phase, which can also be repaired while the computer is running. If the data is lost, the company needs to restore the program Soviet-Russian data files from the backup tapes. Companies also need to apologize to customers, employees, admit responsibility and harm. Also, need to punish employees for ignoring intrusions. Most important is that in the event of a major natural disaster, all business continuity management principles will be people-centred.
I think it’s important that you highlighted the three major priorities of responding to an incident intrusion, those being detection, analysis, and escalation. I agree that companies need to take accountability when they don’t follow the proper steps to protecting their customer’s data. Having a good response planned out beforehand is the best way to protect and minimize damage from a potential attack.
I enjoyed reading about ways to contain intrusions as part of the incident response process from the chapter 10 reading. The first topic mentioned and the most common method I’ve seen used was disconnecting the infected server(s). Disconnecting the server from the local network can bring the intrusion to a halt but this will impact the availability of systems/applications running on the server for use by legitimate users. Black holing an attacker involves blocking the IP address of an attacker(s) and was something I hadn’t heard of previously. This seems like a solid containment strategy if you want keep the systems and applications running on the infected server available but sophisticated attackers can likely find holes in this method. The final method involves prolonging the intrusion to observe what the attacker is doing.
The important thing is containment of the issue and the isolation of the affected networks which may be a radical method of containing the situation. Although disconnection stops the intrusions and making sure the server is completely unavailable for further attacks and by escalating the situation for the Response team for a quick approach to mitigate the situation.
A business continuity plan specifies how a company plans to maintain or restore core business operations when disasters occur. I think the most important part of it is testing the plan. Once a business continuity plan is developed, using input from a wide variety of departments
and external business partners, the company must test the plan. As noted earlier in this chapter,
both walkthroughs (table-top exercises) and live tests are useful. Testing is more difficult
for business continuity disasters than for major security incidents because disasters have much
broader impact and involve so many people.
The company must update the plan frequently because business conditions change constantly
and because businesses reorganize constantly. During a crisis is a bad time to wonder who must
take over responsibilities assigned to a department that no longer exists. It is an even worse time
to discover that your plan does not cover new business activities. Telephone numbers and other
contact specifics change even more rapidly than other factors and should have monthly updates.
All of this updating requires a small permanent staff for business continuity. The staff will
also act as the operational manager during a disaster.
The maintenance of business continuity plans is the hardest part of this exercise. Given the competing priorities and issues facing security teams, updating these documents can be pushed to the back burner. It’s important that firms remain diligent in these efforts, as an outdated phone list can have serious implications for effective crisis communications.
The following quote reminds me of this situation “We don’t rise to the level of our expectations; we fall to the level of our training.” Creating a business continuity plan, but failing to maintain it, creates an unreasonable expectation to be carried out by people without the appropriate training.
Business continuity planning (BCP) ensures that your business can bounce back from a natural disaster, cyberattack, or other form of natural disaster. Organizations are required to have a BCP solution which would allow for a quick return to normal business operations as quickly as possible.
Good point about returning to normal business having to be quick, when it comes to an operation being down, the longer the outage the more damage to the business
In chapter 10 Boyle and Panko discussed Incident Response and Data Recovery. I found the sections dealing with communications to be interesting, specifically how to apologize during an incident and communicate during business continuity management. The outline provided for apologies (i.e. acknowledge responsibility, explain what happened, and explain corrective actions) is good advice for general communications around technology. It’s important to practice this skill as there will certainly be a time when we will be dealing with an incident and need to communicate the issue to stakeholders.
For business continuity management, communications need to be resilient and provide redundancy. This section focused more on the means for communicating over the content. Examples such as phone trees were discussed as a means to relay important communications to stakeholders should primary systems fail.
Ensuring the right people have the information they need is one of the most important aspects of responding to incidents and interruptions to business operations.
I agree with you and the point here is to apologize at the right when the attack has caused harm to customers or employees. But the unfortunate situation about the aftermath apology on the leaks of personal information and other damaging incidents are filled hedging and waffling.
The key takeaway from this reading is the process for managing major incidents and the relationship between business continuity planning and disaster recovery. The timely response after knowing an incident has occurred, then analyze by understand the event and potential damages and escalation of major incidents to management and stakeholders and alert the response team to contain the situation about the threat or attack. However, It is essential for organization to have Incident Response System to handle and identify common threats and attack by alert sensor put in place and logging the logs captured.
Organizations have to plan ahead with details on how they will handle and respond to major incident and disasters. Disasters can include natural events such as earthquake or hurricanes, equipment failure, cyber-attacks.
Business Continuity Planning which is the required blueprint with detailed scope of action and consists of the “plan of action”. at the time of disaster and to help restore core business operations when disasters occur.
IT disaster recovery is critical to successful business continuity. Companies respond quickly to disasters and reduce losses by restoring operations through IT DRP.
IT DRP includes: Critical IT assets and their maximum allowed outage time; Tools or technologies that should be used for recovery; Emergency procedures; Disaster recovery team and their contact information
Good post explaining the difference between business continuity and disaster recovery. You are definitely right that organization must come up with a plan in their system security plan that will respond quickly to disaster and keep the system going or back to normal after that minor/major incident.
This chapter talks about business continuity and disaster recovery plan. It explains how important it is to secure a server/have a backup plan to keep the business going even after a major break up. Breaches or incidents are not only the responsibility of IT but the responsibility of all people starting from senior managers to all other employees. There are three type of incidents that Boyle elaborates such as false alarms, minor and major incidents. He explained that false alarms are incidents that deemed to be innocents and the attacker action could be similar to any actions that an employee, system administrator or manager routinely take in their work. In that case Intrusion Detection System helps in detecting suspicious activity.
I would say there is no such an innocent incident because this incident we call innocent can turn out to have a major impact if no actions are taken to stop it. In this sense, a company must plan to have real live test situation that can help them get prepared and facing the real situation in case an unplanned incident happen. Having the right information on who to call or reach out too if anybody sees any suspicious activities in the system is also a good communication plan as well.
I think that it depends on the type of incident that occurs. Since the incidents can be categorized based on the impact that happens. I agree that the company should plan regardless – especially for “innocent” incidents. Often insider threats are caused indirectly from employees such as data leaks or misconfiguration. When these events occur, they should be documented and noted in order to prepare for possibilities next time and can be used to refine incident response. Furthermore, I remember Professor Lanter talking about this before in a previous class about professionals that cut corners. Even though cutting corners can often lead to work productivity, they should be noted because if you can do it – so can somebody else. And this occurrence could make professionals more aware of what someone else could do.
An interesting point made in this readings was about Accuracy and Planning. It spoke about the danger of someone responding too hastily to an incident and taking steps before having a solid understanding of the problem. This jumps out to me because I find it to be true in Technology issues in general and not just when it comes to a security breach of some kind. Several times over the years I have found myself guilty of responding too hastily when trying to resolve an issue, nothing is worse than working on an issue for a long period of time only to find out later the solution would have taken less then half the time if you were not rushing.
The planning part is a great point as explained in the reading that the best way to respond quickly and accordingly is to plan ahead, to me this speaks to everything we are learning in this program, its best to have the proper controls/policies/plans in place so that we are prepared when something does take place.
I totally agree with you and yes it has happened to all of us before that we like to rush when we are facing a situation we put ourselves to. Taking the time to plan is actually what we are supposed to do but sometimes when you are stressed out you don’t really think too much. Same like information security. The issue is just in front of you but you are focusing on something else because you did not take the time to understand and end up fixing a different issue rather than the one you had in the first place.
This chapter addressed the appropriate corporate responses to both traditional security incidents and disasters. The following stages were discussed in detail: detection, analysis, escalation, containment, recovery, apology, punishment, and postmortem evaluation. This is relevant to all companies considering even businesses with “good security” need to be prepared to handle security incidents, breaches, or compromises. Nevertheless, I will admit that I was surprised to see “Apology” being its own stage; I figured many places would overlook this step. However, after reading into it, I understand why explaining the incident, acknowledging responsibility and harm, and explaining what actions will be taken to compensate the victims would be beneficial, especially after leaks of PII. Downplaying the severity of the incident can cause even more anger and frustration; with that being said, it is in the company’s best interest to be transparent.
Hello Elizabeth, I like when you said; “even businesses with “good security” need to be prepared to handle security incidents, breaches, or compromises.” Something we have been routinely reminded about when studying cyber security is that there is no such thing as being 100% secure. Moreover, I agree with what you said about organizations that have been compromised in a security breech needing to be more transparent. This is not usually the case! Case studies we have read and some details from our ‘in the news’ articles show a pattern that organizations lack accountability for their part in the security breaches they have experienced. I am usually shocked by how they try to keep it under wraps or downplay the reality and severity of the hacks they have allowed to succeed.
This chapter is the last chapter of “Corporate Computer Security” book which introduced 3 phases of computer security for a business including plan, protect, and response phases. Of course, this chapter discussed response phase to both traditional security incidents and disasters. The incident response process included these steps; detection, analysis, escalation, containment, recovery, apology, punishment, and postmortern evaluation. The first 3-steps are priorities at the beginning of incident. However, after the first 3-steps, the others can include in the process especially containment.
Good post detailing what the last chapter looks like. How can you explain or tell us a difference between a disaster recovery and a business continuity ?
During this chapter’s reading I actually took interest in the apology portion of this chapter. Mainly because this topic comes up a lot during a lot of news research with companies being attacked and how they commonly seem to fail to admit that the fault lies on the company for being breached. Especially since many companies collect so much personal data on virtually anybody that visits their site. Commonly, especially demonstrated within both Case Studies, is that breaches can be prevented with better communication from CSIRTs. Many of the times downplaying or writing off the incident as an everyday occurrence is extremely frustrating, especially to those affected. Not only could this affect someone’s financial situation or personal information leaked, but the cost of time to resume normal daily life is a thing. It’s very easy for a Publics Relation Manager to view the damage from impact levels, but from the individual’s perspective the impact is much higher than the companies since they don’t have access to the same resources. And this type of response can aggregate impact if multiple individuals raise their voices, and tarnish company reputation further beyond the impact of the original technicality.
This chapter provides information on the incident, disaster response, and recovery concepts and gives the details of false alarms, and minor and major incidents. It is helpful to understand speed accuracy, planning, rehearsal, and occasional live test processes. To detect various attacks in the initial step using the IDS/IPS devices which generate the alert for the system/security administrator whenever suspicious activity is detected. It gives solutions when incidents are detected, such as disconnecting the server from the local network or disconnecting the internet connections, this is useful to disconnect the attacker completely from the server but it also directly affects legitimate users and business continuity.
If an incident has occurred, then it is best to start the recovery stage when ensuring that the server is running perfectly for business continuity operation. However, it is best to first very carefully identify the backdoor rootkits, Trojan horses registry entries, etc. which are hidden in the system, and that itself can be a big threat to business operations. Once the system operation and hidden malicious programs are cleaned, then the restoration process from the last update backup to continuing operation earlier can continue.
This chapter talks about the apology process in the condition of customers or employees who are the cause of the attack. It is imperative to first acknowledge responsibility and harm, explain what happened, and also explain what action will be taken to compensate. This chapter gives details information on criminal versus civil laws, laws are changed based on government area jurisdiction and international laws. If any major attacks occurred, then computer forensics and evidence collection are important steps, where so much evidence can be collected such as the live system where the attack perform, IDS/IPS log, system log, router log, firewall log, and more which is useful to collect the evidence to capture the attack footprint.
I found section 10.5.2 on office PCs in disaster recovery to be interesting. Even if an organization strictly uses laptops, they must be prepared for the possibility of losing those laptops in the event of a disaster such as a fire. Data should be backed up and agreements for replacement hardware should be in place for a swift recovery. A stand-in physical location should be considered ahead of time as well. Hotels with an internet connection can be a great option but the security of the hotel network should be considered.
Utilizing cloud storage is a great option to mitigate the risk of data loss in the event of a disaster. My company holds thousands of licenses to Microsoft products so we use One Drive to backup our data to the cloud. While users aren’t required to use One Drive it’s strongly recommended to ensure data on our local devices aren’t lost in the event of a disaster.
I agree that backing up data is an imperative task in a disaster recovery plan. I find it interesting that Bryan mentioned one drive. We also encourage our end users at Jefferson Health to save all of their important data on one drive! However, I have been seeing a lot of news articles about how most companies have more than 90% of their assets (data) stored in the cloud. Due to that, it is imperative that these cloud services are as secure as possible and the resources stored on them are readily available to the end users who actually need them to do their job.
In this week’s Boyle and Panko’s reading of chapter 8, we learned about incident and disaster response. One of the units in this chapter is (10.2 The Intrusion Response Process For Major Incidents). I appreciated the insight they provided in that unit about Detection, Analysis, and Escalation. According to the chapter, there are many ways to detect an intrusion. Moreover, it is in an organization’s best interest to first (quickly) learn that the incident has occurred. Following that, the second step would be to, “understand the incident to be sure that it is a real event, to determine its damage potential, and to gather information needed to begin planning for containment and recovery. This is analysis.” The third step would be to handle the incident with the on-duty staff or escalate handling to the CSIRT (Computer Security Incident Response Team) or business continuity team. The chapter further continues by giving an outline of containment. Containment consists of disconnecting a server from the local network, black-holing the attacker or continuing to collect data. I thought this was a very insightful part of the chapter.
In this chapter, we learned about the intrusion detect systems, the BCP, and the necessity of backups. The key point of the incident and disaster chapter I thought was important was the three priorities at the start of an incident. Detection, analysis, and escalation. There are a ton of ways to detect an incident, an alarm, an IDS, or even a phone call. Analysis, a security analyst must gage the situation and understand if there is a security problem, equipment issue or potentially a software issue. Once determined, the analyst can figure out how to proceed. Lastly, escalation, once determined there is a security incident, it must be escalated to the CSIRT or business continuity team.
In previous chapters, we discussed the planning and protection options and how they can eliminate incidents. However, in reality, organizations should focus on post incidents options as well such as disaster recovery and business continuity. . It is important that we always take the risk remaining into consideration. While thinking about what to do after an incident happens, Boyle believes that incident severity is critical to recovery. False alarms (innocent activities), minor incidents (true breaches), major incidents (high impact), and disasters are the severity levels from less severe to the most.
The one thing I learned from this chapter was CSIRT which is designed as computer security incident response team to deal with major incidents when it is too much for regular IT staff. In the recovery process, speed is critical. First, we don’t want bad actors’ access remaining for a long time in our systems, second, every minute our system is down, it cost us money and availability issues.
I found the section on honeypots to be the most interesting. Using honeypots to lure in and distract attackers is a useful way into finding more about the motives and tools that are being used by attackers. Having a susceptible system open on the internet really will attract so many attacks that it is almost impossible to keep on top of all of them. Like stated in the chapter, it was hard for them to even take a screenshot for the honeypot logs because the page kept refreshing with new log entries. Leading attackers away from your real systems also helps distract them, which in turn helps the security of the production systems, albeit most likely just marginally.
I found section 10.5.2 to be particularly interesting in this week’s readings. When you think of a disaster in the work place, you don’t really think about how much of a liability is presented for as something as simple as the PC’s in the office. It is essential for all data to be backed up, to have appropriate IT staff to quickly replace damaged/stolen laptops, and to have an adequate back-up worksite in case an office suffers serious damage. Reading this section reminded me of my own organizations experience with Covid. Many employees did work from home occasionally, but most were in-office everyday at their desktop PCs. When Covid started introducing itself as a serious threat, the daily environment of my organization had to change immediately. Several laptops had to be purchased & configured so that employees who did not typically work from home now had that ability. It was a grueling task, and really not one that anybody was ready for.
This chapter examines security incidents of different severity levels and appropriate enterprise responses. Incident severities are divided into four categories: false alarms, minor incidents, major incidents, and disasters. The process of responding to a major incident intrusion response has three priorities: detection, analysis and escalation.
The IDS might alert the company of the attack, the IT security staff would get a report, they would need to respond to the call, and then proceed to analyze the intrusion to understand the situation. If it is a major matter, it must be escalated to the CSIRT or Business Continuity Team. The next step is to prevent further damage from occurring, and the fundamental method of control is to disconnect the server from the local network. Once the attack is contained, companies need to prepare for the recovery phase, which can also be repaired while the computer is running. If the data is lost, the company needs to restore the program Soviet-Russian data files from the backup tapes. Companies also need to apologize to customers, employees, admit responsibility and harm. Also, need to punish employees for ignoring intrusions. Most important is that in the event of a major natural disaster, all business continuity management principles will be people-centred.
Hi Yangyuan,
I think it’s important that you highlighted the three major priorities of responding to an incident intrusion, those being detection, analysis, and escalation. I agree that companies need to take accountability when they don’t follow the proper steps to protecting their customer’s data. Having a good response planned out beforehand is the best way to protect and minimize damage from a potential attack.
I enjoyed reading about ways to contain intrusions as part of the incident response process from the chapter 10 reading. The first topic mentioned and the most common method I’ve seen used was disconnecting the infected server(s). Disconnecting the server from the local network can bring the intrusion to a halt but this will impact the availability of systems/applications running on the server for use by legitimate users. Black holing an attacker involves blocking the IP address of an attacker(s) and was something I hadn’t heard of previously. This seems like a solid containment strategy if you want keep the systems and applications running on the infected server available but sophisticated attackers can likely find holes in this method. The final method involves prolonging the intrusion to observe what the attacker is doing.
The important thing is containment of the issue and the isolation of the affected networks which may be a radical method of containing the situation. Although disconnection stops the intrusions and making sure the server is completely unavailable for further attacks and by escalating the situation for the Response team for a quick approach to mitigate the situation.
A business continuity plan specifies how a company plans to maintain or restore core business operations when disasters occur. I think the most important part of it is testing the plan. Once a business continuity plan is developed, using input from a wide variety of departments
and external business partners, the company must test the plan. As noted earlier in this chapter,
both walkthroughs (table-top exercises) and live tests are useful. Testing is more difficult
for business continuity disasters than for major security incidents because disasters have much
broader impact and involve so many people.
The company must update the plan frequently because business conditions change constantly
and because businesses reorganize constantly. During a crisis is a bad time to wonder who must
take over responsibilities assigned to a department that no longer exists. It is an even worse time
to discover that your plan does not cover new business activities. Telephone numbers and other
contact specifics change even more rapidly than other factors and should have monthly updates.
All of this updating requires a small permanent staff for business continuity. The staff will
also act as the operational manager during a disaster.
The maintenance of business continuity plans is the hardest part of this exercise. Given the competing priorities and issues facing security teams, updating these documents can be pushed to the back burner. It’s important that firms remain diligent in these efforts, as an outdated phone list can have serious implications for effective crisis communications.
The following quote reminds me of this situation “We don’t rise to the level of our expectations; we fall to the level of our training.” Creating a business continuity plan, but failing to maintain it, creates an unreasonable expectation to be carried out by people without the appropriate training.
Business continuity planning (BCP) ensures that your business can bounce back from a natural disaster, cyberattack, or other form of natural disaster. Organizations are required to have a BCP solution which would allow for a quick return to normal business operations as quickly as possible.
Hey Oluwaseun,
Good point about returning to normal business having to be quick, when it comes to an operation being down, the longer the outage the more damage to the business
In chapter 10 Boyle and Panko discussed Incident Response and Data Recovery. I found the sections dealing with communications to be interesting, specifically how to apologize during an incident and communicate during business continuity management. The outline provided for apologies (i.e. acknowledge responsibility, explain what happened, and explain corrective actions) is good advice for general communications around technology. It’s important to practice this skill as there will certainly be a time when we will be dealing with an incident and need to communicate the issue to stakeholders.
For business continuity management, communications need to be resilient and provide redundancy. This section focused more on the means for communicating over the content. Examples such as phone trees were discussed as a means to relay important communications to stakeholders should primary systems fail.
Ensuring the right people have the information they need is one of the most important aspects of responding to incidents and interruptions to business operations.
I agree with you and the point here is to apologize at the right when the attack has caused harm to customers or employees. But the unfortunate situation about the aftermath apology on the leaks of personal information and other damaging incidents are filled hedging and waffling.
The key takeaway from this reading is the process for managing major incidents and the relationship between business continuity planning and disaster recovery. The timely response after knowing an incident has occurred, then analyze by understand the event and potential damages and escalation of major incidents to management and stakeholders and alert the response team to contain the situation about the threat or attack. However, It is essential for organization to have Incident Response System to handle and identify common threats and attack by alert sensor put in place and logging the logs captured.
Organizations have to plan ahead with details on how they will handle and respond to major incident and disasters. Disasters can include natural events such as earthquake or hurricanes, equipment failure, cyber-attacks.
Business Continuity Planning which is the required blueprint with detailed scope of action and consists of the “plan of action”. at the time of disaster and to help restore core business operations when disasters occur.
Hi Oluwaseun,
IT disaster recovery is critical to successful business continuity. Companies respond quickly to disasters and reduce losses by restoring operations through IT DRP.
IT DRP includes: Critical IT assets and their maximum allowed outage time; Tools or technologies that should be used for recovery; Emergency procedures; Disaster recovery team and their contact information
Hi Oluwaseun,
Good post explaining the difference between business continuity and disaster recovery. You are definitely right that organization must come up with a plan in their system security plan that will respond quickly to disaster and keep the system going or back to normal after that minor/major incident.
This chapter talks about business continuity and disaster recovery plan. It explains how important it is to secure a server/have a backup plan to keep the business going even after a major break up. Breaches or incidents are not only the responsibility of IT but the responsibility of all people starting from senior managers to all other employees. There are three type of incidents that Boyle elaborates such as false alarms, minor and major incidents. He explained that false alarms are incidents that deemed to be innocents and the attacker action could be similar to any actions that an employee, system administrator or manager routinely take in their work. In that case Intrusion Detection System helps in detecting suspicious activity.
I would say there is no such an innocent incident because this incident we call innocent can turn out to have a major impact if no actions are taken to stop it. In this sense, a company must plan to have real live test situation that can help them get prepared and facing the real situation in case an unplanned incident happen. Having the right information on who to call or reach out too if anybody sees any suspicious activities in the system is also a good communication plan as well.
Hi Ornella,
I think that it depends on the type of incident that occurs. Since the incidents can be categorized based on the impact that happens. I agree that the company should plan regardless – especially for “innocent” incidents. Often insider threats are caused indirectly from employees such as data leaks or misconfiguration. When these events occur, they should be documented and noted in order to prepare for possibilities next time and can be used to refine incident response. Furthermore, I remember Professor Lanter talking about this before in a previous class about professionals that cut corners. Even though cutting corners can often lead to work productivity, they should be noted because if you can do it – so can somebody else. And this occurrence could make professionals more aware of what someone else could do.
Chapter 10 Incident and Disaster Response
An interesting point made in this readings was about Accuracy and Planning. It spoke about the danger of someone responding too hastily to an incident and taking steps before having a solid understanding of the problem. This jumps out to me because I find it to be true in Technology issues in general and not just when it comes to a security breach of some kind. Several times over the years I have found myself guilty of responding too hastily when trying to resolve an issue, nothing is worse than working on an issue for a long period of time only to find out later the solution would have taken less then half the time if you were not rushing.
The planning part is a great point as explained in the reading that the best way to respond quickly and accordingly is to plan ahead, to me this speaks to everything we are learning in this program, its best to have the proper controls/policies/plans in place so that we are prepared when something does take place.
Hi Jason,
I totally agree with you and yes it has happened to all of us before that we like to rush when we are facing a situation we put ourselves to. Taking the time to plan is actually what we are supposed to do but sometimes when you are stressed out you don’t really think too much. Same like information security. The issue is just in front of you but you are focusing on something else because you did not take the time to understand and end up fixing a different issue rather than the one you had in the first place.
This chapter addressed the appropriate corporate responses to both traditional security incidents and disasters. The following stages were discussed in detail: detection, analysis, escalation, containment, recovery, apology, punishment, and postmortem evaluation. This is relevant to all companies considering even businesses with “good security” need to be prepared to handle security incidents, breaches, or compromises. Nevertheless, I will admit that I was surprised to see “Apology” being its own stage; I figured many places would overlook this step. However, after reading into it, I understand why explaining the incident, acknowledging responsibility and harm, and explaining what actions will be taken to compensate the victims would be beneficial, especially after leaks of PII. Downplaying the severity of the incident can cause even more anger and frustration; with that being said, it is in the company’s best interest to be transparent.
Hello Elizabeth, I like when you said; “even businesses with “good security” need to be prepared to handle security incidents, breaches, or compromises.” Something we have been routinely reminded about when studying cyber security is that there is no such thing as being 100% secure. Moreover, I agree with what you said about organizations that have been compromised in a security breech needing to be more transparent. This is not usually the case! Case studies we have read and some details from our ‘in the news’ articles show a pattern that organizations lack accountability for their part in the security breaches they have experienced. I am usually shocked by how they try to keep it under wraps or downplay the reality and severity of the hacks they have allowed to succeed.
This chapter is the last chapter of “Corporate Computer Security” book which introduced 3 phases of computer security for a business including plan, protect, and response phases. Of course, this chapter discussed response phase to both traditional security incidents and disasters. The incident response process included these steps; detection, analysis, escalation, containment, recovery, apology, punishment, and postmortern evaluation. The first 3-steps are priorities at the beginning of incident. However, after the first 3-steps, the others can include in the process especially containment.
Hi Hang,
Good post detailing what the last chapter looks like. How can you explain or tell us a difference between a disaster recovery and a business continuity ?
During this chapter’s reading I actually took interest in the apology portion of this chapter. Mainly because this topic comes up a lot during a lot of news research with companies being attacked and how they commonly seem to fail to admit that the fault lies on the company for being breached. Especially since many companies collect so much personal data on virtually anybody that visits their site. Commonly, especially demonstrated within both Case Studies, is that breaches can be prevented with better communication from CSIRTs. Many of the times downplaying or writing off the incident as an everyday occurrence is extremely frustrating, especially to those affected. Not only could this affect someone’s financial situation or personal information leaked, but the cost of time to resume normal daily life is a thing. It’s very easy for a Publics Relation Manager to view the damage from impact levels, but from the individual’s perspective the impact is much higher than the companies since they don’t have access to the same resources. And this type of response can aggregate impact if multiple individuals raise their voices, and tarnish company reputation further beyond the impact of the original technicality.
This chapter provides information on the incident, disaster response, and recovery concepts and gives the details of false alarms, and minor and major incidents. It is helpful to understand speed accuracy, planning, rehearsal, and occasional live test processes. To detect various attacks in the initial step using the IDS/IPS devices which generate the alert for the system/security administrator whenever suspicious activity is detected. It gives solutions when incidents are detected, such as disconnecting the server from the local network or disconnecting the internet connections, this is useful to disconnect the attacker completely from the server but it also directly affects legitimate users and business continuity.
If an incident has occurred, then it is best to start the recovery stage when ensuring that the server is running perfectly for business continuity operation. However, it is best to first very carefully identify the backdoor rootkits, Trojan horses registry entries, etc. which are hidden in the system, and that itself can be a big threat to business operations. Once the system operation and hidden malicious programs are cleaned, then the restoration process from the last update backup to continuing operation earlier can continue.
This chapter talks about the apology process in the condition of customers or employees who are the cause of the attack. It is imperative to first acknowledge responsibility and harm, explain what happened, and also explain what action will be taken to compensate. This chapter gives details information on criminal versus civil laws, laws are changed based on government area jurisdiction and international laws. If any major attacks occurred, then computer forensics and evidence collection are important steps, where so much evidence can be collected such as the live system where the attack perform, IDS/IPS log, system log, router log, firewall log, and more which is useful to collect the evidence to capture the attack footprint.
I found section 10.5.2 on office PCs in disaster recovery to be interesting. Even if an organization strictly uses laptops, they must be prepared for the possibility of losing those laptops in the event of a disaster such as a fire. Data should be backed up and agreements for replacement hardware should be in place for a swift recovery. A stand-in physical location should be considered ahead of time as well. Hotels with an internet connection can be a great option but the security of the hotel network should be considered.
Utilizing cloud storage is a great option to mitigate the risk of data loss in the event of a disaster. My company holds thousands of licenses to Microsoft products so we use One Drive to backup our data to the cloud. While users aren’t required to use One Drive it’s strongly recommended to ensure data on our local devices aren’t lost in the event of a disaster.
Hello Amelia and Bryan,
I agree that backing up data is an imperative task in a disaster recovery plan. I find it interesting that Bryan mentioned one drive. We also encourage our end users at Jefferson Health to save all of their important data on one drive! However, I have been seeing a lot of news articles about how most companies have more than 90% of their assets (data) stored in the cloud. Due to that, it is imperative that these cloud services are as secure as possible and the resources stored on them are readily available to the end users who actually need them to do their job.
In this week’s Boyle and Panko’s reading of chapter 8, we learned about incident and disaster response. One of the units in this chapter is (10.2 The Intrusion Response Process For Major Incidents). I appreciated the insight they provided in that unit about Detection, Analysis, and Escalation. According to the chapter, there are many ways to detect an intrusion. Moreover, it is in an organization’s best interest to first (quickly) learn that the incident has occurred. Following that, the second step would be to, “understand the incident to be sure that it is a real event, to determine its damage potential, and to gather information needed to begin planning for containment and recovery. This is analysis.” The third step would be to handle the incident with the on-duty staff or escalate handling to the CSIRT (Computer Security Incident Response Team) or business continuity team. The chapter further continues by giving an outline of containment. Containment consists of disconnecting a server from the local network, black-holing the attacker or continuing to collect data. I thought this was a very insightful part of the chapter.
In this chapter, we learned about the intrusion detect systems, the BCP, and the necessity of backups. The key point of the incident and disaster chapter I thought was important was the three priorities at the start of an incident. Detection, analysis, and escalation. There are a ton of ways to detect an incident, an alarm, an IDS, or even a phone call. Analysis, a security analyst must gage the situation and understand if there is a security problem, equipment issue or potentially a software issue. Once determined, the analyst can figure out how to proceed. Lastly, escalation, once determined there is a security incident, it must be escalated to the CSIRT or business continuity team.
In previous chapters, we discussed the planning and protection options and how they can eliminate incidents. However, in reality, organizations should focus on post incidents options as well such as disaster recovery and business continuity. . It is important that we always take the risk remaining into consideration. While thinking about what to do after an incident happens, Boyle believes that incident severity is critical to recovery. False alarms (innocent activities), minor incidents (true breaches), major incidents (high impact), and disasters are the severity levels from less severe to the most.
The one thing I learned from this chapter was CSIRT which is designed as computer security incident response team to deal with major incidents when it is too much for regular IT staff. In the recovery process, speed is critical. First, we don’t want bad actors’ access remaining for a long time in our systems, second, every minute our system is down, it cost us money and availability issues.
I found the section on honeypots to be the most interesting. Using honeypots to lure in and distract attackers is a useful way into finding more about the motives and tools that are being used by attackers. Having a susceptible system open on the internet really will attract so many attacks that it is almost impossible to keep on top of all of them. Like stated in the chapter, it was hard for them to even take a screenshot for the honeypot logs because the page kept refreshing with new log entries. Leading attackers away from your real systems also helps distract them, which in turn helps the security of the production systems, albeit most likely just marginally.
I found section 10.5.2 to be particularly interesting in this week’s readings. When you think of a disaster in the work place, you don’t really think about how much of a liability is presented for as something as simple as the PC’s in the office. It is essential for all data to be backed up, to have appropriate IT staff to quickly replace damaged/stolen laptops, and to have an adequate back-up worksite in case an office suffers serious damage. Reading this section reminded me of my own organizations experience with Covid. Many employees did work from home occasionally, but most were in-office everyday at their desktop PCs. When Covid started introducing itself as a serious threat, the daily environment of my organization had to change immediately. Several laptops had to be purchased & configured so that employees who did not typically work from home now had that ability. It was a grueling task, and really not one that anybody was ready for.