WINTER 2023-2024 EDITION

GPSJ WINTER 2023 2024 LATEST

April 2024
M T W T F S S
1234567
891011121314
15161718192021
22232425262728
2930  

Archives

Encryption and GDPR – Where do you Stand?

Reporter: Seymour Roach

Data encryption is nothing new as a need or requirement for an organisation, but since the EU’s General Data Protection Regulation (GDPR) came into force last May, it allows anyone in the Government or public sector a simple and effective way to comply with the legislation.

Article 32 requires “the pseudonymisation and encryption of personal data” and while it is by no means a get out of jail free card, it is a defence. That is because Article 34 suggests that should a breach take place, when data is encrypted, there is no requirement to contact each of the subjects affected by this data loss, something which could prove costly in time, effort and money.

Encryption procedures make achieving compliance a far more attainable goal. For the average employee and contractor working on a corporately-supplied device or through a Bring Your Own Device (BYOD) policy, it should be automatic and invisible, embedded within a holistic information security plan.

Organisations are not concerned whether primary numbers, multiple algorithms, symmetric and asymmetric keys or a plethora of three letter acronyms are used. They just want to know it works and can be trusted. If the bits and bytes at risk on their devices are impossible to read, any attack will fail.

Keeping data secure is imperative to any organisation handling sensitive information but it is especially prescient to Government. We have seen in the past newspaper headlines telling how devices – whether laptops, mobile phones or removable media such as USBs – were lost or stolen, and they contained hugely sensitive security plans, phone numbers or addresses.

One key point of an encryption approach is to have everything as locked down as possible and ensure all PII is encrypted in transit and at rest. This should include the mandating of a FIPS certified, hardware encrypted mobile storage device and the enforcement of its use.

Encryption must be correctly implemented with sufficiently strong encryption keys. Ideally these would be protected in hardware, meaning the only method of attack left is brute force which, if managed correctly within the device, can be limited to a defined number of attempts by policy. Additionally, policies focused on whitelisting and locking down USB ports so they can accept only approved devices, are also vital.

Encryption is especially crucial for work carried out off-site, at home, or on the move. For example, research by Apricorn found half of respondents (44%) agreed their organisation expects their mobile workers to expose them to the risk of a breach. A third (32%) also said their organisation has already experienced a data loss or breach as a direct result of mobile working.

This is why organisations must take time to research, identify and mandate corporate-standard, hardware encrypted devices. They must also educate employees on the best practice in using them to mitigate the risk of a breach and potential fines.

This will take some effort across government and public sector departments but in the digital age when data is taken, sorted and used in transit or the cloud or simply sits there at rest, the potential for it to be compromised is huge. It is important though that encryption is not focused solely on the storage layer as this leaves other unprotected points vulnerable to attacks.

Without the right encryption, data can be taken as easily from internal servers as it can during external wireless transfers. This can be down to sophisticated hacking techniques or simply due to complacency or human error. So it is vital to remember that you can encrypt your data at many levels and ultimately it must be a top level decision and action. The end user should never be left with a decision to encrypt or not.

Leave a Reply

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  

  

  

This site uses Akismet to reduce spam. Learn how your comment data is processed.