John Strand is the owner of Black Hills Information Security. The one thing they have in common with Samurai is making the world a safer place for people. In this interview, David and Brad from Samurai talk with John about his experience over the last two decades. They share stories and anecdotes about dealing with organisations across all verticals.
Recently there have been a few large hacks in the news, and quite a few are down to remote access points due to remote entry.
What is the reason for the hacks?
JS- Due to COVID-19, many people started working from home and left the network coverage that was protecting them. In reality, many compromises boil down to the usual suspects, such as spearfishing. It is surprising how underprepared organisations are for that type of attack.
What are the things we can do to prepare ourselves?
DD- As a starting point, you should make sure that you know what your risks are. Do a risk assessment to identify who the threat actors are, how they may attack, and what motivates them. Review the critical aspects of your business operation, then prioritise the high-impact assets.
JS- We need to understand what makes an organisation unique and what differentiates them from the crowd. It does not really matter what they do, but it is more important that we unpack the reason for their existence. It is shocking how many executives cannot answer that simple question, especially when it relates to intellectual property attacks.
JS- When you strip down the risk to its core, it boils to threats and vulnerabilities. To address threats and vulnerabilities, organisations usually assess their threat intel feeds and defends against them. Unfortunately, they are blinded by one aspect of the danger, and they assume that the threat will be repeated. But the reality is that offensive operations are fraught with failure, trial, and error, and they will adapt. An attacker will never follow just one type of methodology. The threat actors will use any technique at their disposal. It is imperative to ascertain what your organisation is really about and what the threat actors are doing. As security teams, we do not have enough information to answer those questions, making our jobs hard.
What is the best approach to start protecting the organisation?
JS- We need to get organisations to do more vulnerability assessments in a larger context. When vulnerability management companies ask their customers what they want, the response is prioritisation. And 9 times out of 10, the vulnerability management company gets it wrong. They review missing CVE’s, server misconfiguration, or missing patches that require installation. Traditional vulnerability assessment tools largely overlook significant sections of the mitre attack technique matrix. We need to take the adversarial simulation and mainline it into vulnerability management. There should be vulnerability scores for overprivileged workstations where the primary user group is in the local administrator group.
JS- When organisations think of vulnerabilities, it is a tiny percentage of the overall vulnerabilities that exist in the organisation. As an industry, we need to ensure that threat emulation is rolled into vulnerability management across the board. In this way, you can look at vulnerabilities more holistically. You can tie them into the detective controls in place.
DD- There seems to be confusion in terms of vulnerability assessment and red team penetration testing activities. When you ask the layperson what the difference is, they do not really know. When you do a penetration test, the minority of your time is spent on identifying the low-hanging fruit. What a vulnerability assessment is good at is finding missing patches. It does not gear itself towards intelligence and creative thought activities. And even with the panacea of AI and machine learning, we may never get there. Simply setting up a scanner to check your systems is not enough. You require threat emulation to emulate what an attacker will do.
JS- We are fighting against the inclination of organisations to do the bare minimum. Executives want to follow a checklist manifesto – they want to get secure, and they do not want to think about it again. Security is not an Easter egg hunt. You cannot identify security risks once-off and leave them be it is a continuous evaluation and re-evaluation.
DD- The mindset is: we’ve had our pen test; we are good now! Often an entire year passes before you hear from clients again. And when you do, you find that they did not implement all the recommendations. Infrastructure and the threat landscape changes within an organisation, so it is impossible to remain on top of things with an annual pen test.
The trouble with cloud centricity
JS- When moving to a cloud-centric, zero-trust model, you should not rush or try and oversimplify things. It should occur naturally for the progression to make sense. Enterprises cannot be picked up and dropped into the cloud seamlessly, in a secure fashion. In the USA, they push all government agencies to move to the cloud as fast as possible, which is a concern. It introduces complexities and errors as you are trying to rush things. Complexity is the enemy of computer security. Attempting to rapidly transition an active directory traditional DMZ firewall environment into the cloud over 12 to 24 months is a recipe for disaster.
DD- We are still in the infancy stage of securing infrastructure. You can make the boxes and software secure. Still, when you put it into an infrastructure you do not fully understand, you introduce vulnerabilities by moving into the cloud.
What is the situation in the US regarding the rollout of software applications?
JS- Cloud security is driven by the phenomenon that being first to market is everything. New generation developers tend to develop a whole new coding language every 5 or 6 years. The language is new, new to developing and subsequently, the coding is not very good. This has been a consistent problem over the last 20 years. The biggest issue here is the rollout of sub-standard software which eventually becomes a legacy software problem.
JS- Every vertical considers itself unique, and they all believe that they need to develop software rules that allow for exceptions. The problem is that the same theme is repeated, and exceptions are made for legacy hardware and software all the time. Unfortunately, the exception cannot become the permanent fix. You have to replace legacy systems at some point. Sub-standard software is something that stays with us forever with no plan to retire the software or hardware. Regrettably, this is not the exception to the rule.
JS- You regularly find old proprietary systems that people are terrified of touching. And to make things worse, the developer retired 10 years ago and would not have a clue about it now anyway! The common argument is “when we stop this software, lives will be lost”. The fundamental issue boils down to this: every single market vertical believes that they are dealing with a unique problem. They can create magical exceptions where they don’t have to worry about securing things. We understand that there is an impact on lives in some cases. Still, we need to force organisations to develop a retirement plan for the legacy systems. The system will eventually retire on its own – everything degrades, and everything dies.
How do you encourage people to retire legacy systems? Stick? Carrot? Law?
JS- GDPR is an accountability framework that will result in a fine when organisations are not compliant. Whenever you create a compliance standard, it will guide people on how to remain secure. Unfortunately, standards do not age well, and organisations use them as a guide to meet the minimum. An accountability framework is much better. Significant fines are defined, and organisations will not be able to write it off willy-nilly.
Has GDPR, as an accountability framework, been effective?
DD- It has definitely made a difference! There is a massive discrepancy between cybersecurity and GDPR. The NIS framework we are trying to get going in the UK is a bit like GDPR. It is regulated, and you can get fined when you don’t adhere. However, it does not apply to all companies. It applies to telcos and critical infrastructure. However, I do think if frameworks are done well by the right people, they mean something.
DD- When you look at ISO 27001, the original publication was in 1995, it was revised in 2005, and then again in 2013. It is okay to follow a framework when the person pushing the frameworks forward brings it up to date. The interpretation of the frameworks also varies tremendously.
JS- It is interesting how politicised these frameworks are, especially when it comes to compliance and interpretation. Suppose an insurance company’s investigation reveals an absence of vulnerability management or user awareness training. In that case, there will be no insurance payout when hit with ransomware. Ransomware is the reason why organisations should increase their security more than any audit or compliance framework suggests. Organisations weigh up the cost of protection against insurance costs in the past. Because insurance is cheaper, they go that route. Insurance companies are starting to challenge their safety blanket role. They will start pushing back at companies not implementing basic security measures.
DD- At Samurai, we have seen insurance companies do a payout, but there is never a guarantee. We have submitted incidence reports to breached companies in the past. The incidence report is viewed as too damning. Consequently, another incidence report is done on evaluating ours to reduce the loss companies have to pay.
Have organisations requested you to amend a report after an audit?
JS- I have actually solved this problem! Whenever a company hires us, and we produce a report, we don’t go back on what we submit. We are not setting risk scores, but we are providing recommendations for that risk. Organisations need to understand that our role is to provide an opinion and not pass judgment. They can take the risk score and modify it for their action plan or milestones. But at the end of the day, if they change any scores, the liability is on them.
JS- When it comes to a letter of attestation, it is a different story. We have to reveal the accurate risk score in this letter. The client may share the information with customers and auditors. The content will not be changed, and we make sure that it is understood upfront. When you get down to it, it comes back to ego. And if a customer insists on changing the report, we basically fire that customer and refuse to work with them in future.
DD- People tend to overestimate their abilities when they are not an expert. They regard their view to be superior to the expert they have paid to come in.
JS- There is no way for us as security experts to win that argument. Especially when you know that they have made up their minds. It is pointless to expend the mental effort to fight that. Inevitably, rotten apples are constantly exposed. Inabilities always have a way to come to light.
Please note: This article has been transcribed and summarised from our podcast of the same title.