computer

profilenecolas00073
1123461035.docx

Business Continuity Plan By

Contents Justification for Plan 4 Roles and Responsibilities 5 Canadian Delegation Employee Responsibilities 5 Incident Response Team Responsibilities 6 Security Personnel Responsibilities 7 Critical Systems 8 Normal Operations 8 Critical Functions 9 Communication in Email Outage 10 Email Server 10 File Servers 11 Canadian Government-owned User devices 11 Event Reactions 12 Ransomware Infection 12 Dedicated Denial of Service 13 Rogue Access Points 13 Business Continuity Checklist 15 IR Response Flow DDOS 17 IR Response Flow Insider Threat 18 References 19

Justification for Plan

In the event of a cyber event that drastically impacts the communication posture of the Canadian delegation is it necessary that a plan be developed to maintain critical functions of the delegation. Regardless of a dramatic cyber event, members of the delegation must be able to effectively communicate in at all times with each other and decision makers back inside the homeland. Failure to maintain this important function does not only jeopardizes the delegation located in the UK, but could also have serious consequences for the Canadian government as a whole. It is important to remember that adversaries may plot to disrupt communications for a variety of reasons ranging from a simple desire to embarrass the Canadian government to a goal of drastically infiltrating government communication systems to corrupt or exfiltrate data. In either event, efforts must be taken to prevent the adversary from realizing their goals while maintaining the functions of the government. In order to ensure that there is a roadmap in place to maintain critical functions of the mission a Business Continuity Plan (BCP) must be created. A BCP is not to be confused with a Disaster Recovery Plan, though the two are often used interchangeably. A BCP is a plan for how a business will maintain operations in the event of a disaster, while a Disaster Recovery Plan is an actual plan for disaster remediation (Kunthe, 2012). In this document aspects of each plan will be discussed, but the primary focus will be on the BCP portion of incident response.

Failure to properly secure the government security functions could have dramatic consequences for communication systems back inside Canada if the failure allows malicious actors to leverage vulnerabilities within the delegation communication network to execute a lateral move into primary Canadian government systems. This outcome must be avoided at all costs and may require the temporary shutdown of some systems, critical and non-critical, until the possibility of increased malicious actor access is eliminated. This proposal will focus on plans to maintain the communication abilities of the delegation. For the purposes of this plan, communication includes not only person-to-person communication between delegates within the UK and/or back to the homeland, but also includes communication between various devices on the Canadian delegation network. To that end, the list of critical systems will encompass a wide array of devices and shall not be limited to only include end user communication devices.

Roles and Responsibilities

With any plan the roles and responsibilities of all stakeholders must be clearly defined prior to the triggering incident. The clear communication of these roles and responsibilities, and appropriate corresponding education, will be key to the swift and efficient restoration of functions. To that end, this document clearly defines the roles of users within the network and their responsibilities within the Business Continuity Plan.

Canadian Delegation Employee Responsibilities

The majority of users will fall within the basic end user role. These are individuals who do not have administrator access within the network and do not fill a security and/or digital forensic role. An example would be a diplomat within the delegation who uses the communication network, but does not perform any administration or configuration within the network.

In the event of a critical event, it is the responsibility of these end users to maintain situational awareness and continue to adhere to previously outlined security practices and incorporate any additional guidance into their functions. These users must make every event to review bulletins put out by the Network Security Officer and/or other network security personnel. These users are not authorized to make any independent action in reaction to the event as doing so could exacerbate the situation (such as attempting to download a new anti-virus which is either disguised ransomware or conflicts with existing software).

End users within the delegation, not network related, will make every effort to contact immediate supervisors to receive their operational status update. In the event that the delegation network is down, users are authorized to use personal devices (within reason) to receive the update. Note that classification levels and the appropriate protections are not waived in the event of a critical event and still must be observed.

Incident Response Team Responsibilities

Immediately upon confirmation that a large scale cyber incident is taking place the Incident Response Plan will be initiated and an Incident Response Team will be formed. The roles and responsibilities within the team were previously outlined within a previous document and will not be explored in full here. For the sake of this document, all personnel conducting network analysis, diagnosis, and correction will be referred to as “Network Analyst” though their official titles will vary.

The Network Analyst will immediately upon discovery initiate a Situation Report (SITREP) to document the event and provide a document for other stakeholders to review. Documentation will continue throughout the entire course of the event. The Network Analyst will also contact appropriate security personnel to keep them appraised of the situation and if deemed necessary issue an alert to end-users providing situation awareness and/or event response guidance. Note that any notices to end-users will only include basic descriptions of the event, recommended or required end user actions, and/or estimated time to system restoration. Comprehensive reports of the situation will not be issued regarding the event until the full details are known and will be issued by security personnel.

The analyst will also make attempt to safeguard any critical systems (to be described further in the document) which are jeopardized by the event and immediately take any available steps to safeguard the systems. Critical Systems must be identified prior to any event (a non-comprehensive list is included with this document), so as to expedite the process of securing the systems. In the event a critical system is damaged by the event the analyst will immediately begin remediation efforts to bring the system back online. If a non-critical system is also affected the critical system will always take precedence.

The network analyst will document all discoveries and remediation steps (as previously stated). Additionally, the analyst will provide periodic updates to security personnel and senior leaders. Periodic updates to end users will be issued as necessary.

Security Personnel Responsibilities

Upon notification by the Incident Response Team, security personnel will open a file regarding the event and record any appropriate details. In the event of a ransomware attack information related to the ransom will be recorded and will document pertinent details to include the date/time ransom request was received, method of receipt (email, via malware infection, etc), amount of ransom, currency requested, recipient of funds (to include any banking information or crypto-currency wallets), and/or details failure to pay ransom. Note that this information should also have been recorded by the Incident Response Team. Once the information is documented security personnel will inform senior leaders of the situation from their perspective understanding that the Incident Response Team will also be reporting to senior leaders from their perspective.

It may be deemed necessary for a bulletin to be put out regarding full details of the event. If that case security personnel will draft the bulletin, minus technical details, and provide it to affected end users. Note that ever effort must be made to not reveal information which could reveals sources and methods, sensitive areas which may have been affected, and/or sensitive details of ongoing investigations. The bulletin should include all details needed for end users to be informed of incident and implement identified methods to safeguard systems, but not provide critical information to adversaries who may be launching an operation.

Critical Systems

As previously stated, critical systems take precedent when resolving the cyber incident as they are necessary to maintaining the core functions of organization operations (Gibson, 2015). In order to ascertain what systems should be designated as mission critical a review of the core duties and requirements of the mission must be conducted. In this scenario, the delegation must be able to communicate effectively (to carry out normal mission and coordinate incident response), while also accessing documents of importance. Those documents remaining uncorrupted and complete is also key as delegates operating under corrupted or intentionally altered data could have drastic consequences to the government operations. To that end, communication system components and document storage and retrieval mechanisms are most certainly mission-critical systems.

Normal Operations

In the normal operation of the network users should be permitted to send and receive emails with attachments as usual. There is already a method in place to PKI protect emails in order for recipients to verify that messages were received from authorized individuals. There is also rudimentary malware scanning of documents. The program that updates the anti-virus software sends patches to user machines on a periodic basis, though it requires the machine to be powered on to receive the update. If the machine is powered down the update will not be received until the next patch push in which the machine is powered on.

For users sharing files there are a few authorized means to send and/or receive files. As previously mentioned, users can send files via email attachments provided the classification of the document does not exceed the security requirements for this transmission method and the file is within the size restrictions for email attachments. Users can also send documents via a Dropbox type mechanism. In this method a user would navigate to the intended recipient’s dropbox and upload the file. Only the user who owns the dropbox (or those who have been given authorization by the owner), can download files stored there. This method is useful for files which exceed the size or classification restrictions for email. Finally, users can send each other the file path for the file so that the recipient can navigate to it within the network, provided they have the appropriate credentials.

In regard to typical communication, users can communicate via email, chat, phone or conference. A review of organization communication trends revealed that email is the most popular communication method, followed by chat, and calling. Conferencing was the least utilized communication method. Unfortunately, users were not asked to specify between mobile text messaging and online chat.

The entire system is backed up once a day to offsite servers in the event a system rollback is necessary. Unfortunately, any changes which were implemented after the last backup will be lost in the event of a rollback and may not be retrievable.

Critical Functions

In event of a crisis, Canadian officials are still obligated to carry out the functions of the delegation at the Summit. This includes relaying Canadian government objectives and positions to the international community. Additionally, security posture must be maintained to include the physical and cyber security of all Canadian owned and occupied locations. These are functions which cannot be dropped and as such all systems which facilitate the execution of these functions must be safeguarded prior to an event, and prioritized in the event an incident occurs. These systems would include communication systems and systems which facilitate file access/sharing.

Communication in Email Outage

In the event that an incident occurs which completely takes down all online communications methods users should be instructed to contact their immediate supervisor using a phone (assuming phone lines remain unaffected). Preferably the user would utilize a landline phone within the delegation spaces; however, if the option is not available the use of either government-issued or personally owned mobile devices are authorized so long as appropriate security practices are followed.

Within the office spaces the user of short range radios can be used for communication by critical personnel. Precedence will be given to individuals actively working to resolve the communications issue.

Email Server

Given the fact that the majority of communication for the delegation occurs via email, in the event email servers remain minimally affected users will communicate via that medium. An email should be sent to all users on the network (PKI protected) informing them of the ongoing issues and providing any steps which must be taken. If email is affected then, if necessary, a determination will be made which will result in critical personnel accounts being recovered first.

Network analysts will review the email servers to determine if there is any unauthorized access or if any user account displays anomalous behavior. Strange behavior on a user account could indicate unauthorized access which could potentially lead to further infections within the network. If such behavior is noted network administrators will make an executive decision as to whether or not to suspect account access in an abundance of caution. Additionally, analyst should review the possible benefits to restricting the account owners access to other areas in the network.

If at all possible, history email messages should also be retrieved from backups and or user person PST files. Access to historic data could be critical to decisions which must be made by delegation employees.

File Servers

Following communication between users, maintaining the integrity and security of files on the network is also key. A file server is a server that allows for the sharing of files across different devices on a network (Brunelli, 2016). In the event of a crisis critical files have to be retrievable by authorized users. To that end, a periodic cloud backup of file servers should be conducted in order to ensure that an uncorrupted version of files is stored offsite in the event anything occurs to the onsite file server. Additionally, periodic reviews of user authorizations on the network, to include areas users are allowed to access should be reviewed.

Following a crisis, the user access list currently in place should be compared to the documented list to determine if any changes have been implemented. Such a change could indicate malicious actor escalation of privileges. If such a change exists an authorization rollback should be conducted ahead of an examination of the discrepancy. If such a discrepancy does not exist then a review of files should be done to ascertain if documents stored on servers can be trusted. If widespread corruption or tampering is suspected then a rollback to the previously saved backup can be implemented.

Canadian Government-owned User devices

Mission critical end user devices should be completely backed upon a periodic basic on par with the backups of file servers. In the event of a crisis these machines can be rolled back to the last backup. Prior to rollback, the systems should be reviewed for unusual login activity or activity which is outside the normal parameters for the authorized user

Event Reactions

Part of an effective Incident Response Plan, Business Continuity Plan, or Disaster Response Plan, is determining what action will be taking in response to any identified threat. To this end, a series of responses have been compiled in the event of common cyber threats are encountered by the delegation.

Ransomware Infection

In the event of a ransomware infection, as previously stated, all information related to the incident will be recorded. The information should immediately be reported to the Canadian Cyber Incident Response Centre (CCIRC) which is responsible for reducing cyber risks to Canadian critical infrastructure and systems (Department of Public Safety and Emergency Preparedness , 2016). However, no ransom will be paid. Ransomware launched against government systems has a far greater implication then when launched against civilian systems and has been compared to terrorism (Zurkus, 2016). The Canadian government will not negotiate with such actors nor encourage such behavior by paying a requested ransom.

Ransomware attacks pose a few security threats. The primary threat, and the most noticeable, is the manipulation and/or corruption of files on a target system. This can be demonstrated by the encryption of files or the altering of programs on the machine to negatively affect its operation. Additionally, a user is unable to determine (without in-depth review of the network) if the malicious actor still has access to the victim machine. If so, then paying the ransom once could just result in another infection and follow-up ransom. Additionally, the ransom could be meant to distract from or hide other actions the malicious actor is taking on the machine. Users may be too concerned about the ransomware to notice that the actor is copying files out of the machine or changing account privileges.

Dedicated Denial of Service

In the event of a Dedicated Denial of Service (DDOS) attack the network administrator should carry out a few steps. First the router should be rate limited to protect the web server. Rate limiting is a process in which controls the amount of data which flows to and/or from a network (Key CDN, 2017). Filters can also be added to router security which informs the router to discard packs which originate from previously identified attack sources. Additionally, the router can be instructed to drop any packets which are malformed or duplicates. Finally, the network analysts can lower SYN, ICMP, and UDP flood drop thresholds (Rubens, 2016).

In the event that this does not solve the issue, DDOS attacks can last for 24 hours, then network administrators could take other methods. One option is to block all communications originating from a specific country. For example, the network administrators notice that the majority of calls are coming from China, then connections to China could be blocked to allow other packets through. This is a temporary fix, as a savvy cyber actor will switch to using proxies from another nation. Network administrators could also whitelist any typical connections and block all others. This would allow users who habitually use a system to gain access but would prevent new or periodic users from doing so. In the event of an event that triggers the BCP, this may be the best option as critical personnel would most likely be within the habitual user set and included in the whitelist (Buntinx, 2017).

Rogue Access Points

In order to discover and eliminate rogue access points, network administrators should maintain a list (both digital and hard-copy) of authorized access points (AP) within the network. Authorized access points being wireless access points that are put in place by company IT personnel and are the only devices approved to allow users access to the WLAN. The need for the hard-copy list is a precaution in the event of a hack in which malicious actors attempt to alter the digital copy of the AP list. The list of authorized APs should document official devices by both media access control (MAC) address and Service Set Identifier (SSID). This dual listing is required because of the possible existence of multiple WLANs within the delegation network.

In order to detect unauthorized AP, the Canadian delegation will employ both mobile and bundled wireless intrusion detection and prevention systems (WIDPS). These systems could detect APs which are not authorized to be on the network. Bundled WIDPS come bundled with an AP, so authorized APs can serve a dual purpose of providing access to the network and detecting unauthorized devices. Mobile WIDPS systems allow security personnel to walk the premises with the device and detect them on the go. This can be useful if an authorized AP is detected, but the exact physical location of the device is unknown. In this way, the bundled and mobile versions of the system can work in tandem, with one providing the initial detection and the second being used for location.

Business Continuity Checklist

· Validate the security incident

· Begin incident response documentation/reporting process

· Review network activity and/or log analysis to identify irregular data

· Identify data which may have been compromised

· In event of DDOS

· Identify possible source of DDOS

· Identify, if possible, the method of DDOS

· Identify, if possible, the source of the breach

· Assemble incident response team

· Assign Incident Response Manager

· Assign Security Analysts

· Assign Security Researchers

· Identify additional internal and external stakeholders

· Coordinate response communication workflow

· Determine status and scope of breach

· Ensure all portions of investigation and findings are documented

· Ensure preservation of all evidence discovered

· Determine if the breach is ongoing or if it is post-breach

· Identify all effected machines, data, or network components

· If breach is ongoing immediately take actions to prevent further data loss

· Block unauthorized access

· If necessary take isolate affected portions of network

· If necessary shutdown and/or remove affected network components

· If criminal activity is suspected notify law enforcement

· Take remediation efforts

· Take steps to remove any malicious files that may be present on affected machines

· In event of DDOS

· Take DDOS remediation steps

· If necessary create whitelist of routine network activity

· Carry out data recovery

· Utilize system backups

· Hash comparison should be utilized to ensure data remains uncorrupted

· Update relevant security patches

· Update anti-viruses, IDS, IPS, and other software to detect identified malicious activity to prevent reoccurrence

· Conduct interviews with key personnel

· If necessary, have Human Resources attend interviews

· Above is mandatory in case of suspected insider threat

· If criminal activity is suspected contact local law enforcement prior to interview

· Above is mandatory in case of suspected insider threat

· Inform stakeholders of findings of breach investigation

· Internal stakeholders should be informed first

· Notify external stakeholders if deemed necessary

Business Continuity Plan 1

Business Continuity Plan 18

IR Response Flow DDOS

Initial Detector

Report Security Incident

Incident Response Team

Manager

Inform Delegation of findings

Yes/no

Criminal act suspected?

Assemble Analysts and Researchers

Security Analyst

Implement DDOS remediation

Report findings to delegation

Investigate technical details of incident

Security Researcher

Report findings to delegation

Research incident info available openly

General Counsel

Inform parties of legalities, review statements

Law Enforcement

Conduct and oversee criminal investigation

Canadian Delegation

Inform external stakeholders of situation

IR Response Flow Insider Threat

Initial Detector

Report Security Incident

Incident Response Team

Manager

Inform Delegation of findings

Yes/no

Criminal act suspected?

Assemble Analysts and Researchers

Security Analyst

Report findings to delegation

Investigate technical details of incident

Security Researcher

Research incident info available openly

Report findings to delegation

Human Resources

yes

Remove Employee access

Wrong doing suspected?

Review Employee access

Create Employee incident file

General Counsel

Inform parties of legalities, review statements

Law Enforcement

Conduct and oversee criminal investigation

Canadian Delegation

Inform external stakeholders of situation

References Brunelli, M. (2016, June 8). What's the difference between a file server and a NAS device? Retrieved from Carbonite: https://www.carbonite.com/blog/article/2016/06/whats-the-difference-between-a-file-server-and-a-nas-device/ Buntinx, J. (2017, January 31). How Do I Stop A DDoS Attack? Retrieved from The Merkle: https://themerkle.com/how-do-i-stop-a-ddos-attack/ Department of Public Safety and Emergency Preparedness . (2016, May 4). Canadian Cyber Incident Response Centre (CCIRC). Retrieved from Department of Public Safety and Emergency Preparedness : https://www.publicsafety.gc.ca/cnt/ntnl-scrt/cbr-scrt/ccirc-ccric-en.aspx Gibson, D. (2015). Managing Risk in Information Systems. Burlington, MA: Jones & Bartlett Learning. Key CDN. (2017, April 26). What Is Rate Limiting? . Retrieved from Key CDN: https://www.keycdn.com/support/rate-limiting/ Kunthe, C. (2012, October 12). Difference between BCP and DR. Retrieved from ISACA: http://www.isaca.org/Groups/Professional-English/business-continuity-disaster-recovery-planning/Pages/ViewDiscussion.aspx?PostID=72 Rubens, P. (2016, January 26). 6 Tips for Fighting DDoS Attacks. Retrieved from eSecurity Planet: https://www.esecurityplanet.com/network-security/5-tips-for-fighting-ddos-attacks.html Zurkus, K. (2016, July 11). Why you shouldn't pay the ransomware fee. Retrieved from CSO Online: https://www.csoonline.com/article/3092278/backup-recovery/why-you-shouldnt-pay-the-ransomware-fee.html