Security – Page 2

Singular Execution of Mission-Critical Operations

Something happened this month with Romania’s ING Bank. I’m sure you’re probably aware of it. They managed to execute a several (well, maybe more than just a several) transactions more than once. Well, shit happens, I guess. They have eventually fixed it. At least they say so. I choose believe them.

This unfortunate happening triggered a memory of my first time working in a mission-critical environment where certain operations were supposed to be executed exactly, absolutely, only once. It was for a german company. back in 2013. I am not allowed to mention or make any refference to them or the project, so let’s anonymously call them Weltschmerz Inc. It went something like this (oversimplified diagram):

I don’t claim that ING’s systems can be oversimplified to this level, but for the sake of the argument, and the protection I assumed for the so-called Weltschmerz Inc. let’s go with the banking example.

Trusted actor is me, when using a payment instrument that allows me to innitiate a transaction. (can be me using my card, or me being authenticated in any of their systems)

Trusted application is the innitial endpoint where I place my input describing my transaction (can be a POS, can be an e-banking application, anything)

The Mission-Critical Operation is the magic. Somehow, the application (be it POS, e-banking, whatsoever) knows how to construct such a dangerous operation.

Trick is, that whoever handles the execution of this operation must do it exactly, absolutely, only once. If the trusted application has a bug /attack/misfortune and generates two consecutive identical operations, one of them will never get executed. If I make a dubious mistake and somehow am allowed to quickly press twice a button, or if the e-banking / POS undergoes an attack, the second operation will be invalid. If anyone tries to pull a replay attack, it will still not work.

How to tackle this? Well, there are alot of solutions for this problem. Most of them gravitate around cryptography and efficient searching, here’s the approach we took back then:

Digitally signing the operation: necesarry in order to obtain a trusted fingerprint of the operation. the perfect unique identifier of the operation.
I understand, it is not easy to accomodate a digital signature ecosystem inside your infrastructure, there’s a lot of trust, PKI + certificates, guns, doors, locks, bieurocracy and shit to handle. It is expensive, but that’s life, no other way around it unfortunately.

Storing and partitioning: this signed version is stored wherever. However its signed hash must be partitioned based on variable that derrive from the business itself. If we are to consider banking, and if we speculate, we could come up to: time of the operation, identified recipient, innitiator, requested value, actual value, soo many more possibilities…. This partition is needed because, well, theory and practice tells us that “unicity has no value unless confined” If you are a very young developer, keep that in mind, it will cut you some slack later in your life.

Storing this hash uniquely inside a partition is easy now, it is ultimately just a carefull comparrison of the hashes inside a partition and the new operation which is a candidate for execution.

Hint: be carefull in including time in your partition. Time should not only be a part inside the signed operation, but also a separate, synchronised, independent, clock. I’m sure you already know this.

If you do this partitioning and time handling by the book, no replay attack will ever work.

Execution: Goes in all partitions that have something inside of them, gets the operations, does the magic. Magic does not include deleting the operation hash in the partition afterwards. It includes some other magic maker. I choosed my words carefully here :). #ACID.

There’s a lot more to it:

signed hashes should be considered highly sensitive secrets, tough an encryption mechanism must be employed. Key management in this case is an issue. That’s why you will probably need an HSM or some sort of simmilar vault for the keys, and key derivates
choose your algorithms carefully. If you have no real expertise in cryptography, please call someone that does. Never assume anything here unless you really know how to validate your assumptions
maintaining such an infrastructure comes with a cost. It’s not such a deal breaker, but it is to be considered.

Again, I am not claiming that ING Romania did anything less than the best in order to ensure the singular execution, this article is not related directly to them. It is just a kind reminder, that it is possible to design such a mission-critical environment, for singular execution of certain operations.

As for my experience, it was not in banking, but rather a more open environment. #Marine, #Navigation.

Cheers to us all.

Avoidable privacy happenings

Last time, I tried to brief some of the steps you need to cover before starting to choose tools that will help you achieve compliance. Let’s dig a little deeper into that by using some real life negative examples that I ran into.

Case: The insufficiently authenticated channel.

Disclosure disclaimer: following examples are real. I have chosen to anonymize the data about the bank in this article, although I have no obligation whatsoever to do so. I could disclose the full information to you per request.

At one point, I received an e-mail from a bank in my inbox. I was not, am not, and hopefully will not be a client of that particular bank. Ever. The e-mail seemed (from the subject line) to inform me about some new prices of the services the bank provided. It was not marked as spam, and so it intrigued me. I ran some checks (traces, headers, signatures, specific backtracking magic), got to the conclusion that it is not spam, so I opened it. Surprise, it was directly addressed to me, my full name appeared somewhere inside. Oh’ and of course thanking ME that I chose to be their client. Well. Here’s a snippet (it is in Romanian, but you’ll get it):

Of course I complained to the bank. I was asking then to inform me how they’ve got my personal data, asking them to delete it, and so on. Boring.

About four+ months later (not even close to a compliant time) a response popped up:

Let me brief it for you: It said that I am a client of the bank, that I have a current account opened, where the account was opened. Oh but that is not all. They have also given me a copy of the original contract I supposedly signed. And a copy of the personal data processing document that I also signed and provided to them. Will the full blown personal data. I mean full blown: name, national id numbers, personal address etc. One problem tough: That data was not mine, it was some other guy’s data that had one additional middle name. And thus, a miracle data leak was born. It is small, but it can grow if you nurture it right…

What went wrong?

Well, in short, the guy filled in my e-mail address and nobody checked it, not him, not the bank, nobody. You imagine the rest.

Here’s what I am wondering.

Now, in the 21^st century, is it so hard to authenticate a channel of communication with a person? it difficult to implement a solution for e-mail confirmation based on some contract id? Is it really? We could do it for you, bank. Really. We’ll make it integrated with whatever systems you have. Just please, do it yourselves or ask for some help.
Obviously privacy was 100% absent from the process of answering my complaint. Even though I made a privacy complaint 🙂 Is privacy totally absent from all your processes?

In the end, this is a great example of poor legislative compliance, with zero security involved, I mean ZERO security. They have some poor legal compliance: there is a separate document asking for personal data and asking for permission to process it. The document was held, and it was accessible (ok, it was too accessible). They have answered my complaint even though it was not in a timely compliant manner, and I had not received any justification for the delay.

Conclusions?

Have a good privacy program. A global one.
Have exquisite security. OK, not exquisite, but have some information security in place.
When you choose tools, make sure they can support your privacy program.
Don’t be afraid to customize the process, or the tools. Me (and, to be honest, anybody in the business) could easily give you a quote for an authentication / authorization solution of your communication channels with any type of client.

I am sure you can already see for yourself how this is useful in the context of choosing tools that will help you organize your conference event, and still maintain its privacy compliance.

Is your conference event GDPR compliant? – Part 1

I’m starting a series of articles in which I will try to cover my experience in managing privacy and GDPR compliance for several IT related conference events that are handled by “Avaelgo”. During this journey, I will also touch some in-depth security aspects, so stay tuned for that.

As I am sure you know already, a conference is a place where people gather, get informed, do networking (business or personal), have fun, and who knows what other stuff they may be doing. The key aspect here is that for such a conference to be successful, you need to have a fair amount of people being part of it. And since people are persons, well, that also means a fair amount of personal data.

There’s a lot to cover, but we’ll start with the basics. If this is the first time you are organizing such a conference, then you already have a head start: you don’t have to change anything. If not, then you must start by reviewing the processes that you already have in place.

In this first article I’m just going to cover what are the key points that you should review. Let’s go:

How do people get to know about your event?

It is very important to know how exactly you are going to market your event. The marketing step is very important, and itself must be compliant with the regulation. This is a slightly separate topic, but it cannot be overlooked.

It does not matter that you will market yourself to participants, speakers, or companies. Personal data is still going to be involved.

How are people going to register for your event?

This means: how are you going to collect data regarding the participants? Is there going be a website that allows registration? Do you allow registration by phone? There are still more questions to answer, but you have an idea about the baseline. These decisions will have a later impact on the security measures you need to take in order to secure those channels

How are speakers going to onboard your event?

Same situation as above, but it may be that there is a different set of tools for a different workflow.

How are you going to verify the identity of the participants?

Is someone going to be manually verifying attendance and compare ID card names with a list? Is there going to be a tool? Is there a backup plan?

Do you handle housing / travelling for speakers / participants?

If yes, you will probably need to transfer some data to some hotels / airlines / taxies, etc…

Do you have sponsors? Do they require some privilege regarding the data of the participants?

This is a big one, as I am sure you know, some or all of the entities that collaborate on your conference will require some perks back from your conference. It may be that they are interested in recruitment activities, or marketing activities, or some other kind of activities on the personal data of your participants. Trade carefully, everything must be transparent.

Will you get external help?

Companies / volunteers / software tools and services that will help you with different aspects of organizing the event? What are they going to do for you? If they touch personal data, it is kind of important to know before you give it away to them.

Are there going to be promotions / contests?

Usually, these will be threated separately and onboarding to this kind of activities will be handled separately, but still, it is a good idea to know beforehand if you intend to do this.

As you can already imagine, this is not all, but we will anyway cover each topic from here in future articles, and then, probably, extend with some more.

This may look freaky and like a lot of work, but it really is not. Anyway, by trying to tackle personal privacy beforehand, you also get, as a happy byproduct, a cool fingerprint of what you need to do in order to have a successful event. Cheers to that!

A future article will come soon, covering the next steps. I am sure you already have an intuition of what those are.

See you soon!