3 years ago


  • Text
  • Fastener
  • Fasteners
  • Products
  • Diameter
  • Pins
  • Distributors
  • Manufacturing
  • Industrial
  • Rivet
  • Screws
Distributor's Link Magazine Summer 2018 / Vol 41 No3


150 THE DISTRIBUTOR’S LINK BRYCE AUSTIN WHAT IS MY PLAYBOOK IF I HAVE A CYBERSECURITY INCIDENT? from page 86 Doing so took extra time and might have led them to miss obvious steps. ¤ The company did not have documents outlining how to bring operations back online if the hack had been successful, nor did they have procedures to follow if it was determined that any sensitive data had been stolen. ¤ Their IT services vendor wasn’t well trained in how to get to the bottom of the technical issues quickly, which lengthened the incident by hours. ¤ The client didn’t have a list of whom to call if a cybersecurity incident was suspected, which made the phone number to their cybersecurity advisor the only number they thought to use. What if he was unavailable when this took place? In a nutshell, they didn’t have their act together, and it showed. After an incident occurs, your company will be judged on the following criteria: [1] Before the incident, did your company take all actions to prevent the incident that one would expect of a prudent organization? [2] Did your company respond to the incident using procedures that one would expect of a prudent organization? [3] Are there any ways that the media could portray your actions around steps 1 and 2 to make your company appear to be culpable or incompetent? If true, expect that they will. It attracts more readers to their publication. A robust playbook that includes the CEO, Chief Legal Counsel, and all other senior leaders will do immeasurable good in your ability to respond to an incident. An incident response playbook needs several key elements to be effective. It must: ¤ Identify who in your organization has the authority to declare a cybersecurity incident. Who can initiate the playbook? ¤ Spell out how much money that person can authorize to be spent to have an incident investigated or remediated. ¤ Have a list of the types of scenarios that it is designed to cover. Examples include the loss of sensitive data, a ransomware attack, the loss of a critical system, natural disasters, law enforcement contacting your organization about a warrant or subpoena, and the loss of the use of one or more of your sites due to a natural disaster or because of other issues (such as a crime taking place in the building and the police barring your employees from entering the premises). ¤ Have a call tree that includes which people or groups to call when an incident takes place. ¤ Define the people or groups responsible for making the decision on when to bring in law enforcement. ¤ List the people authorized to speak to the media about a cybersecurity incident, and what those who are not authorized to speak to the media should say if they are approached by a reporter. ¤ List all of your critical systems, the location of the data in those critical systems, and the location of the backups of the data for those systems. ¤ Outline your general incident-response process. While every scenario is different, this process normally follows these steps: preparation, detection/analysis, containment, eradication, recovery, incident closure/rootcause analysis, and preventative measures. ¤ Be reviewed on a frequent basis. These plans get stale quickly, and need to be reviewed whenever a significant change in your organization takes place. If the above points are reviewed as a group, an interesting trend emerges. Most of them are nontechnical. The majority are operational and financial in nature. That is a critical misstep in many incident response plans. If your technology team manages your incident response plan, they are making business and financial decisions that should be made by CEOs and COOs and CFOs and legal counsel. Above all, your incident response plan needs to be tested. Unless you have rehearsed an incident response procedure, you’re only able to guess if it will work. This is too important to be left to guesses. The takeaway messages from this article are easy to list: ¤ Your company needs an incident response playbook. ¤ The incident response playbook should be owned by a non-technical member of your executive team. ¤ Your company needs to periodically test your incident response capabilities. ¤ Your company needs to update the playbook from lessons learned as a result of tests, whenever significant changes occur to the operational or technical aspects of the company, or when merger/acquisition activity occurs. Questions to explore this topic further with your company’s leaders: [1] How do we test our incident response playbook? [2] How often do we test it? [3] What did we learn from our last test? BRYCE AUSTIN



OPTION 1: Click on the share tab above, or OPTION 2: Click on the icon (far right of toolbar) and then click on the icon (top right of the page).

Copyright © Distributor's Link, Inc. All Rights Reserved | Privacy Policy