Data is the key to your operation. Make sure you’re keeping it safe.

Whether it’s the data you receive from your customers, information you use to run your business, or the source code for your applications, data is at the very heart of any organization. Securing that data is job #1 for any information security program. 


A good place to start is understanding where the data is, who uses it, and why it’s being used, so you can determine how to best secure it. 

Once all the important data has been identified, commit the details to documentation by creating a data flow diagram so you know where all of your organization’s data is at any given time.

A data flow diagram maps the flow of data within your organization and its networks. This diagram is the key to understanding the data stored in your environment.

To learn more about creating your own data flow diagram, watch this short video:

When thinking through data flows, it’s useful to walk through a data lifecycle model.  For instance, one popular model considers that data is created, shared with others, used by personnel or applications to accomplish something meaningful, stored electronically or physically for later use, archived for a long period “just in case” and finally destroyed.  By considering each of these steps, an informed understanding of how data moves throughout your organization is well within reach. Knowing where your data is and how it’s being used will strengthen your organization’s data security.

In addition to understanding the movement of data throughout your organization, the requirements for preserving the confidentiality, integrity, and availability of each type of data should also be captured.  Not all data is subject to the same set of requirements – your public website probably has low confidentiality and high integrity and availability requirements, but healthcare data usually ranks high in all three categories.  By fleshing out these requirements, the protections that should be afforded the data will become clearer. 

For instance, encryption can be used to ensure both data confidentiality and integrity requirements are being met. To do so, your policies should require appropriate encryption for both data-at-rest and data-in-motion.  Likewise, mechanisms to manage access to data should be in line with these requirements.  Finally, availability requirements will drive the system design, business continuity planning, IT resiliency, and other information management considerations.

Data has a useful life, and you must make sure you abide by it. This means understanding and enforcing data retention requirements. In some cases, this is defined by various laws and regulations, and in others, it’s up to your organization to define. 

Data retention requirements should be formally defined and then implemented to eliminate (“destroy” in the data lifecycle model) the data such that it’s no longer recoverable.  It’s only after this step that the protections are no longer required because data that you no longer have in your possession doesn’t need to be secured.

Work with a KirkpatrickPrice Expert to Make Sure Your Data Is Secure

Data security can be an intimidating goal, especially with the amount of data organizations are responsible for these days. It can be difficult to keep up with what data is being used, who is responsible for certain data, and even what data is still relevant to your organization. At KirkpatrickPrice, our data security experts are here to help you understand your data’s lifecycle and how to best protect that data.

Connect with an expert today to make sure you’re doing everything you can to secure your data.

About the Author

As a 30-year IT veteran, Randy Bartels has experienced nearly every facet of information technology management from help desk and software development to architecture and budgets. For the past 15 years, Randy has been providing information security consulting services to clients of all shapes and sizes and he currently serves KirkpatrickPrice as their VP of Operations. He holds CISSP, CISA, CSSLP, QSA, CCSK certifications.

I Piloted an Emergency Landing, and So Can You

It can be easy to put business continuity and disaster recovery planning on the back burner if your organization has never been affected by a disaster. But what would happen if a power outage, tornado, or data breach hit your organization and you didn’t have any plan in place? Disaster strikes when you’re least expecting it. It’s critical that you ensure that your organization is prepared. Learning from the experiences of others who have survived emergency situations is a key way to better prepare your organization for disaster.

On June 23, 2018, I was flying home from the Miami area to Tampa after finishing some charity work, piloting my private airplane. As I was flying over Lake Okeechobee and without any warning, the engine of my plane fell silent – something I never wanted to hear. I quickly realized that I had just nine minutes to implement an emergency landing plan before my plane would crash. Because of extensive preparations, I was able to successfully pilot my plane to the ground without harm using six basic steps. The same six steps that helped me pilot an emergency landing can also help your organization navigate a disaster. Let’s review the following steps:

  1. Prepare for an incident
  2. Diagnose the problem
  3. Determine your assets
  4. Determine your options
  5. Prepare for curveballs
  6. Make a post-action report

Preparation

If we could predict disasters, we would avoid them – but we can’t. Avoiding disaster is essentially impossible but preparing for an incident can help lessen the impact. So, how can you prepare for disaster? Training and practice are key ways that you can prepare your organization for disaster. Your disaster recovery team should be continuously practicing the steps it would take to implement your business continuity and disaster recovery plans. Placing your disaster recovery team under heightened stressors will also assist in better preparing them for the high levels of stress that will occur when disaster does hit. Your plans should be like muscle memory for your team; each member must be intuitive about how your systems work. During my flight, knowing systems like my GPS, engine, radio, and fuel gauge was critical, just like knowing your firewalls, applications, networks, and cloud environments will be critical.

What’s the Problem?

When disaster strikes, noticing how the problem stands out from what’s expected is critical. We all know what the inside of plane sounds like, right? There’s a buzz in the air from the sound of engines and wind. When my plane went silent, I knew something was extremely wrong. Your employees must be trained to notice anomalies in your systems without delay. Once the problem is diagnosed, the incident must be reported immediately. This will allow your organization to put more resources on the problem.

What are Your Assets?

In high-stress situations, determining your assets is a way to focus your team and identify the problems at hand that can be solved. During my flight, I quickly identified my assets as the time I had to land, the nearest airport, and my training. You should always be looking for unexpected assets, though. In my case, it was help from the local sheriff’s office. In your situation, it may be outside help from a PR firm or IT consultant. Having a focused mind will allow you to uncover these assets.

What are Your Options?

Often times, the number of options to mitigate disaster-related problems can be overwhelming. I don’t want  you to get lost in this, though. Keep as many options open as possible, but eliminate options immediately once they’re no longer viable. You need to analyze options and commit to a plan, not fixate on or misinterpret facts.

Prepare for the Curveball

Even if you have a business continuity and disaster recovery plan, things don’t always go the way they’re planned. You must keep this in mind as you’re strategizing how to recover. When I decided to land my plane on a highway, I knew that powerlines, an oncoming semi-trick, and a slow-moving Sedan were in my way. What did I do? I prepared myself for these obstacles and didn’t let them overwhelm me. If you’re in the midst of dealing with a major data breach and a malicious hacker makes a ransom demand, you cannot give up. Manage the incident all the way to the end.

Make a Post-Action Report

Congratulations! You’ve made it through the disaster. Celebrate your successes and don’t be discouraged if you didn’t do everything perfectly—you won’t and I didn’t. But you can learn from your mistakes. At this point, you’ll need to question how you can improve your plan. What could you have done differently? Is there additional training or practice that your disaster recovery team needs to be put through?

While we can’t prevent disaster from happening, we can set our organization’s up for success by creating, practicing, and implementing business recovery and disaster recovery plans. Following these six steps will allow your organization to be best prepared for when, not if, a disaster hit. Remember: extraordinary events happen on ordinary days. Will you be prepared?

Ready to get started on your organization’s business continuity and disaster recover plans? Find out how KirkpatrickPrice can help you create business continuity and disaster recovery plans.

About Randy Bartels

Randy Bartels serves as Vice President of Security Services at KirkpatrickPrice. His experience crosses a wide range of information technology disciplines including security and network architecture, software lifecycle management, operations, and penetration testing. Randy is responsible for leading complex engagements and investigating risks in new areas of technology. He holds CISSP, CISA, CSSLP, and QSA certifications.

More Disaster Recovery Resources

Business Continuity and Disaster Recovery Planning Checklist

3 Steps for an Effective Disaster Recovery Plan

Cloud Security: Business Continuity and Disaster Recovery Planning Checklist

Documenting Your Review Process

The final requirement in PCI Requirement 12 works in conjunction with PCI Requirement 12.11. PCI Requirement 12.11.1 mandates organizations to maintain documentation of a quarterly review process, which should include documenting results of the reviews and review/sign-off of results by personnel assigned responsibility for the PCI DSS compliance program.

Why are PCI Requirement 12.11 and PCI Requirement 12.11.1 listed separately? The PCI DSS explains, “The intent of these independent checks is to confirm whether security activities are being performed on an ongoing basis. These reviews can also be used to verify that appropriate evidence is being maintained—for example, audit logs, vulnerability scan reports, firewall reviews, etc.—to assist the entity’s preparation for its next PCI DSS assessment.”

The last requirement within the last requirement of the PCI DSS is PCI Requirement 12.11.1. PCI Requirement 12.11.1 says that if you are a service provider, you have to implement a program where your management is receiving all of the documentation about your program and they’re signing off on it.

Understand that management is responsible for the overall security. They might delegate that responsibility to somebody else within their organization, but really at the end of the day, they own it, they broke it, they bought it, it’s theirs. PCI Requirement 12.11.1 says that they’re receiving that information, they’re managing that information, and that they’re well aware and signing off on that after having received it.

Reviewing Your Personnel

If you are a service provider, your organization must comply with PCI Requirement 12.11. It requires that you perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. These reviews must cover the following processes:

  • Daily log reviews
  • Firewall rule-set reviews
  • Applying configuration standards to new systems
  • Responding to security alerts
  • Change management processes

The PCI DSS explains, “Regularly confirming that security policies and procedures are being followed provides assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected.”

If you’re a service provider, once again the PCI DSS calls out another specific requirement for you. PCI Requirement 12.1 says that if you are a service provider, you have to have a program in place that’s performed at least quarterly, making sure that your security program is still functioning. For example, your log review program, your firewall route reviews, and your scanning – all of those things that go into the daily care and feeding of your information security program. What we’re going to be looking for if you’re a service provider is that you actually have a program in place for monitoring and then taking corrective actions in the event that you find out, for some reason, your program has failed and it’s no longer working.

Modifying Your Incident Response Plan

Your incident response plan should be able to easily modify so it can be as thorough and up-to-date as possible. PCI Requirement 12.10.6 says, “Develop a process to modify and evolve the incident response plan according to lessons learned and to incorporate industry developments.” This is sort of a management exercise to analyze what could’ve been done better during incident response and to keep your incident response plan current and able to react to emerging threats and security trends.

PCI Requirement 12.10.6 defines that after you have an incident or after you’ve practiced your incident response plan, you have “lessons learned.” Understand that this is not really about that Johnny did good and Susie did bad; this is really a management exercise to identify what you did good and what you could have done better. It’s really meant to evolve your practice to the next level. We look for evidence that you perform this process of evaluation, making sure that you look at what are the new incidents and types of events that could impact you. We’re also making sure that your organization has that documented after an incident or a practice incident response as a requirement and that you retain evidence of that occurring.