Posted on 2020-09-21 by Matt Strahan in Business Security
We have now released new vulnerability disclosure terms for Volkis. You can look at them here. They were based off the excellent disclose.io templates pushed by Bugcrowd among others. I’d like to take a bit of time to talk about why vulnerability disclosure terms are important and why each and every company, no matter how large or small, should have them.
Posted on 2020-07-22 by Matt Strahan in Business Security , Social Engineering
Last week Twitter had a successful social engineering attack that pushed through a Bitcoin scam. The scam netted about $120k for the scammers, but for Twitter it caused huge damage to their brand with the news of this attack going around the world.
Although we don’t have any hidden information about the Twitter hack that’s not already public, I thought it would be fun to look at the kinds of security controls that would help stop this kind of attack.
Yesterday we looked at all the multi-X controls. Today we’ll be looking at other strategies that can help mitigate the compromise.
Posted on 2020-07-21 by Matt Strahan in Business Security , Social Engineering
Last week Twitter had a successful social engineering attack that pushed through a Bitcoin scam. The scam netted about $120k for the scammers, but for Twitter it caused huge damage to their brand with the news of this attack going around the world.
Even with the greatest of anti-phishing and anti-malware security stack, social engineering attacks are extremely difficult to stop. In our social engineering exercises we may call a 5% response rate to a social engineering attack a good result, but for many organisations just having one response is a catastrophic scenario.
Many guides when they talk about social engineering talk about user training and “users being the weakest link”. While security awareness is important, the social engineers are smart. It’s almost impossible to tell the difference between what is real and what isn’t. Why are we blaming users when they’re being put in an impossible situation?
Posted on 2020-07-16 by Matt Strahan in Business Security
The results of the security review come in and they’re…let’s just say “less than ideal”. Vulnerabilities that could be used to break in, steal data, and potentially get the organisation in the news. Better fix those right away!
So we assign the tasks in our ITSM system and get to work. We patch what needs patching, reconfigure what needs reconfiguring, disable what shouldn’t be there and then pat our back and call it a day. We’re now secure…right?
This is what a lot of organisations do, but you’ve only got half the story. Those vulnerabilities didn’t come from nowhere, they were the symptom of an underlying problem and if you don’t fix the problem then the same thing will happen over and over again.
In a previous blog post I spoke about the “5 whys” and pinning down root causes that pop up as vulnerabilities. One of those root causes that is bound to prop up again and again is training.
Developers are often not trained in secure coding. Administrators are often not trained in secure administration. And yet the security vulnerabilities that could be placed in the environment from those teams could cause huge consequences to the organisation.
What can you do with a penetration test to help training?
Posted on 2020-06-25 by Matt Strahan in Business Security
What is in scope for a penetration test will be tested and what isn’t in scope for a penetration test won’t be tested. Simple enough, right? The problem comes when the hackers don’t follow the same scope that the penetration testers follow.
The choices that are usually made when scoping a penetration test are often made around simple practicalities and the various requirements that pop up for the organisation. Security considerations are important, but can be a secondary factor to it all.
For smaller organisations it’s not uncommon to have a full annual test with the entire internal and external environment in scope. After all, it’s easier to do it in one lot and just get it over with.
For larger organisations a full annual test would be too much since there are too many moving parts. It’s more common to have the scope restricted to a single project, maybe the new web application, new SOE, or the new network environment.
For this project by project testing the idea is that you can potentially get comprehensive coverage over the entire environment by testing each project in isolation. Hopefully a group of secure systems ends up being a secure environment. In the end, though, hackers will end up not targeting the systems directly, but they’ll start manipulating how they integrate and interact together.
Posted on 2020-06-09 by Matt Strahan in Business Security
When investigating software to use, I’ll inevitably have a look at their security record. What vulnerabilities have they had? Should I be worried?
Sometimes you see something really really dumb. Like an SQL injection in 2020. Or backdoor credentials… Wait I mean an “undocumented user account“.
Sometimes the security record makes news, like for Zoom at the moment. They’re suddenly one of the biggest pieces of software on the internet, and that means they’re being picked apart. There’s worries about privacy issues and their end-to-end encryption. Zoom has become a household name, and more than a few people have said to me “aren’t you worried about their security issues?”
Posted on 2020-05-21 by Matt Strahan in Business Security
What is in scope for a penetration test will be tested and what isn’t in scope for a penetration test won’t be tested. Simple enough, right? The problem comes when the hackers don’t follow the same scope that the penetration testers follow.
The choices that are usually made when scoping a penetration test are often made around simple practicalities and the various requirements that pop up for the organisation. Security considerations are important, but can be a secondary factor to it all.
Posted on 2020-05-13 by Matt Strahan in Business Security
How many organisations have access to your customer data?
As software-as-a-service and cloud-based environments become more standard within organisations, this question becomes harder to answer. In the modern interconnected security world, though, it’s a question that needs to be answered for all organisations.
Posted on 2020-04-29 by Matt Strahan in Business Security
There I was again, staring at the report. In each security issue in our penetration testing and compliance work we have our risk assessment rating which is a pretty simple process based on ISO 31000. You identify the risk, figure out the likelihood and impact, and then use the risk matrix to give it a risk rating. Although a fair few companies now have their own risk matrix which we are happy to use in our reports for them, our standard risk matrix looks like this:
It should be a simple enough process, yet still I am left staring at the report thinking “how likely is it that this company will get hacked using this vulnerability?”
Posted on 2020-04-22 by Matt Strahan in Business Security
I often hear a common phrase from people both in the security industry and those who are now faced with dealing with cyber security in their business: “We need to strike a balance between security and convenience!”
It’s a phrase that makes it feel like we’ve got a line with convenience at one end and security at the other. We have a slider on that line, and security as an exercise is really about picking the exact right point for that slider to land on. “This is a critical environment, so let’s take 20% convenience and 80% security.”
Maybe security within organisations is actually a battle between two parties: “Security” against “Convenience”. Maybe one of the solutions could be that organisations have a “Convenience” department like the security departments they currently have. Should we have a “Chief Convenience Officer” that sits alongside the CISO when reporting to the board?
Is that really how it is? A never-ending battle between security and convenience? Is there really such a trade-off between security and convenience?