5 Things Your Incident Response Plan Needs

Find out some of the essentials to include in your incident response plan.  

By: David Ellis
Director of Forensic Investigations
CISSP, QSA, PFI
Previously, we outlined 6 first-steps in creating an incident response plan:
  1. Identify and prioritize your assets
  2. Identify your potential risks
  3. Establish procedures
  4. Assemble a response team
  5. Sell your plan to the company decision-makers

incident response planWhen it comes to creating an incident response plan, it can seem a little overwhelming.  Breaking it down into smaller components can help relieve some of your stress by making the project more manageable.  Every business is different and will require different types of training, documents, policies, etc. that are tailored to your company’s specific needs. But there are a few things most businesses should include in their incident response plans.

A helpful way to organize your incident response plan is to have a series of itemized response lists. These are basically a series of “to-do” lists that provide needed information and tasks to perform during a data breach.

SEE ALSO: How to Manage a Data Breach: 5 Steps to Keep Your Business Safe
Here are 5 itemized response lists you’ll want in your incident response plan.

1.  Emergency contact/communications list

This list includes those that should be contacted in the event of a data breach. Those notifications could include:
  • Response team
  • Executive team
  • Legal team
  • Forensics company
  • Public Relations
  • Affected individuals
The list should contain information on how to reach these contacts, and what you need to say.  Pre-prepared emails and talking points can help communicate the issues more clearly and concisely, and could help you to stave off potentially bad press or other negative repercussions early in the event.


2.  System backup and recovery processes list

This list will help you deal with the technical side of a data breach. Here are some things that should be included:
  • Process for disconnecting from the Internet (Your processes need to state who is responsible to decide whether you disconnect or wait and see)
  • System configuration diagrams that include device descriptions, IP addresses, OS, etc.
  • Process for switching to redundant systems and preserving evidence
  • Steps to test the system backup and verify it hasn’t been compromised, and that it will not be affected by the suspected compromised systems
This list gives you quick steps to preserve any compromised data and to quickly handle the breach as well as preserving your systems through backups. This list is crucial to help your business from losing too much data in a breach and to return to business as quickly as possible.

3.  Forensics analysis list

incident responseThis list is for businesses that have in-house forensic investigations resources. Your team will need to know the areas where to look for strange behavior and have access to system security and event logs.  Some of the tools your team will need may include:
  • Data acquisition tools
  • Write-blockers
  • Clean/wiped USB hard drives
  • Cabling for all connections they could experience in your environment
  • Forensic analysis tools such as, EnCase, FTK, X-Ways, etc
If your business doesn’t have access to an experienced computer forensic examiner in-house, you will want to consider vetting a forensics firm in advance with pre-completed agreements. This helps ensure you get an experienced investigator when you need it.

SEE ALSO: What Does a Cyber Forensic Investigation Do and How Much Does It Cost?


4.  Jumpbag list

This is a list for grab-and-go responses. When responding to a breach quickly, have a list of overall actions your employees need to take right away. It keeps the plan organized and prevents mistakes caused by panic. Some things to include in this list are:
  • Incident handler’s journal to document the incident
  • Incident response team contact list
  • USB hard drives and write-blockers
  • USB multi-hub
  • Flashlight, pens, notebooks
  • All of the lists mentioned in this article
  • USB and/or DVD-ROM containing bootable versions of your OS
  • Computer tool kit
  • Forensic tools and software (if your company has the expertise to perform its own forensic investigations—if not, this is best left to professionals)

5.  Security policy review list

This list deals with the aftermath of the breach and the response to it. It essentially helps your organization analyze the breach and what you can learn from it. This list should include documentation of the following things:
  • When the breach was detected, by whom and what method
  • Scope of the incident/affected systems
  • Data that was put at-risk
  • How the breach was contained and eradicated
  • Work performed or changes made to systems during recovery
  • Areas where the response plan was effective
  • Areas that need improvement
You should look at where your security controls failed, and how to improve them. The purpose of this list is to document the entire incident, what was done, what worked, what didn’t, and what was learned.

Be prepared

You don’t want to have the mentality that you’re protected because you believe that a data breach won’t happen to you. Experiencing any data breach is harsh.  If you aren’t prepared in advance, the damaging affects of the breach will be more severe.  When you have an incident response plan (and rehearse it), should the worst happen, your employees and your business will be able to handle it.

Talk to us about getting a forensic examination!  

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.

SecurityMetrics Guide to PCI DSS Compliance
5 Tips to Boost Your Business’s Physical Security


Learn how you can improve your business’s physical security to protect your data.  

By: Michael Maughan

physical securityWhat’s the first thing you think of when you hear the word data security? You may think of firewallsencryption, or even vulnerability scanning. But do you also think of locked doors, security badges, or sign-in sheets?


Many businesses don’t often realize how physical security can help protect their card data. But there are many ways for data thieves to gain access, and several don’t involve a computer. Strengthening your physical security will keep hackers and social engineers from gaining the needed information to access and steal card data.

SEE ALSO: Physical Security: What You Aren’t Thinking About

Here are 5 tips ensure physical security gives adequate protection to guard against card data loss.

1. Keep an inventory of devices

More businesses are using mobile devices in their transactions. While convenient, it also brings some security issues. Theft of devices such as laptops, servers, etc., are often causes of data breaches.

Make sure you have a documented inventory of your devices that either carry or can connect to card data. Your business should be aware of where these devices are, who has them, whether they can leave your business environment, etc. And as always, card data storage should be encrypted.

This inventory can help you keep track of all your devices. Should someone walk out with something, keeping an inventory can help you quickly identify the stolen device, when it happened, the extent of what data was stolen, and what further actions should be taken.

2. Limit access to areas with sensitive info or equipment

Banks don’t just let everybody walk around their vaults.

Your business should treat your data like it’s very valuable, because it is.
That means rooms that have card data should only be accessed by employees that need it.

Make sure to give your employees only the amount of access that they need and nothing more. For example, your marketing supervisor may not need access to card data. Most data resides in a data center so make sure you can trust your service providers before you hand them all of your data.

3. Put together and document security policies

You’ll need to come up with a set of policies for your employees to handle physical security. Doing this will guard against intentional or unintentional data theft. Some things to consider in your policies include:
  • When doors are locked
  • Who is assigned what access
  • Which devices are to remain on premise always
  • Who oversees implementing security
  • Who has physical access to CDE server hardware and network gear
  • Password change policy (don’t write passwords down)
  • Procedures for reporting lost/stolen access card or badge
  • Visitor access procedures
It’s important to document these policies and procedures since having them on paper will clarify any questions your employees may have and mitigate liability should a breach occur. You’ll also want to update these policies regularly.

SEE ALSO: The Cost of a PCI Security Policy: What You Need to Know

4. Train employees

physical security best practicesPolicies and procedures alone won’t do your business much good if your employees aren’t following
them. One of the biggest causes of many data breaches is due to human error. All it takes is one employee forgetting to lock a door or a data center cabinet, or letting an unauthorized person into a restricted area for card data to get stolen.

Make sure to train your employees consistently on physical security. Show examples of proper and improper application of policies and procedures. Help employees understand the risk and liabilities involved in poor adherence to company policy.

Doing training just once when they join you and annually likely won’t be enough. It’s recommended that employees are trained quarterly, if not monthly.

SEE ALSO: Employee Data Security Training: What You Should Do

5. Don’t forget the smaller things

It’s one thing to make sure your doors are locked at night and everything is secure after hours, but what about during the day? Contrary to popular belief, a lot of data thefts happen in the middle of working hours, particularly when social engineers are involved. Consider the access that janitors and delivery persons have. It would be very easy for a social engineer to gain access to data by pretending to be an employee.

Social engineers are often very skilled at slipping into unauthorized areas unnoticed, and this is often due to employees overlooking smaller security details. Regardless of how friendly and innocent someone may be, you should adhere to policy to ensure data protection.

It’s crucial to not leave out smaller security details.  Installing privacy monitors on computers, having blinds in rooms with sensitive data, and documenting who comes in and out of your organization can go a long way to protecting card data.

It just takes one breach to ruin a business, so don’t be that business.

Need help in securing your data? Talk with our consultants!

Michael Maughan is a Security Analyst at SecurityMetrics and has been in IT for 18 years. He has a Bachelor of Science in Applied Physics from BYU and is an avid college sports fan.

SecurityMetrics Guide to PCI DSS Compliance
SAQ A-EP: The What and the How

 Learn what businesses qualify for SAQ A-EP. 

By: Michael Simpson
Principal Security Analyst
QSA, CISSP
SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.
Here are a few answered questions about SAQ A-EP.

Who qualifies for the SAQ A-EP?

Here’s what qualifies your business for the SAQ A-EP:
  • Your company accepts only e-commerce transactions;
  • All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor;
  • Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;
  • If merchant website is hosted by a third-party provider, the provider is validated to all applicable PCI DSS requirements (e.g., including PCI DSS Appendix A if the provider is a shared hosting provider);
  • Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSS compliant service provider(s);
  • Your company does not electronically store, process, or transmit any cardholder data on your systems or premises, but relies entirely on a third party(s) to handle all these functions;
  • Your company has confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant; and
  • Any cardholder data your company retains is on paper (for example, printed reports or receipts), and these documents are not received electronically.

What’s the difference between SAQ A and SAQ A-EP?

Many businesses are often confused with these two SAQs, and wonder if they’re the same thing. The two SAQs are very similar, in that both involve e-commerce merchants that outsource their card data to a third-party vendor. But there are a few differences.

The biggest difference between the two is SAQ A involves merchants that outsource all responsibility of their card data to third party, while SAQ A-EP involves merchants that don’t receive cardholder data, but control how cardholder data is redirected to a PCI DSS validated third-party payment processor.

If a merchant’s e-commerce website is configured to fully redirect customers to a compliant third-party website prior to requesting cardholder data, or if an iFrame provided by a compliant third-party provider is used for the collection of cardholder data, the flow of cardholder data is controlled by the third-party provider and the merchant will likely qualify to attest using the SAQ A. E-commerce merchants who use other technologies or processes, such as JavaScript or direct post methods, to direct the flow of cardholder data from the customer directly to the compliant third-party payment gateway would need to validate using the SAQ A-EP.

SEE ALSO: SAQ A: What to Know, and What to Do

What PCI Requirements does SAQ A-EP cover?

The SAQ A-EP touches base with all the requirements in the PCI DSS. Here’s a quick look at the involved requirements.
  • Requirement 1: Install and maintain a firewall configuration to protect data
  • Requirement 2: don’t use vendor-supplied defaults for system passwords and other security parameters
  • Requirement 3: protect cardholder data
  • Requirement 4: encrypt transmission of cardholder data across open public networks
  • Requirement 5: regularly update anti-virus software
  • Requirement 6: develop and maintain secure systems and applications
  • Requirement 7: Restrict access to cardholder data by business need to know
  • Requirement 8: Identify and authenticate access to systems
  • Requirement 9: Restrict physical access to cardholder data
  • Requirement 10: Track and monitor all access to network resources and cardholder data
  • Requirement 11: Regularly test security systems and processes
  • Requirement 12: Maintain a policy that addresses information security for all personnel

Example questions

Here are a few questions you’ll need to answer for this SAQ.
  • Is there a formal process for approving and testing all network connections and changes to the firewall and router configuration?
  • Is there a current diagram that shows all cardholder data flows across systems and networks?
  • Are security parameter settings set appropriately on system components?
  • Are only trusted keys and/or certificates accepted?
  • Is antivirus software deployed on all systems commonly affected by malicious software
  • Are critical security patches installed within one month of release?
  • Are all users assigned a unique ID before allowing them to access system components or cardholder data?
  • Are all intrusion-detection and prevention engines, baselines, and signatures kept up to date?
  • Is a security policy established, published, maintained, and disseminated to all relevant personnel?

Additional tips

Here are a few extra things to think about when filling out SAQ A-EP
  • Protect the integrity of payment pages: It is vital that SAQ A and SAQ A-EP merchants implement controls to prevent unauthorized modification of pages containing code that can affect the flow of cardholder data (redirects, iFrame, JavaScript, etc.). Change detection systems or file integrity monitoring should be in place to identify and alert on any unauthorized changes to payment pages
  • Look into intrusion detection/prevention devices: these devices can help you quickly find and eliminate potential breaches
  • Document everything: having documented policies, changes, and incident response plans prevent you from liability and keeps you organized
Need help getting PCI compliant? Talk to us!

Michael Simpson (QSA, CISSP, CCNP) is a Principal Security Analyst at SecurityMetrics and has been in the IT Security industry for 15 years. He has a Bachelor of Science in Computer Science and a Masters in Business Administration.

PCI DSS Requirement 3: What You Need to be Compliant

Learn how to fulfill PCI Requirement 3. 

Jen Stone, QSA, CISSP
By: Jen Stone
Security Analyst
QSA, CISSP
Are you compliant with PCI DSS Requirement 3? This requirement involves protecting card data storage.
Here are some things to remember when it comes to complying with PCI Requirement 3.

Encrypt stored card data

PCI Requirement 3When cybercriminals hack a payment system, they can’t steal cardholder data that isn’t there. That’s why it’s important to keep your system clean of insecurely stored card data. The problem is that unencrypted payment card data has a way of creeping in where you least expect it.

Stored card data must be encrypted using industry-accepted algorithms (e.g., AES-256). Unfortunately, many merchants don’t know they are storing unencrypted Primary Account Numbers (PANs). In the latest study by SecurityMetrics, 61% of merchants were found to store unencrypted PANs.

Some places that may be hiding card data unintentionally include:
  • Error logs: often contain full card data when an error in card authentication occurs
  • Sales departments: may have emailed or printed forms containing card data
  • Customer service representatives: may take card numbers over the phone, have handwritten card data
  • Administrative assistants: may have a spreadsheet containing an executive’s card number for quick access 
SEE ALSO: Do You Know Where You Store Card Data?

Protect encryption keys

Not only must card data be protected, but also the encryption keys must be protected. Leaving encryption keys unprotected is like storing your house key by leaving it in your front door lock, so it’s critical to use a solid PCI DSS encryption key management process.

Find stored card data 

Payment card data can easily leak due to poor processes or misconfigured software. You must look where you think the data is, and then look where it shouldn’t be.

PCI DSS 3.2 Requirement 1.1.3 requires a current diagram for all card data flows in your organization. A card data flow diagram is a graphical representation of how card data moves through an organization. As you define your environment, ask all organizations and departments if they receive cardholder information, and determine how their answers may change your current understanding of your organization’s card data flows.

Here are a few questions you should ask when making a card data flow diagram:
requirement 3
  • What device(s) am I using for transactions? A virtual terminal? POS system? 

  • What happens to the card data after a transaction? 

  • Is data encrypted? If so, when is it encrypted? Is encryption managed internally or by a third party? 
  • Do I store card data after it’s sent to the processor for approval? Do my logs inadvertently store card data held in memory? Do manual processes allow card data storage in notes fields or other unprotected locations?

  • When does authorization occur? Real-time or end-of-day? 

  • When a transaction is authorized, what cardholder data is returned by the processor? Is it encrypted? Tokenized?

  • Is card data backed up on my system? Are backups encrypted? Is my backup server at a different location? Does that location meet PCI DSS requirements? 

  • Where might card data be transmitted or stored in processes not part of authorization? 

In addition to looking at data flows and processes, you should regularly run a cardholder data discovery tool (such as PANscan®) on your systems. These tools help identify the location of unencrypted PAN. Knowing where PAN data is stored helps confirm if your CDE is secure. It also helps identify which processes or data flows might need to be adjusted.

Assign the responsibility of keeping unencrypted card data off your systems to an individual or team. Have them define and follow a process of periodic data discovery cycles to recheck and ensure systems remain clean of unencrypted card information.

SEE ALSO: How Much Credit Card Data do You Store? (It’s More Than You Think.)

Additional tips

Here are a few more things to think about while fulfilling Requirement 3:
  • Reduce your PCI scope: The less you have to secure, the better. Streamline your card data flows and make sure you’re only storing what’s necessary
  • Segment networks: While not required by the PCI DSS, network segmentation keeps your cardholder data environment separate from the rest of your network, reducing risk
  • Place an individual in charge of PCI compliance: Becoming compliant can take time and effort. Establishing responsibility for PCI compliance can reduce confusion and increase accountability
Note: Making a single person responsible for PCI compliance is a new requirement (12.4.1) for service providers that will be in place next year. This requirement is a best practice until January 31, 2018, after which it becomes a requirement. 


Need help with PCI compliance? Talk to us! 

Jen Stone (MSCIS, CISSP, QSA) is a Security Analyst at SecurityMetrics with an extensive background in Information Security and 20+ years in IT. 

SecurityMetrics Guide to PCI DSS Compliance
6 Steps to Making an Incident Response Plan

Learn how to get started on creating your own incident response plan.  

David Ellis
Director of Forensic Investigations
CISSP, PFI, QSA
What do you do if you get hacked? If you learn that you’ve been hacked via a third party, like your bank, the FBI, or the media, your organization could be in serious trouble. It’s not enough to just sit back and hope it doesn’t happen to you. With the rise of technology and networked devices, many businesses are preparing for when they get breached, not if.

Developing and implementing an incident response plan will help your business handle a data breach quickly, efficiently, and with minimal damage done.

SEE ALSO: How to Manage a Data Breach: 5 Steps to Keep Your Business Safe

So how do you get started?
Here are 6 steps to help you create an incident response plan.

1. Identify and prioritize assets

You need to make sure you know where your company keeps its crucial data assets. Ask this question: What would cause my business to go under or suffer heavy losses if it were stolen or damaged?

Once you identify your lists of critical assets, prioritize them according to importance and highest risk. Make sure to quantify your asset values. This will help justify your security budget and show executives what you’re trying to protect and why it’s essential to do so.

2. Identify potential risks

Do research. Look at the greatest current threats against your business systems. Keep in mind that this will be different for every business.

For businesses that process a lot of data online, improper coding could be their biggest risk. For those in a brick-and-mortar environment that offer WiFi for their customers, it may be Internet access. Other businesses may place a higher focus on ensuring physical security.  And some businesses may focus on securing their remote access applications.

Here are examples of a few possible risks:
  • External or removable media
  • Attrition
  • Web
  • Email security
  • Social engineering
  • Loss or theft
SEE ALSO: What is a Risk Assessment, and Why Does Your Business Need One?

3. Establish procedures

You can’t just hope you’ll know what to do should you get breached. If you don’t have a set of practiced procedures to follow, a panicked employee could end up making crucial mistakes that could be costly to your organization. Your policies and procedures for handling a data breach should include:
  • identifying and containing a breach
  • recording information on the breach
  • notification and communications plan
  • Defense approach
  • Employee training
Obviously, you’ll need to tailor your policies to your business. Some businesses may require a heftier notification and communications plan, while others may need to get help from outside resources.  All businesses will need to focus heavily on employee training (safe handling of emails, defense against phishing and social engineering attacks, etc.).

4. Set up a response team

You’ll need to designate a team that helps coordinate the actions of your company after the discovery of a data breach. The goal for this team is to help coordinate resources during a security incident to minimize impact and restore operations as quickly as possible.

Some of the necessary team roles are:
  • Lead Investigator
  • IT Director
  • Communications Leader
  • Documentations and Timeline Leader
  • HR/Legal Representative
Make sure your team covers all aspects of your organization, and that they understand their particular roles in the plan.

5. Sell the plan

Your incident response team won’t be very effective if you don’t have the proper backing and resources to execute the plan. This is true from enterprise organizations to smaller, one-off businesses. That’s why you need to make sure that those who control your company’s purse strings are aware of the need and benefits of having an incident response plan.

Enterprise organizations should make sure executive members are on board with the idea of an incident response team. Smaller organizations should make sure their higher ups are okay with some additional funding and resources dedicated to incident response.

Present your plan with the mindset of how this will benefit the company, both financially and with your brand (think of the damage to your company’s reputation in the event that you suffer a data breach and do a poor job of managing the incident). The better you present your goals to protect your business, the easier it will be for you to obtain any needed funding to create, practice, and execute the plan.

SEE ALSO: 10 Tips for Increasing IT Budget and Security Buy-In

6. Employee training

Just having an incident response plan won’t help you in a data breach. Your employees need to be aware of the plan and be properly trained on what they’re expected to do should you get breached.

Test the response plan through tabletop exercises. These exercises familiarize your employees with their particular roles in a data breach by testing your response plan through a potential hacking scenario. Through testing your plan, you can identify and address holes in the plan and help everyone involved see where they can improve, and do this when there is no actual risk to your business’s assets.

SEE ALSO: Employee Data Security Training: What You Should Do

Additional tips

Here are a few other things to think about when making your incident response plan:
  • Train employees on data security: Help you employees to see their role in maintaining company security through being able to better identify phishing emails, social engineering efforts, and the like. This will help prevent data breaches and keep your employee’s focused on security
  • Document everything: Documenting your plan is crucial to having set procedures, and it helps keep everyone on the same page
  • Test your employees: Hire ethical social engineers to test employees and their training. This helps employees to practice what they’ve learned and be ready for the real thing
Need help after a data breach? Our team of forensic investigators can help!

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.

SecurityMetrics Guide to PCI DSS Compliance