TData is core to creating your IT Security Strategy. Knowing what data your business has, where it is and what it is is critical to your business security.
I will briefly discuss the different aspects of data lifecycle management below:
Data Classification
Data classification is critical in managing your business data appropriately, lack of classification means that you cannot apply appropriate access controls (Which we discuss in the next section) and it prevents you from adequately applying protection mechanisms as required for compliance (Such as GDPR for Personal Data and PCI DSS for credit card information). Effective classification involves several key steps.
- Identify data – Studies have shown that businesses are unaware of a significant amount of data on their business systems. A breach of data unknown to the organisation could remain undiscovered until it is leaked and the damage is done. A robust data discovery mechanism that identifies data location, type and access is an essential first step.
- Use Data Governance – Not all data is created equal. Whilst certain aspects of data may not be strategically important for a business, it may be sensitive enough to be controlled by regulatory requirements such as GDPR, HIPAA etc. It’s critical, once you’ve identified data pols, to understand what governance (if any) is in place to control the processing of that data.
- Create Categories – Data points can range into their millions, by creating categories, whether through their impact on the business (low, medium, high, critical), or through their definition in statutory frameworks such as the GDPR (Class A, A1, B, C), you can sort data points into manageable categories onto which you can apply priorities. In Appendix 5 of my book, I have given you some example classification tables for business and personal data. You can use these tables as a starting point. I’ve also given you an overview of Privacy Laws around the world, which may help you to get to grips with what applies to you (The IAPP maintains this list)
- Prioritise data – Once you have created your data categories, you need to assign the data to the categories. This is something that you should consider delegating to the data owner and custodians, since they are the ones creating, collecting and maintaining that data. Certain tools can be leveraged to automate the data classification.
- Budget – Effective Data Classification requires a budget, for the classification tools, the security and storage technologies.
- Keep Going – Data Classification is an ongoing process, not only is the business continually generating data, but the classifications of certain types of data may change over time. Your strategy needs to include the ability to review your data classification strategy.
Below is an example of a data classification table. Similar classifications can be made for data privacy or other regulatory controls where data needs to be classified. I go into Data Classification in some depth in my book, where you can find similar useable templates.
| Confidentiality Business Impact Access Traffic Light Protocol |
Definition |
Impact(CIA) C – Loss of Confidentiality |
Control Principles |
| Discussion | |||
| Low Non-Sensitive Public Access Clear |
Disclosure does no harm. | No confidentiality concerns. Information may be made freely available to the general public | Few or no controls applied. Information is already within the public domain or cleared for release. |
| This is the kind of information that a business will routinely make public. Declared financial records released to shareholders, marketing content, open source intellectual property etc. A business typically requires internal authorisation from the data owner or other stakeholder before information is transferred into this category. |
|||
| Medium Operational Internal-only Green |
Disclosure causes minor embarrassment or minor operational inconvenience. | Minor impact on reputation but no legal or regularity impact. Impact falls within Risk tolerance. |
Normal levels of security and controls. Data can be accessed within the boundaries of operational need. Storage and transmission does not require additional security or encryption |
| Internal memo’s, discussion and operating manuals about business operations. Organisational charts, email and internal phone numbers etc. Any data waiting for release into Public Access category. | |||
| High Important Restricted/Confidential Amber |
Disclosure has a significant short-term impact on operations or tactical objectives. | Serious short-term impact, loss in revenue over the short term) There may be some legal or compliance impact. Impact falls outside of agreed Risk Tolerance |
High level of security and control. Access restricted on a least privilege basis to appropriate business roles. Encryption of data at rest and in transit required. |
| Operations discussions, project plans, low level financial information, system configuration, source code, vendor contracts. | |||
| Very High Critical Highly Confidential/Privileged Access Red |
Disclosure has a serious impact on long term strategic objectives or puts the survival of the organisation at risk. | Unacceptable long-term financial impact. Extreme and lasting impact. Potentially existential treat to one or more business unit or revenue stream. Impact on business is outside Risk Capacity |
Highest level of security and control. Access granted on an individual basis by data owner. Access list must be maintained by data owner and regularly audited. Encryption of data at rest and in transit must be assured. |
| Strategic business information, M&A information etc. Trade secrets, R&D. Information that would impact share prices. Information that could impact competitive advantage. Passwords, digital certificates etc. Personal Data protected by law. Detailed financial information. | |||
Data Collection and Creation
The first part of the Data Lifecycle is Data collection, and the general rule of thumb here is “Only collect data that you need in order to complete the tasks it is needed for.” Clearly this is challenging but it aligns with the GDPR Article 5.1.b that require you to only collect personal data for a specified, explicit and legitimate purpose. Data Collection is defined under the GDPR Article 4.2 as “Processing” and is thus a controlled activity. It is wise to apply this to the collection or creation of all sensitive business data. The less data that you have collected or created, the less data you have that may be subject to breach.
Data Storage and Transmission
Having classified your data, you must decide how each data class may be stored, processed and transmitted. What access controls do you have in place? Does it need to be encrypted at rest, in transit, is it so sensitive that it must also be encrypted while in use? Do you need to employ Data Loss Prevention mechanisms? These risk decisions can be applied to entire categories of data. A Data Encryption schedule (As shown below and found in my book) will help you decide whether data encryption should be mandatory or optional under specific circumstances.
Data in Transit |
Data at Rest |
|||
| Traffic Light Protocol | Internal | External | Internal | External |
| Red | Mandatory | Mandatory | Mandatory | Mandatory |
| Amber | Optional | Mandatory | Mandatory | Mandatory |
| Green | Optional | Optional | Optional | Optional |
Data Disposal and Destruction
You will need to create specific data disposal policies based on circumstances when disposing of data. A data retention schedule should be assigned to data, and a Data Disposal Decision Treewill tell you whether the data can be disposed of. Your strategy should assign retention periods and destruction methods based on classification.
You also need to consider methods of destruction. Again, employing a traffic light protocol will allow you to understand whether physical destruction of hard drives is required, or whether hard disk wiping or reformatting and putting back into service is sufficient given the sensitivity of data.
(Have I mentioned that you can find all this in my book yet?)
Backup, Disaster Recovery and Business Continuity
Finally, you need to consider backup and disaster recovery strategies.
Your backup strategy should be dependent on your data classification, it should cover the backup schedule, data redundancy and off-site and offline requirements (Offline backups cannot be impacted by a ransomware outbreak for example), whether you use incremental or full backups, testing and verification scheduling.
Your disaster recovery strategy should cover your backup strategy, but in addition, it should include a Business Impact Analysis (BIA), a Disaster Recovery Plan (DRP), Your Backup Infrastructure, whether you use data replication and mirroring (which can be subject to ransomware), Testing and maintenance scheduling and methodology, communication and coordination between stakeholders, documentation including technical configurations, network diagrams and contact details, as well as and training requirements for relevant personnel. The strategy should also include a continuous improvement strategy, ensuring that when testing (or a real disaster) shows a flaw, that is fed back and the strategy is improved.
Disaster recovery is time-dependent, you need to create metrics such as RTO (Recovery Time Objective), RPO (Recovery Point Objective), Work Recovery Time (WRT), SDO, MTD, MTO, MTTD, MTTR, MTBF, and MTTRp. (All of these are, no surprise, explained in my book) Your testing should be compared to these, and should be fed back into your Disaster Recovery Strategy to improve the system until the desirable metrics are achieved.
Disaster Recovery Testing can take the form of different types, including a checklist review, tabletop testing, simulation testing, and full interruption testing (Which is doing a full disaster recovery on live systems) and the frequency of these tests should be mandated in your strategy.
Business continuity differs from disaster recovery in that DR is the method and practices used for bring a business back on line following a disaster. Business Continuity is the methodology and practices employed to keep the business running WHILE a disaster is still in progress (even if at a reduced capacity). So while DR might be considering how to retrieve data, BC would be considering failover options for data systems.
Traffic Light Protocol
The Traffic Light Protocol (TLP) is a system for classifying sensitive information created in the early 2000s by the UK Government’s National Infrastructure Security Co-ordination Centre, in order to encourage greater sharing of sensitive information. It is described in detail in Annex C of ISO 27010 as well as in my book.
It can be used within your organisation to clearly define how data should be handled, for example, by using it in the backgrounds of your documents or business emails. If you use it, it is essential that everyone in your organisation understands how and when to use it, it should be part of the onboarding training and your general business security culture.
| Colour | Explanation |
| Red | Personal for Named Recipients Only. In the context of a meeting, for example, RED information is limited to those present at the meeting. In most circumstances, RED information will be passed verbally or in person. |
| Amber | Limited Distribution. The recipient may share AMBER information with others within their organization, but only on a ‘need-to-know’ basis. The originator may be expected to specify the intended limits of that sharing. |
| Green | Community Wide. Information in this category can be circulated widely within a particular community. However, the information may not be published or posted on the Internet, nor released outside of the community. |
| White | Unlimited. Subject to standard copyright rules, WHITE information may be distributed freely, without restriction. |