Thursday, 28 April 2016

My Technical Learning Curve: Encryption

Resilience professionals, particularly those from a non IT background, really need to step up and develop their overall understanding of technology, especially focusing on how we all communicate with one another in the modern age. I mean, how else are you going to be able to fully appreciate the magnitude of risks potentially facing your business?

I hear you say “my IT guy will tell me” but even then beyond the tech descriptions you’re only ever getting their individual perspective. How confident are you of their awareness of the business process that’s using the technology? or the impact to customer experience? Or how it might affect the long term leadership strategy as to why you have that technology in the first place? In my experience, very technical employees are often very skilled in one particular area of focus and tend to think in a very linear way. I therefore think it’s vital that resilience professionals who face off to senior management and leadership need to have a basic understanding of how some of it actually works.

Oh and by the way I’m not just talking about all the buzzwords you see coming out from half-baked vendor blogs repeatedly referencing cool words like “Brute Force”, “Spear Phishing” or “Whaling” or “Social Engineering”.

I’m talking about things like:

- When I send confidential information online – how is it actually secured?
- What is the security model around how my business and customer data is stored?
- How can I trust any online resource I access?
- How is data actually stored?
- What tools can I use defend against unwanted incoming traffic into my network?

There are countless others but these are some of the fundamentals that we need to start getting our head around.

So after wondering in which direction to take my blog I’ve decided that moving forward I will start to post experiences from my own tech learning curve to help share an understanding among my peers in the resilience community, many of whom I know are equally as limited in their own IT knowledge!

Disclaimer! I’m not saying it’s going to be totally accurate and I invite others to contribute below to clear up any duff steer that I give. That’s the beauty of sharing!

My first experience comes from the world of encryption and keys, something that has taken me a while to get my head around and I hope it helps…

Asymmetric and Symmetric Keys

Starting with a very basic example that helped me to understand the concept:

Let’s say you wanted to send Person X a package but you know the courier is a bit dodgy and is likely to open anything unsecured that you send. Therefore, you’re going to need to lock it up with a padlock!

However, if you go ahead and send the package with the padlock, Person X won’t be able to open it because they don’t have the key! Also, even if you sent the key separately the courier will take it before it gets to them. So how do you send it across securely but so they can still open it? (Don’t say use a combination lock and text them the code! It’s a padlock and key that you have!).

Solution: You send your package with your padlock on it and no key. Person X doesn't open the package when they receive it but instead return it back to you adding their own padlock. Then you take off your padlock and once again send it back across leaving them to unlock their own remaining padlock.

Easy right? Hmmmm

Okay well it doesn't get any easier! Here is an example given to me recently of how encryption might work between two parties:

John wants to send Stuart a highly confidential file.

So John encrypts the file being sent to Stuart using a key that he generates from his encryption software but doesn't send the key itself across with the file.

Stuart receives the encrypted payload (i.e. the file), He already has the algorithm in his encryption software to mathematically decrypt it but he doesn't have the key generated by John to actually do so. This will be sent differently.

John then uses Stuart's available public key (this is an encryption that only Stuart can decrypt) to encrypt the required key before sending it across to Stuart.

Stuart can then use his private key to decrypt the key sent by John.

Stuart then uses the key that John generated to decrypt the original file to see the confidential material.

Told you...easy...

Let me know if anyone sees it differently or has a better way of explaining it!

On to the next curve…

No comments:

Post a Comment