Employee Data Security Training: Tabletop Exercises

data security training, tabletop exercise, cyber security tabletop exercise, incident response plan

Learn how to prepare for a data breach by conducting drills, exercises, and trainings. 

david ellis, tabletop exercises, data security training, cyber security tabletop exercise, incident response plan, employee training
David Ellis
SVP, Investigations
Massive data breaches—and their devastating aftermath—are increasing in frequency. Businesses have taken renewed interest in planning for inevitable attacks on, and possible breaches of, their cardholder data environment. In this post, we’ll cover best practices for holding “tabletop exercises” like drills, discussions, and trainings, to make sure your business is prepared and protected in the event of a breach.

In their Guide for Cybersecurity Event Recovery, The National Institute of Standards and Technology (NIST) states that your Incident Response Plan will have 6 phases:

    data security training, tabletop exercise, cyber security tabletop exercise, incident response plan
  1. Preparation
  2. Identification 
  3. Containment
  4. Eradication
  5. Recovery
  6. Lessons Learned

This article focuses on parts of Phase 1— “Preparation”— as it’s different from the other five phases. It is the foundation of your entire incident response plan. Technically, you should always be in Phase 1, by holding regular training, drills, and incident-response-plan review. You will perform the vast majority of your planning and work during phase 1. During this phase, you should:

  • Ensure your employees are properly trained regarding their incident response roles and responsibilities in the event of data breach.
  • Develop incident response drill scenarios and conduct mock data breaches, at least annually, to evaluate the effectiveness of your incident response plan.
  • Ensure that all aspects of your incident response plan (training, execution, hardware and software resources, etc.) are approved, funded, available, and inventoried, in advance.

Your response plan should be thoroughly written, explaining everyone’s roles and responsibilities in detail, and you should document to whom it is distributed as well as the dates they received training regarding their role(s). Then the plan must be tested in order to assure that your employees will perform as they were trained.  The more prepared your employees are, the less likely they’ll make critical mistakes in the event of an actual breach incident.

SEE ALSO: 5 Things Your Incident Response Plan Needs

Types of Cyber Security Training Exercises

The point of running security incident response exercises is to increase awareness, test training effectiveness, and start discussions. Everyday drills and exercises can be as short as 15 minutes; where large-scale coordinated drills can last up to a day or two.  Your annual training should include at least one large-scale drill, while smaller table-top drills may be conducted more frequently according to your company needs.

In a discussion-based table exercise, you and your staff discuss response roles in hypothetical situations. A discussion-based tabletop exercise is a great starting point because it doesn’t require extensive preparation or resources, while still testing your team’s understanding of their incident response roles to potential real-life scenarios without risk to your organization. However, this exercise doesn’t fully test your incident response plan or your team’s actual response actions.

In a simulation exercise, your team tests their incident responses through a live walk-through that has been highly choreographed and planned. This exercise allows participants to experience how events actually happen in semi-real time, helping your team better understand their roles. Simulation exercises require more time to plan and coordinate, while still not completely testing your team’s capabilities.

In parallel testing, your incident response team actually tests their incident response roles in a safe test environment.  Parallel testing is the most realistic simulation possible and provides your team with the best feedback about their roles. However, parallel testing is more expensive
and requires more time planning than other exercise because you need to simulate an actual production environment (e.g., segregated systems, networks).

Data Security Training Tips

data security training, tabletop exercise, cyber security tabletop exercise, incident response plan
Before running through your exercises, consider these questions:

  • Have your security policies and incident response plan been approved by appropriate management?
  • Has everyone been trained on your security policies?
  • Does the Incident Response Team understand their roles, including making any required notifications?
  • Are all Incident Response Team members prepared to participate in mock drills?

When designing your tabletop exercise, prepare the following exercise information:

  • A facilitator guide that documents your exercise’s purpose, scope, objective, and scenario
  • A list of questions to address your exercise’s objectives
  • A participant briefing that includes the exercise agenda and logistics information
  • A participant guide that includes the same information as the facilitator guide, without the facilitator guide questions (or it may include a shorter list of questions designed to prepare participants)
  • An after-action report that documents the evaluations, observations, and lessons learned from your tabletop exercise staff

As you conduct your exercises, keep an eye out for a few things:

Task Timing:  Note how long certain tasks and operations seem to take under pressure. How long does it take to disconnect all of your potentially affected systems from the internet? How quickly can the team get a formal statement together? How quickly can they pull together a list of affected customers? If you do experience a data breach, there may be requirements for how soon you need to report it—especially if the suspected breach includes either HIPAA or PCI data.

Increased Volume:  You should test the ability of departments (like your call center, IT department, website, etc.) to expand and meet the demands of a data breach’s aftermath. Can your IT team handle an increase in internal requests? How many customer support calls can you realistically handle? Who will deal with the increase in customer questions on your website or your social media accounts?

Snags in the Plan:  Expect that some things may not go as planned.  This is not a cause for panic, as discovering issues that you were not prepared for is one of the primary reasons for conducting mock breach exercises.  Simply watch out for anomalies, note them, and address them either during the course of the mock exercise, or through the after-action process. This will also help you to develop contingency plans and alternative action scenarios. For instance, if someone plays a critical role in the incident response plan but happens to be out of office that day, what will you do?

After conducting a mock data breach exercise, be sure to set up a debrief meeting to discuss response successes and weaknesses. Your team’s input will help you know where and how to make necessary revisions to your incident response plan and training processes.


A Different Kind of Prevention

While it would be great to be able to prevent each and every data breach before it happens, in today’s world it’s often just not possible. While you still need to take all appropriate security measures and comply with all PCI and/or HIPAA requirements, it’s important to keep a “not if, but when” mindset when creating your incident response plan—remember, the designers of the Titanic didn’t think that it could sink. These exercises are an important part of your company’s security habit, and are intended to test your response plan, increase confidence, identify related strengths and weaknesses, and decrease collateral damage.

David Ellis (GCIH, QSA, PFI, CISSP) is Director of Forensic Investigations at SecurityMetrics with over 25 years of law enforcement and investigative experience. Check out his other blog posts.

2017 HIPAA Survey Results

Find out how organizations did with HIPAA compliance in 2017. 

hipaa, hipaa guide, hipaa compliance, hipaa compliance manualIn 2017, we conducted 4 surveys of over 300 healthcare professionals from organizations of all sizes, primarily from those with less than 500 employees. We included the results in our 2018 Guide to HIPAA Compliance. Data from these surveys can help security experts and practices alike decide on which areas to focus their HIPAA resources.

So how did organizations do with HIPAA compliance in 2017? Here are the results along with major takeaways to help you with your own HIPAA compliance efforts:

Physical Security

When it came to the physical security of HIPAA-compliant data in 2017, at least 20% of respondents reported that their organizations did not use automatic timeouts or log outs on workstations. Also notable was the fact that at least 20% of respondents reported their organizations did not encrypt stored electronic protected health information. Organizations did well in the area of providing unique ID credentials for each employee—with 94% reporting that they followed this requirement. 


  • Yes: 78%
  • No: 20%
  • Don't know: 2%

Takeaway: All workstations need to have an automated timeout/log out (i.e., a password-protected screensaver enabled after a time of disuse.


  • Have unique ID credential: 94%
  • Share credentials: 6%

Takeaway: All employees should have their own login IDs and passwords for computer, software, and physical access.


  • Yes: 78%
  • No: 20%
  • Don’t know: 2%

Takeaway: If you store any ePHI, you need to make sure that it has been properly encrypted (e.g., using AES-256 encryption).

HIPAA Firewalls

Network firewalls (both physical and virtual) are vital to HIPAA compliance. 31% of our respondents reported using both. Most organizations we surveyed opted for a managed firewall—a move that can help practices with large or complex networks.


  • Hardware firewall: 20% 
  • Software firewall: 18%
  • Both: 31%
  • Don’t know: 31%

Takeaway: All networks (whether small or large) need both a hardware and software firewall.


  • Third party vendor: 74%
  • In-house security professional: 10%
  • Don’t know: 16%%

Takeaway: Though not required, managed firewall(s) can help organizations with complex firewall rules and firewall management.


  • At least weekly: 13%
  • At least monthly: 16%
  • At least quarterly: 16%
  • At least yearly: 10%
  • Don’t know: 45% 

Takeaway: A security professional should regularly review your firewall rules (e.g., at least quarterly).


  • Yes, a third-party vendor: 70%
  • Yes, in-house security professional: 12%
  • No-one: 8%
  • Don't know: 10%

Takeaway: HIPAA requires that organizations enable logging and log alerting on critical systems (e.g., un-authorized connection attempt).

hipaa, hipaa guide, hipaa compliance

  • Employees: 36%
  • Another healthcare entity: 2%
  • Third party vendor: 26%
  • Don't allow remote access: 29%
  • Don’t know: 7%

Takeaway: If you use remote access, make sure to implement adequate security, such as multi-factor authentication and proper firewall configuration.


  • Yes: 26%
  • No: 40%
  • Don’t know: 34%

Takeaway: If you use remote access, make sure to implement adequate security, such as multi-factor authentication.

Penetration Testing

This type of white-hat hacking is one of the best ways to find network vulnerabilities. Organizations should make sure that pen testers are qualified and vetted, and should perform a variety of penetration tests—to help prevent wasting time and money.


  • Yes: 26%
  • No: 16%
  • Don’t know: 58%

Takeaway: To protect against cyber-attacks, penetration testing is vital to network security.


  • In-house security professional: 2%
  • Third-party vendor: 22%
  • Don't perform penetration tests: 10%
  • Don’t know: 66%

Takeaway: Whether a penetration test is performed by an in-house security professional or third-party vendor, make sure they are qualified.


  • Every other year: 2%
  • Annually: 6%
  • Yearly and after major network changes: 4%
  • After major network changes: 2%
  • Never: 8%
  • Don’t know: 78%

Takeaway: Organizations should regularly perform penetration tests (e.g., yearly).


  • Network penetration test: 10%
  • Segmentation check: 0%
  • Application penetration test: 0%
  • Wireless penetration test: 0%
  • Social engineering assessment: 0%
  • Don't perform penetration tests: 12%
  • Don't know: 78%

Takeaway: Organizations should perform a variety of penetration tests to confirm their network security.

HIPAA Security Tips

Here are a few things to keep in mind for HIPAA compliance:

  • Train employees at least quarterly: if you have an IT team, let them participate in a few trainings to help familiarize all employees and staff with HIPAA compliance and PHI security
  • Get expert help: it’s a good idea to consult HIPAA Compliance and Security Assessors and other security experts to help your organization with areas of concern
  • Do security testing: hire penetration testers and ethical social engineers to test your systems and your employees 

Need help with HIPAA? Check out our 2018 Guide to HIPAA Compliance and contact us with any questions.

Security Bulletin: Meltdown and Spectre Vulnerabilities

vulnerabilities, cpu bug, meltdown, spectre, intel chip

Learn about Meltdown and Spectre Vulnerabilities and what you should do.

Gary Glover
SVP, Assessments
By now you've probably heard about "Meltdown" and "Spectre," hardware bugs that can exploit vulnerabilities in modern microprocessors (also called central processing units or CPUs).

Meltdown and Spectre are possible due to design flaws in several modern CPU architectures. These bugs were first presented in scientific papers, and then announced publicly on the Google Project Zero blog on January 3, 2018.

vulnerabilities, cpu bug, meltdown, spectre, intel chipAccording to researchers, Meltdown can "melt" security boundaries by breaking the mechanism that keeps applications from accessing arbitrary system memory—which could include things like passwords, card numbers, etc. Spectre works by breaking the isolation between different applications allowing an attacker to trick error-free programs, which follow best practices, into leaking their secrets.

What should you do?

Install updates and patches as they come from your OS and CPU manufacturers. Companies including Microsoft, Intel, and Google have been working around the clock to create patches for these vulnerabilities. Downloadable tools are being developed by various CPU manufacturers to detect the Meltdown and Spectre vulnerabilities; watch for them.

You can find a full list of links to the official security advisories of affected manufacturers and companies here.

We don't yet know if Meltdown or Spectre have been or are being abused in the wild, but now would be a good time to check for patches or updates available from your OS and CPU manufacturers. 

Learn more about Data Security Consulting.

Who discovered Spectre and Meltdown? 

Spectre was independently discovered and reported by two people:

  • Jann Horn (Google Project Zero)
  • Paul Kocher in collaboration with, in alphabetical order, Daniel Genkin (University of Pennsylvania and University of Maryland), Mike Hamburg (Rambus), Moritz Lipp (Graz University of Technology), and Yuval Yarom (University of Adelaide and Data61).

Meltdown was independently discovered and reported by three teams:

  • Jann Horn (Google Project Zero) 
  • Werner Haas, Thomas Prescher (Cyberus Technology)
  • Daniel Gruss, Moritz Lipp, Stefan Mangard, Michael Schwarz (Graz University of Technology).

Researchers have shared a video showing Meltdown in action.

For press inquiries, please call 801-995-6516.

Our Top 5 Most Popular Blog Posts of 2017

Learn about cybersecurity and get the top tips from each of our most popular 2017 posts.

It may be an understatement that 2017 was a big year for cybersecurity. From crippling ransomware, to massive data breaches like Equifax, to changes in the Payment Card Industry Data Security Standard (PCI DSS)--2017 brought some milestone changes.

We're starting out 2018 by reviewing our top 5 most popular blog posts from last year. What can we learn, and what tips are most important to remember as we begin a new year?

WannaCrypt Ransomware Attacks: What You Should Do

On May 12 of 2017, many organizations with Windows-running machines were attacked by WannaCrypt, also known as WannaCry. This attack affected individuals, businesses, and organizations in over 150 countries. Victims were told they could free their machines and files by paying the equivalent of US $300 in Bitcoin. The ransomware threatened to delete the files within 7 days if no payment was made.

Over 230,000 computers worldwide were crippled. Healthcare organizations in particular were affected by this ransomware, including many National Health Services hospitals in England.

The WannaCry worm was contained by British security researcher Marcus Hutchins (yes, that Marcus Hutchins.) The attack itself targeted outdated versions of Windows, and its spread was compounded by social engineering tactics like phishing emails which contained an infected Word document.

Top tips from this post:

-Keep all systems up to date. Watch for patches and stay informed about vulnerabilities.
-NEVER open an unexpected or unverified attachment in an email. If it looks like it might be malicious, it probably is.
-Don't pay ransoms to attackers. Instead, contact an expert.

WPA2 Security Flaw Puts Wireless Devices at Risk

On October 16, 2017, security researcher Mathy Vanhoef made public his discovery of a serious vulnerability, dubbed “KRACK.” This vulnerability lies within the current industry standard encryption protocol "Wi-Fi Protected Access II" (WPA2). WPA2 encrypts traffic on all modern Wi-Fi networks, so any device connected to Wi-Fi could be affected.

This vulnerability is serious, but we haven't yet seen symptoms of a KRACK attack "in the wild." This post directed readers to watch for and install updates and patches for affected devices. Android and Linux devices are most easily affected. Most versions of iOS and Windows are only vulnerable when using non-typical multicast communications on a wireless network.

Top tips from this post:

-Follow your manufacturer's patches, updates, and bulletins. Follow their directions. 
-Make sure you're always connected to your intended Wi-Fi network. Using Ethernet, cellular data, or a VPN will protect you from such an attack. 
-HTTPS websites provide an extra layer of encryption, so make sure to only send sensitive information over HTTPS websites (never HTTP). 

Are You Ready for PCI DSS 3.2?

The Payment Card Industry Security Standards Council (PCI SSC) announced PCI Data Security Standard (PCI DSS) version 3.2 on April 28, 2016. This latest version adds clarification, guidance as well as some new requirements to the standard. On February 1 of 2018, the changes in PCI DSS 3.2 will be considered requirements.

The new version includes a few new requirements specifically for service providers, additional guidance about multi-factor authentication and scoping, as well as new requirements for most of the SAQ categories

This popular post helped our readers understand the timeline of events surrounding the PCI DSS version 3.2, and gave a list of resources to help them study, prepare, and train employees if needed. 

Top tips from this post:

-PCI compliance involves many steps, details and technicalities, so it’s important to start as soon as possible with any changes you need to make in order to be compliant with PCI DSS 3.2. 
-Keeping up on the standard and its associated guidance/clarification will help you understand data security and clear up any previous confusion. 
-There are many resources and experts available to clarify the new version of the standard and to help you comply.

New 3.2 Requirements for Service Providers: What You Should Know 

Like the above post, this one clarified the changes that have come with PCI DSS 3.2, specifically the ones that affect service providers. And just like the entire 3.2 standard, the "service-provider-only" requirements are considered best practice until January 31, 2018, and become requirements starting February 1, 2018.

Service providers will need to fulfill new requirements including the following:

  • Maintain a documented description of cryptographic architectures.
  • Implement a timely detection and alerting process to identify failure of critical security control systems.
  • Establish responsibility for the protection of card-holder data and a PCI DSS compliance program
  • Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures.
  • Perform penetration testing on segmentation controls at least every 6 months and after any changes to segmentation controls/methods.

Top tips from this post:

-Make time your friend, not your enemy; if any of these new requirements apply to you, get started as soon as possible.
-Stay up to date on the PCI requirements to give yourself a leg up on future attacks. 

6 Phases in the Incident Response Plan

With so many serious data breaches, hacks, and discovered vulnerabilities in 2017, it follows that our readers are concerned with preparing for and mitigating possible data breaches at their own companies. There's a terrifying spectrum of possible consequences of a data breach, and businesses are right to seek guidance in their preparation for that possibility.

An incident response plan should be set up so that it will address a suspected data breach in a series of phases. Within each phase, there are specific areas that should be considered.

The incident response phases are:

  • Preparation
  • Identification
  • Containment
  • Eradication
  • Recovery
  • Lessons Learned

Your response plan should be well-documented, thoroughly explaining everyone’s roles and responsibilities.  Then the plan must be tested in order to assure that your employees will perform as they were trained.  The more prepared your employees are, the less likely they’ll make critical mistakes.

Top tips from this post: 

-An ounce of prevention is worth a pound of cure.
-PCI DSS requirement 12 calls for businesses to keep an incident response plan on file.
-Be prepared for a range of possibilities and make sure all employees and staff are on board.

New Year, Better Security

A New Year inevitably brings with it new resolutions. Using the takeaways and lessons from our 5 most popular posts, you can see what areas your company should pay special attention, as well as where resources will be best allocated.

Whether you're protecting patient data, complying with the PCI DSS, or just beefing up data security at your company, SecurityMetrics has a solution for you.

PCI Standards: Which PCI SAQ is Right for My Business?

George Mateaki
Security Analyst

Prove your payment card security to your bank through an SAQ.

PCI SAQ, SAQA PCI Self-Assessment Questionnaire (PCI SAQ) is a merchant’s statement of PCI compliance. It’s a way to show that you're taking the security measures needed to keep cardholder data secure at your business.

Each SAQ includes a list of security standards that businesses must review and follow. PCI SAQs vary in length. SAQ A is the shortest with just 22 questions, and the longest is SAQ D with 329 questions.

Determining which SAQ is appropriate for you

There are 9 different SAQs a merchant can choose from. How you process credit cards and handle cardholder data determines which SAQ your business needs to fill out. For example, if you don't have a storefront and all your products are sold online through a third party, you probably qualify for SAQ A or SAQ A-EP. If you do have a storefront that processes credit cards through the Internet and you also store customer credit card data, you're probably an SAQ D merchant.

SEE ALSO: Updating to PCI 3.2 SAQs: The Changes You Should Know

Ultimately, you must choose the SAQ that’s right for your processing environment, but generally speaking:

  • SAQ A is for e-commerce/mail/telephone-order (card-not-present) merchants that have fully outsourced all cardholder data functions. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
  • SAQ A-EP is for e-commerce-only merchants that use a third-party service provider to handle their card information and who have a website that doesn’t handle card data, but could impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
  • SAQ B is for merchants that use imprint machines and/or standalone, dial-out terminals, and have no electronic cardholder data transmission, processing, or storage. Not for e-commerce environments.
  • SAQ B-IP Merchants using only standalone, PTS-approved payment terminals with an IP connection to the payment processor, and that have no electronic cardholder data storage. Not for e-commerce environments.
  • SAQ C-VT is for merchants that use a virtual terminal on one computer dedicated solely to card processing. No electronic cardholder data storage. Not for e-commerce environments.
  • SAQ C is for any merchant with a payment application connected to the Internet, but with no electronic cardholder data storage.
  • SAQ P2PE is for merchants using approved point-to-point encryption (P2PE) devices, with no electronic card data storage. 
  • SAQ D for Merchants is for merchants that do not outsource their credit card processing or use a P2PE solution, and may store credit card data electronically. 
  • SAQ D for Service Providers is for service providers deemed eligible to complete an SAQ.

This table gives more detail about each of the PCI DSS 3.2 SAQ types:

Watch this video to learn what you should know before you begin filling out your PCI questionnaire.

Why is this a requirement?

The Self-Assessment Questionnaire isn’t just a roadmap to compliance; it’s a roadmap to better security. Filling out a PCI SAQ is the best way to make sure you aren’t missing any business security requirements. In addition, merchant processors don’t want to work with insecure businesses, so they typically require each merchant to provide a PCI SAQ as proof of payment security.


Remember that no matter your SAQ type, you're still required to follow ALL the PCI DSS standards. Doing so may require vulnerability scans, penetration tests, and/or audits.
George Mateaki (CISSP, CISA, QSA, PA-QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT.