GDPR has gone into effect unleashing a flood of commentary, proposals for solutions, and tons of advice, some very good as well some not so good or even bad. It’s time to discuss planning and strategy for enterprises moving forward.
|Image courtesy of European Commission|
In fact, many companies already are taking action as they anticipate some version of GPDR being at least partially enacted, if not imposed in developed countries including the US. These may be initially presented as recommendations before taking on the form of federal regulations or laws, state laws or some mixture of the two. Current actions include limiting or even completely eliminating EU consumers access to services, publications or products.
In any case, hacker-driven incidents will continue. The risks, full costs and fines of Facebook-type occurrences are far from settled, and similar infractions are distinctly possible. Consumers and organized consumer interest groups can be expected to drive regulatory action by pressuring governments “to do something”.
How to Prepare
The question is what should a small and medium(SME) enterprise without a physical presence in the EU do? The first step is to determine which, if any, enterprise activities and actions will be potentially affected by a GDPR-like regulation. Then, develop a strategy. Here we are going to discuss general steps that all enterprises should take. In our next version of this report, there will be more specifics. None of the following should be considered to be or substitute for professional legal advice. It is intended for guidance and information purposes.
Enterprises need to examine their internal processes to consider how they could be changed or improved to align with GDPR principles. In some cases, this will mean incurring additional significant costs. Therefore, management oversight is critical. Pro-active activities are prudent. Waiting until there is external compulsion usually results in ballooning costs. Planning for necessary changes in advance means work can be done in a non-crisis, phased mode.
Initial action - Security
The first area to address is security. Given the level of criminal attacks, it is common sense to have ongoing efforts in this area. Evidence indicates that most companies have failed to take the threat of criminal hacking seriously enough. Virtually any company would be damaged and thrown into management turmoil if hackers penetrate their systems. Critical payroll data, personal data, and sensitive customer information are all at risk. Consider what happened to Sony when hackers penetrated their email system. That attack might have been North Korean hackers, but the results might have been worse if criminal hackers had been involved. The North Koreans’ apparent incentive was to disclose email contents to embarrass and punish Sony for making a movie that mocked their leader. Criminal hackers would not necessarily disclose the penetration. Instead, they could monetize the information for use in identity theft or other costly criminal purposes.
The prudent course is to begin with a security audit. In some cases, involving an outside consultant would be necessary. However, in many cases, it could be performed by internal auditors at relatively low cost. For example, investigations reveal that many systems operate with default ids and passwords. Critical systems, installed years ago, with these exposures were never corrected. Such security risks can be uncovered and fixed without expensive auditors by using someone with authorized access to the system. Another common problem occurs when the ids and accounts of ex-employees are not deleted. There are numerous other such security violations well documented. The point is to review and assure that proper polices have been implemented to fix such problems and prevent their recurrence.
There is another class of problems that demand more work to detect and fix. For instance, handy tools installed by IT to make their jobs easier might be applied to a criminal purpose in the hands of a hacker. Policies must be developed to avoid this situation. Sometimes, the solution is simple, i.e. removing tools from the system when not in use. In other cases, the tool might be critical for production. In such cases, it might be necessary for ongoing code audits to see that what it is doing is necessary. Anytime new software is installed on a system, it should be verified and checked to avoid introducing rogue code or viruses.
In the Equifax penetration, improperly maintained open source software caused the problem. A maintenance audit can uncover this problem. The institution of a rigorously enforced policy of careful maintenance for operating system, open source and all vendor supplied software, will help avoid the problem. When a vendor announces a flaw in their system (with or without a fix) one can guarantee that hackers are aware of the situation and will begin probing to find systems without the fix installed.
Despite taking all reasonable precautions, an installation might still be penetrated. Studies have shown that companies are very slow in detecting such events. There may be reasonable ways to improve this response. These should be standard practice. Clearly, once a penetration is detected corrective action should be taken immediately to limit damage.
If immediate detection is impossible or not feasible, full or partial encryption of data can be an alternative solution. The cost and overhead associated with encryption has dropped dramatically recently. It may not always be practical, or financially feasible, but it is worth investigating. As an aside, IBM provides pervasive encryption on mainframe Linux systems. Encryption needs to be evaluated in other environments.
In summary, most IT installations need to tighten their security. GPDR imposes rather severe penalties for disclosing confidential and personal information. It is good practice to take practical steps now. Let’s look at another area of enterprise risk not necessarily as obvious, but one that needs attention, personal data.
Personal data protection
GDPR privacy legislation intends to give citizens ownership and control of their personal data. This includes: 1) knowledge of what personal data is in a system 2) an ability to correct any errors, 3) ability to remove data, 4) information about when a data breach occurs and what was exposed, 5) ability to review data stored in the past upon request. Such past data might be important in tax, criminal or judicial matters or contract disputes. Consideration has to be given to how the data is protected, stored, and for how long it must be retained. All are a normal part of data storage and archival. GDPR sets some restrictive requirements on how quickly these must be available, and notifications sent. AND, penalties for non-compliance are high.
This raises the question about what happens when data retrieval isn’t possible from the current system. For instance, it has been corrupted in some way. System backups will need to be accessed. For historical data, the storage media is typically on tape.
Here is a cautionary tale from real-life. Several years ago, a colleague of ours started a company to update backup tapes. Old backup tapes were to be converted to CD or DVD format. The processed tapes were from a variety of companies and government agencies. He found that about ¼ (25%) of the tapes were bad. There were spots on the old, open reel tapes that were unreadable.
Unfortunately, the situation was actually somewhat worse. His process would only detect unreadable spots. In addition, there were readable records that were still wrong because they had been corrupted.
This story demonstrates the need to examine the process for controlling backups. This should not surprise anyone. Most of us have had the experience of trying to use a PC backup only to discover that the backup does not work. Failing to check a backup process, means that a failed process is revealed when most damaging. Most organization have a backup process that periodically ships tapes offsite; then forgets them. GDPR-type regulations mean it is wise to take steps to test that the backups work, and provide valid information. Addressing these issues will improve current operations while preparing for their critical need when some form of GPDR arrives.
We recognize neither of these issues were covered in great detail. Our goal has been to make the point that these and other areas need to be carefully examined along with privacy policies, data movement, network issues etc. There is a great deal of work to do here.
The likely arrival of GPDR-like regulations ought to make companies review and reconsider their policies in areas involving the acquisition, storage, use and protection of customer data. All of these will be impacted by such regulations. It is foolish to wait until the arrival of regulations that force mandatory change in a limited time period. Such a delay will likely raise the costs of review and remediation as well as risk costly fines for missing deadlines if breach is experienced. Of course, some flexibility is needed since the exact details of such regulation are not known currently.
Many vendors, including Compuware, IBM, Microsoft, HPE, BMC etc. are offering services and solutions (partial or comprehensive) that include process review definition, evaluation and planning services. Most recognize the need for implementation flexibility and openness to allow for advances in technology and regulatory changes. Be sure to verify this if you decide to employ a partner in your effort. Whatever you do, remember regulatory details will change and you must be able to adapt.
By starting today, enterprises and companies will have adequate time to study this issue and determine the best way forward. Finally, we are convinced there is no reasonable excuse to delay or wait for regulations to take steps to strengthen existing security. For most, there is much work to do. The best thing is to get started now.
In the next edition of this report we will discuss specific steps that companies without a physical presence in the European Union need to take to steer clear of being entrapped in the GPDR web.
Publication Date: June 4, 2018
This document is subject to copyright. No part of this publication may be reproduced by any method whatsoever without the prior written consent of Ptak Associates LLC.
To obtain reprint rights contact email@example.com
All trademarks are the property of their respective owners.
While every care has been taken during the preparation of this document to ensure accurate information, the publishers cannot accept responsibility for any errors or omissions. Hyperlinks included in this paper were available at publication time.