Introduction to Information Security - Video Script

I recently published a video, and one of my first talking-head style videos, on a quick introduction to information security.

Here’s the original script I wrote to help me record the video.

Script #

Hey folks!

I wanted to talk security as part of application development today, as one of my favourite questions to ask in full-stack engineer interviews is about broad security understanding, and I often don’t get great replies.

Security for me is everyone’s responsibility, while your company may a dedicated security team of some sort, the people who are best placed to secure an application or platform, are the people working on it every day.

In this series of videos, I’ll dig a little deeper into security as a whole, and what we can do as engineers and leaders, to help continuously improve it.

My background is as a software engineer, and I’m now leading teams to improve and architect more resilient and secure systems in the cloud.

But first, what am I even talking about? What are the foundations of information security?

CIA triad #

One of the key concepts is the CIA triad.

Confidentiality. Integrity. Availability.

Confidentiality is only making information available to authorised users, or put another way, not making information available to unauthorised users.

Integrity is ensuring the information is accurate and complete, and cannot be modified by unauthorised users.

Availability is ensuring the information can be accessed when it is needed. Unauthorised users should not be able to prevent users from accessing data.

This is a useful and a key concept when thinking about information, but it’s also important to remember it is focussed fairly heavily on data. For example; an unauthorised user could misuse your hardware, for Bitcoin mining - which would also be a security issue, but not strictly covered by the CIA triad.

Security balancing risk #

Information security in software systems is all about identifying vulnerabilities and threats to an environment, and deciding what, if any, countermeasures to enact to reduce that risk to an acceptable level.

Security is about balancing risk and access to information. Putting an application on the internet is risky, just about mitigating that risk as much as possible to reduce the possibility of a breach or loss of data.

Defence in depth #

Nothing is ever truly secure. I suppose you could lock a computer, in a bunker, with no internet access, behind a hundred bank vault style doors - but with enough time or effort, someone could theoretically break-in—time to get my tin foil hat out.

So one concept we employ is defence in depth. The is multiple layers of security controls, used in conjunction with each other to increase the difficulty of an exploit.

Time for an example, and by no means is this exhaustive: we may want to lock our servers in a secure data centre, with biometrics, CCTV and lots of physical security, and keep the location secret. As many of us are now using cloud providers for our hosting, these are some of the tactics we know they employ.

Next, we can ensure our network security is up to spec, adding firewalls to our systems, only allowing connectivity across systems for the bare minimum to make it work. Especially noteworthy is removing all inbound access from the internet. API gateways are great for this, they can be a proxy and translation layer, so your applications aren’t directly exposed to the internet. We can also look at encrypting our traffic in transit, which will make it harder to eavesdrop and get valuable information.

Using VPNs or a BeyondCorp, ZeroTrust model to access internal systems is an excellent way of adding an extra layer of defence, only allowing privileged users access to specific networks. This also helps keep these networks off the internet.

Then we can look at infrastructure security, the machines our code or applications are running on, ensuring they’re up to date and are running a minimum amount of software necessary for the app to work. We can also encrypt our disks at rest, so our data is less accessible to any unauthorised users. Servers should be regularly scanned for vulnerabilities and malicious software and rectified quickly. This means no more running 2-year-old versions of your favourite Linux distro…

Now we’re down to the application layer, again we’re going to want to check vulnerabilities here, in any of the 3rd party dependencies. A recent report released revealed that 86% of npm and 74% of indirect Java dependencies are vulnerable, with cross-site scripting being most common. Then we’re going to want to review our authentication and authorisation layers, to ensure they’re robust, ensuring our role-based access control works as intended.

We can also check that our secrets are not stored in our code, and are appropriately stored in a centralised secrets management tool.

Wrap up #

Thanks for watching and/or reading - I’d love to know what you thought.

Let me know on twitter - @florx