All posts by Bozho

One-Time Passwords Do Not Provide Non-Repudiation

Post Syndicated from Bozho original https://techblog.bozho.net/one-time-passwords-do-not-provide-non-repudiation/

The title is obvious and it could’ve been a tweet rather than a blogpost. But let me expand.

OTP, or one-time password, used to be mainstream with online banking. You get a dedicated device that generates a 6-digit code which you enter into your online banking in order to login or confirm a transaction. The device (token) is airgapped (with no internet connection), and has a preinstalled secret key that cannot be leaked. This key is symmetric and is used to (depending on the algorithm used) encrypt the current time, strip most of the ciphertext and turn the rest into 6 digits. The server owns the same secret key, does the same operation and compares the resulting 6 digits with the ones provided. If you want a more precise description of (T)OTP – check wikipedia.

Non-repudiation is a property of, in this case, a cryptographic scheme, that means the author of a message cannot deny the authorship. In the banking scenario, this means you cannot dispute that it was indeed you who entered those 6 digits (because, allegedly, only you possess the secret key because only you possess the token).

Hardware tokens are going out of fashion and are being replaced by mobile apps that are much easier to use and still represent a hardware device. There is one major difference, though – the phone is connected to the internet, which introduces additional security risks. But if we try to ignore them, then it’s fine to have the secret key on a smartphone, especially if it supports secure per-app storage, not accessible by 3rd party apps, or even hardware security module with encryption support, which the latest ones do.

Software “tokens” (mobile apps) often rely on OTPs as well, even though they don’t display the code to the user. This makes little sense, as OTPs are short precisely because people need to enter them. If you send an OTP via a RESTful API, why not just send the whole ciphertext? Or better – do a digital signature on a server-provided challenge.

But that’s not the biggest problem with OTPs. They don’t give the bank (or whoever decides to use them as a means to confirm transactions) non-repudiation. Because OTPs rely on a shared secret. This means the bank, and any (curious) admin knows the shared secret. Especially if the shared secret is dynamically generated based on some transaction-related data, as I’ve seen in some cases. A bank data breach or a malicious insider can easily generate the same 6 digits as you, with your secure token (dedicated hardware or mobile).

Of course, there are exceptions. Apparently there’s ITU-T X.1156 – a non-repudiation framework for OTPs. It involves trusted 3rd parties, though, which is unlikely a bank scenario. There are also HSMs (server-side hardware security modules) that can store secret keys without any option to leak them to the outside world that support TOTP natively. So the device generates the next 6 digits. Someone with access to the HSM can still generate such a sequence, but hopefully audit trail would indicate that this happened, and it is far less of an issue than just a database breach. Obviously (or, hopefully?) secrets are not stored in plaintext even outside of HSMs, but chances are they are wrapped with a master key in an HSM. Which means that someone can bulk-decrypt them and leak them.

And this “can” is very important. No matter how unlikely it is, due to internal security policies and whatnot, there is no cryptographic non-repudation for OTPs. A customer can easily deny entering the code to confirm a transaction. Whether this will hold in court is a complicated legal issue, where the processes in the bank can be audited to see if a breach is possible, whether any of the admins has a motive to abuse their privilege and so on, whether there’s logs of the user activities that can be linked to their device based on network logs from internet carriers, and so on. So you can achieve some limited level of non-repudiation through proper procedures. But it is not much different than authorizing the transaction with your password (at least it is not a shared secret, hopefully).

But why bother with all of that if you have a mobile app with internet connection? You can just create a digital signature on a unique per-transaction challenge and you get proper non-repudiation. The phone can generate a private key on enrollment and send its public key to the server, which can later be used to verify the signature. You don’t have the bandwidth limitation of the human brain that lead to the requirement of 6 digits, so the signature length can be arbitrarily long (even GPRS can handle digital signatures).

Using the right tool for the job doesn’t have just technical implications, it also has legal and business implications. If you can achieve non-repudiation with standard public-key cryptography, if your customers have phones with secure hardware modules and you are doing online mobile-app-based authentication and authorization anyway, just drop the OTP.
.

The post One-Time Passwords Do Not Provide Non-Repudiation appeared first on Bozho's tech blog.

Спам от името на държавни институции?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3473

Миналата седмица от името на МВР беше изпратен спам. МВР не е хакнато, но в интернет всеки може да се представи за всеки и да изпрати вирус или линк, в който да си въведете паролата или номера на кредитната карта.

Изпращането на спам/фишинг от името на някоя държавна институция е хитра стретегия – изпращат ти фиш, данъчно задължение, призовка, болничен лист, документи за обществена поръчка и дори, защо не, съобщение от министър-председателя. Ако домейнът на изпращача наистина е съответстващия на институцията (mvr.bg, nap.bg, government.bg, parliament.bg), е по-вероятно повече хора „да се вържат“.

Какво могат да направят институциите, обаче? На пръв поглед – нищо. Всеки може да прати имейл от фалшив адрес и да се представи за институция. Само че институциите всъщност има какво да направят – поне за да не могат злонамерените изпращачи да злоупотребяват с домейна им и така да дават допълнителна достоверност на своя имейл. Има няколко настройки (DNS записи), които всеки притежател на домейн може и трябва да направи, за да гарантира, че никой няма да може да изпраща имейли от негово име. Или по-скоро – ако изпраща, системите за електронна поща ще ги класифицират автоматично като спам.

Техническите детайли съм описал тук, но с две думи, собственикът на домейна посочва от кои IP адреси е позволено да се изпращат мейли от името на неговия домейн, както и публичния ключ, с който да се валидира електронния подпис върху имейлите (да, мейлите автоматично се подписват електронно от системата за електронна поща, макар че това не е познатия ни квалифициран електронен подпис). И не на последно място – посочва какво да прави получателят на писма от неговия домейн, ако някоя от предходните проверки се провали – дали да го праща в „спам“ или не. Това са т.нар. SPF, DKIM и DMARC DNS записи.

Реших да проверя колко от институциите са направили тези настройки. И за съжеление, резултатът не е твърде добър. В таблицата по-долу съм показал 39 институции и дали те имат или нямат съответния DNS запис. На места има въпросителни – по принцип DKIM може да се провери само ако си получил имейл от съответния домейн, защото DNS записът включва селектор, който може да е произволен. Направил съм проверката с най-често срещаните селектори (default, selector, dkim, selector1) и съм допълнил информацията с ръчна проверка в собствената ми поща с мейли от съответните институции. Ако не мога да определя дали има или няма DKIM, съм сложил въпросителна. На места има „не“ по презумпция – ако нямаш нито един от другите два записа, едва ли ще имаш DKIM. Със звездичка в колоната DMARC са отбелязани институциите, които имат DMARC политика, но тя инструктира получателя да не прави нищо специално, ако проверките се провалят (вместо да го инструктира да сложи писмото в спам). С болд са „шампионите“ – тези, които са си настроили нещата както трябва.

ИнституциядомейнSPFDMARCDKIM
Агенция по вписваниятаregistryagency.bgДаДаНе
Агенция Митнициcustoms.bgДаДа*Да
АГККcadastre.bgДаДаДа
ВССjustice.bgДаДаДа
ГРАОgrao.bgДаДа?
ДАЕУe-gov.bgДаНеНе
ДАНСdans.bgДаДа*?
ДАТОdato.bgНеНеНе
МВнРmfa.bgДаНеНе
МВРmvr.bgДаНеНе
Министерство на енергетикатаme.government.bgДаДа*Да
Министерство на здравеопазваентоmh.government.bgДаНеНе
Министерство на икономикатаmi.government.bgДаДа*Да
Министерски съветgovernment.bgДаНеНе
Министерство на спортаmpes.government.bgНеНеНе
Министерство на културатаmc.government.bgНеНеНе
Министерство на отбранатаmod.bgДаДа*?
МОНmon.bgДаНеНе
МОСВmoew.government.bgДаНеНе
Министерство на правосъдиетоjustice.government.bgДаНеНе
МРРБmrrb.bgДаНеНе
Министерство на туризмаtourism.government.bgДаНеНе
МТИТСmtitc.government.bgДаДа*Не
МТСПmlsp.government.bgДаНеНе
МФminfin.bgДаДаДа
НАПnap.bgДаНеНе
НАПnra.bgДаДа*Не
НЗОКnhif.bgНеНеНе
Народно събраниеparliament.bgНеНеНе
Президентpresident.bgДаДа*Да
Община Бургасburgas.bgДаНеДа
Община Варнаvarna.bgНеНеНе
Община Пловдивplovdiv.bgДаНеНе
Столична общинаsofia.bgДаНеНе
Търговски регистърbrra.bgНеНеНе
КЗЛДcpdp.bgДаДаДа
КЗКcpc.bgНеНеНе
КФНfsc.bgДаДа*?
КРСcrc.bgНеНеНе
CERTgovcert.bgНеНеНе

Това ли е най-важната мярка за киберсигурност? Не – в киберсигурността (и киберустойчивостта) няма най-важна мярка. Всичко е серия от мерки, които покриват серия от рискове и уязвимости. Има много какво да се желае от киберсигурността в публичния сектор. Базовите настройки са едно добро начало – както за изпращане на имейли, така и за криптирането им. Но продължаваме да нямаме системно усилие за адекватна киберсигурност, което да дава резултат. Има закон, наредба, съвет, вицепремиер. Но явно няма сисадмин, който да настрои едни записи. И няма политика, насочена към това, да има такъв сисадмин навсякъде.

Solving Problems Properly Is Often Not Viable

Post Syndicated from Bozho original https://techblog.bozho.net/solving-problems-properly-is-often-not-viable/

How many times you, as a software expert, saw some software or process and thought “damn, this can be done so much better”. Yes, a lot. But why, since large organizations spend a lot of money on IT? Is it because software is too complex, is it because of organizational issues, is it legacy software, or just the way things are?

And if what we see is so bad, isn’t common market sense saying that surely these companies will be disrupted and made obsolete by a new and better competitor? I won’t give a definitive answer why software is bad (I have already blamed developers, though I admit, developers are only a part of the problem). But I’ll try to reason about what it’s not getting replaced under market forces.

Peter Thiel in his book “From Zero to One” says that a a new product has to be at least 10 times better in order to be disruptive. Everything below that is just gradual improvement over the status quo. Google was 10 times better than AltaVista, Lycos and Yahoo as a way to find information on the web. Skype was 10 times better than whatever was out there before that. But most of the things that we see as broken don’t get fixed because there’s no 10x improvement that would kill them. Let’s take a loot at a few examples.

Banking. Banking is horrible. Online banking UX is usually on par with a legacy ERP, bank transfers rely on a patchwork of national specifics and ages old international standards like SWIFT. I can’t really think of anyone who really likes their online banking. Mobile banking is even worse, as, of course, it’s tedious to copy-paste IBANs on a phone. Banks are, in many cases, still running COBOL on mainframes, and it’s really hard and expensive to get something changed or fixed. Why they are still around? Because the experience of the online banking is of marginal importance to the bank’s bottom line.

Yes, Revolut and TransferWise are cool tech billion-dollar-valuation startups that are “disrupting” banking. But not really. They are just fancier banks. Yes, finally you can do something on your mobile and you can be onboarded without going to a physical office and support is better and the UI is sleek, and the UX make sense. Do banks care? Not much. Because these startups are just small banks that are currently losing money in order to get to more people and make them spend small amounts online. Nothing of that is a 10x improvement in the value provided. It surely is much better technically, but once you have to transfer money elsewhere, you hit SWIFT or ideally SEPA. Once you want to pay in store, you hit Visa or MasterCard. Nothing of the legacy infrastructure is replaced, we just have better UX for, in many cases, sending money to those legacy banks.

Digital Identity. Anything online where it’s important to know who’s on the other end, requires digital identity. And yet we are nowhere near solving that problem. There are country-specific solutions where governments and/or consortia of banks issue some form of digital identity which others can trust. But it’s fragmented, with varying levels of security and integration isn’t necessarily easy. At the same time we have KYC companies that basically let you scan your customers passport or ID, optionally does a liveness detection (automated or manual) video conference and then check the person against databases of terrorists or sanctioned individuals. So for each service you have to do that again, slightly differently, and if something changes (e.g. an address or name change), there’s not really much you can do.

Ideally, digital identity is federated, using a common standard and easy to integrate, so that enrollment in sensitive online services that require some knowledge about a customer, is straightforward. The identification process gives just as much information as you need. Identity can be managed by multiple entities, government or private, that can vouch that an individual is indeed who they claim to be. The way you identify, with the current technology setting, would be with a key, securely stored in a mobile phone secure storage, using WebAuthn, SAML. There should be a way to re-issue they key in case a phone is lost, and then we’ll have an awesome, reusable digital identity to solve all online authentication and enrollment woes.

Alas, we are nowhere near that. Because what we currently have is working. It’s working terribly, expensively and with a lot of hacks and patches, and most importantly – users have to enrollment for every service separately, but from the point of view of each individual company, it’s easier to just get some service for passport verification and then issue username and password, with optional 2FA, and you are done. The system I described above is not 10 times better than the status quo. A blockchain-based self-sovereign identity, by the way, is also not 10 times better. And it has usability issues that even make it inferior to the status quo.

Privacy. Literally every day there’s a huge data breach or a huge privacy issue (mostly with Facebook). Facebook has been giving our data to 3rd parties, because why not. Companies are collecting whatever they can get ahold of, without much care of protecting it. Sensitive personal data is still stored unencrypted, unpseudonymized, in SQL databases with barely tracked admin access; applications still export bulks of sensitive data to excel sheets sent over email or published to public S3 buckets. Passwords are still stored in plaintext or unsalted, data is communicated over unencrypted connections.

We know how to fix all that; there are many best practices to address all of that. How many companies encrypt data at rest, which is the simplest and most obvious thing to do? How many encrypt data with separate keys to protect bulk exports? How many use pseudonymization when doing exports? Knowledge and best practices are out there but our software is still built as a CRUD application over a SQL datastore and the most important task is to get it done quickly, so let’s not bother with privacy protections.

And, from a business point of view, rightly so, unfortunately. Check the share price of a few recently breached companies. It drops for a few days and then bounces back up. And at the same time no privacy-preserving technology is 10 times better than what we have today, no company will be 10 times better if it protects personal data. So why bother?

Security. In the long run cybersecurity is very important. In the short term, it isn’t. Nothing bad will happen. The other day I inspected the 2FA application of a bank. It’s full of mistakes and yet, through multiple hoops and security-through-obscurity, it reduces the risk of something very bad happening. And if it happens, well, insurance will cover the losses. Data breaches happen not only because we don’t care about personal data, but also because we don’t care about security. Chief infomration security officers find it hard to convince boards that their role is needed, let alone that it needs budget. Security tools are a patchwork of barely working integrations. There was recently a series of rants from one infosec professional that rightly points out that our infosec tools are bad.

Are things improving? A little bit, mostly by introducing more secure protocols. Backward compatibility slows down the improvements, of course, but we’re getting there. But is there a security “fix” that makes things 10 times better, that changes the game, that cuts costs or risk so much? Nope.

These observations go for many more areas, both horizontal and vertical – social networks (where Facebook can’t even get sharing right, let alone data protection), public sector software is mostly still in the 90s, even online payments have not moved since PayPal at the beginning of the century – we still take our credit card from our wallets and type numbers and CVC codes, with all the associated fraud.

In many cases when there’s no visible improvement for years, some proactive governmental structure like the European Commission decides to step in and write some piece of legislation that tries to fix things. For banks, for example, there’s the PSD2 (2nd payment services directive), which mandates open banking – all data about a bank account should be accessible via APIs to third parties who can manage it, display it properly, analyze it. Wonderful in theory, a mess in practice so far – APIs barely work, there’s no standardization and anyone who wants to offer a service ontop of open banking APIs is suffering at the moment. SEPA, the single euro payment area standard, was introduced by a directive as well, more than a decade ago.

Regarding digital identity, there’s the eIDAS regulation which defines how governments should offer their eID cross border, so that, in theory, anyone can use any government or otherwise issued electronic identity to identify for any service across the EU. Things are not there yet at all, and the architecture is so complicated, I don’t think it will work as intended. The fragmented eID space will remain fragmented for all practical purposes.

For privacy there’s, of course, GDPR. And while it resulted in more people trying to take care of personal data, it lead to more documents being written than lines of code changed. Same for information security – the NIS directive tried to improve the security of providers of substantial services. It’s often unclear, though, what is a substantial service to begin with. And then it’s mostly organizational measures. Countries like the UK and Germany have good guidelines and frameworks to improve security but we are yet to see the results.

Why is solving problems properly so hard? Legacy software, legacy standard and legacy thinking certainly doesn’t help. But in many of these domains, solving problems properly does not bring sufficient business value. And we are not prepared to do things properly – while the knowledge on how to do things better exists, it’s not mainstream. And it’s not mainstream, because it’s not perceived as required.

We have half-assed our technology because it kinda works sufficiently to support the bottom line and to make users happy. We have muddled through the myriad of issues with the minimum effort required. Because even the maximum effort would not have been a sufficient improvement to change the game. Even the perfect re-imagined banking, digital identity, social network would not be significantly different for the end user. Sure, a little cheaper and a little more convenient, but not groundbreaking. Not to mention hidden horizontal aspects like security and privacy.

And we will continue that way, pushed by standards and regulations when nothing else helps, to a messy gradual improvement. But it won’t be worth the investment to do things right – why would you invest millions in quality software development when it will marginally affect your business? It’s only worth to get things to barely work.

The post Solving Problems Properly Is Often Not Viable appeared first on Bozho's tech blog.

Getting Email Sending Settings Right

Post Syndicated from Bozho original https://techblog.bozho.net/getting-email-sending-settings-right/

Email. The most common means of internet communication, that has been around for ages and nobody has been able to replace it. And yet, it is so hard to get it right in terms of configuration so that messages don’t get sent in spam.

Setting up your own email server is a nightmare, of course, but even cloud email providers don’t let you skip any of the steps – you have to know them and you have to do them. And if you miss something, business will suffer, as a portion of your important emails will get in spam. The sad part is that even if you get all of them right, emails can still get in spam, but this is on the spam filters and there’s little you can do about it. (I dread the moment when an outgoing server will run the email through standard spam filters with standard sets of configurations to see if it would get flagged as spam or not)

This won’t be the first “how to configure email” overview article that mentions all the pitfalls, but most of the ones I see omit some important details. But if you’ve seen one, you are probably familiar with what has to be done – configure SPF, DKIM and DMARC. But doing that in practice is trickier, as this meme (by a friend of mine) implies:

So, you have an organization that wants to send email from its “example.com” domain. Most tutorials assume that you want to send email from one server, which is almost never the case. You need it for the corporate emails (which would in many cases be a hosted or cloud MS Exchange, or Google Suite), you need it for system emails from your applications (one or more of them), which use either another internal server or a cloud email provider, e.g. Amazon SES, you also need it for your website, which uses the hosting provider email server, and you need it for your email campaigns, e.g. via Mailchimp or Sendgrid.

All of the email providers mentioned above have some parts of the picture in their documentation but it doesn’t work in combination. As most providers wrongly assume they are the only one. Their examples assume that and their automated verifications assume that – e.g. Microsoft checks if your SPF record matches exactly what they provide, rather than checking if their servers are allowed by your more complex SPF record which includes all of the above providers.

So let’s get to the individual items you have to configure. Most of them are DNS records, which explains why a technical person in each organization has to do it manually, rather than each service pushing it there automatically after some API authentication:

  • SPF (Sender Policy Framework) – a DNS recrod that lists the permitted senders (IP addresses) and an instruction flag on what to do with those that don’t match. In the typical scenario you need to include multiple senders’ policies rather than listing IP addresses, as they can change. E.g. in order to use Office365, you have to add include:spf.protection.outlook.com. Note that this should be a TXT record, but some DNS providers support a special type of record – SPF. So some older software may expect an SPF header, which means you should support both records with identical values. The syntax is straighforward but sometimes tricky, so you can use a tool to generate and validate it.
  • DKIM (DomainKeys Identified Mail) – a DNS record that lets email senders sign their emails. The DNS record includes the public key used to verify the signature. Why is it needed if there’s SPF? Among other things (like non-repudiation), because with SPF the From header can still be spoofed. Not that DKIM always helps with that, but in combination with DMARC it does. How does DKIM work in multi-sender scenario? You have multiple DKIM selectors which means multiple TXT records. Usually every provider will recommend its own selector (e.g. selector1._domainkey.example.com). Some may insist on being default._domainkey, and if two of them insist on that, you should contact support (the message contains the selector and then verification will fail if it does not match). Email providers would prefer CNAME instead of TXT records as that allows them to rotate the keys without you having to change your DNS records.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance) – this DNS record contains the policy according to which your emails should be validated – it enforces SPF and DKIM and tells the receiving side what to do if they fail. You can have one DMARC policy (again as a TXT record). The syntax is not exactly human readable, so use a tool to generate and validate it. An important aspect of DMARC is that you can receive reports in case of failures – you can specify an email where reports are sent and you can analyze them. There are services (like ReportURI) that can aggregate and analyze these reports. I prefer setting multiple report emails – one administrative and one for ReportURI.
  • PTR (pointer) – this is used for reverse DNS loopkups – it maps a domain name to an IP address (as opposed to A records which map IP adresses to domain names). Spam filters use it to check incoming email. The PTR records should be there for the servers that send the email, e.g. mail.example.com. External providers are likely to already have that record so no need to worry about it. And in many cases you won’t even be able to anyway if you don’t own/control the network.
  • Service-specific settings – you may configure your headers properly but the service sending the emails (e.g. Office365, Mailchimp) might still be missing some configuration. In some cases you have to manually confirm your headers in order to enable DKIM signing. With MS Exhange, for example, you have to execute a few PowerShell commands to generate and then confirm the DKIM records.
  • Blacklists – if you haven’t had everything setup correctly, or if one of your sending servers/services has been compromised, your domain and/or servers may be present in some blacklist. You have to check that. There are tools that aggregate blacklists and check against the, e.g. this one

After everything is done, you can run a spam test using some of the available online tools: e.g. this, this or this. And speaking of tools, MXToolbox has many useful tools to verify all aspects of email configuration.

By the way, this is not everything you can configure about your email. SMTP over TLS (SMTPS), MTA-STS, TLS RPT, DANE. I’ve omitted them because they are about encrypted communication and not about spam, but you should review them for proper email configuration.

By now (even if you already knew most of the things above) you are probably wondering “why did we get here?”. Why do we have to do so many things just to send simple email. Well, first, it’s not that simple to have a universal messaging protocol. It looks simple to use and that’s the great part of it, but it does hide some complexities. The second reason is that the SMTP protocol was not designed with security in mind. Spam and phishing were maybe not seen as such a big issue and so the protocol does not have built-in guarantees for anything. It doesn’t have encryption, authentication, non-repudiation, anything.

That’s why this set of instruments evolved over time to add these security features to email (I haven’t talked about encryption, as it’s handled differently). Why did it have to be DNS-based? It’s the most logical solution, as it guarantees the ownership of the domain, which is what matters even visually to the recipient in the end. But it makes administration more complicated, as you are limited to one-line, semicolon or space separated formats. I think it would be helpful to have a way to delegate all of that to external services, e.g. by a single authenticating DNS record which points to a URL which provide all these policies. For example an EML record to point to https://example.com/email-policies which can publish them in a prettier and more readable (e.g. JSON) format and does that in a single place rather than having to generate multiple records. Maybe that has its own cons, like having the policy server compromised.

But if anything is obvious it is that everything should be designed with security in mind. And every malicious scenario should be taken into account. Because adding security later makes things even more complicated.

The post Getting Email Sending Settings Right appeared first on Bozho's tech blog.

Има ли македонски език?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3460

Онзи ден, по повод становище на БАН, че македонски език няма, публикувах следното, което предизвика много онлайн полемика:

И на кого е нужно БАН да обяснява, че няма македонски език?

Македонски език има. Как се е появил на езиковата карта и дали не е имало политическо влияние в първоначалната книжовна норма няма значение за днешния ден, в който не просто има македонски език, ами мнозинството от българите няма да разбират повече от 60%, гледайки македонска телевизия, напр.

Езикът, това е диалект с армия. Няма ясно дефинирана разлика между език и диалект. И няма нужда да изобретяваме такава, за да смущаваме геополитическия прогрес.

Темата, обаче, е по-сложна и просто „има“ и „няма“ са не са достатъчни отговори. Затова ще опитам да обясня, особено за хората, които смятат несъществуването на македонски език за въпрос от национално значение.

Лингвистиката, като наука, която се занимава с изучаване на езика, не прави разлика между език и диалект. Няма такава. Дали едно нещо се нарича език или диалект е въпрос на други съображения. Най-значимото от които – наличието на геополитически субект, който да застане зад дадено наречие и да го нарече език.

А как така няма такава? За да има са ни нужни два компонента. Първият е отдалеченост на езиците. Има начини това да бъде изчислено с някакво приближение. Не е тривиално, но комбинация от лексикална отдалеченост (колко думи, и по-конкретно колко основни думи, напр. от списъка на Суодеш) се различават; фонологична отдалеченост – колко звуковите правила се различават; морфологична и синтактична отдалеченост – доколко, грубо казано, „граматиката“ се различава. И да кажем, че събираме единен индикатор за отдалеченост на база на претегляне на гореизброените. Идва обаче въпросът без отговор – къде слагаме границата? На отдалеченост = 1, 5, 7, 12? И защо? Македонският диалект ли е на българския, белоруският диалект ли е на украинския, австрийският и люксембургският диалекти ли са на немския, кантонският диалект ли е на китайския (путунхуа) и т.н. и т.н. И ще видим, че няма обективен критерий, по който да теглим чертата. Кантонският е толкова различен от други китайски диалекти, колкото френски от испански, например.

Именно поради тази невъзможност да бъде дефинирана разлика е прословутата фраза, че „езикът, това е диалект с армия и флот“. Или иначе казано – геополитическа конструкция. Ако Македонската държава казва, че има македонски език, значи такъв има (научих, че имали бойни кораби в Охридското езеро, така че и критерия с флота покриват).

Вече чувам блъскащите по клавиатурата пръсти на хората, които са наизвадили Гоце Делчев и Братя Миладинови, исторически извори за напъна за създаване на македонска нация и не на последно място – БАН, които все пак са професори, дето разбират от тая работа.

И искам веднага да ги успокоя – не смятам, че строителството на македонската нация е естествен процес. Или че „Антична Македония“ съществува, и че говорят езика на Александър Македонски. Дългогодишното изкривяване на историята от страна на македонските власти не е в услуга на никого, особено на самите македонци. Когато през 45-та година се кодифицира македонската книжовна норма, тя в немалка степен измислена на празно място. В следващите 70 години, обаче, така наложеният език търпи естествено (и отчасти насилствено) влияние от своите съседи, а именно – сръбския. Така той вече звучи различно и макар да няма изследване доколко е разбираем за българите, смятам, че много от думите, конструкциите и дори различните ударения ще са объркващи и дори неразбираеми за нетренираното ухо на носител на българския език.

Това желание да сложим езиците в едни кутийки и да кажем, че нещо е български и нещо не е български е следствие от опростената ни представа за езика като цяло. Езикът, това не е книжовна норма. Езикът е жив организъм, който се развива постоянно в следствие на естествени или изкуствени стимули. Езикът се развива на различни места по различен начин и затова лингвистичната карта не съвпада с държавните граници. В Крива паланка говорят едно, в Охрид друго. В Пирот говорят едно, в Нови сад – друго. Това сръбски ли е, ако, например няма всички падежи на книжовния сръбски? Отговорът – няма значение.

Лингвистиката се интересува от това какво се говори, какви са явленията в него, и как се е стигнало до тях.

И тук идва становището на Института за български език към БАН (Останалите становища имат по-малко общо с езикови аргументи, така че не ги коментирам). В становището на ИБЕ-БАН почти няма цитирана литература, липсва библиографска справка в края. Това беше първи червен флаг. Аргументацията вътре е вярна, доколкото разглежда българската диалектна карта и особеностите в нея, както и литературния български преди кодифицирането на македонския. Но по никакъв начин от това не следва, че има или няма македонски език. Именно защото това не е научен въпрос.

И това е тъжното – че становището на научна институция е с политически цели. Използването на науката с политически цели е нещо, което комунизмът е правил, включително при кодифицирането на македонския език. И вместо да се поучим от това, което не харесваме, правим същото – използваме научни институции за геополитически цели. Може би това е легитимен подход, защото „всички го правят“. Но нека не се заблуждаваме, че това е научно заключение.

И това важи и за двете страни – целият казус започна от (най-вероятна) провокация от страна на македонски научни среди, които публикуваха документ, в който повтарят до болка познати тези за „континюитета“ на македонската нация и езика като част от това. Които БАН правилно опровергава, макар че беше по-добра идея да не пада в капана.

Има ли македонски език или няма е въпрос без значение за лингвистичната наука. И тя няма отговор на него. Но спокойно – това, че има македонски език, защото македонската държава смята така, не означава, че Гоце, Даме и Яне са македонци. Не означава, че Александър Македонски е говорил славянски език. Не дава отговор има или няма македонска нация.

И призивът ми е да не се хващаме за разграничението между език и диалект като нещо толкова значимо за македонския въпрос. Не е.

A Disk-Backed ArrayList

Post Syndicated from Bozho original https://techblog.bozho.net/a-disk-backed-arraylist/

It sometimes happens that your list can become too big to fit in memory and you have to do something in order to avoid running out of memory.

The proper way to do that is streaming – instead of fitting everything in memory, you should stream data from the source and discard the entries that are already processed.

However, there are cases when code that’s outside of your control requires a List and you can’t use streaming. These cases are rather rare but in case you hit them, you have to find a workaround. One is to re-implement the code to work with streaming, but depending on the way the library is written, it may not be possible. So the other option is to use a disk-backed list – one that works as a list, but underneath stores and loads elements from disk.

Searching for existing solutions results in several 3+ years old repos like this one and this one and this one.

And then there’s MapDB, which is great and supported. It’s mostly about maps, but it does support a List as well, as shown here.

And finally, you have the option to implement something simpler yourself, in case you need just iteration and almost nothing else. I’ve done it here – DiskBackedArrayList.java. It doesn’t support many things (not all methods are overridden to throw an exception, but they should). But most importantly, it doesn’t support random adding and random getting, and also toArray(). It’s purely “fill the collection” and then “iterate the collection”. It relies on ObjectOutputStream which is not terribly efficient, but is simple to use. Note that I’ve allowed a short in-memory prependList in case small amounts of data need to be prepended to the list.

The list gets filled in memory until a specified threshold and then gets flushed to disk, clearing the memory which starts getting filled again. This too can be more efficient – with background flushing in another thread that doesn’t interfere with adding elements to the list, but optimizations complicate things and in this case the total running time was not an issue. Most importantly, the iterator() method is overridden to return a custom iterator that first streams the prepended list, then reads everything from disk and finally iterates over the latest batch which is still in memory. And finally, the clear() method should be called in the end in order to close the underlying stream. An output stream could be opened and closed on each flush, but ObjectOutputStream can’t be used in append mode due to some implementation specific about writing headers first.

So basically we hide the streaming approach underneath a List interface – it’s still streaming elements and discarding them when not needed. Ideally this should be done at the source of the data (e.g. a database, message queue, etc.) rather than using the disk as overflow space, but there are cases where using the disk is fine. This implementation is a starting point, as it’s not tested in production, but illustrates that you can adapt existing classes to use different data access patterns if needed.

The post A Disk-Backed ArrayList appeared first on Bozho's tech blog.

Защо новите трудови книжки няма да са електронни?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3458

В последните няколко месеца за втори път се появява новината за новите трудови книжки, а именно – че не просто няма да са електронни, а ще се смени дизайна им с по-грозен.

Трудовите книжки са един ужасен анахронизъм, който трябваше отдавна да е в историята, но по някаква причина не е. Министерство на труда предлага нищо да не се промени по същество и да продължаваме да мъкнем един (в някои случаи) парцал по работодатели, които с нечетим почерк, замазан от огромни печати, да пишат никому ненужна информация.

Защо са ни нужни изобщо трудови книжки? На пръв поглед не ни трябват – всеки трудов договор се регистрира в НАП, т.е. НАП има необходимата информация, а осигурителният стаж се пази в НОИ.

Само, че както винаги, „нещата са малко по-сложни“. Има разлика между осигурителен стаж и трудов стаж. Каква е разликата – може да прочетете на тази „красива“ страница на Главна инспекция по труда. Макар синдикатите да държат на тези разлики, отпадането им би улеснило много системата. Още повече че напр. управителите на фирми не трупат трудов стаж, защото не са на трудов договор, а на договор за управление и контрол, т.е. действащото положение активно наказва предприемачи, които в малките фирми много често вършат същата работа, като работниците, но се водят управители. „Клас прослужено време“ са добавка към заплатата, чието отпадане няма да навреди на никого (и не, работниците няма да вземат по-малко пари; ако тази добавка има значение, работодателите просто дават по-ниска основна заплата, за да се стигне до договорената нетна заплата.)

В трудовата книжка има и други параметри, които в момента никъде не се записват – код на професия, основание за прекратяване на правоотношение, работа на пълен или непълен работен ден и др.

Но дори политическото решение за отпадане на трудовия стаж и приравняването му към осигурителния да е прекалено трудно, проблемът има практически решения, а именно – някой да води регистър на трудовия стаж. Кандидатите са няколко – НАП, НОИ, МТСП, главна инспекция по труда, синдикатите, работодателските организации. Последните, логично, не биха искали и нямат интерес от това. Синдикатите нямат капацитет (те за какво ли имат). За НОИ и НАП това не е присъщи дейности, тъй като не се отнасят до приходи и осигуровки. МСТП и ГИТ остават като логичните администрации, които да водят такъв регистър.

Администрацията вижда воденето на електронен регистър като нещо ужасно тежко. И то в известна степен е, предвид, че все още не е дори стартирал проекта за базов регистър, който да позволи всяка администрация да създават с няколко стъпки изцяло нов регистър. Но дори МТСП/ГИТ да поръчат изграждане на регистър на трудовия стаж, някой трябва да въвежда данни в него. Най-логичното е това да са работодателите, но те може да разглеждат това задължение като допълнителна административна тежест. Тя не е такава, тъй като те така или иначе имат задължение за поддържане на трудови книжки, но от друга страна това добавя стъпка на комуникация с администрацията.

В трудовия договор на практика има цялата тази информация, а за него се изпраща уведомление до НАП. Данните, които трябва да се подават, са описани в Наредба 5 от 2002г, и включват кода на длъжността, възнаграждението, дата, срок, прекратяване.

Съвсем логично решение е просто Наредба 5 да се измени и в уведомлението за сключване на трудов договор да се добавят данните, които се вписват в трудовата книжка. НАП пък от своя страна може да има задължението просто да ги препраща към новосъздаден регистър на трудовите правоотношения („електронна трудова книжка“) в МТСП. По този начин административната тежест не се променя, а единствено се разширява обхвата на уведомлението до НАП.

В трудовата книжка трябва да се вписват и запори (вероятно има и други събития, които не са ми известни). Всички те са сравнително редки случаи и могат да се докладват директно към регистъра в МТСП, отново по електронен път или на хартия, за по-нискотехнологични работодатели.

Първоначалното въвеждане на данните от хартиените книжки пък може да е задължение на работодателя, за което да има срок от една година. При уведомление за новопостъпил работник пък работодателят може да получава отговор, че на този служител данните от трудовата книжка не са въведени и да ги въведе еднократно. Така за няколко години всичко ще е електронно.

След всички тия скучни членове, алинеи и регистри, изглежда, че по-скоро имам отговор на въпроса „как да имаме електронна трудова книжка“, а не защо нямаме.

Отговорът на въпроса в заглавието е нежелание за поемане на отговорност и липса на политическа инициатива. Някой на високо политическо ниво трябва да събере всички участници в процеса, да им предложи подобно на гореописаното решение, да го прецизира заедно с тях и да им наложи неговото изпълнение. Иначе никоя институция няма да си „навлече“ повече работа и повече отговорности.

Нов дизайн на трудовата книжка е каране по една убийствена инерция и единственият начин това да се промени е адекватност в политическото ниво. Не е късно да имаме електронни трудови книжки и да изхвърлим хартията и призовавам новия министър на труда и социалната политика да разгледа сериозно тази възможност.

Near Real-Time Indexing With ElasticSearch

Post Syndicated from Bozho original https://techblog.bozho.net/near-real-time-indexing-with-elasticsearch/

Choosing your indexing strategy is hard. The Elasticsearch documentation does have some general recommendations, and there are some tips from other companies, but it also depends on the particular usecase. In the typical scenario you have a database as the source of truth, and you have an index that makes things searchable. And you can have the following strategies:

  • Index as data comes – you insert in the database and index at the same time. It makes sense if there isn’t too much data; otherwise indexing becomes very inefficient.
  • Store in database, index with scheduled job – this is probably the most common approach and is also easy to implement. However, it can have issues if there’s a lot of data to index, as it has to be precisely fetched with (from, to) criteria from the database, and your index lags behind the actual data with the number of seconds (or minutes) between scheduled job runs
  • Push to a message queue and write an indexing consumer – you can run something like RabbitMQ and have multiple consumers that poll data and index it. This is not straightforward to implement because you have to poll multiple items in order to leverage batch indexing, and then only mark them as consumed upon successful batch execution – somewhat transactional behaviour.
  • Queue items in memory and flush them regularly – this may be good and efficient, but you may lose data if a node dies, so you have to have some sort of healthcheck based on the data in the database
  • Hybrid – do a combination of the above; for example if you need to enrich the raw data and update the index at a later stage, you can queue items in memory and then use “store in database, index with scheduled job” to update the index and fill in any missing item. Or you can index as some parts of the data come, and use another strategy for the more active types of data

We have recently decided to implement the “queue in memory” approach (in combination with another one, as we have to do some scheduled post-processing anyway). And the first attempt was to use a class provided by the Elasticsearch client – the BulkProcessor. The logic is clear – accumulate index requests in memory and flush them to Elasticsearch in batches either if a certain limit is reached, or at a fixed time interval. So at most every X seconds and at most at every Y records there will be a batch index request. That achieves near real-time indexing without putting too much stress on Elasticsearch. It also allows multiple bulk indexing requests at the same time, as per Elasticsearch recommendations.

However, we are using the REST API (via Jest) which is not supported by the BulkProcessor. We tried to plug a REST indexing logic instead of the current native one, and although it almost worked, in the process we noticed something worrying – the internalAdd method, which gets invoked every time an index request is added to the bulk, is synchronized. Which means threads will block, waiting for each other to add stuff to the bulk. This sounded suboptimal and risky for production environments, so we went for a separate implementation. It can be seen here – ESBulkProcessor.

It allows for multiple threads to flush to Elasticsearch simultaneously, but only one thread (using a lock) to consume from the queue in order to form the batches. Since this is a fast operation, it’s fine to have it serialized. And not because the concurrent queue can’t handle multiple threads reading from it – it can; but reaching the condition for forming the bulk by multiple threads at the same time will result in several small batches rather than one big one, hence the need for only one consumer at a time. This is not a huge problem so the lock can be removed. But it’s important to note it’s not blocking.

This has been in production for a while now and doesn’t seem to have any issues. I will report any changes if there are such due to increased load or edge cases.

It’s important to reiterate the issue if this is the only indexing logic – your application node may fail and you may end up with missing data in Elasticsearch. We are not in that scenario, and I’m not sure which is the best approach to remedy it – be it to do a partial reindex of recent data in case of a failed server, or a batch process the checks if there aren’t mismatches between the database and the index. Of course, we should also say that you may not always have a database – sometimes Elasticsearch is all you have for data storage, and in that case some sort of queue persistence is needed.

The ultimate goal is to have a near real-time indexing as users will expect to see their data as soon as possible, while at the same time not overwhelming the Elasticsearch cluster.

The topic of “what’s the best way to index data” is huge and I hope I’ve clarified it at least a little bit and that our contribution makes sense for other scenarios as well.

The post Near Real-Time Indexing With ElasticSearch appeared first on Bozho's tech blog.

Забраната на Airbnb – аналогови хора в дигиталния свят

Post Syndicated from Bozho original https://blog.bozho.net/blog/3449

Тези дни депутати предложиха Airbnb да бъде на практика забранен – предложението е да не могат некатегоризирани обекти по Закона за туризма да се предлагат през платформата. Ограничението не е само за Airbnb, а за Booking, Facebook и други платформи за предлагане на места за настаняваме. Надолу в текста ще ползвам Airbnb като събирателно за всички тях, поради сходния модел.

Тази забрана е още един пример как аналогови хора достигат тавана на възможностите си да възприемат дигиталния свят.

Airbnb е проблем на много места, по много различни начини. И правилното решение почти никога не е „забраняваме го“. Най-малкото защото контролът е скъп и труден до невъзможен и на моменти граничещ с умствено изоставане – задължаваш интернет доставчици да блокират Airbnb за своите клиенти? „Давам апартаменти под наем“ е новото „продавам оръжие“, явно.

Факт е, че хотелиери, собственици на къщи за гости (ама от истинските), и като цяло туристическият бранш е недоволен, че някой може да заобикаля правилата, които важат за тях. И са прави – бизнесът трябва да работи при максимално изравнени външни условия, за да има истинска конкуренция.

Само че тия правила са от преди минимум 20 години, като начин ма мислене поне. Табели, тарифи, категории – все неща, които имат за цел да гарантират удобство на клиента, но не са единствения начин за това – Airbnb дава други начини за гарантиране на това удобство.

Та, вместо да ги забраняваме, каквато е вечната рецепта тук (както стана и с Uber), имам две конкретни предложения, които са със същата философия като предложенията ми за Uber тогава

  • интегриране на Airbnb със системите на НАП за автоматично изпращане на данни за получените плащания. Така данъци няма да могат да се укриват. Естония направи така с Uber – „върза“ ги с API на данъчните.
  • олекотяване на режимите за хотелите, къщите за гости и другите места за настаняване. Всичко да може да става онлайн, за да може усилието да си регистрираш апартамента в Airbnb да е съизмеримо с това да си го регистрираш в Министерство на туризма. А ако сме особено амбициозни, Министерство на туризма да даде API (програмен интерфейс), през който Airbnb автоматично да регистрира обявените места за настаняване, с някакви смятани за важни параметри – тоалетни/бани, квадратура, асансьор, пушене, които така или иначе са важните неща за клиента, а не че нещо е 3 или 4 звезди. Ако МТ пусне такъв интерфейс, ще видим, че за няколко месеца и хотелиерските софтуери ще започнат да го ползват и да обявяват местата си там

Напомням, че в Закона за електеронното управление и подзаконовата нормативна уредба вкарахме изискване всички системи да предоставят всичките си функционалности през програмен интерфейс. Именно за да позволим такива интеграции. За Airbnb това ще е една седмица работа, а те така или иначе са си организирали кода да позволява национални специфики. Само че важността на програмните интерфейси (APIs) за електронното управление остава недоразбрана.

Хората ползват Airbnb не защото искат да бягат от правилата, а защото правилата са неадекватни и начинът на комуникация с институциите е неудобен и тромав. Публикуването на обява в Airbnb е не толкова просто, но удобно и предсказуемо занимание. Ако отворим сайта на Министерство на туризма, виждаме това. Списък с новини в CMS-а на сайта, като всяка препраща към страница със стена от текст и няколко формуляра в doc или pdf, които да разпечатаме и занесем в общината и/или министерството. Еми, не, мерси.

(Знам, че преди време Ангелкова обяви, че всички електронни услуги са достъпни и с eID от един частен доставчик, но за 10 минути търсене не ги открих. Знаейки за една малко известна система – портала за е-форми, все пак ги намерих, но и там са под формата попълване на PDF и изпращането му по електронен път – все пак е нещо, но много далеч от потребителското изживяване на Airbnb)/

Дигиталната трансформация понякога изисква малко мисъл и малко усилия, но аналоговите човечета предпочитат просто да сложат хикса и да кажат „интернет – лош; хора в интернет – лоши“.

A Technical Guide to CCPA

Post Syndicated from Bozho original https://techblog.bozho.net/a-technical-guide-to-ccpa/

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. And, obviously, I’m not a lawyer, but I’ve been doing data protection consultations and products (like SentinelDB) for the past several years, so I’m qualified to talk about the technical side of privacy regulations.

  • 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, necessary to complete the business requirement, or anything that the user can reasonably expect. From a technical perspective, this means you most likely have to delete what’s in your database, but other places where you have personal data, like logs or analytics, can be skipped (provided you don’t use it to reconstruct user profiles, of course)
  • Notify 3rd party providers that received data from you – when data deletion is requested, you have to somehow send notifications to wherever you’ve sent personal data. This can be a SaaS like Mailchimp, Salesforce or Hubspot, or it can be someone you sold the data (apparently that’s a major thing in CCPA). So ideally you should know where data has been sent and invoke APIs for forgetting it. Fortunately, most of these companies are already compliant with GDPR anyway, so they have these endpoints exposed. You just have to add the logic. If your company sells data by posting dumps to S3 or sending Excel sheets via email, you have a bigger problem as you have to keep track of those activities and send unstructured requests (e.g. emails).
  • Data lineage – this is not spelled out as a requirement, but it follows from multiple articles, including the one for deletion as well as the one for disclosing who data was sent to and where did data came from in your system (in order to know if you can re-sell it, among other things). In order to avoid buying expensive data lineage solutions, you can either have a spreadsheet (in case of simpler processes), or come up with a meaningful way to tag your data. For example, using a separate table with columns (ID, table, sourceType, sourceId, sourceDetails), where ID and table identify a record of personal data in your database, sourceType is the way you have ingested the data (e.g. API call, S3, email) and the ID is the identifier that you can use to track how it came in your system – API key, S3 bucket name, email “from”, or even company registration ID (data might still be sent around flash drives, I guess). Similar table for the outgoing data (with targetType and targetId). It’s a simplified implementation but it might work in cases where a spreadsheet would be too cumbersome to take care of.
  • Age restriction – if you’ve had the opportunity to know the age of a person whose data you have, you should check it. That means not to ignore the age or data of birth field when you import data from 3rd parties, and also to politely ask users about their age. You can’t sell that data, so you need to know which records are automatically opted out. If you never ever sell data, well, it’s still a good idea to keep it (per GDPR)
  • Don’t discriminate if users have used their privacy rights – that’s more of a business requirement, but as technical people we should know that we are not allowed to have logic based on users having used their CCPA (or GDPR) rights. From a data organization perspective, I’d put rights requests in a separate database than the actual data to make it harder to fulfill such requirements. You can’t just do a SQL query to check if someone should get a better price, you should do cross system integration and that might dissuade product owners from breaking the law; furthermore it will be a good sign in case of audits.
  • “Do Not Sell My Personal Information” – this should be on the homepage if you have to comply with CCPA. It’s a bit of a harsh requirement, but it should take users to a form where they can opt out of having their data sold. As mentioned in a previous point, this could be a different system to hold users’ CCPA preferences. It might be easier to just have a set of columns in the users’ table, of course.
  • Identifying users is an important aspect. CCPA speaks about “verifiable requests”. So if someone drops you an email “I want my data deleted”, you should be able to confirm it’s really them. In an online system that can be a button in the user profile (for opting out, for deletion, or for data access) – if they know the password, it’s fairly certain it’s them. However, in some cases, users don’t have accounts in the system. In that case there should be other ways to identify them. SSN sounds like one, and although it’s a terrible things to use for authentication, with the lack of universal digital identity, especially in the US, it’s hard not to use it at least as part of the identifying information. But it can’t be the only thing – it’s not a password, it’s an identifier. So users sharing their SSN (if you have it), their phone or address, passport or driving license might be some data points to collect for identifying them. Note that once you collect that data, you can’t use it for other purposes, even if you are tempted to. CCPA requires also a toll-free phone support, which is hardly applicable to non-US companies even though they have customers in California, but it poses the question of identifying people online based on real-world data rather than account credentials. And please don’t ask users about their passwords over the phone; just initiate a request on their behalf in the system and direct them to login and confirm it. There should be additional guidelines for identifying users as per 1798.185(a)(7).
  • Deidentification and aggregate consumer information – aggregated information, e.g. statistics, is not personal data, unless you are able to extract personal data based on it (e.g. the statistics is split per town and age and you have only two users in a given town, you can easily see who is who). Aggregated data is differentiate from deidentified data, which is data that has its identifiers removed. Simply removing identifiers, though, might again not be sufficient to deidentify data – based on several other data points, like IP address (+ logs), physical address (+ snail mail history), phone (+ phone book), one can be uniquely identified. If you can’t reasonably identify a person based on a set of data, it can be considered deidentified. Do make the mental exercise of thinking how to deidentify your data, as then it’s much easier to share it (or sell it) to third parties. Probably nobody minds being part of an aggregated statistics sold to someone, or an anonymized account used for trend analysis.
  • Pseudonymization is a measure to be taken in many scenarios to protect data. CCPA mentions it particularly in research context, but I’d support a generic pseudonymization functionality. That means replacing the identifying information with a pseudonym, that’s not reversible unless a secret piece of data is used. Think of it (and you can do that quite literally) as encrypting the identifier(s) with a secret key to form the pseudonym. You can then give that data to third parties to work with it (e.g. to do market segmentation) and then give it back to you. You can then decrypt the pseudonyms and fill the obtained market segment(s) into your own database. The 3rd party doesn’t get personal information, but you still get the relevant data
  • Audit trail is not explicitly stated as a requirement, but since you have the obligation to handle users requests and track the use of their data in and outside of your system, it’s a good idea to have a form of audit trail – who did what with which data; who handled a particular user request; how was the user identified in order to perform the request, etc.

As CCPA is not concerned with data confidentiality requirements, I won’t repeat my GDPR advice about using encryption whenever possible (notably, for backups), or about internal security measures for authentication.

CCPA is focused on the rights of your users and you should be able to handle them (and track how you handled them). You can have manual and spreadsheet based processes if you are not too big, and you should definitely check with your legal team if and to what extent CCPA applies to your company. But if you have implemented the GDPR data subject rights, it’s likely that you are already compliant with CCPA in terms of the overall system architecture, except for a few minor details.

The post A Technical Guide to CCPA appeared first on Bozho's tech blog.

Какво пък толкова – 2026 г.

Post Syndicated from Bozho original https://blog.bozho.net/blog/3441

Годината е 2026. Текат дискусии по избора на нов главен прокурор. Единственото предложение е Делян Пеевски.

За малка част от обществото темата е важна – правомощията на главния прокурор и структурата на са непроменени от 91г насам, а злоупотребите на предишните главни прокурори са известни на тази малка част от обществото.

Организират се протести. Протестът около ВСС е малък, като в по-слънчевите сутрини се събират около 500-600 души, в т.ч. Йоло Денев. Разбира се, има организиран контрапротест, на който са докарани нищо неподозиращи хора за по 50 лева.

Националните медии отразяват протестите някъде назад в новините – „два протеста днес в София – един за и един против новия главен прокурор“. Няколко онлайн медии все пак отбелязват, че единият протест е с неясна организация и съмнителни участници. По-близките до Пеевски медии правят захаросан очерк на неговата биография и опита му в съдебната система.

Появяват се няколко дълбокомислени статии за системните проблеми с препратки към падането на комунизма и грешките, които са допуснати още тогава. Разбира се, провалът на „лидерите на дясното“ е незаменима част от аргументацията.

„Дясното“ поне от известно време е обединено, но все не успява да достигне до масовия избирател и остава със 7-8% на парламентарни избори, което му дава възможността да е заглушен от фоновия шум дразнител.

Във Фейсбук дебатът се ограничава до това дали е трябвало протестът е да сутринта или вечерта; дали трябвало да е граждански или организиран от партии; дали пеенето на революционни песни е проява на лош вкус; защо едикойси не е бил или е бил на протеста. Заражда се възмущение защо толкова се акцентира върху външния вид на Пеевски и това ли е най-големият проблем? „Така не се прави“, „аз откога ви казах“, „няма лидерство“ и „пропиляхме шансовете“ са сред най-често използваните коментари.

Участници и наблюдатели се разделят по осите дали протестът е партиен или граждански, дали някой не го е яхнал, защо никой не поведе гражданите и дали не трябва „най-накрая да се спре в тия мирни протести и да им покажем, че това не се трае“.

Разследващи журналисти откриват поредната схема на властта, при която Пеевски е печелил обществени поръчки, но това някак си остава маловажно.

Отстрани, фенклубът на управляващите и други придали си важност коментатори с перспектива за някое постче, омаловажават и иронизират всеки дребен детайл от протеста и неговите участници, като в същото време с достатъчно медийно покритие обясняват как той Пеевски може и да не е добър главен прокурор, но всъщност виновни за това не са управляващите.

Някой пише меланхолична статия за това колко зле ще са нещата след още седем години.

Няколко групи интелектуалци в рамките на месец и половина публикуват манифест, харта и призив за нов обществен договор. Други групи интелектуалци не са точно съгласни, че точка три е толкова важна. Новият обществен договор така и не се материализира.

Филчев, Цацаров и Гешев дават по две-три дълги интервюта в национален ефир, в които обясняват за професионалните и етичните качества на Пеевски. В две трети от интервютата атакуват опозицията.

Няколко дни след гласуването във ВСС президентът Борисов подписва указа за назначаване на Пеевски и заявява пред медиите „ами те прокурорите си го избраха, явно има качества. А Христо Иванов като е толкова против, да не я беше предлагал тая реформа“.

На мнозинството от хората им е омръзнала отдавна тая тема, Пеевски е достатъчно де-демонизиран за толкова години. Много от тези, на които някога им е пукало, или са си тръгнали, или вече не следят темата. Държавата криволичи в развитието си, икономическият растеж е скромен, но достатъчен, за да няма обществени сътресения. Системните проблеми се задълбочават, но някой друг ще ги мисли.

Обществените поръчки си текат към „наши хора“, посредствеността във властта е константа, ежемесечните скандали в следствие на микс от корупция и некадърност са нормална част от пейзажа. Пеевски е уредил да усвои поръчки покрай АЕЦ Белене и Южен Поток, които някак все още не са истински започнати, но „стратегически важни“ и поглъщат по някой консултантски милион.

В задната част на протеста няколко души обсъждат усещането, че се въртим в кръг. Че правим същите когнитивни грешки, че падаме в същите капани. Че не сме успели да изградим нужния социален капитал, че не сме се научили да работим заедно за общи цели, че не сме разбрали, че въртенето ни в кръга ще продължи да бъде незначително за историята.

После прокапва дъжд и хората се разотиват. Навън е студено, а градският транспорт е все по-нарядко. Тихо е. Но и някак спокойно. Какво пък толкова, че Пеевски ще е главен прокурор.

Електронни документи – имат ли почва у нас?

Post Syndicated from Bozho original https://blog.bozho.net/blog/3438

Електронните документи се въвеждат у нас със Закона за електронния документ и електронния подпис през 2001. На теория това значи, че всички документи и в публичния, и в частния сектор, могат да бъдат електронни и да имат правна стойност. На практика нещата стоят доста по-различно, макар ползите да са огромни.

На първо място трябва да бъде разгледан електронния подпис. Много документи изискват подпис, за да бъдат признати за валидно волеизявление. Квалифицираният електронен подпис е единственият, който е автоматично приравнен на саморъчен, поради което и у нас той се счита за единствено приемлив. Той обаче има редица технически предизвикателства – поддръжката му в браузърите, удостоверенията на доставчиците и форматите, в които се съхранява. Дори да успеем да подпишем електронен документ, отсрещната страна често казва „не се валидира“, „не се показва“, или дори да не може да разбере кое е подписът. Това кара много организации и в частния и в публичния сектор да изискват хартиен документ, за всеки случай. Държавата е опитала да реши частично този проблем със система за електронно валидиране, но тя на практика не се използва и никой не знае за нея, макар да има нормативно задължение за използването ѝ.

На второ място е вътрешният документооборот – за него не е необходим квалифициран електронен подпис, тъй като в рамките на една организация и други данни могат да се използват за електронно подписване. В една деловодна система документът може да се води подписан без реално да се срещат всички усложнения на квалифицираните подписи. Т.е. на теория всички документи в една администрация могат да са електронни. На практика, обаче, много служители, а и главни секретари, продължават да искат да работят с хартиени документи. Отново въпреки изискването на нормативната уредба целият вътрешен обмен на документи да бъде електронен. Сканирането на хартиени (и подписани на хартия) документи е една „кръпка“, която се използва много често – ако директорът на дирекция не иска или не може да работи електронно, секретарката му разпечатва документите за подпис и след това ги сканира. Когато граждани подават документи на гише, се случва същото. Проблемът с това е, че съдържанието на документа става недостъпно – не може да се търси, не може да се копира. За да се стигне до истински електронен обмен на документи, разпечатването и сканирането трябва да са на практика забранени, с изключение на гражданите, подаващи документи на гише.

Що се отнася до гражданите, стигаме до третия проблем – приемането и връчването на електронни документи. Приемането и връчването може да става по имейл или през специална система – за е-услуги или за електронно връчване. Последната съществува и се развива в последните години в администрацията като универсално средство за обменяне на документи между държава и граждани. Връчването на електронни документи има и друга важна функция – да определи еднозначно от кой момент започват да текат сроковете (за обжалване, за коригиране и др.) и би трябвало системи за е-връчване да се налагат все повече и в публиичния, и в частния сектор, тъй като пестят време, пари и главоболия – куриери, обратни разписки, закъснения.

На последно място е дигитализирането на архиви – то е времеемка и скъпа задача, тъй като тоновете хартия, която е генерирана с десетилетия, трябва да бъде обърната не просто в снимка, а в текст, чрез автоматично разпознаване на символи. Тази задача, за съжаление, е избягвана от много институции. Имотният регистър, например, не е дигитализиран все още и това създава редица проблеми.

За да не става все по-скъпа задачата с дигитализиране на архиви е необходимо много скоро администрацията да премине изцяло към електронни документи – и вътрешно, и в общуването с граждани. Електронните документи не са просто удобство – на база на тях могат да се извличат данни, да се правят анализи и в крайна сметка – политики. А съхранението им, ако към него се подходи сериозно, е по-сигурно от това на хартиени документи и манипулации и „изчезвания“ стават много по-малко вероятни. А колкото повече документи се приемат по електронен път, толкова по-малко човекочасове ще губят гражданите и бизнесът в мъкнене на папки по опашки.

(статията е написана за сп. Мениджър и публикувана първоначално там)

Restoring Cassandra Priam Backup With sstableloader

Post Syndicated from Bozho original https://techblog.bozho.net/restoring-cassandra-priam-backup-with-sstableloader/

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 facility of Priam (using Snappy)
# so that it can be used with sstableloader for restore
import os
import requests

rootdir = '/home/ec2-user/backup'
target = '/home/ec2-user/keyspace'

for subdir, dirs, files in os.walk(rootdir):
    for file in files:
        fullpath = os.path.join(subdir, file)
        parent = os.path.join(fullpath, os.pardir)
        table = os.path.basename(os.path.abspath(parent))
        targetdir = target + "/" + table + "/"
        if not os.path.exists(targetdir):
            os.makedirs(targetdir)

        url = 'http://localhost:8080/Priam/REST/v1/cassadmin/decompress?in=' + fullpath + '&out=' + target + "/" + table + "/" + file
        print(url)
        requests.get(url)

Now you have decompressed backup files that you can restore using sstableloader. It may take some time if you have a lot of data, and you should not run the restore at the same time a snapshot backup is performed, as it may fail (was warned by the documentation)

As a general note here, it’s very important to have backups but it’s much more important to be able to restore from them. A backup is useless if you don’t have a restore procedure. And simply having the tools available (e.g. Priam) doesn’t mean you can a restore procedure ready to execute. You should be doing test restores on active staging data as well as full restores on an empty, newly formed cluster, as there are different restore scenarios.

The post Restoring Cassandra Priam Backup With sstableloader appeared first on Bozho's tech blog.

Кратък анализ на местните избори

Post Syndicated from Bozho original https://blog.bozho.net/blog/3435

Първият тур на местните избори приключи. И макар да остават много важни балотажи ми се ще да направя няколко коментара в полето на демократичната общност. По-точно – шест.

1. Безсмислено и неадекватно да се хвърлят обвинения във всички посоки относно местните избори. Никой не печели и никой няма да си промени мнението.

2. Бакалските сметки не работят. Игнатов + Бонев не е по-голямо от Манолова. Ако Бонев беше кандидат на ДБ, много от тези 80% от неговите избиратели, които не са симпатизанти на ДБ (според екзит пола), нямаше да гласуват. Същото щеше да е и ако беше подкрепен независим – медиите щяха да побързат да го асоциират с ДБ и де факто да е наш кандидат с друг номер, а атаките срещу него в по-свинските медии щяха да са като към „кандидата на Сорос“, каквито заявки даде ПИК в началото.

3. Положително е, че Бонев привлече толкова нови избиратели. Не просто защото ще бъде общински съветник, а защото по този начин обществената подкрепа за политиките, които вярвам ще бъдат съвместно прокарвани в общинския съвет от Демократична България и него, ще е по-широка. А това е важно – не просто колко съветника гласуват за едно или друго, а колко хора стоят зад това.

4. В крайна сметка няма нищо разцепено и нищо разделено освен едни 200 души във фейсбук, които сън не спят да посочат кой е виновен. Има поле за разширяваща се общност и това ще го видим в общинския съвет съвсем скоро.

5. Демократична България постигна добър резултат. Знам, че много хора го определят като пълен провал, но това е най-добрият резултат на демократичната общност за последните 12 години – има най-голяма група в общинския съвет (12 души) и кандидатът за кмет е получил най-висок процент от гласовете. Да, това не е победа, но е важна стъпка в правилната посока. Защото този път в общинския съвет няма да има политическите опортюнисти влезли под флага на поредното дясно обединение, които след няколко месеца ще почнат да гласуват заедно с ГЕРБ. Има хора, които тепърва влизат в политиката с ентусиазъм да правят правилните неща. Казвам го, защото ги познавам. А тази неделя ще видим колко от 10-те балотажа за районни кметове ще бъдат спечелени.

6. Извън София нещата не са розови и там сериозни промени няма. Все пак в Пловдив вече ще има група в общинския съвет (Реформаторският блок нямаше), във Варна групата няма да е заедно с ВМРО (макар да е по-малка). На други места се усеща липсата на другите партии от РБ, които по различни начини носеха по някой глас тук и там.

Следват парламентарните избори и Демократична България трябва да продължи работата, защото такава има много.

Електронни обществени поръчки – хронология на липсата

Post Syndicated from Bozho original https://blog.bozho.net/blog/3421

Електронните обществени поръчки са нещо, за което все повече хора се сещат да говорят. Предизборно, разбира се, и повърхностно. Електронните обществени поръчки предполагат повече прозрачност и по-малко коруоция.

Ако бъдат направени както трябва, това със сигурност е така. Ако се качват едни сканирани документи в обикновено хранилище за документи, както вероатно някои си го представят, полза няма.

Но в следствие на директивата на ЕС за обществените поръчки, би трябвало дс има национална централизирана система за електронни обществени поръчки – електронно обявяване, кандидатстване, отваряне на оферти и т.н.

Да разгледаме, обаче, хронологията на събитията:

2014г: ЕС приема директива за задължителна централизирана платформа за обществени поръчки във всяка държава-членка, срок за транспиниране 19 април 2016. Срокът за въвеждане на е-обществените поръчки е 18 октомври 2018.

2016г. (март) проектът за електронни обществени поръчки е добавен в пътната карта за електронно управление като приоритетен (добавен с мое участие през септември 2015, но приет от МС март 2016). С това на практика се осигурява и финансиране за проекта по Оперативна програма „Добро управление“ (не автоматично, разбира се, но прави проекта финансируем без допълнително одобрение)

2016г: (15 април) Българският парламент приема новия Закон за обществени поръчки, като срокът за електронните обществени поръчки е юни 2017г.

2016г стартира процедурата за система за обществени поръчки, но КЗК я „порязва“

2017г процедурата за електронна система за обществени поръчки стартира наново

2017г: парламентът се сеща, че тая няма да я бъде, и отлага влизането в сила за 18 октовмри 2018, т.е. крайният срок по директива

2018г: парламентът се сеща, че и тая няма да я бъде, и изтрива изцяло члена, като прави нов, в който срокът вече е 1 ноември 2019г.

2019г: системата за електронни обществени поръчки е пусната, но още не е готова и липсват важни функционалности. Например липсват отворени данни, макар да е задължително и по закон, и по задание, и по критерии на оперативната програма, по която е финансиран проектът. (Заб: С колегите в АОП отворихме данните от старата система за няколко часа работа)

2019г, октомври: Менда Стоянова (ГЕРБ) внася между първо и второ четене изменения чрез преходни и заключителни разпоредби в нямащ нищо общо закон (Закона за пазарите и финансовите инструменти), в който въвежда правната иновация – Министерски съвет да определя от кога влиза в сила законът за конкретните институции. На практика казва „когато стане – тогава“.

Всички тия законодателни странности са вероятно за да не е очевидно, че от 1 година сме нарушение на директивата, приета 2014г. За 5 години (а и повече, защото тя се готви по-отдавна) въвеждането на електронни обществени поръчки се оказа невъзможно.

Системата ЦАИС ЕОП работи от известно време. Само че все още на практика никой не я използва. Затова и управляващите искат изпълнителната власт да решава кое министерство кога да я ползва.

Причините за това забавяне са много и разнообразни. Започват с мотането на законодателя (ЗОП е приет няколко дни преди крайния срок по директива), КЗК спира първата процедура със (според моя прочит) не особено убедилни аргументи, новата процедура се забавя повече от очакваното.

Дали можеше по-бързо? Можеше, ако имаше споделено от всички разбиране, че това е един от най-важните проекти. Тогава на всяка една стъпка нещата щяха да стават по-гладко, според мен.

Заключения няма да правя, те са ясни.

Blockchain Overview – Types, Use-Cases, Security and Usability [slides]

Post Syndicated from Bozho original https://techblog.bozho.net/blockchain-overview-types-use-cases-security-and-usability-slides/

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
  • 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 blog.

Защо е важен главният прокурор

Post Syndicated from Bozho original https://blog.bozho.net/blog/3413

Предстои избор на нов главен прокурор. Със седемгодишен мандат. А прокуратурата е йерархична структура – главният прокурор може да контролира всичко в системата, всички са му подчинени. Този избор на пръв поглед не е толкова важен – да си се избират в съдебната система, да си гонят престъпниците. А и „хората правосъдие не ядат“.

Прокуратурата наистина има за цел да обвинява престъпници (хора, които са нарушили някой член на Наказателния кодекс, при който престъплението се счита от общ характер). Само че в Наказателния кодекс няма само телесни повреди, убийства и (кибер)тероризъм. Има и престъпления по служба, безстопанственост, попълване на документи с невярно съдържание и други престъпления, в които може да бъде обвинен един премиер, вицепремиер, министър, зам.министър, председател на агенция или комисия или кмет. И обвиненията се повдигат именно от прокуратурата, когато тя реши. А за определени обвинения, например на гореспоменатите длъжности, когато главният прокурор реши.

Появяват се тук-там странни защитници на Гешев (и Цацаров), според които прокуратурата си работи чу-дес-но, щото, видите ли, били арестували разни съмнителни бизнесмени (наречени малко пресилено „олигарси“). Това, че прокуратурата от време на време обвинява някой престъпник и даже накрая той влиза в затвора, е супер. Все пак – това ѝ е работата.

Причината обаче да се слагат хора като Гешев и Цацаров на тия постове е не това кого са обвинили успешно, а четири други неща:

  • кого НЕ са обвинили – когато знаеш, че всяка схема ще ти се размине, защото „имаш човек в прокуратурата“, корупцията си тече най-добре
  • кого са обвинили със съзнателни пропуски в обвинението, за да падне в съда – за да може после някой да каже „ние ги хващаме, те ги пускат“, прехвърляйки топката на съда
  • кого са обвинили без доказателства, само за да го държат в страх. Например министрите на Реформаторския блок получиха обвинения, които после се разпаднаха
  • за кого главният прокурор има „папки“, които чакат да бъдат отворени – когато си министър и ти покажат папката в прокуратурата, ще правиш точно това, което ти кажат, ако не искаш тя да бъде превърната в обвинение

Та, да оставим Минюстайковци, Баневи и подобни. Не за тях става дума тук.

Става дума за корупцията по високите етажи, която остава ненаказана. Но още повече става дума за всеки, който се опита да счупи някоя съществуваща схема, и срещу който може да бъде повдигнато обвинение и да бъде разнасян по медиите и из съдилищата.

На Христо Иванов беше проверяван за обществена поръчка за поддръжка на климатици. До обвинение не се стигна, защото щеше да е прекалено абсурдно. Даниел Митов и Христо Ангеличин бяха обвинени, за неизгодни самолетни билети за нуждите на министерството и за неизгодна сделка с телефонни централи. Обвиненията се разпаднаха в съда, разбира се.

В горните примери трябва да отбележим, че това са поръчки на сравнително ниски стойности, които министрите разписват, защото хората под тях са им ги дали за подпис. Един министър трябва да подпише тонове документи и носи отговорност за тях. Съответно е лесна мишена за саботаж или при неволна грешка.

С тези механизми на всеки бъдещ министър му е ясно, че във всеки един момент могат да му спретнат проверка и дори обвинение. Без значение дали е нарушил закона. Всичките четири неща от списъка по-горе изкривяват властта и я правят зависима от прокуратурата. Естествено, че прокуратурата трябва да може да повдига обвинения, въпросът е, че в момента се използва и за други цели.

Не съм специалист по съдебна реформа, но знам, че в западна Европа има доста по-различен модел на държавното обвинение. Нашият е съветски. Там целта е била ясна – противниците на властта са врагове на народа. Сега целта, уж, е различна.

Та, изборът на главен прокурор може да изглежда маловажен. Привидният консенсус около кандидатурата на Гешев може да звучи успокоително. Но всъщност един човек, който в телевизионни интервюта обвинява политическата опозиция в тероризъм, ще получи седемгодишен мандат с безконтролна власт да обвинява или не обвинява „когото трябва“. Тази власт е прекалено голяма и затова този избор е толкова важен. Не просто за съдебната система, а за демократичното развитие на страната.

The Personal Data Store Pattern

Post Syndicated from Bozho original https://techblog.bozho.net/the-personal-data-store-pattern/

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.

So, the personal data store pattern is an architectural approach to personal data protection. It can be implemented as a “personal data microservice”, with CRUD operations on predefined data entities, an external service can be used (e.g. SentinelDB, a project of mine), or it can just be a centralized database that has some proxy in front of it to control the access patterns. You an imagine it as externalizing your application’s “users” table and its related tables.

It sounds a little bit like a data warehouse for personal data, but the major difference is that it’s used for operational data, rather than (just) analysis and reporting. All (or most) of your other applications/microservices interact constantly with the personal data store whenever they need to access or update (or “forget”) personal data.

Some of the main features of such a personal data store, the combination of which protect against data breaches, in my view, include:

  • Easy to use interface (e.g. RESTful web services or simply SQL) – systems that integrate with the personal data store should be built in a way that a simple DAO layer implementation gets swapped and then data that was previously accessed form a local database is now obtained from the personal data store. This is not always easy, as ORM technologies add a layer of complexity.
  • High level of general security – servers protected with 2FA, access control, segregated networks, restricted physical access, firewalls, intrusion prevention systems, etc. The good things is that it’s easier to apply all the best practices applied to a single system instead of applying it (and keeping it that way) to every system.
  • Encryption – but not just “data at rest” encryption; especially sensitive data can and should be encrypted with well protected and rotated keys. That way the “honest but curious” admin won’t be able to extract anything form the underlying database
  • Audit trail – all infosec and data protection standards and regulations focus on accountability and traceability. There should not be a way to extract or modify personal data without leaving a trace (and ideally, that trace should be protected as well)
  • Anomaly detection – checking if there is something strange/anomalous in the data access patterns. Such strange access patterns can mean a data breach is happening, and the personal data store can actively block it. There is a lot of software out there that does anomaly detection on network traffic, but it’s much better if the rules (or machine learning) are domain-specific. “Monitor for increased traffic to those servers” is one thing, but it’s much better to be able to say “monitor for out-of-the ordinary accesses to personal data of such and such kind”
  • Pseudonymization – many systems that need the personal data don’t actually need to know who it is about. That includes marketing, including outsourcing to 3rd parties, reporting functionalities, etc. So the personal data store can return data that does not allow a person do be identified, but a pseudo-ID instead. That way, when updates are made back to the personal data store, they can still refer to a particular person, via the pseudonymous ID, but the application that extracted the data in the first place doesn’t get to know who the data was about. This is useful in scenarios where data has to be (temporarily or not) stored in a database that lies outside the personal datastore.
  • Authentication – if the company offers user authentication, this can be done via the personal data store. Passwords, two-factor authentication secrets and other means of authentication are personal data, and an important one as well. An organization may use a single-sign-on internally (e.g. Active Directory), but it doesn’t make sense to put customers there, too, so they are usually stored in a database. During authentication, the personal data store accepts all necessary credentials (username, password, 2FA code), and return a token to be used for subsequent calls or to be used a a session cookie token.
  • GDPR (or CCPA or similar) functionalities – e.g. export of all data about a person, forgetting a person. That’s an often overlooked problem, but “give me all data about me that you have” is an enormous issue with large companies that have dozens of systems. It’s next to impossible to extract the data in a sensible way from all the systems. Tracking all these requests is itself a requirement, so the personal data store can keep track of them to present to auditors if needed.

That’s all easier said than done. In organizations that have already many systems working alongside and processing personal data, migration can be costly. So it’s a good idea to introduce it as early as possible, and have a plan (even if it lasts for years) to move at least sensitive personal data to the well protected silo. This silo is a data engineering effort, a system refactoring effort and an organizational effort. The benefits, though, are reduced long-term cost and reduced risks for data breaches and non-compliance.

The post The Personal Data Store Pattern appeared first on Bozho's tech blog.

Без фалшиви дилеми на първи тур

Post Syndicated from Bozho original https://blog.bozho.net/blog/3410

Наближават местни избори. И поне в София, а и на доста други места, се прокрадва и пробутва схващането, че изборът е само между две опции и от нищо друго няма смисъл, и битката ще е точно между тези две опции. В контекста на София се опитват да ни убедят, че това ще е битката Фандъкова – Манолова. И да си изберем една от тях. В същото време се опитват да ни пробутат и друга теза – че издигането на един или друг кандидат помагало я на Манолова, я на Фандъкова, в зависимост „чий“ анализатор питаме.

Това, разбира се, са глупости. Т.нар. тактическото гласуване, при което гласуваш не за предпочитания от теб кандидат (или партия), а за някой от обявените за фаворити, действително съществува, но от него няма нужда на първи тур. Една от целите на изборите в два тура е именно да минимизират тактическото гласуване, защото „по-малкото зло“ ще може да се избере на втори тур, ако избирателят прецени.

Тактическо гласуване има на парламентарни избори, където избирателите решават да не подкрепят партия, която не е сигурно дали ще влезе в парламента. Такова има и на избори в един тур (като например парламентарните във Великобритания), където след гласуването победителят печели, всички останали губят. Всичко това е само един тип тактическо гласуване, наречено „полезен глас“, т.е. целта е гласът да не се загуби. Но на първи тур гласът не се губи, така че тактическото гласуване е излишно

Така че да не се оставяме да ни заблудят с фалшиви дилеми на първи тур – можем да гласуваме точно за този, за който искаме да гласуваме, като така резултатът ще отразява реалните нагласи. След това, на база на тези нагласи, а не на база на твърденията на един или друг анализатор, ще се реши кой ще отиде на балотаж.

В тази връзка и твърденията, че издигането на арх. Игнатов работело в полза на някого също е доста изпразнено от смисъл – ако отхвърлим фалшивата дилема за избор между Манолова или Фандъкова на първи тур, само защото предпочитаният кандидат няма шанс, то издигането му (и на който и да било друг) не помага на Манолова или Фандъкова.

Резултатът на първи тур не е изцяло без значение – водещият от двамата отиващи на балотажа може да увлече малко повече гласове, но пък същият резултат може да мотивира повече избирателите на другата страна. Няма ясно предсказуем и лесно измерим ефект на разликите на първия тур.

Шансовете на един кандидат, разбира се, са фактор при вземането на решения. Ако харесваш някого, но социологията го отчита под 1%, а второто ти предпочитание е с 10%, то по-високият шанс може да надделее над предпочитанията, ако те не са чак толкова силни. Този тип разсъждения са минус на всяка система, в която избирателят трябва да направи точно един избор. Има и алтернативни системи (тази или тази), в които избирателят подрежда кандидатите по реда, в който ги предпочита, което отразява доста по-точно нагласите. Тези системи също не са перфектни и при тях съществуват определени видове тактически гласувания, но така или иначе у нас те не са популярни.

В крайна сметка изборът не е предрешен. Дори още нямаме адекватни социологически проучвания, които да кажат кой кандидат какво се очаква да вземе, с всички уговорки за неточностите в социологията, които бяха направени след евроизборите. И няма нужда да гласуваме тактически на първи тур за Фандъкова или Манолова. Дали третият кандидат, арх. Игнатов, има шанс да се намеси там, ще разберем. Но изключването му априори е предизборен шаманизъм. Нека се възползваме от гъвкавостта на изборната система с два тура и да му мислим на балотажа, ако предпочетеният от нас кандидат не стигне до него.

Remote Log Collection on Windows

Post Syndicated from Bozho original https://techblog.bozho.net/remote-log-collection-on-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 (e.g. this or this. To be honest, I don’t know whether the native calls and the powershell commands don’t use WMI and/or CIM underneath as well – probably.

So, in order to get these options running, the following configurations have to be done:

  1. Allow the necessary network connections to the target machines (through network rules and firewall rules, if applicable)
  2. Go to Windows Firewall -> Inbound rules and enable the rules regarding “Remote log management”
  3. Create a service account and configure it in the remote collector. The other option is to have an account on the collector machine that is given the proper access, so that you can use the integrated AD authentication
  4. Add the account to the following domain groups: Event log readers, Distributed COM users. The linked article above mentions “Remote management users” as well, but that’s optional if you just want to read the logs
  5. Give the “Manage auditing and security log” privilege to the service account through group policies (GPO) or via “local security policy”. Find it under User Rights Assignment > Manage auditing and security log
  6. Give WMI access – open “wmimgmt” -> right click -> properties > Security -> Advanced and allow the service account to “Execute Methods”, “Provider Write”, “Enable Account”, “Remote Enable”. To be honest, I’m not sure exactly which folder that should be applied to, and applying it to the root may be too wide, so you’d have to experiment
  7. Give registry permissions: Regedit -> Local machine -> System\CurrentControlSet\Services\eventlog\Security -> right click -> permissions and add the service account. According to the linked post you also have to modify a particular registry entry, but that’s not required just for reading the log. This step is probably the most bizarre and unexpected one.
  8. Make sure you have DCOM rights. This comes automatically wit the DCOM group, but double check via DCOMCnfg -> right click -> COM security
  9. Grant permissions for the service account on c:\windows\system32\winevt. This step is not required for “simple” reading of the logs, but I’ve seen it in various places, so in some scenarios you might need to check it
  10. Make sure the application or service that is reading the logs remotely has sufficient permissions – it can usually run with admin privileges, because it’s on a separate, dedicated machine.
  11. Restart services – that is optional, but can be done just in case: Restart “Windows Remote Management (WS-Management)” and “Windows Event Log” on the target machine

As you can see, there are many things that you can miss, and there isn’t a single place in any documentation to list those steps (though there are good guides like this that go in a slightly different direction).

I can’t but make a high-level observation here – the need to do everything above is an example of how security measures can “explode” and become really hard to manage. There are many service, groups, privileges, policies, inbound rules and whatnot, instead of just “Allow remote log reading for this user”. I know it’s inherently complex, but maybe security products should make things simpler by providing recipes for typical scenarios. Following guides in some blog is definitely worse than running a predefined set of commands. And running the “Allow remote access to event log” recipe would do just what you need. Of course, knowing which recipe to run and how to parameterize it would require specific knowledge, but you can’t do security without trained experts.

The post Remote Log Collection on Windows appeared first on Bozho's tech blog.