Continuing my mini-series on security, I discuss why you would paid to be hacked. When you are spending so much time and money putting security in place, it seem counter-intuitive to then pay someone to try and break it. But without that, how will you know if your defenses work? I also introduce three ways of validating those defenses - penetration testing, bug bounties and red team/ blue team exercises.
Or listen at:
Published: Wed, 17 Nov 2021 16:58:06 GMT
Links
Transcript
Hello, and welcome back to the Better ROI from Software Development podcast.
In this episode, I'm going to give you another security briefing - in this episode, I'm going to talk about the counter-intuitive process of paying people to hack you. I'll start off with a why, why you would want to pay someone to hack you. Then I'll talk about three things: I talk about Penetration Testing, Bug Bounties and Red Team/ Blue Team exercises.
So why?
Fundamentally, it's a learning exercise. It's a way of understanding our defences and just how good they are. If you think back to episode forty seven, when I talked about game days, an exercise where we role play and test various scenarios to see how we would cope as an organisation, this is very similar. This is all about running drills. This is all about practicing. This is all about making sure we understand how good we actually are, how good our defences are, how good we are in terms of preparation, our processes, our systems.
The key thing here is that it's a learning exercise.
It's not a pass or a fail.
It's all part of a learning culture. We want to know how well our defence is work and what we can improve.
Without an active test, our security defences are hypothetical. We think they will work. We don't know, but we think they will. Much better to exercise them and learn and understand where the problems are than wait for an attacker to do it.
Ok. Let's look at a few ways in which we could pay people to hack us.
Let's start with Penetration Testing.
Wikipedia describes Penetration Testing as:.
"A penetration test, colloquially known as a pen test or ethical hacking, is an authorized simulated cyberattack on a computer system, performed to evaluate the security of the system ... The test is performed to identify weaknesses (also referred to as vulnerabilities), including the potential for unauthorized parties to gain access to the system's features and data, as well as strengths, enabling a full risk assessment to be completed."
Now, you may have come across doing something like a penetration test as part of a mandatory requirement, either by some form of governance programme or maybe even a partner. In these cases, you're probably seeing them as a one-off exercise, something that effectively is a "tick the box" and will be treated very much as a binary pass or fail. And in most situations, these Penetration Tests are being forced on us because we need to complete them to be able to complete that governance programme or as part of security for our partners. And as such, it's often seen, as I say, more as a one-off exercise, more of a "tick the box", it's more of a job to be done, a task to be completed, something to pass rather than necessary something to learn from.
Now that one-off testing is really not in line anymore with the modern security practises. In the past, potentially yes, if you are building a system for 12 months and everything was done and then released at the end in one go, then a single test of that system was often called for. However, as we are now moving into a situation where we're releasing functionality little and often, then you really need to change the way that testing is done.
As such, the mindset about Penetration Testing should be different.
It shouldn't be treated as a one-off. It shouldn't be treated as a pass or fail.
It should be treated as a periodic exercise. It should be treated as something that is done repeatedly. Something that is repeated on a regular cadence and lessons learnt from each time it's run.
So again, rather than doing the Penetration Testing at the end of a project, we should be making sure that we're set up to run those tests on a periodic basis and cater for the output that comes from them.
Traditionally, a Penetration Test is normally provided by a third party, a third party accredited to provide it. And this is why we normally see them in things like governance programmes.
But going forwards, yes, you can build a relationship with a third party to have that ongoing continue testing, but better still is to look at tools and practises and bring them closer to the developers so that it's being run inline with any development work that's being done.
This is known as shift-left, moving the work earlier in the process so that testing of security is being done as part of the normal development process.
I've talked previously about DevOps - the idea of merging the functions and operations and procedures of development and operations. So whereas traditionally you would have had a development team build it and an operations team have to support it, you merge the two, so you're not having to have that crossover of having two independent teams. An evolution of that is DevSecOps. So a combination of development, security, operations - all of these activities happening earlier in the process - that idea of shifting-left.
So they'd done earlier rather than left right at the end of the development process. By making sure that we're doing all of these activities early and often within the development process, we're ensuring a much better level of quality, a much better level of security. And while I'm not going to cover them in this episode, there are tools out there to help us achieve this, both in terms of being able to do those tests repeatedly and ideally automatically.
Ok, let's move on to Bug Bounties.
So Wikipedia describes Bug Bounties as:
"A bug bounty program is a deal offered by many websites, organizations and software developers by which individuals can receive recognition and compensation for reporting bugs, especially those pertaining to security exploits and vulnerabilities."
So what we're talking about here is an ability to provide a bounty for members of the general public potentially, to report bugs and vulnerabilities to you. You're doing this to harness the power of crowd-sourcing capabilities. So rather than the limitation of a single individual or team, you've got potentially the entire world being able to report bugs to you.
You're going out of your way to publicly offer awards for anybody finding bugs or vulnerabilities. And this goes a number of ways to help your organisation.
Firstly, it helps improve a trust factor. People knowing that you're prepared to put money up front, put some form of bounty up for any vulnerability or bug found, builds a level of trust, it's a public opportunity to demonstrate that commitment.
It also helps to promote ethical behaviour. Now maybe I'm using your software and I accidentally fall across a vulnerability. I realise I can access the entirety of your customer database. Now, while I'd like to believe most individuals would want to report that to you responsibly, making sure that they've got some form of incentive helps to make sure they're doing the ethical behaviour, rather than than potentially looking to see if they could sell the exploit on the dark web to other attackers.
There are a number of platforms out there to help you produce a bug bounty programme - for example, Bug Crowd and Hacker One, I'll include links to their websites in the show notes. Both of these platforms have an established community of security researchers - ranging from exceptionally qualified, well versed hackers to people that are just doing it as a bit of an experiment, a bit of learning.
Those platforms help you to exploit the broad range of capabilities that they have within their members. So as I said, rather than it just being a limitation of a single individual or even a team that you may get in for a Penetration Test, you have that breadth of capability.
As with all things, the more people you have looking at a problem, the more likely you are to solve it. So in this case, the more people and the wider capabilities you have in terms of people that could come and look at your website, looking for vulnerabilities, the more likely you are to expose them.
Ok, let's move on to Red Team/ Blue Team exercises.
Wikipedia describes a Red Team as:
"A red team is a group that plays the role of an enemy or competitor, and provides security feedback from that perspective."
And conversely, the Blue Team are your defenders.
Think about this as any team sport. Any team sport gets better, the team and the players get better, with repetitive practice. You wouldn't expect a world class soccer team, a world class hockey team, a world class baseball team to turn up without any practice - you wouldn't expect them to turn up on the day and be at their best. They need to practice - and this is exactly what that's doing.
The Red Team is using their experience, their capabilities to attack your systems. And the Blue Team are using the capabilities they have, as well as the processes and practises they have in place, to see how well they can defend.
And of course, this is another learning exercise. This is a way of understanding;
Can the Red Team bypass those securities that the Blue Team have put in place?
Are the Blue Team aware of what the Red Team are doing?
Can they see how the Red Team are actively attacking you?
And can they find ways of mitigating those attacks while it is in process?
While a true Red Team exercise would be performed without the Blue Team being given advance warning, I personally see more value with the teams actively knowledge sharing during their process. Being able to share ideas and concepts, of being able to ask "what -if" questions, I certainly think that's very valuable, especially early on in any process. And I think it builds a collaborative approach to improving security, which is often described as a purple team.
Regardless of what you use, whether it's Penetration Testing, Bug Bounties, Red Team/ Blue Team exercises, or something else, the thing we need to remember is this is a learning exercise.
It is not a pass or fail.
We're not here to embarrass a team.
We're not here to demotivate the people that operate the security.
We're here to learn.
Off the back of any of these processes we do, we need to assume that there will be follow up activities and remediation steps. We need to take those, learn from them and expect them to educate our next steps along our security journey. This should not be expected to be a one and done exercise. This should be part of an ongoing continuous improvement exercise, both in terms of learning and in terms of making your system stronger and more capable of surviving attack.
Ok, so in this episode, I've introduced some ideas as to why you would pay to be hacked.
This may seem exceptionally counter-intuitive. You're spending lots of money and time putting security around your systems. You're spending effort making sure that your systems and your data are secure. So why would you then pay people to try to break them?
And it comes back to that validated learning.
We can put all the defences in place we want, but until we've tested them, they're hypothetical. We believe they will work. We have every expectation they will work. But it's still a hypothesis.
Like many things I talk about, until you've tested it, it's a guess. It's an educated guess, possibly, but it's still a theory. Until he can prove that theory, it's still unproven.
And this is why using these sort of approaches help us to learn, because they help us to understand what we've got right. Help us to understand what we've got wrong. And as in anything to do with modern software, we have to think of that continual effort as to what to do next. Modern software and modern systems are continually evolving and growing. We have to be constantly thinking, as we build them out, what do we do next with our security as we add more functionality, more capabilities, as we provide access for more customers and partners.
Remember, this is not a one and done exercise. Making sure that our security is correct and capable for what we need, we need to make sure we do not a regular and continual basis.
Thank you very much for taking the time to listen to this podcast. I look forward to speaking to you again next week.