Classifying Data: Why It’s Important and How To Do It

Why is Classifying Data Necessary?

Knowing how to classify data is critical given today’s advancing cyber threats. With well over 5,000 data breaches occurring in 2019 alone, including more than 8 billion pieces of data compromised, classifying your data is essential if you want to know how to secure it and prevent security incidents at your organization.

How to Classify Data

Determining how to classify your data will depend on your industry and the type of data your organization collects, uses, stores, processes, and transmits. For healthcare organizations, this could be PHI such as patient names, dates of birth, Social Security numbers, medical data and histories, or prescription information. For financial services organizations, this could be CHD, PINs, credit scores, payment history, or loan information. Regardless of the type of data, though there are a few key considerations to make when classifying data, including:

  1. What data does your organization collect from customers and vendors?
  2. What data does your organization create?
  3. What is the level of sensitivity of the data?
  4. Who needs access to the data?

4 Ways to Classify Data

Depending on the sensitivity of the data an organization holds, there needs to be different levels of classification, which determines a number of things, including who has access to that data and how long the data needs to be retained. Typically, there are four classifications for data: public, internal-only, confidential, and restricted. Let’s look at examples for each of those.

  • Public data: This type of data is freely accessible to the public (i.e. all employees/company personnel). It can be freely used, reused, and redistributed without repercussions. An example might be first and last names, job descriptions, or press releases.
  • Internal-only data: This type of data is strictly accessible to internal company personnel or internal employees who are granted access. This might include internal-only memos or other communications, business plans, etc.
  • Confidential data: Access to confidential data requires specific authorization and/or clearance. Types of confidential data might include Social Security numbers, cardholder data, M&A documents, and more. Usually, confidential data is protected by laws like HIPAA and the PCI DSS.
  • Restricted data: Restricted data includes data that, if compromised or accessed without authorization, which could lead to criminal charges and massive legal fines or cause irreparable damage to the company. Examples of restricted data might include proprietary information or research and data protected by state and federal regulations.

Common Requirements for Classifying Data

Many frameworks and legal regulations have specific requirements that encourage organizations to classify data. While this isn’t an exhaustive list of the requirements and laws, these are quite common. It should be noted that these requirements vary depending on the types of data your organization collects, uses, stores, processes, or transmits.

  • SOC 2: The SOC 2 Trust Services Criteria requires that service organizations who include the confidentiality category in their audit demonstrate that they identify and maintain confidential information to meet the entity’s objectives related to confidentiality.
  • HIPAA: PHI is considered high-risk data. As such, HIPAA Security Rule requires that all covered entities and business associates implement administrative safeguards that ensure the confidentiality, integrity, and availability of PHI. In addition, the HIPAA Privacy Rule limits the uses and disclosures of PHI, forcing covered entities and business associates alike to establish procedures for classifying the data they collect, use, store, or transmit.
  • PCI: In order to comply with PCI DSS Requirement 9.6.1, entities must “classify data so that sensitivity of the data can be determined.”
  • GDPR: Organizations that handle the personal data of EU data subjects must classify the types of data they collect in order to comply with the law. Additionally, GDPR categorizes certain data – race, ethnic origin, political opinions, biometric data, and health data – as “special” and therefore it is subject to additional protection. This not only means that organizations need to know what types of data they hold, but they also need to be able to label that data such as public, proprietary, or confidential.

What processes does your organization have in place for classifying data? Do you need help determining which types of data you collect, use, store, process, or transmit? If compliance is on your radar this year, make sure you’ve done your due diligence to classify data. Interested in learning more about how we can help you establish data classification procedures? Let’s find some time to talk.

More Resources

Best Practices for Data Retention

How to Build an IT Asset Management Plan

How Much is Your Data Worth to Hackers?

Creating Effective Network Diagrams and Data Flow Diagrams

The Importance of Network and Data Flow Diagrams

Network diagrams and data flow diagram are called out in PCI Requirement 1; in fact, the PCI DSS puts so much weight on a good diagram that they include it in the first phase of the Prioritized Approach, which is the recommended method to remediate compliance gaps.

But, PCI is not the only place where network and data flow diagrams are valid. In any environment where an organization has sensitive data, these two pieces of documentation are critical during an audit. They will provide valuable information and understanding about the environment in less time than any other piece of documentation. So, how can you create effective network diagrams? How can you create effective data flow diagrams? Let’s discuss.

What is a Network Flow Diagram?

A network flow diagram maps the flow of data through networks. Digital systems often involve network-connected systems with functionality distributed across multiple nodes. For example, in an ecommerce store, data might move from an order system to invoicing, payment, and logistics systems.

A network flow diagram indicates the routes over which data travels, the internal and external nodes on which it is stored or processed, and the purpose of those nodes. Network flow diagrams are essential to understanding the environment that hosts sensitive data as well as risk mitigation and the enforcement of information security policies.

How to Create Effective Network Diagrams

Effective network diagrams show where sensitive data is on your network and how it is protected. In order for a network diagram to be effective, it needs to achieve the following:

  1. Identify:
    • All boundaries of the sensitive data’s environment
    • Any network segmentation points which are used to reduce scope of the assessment
    • Boundaries between trusted and untrusted networks
    • Wireless and wired networks
    • All other connected points applicable to the protection of sensitive information and the critical assets where it is transmitted, processed, or stored
  2. Locate the network protections (i.e. firewalls, IDSes, router ACLs, etc.) surrounding the systems that transmit, process, or store the data in question (the “sensitive environment”). Important considerations include:
    • Define the boundaries between trusted and untrusted networks, including any network segmentation related technical controls that enforce segmentation if the entire network is not supposed to be in scope.
    • If there is no internal network segmentation, then your entire network is in scope for the audit.
    • VLANs do not, by themselves, constitute internal segmentation since they don’t restrict access.
    • Internal segmentation might include internally deployed network firewalls; router ACLs that only allows specific devices to communicate to the sensitive systems; Network Admission Control or similar technology to make decisions on whether or not a device requesting access to the sensitive area has met the security requirements such as patch levels, anti-virus signature dates, and last scan time, etc.
    • In all cases, segmentation must enforce access to the sensitive areas. If a packet – any packet – can get from one place to another, then the source is not segmented from the sensitive environment and it is in-scope.
  3. Identify ALL wireless networks – even if they’re out scope.
  4. Identify the system components involved in transmitting, processing or storing sensitive data. This includes workstations, databases, routers, firewalls, wireless access points, application servers, switches, etc.
  5. Identify the devices responsible for administering the security of the sensitive systems (i.e. antivirus, logging, authentication, etc.).

How to Create Effective Data Flow Diagrams

In a simple environment, the data flows might be easily overlaid on top of network diagrams. In more complex environment, you might see something else altogether. We frequently see “swim lane” flowcharts that break the process down into “lanes” executed by specific teams. The form and structure is less important than the information contained in it, though. Effective data flow diagrams must include the following:

  1. Be sequenced. For example, “We receive sensitive data at X; it goes through these Y points and is destroyed at Z.”
  2. Follow the data life cycle.
    • Create: Where does data come into our organization?  What business processes – such as a sales team or a call center – are involved? What technical systems – such as a web server, an SFTP server, or contact center – are involved?
    • Share: With whom and how is the data shared?  For example, by email attachment, SharePoint, or AWS S3 bucket.
    • Use: What people and system components use the data – either as input or provided as output as part of the process?
    • Store: Where is it stored? A filing cabinet, a shared folder?
    • Archive: How, where, and for long is the data archived? For instance,  archived in an S3 Glacier bucket for one year, on magnetic tape for two years, then in a records warehouse for seven years.
    • Destroy: How is it destroyed when no longer needed? Is it via Iron Mountain shredding service, by secure electronic wipe of the magnetic tape?
  3. Have sufficient references to names of applications where sensitive is transmitted, processed or stored.  The application details, including the system components on which it runs, might be documented elsewhere in a more complex environment.
  4. Address the question: Where is my sensitive data and who needs to interact with it?

An Example Network Flow Diagram

Whether you’re undergoing a PCI or SOC audit, or you’re pursuing other compliance goals, creating and maintaining effective network diagrams and data flow diagrams is key to your audit success. Because we know that this is complex but critical documentation, KirkpatrickPrice auditors are committed to helping our clients create thorough network diagrams and data flow diagrams.

Our client, Net Friends, is a great example of this. After Net Friends’ SOC 2 audit, they commented,

“We are so appreciative of the time and attention we received from Randy and the team at Kirkpatrick Price during the SOC 2 audits, and their collaborative approach of working with us on topics that extend well beyond their core mandate. Who could have predicted when we started this ongoing audit process that we would be inspired creatively?!?”

This is part of KirkpatrickPrice’s mission – to inspire and empower our clients to achieve challenging compliance goals.

Here’s an example network flow diagram we put together for Net Friends’ before and after:

example network flow diagram for Net Friends

All in all, effective network diagrams and effective data flow diagrams play off of each other.  They are powerful tools that will provide significant amounts of information to those responsible for protecting sensitive data.  They will help you define scope the of affected system components, identify critical controls, and identity weaknesses in the control framework. If you want to learn more about how KirkpatrickPrice can help you improve your network diagrams and data flow diagrams, contact us today to speak to a specialist.

More Compliance & Cybersecurity Resources

Most Common SOC 2 Gaps

How to Scope a HITRUST Engagement

Stay Secure With These Intrusion Detection and Protection Techniques

Does your organization have robust processes and procedures in place to identify and contain threats in your environment? Are you confident that these processes can prevent security incidents and data breaches caused by common attack methods like malware, ransomware, DoS attacks, phishing attacks, and more?

Establishing a strong intrusion detection and prevention system (IDPS) – although they are sometimes separately referred to as intrusion detection systems (IDS) and intrusion prevention systems (IPS) – is a core component to any cybersecurity strategy.

Why is that?

First, let’s take a look at what an intrusion detection and prevention system is, and then we’ll discuss what type of intrusion detection and prevention system your organization should consider using.

What is an Intrusion Detection and Prevention System?

An Intrusion Detection and Prevention System (IDPS) monitors network traffic for indications of an attack, alerting administrators to possible attacks. IDPS solutions monitor traffic for patterns that match with known attacks. Traditionally, they used signature-based or statistical anomaly detection methods, but IDPS increasingly leverages machine learning technologies to process vast amounts of data and identify threats that signature and anomaly detection would miss.

IDPS solutions are usually deployed behind an organization’s firewall to identify threats that pass through the network’s first line of defense. Typically, an intrusion detection and prevention system accomplishes this by using a device or software to gather, log, detect, and prevent suspicious activity.

What Type of Intrusion Detection and Prevention System Do You Need?

When determining which type of intrusion detection and prevention system your organization should use, you’ll need to consider factors like the characteristics of the network environment, the goals and objectives for using an IDPS, and current organization security policies. Ultimately, there are two types of IDS/IPS: network-based and host-based. A network-based IDPS runs on network segments, including wireless or any other network that is selected. A host-based IDPS, on the other hand, runs on servers. The four common types of IDPS, as defined by NIST, include the following:

  1. Network-Based IDPS: This type of IDPS monitors network traffic for specific network segments and devices. It analyzes the network and application protocol activity to identify suspicious and abnormal activity.
  2. Wireless IDPS: This IDPS is a sub-type of network-based IDPS. It monitors wireless network traffic and analyzes it to identify suspicious activity involving networking protocols.
  3. Network Behavior Analysis (NBA) System: This IDPS is a sub-type of network-based IDPS. It is used to examine network traffic in order to identify threats that generate unusual traffic flows (i.e. malware, DDoS attacks, and policy violations).
  4. Host-Based IDPS: This IDPS is used to monitor the characteristics of a single host and the events occurring within that host for suspicious activity.

Should You Use Multiple Types of IDPS Technologies?

Many businesses today have complex environments, making it a necessity to deploy more than one type of intrusion detection and prevention system. However, before implementing multiple types of IDPS technologies, it’s necessary to fully evaluate the needs of your organization. In theory, using multiple types of IDPS technologies can only lead to a more secure environment, but if they’re implemented incorrectly, there could be detrimental consequences.

What Type of Detection Should Your IDPS Use?

After you’ve determined which type of intrusion and detection system your organization should utilize, you’ll need to determine which detection method is right for you. Each type of intrusion detection and prevention system listed above, regardless if they’re network-based or host-based, has detection capabilities with one or more of the following:

  • Signature-based: The signature-based IDS is used to match the signatures of known attacks that have already been stored in your database to detect attacks on your network.
  • Anomaly-based: The anomaly-based IDS method identifies abnormal behavior in your organization’s network.
  • Protocol-based: The protocol-based IDS method monitors and analyzes protocols used by the computing system.

Regardless of which type of intrusion and detection system your organization uses, they are a vital component of your cybersecurity strategy. To mitigate the advancing threats all organizations are faced with, having a robust IDPS in place is a must. If you’re looking for advice on how you can better implement an intrusion detection and prevention system in your environment, let’s chat about how KirkpatrickPrice can partner with you to ensure the security of your business.

More Network Security Resources

Security Within Your Development, Staging, and Production Environments

Encrypted Backups: What They Are and How to Use Them

How to Build an IT Asset Management Plan

Data Backup Best Practices: 4 Things You Need to Know

Data Backups and Recovery Go Hand-in-Hand

When a data breach happens at your organization – whether you’re hit by a ransomware attack, an advanced DoS attack, or an internal actor mistakenly deletes company records – you need to ensure that your data is properly backed up. A data backup is an updated copy of your company’s data that is stored in a separate system or medium (i.e. file, hard drive, cloud, etc.) and is used to protect your organization’s assets in the event of data loss, including data breaches, accidental loss, theft, or natural disasters. In other words, data backups and recovery should go hand-in-hand.

4 Data Backup Best Practices

The concept of data backups is quite simple, but it’s one that many organizations have trouble implementing whether due to lack of resources, personnel, or time. For those questioning how to back up data, consider using these four data backup best practices.

1. Use Remote Storage

Storing backups on-site can pose imminent danger. If your entire system is compromised or if there is a natural disaster that compromises your entire facility, the data backup will likely also be compromised. Because of this, data backup best practices include storing data backups in an off-site location, whether that is at another physical location or in the cloud. However, Lead Practitioner at KirkpatrickPrice, Richard Rieben, explains, “Just because you’re in the cloud, it doesn’t mean you don’t need offline backups. The bottom line is, all organizations need to back up their data online and offline.”

2. Schedule Frequent Backups

Having current, up-to-date backups is essential to the continuity of your business. When establishing a data backup program, consider utilizing built-in backup programs, like those provided in Microsoft and Apple products, or create time-based solutions, such as updating every day, week, or month. To ensure that data backups aren’t neglected, it’s a best practice to automate backups.

3. Encrypt Backups

If your data backups are not encrypted, they could easily be compromised if the data is stolen, misplaced, or compromised in some way. For this reason, encrypted backups are one of the top data backup best practices. It adds an extra layer of security to your backups and can give you peace of mind that your data is secure in the event that you have to use your disaster recovery plan.

4. Determine and Comply with Retention Requirements

Are you aware of the data backup retention requirements that your organization must comply with? In this new age of data privacy laws, like GDPR and CCPA, you must know which data backup retention requirements apply to your business. These laws make data backup retention requirements a bit ambiguous because of the “right to erasure” requirements that entities must comply with – organizations must know which data they are required to backup, which data they must delete, and more. This is also the case when dealing with highly sensitive data, like protected health information or payment card data.

Knowing data backup retention requirements also helps limit the amount of data you must store. Older, out-of-date backups should be deleted, data that is no longer in use should be deleted, or data that no longer supports the activities of your organization should be deleted.

Common Framework and Legal Requirements for Data Backups

Data is now the world’s most valuable asset, and many information security frameworks address securing such assets by requiring robust data backup practices. Take a look at some of the common framework and legal requirements for data backups.

  • SOC 2: According to Availability Criteria 1.2, service organizations must “authorize, design, develop or acquire, implement, operate, approve, maintain, and monitor environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.” It also reiterates that entities should have “procedures … in place for backing up data, monitoring to detect back-up failures, and initiate corrective action when such failures occur.”
  • PCI DSS: PCI Requirement 9 says that entities must restrict physical access to cardholder data. Elaborating on this, PCI Requirement 9.5.1 says, “Store media backups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually.”
  • HIPAA: Under the HIPAA Security Rule, 45 CFR § 164.308(a)(7)(ii)(A), business associates and covered entities must establish a contingency plan, including a data backup plan, that details a response to any emergency situation that damages systems that contain ePHI.

In today’s threat climate, data breaches are inevitable. Are your data backup retention policies up-to-date with the current framework and legal requirements? Are your data backups and recovery processes aligned? Let us help you ensure the security of your data backups by evaluating if your organization has implemented these four data backup best practices. Contact us today to get started.

More Information Security Resources

Encrypted Backups: What They Are and Why to Use Them

Auditor Insights: Business Continuity and Disaster Recovery Plans for the Cloud

Incident Response Planning: 6 Steps to Prepare Your Organization

Security Within Your Development, Staging, and Production Environments

When information security, data security, and cybersecurity measures aren’t followed in development, staging, and production environments, the consequences can be detrimental. We’ve seen that time and time again. Last year, a bug bounty discovered a data breach at Imperva – a leading provider of firewall services. How did it happen? An unauthorized user stole an administrative API key from a production AWS account. What was the mistake behind Uber’s 2016 data breach? Developers published code that led to hackers gaining access to developers’ privileged accounts and to Uber’s servers.

Are your developers following the security standards you’ve put into place? Are you aware of the security concerns with DevOps? Let’s discuss how to securely manage multiple environments, from development to deployment.

Development, Staging, and Production Environments

A typical development workflow has three environments: development, staging, and production. Some developers don’t view staging as an environment, but we included it here to give you a full scope of the process.

Development Environment

A development environment is on your computer. It’s the environment where you’ll conduct all your code development without touching with the actual data. In development, you can test upgrades, new features, and improvements without impacting the customer’s view. You may find bugs along the way, but that’s what this environment is meant to discover.

Ideally, the development environment is similar to the production environment, with the same operating system, tools, software libraries, and a copy of the product data. Developers will often use virtual machines or container systems like Docker to mimic the production environment, ensuring that code that works in development will also work in production. 

Typical use-cases for a development environment include:

  • Building new features, extending existing features, and code refactoring.
  • Running integration tests. 
  • Debugging.

There are few restrictions on what developers can do in their development environment, and they are free to experiment with code until they are happy with it, at which point they will push it to the staging environment.

Staging Environment

The staging environment is a production-like environment to see how your code will perform. This is the final testing ground before the code is pushed into production. Staging environments are often used for:

  • Quality assurance and performance testing.
  • Vulnerability testing and risk analysis.  
  • Integration testing, to ensure that the code integrates well with services and databases the app depends on. 

Staging environments also give other developers, project managers, and clients an opportunity to examine software before it goes live. 

Because extensive testing takes place in the staging environment, it’s important that it is as similar to production as possible, including both the software and hardware. While it’s fine to host a development environment on a laptop, the staging environment should be on a server with the same hardware it will run on in production. 

Production Environment

In a production environment, systems go live and your developed code is released to end-users. You deploy completed code that has endured proper vulnerability testing and risk analysis. All of the testing is complete and there’s the expectation that you’ll find only minor bugs, if any. Once it’s released, you’re relying on it as a profit source, so you want to make sure it’s secure

In theory, major bugs and software vulnerabilities should have been discovered before the code goes to production, but that’s rarely the case for complex software systems. It is likely that at least some bugs made it through testing, so organizations must design and  implement network and data security systems that assume the existence of vulnerabilities. 

Importance of Security Throughout Dev, Staging, and Production

With multiple environments comes the difficulty of securely managing them. Best practice is to separate your development, staging, and production environments. This allows each to evolve at its own pace – maybe the development environment is testing out features that won’t be available in production for at least a year – and reduces the risk of cross contamination. Any bugs discovered in staging, for example, will be contained within that environment and not spread any further. Most importantly, keeping your development, staging, and production environment separate will help protect data.

In audits or penetration testing, we see many organizations failing to test their test all of their environments, but there could be a vulnerability in the test environment that compromises the production environment. It’s problematic to avoid testing all environments.

Security Concerns in DevOps

For organizations that use the DevOps approach, security is an even greater concern. It’s face-based, there’s more overlap, there’s automation – there are many reasons to implement and verify security processes in DevOps.

To preserve high-level compliance practices within your development, staging, and production environments, you can implement configuration management techniques, monitoring and logging processes, and even integrate infrastructure as code or policy as code. You can set yourself up for success by performing regular code review during the development process, making changes proactively to all environments, confirming that you have limited access to the proper channels, or even engage in continuous penetration testing to ensure no vulnerability is overlooked. These practices will ensure you’re doing your due diligence to securely manage your various environments.

If you’re interested in advanced penetration testing services that will locate your vulnerabilities and help you avoid harmful gaps in your code, KirkpatrickPrice can help! Contact us to learn more.

More DevOps Security Resources

Think Like a Hacker: How Could Your Mobile Apps Be Compromised?

Best Practices for Configuring Your AWS Perimeter

PCI Requirement 6.5 – Address Common Coding Vulnerabilities in Software-Development Processes