Month: April 2014

Last week Ultan O’Carroll of the Data Protection Commisioner’s office gave an excellent presentation on best practice policies for data protection.

Below is a quick snapshot of some key points.

Knowing your data – “If there is anything you need to know – know what data you have and categorise it in some way – whether it is personal, financial and so on” . He further advised delegates that apart from categorising your data, “you need to know where your data is – whether it is on tape, on disk, on your production server and so on”

“Access ontrol” data among your employees – “Not everyone needs to see all the personal data that you hold” For example, sometimes your admin staff only need to  have access to the address details of your customers. If the data is not within their remit, they need not be privy to it. All of this goes back to “knowing your data”.

 Use access logging  – Finding out “who logged in when”, “whether it was local or remotely” and “what password they used”. “We often see things go wrong at this level” said O’Carroll.

Have a plan to deal with data breaches within your organisation –  Dealing with data breaches in an ad-hoc fashion is not the best way. Data controllers must have a plan in place.

Software patching – You should have a policy in place for the patching of software and it needs to be enforced. “We often find that top-level security patches get released but they are only applied for 3 – 6 months after that. In that window, hackers will try to do some reconnaisance on your site”.

Passwords – Having a robust password policy in your business or organisation is essential. For example,  users using the same passwords for their Facebook account and their company database is not secure. Moreover,  passwords need to be transmitted and stored securely. For example, emailing or storing passwords in clear text is not good practice.

Use third parties to independently test your security – There are specialists who can independently test the security of your I.T. infrastrcture. These often have their own sub-specialisations. For example, one penetration tester might specialise in         e-commerce payment gateways whilst another might specialise in network penetration testing.”Test it and test it again”  is the advice.

Whilst the above points are just guidelines on data protection best practice – the best data protection systems are often built from the ground up. If you want to find out more information implementing better data protection, an excellent ressource  is    “The Privacy Engineer’s Manifesto” by Dennedy, Fox and Finneran.  The authors espouse the view that “privacy will be an integral part of the next wave in the technology revolution and that innovators who are emphasizing privacy as an integral part of the product life cycle are on the  right track”.

The ebook version of the book is free to download at:

http://www.apress.com/9781430263555

Last week, we got a call from a Dublin physiotherapist`s practice. Their Dell Poweredge server, configured in RAID 5, had failed.

Their I.T support technician identified the problem immediately. However, for him data recovery from a RAID 5 server was unknown territory. For this blog post, here is an abridged version of the RAID recovery process which we used.

For recovery we decided to use Mdadm.  It is a powerful linux-based RAID recovery utility. A good knowledge of Linux command line and in-depth experience of this tool are essential prerequisites for it’s operation.

The first step in the recovery process was to deterimine the status of the server’s drives in-situ.

We used the following command on every disk in the array:

            mdadm – -examine

We were able to determine that drives /dev/sdc1 and /dev/sdd1 drives had failed (sdc1 being in worse condtion). Mdadm revealed that this RAID 5 had experienced double-disk failure.We then carefully labelled each drive and removed them from the server. Then, using a specialised hardware disk imager – we imaged the disks. This means that we would be working on copies of the disks rather than the original ones. In the unlikely event of the data recovery process being unsuccessful – the original configuration and data, as we received it, would still be intact.

The imaging process completed successfully. We now put the imaged drives into the server. With all the prep work completed. It was now time to take the RAID array “offline”. This can be achieved by using the “mdadm –stop” command. The last thing we wanted was for the RAID rebuilding process to start using a failed disk in bad condition  (e.g. /dev/sdc1) To prevent this from happening, we cleared the superblock of this drive using the command:

            mdadm –zero-superblock /dev/sdc1

Now using the output we got from mdadm –examine, we used the following command to  rebuild the array:

            mdadm –verbose –create –metadata=0.90 /dev/md0 –chunk=128 –level=5 –        -raid-devices=5 /dev/sdd1 /dev/sde1 missing /dev/sda1 /dev/sdb1

We now had to check whether the array was aligned correctly using the command:

            e2fsck -B 4096 -n /dev/md0

Using e2fsck it is always helpful to specify the block size before a scan to get a more accurate status of the array. We also used the -n prefix in case the array was mis-aligned and e2fsck attempted to fix it. ( e2fsck should never be executed on an array that is potentially mis-aligned)

 

E2fsck completed successfully and correctly identified the status and alignment of the array.

It was now safe to proceed with the repair and fix command

 

            e2fsck -B 4096 /dev/md0

Notice that no “-n” was used this time. The scan took around 5.5 hours to complete. It found over 26 inode errors, hundreds of group errors and some bitmap errors.

Now, it was time to add the first failed drive back into the array. We used the command:

            e2fsck -a /dev/sdc1

The RAID array now began to rebuild. After a couple of hours, the RAID 5 was totally re-created, albeit in degraded mode. But the the volume was mountable again and all data was now accessible.

The client had over 4 years of Sage Micropay and Sage 50 accounts files on the server. In addition, they had over 6 years worth of PhysioTools data files. This is a software package which they used to create customised exercise regimes for their  patients.  Reconstructing accounts and staff payslips would have been very time consuming and costly. For their staff to re-create patient exercise regimes, it would have incurred a huge time burden on them. Moreover, it would probably have been professionally damaging for thier reputation if they had to inform their patients that their customised exercise regimes had been “lost”.

We advised the client on some best-practice back-up strategies so they could prevent data loss in the future. It is deeply satisfying to help a customer like this when the “plan B” option would have been so disruptive for them. They could now get back to helping their patients with minimum downtime to their business.

.