"Money No Enough?" - Rethink Cybersecurity

Background

Recently, I shared at the Future of Singapore Government Summit 2024, moderated by Richard Pain , with Wan Roshaimi Wan Abdullah and Leonard Ong on the topic "Strategy Against Cyber Threats."

"Money No Enough?" This comedy not only reflects the problems that many people on the streets face but also the problems that organisations face. Limited resources present new opportunities for us to rethink cybersecurity and explore how we can potentially push the boundary and drive new norms and innovation to address cyber challenges!

Understanding Problems...

Albert Einstein said, "Given an hour to save the world, I would spend 55 minutes defining the problem and 5 minutes finding the solution.

Based on the current threat landscape, threats arising from cyber threat actors have become more expansive in scope and more intertwined between the cyber and physical worlds.?

For example, we do not only worry about APT and Ransomware attacks in the cyber world but also about Scams and Physical Safety in the physical realm. Scams aside, we witness cyber breaches transcend into compromising critical OT systems and personal devices. For example, explosives embedded within batteries that are compromised through supply chains could be remotely activated.

Studying these cyber incidents, I found that the most concerning vulnerabilities are?(V1) Insecure Architecture and Insecure Development, (V2) Supply-Chain vulnerabilities, and (V3) Insecure Deployments and Operations.

On V1, Insecure Architecture and Development are still present, which could often impact network and data security. V1 is a fundamental vulnerability we should be concerned with, even with newer technologies, such as various Cloud services, SaaS services, and AI technologies, that claim to be able to remove old vulnerabilities. "Insecure Architecture and Development" is likely a vulnerability that will never go away easily because newer technologies also come with new (yet to discover) challenges and vulnerabilities.

For example, while cloud-based architecture provides more convenience to cybersecurity, not all configurations are secured by default—exploitation of default configurations like allowing all outgoing traffic and default excessive permissions.?

How about SaaS? This black box is sometimes sold to customers who believe it is adequately secured with SOC2-Type2 certification. Is it truly the case? Does such certification truly mean that these SaaSes are reasonably secured? Who is the party that conducts the audits? Are these results reliable?

What about AI systems? AI systems do not exist alone. They are built on top of the standard application technology stack to provide additional AI-powered capabilities. Hence, we observe that the exploitation of vulnerabilities in AI systems, in most cases, is not because the AI model is insecure; rather, the application, the API interfaces, and the implementation around the AI models are insecurely designed and coded.?

For example, in addition to observing application-security-related vulnerabilities found in AI systems, we also observe vulnerabilities introduced due to data co-mingling. For example, while the access control for each document is managed correctly, after ingestion, such access controls are lost for their correspondingly generated data!

Insecure application is a complex problem that we need to continue to double down on, especially with an exponential increase in use cases around AI that increases the number of digital use cases.

On V2, Supply-Chain Vulnerabilities. These vulnerabilities deserve increased attention due to the increasing threat activity. Broadly, we can further classify them into three sub-categories: (A) Insecure Suppliers (e.g., Compromise of Microsoft Exchange Online mailboxes), (B) Implicated Suppliers (e.g., XZ Util), and (C) Careless Suppliers (e.g., CrowdStrike incident, etc.)

During the panel discussion, we briefly discussed the compromised explosive pager, and the moderator asked if this type of attack was continued or novel. In my mind, this type of attack is not something that people have not thought of. Instead, having someone execute this modulo operandi opened a new Pandora's Box, where, unfortunately, such possibilities have been demonstrated.

The other reason why we should pay more attention to supply-chain vulnerabilities is also because more and more companies are rebranding themselves as Software-as-a-Service (SaaS). This is a great movement, but it is also essential for business users to understand the risks they face. The current landscape of SaaS is essentially a black box. Once we are on it, in most cases, we just have to simply trust it, as there is very little means to validate its security. Well, for low-risk use cases, I guess it is still considered acceptable, and SaaS does have its place.

On V3, Insecure Deployments and Operations: This problem is not new. However, precisely because it is an old problem that doesn't disappear, we should rethink how to address it more strategically. How do we eliminate password sharing, insecure passwords, or even passwords themselves, etc.?

Recognising Limitations ...

Understanding vulnerabilities is inadequate to arrive at pragmatic solutions. We also need to assess our limitations. Off my head, many organisations may face similar constraints: (L1) Resources are limited, both money and headcounts; (L2) Inadequate Skilled Cyber Specialists; and (L3) Compliance but not security mindset of individuals.

So, What's the Strategy ...

The strategy, in my mind, is no secret sauce, and I hope to share and invite you for comments.

S1: Harness Community and Technologies (Overcome Resource Constraints)

We should continue to hardness on the "Crowdsourced Vulnerability Discovery Programme" to maximise the discovery of vulnerabilities through crowdsourcing.

Through our lessons learned, I think there is still room for improvement. Firstly, we should work closer with the Agencies' top management teams, to embrace and encourage their teams to be welcoming and proactive to the vulnerabilities reported.

While we have sticks, we also have carrots. If staff are worried about being seen as negligent, it may discourage welcoming reporting of vulnerabilities or even incidents. Therefore, assurance and encouragement from the management team may have to come along their way to encourage a mindset shift in owning cybersecurity responsibility.

S2: Cyberise ICT Professionals (Drive Mindset Shift)

To help all ICT professionals be confident in their cybersecurity responsibility, we must first "cyberise" them and include them as part of the cybersecurity community. This is akin to equipping all ICT professionals, including product owners, developers, operators, etc., with additional cybersecurity skills and cyber tools before allowing them to start their work.

For example, the XZ util malicious code was uncovered by Andres Freund, a Postgres developer in Microsoft, not their Security Operations Center! This is not because their security operations centres are not up to standard but because such vulnerabilities are hard to detect solely through log analysis. Through scrutiny and ownership to find out more about the suspicious activities, this mindset has enabled them with some "luck" to discover such insidious malware.?

Learning from this incident, I think we need everyone to be part of the cyber community to increase our "luck" in finding more such malicious packages. I am sure there are more to be found ...

Furthermore, with some cybersecurity skills, ICT professionals, especially product owners, can conduct cybersecurity risk assessments for more straightforward and lower-risk systems without being blocked by their security architects. For engineer and operation teams, they will also be more security conscious as part of they deployment and operations.

You may ask, "If ICT professionals undertook these cybersecurity tasks, would security professionals be out of jobs?"

Unlikely. The scarce group of security professionals needs to play more challenging and higher-value roles that focus on delivering cybersecurity expertise, such as cybersecurity trainers to cyberise others, security architects for more complex or higher-risk systems, or highly-skilled red-team operators to conduct continuous red-teaming.

Providing ICT professionals with training is inadequate. We need to continue harnessing technologies to make cybersecurity simpler for most people by delivering our cyber tradecrafts through technology. This way, we can multiply ourselves with fewer human resources.

When we have both training and tools, the remaining formula is to drive change management so that ICT professionals shift their mental model from delivering systems to delivering secured and resilient systems.

S3: Sharpen Detection (Overcome Protection Gaps)

Even when all systems are securely architected and developed, they are incomplete. We just have to acknowledge that undiscovered vulnerabilities could still be exploited. Therefore, we need a strong detection capability to be ready for threats already present in the environment.

One of my past experiences as part of the global security content team exposed me to the fact that detection is both a risk and a gain for anti-malware companies. Most companies hover at around 90% detection to balance against false positives. When false positives arise, they may result in another Crowd Strike incident if a critical operating system file is removed. Hence, relying on security products for detection is not enough, as not all observed malware can be detected, especially when the rules can also be flagged against legitimate files after tuning.

Hence, we need a red team that can conduct red-teaming exercises beyond the time-bounded manner. We need continuous red-teaming so that we can a) continuously hone the skills of both the red team and the blue team with new TTPs, b) motivate our detection teams to look out for threats continuously, and c) identify gaps not only with targeted systems and networks but also with all agencies, anytime, (almost) anywhere.

With such an eco-system, we can also have better means to measure metrics like Mean-Time To Detect/Response (MTTD/MTTR). This programme requires careful planning and phasing, depending on the maturity of Agencies, SOC, and Red Team.

In summary, after broadly reviewing the threats, vulnerabilities, and limitations, I would strongly suggest that organisations adopt the following strategies:

S1: Harness Community and Technologies (Overcome Resource Constraints)

S2: Cyberise ICT Professionals (Drive Mindset Shift)

S3: Sharpen Detection (Overcome Protection Gaps)

Thanks to GovTech and FST Media for giving me this opportunity to share my thoughts. I welcome feedback to learn from you and sharpen my thoughts.