If you're new to thinking about cyber security, in this episode I give you my top 5 recommendations to address in your organisation:
Or listen at:
Published: Wed, 13 Oct 2021 16:17:48 GMT
Transcript
Hello, and welcome back to the Better ROI from software development podcast.
In this episode, I'm going to continue my mini-series on Security Briefings. In the last episode, I introduced you to the importance of security and why it really matters to you.
In this episode, because security is such a big topic, I'll give you my ideas of where to start. Security is a massive area, and it can be quite daunting. So my top five, for things to think about when you're starting to think about security, patching, backups, no shared credentials, single sign on, and solution reviews.
All these top five obviously don't cover everything in security, but it gives you a good starting point if you're only just coming to it fresh.
So let's start with patching.
Wikipedia describes patching as:.
"A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it. This includes fixing security vulnerabilities and other bugs, with such patches usually being called bugfixes or bug fixes. Patches are often written to improve the functionality, usability, or performance of a program."
The key here that we're thinking about is that we're using patching to fix security vulnerabilities.
This may come as a surprise, but software is not perfect. Very rarely is software completely security free. Microsoft, Apple, Google, all of the big players regularly release security patches for their software.
Now, these people have extensively large development teams. They have probably the best in the industries in terms of security and making sure their software is as good as it can be. And yet they still have to release regular security patches. Each of them will be releasing multiple patches per month, possibly in per week.
As such, we really need to be thinking about applying those patches as quickly as possible.
Now, it may come as a surprise to you that we're finding security patches so often, but we do. That's just the nature of software, and sometimes this could be from software that is decades old. It is a fact of life that we will find security vulnerabilities in any piece of software. The question is how quickly we can address it and make sure that it isn't exposing us and our organisations and our customers.
If we think about the evolution of a security vulnerability, it starts with what's known as a zero day. A zero day is where the exploit exists and is known about - the problem in the software is known about, but not by the manufacturer, not by the software provider.
So, for example, if there is an exploit within Word but isn't known by Microsoft, that's considered a zero day - all the time that Microsoft isn't aware of it, then that vulnerability can be exploited for bad purposes.
And obviously, it depends who finds that vulnerability.
If it's a security researcher, they will probably go on to try and disclose that vulnerability to Microsoft in a responsible manner - in future episodes. I'll probably talk about something like bug bounties, where the likes of Microsoft will actually pay security researchers for any bugs they find. If, however, that exploit is found by somebody that wants to use it for nefarious purposes, that zero day, because Microsoft doesn't know about it, effectively allows them to utilise it to gain access to systems and data and people.
Once the manufacturer, say Microsoft for example, are aware of the exploit, they can start to make patches available. They can make fixes to their software. Thus, the quicker they are aware of the exploit, and it turns from being a zero day to being something where there's a patch available, the better.
And once that patch is available, we need to get it deployed as quickly as possible so that our systems aren't exploitable.
Now, many systems now are called evergreen. They automatically download and install updates. Windows will download and install updates. Chrome, Edge, Firefox, many of the systems we use on a day to day basis are set to automatically download.
But that isn't always the case. They aren't always applied automatically. You may need to think about when you apply them. And the important thing is is make sure you're applying them regularly.
You always want to make sure that you're running the most current maintained software.
You want to make sure that your Windows updates have been installed. You want to make sure that iPhone and iPad updates are done. You also want to make sure your servers and even your network equipment have any updates applied in a timely manner.
The shorter period of time between the zero day and applying the patch to your system, the shorter the risk, in terms of window where your systems can be exploited. Thus, it is key to make sure you're doing this on a regular cadence and you are getting patches applied as quickly as possible.
The next recommendation was backups.
Question, do you have backups?
Do you have backups of your most sensitive, important data?
Are you sure?
And more importantly, when was the last time you used them?
It isn't uncommon for people to think they've got backups, only to find when they go back to use them, they're not available or they just simply do not work.
Whenever you're thinking about your backups, you need to think how quickly you could restore? How quickly do you need to restore? Are we talking hours, days, weeks or even shorter? And you need to test this regularly.
This should form part of your business continuity plans.
Wikipedia describes business continuity as:.
"Business continuity may be defined as "the capability of an organization to continue the delivery of products or services at pre-defined acceptable levels following a disruptive incident”, and business continuity planning (or business continuity and resiliency planning) is the process of creating systems of prevention and recovery to deal with potential threats to a company. In addition to prevention, the goal is to enable ongoing operations before and during execution of disaster recovery. Business continuity is the intended outcome of proper execution of both business continuity planning and disaster recovery."
So obviously as part of that business continuity, you want to understand how quickly you can have those systems available to you, how quickly you need to be able to restore backups and, more importantly, prove that you can do it.
So what has backups got to do with security?
Well, the important thing here is that your backups are providing a safety net, so if something does go wrong, say, for example, that you're the victim of ransomware that encrypts your data, having those backups are a way of being able to recover.
And backups provide that ultimate safety net that, if something goes wrong, then we can restore the data because we have it.
And as we're backing up regularly and testing regularly, we know that we're in a good position that if something happens, then we can respond relatively quickly.
Ok, let's move on to no shared credentials.
So what is this and when does it happen?
I find this all the time. It may even just be an IT thing where they share administrator passwords, probably the worst credentials to share, or we may share online services. Someone has signed up for something using the credit card, using their email address, and thus they share that email address and that password to everybody in the organisation or department so they can all use that online service.
The problem with this is there's no accountability, there's no audit trail of who did what.
Take the administrator account; If it's a shared set of credentials, you have no idea who has done what on what day. It could be any number of people that have that administrator account.
In one organisation I worked with, their main content management system, used for all the content on the website, was all done through one username. Thus, if there was a problem, it was very difficult to go back to understand who made it and why - because it was all logged under this one account.
And shared credentials are much more likely to leak. They will be emailed around, they'll be put on Post-it note. The whole point is they are shared. They're probably not treated with the same level of security as individual accounts.
And imagine if a disgruntled employee leaves with that shared credentials, how many times are we changing those shared credentials? We probably aren't. Thus, they become quite an opportunity for exploitation.
And once they shared it, it's almost impossible to revoke or change the password. Primarily because we don't know who's using it, so it's very difficult to make sure everybody is included in that notification that we've changed the password.
So the best situation is to avoid doing it in the first place. You should never share credentials.
All right, let's move on to single sign on.
Wikipedia describes single sign on as:.
"Single sign-on (SSO) is an authentication scheme that allows a user to log in with a single ID and password to any of several related, yet independent, software systems."
So what does this mean?
This means if you've got multiple services you're using, maybe you're using Office 365, maybe using Salesforce, maybe you're using bespoke applications developed internally, maybe you're using online services from other third parties, you want all of those credentials to be the same.
You want them all linked back to your single sign on with the same username and password.
This may sound counterproductive. We're talking about not sharing credentials.
But this is your credentials. You want to be able to use the same credentials across all systems.
Why?
Because they can be managed properly.
What I usually find is an organisation has organically added these other systems to their core system. So while they may be having a central username & password for their internal systems, all of these other systems, especially third party online systems, normally have different sets of credentials.
And this makes it very difficult to manage.
And to be honest, the main thing we're talking about here is hygiene.
So if somebody leaves the organisation, are you confident that all of their access to all of these systems is stopped?
If you've got a different login for Office 365, Salesforce or your bespoke apps or your online services, that's an overhead in terms of making sure that all of those accesses are removed when someone leaves.
And to be honest, it doesn't happen.
There will always be some third party service that is forgotten, some third party service that nobody touches.
Whereas with single sign on, you're using the same set of credentials and it's all managed centrally. Thus, when you have a leaver, you can disable their account in one place and everything then is tied back to that and blocks access to everything.
It also makes it a lot easier in the event of needing to change a password, you're changing a password across the entire estate.
And you, as a user, are only having to remember one password for all of your systems, which means you can focus on creating a good password rather than having a mediocre password for all those separate systems. Because you can remember easier.
I can't overstress the idea that this is hygiene. This is about cleaning up after somebody has left. I've seen too often many, many years later, that people still have access to some systems because they aren't on the list of systems that need to be cleaned up after leaver has left.
Ok, let's talk about the last piece, the solution reviews.
This, for me is very similar to how I talked about Game Days in episode 47. Any system that you develop or take into your organisation, you want to sit down and you want to review. You want to play it through in terms of how good is it at security?
Now, when I talked about it in Game Days, we were talking about in the ability to support and make sure that it would work under most situations and you knew how to support it. In this, we're looking at security and understanding where the possible problems may be. Think about this like a fire drill. We do this to make sure we can check to see what needs to be improved.
We go through and discuss ideas. We expose possible problems. And this is part of shared learning. This is having multiple people in the room that may not have previously had much exposure to the software, but can bring their thoughts to bear on how well have you thought about this? How do you cover that?
And having these regular solution reviews allows us to keep top of our software to make sure that we keep security front of mind.
And then it's important to repeat that exercise on a regular cadence. Like everything in software. It's a learning exercise. Over time, we learn more. So you expect to learn from a review to review, so you may have reviewed a piece of software six months ago, only to review it now and actually go as "we should now be doing this".
It's not a static thing. Software is not static.
So having a solution review can be a good opportunity for everybody just to take some time and think about the security implications of whatever software package you may be developing.
And in truth, this may not actually just be your own custom software. This may be things where you're bringing in third party systems such as Office 365 or Salesforce. Again, having that solution review round it just to ask the questions.
I personally find these sort of activities, and anything related to Game Days, as being incredibly valuable for improving systems. It's investing in making sure that systems have the level of quality - and in this case, security that we want going forward.
And I really do think it is well worth investing that time, which is why it's in my top five.
Ok, in this episode, I've tried to give you an idea of where to start if you're new to thinking about security. A lot of it comes down to basic hygiene, the cleaner you keep your kitchen less likely you will catch food poisoning.
You must think about making this a priority.
The five steps I've given you, will it stop everything? No, not even close.
But their the basics to start with. They help against trying to protect against those opportunists. Think about back to last episode where I talked about people just trying car doors in a car park. What we're doing here is making the initial steps much harder for somebody just to walk up to our car, open the door and take our Taylor Swift CDs.
What we're doing is we're making harder - it requires more effort, more time, more capabilities. Thus will be a deterrent for a good chunk of people trying to attack our networks.
And it's probably not going to come as much a surprise to anybody that the next step I'm going to recommend after this is training, training, training, training with more training.
The more that our teams understand about the potentials of potential threats, the more they understand about how to combat them, the better they will always be. And that should then feed back into things like the solution reviews and those Game Days so that we can make sure that we're keeping on top of potential problems, potential exploits and potential dangers to the future and reputation of our organisations.
Thank you very much for listening to this podcast. I look forward to speaking to you again next week.