SecurityBlanket: When an Idea Became a Product
When an Idea Became a Product
Episode 1 ended with me returning home from ING Bank with an unusual combination of things.
I understood the problem.
I knew the bank's requirements.
I knew the deadline they were working towards.
I even knew the budget they had available.
What I didn't have was a product.
Looking for something that didn't exist
My first instinct wasn't to start writing software.
It was to see whether someone else had already solved the problem.
I spent time researching the security products that were available at the time. There were plenty of them. Some encrypted files while they were stored. Others protected communications. Some specialised in particular operating systems or hardware platforms.
What I couldn't find was a solution that protected information throughout its entire journey.
That was the gap.
The banks weren't looking for another encryption product. They needed an end-to-end solution that protected data as it moved from one system to another, whether it was travelling across a local network, between countries or ultimately into the Tandem systems at the heart of the bank.
Eventually I reached a simple conclusion.
The product I wanted didn't exist.
So I decided to try building it myself.
Starting with what I already knew
I wasn't starting from scratch.
A few years earlier I had developed Integrated Solutions, our Tandem data extraction software. It already contained a great deal of the framework I needed.
Rather than opening an empty project, I stripped away everything that wasn't relevant, leaving myself with a solid skeleton on which to build.
It saved months of work.
More importantly, it meant I was building on code that had already proved itself in real banking environments.
Choosing proven building blocks
One thing I never considered was writing my own encryption software.
Cryptography is one of those areas where "rolling your own" is rarely a good idea.
Instead, I looked for a mature product that exposed its functionality through an Application Programming Interface (API). After evaluating several possibilities, I chose Secret Agent because it gave me everything I needed.
Through its API I could create certificates, encrypt files, digitally sign them, verify signatures on receipt and decrypt them again.
The cryptography already existed.
My objective wasn't to invent better cryptography. It was to integrate proven components into an architecture that solved a real business problem.
Security had to follow the data
The principle behind SecurityBlanket was surprisingly simple.
Every time information moved, it needed protecting.
When payment instructions first arrived at the local bank, they were encrypted.
If another system needed to process the information, it was decrypted only for as long as necessary before being encrypted again and passed on.
Rather than thinking of security as something that happened at the beginning or the end of a process, I treated it as something that travelled with the data itself.
Looking back, I realise that idea has shaped almost everything I have built since.
The phone call
After about six months of development I had a working system.
I remember wondering whether I should call ING.
Perhaps they had already solved the problem.
Perhaps they had moved on.
In the end I decided I had nothing to lose.
In the end, it wasn't really my decision. My wife simply said, "What have you got to lose? Give them a call." She was right.
It turned out they were still struggling.
The technical issues were no longer the biggest obstacle. Different departments had different priorities, different platforms and different political considerations. Integrating multiple security products into a coherent solution had proved much harder than expected.
I asked if I could demonstrate what I had built.
Their answer was simple.
"If it works, we'll buy it."
From prototype to production
Fortunately, it worked.
Not perfectly at first.
Like every real project, there were refinements to make. Working closely with ING's Internal Risk Management team, I added additional controls, permissions and tokenisation to meet their operational requirements.
Before long SecurityBlanket was protecting payment data across six European banking operations.
Later, another division within ING adopted it for their worldwide payment and cash management systems, extending its reach to around twenty countries.
What had started as a personal experiment had become a production system protecting real banking data.
The best compliment I ever received
During later contracts at ING I worked alongside one of the finest Tandem engineers I have ever met, Gerrit Jan Abma.
Gerrit Jan wasn't trying to help me prove SecurityBlanket worked.
He was trying to break it.
Oddly enough, I welcomed that.
If anyone was going to find a weakness, I wanted it to be someone of Gerrit Jan’s calibre.
He never did.
One incident has stayed with me over the years.
After SecurityBlanket was deployed in Sofia, the local team complained that they could no longer alter the payment files.
That wasn't a bug.
It was exactly what the software had been designed to prevent.
Sometimes the best evidence that a security system is working is when people discover they can no longer do something they used to take for granted.
Looking beyond banking
SecurityBlanket solved ING's problem.
But it also changed the way I thought about security.
Until then I had regarded security as something organisations purchased.
Afterwards, I began to see it differently.
The principles weren't unique to banks.
Every organisation moved sensitive information.
Every organisation faced the same fundamental problem.
How do you protect data while it is moving?
At the time, I thought I had solved a banking problem.
I hadn't.
I had uncovered a principle that would stay with me for the next twenty years.
Eventually, it would lead me to build something very different.
It would lead to SecurityNet.
Next: What thirty years in banking taught me about trust, privacy and the movement of data.
