Announcement

Collapse
No announcement yet.

New GDPR Privacy Data Regulations

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Hughes
    replied
    So where does that leave us?

    If we assume that we should be protecting Level 3 Consequence data to at least a Level 3 mitigation level then we end up saying that in general the acceptable Risk level is somewhere around 9 or less (Being the Consequence x Protection Level)

    This seems fair enough and I'm sure for each Hazard we can assess the Likelihood of occurrence and therefor work out what level of mitigation is acceptable.

    There are a couple of immediate thoughts that come to me from looking at this.

    1. Being able to reduce the Consequence risk by encryption of the sensitive data in Sellerdeck would immediately make our task much easier to achieve and much more secure overall. I realise this in itself is really a mitigation factor but it's certainly something I'd like to see (for the sensitive data only much as it has been done for card details in the past. And ideally for selectable fields).

    2. If the assumption is correct that storing passwords raises the Consequence level because of their sensitivity (as these are often used by the individual across several sites) then that does suggest there's an impact on the level of mitigation we need to be using. Does anyone know if the user passwords to access order progress, etc are encrypted in the sellerdeck database as that would potentially be of benefit in achieving the desired data protection as well. Alternatively, it might be better to not offer that facility because of the security implications and the extra cost of protecting them to an appropriate level.

    Mike

    Leave a comment:


  • Mike Hughes
    replied
    And then for the level of protection / mitigation I'm thinking of a scale that goes somewhere along the lines of:

    Level 1 - State of the Art

    Top level protection across the board with state of the art measures to provide physical barriers, network protection, computer protection, data protection, effective procedural measures and counter measure systems to identify and protect data through intrusion detection, honey traps, etc.

    In terms of implementation efforts, this is the kind of stuff banks, government agencies, etc should be doing.

    Level 2 - Professional Implementation

    Similar in scope to the above but may not using the best, latest and most effective measures. Still professionally implemented by people who know what they're doing.

    This is the stuff you'd expect most large companies should be doing to protect data that is maybe not the most sensitive.

    Level 3 - Practical Implementation

    Systems implemented to a practical level by people who aren't experts in their fields. Still using a good level of security for data loss mitigation where appropriate. So using decent firewall, good anti-virus software with regular updates, strong passwords for computer / wifi / encryption, hard disc encryption, etc.

    This is probably the level we should all be aspiring to.

    Level 4 - Practical with some clear weaknesses.

    Similar to Level 3 but maybe with some weakness that make the system less secure. Maybe use weak passwords, free anti-virus, only update software occasionally, don't use encryption on the hard disc, maybe carry a laptop around with them containing the data, etc.

    Level 5 - Poor.

    Any system that doesn't achieve the higher standards.

    Leave a comment:


  • Mike Hughes
    replied
    I'm going to make a first attempt at quantifying the Consequence / Sensitivity of data side of things.

    I see the scale of consequence / sensitivity (on a scale of 1 to 5 where 5 is the most serious) as being somewhere along the lines of :

    5: Incredibly sensitive data such as medical records, sexual persuasion, bank records, passport details, credit card details, email servers, credit history, etc. This is stuff that you rightly expect to be protected to the highest level and never exposed publicly.

    4. Less sensitive data but still private data that can have serious consequences. Things like political leanings, passwords, purchases from adult websites, photo storage servers, etc.

    3. Name, address, phone number and email contacts etc. Things you expect to be kept private but that might be available from public records, phone directories, etc and that aren't that sensitive really because of the low impact of their exposure and / or can be changed without much difficulty if required (such as phone numbers and email addresses, etc).

    2. Randomised / encrypted data with nothing that can be used to identify an individual or reveal any private data about them.

    To my way of thinking, most of us as retailers will be at a consequence level of 3. Those of us that sell sensitive items such as adult goods or use passwords to access purchase history, etc might be at a higher level of 4.

    If Sellerdeck encrypted the names, addresses, passwords and contact details in the database then the consequence level would probably drop to a 2.

    What do you think? Does this work as a starting point for assessing the consequences / sensitivity of a data breach?

    Leave a comment:


  • Mike Hughes
    replied
    I wrote this post a few days ago but for some reason the forum won't let me post it. I'm going to try it in bits and see if I can do it this way. --> I've made it eventually.

    I've spent a little time considering the various opportunities for customers data to be accessed and what kind of measures might be appropriate to mitigate them. I'm sure the list isn't complete so please feel free to add, comment, disagree as you like. It would be good if we could come up with a list of risks and measures that covers most of the bases.

    1. Early access / Interception. (data open to access coming in / going out of the secure system)

    Prevention:

    - Encrypt the webpages with SSL.
    - Encrypt customer orders while on the Server
    - Encrypt the customer emails, uploads, etc - Coming in Sellerdeck 2018

    2. Loss or theft of hardware (Computer / Laptop / Backup drives)

    Prevention:

    - Encrypt the data on the storage media
    - Secure access to the computers (strong passwords, HW Keys?)

    3. Malicious Access (hackers, viruses, etc)

    Prevention:

    - Protect the network - HW Firewall on router, secure WiFi, etc
    - Protect the computer. Effective Firewall, Anti Virus, etc with regular updates and scans.
    - Encrypt sensitive data in the database *** 'someword' (and/or just data that can identify the individual)

    *** The forum won't let me post an explanation of this using brackets. It keeps saying "Forbidden You don't have permission to access /editpost.php on this server." ??? It looks as if it doesn't like to see 'database' followed by a '(' which is why I've added 'someword' above..


    4. Unauthorised Access

    Prevention:

    - Password protect the computer.
    - HW keys?

    One of the things that I am thinking about is Hardware keys and whether I can arrange it so that an encrypted partition can only be access when a USB key is in the computer. I think Goldkey do one but I suspect the cost might be a bit excessive for this kind of application. Whether it's needed for most SMBs I don't know.

    PS. I like Martin's approach to quantifying / assessing the risk.

    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).
    If we can agree a suitable list of hazards then it shouldn't be too hard to come up with a reasonable assessment of the Likelihood of occurrence for various approaches to mitigation.

    Leave a comment:


  • Mantra
    replied
    Originally posted by graphicz View Post
    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.
    Thank you for this, Jonathan.
    Some usefull CSS application code here.
    Only problem is with the test site, I tried this out and it works fine but my wife caught a glimpse of the screen displaying the white gold diamond solitaire ring and thought I was shopping around for a surprise gift for our wedding anniversary next week.
    Martin

    Leave a comment:


  • graphicz
    replied
    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:

    Code:
    .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:

    Code:
    <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.

    Leave a comment:


  • Mantra
    replied
    Originally posted by Duncan Rounding View Post
    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

    Leave a comment:


  • Mike Hughes
    replied
    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.

    Leave a comment:


  • John Ennals
    replied
    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

    Leave a comment:


  • Mike Hughes
    replied
    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.

    Leave a comment:


  • Duncan Rounding
    replied
    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.

    Leave a comment:


  • Mike Hughes
    replied
    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.

    Leave a comment:


  • Mantra
    replied
    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

    Leave a comment:


  • Mantra
    replied
    Originally posted by graphicz View Post
    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

    Leave a comment:


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

    Leave a comment:

Working...
X