by Bozho | Nov 25, 2019 | Aggregated, ccpa, data protection, Developer tips, gdpr, Opinions, privacy
CCPA, or the California Consumer Privacy Act, is the upcoming “small GDPR” that is applied for all companies that have users from California (i.e. it has extraterritorial application). It is not as massive as GDPR, but you may want to follow its general recommendations. A few years ago I wrote a technical GDPR guide. Now I’d like to do the same with CCPA. GDPR is much more prescriptive on the fact that you should protect users’ data, whereas CCPA seems to be mainly concerned with the rights of the users – to be informed, to opt out of having their data sold, and to be forgotten. That focus is mainly because other laws in California and the US have provisions about protecting confidentiality of data and data breaches; in that regard GDPR is a more holistic piece of legislation, whereas CCPA covers mostly the aspect of users’ rights (or “consumers”, which is the term used in CCPA). I’ll use “user” as it’s the term more often use in technical discussions. I’ll list below some important points from CCPA – this is not an exhaustive list of requirements to a software system, but aims to highlight some important bits. Right of access – you should be able to export (in a human-readable format, and preferable in machine-readable as well) all the data that you have collected about an individual. Their account details, their orders, their preferences, their posts and comments, etc. Deletion – you should delete any data you hold about the user. Exceptions apply, of course, including data used for prevention of fraud, other legal reasons, needed for debugging,...
by Bozho | Nov 2, 2019 | Aggregated, cassandra, Developer tips
I’ve previously written about setting up Cassandra and Priam for backup and cluster management. The example that I gave for backup restore there, however, is not applicable in every situation – it may not work on a completely separate cluster, for example. Or in case of partial restore to just one table, rather than the whole database. In such cases you may choose to do a restore using the sstableloader utility. It has a straightforward syntax: sudo sstableloader -d 172.35.1.2,172.35.1.3 -ts /etc/cassandra/conf/truststore.jks \ -ks /etc/cassandra/conf/node.jks -f /etc/cassandra/conf/cassandra.yaml \ ~/keyspacename/table-0edcc420c19011e7a8c37656dd492a94 If you look at your Priam-generated backup, it looks like you can just copy the files (e.g. via s3 aws cp on AWS) for the particular tables and sstableloader import them. There’s a catch, however. In order to save space, Priam is using Snappy to compress all of the files. So if you try to feed them to any Cassandra utility, it will complain that they are corrupted. So you have to decompress them before using sstableloader or anything else. But how? Well, Priam offers a service for that – you call it by passing the absolute path to a compressed file and the absolute path to where the uncompressed should be placed and it does the simple job of streaming the original through a decompressor. For decompressing an entire backup, I’ve written a python script. It assumes a certain structure, but you can parameterize it to make it more flexible. Here’s the code (excuse my non-idiomatic Python, I’m only using it for simple scripting): #! /usr/bin/env python # python script used to pass each backup file through the decompression...
by Bozho | Oct 13, 2019 | Aggregated, blockchain, cryptography, Opinions
This week I have a talk on a meetup about blockchain beyond the hype – its actual implementation issues and proper use-cases. The slides can be found here: The main takeaways are: Think of blockchain in specifics, not in high-level “magic” Tamper-evident data structures are cool, you should be familiar with them – merkle trees, hash chains, etc. They are useful for other things as well, e.g. certificate transparency Blockchain and its cryptography is perfect for protecting data integrity, which is part of the CIA triad of information security Blockchain (a private one) can be a good enterprise integration solution for multi-organization setups where trust is required Many proposed use-cases can be solved with centralized solutions + trusted timestamps instead Usability is a major issue when it comes to wider adoption As with anything in technology – use the right tool for the job, as no solution solves every problem. The post Blockchain Overview – Types, Use-Cases, Security and Usability [slides] appeared first on Bozho's tech...
by Bozho | Sep 18, 2019 | Aggregated, data protection, Developer tips, Opinions
With the recent trend towards data protection and privacy, as well as the requirements of data protection regulations like GDPR and CCPA, some organizations are trying to reorganize their personal data so that it has a higher level of protection. One path that I’ve seen organizations take is to apply the (what I call) “Personal data store” pattern. That is, to extract all personal data from existing systems and store it in a single place, where it’s accessible via APIs (or in some cases directly through the database). The personal data store is well guarded, audited, has proper audit trail and anomaly detection, and offers privacy-preserving features. It makes sense to focus one’s data protection efforts predominantly in one place rather than scatter it across dozens of systems. Of course it’s far from trivial to migrate so much data from legacy systems to a new module and then upgrade them to still be able to request and use it when needed. That’s why in some cases the pattern is applied only to sensitive data – medical, biometric, credit cards, etc. For the sake of completeness, there’s something else called “personal data stores” and it means an architecture where the users themselves store their own data in order to be in control. While this is nice in theory, in practice very few users have the capacity to do so, and while I admire the Solid project, for example, I don’t think it is viable pattern for many organizations, as in many cases users don’t directly interact with the company, but the company still processes large amounts of their personal data....
by Bozho | Sep 6, 2019 | Aggregated, Developer tips, event logs, security, windows
Every organization needs to collect logs from multiple sources in order to put them in either a log collector or SIEM (or a dedicated audit trail solution). And there are two options for that – using an agent and agentless. Using an agent is easy – you install a piece of software on each machine that generates logs and it forwards them wherever needed. This is however not preferred by many organizations as it complicates things – upgrading to new versions, keeping track of dozens of configurations, and potentially impacting performance of the target machines. So some organizations prefer to collect logs remotely, or use standard tooling, already present on the target machine. For Linux that’s typically syslog, where forwarding is configured. Logs can also be read remotely via SCP/SSH. However, on Windows things are less straightforward. You need to access the Windows Event Log facility remotely, but there is barely a single place that describes all the required steps. This blogpost comes close, but I’d like to provide the full steps, as there are many, many things that one may miss. It is a best practice to use a non-admin, service account for that and you have to give multiple permissions to allow reading the event logs remotely. There are also multiple ways to read the logs remotely: Through the Event Viewer UI – it’s the simplest to get right, as only one domain group is required for access Through Win32 native API calls (and DCOM) – i.e. EvtOpenSession and the related methods Through PowerShell Get-WinEvent (Get-EventLog is a legacy cmdlet that doesn’t support remoting) Through WMI directly...
Recent Comments