New GDPR Privacy Data Regulations

[graphicz]

There is a thread about the New GDPR Privacy Data Regulations on the wishlist section of this forum to which I have added a lot of information about GDPR and making sites compliant without needing to upgrade Sellerdeck (without warranty express or implied).

I do not wish to duplicate but as it is a current topic you can read about it here:

http://community.sellerdeck.com/show...t=57398&page=2

[Mantra]

Jonathan
I raised a question on the wish section topic on security of personal data retained at back office level concerning encryption of personal details contained in the ActinicCatalog database as yet unanswered and I wondered if you have a view on this aspect?
Martin
Mantra Audio

[graphicz]

This is just my personal view and without any warranty express or implied, but I don't see that back office security is down to the software (Sellerdeck). This is something we as business owners need to address and take respoonsibility for ourselves. It is about developing good practice in the acquisition and care of people's data as I have stated above.

I think we might need to keep site folders and snapshots on encrypted drives. Encryption is built in to Windows and its said not to slow the machine down.

I would suggest running the site folder off an external or second internal HDD and encrypting that.

https://www.pcworld.com/article/2308...tion-tool.html

[feemish]

Good idea but bitlocker isnt available on all Windows versions.
I am using Windows 7 professional and bitlocker isnt available on that.

[Mike Hughes]

I'd have to say that I don't think encryption of the hard drive does much in the way of protecting people's data anyway.

The biggest risks of loss of data have to be from a remote hack, unauthorised access or misuse / copying of the data by employees. Encryption of the hard drive doesn't achieve much at all in these circumstances.

What it will do is protect the data if your computer gets lost or stolen, which is probably a reasonable risk if you use sellerdeck on a laptop.

Mike

[graphicz]

It is all about taking a number of steps to ensure security, not just one thing. And taking all available steps...

[Mantra]

I would suggest running the site folder off an external or second internal HDD and encrypting that.

I set a separate partition on the office PC hard drive I was able to encrypt this drive using the Windows 8-10 bitlocker guidance given in the PC World article.

I copied the SellerDeck site folder over to this drive as suggested just to try it out and this worked fine - the site folder location path line in C:\ProgramData\SellerDeck\SellerDeck 2016\config.ini file needed to be changed to do this.

The only drawback is that once the folder has been encrypted within the drive, it can then only be accessed after the encrypted drive has been unlocked by a password or key entry.

I will be transferring all sensitive data file folders over to the encrypted drive including the Actinic database unless SellerDeck make other arrangements for this to be encrypted within the software application.

Martin

[Mantra]

I feel encryption is now more important than ever.
I have always considered personal data file to be at risk before the GDPR thing and particularly because the version of MS Access that SellerDeck use for its Actinic database does not have a file encryption facility. You do not even need to have Access to open the database as it can be opened quite readily in Excel.
On checking our anti-virus/firewall history today there is remote intrusion attempt logged every few minutes. Thankfully these are blocked, but I expect there will be an occasion when one gets through, also a risk if you disable the protection for a period that is sometimes needed to allow bug clearance fixes to run.
The key protection needed to set up encryption of folders, files and drives should also protect against unauthorised access as a password login is needed to unlock the encryption before folders/files can be opened.

Martin

[Mike Hughes]

It is all about taking a number of steps to ensure security, not just one thing. And taking all available steps..

I have to admit my reading is very different to this. This is an example what the GDPR says

Security of Data - Security of processing

1. Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk,

So it's about assessing the sensitivity of the data, the risks associated with processing it and taking appropriate measures that take into account what can be done and the associated costs. Nothing at all that I can see about taking all available steps....

Martin's encryption approach sounds like a good idea although clearly it will only work when the encrypted drive hasn't been unlocked. Still beneficial though.

[Duncan Rounding]

The important factor here that I see is, as Mike rightly points out, the need to do a comprehensive risk assessment with risk identification, likelyhood of occurrence and appropriate mitigation, and to document this and review it at regular, defined intervals.

If the worst should happen then you can at least demonstrate that you followed processes you had in place.

[Mike Hughes]

Looking into the encryption side of things, it seems encryption of an Access database using the built in functionality apparently isn't that secure anyway as the passwords are stored in open text in the database itself and can be retrieved with a bit of clever coding.

https://www.devhut.net/2016/08/19/wh...cure-database/

So Martin's approach of using bitlocker on a secure partition looks like it could be the easiest and most secure approach anyway. Although it does still have the problem that once the partition is unlocked the data in it becomes visible to other applications. (Which actually suits me, and I'm sure some others too, as I use a large excel spreadsheet to control stock, create sales reports, etc so being able to access the database is a good thing for me).

If Sellerdeck does think about encrypting the database, I'd like to see it look at encrypting Specific fields only (which could be selectable by us) such that we could encrypt specific user data such as names, addresses, email, etc (which we can export to a file if we need them for something else) and leave other data such as product codes, variables, stock levels, other order data, etc open for us to access in external applications.

[John Ennals]

A couple of arguments in favour of disk encryption (as opposed to no encryption):

- It's good to be able to state in your Privacy and Security Policy that your stored customer personal data is encrypted. If you draw your customers' attention to this they might start looking for, and sometimes not find, similar statements on your competitors' websites.

- If one of your customers becomes the victim of fraud through having their personal details stolen and they're trying to find the source of the data breach (and thus compensation), you will be in a stronger position to defend yourself against a false accusation if you can demonstrate that you're using some form of encryption.

However as Mike says, no form of encryption is completely secure. If data can be displayed on a screen, it can be nicked.

John

[Mike Hughes]

I have to admit I'm coming down to the same view on disc encryption of one sort or another.

Disc encryption absolutely isn't a solution to data security by itself , but

1. It does secure the data in the event of stolen or lost computer, laptop, backup drives, etc

2. There's generally no cost to implement and typically low impact in terms of computer performance or company processes.

Given the above it would seem an appropriate measure to take under the GDPR as part of an overall process and what's likely to be one of several measures taken to ensure appropriate data protection.

[Mantra]

The important factor here that I see is, as Mike rightly points out, the need to do a comprehensive risk assessment with risk identification, likelyhood of occurrence and appropriate mitigation, and to document this and review it at regular, defined intervals.

These were Mike's actual words,

So it's about assessing the sensitivity of the data, the risks associated with processing it and taking appropriate measures that take into account what can be done and the associated costs.

Risk assessment in my experience should be Hazard identification, followed by [L]ikelyhood/frequency of occurrence, [C]onsequence/severity (sensitivity of data), [R]isk [L] x [C] rating then mitigation to reduce risk rating to a level that is acceptable/tolerable, presented in the form of a log (tabular listing). My recollection is that a [R] = [L] x [C] rating of 5 and below was acceptable and between 5 up to and including 10 tolerable with control measures implemented.

I have seen this approach applied many times in industry for H & S assessments using a simple qualitative 5 x 5 matrix with [L] scored down from 5 (highly likely) 1 (extremely unlikely) and [C] scored up from 1 (very low severity) to 5 (catastrophic - extremely severe).

I know that SellerDeck are not in a position to offer guidance but is there any guidance out there on methods of risk assessment adopted that you could point users to?

A quantative risk assessment approach would be far more complex and beyond the scope of the majority of SellerDeck users, I think!

Cost and what is reasonable are factors that need to be taken into account as Mike states.

Martin

[graphicz]

Tooltips when already using jquery ui

If you are already using jquery ui for some other purpose the tooltips I have posted above may not work.

In which event you will need to use css.

You will need this image: http://www.graphicz.solutions/gdprcs...info-green.png

Add this css to your stylesheet:

.red {
      color: red;
  }
  
  /*=== ERIC ===*/
  .content-area form .checkout fieldset .InvoiceField, .content-area form .checkout fieldset div {
  position: relative;
}
   .eric, .def {
            border-bottom: 1px dotted #000000;
            color: #000000;
            outline: none;
            cursor: help;
            text-decoration: none;
            position: relative;
            left:0;            
			clear:both;
			float:left;
        }

        .eric span, .def span {
            margin-left: -999em;
            position: absolute;
        }

        .eric:hover, .def:hover {
			color:green;
		}
		.eric:hover span, .def:hover span {
            border-radius: 5px 5px;
            -moz-border-radius: 5px;
            -webkit-border-radius: 5px;
            box-shadow: 5px 5px 5px rgba(0, 0, 0, 0.1);
            -webkit-box-shadow: 5px 5px rgba(0, 0, 0, 0.1);
            -moz-box-shadow: 5px 5px rgba(0, 0, 0, 0.1);
            font-family: Calibri, Tahoma, Geneva, sans-serif;
			font-size:12px;
			font-weight:normal;
			line-height: 1.2em;
            position: absolute;
            left: 1em;
            top: 2.6em;
            z-index: 99;
            margin-left: 0;
            width: 250px;
			color:#111111;
			clear:both;
        }

        .eric:hover img, .def:hover img {
            border: 0;
            margin: -10px 0 0 -35px!Important;
            float: left;
            position: absolute;
        }

        .eric:hover em, .def:hover em {
            font-family: Candara, Tahoma, Geneva, sans-serif;
            font-size: 1.2em;
            font-weight: bold;
            display: block;
            padding: 0.2em 0 0.6em 0;
        }


        * html span:hover {
            background: transparent;
        }

        span.eric span, span.def span {
            background: #CADDCF;
            border: 1px solid #45C76D;
			padding: 0.5em 0.8em 0.8em 2em;
			clear:both;
			float:none;
        }
  /*== == == */
  .clearfloat { /* this class should be placed on a div or break element and should be the final element before the close of a container that should fully contain a float */
	clear:both;
    height:0;
    font-size: 1px;
    line-height: 0px;
}

And wrap your inputs in a span:

<span class="eric"><input type="text" id="idINVOICEFIRSTNAME" name="INVOICEFIRSTNAME" size="30" maxlength="40" value="<actinic:variable name="InvoiceFirstNameOnline" selectable="false" />" tabindex="NETQUOTEVAR:TABINDEXINVOICEFIRSTNAME"><span><img src="info-green.png" alt="Information" height="28" width="28" /><em>Information</em>To process and deliver your order we need to collect your name. <a href='info.html'><em>Privacy</em></a></span></span>

Test it at: http://www.graphicz.solutions/gdprcss/ add something to cart and mouseover the frst checkout page fields. If you want the tooltips on the progress bar add the spans there as well.