UK cybersecurity authorities and researchers tamp down fears that ChatGPT will overwhelm current defenses, while the CEO of OpenAI worries about its use in cyberattacks.

The dizzying capacity for OpenAI to vacuum up vast amounts of data and spit out custom-tailored content has ushered in all sorts of worrying predictions about the technology's ability to overwhelm everything — including cybersecurity defenses.

Indeed, ChatGPT's latest iteration, GPT-4, is smart enough to pass the bar exam, generate thousands of words of text, and write malicious code. And thanks to its stripped-down interface anyone can use, concerns that the OpenAI tools could turn any would-be petty thief into a technically savvy malicious coder in moments were, and still are, well-founded. ChatGPT-enabled cyberattacks started popping up just after its user-friendly interface premiered in November 2022.

OpenAI co-founder Greg Brockman told a crowd gathered at SXSW this month that he is concerned about the technology's potential to do two specific things really well: spread disinformation and launch cyberattacks.

"Now that they're getting better at writing computer code, \[OpenAI\] could be used for offensive cyberattacks," Brockman said.

No word on what OpenAI intends to do to mitigate the chatbot's cybersecurity threat, however. For the time being, it appears to be up to the cybersecurity community to mount a defense.

There are current safeguards put in place to keep users for using ChatGPT for unintended purposes, or for content deemed too violent or illegal, but users are quickly finding jailbreak workarounds for those content limitations.

Those threats warrant concern, but a growing chorus of experts, including a recent post by the UK's National Cyber Security Centre, are tempering concerns over the true dangers to enterprises with the rise of ChatGPT and large language models (LLMs).

**ChatGPT's Current Cyber Threat**

Work products of chatbots can save time taking care of less complex tasks, but when it comes to performing expert work like writing malicious code, OpenAI's ability to do that from scratch isn't really ready for prime time yet, the NCSC's blog post explained.

"For more complex tasks, it's currently easier for an expert to create the malware from scratch, rather than having to spend time correcting what the LLM has produced," the ChatGPT cyber-threat post said. "However, an expert capable of creating highly capable malware is likely to be able to coax an LLM into writing capable malware."

The problem with ChatGPT as a cyberattack tool on its own is that it lacks the ability to test whether the code it's creating actually works or not, says Nathan Hamiel, senior director of research with Kudelski Security.

"I agree with the NCSC's assessment," Hamiel says. "ChatGPT responds to every request with a high degree of confidence whether it's right or wrong, whether it's outputting functional or nonfunctional code."

More realistically, he says, cyberattackers could use ChatGPT the same way they do other tools, like pen testing.

**ChatGPT Threat "Massively Overhyped"**

The harm to IT teams is that overblown cybersecurity risks being ascribed to ChatGPT and OpenAI are sucking already scarce resources away from more immediate threats, as Jeffrey Wells, partner at Sigma7, points out.

"The threats from ChatGPT are massively overhyped," Wells says. "The technology is still in its infancy, and there is little to no reason why a threat actor would want to use ChatGPT to create malicious code when there is an abundance of existing malware or crime-as-a-service (CaaS) that can be used to exploit the list of known and growing vulnerabilities."

Rather than worrying about ChatGPT, enterprise IT teams should focus their attention on cybersecurity fundamentals, risk management, and resource allocation strategies, Wells adds.

The value of ChatGPT, as well as an array of other tools available to threat actors, come down to their ability to exploit human error, says Bugcrowd founder and CTO Casey Ellis. The remedy is human problem-solving, he notes.

"The entire reason our industry exists is because of human creativity, human failures, and human needs," Ellis says. "Whenever automation 'solves' a swath of the cyber-defense problem, the attackers simply innovate past these defenses with newer techniques to serve their goals."

But Patrick Harr, CEO of SlashNext, warns organizations not to underestimate the longer-term threat ChatGPT could pose. Security teams, meanwhile, should look to leverage similar LLMs in their defenses, he says.

"Suggesting that ChatGPT is low risk is like putting your head in the sand and carrying on like it doesn’t exist," Harr says. "ChatGTP is only the start of the generative AI revolution, and the industry needs to take it seriously and focus on developing AI technology to combat AI-borne threats."

ChatGPT Gut Check: Cybersecurity Threats Overhyped or Not?

With HinataBot, malware authors have created a beast many times more efficient than even the scariest botnets of old, packing more than 3Tbit/s DDoS speeds.

Former Mirai hackers have developed a new botnet, dubbed HinataBot, with the potential to cause far greater damage with far fewer resources required from its operators than its predecessor.

Mirai is one of the world's most notorious botnets. In circulation since the mid-2010s, it uses Internet of Things (IoT) devices like routers and cameras to hit targets with massive amounts of traffic to force distributed denial of service (DDoS). Some of its most notorious attacks were against French technology company OVH, the government of Liberia, and DNS provider Dyn, an attack that touched websites such as Twitter, Reddit, GitHub, CNN, and many more.

Now, in a report published March 16, researchers from Akamai noted that HinataBot has only been in development since mid-January. Despite that, according to initial tests, it packs in orders of magnitude more powerful than its predecessor, reaching more than 3 Tbit/s traffic flows.

**Just How Powerful Is HinataBot?**

In its heyday, the Mirai botnet managed to flood its victims with hundreds of gigabytes per second in traffic — up to 623 Gbit/s for the KrebsOnSecurity website, and nearly 1 Tbit/s against OVH. As OVH noted at the time, that huge wave of data was enabled by a network of around 145,000 connected computers, all sending requests to their systems simultaneously.

To gauge the relative strength of HinataBot the Akamai researchers ran 10-second test attacks. "If the botnet contained just 1,000 nodes," they found, "the resulting UDP flood would weigh in at around 336 Gbps per second." In other words, with less than 1% of the resources, HinataBot was already capable of producing traffic approaching Mirai's most vicious attacks.

When they considered what HinataBot could do with 10,000 nodes — roughly 6.9% of the size of peak Mirai — the resulting traffic topped out at more than 3.3 Tbit/s, many times stronger than any Mirai attack.

"These theorized capabilities obviously don't take into account the different kinds of servers that would be participating, their respective bandwidth and hardware capabilities, etc.," Akamai researchers warned in the report, "but you get the picture. Let's hope that the HinataBot authors move onto new hobbies before we have to deal with their botnet at any real scale."

**Why Hackers Are Choosing Golang**

Much of the reason for HinataBot's improvements comes down to how it was written.

"Most malware has traditionally been written in C++ and C," explains Allen West, one of the principal researchers of the report. Mirai, for example, was written in C.

In more recent years, though, hackers have become more creative. "They're trying to take any new approach they can, and these new languages — such as Go, with its efficiencies and the way it stores strings — makes it more difficult for people to deal with."

"Go" — short for "Golang" — is the high-level programming language underpinning HinataBot. It's similar to C, but, in some ways, it's more powerful. With Golang, explains Chad Seaman, another author of the report, hackers "get better error handling, they get memory management, they get easy threaded worker pools, and a little bit more of a stable platform that provides some of the speed and performance you would associate with a C-level language, and C or C++ binaries, with a lot of things that they don't have to manage."

"It just lowers the bar on technical difficulty," he says, "while also raising the performance bar over, say, some of the other traditional languages."

For all of these reasons, Go has become a popular choice for malware authors. Botnets like kmsdbot, GoTrim, and GoBruteForcer are cases in point. "Go is becoming more performant and more mainstream and more common," Seaman says, and the malware that results is all the more powerful for it.

**How Much Should Businesses Worry About HinataBot?**

As scary as HinataBot may be, there may be a bright side.

HinataBot isn't simply more efficient than Mirai — it _must be_ more efficient because it's working with less.

"The vulnerabilities through which it's spread are not new or novel," Seaman says. HinataBot leverages weaknesses and CVEs already known to the security community and utilized by other botnets. It's an environment quite different than that of which Mirai operated in circa 2016–'17, when IoT vulnerabilities were novel and security for the devices was not top of mind.

"I don't think we're going to see a case of another Mirai, unless they get creative in how they're distributing and their infection techniques,” Seaman says. "We're not going to see another 70,000 or 100,000-node, Mirai-like threat from the Hinata authors under their current tactics, techniques, and procedures."

A less optimistic observer might note that, being only a couple of months old now, there is plenty of time for HinataBot to improve upon its limited weaknesses. "It may just be an introductory phase, right?" Seaman points out. "They're grabbing at low hanging fruit so far, without needing to go out and do anything really novel yet."

Nobody can yet say how big this botnet will become, or in what ways it'll change over time. For now, we can only prepare for what we know — that this is a very powerful tool, operating over known channels and exploiting known vulnerabilities.

"There's nothing that they're doing within the traffic that's circumventing security controls we've already put in place," notes Larry Cashdollar, the third author of the report. "The exploits are old. There are no zero days. So, as it stands, the fundamental security principles for defending against this kind of threat" — strong password policies, dutiful patching, and so on — "are the same. They're still sufficient."

Mirai Hackers Use Golang to Create a Bigger, Badder DDoS Botnet

No-code has lowered the barrier for non-developers to create applications. AI will completely eliminate it.

Since ChatGPT captured our imaginations, people have been contemplating its pending impact on the business world. This week, these thoughts became a reality, with Google and Microsoft embedding AI features into their business productivity suites.

Microsoft took another major step by releasing AI Copilot for Power Apps, Microsoft's low-code platform. Power Apps can connect far and beyond the Microsoft ecosystem, with almost a thousand built-in connectors to everything from Salesforce to on-prem and AWS. With one swift move, AI has been integrated into the day-to-day workflows of the world's largest organizations.

This is an amazing achievement, and other low-code/no-code platforms will surely try to catch up quickly. But ask yourself: Who will make the decision to integrate data with AI? Who will grant access? The answer: Every business user, and you won't even know, since they'll let AI impersonate their accounts.

**AI + Low-Code/No-Code = A Perfect Storm**

In recent years, low-code/no-code has given business users newfound freedom. They were granted developer-level power that enabled them to customize their digital experience, with the technical skills they already have rather than having to learn new ones. Business users have started building applications that solve the problems that hurt most, on top of their day-to-day business data, without relying on IT or waiting for resources. After just a few years of low-code/no-code, many enterprises find themselves with tens or hundreds of thousands of applications, built outside of IT with no oversight or control.

Forget about CI/CD or security reviews, most of these applications follow the "push save to deploy to production" model instead. Quickly and quietly, applications developed outside of IT without SDLC have become a significant portion of enterprise business applications. This has already become a major concern for enterprise security.

Enter AI. Imagine that every conversation you had with ChatGPT involved you giving it access to business data, and left behind a nice little application you could play around with and share with others. Got a long business email? Let AI shorten it for you. Need to find relevant customers in your CRM? Let AI generate statistics for you. Need to analyze user behavior over product telemetry? Let AI query the database for you. Don't stop there! Create mini-applications to allow answering those questions repeatedly, and share them with your coworkers! Every application requires access — your access. Low-code has lowered the barrier for non-developers to create applications. AI, however, will completely eliminate it.

Low-code/no-code provides ease-of-connectivity to business data by removing the difficult hurdles around authentication, and provides a host of widgets business users can combine creatively to address their needs. AI brings power to everyone, allowing them to create by simply asking for what they want. The two techniques fit together like a glove and a hand. Superpowered by AI, low-code/no-code expands from "everyone can build an application" to "everyone builds an application, for everything they think of, all of the time."

**You Are Not in Control**

Who decides what data the AI can access? You might be thinking this would be IT, or the security team, but you would be wrong. Business users are making those decisions. But how?

Imagine a scenario where every business user in a large enterprise starts to build their own applications. Setting aside the skill gap, the No. 1 hurdle to progress would be identity and access. Provisioning an application identity and granting the right permissions to it would require approval, which would trigger questions and perhaps even a security review. You won't get to tens of thousands of applications in a large enterprise this way.

To circumvent this hurdle, low-code/no-code platforms made a significant compromise: Applications can — and mostly do — impersonate users rather than have their own identities. This completely negates the permission issue. As a low-code/no-code developer, I can embed my own identity within my newly created application. I can even share my credentials with others, so they'll be able to build their own applications with my access to data or performing operations on my behalf. No more waiting for approval — we have a green light to create!

The problem with this credentials-sharing-as-a-service is that it completely negates the enterprise permission model. If users are sharing their credentials with each other, there's no easy way to distinguish them. Moreover, an application can leverage credentials across your organizational boundary — say, an employee's personal email account — in combination with a business account. To add a cherry on top, moving data between one account and the other is done by automated copy-and-paste on the low-code/no-code platform's cloud. No data gets transmitted, so there is no opportunity to block data leaking out.

Credential sharing and data leakage have been a major issue with low-code/no-code applications. AI doesn't change that, but it magnifies the scale of the problem. When AI is plugged into a low-code/no-code platform, the AI gains potential access to everything the platform can access. The transition between potential and in-practice access is up to whoever prompts the AI to build a low-code/no-code application for them. We are trusting our business users with making the right choice without any guardrails or guidance.

**Business Users Build Enterprise Applications**

More than a specific technology, low-code/no-code is an idea — a strong push into IT decentralization and business empowerment. It has already brought tremendous productivity benefits to the world's largest organizations, because the employees who know best how to impact the business are the business users.

For professionals in IT and security, this is a paradigm shift. No longer can we rely on the security savviness of developers or official security mandates. We must embrace business users and help guide them in the right direction. If we fail to do so, the forces of productivity and data-hungry AI will surely be glad to do that for us.

AI Has Your Business Data

Users of affected devices that want to mitigate risk from the security issues in the Exynos chipsets can turn off Wi-Fi and Voice-over-LTE settings, researchers from Google's Project Zero say.

A newly disclosed set of vulnerabilities in Samsung chipsets has exposed millions of Android mobile phone users to potential remote code execution (RCE) attacks, until their individual device vendors make patches available for the flaws.

Until then, the best bet for users who want to protect against the threat is to turn off Wi-Fi calling and Voice-over-LTE settings on their devices, according to the researchers from Google's Project Zero who discovered the flaws.

In a blog post last week, the researchers said they had reported as many as 18 vulnerabilities to Samsung in the company's Exynos chipsets, used in multiple mobile phone models from Samsung, Vivo, and Google. Affected devices include Samsung Galaxy S22, M33, M13, M12, A71, and A53, Vivo S16, S15, S6, X70, X60, and X30, and Google's Pixel 6 and Pixel 7 series of devices.

**Android Users Face Complete Compromise**

Four of the vulnerabilities in the Samsung Exynos chipsets give attackers a way to completely compromise an affected device, with no user interaction needed and requiring the attacker to only know the victim's phone number, Project Zero threat researcher Tim Willis wrote.

"Tests conducted by Project Zero confirm that those four vulnerabilities \[CVE-2023-24033, CVE-2023-26496, CVE-2023-26497, and CVE-2023-26498\] allow an attacker to remotely compromise a phone at the baseband level," Willis said. "With limited additional research and development, we believe that skilled attackers would be able to quickly create an operational exploit to compromise affected devices silently and remotely." 

The security researcher identified the remaining 14 vulnerabilities in Samsung Exynos chipsets as being somewhat less severe.

In an emailed statement, Samsung said it had identified six of the vulnerabilities as potentially impacting some of its Galaxy devices. The company described the six flaws as not being "severe" and said it had released patches for five of them in a March security update. Samsung will release a patch for the sixth flaw in April. The company did not respond to a Dark Reading request seeking information on whether it will release patches for all 18 vulnerabilities that Google disclosed. It's also unclear whether, or when, all affected Samsung Galaxy devices will receive the updates.

Willis said affected Google Pixel devices had already received a fix for one of the disclosed flaws (CVE-2023-24033) with the company's March 2023 security update. Google did not immediately respond to a Dark Reading request for information on when patches would be available for the remaining vulnerabilities. Vivo did not respond immediately to a Dark Reading request either, so the company's plans for addressing the vulnerabilities remain unclear as well.

**The Android Patch Gap Problem**

In the past, device vendors have taken their time addressing vulnerabilities in the Android ecosystem. So, if that's any indication, users affected by the vulnerabilities in the Samsung chipset could be in for a long wait. 

In November, Project Zero researchers reported on what they described a significant patch gap resulting from the delay between when a firmware patch for an Android device becomes available and when a device vendor actually makes it available for their users. As an example, Project Zero researchers pointed to several vulnerabilities they discovered in the ARM Mali GPU driver. Google reported the vulnerabilities to ARM last June and July, after which the latter issued patches for the flaws in July and August. Yet more than three months later, in November, when Google tested affected devices for the vulnerability, the researchers found every single device still vulnerable to the issues.

"The easy part is fixing the hardware flaws with new software," says Ted Miracco, CEO at Approov. "The harder part is getting manufacturers to push the updates to the end users and getting end users to update their devices," he says. Unfortunately, many users of the chipsets may not be quick to patch the devices and users are probably largely unaware if the vulnerabilities, he says.

Vulnerabilities like the ones Project Zero discovered in the Samsung chipsets exist not only in the Android ecosystem, but in the iOS ecosystem and any complex supply chain involving sophisticated hardware and software as well, Miracco continues. The challenge is reducing the time from detecting flaws to deploying solutions on all devices. 

"This is an area where the Android ecosystem needs to put a lot attention, as updates can be few and far between with many manufacturers of mobile devices," he says. Enterprises could mandate that users who bring their own devices (BYOD) to work must utilize devices from approved suppliers that have a track record of rapidly deploying updates, Miracco adds.

Krishna Vishnubhotla, vice president of product strategy at Zimperium, says vulnerabilities like these highlight the need for enterprises to evaluate their mobile security strategies. "It makes sense for enterprises to guide their employees on how to stay safe and if there are new requirements for enterprise access," he notes.

With so much original equipment manufacturer (OEM) fragmentation in the Android space, the patches might only be available after a few months for all the vulnerabilities discovered. "This is why it's important for enterprises to invest in security that can handle zero-day threats and can be updated over the air," Vishnubhotta adds.

Unpatched Samsung Chipset Vulnerabilities Open Android Users to RCE Attacks

The alleged mastermind of hacker forum Breach Forums, "pompompurin," has been arrested in New York City, according to court documents.

Following last year's takedown of Dark Web hacker destination Raid Forums, a new platform soon emerged in its place called Breach Forums.

Now US federal agents have a man called Conor Brian Fitzpatrick in custody, the person they allege is behind the moniker "pompompurin," and the chief operator of the BreachForums underground hacker site.

Fitzpatrick was arrested in Peekskill, New York on March 15, according to an affidavit.

"When I arrested the defendant ... he stated to me in substance and in part that: a) his name was Conor Brian Fitzpatrick, b) he used the alias 'pompompurin,' and c) he was the owner and administrator of BreachForums, the data breach website referenced in the complaint," FBI special agent John Longmire testified.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Cops Nab BreachForums Boss in New York

The basketball playoffs are around the corner and convincing social-engineering attacks on fans using NBA-themed lures could be too.

As it moves into the final stretch of its regular season, the National Basketball Association said over the weekend that "an unauthorized third party" netted a database filled with the names and email addresses of fans.

The data was housed by a newsletter service that it partners with, the NBA noted in a letter to those affected — an all-too-common instance of the risk that third-party vendors can represent for organizations if their security isn't properly vetted.

For the affected fans of the sport, they now have more to deal with than just handicapping the playoff picture. While account credentials, phone numbers, and other sensitive information were not included in the heist, they should still expect targeted email phishing attacks related to NBA topics, the NBA warned in the letter, which was tweeted out by one recipient. Those could include messages appearing to relate to office pools and other business-themed attacks.

"Even though the information did not contain much sensitive information, by using a name and email address, along with the knowledge that this individual has an interest in the NBA, social engineers could put together a much more appealing phishing attack than if they had none of this information," Erich Kron, security awareness advocate at KnowBe4, said in an emailed statement.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Cyberattackers Hoop NBA Fan Data via Third-Party Vendor

**Ingolstadt, Germany, March 20, 2023** – SAP security provider SecurityBridge — now operating in the U.S. — today announced the latest addition to the SecurityBridge Platform — the Management Dashboard for SAP security. The SAP Management Dashboard is a no-cost, additional application for the existing SecurityBridge Platform that combines all SAP data aspects and presents the information through a customizable, single pane of glass security dashboard view.

With the Dashboard, organizations can now benefit from analyzing live monitoring, static configuration validation, patching, interface traffic statistics, and code security information in one place. The dashboard provides real-time data, eliminating the need for outdated manual reporting. Additionally, the solution is fully customizable and can create multiple dashboards, allowing organizations to choose the views that best meet their needs. 

*   Customizable views also include:
*   The number of new code vulnerabilities.
*   The current security posture of production systems.
*   Progress reports on implementing SAP security notes.
*   All open SAP security incidents.

"Thanks to the new security dashboard for SAP, management-level personnel can easily access preferred live data, enabling stakeholders to make quick, informed cybersecurity decisions based on real-time SAP data with just a click," said Christoph Nagy, CEO of SecurityBridge.

SecurityBridge's Management Dashboard is anticipated to be released in early Q2, 2023. As with all SecurityBridge apps, the Management Dashboard will evolve based on customer feedback.

Please visit our website for more information on SecurityBridge's SAP Management Dashboard.

**About SecurityBridge**

SecurityBridge is an SAP Security Platform provider developing tools to extend the SAP ecosystem. The company takes a radically different approach to traditional security solutions, believing SAP applications and custom code will be infiltrated no matter how diligently security hygiene is applied. In response to this belief, SecurityBridge created its integrated real-time solution for constant monitoring. Powered by anomaly detection, the SecurityBridge platform can differentiate between accurate results and false positives so that security teams can better focus on real issues. For more information, please visit securitybridge.com.

SecurityBridge Introduces The SAP Management Dashboard

There are a number of solutions that can help ensure security and compliance mandates are met in the cloud, but organizations should prioritize integration and policy-based management.

As business and the world in general grow more complex, the shared responsibility between cloud customer and cloud provider becomes, well, cloudier. This is especially true when it comes to security and compliance.

Moving applications and infrastructure to the cloud frees up resources and increases flexibility and scalability, but does not free organizations from ensuring their regulatory and security responsibilities are being met. Cloud providers promise security of the cloud, but organizations are responsible for security _in_ the cloud. And compliance in the cloud — especially in a hybrid model — can be an overwhelming challenge, because you don't know what you don't know. And, of course, what you don't know is what will end up costing you — in time, money, and, sometimes, reputation.

It would be hard enough if nothing ever changed, but we live in a world of continuous churn. In early January, for example, the Biden administration released its fall 2022 regulatory agenda, including dozens of proposed, pending, and final rules governing everything from food additives to cybersecurity requirements for government contractors. And the cloud itself has paved the way for disruptive applications such as the AI-based ChatGPT— applications that have many potential benefits but also open up new channels warranting compliance and security concerns. The proposed American Data Privacy and Protection Act, which would provide national standards for personal information collected by companies, also could increase federal oversight of AI.

As scrutiny and regulations increase, penalties are becoming stronger. Organizations must ensure they are doing everything they can to protect their business applications and meet regulatory requirements while taking advantage of the cloud. Not only that, but organizations must be able to demonstrate they are doing so to whomever asks — auditors, customers, partners, and even the competition — whenever they ask. 

**Continuous Compliance Mindset**

Continuous change requires adopting a mindset of continuous compliance within a DevSecOps model. There's no one tool for doing this. In fact, there are many — perhaps too many right now. The market is likely to converge, as platform providers integrate security and compliance capabilities, but in the meantime, organizations should proactively be seeking opportunities to integrate technology that enables and helps maintain observability, governance, and security.

For example, cloud security posture management (CSPM) systems help organizations identify and remediate security risks due to misconfigurations of IaaS, SaaS, and PaaS platforms. CSPMs discover cloud resources and monitor them against established security best practices and regulatory standards. 

On a more comprehensive scale, CNAPPs (cloud-native application protection platforms) provide an integrated platform approach to cloud-native application security that combines CSPM capabilities with CWPP (cloud workload protection platform) features. The goal of CNAPPs is to apply security and compliance holistically across cloud infrastructure and cloud workloads to identify and remediate risk throughout the solution stack.

Notably, CNAPPs that integrate with Kubernetes strengthen an organization's ability to securely and compliantly build, deploy, run, and scale cloud-native applications across on-premises, hybrid, and cloud infrastructures. There are a number of Kubernetes projects designed to improve security, observability, and governance. Community investment in this space is growing as organizations increasingly deploy multiple Kube clusters and expand their use of the platform across organizational boundaries.

SPIFFE/SPIRE, for example, goes a long way toward solving the problem of end-to-end identity, while Sigstore eases cryotographic signing along the supply chain. Opportunities exist to combine many of these projects for even greater benefits. Tekton Chains uses Sigstore for signing and attestation of the artifacts produced by a Tekton pipeline. The Tekton project is also investing in using SPIFFE/SPIRE to provide identities for TaskRun pods and sign the task objects to guarantee that the tasks themselves were not tampered with.

**Automating Policy**

Organizations should also be thinking in terms of automated, policy-based governance, risk management, and compliance whenever and wherever possible. Just as bridges are being created between historically siloed security solutions, DevOps teams must build bridges between historically siloed organizations. DevOps teams must become DevSecOps teams by taking a proactive approach to managing security and compliance throughout the application and platform lifecycle, as well as the application supply chain.

Look for solutions that help provide automated guard rails for your developers in the tools they use every day so that applications can be hardened before they're deployed. Many developers don't have a strong compliance and security knowledge base, so the more guidance solutions can provide, the better. Similarly, look for solutions that help provide automated guard rails for teams managing infrastructure as code so infrastructure can be hardened at deployment time. Leverage solutions that simplify adoption of security practices with standard patterns for developers, infrastructure, and security teams based on industry expertise with out-of-the-box policies and built-in response capabilities. 

**Conclusion**

More and more organizations are managing solutions in multiple clouds, including on-premises and public cloud, to build business agility and scalability. Managing solutions across multiple clouds can create additional work and overhead for infrastructure, application, and security teams. Organizations investing in multicloud and hybrid cloud infrastructure will benefit from solutions that enable them to implement automated, policy-based governance, compliance, and security practices in a common way across cloud environments. Look for solutions that can be used throughout the lifecycle and the stack; solutions that create bridges by providing guidance to individual teams in the tools they use every day. This can create feedback loops and solutions that enable collaboration among stakeholders with a common language, while also enabling informed risk-management decisions and more effective prioritization workflows based on contextualized data.

Shouldering the Increasingly Heavy Cloud Shared-Responsibility Model

CISOs can and should push back when they're presented with budget costs that affect the business. Here's how.

Today's enterprise security executives face situations that could really hurt the company's bottom line. Security teams are trying to modernize security operations in an increasingly porous network environment with ever more sophisticated threats. There are also economic pressures from layoffs, budget cuts, and restructuring.

Even worse, CFOs have heard from CISOs the doom-and-gloom predictions of the potential fiscal disaster of data breaches so often that it's no longer resonating with them.

The doomer scenario is not hypothetical — global compliance requirements and privacy regulations drive the cost of a breach even higher than just the technical costs. However, CFOs and other C-level executives have heard these warnings so often now that it's just background information that doesn't drive their decision making.

Is there a more effective way to help the CFO understand why security needs to be far better funded? Yes: Present the CFO with a shared-risk scenario.

**Setting Protection Priorities**

Allan Alford, who was a CISO in various industries including technology, communications, and business services before morphing into a CISO consultant, says CISOs should use a different approach to describe cybersecurity issues to the CFO. They should begin by asking the CFO to identify the six most important strategic elements of the business — possibly including the supply chain, manufacturing operations, sensitive future product plans, etc. — then detail their plans for protecting each of those critical areas, Alford says.

The CISO can present the situation to the CFO in the following manner: "Thanks for sharing those priorities. Now, you are saying we need to cut the security budget by 37%. Given the state of the economy in our sectors, that is completely understandable. To make the cuts possible, can you tell me which of these six areas I should stop protecting? We will also need to bring in the line-of-business executive so that you can explain how these changes will impact that area."

Historically, CISOs, CSOs, CROs, and other security-adjacent executives have been good soldiers, accepting the CFO-ordered cuts and deciding where changes have to be made, Alford says. This conflicts with the CISO's job: to protect the company — including all intellectual property and all assets.

If the CFO decides to cut back security funding, they need to work with the COO, the CEO, the board, and other senior executives to decide which operations they can afford to not protect. It should not be left to the CISO to make those calls or defend the choices.

In fairness, the decision is rarely black-and-white. But if the CISO positions the budget decisions in this manner, the CFO will see the actual business impact the reductions would have. When the CFO is forced to decide where the cuts will happen and to choose which top-priority division is left undefended, the conversation shifts, Alford says. The CISO can say to the CFO, "We'll jointly figure out what risks are tolerable, but make no mistake: A 37% cut will put various units at extreme risk. Can the business afford that deep a cut in our defenses?"

The CISO can present cost-effective alternatives to reduce security defenses, rather than eliminating them entirely. Now there is the possibility of negotiating a smaller budget cut. Maybe that 37% cut becomes a 23% cut.

**Negotiating as a Group**

The conversation shouldn't begin and end with the CFO, says Daniel Wallance, an associate partner with McKinsey. It should involve the board's risk committee, the CEO, the COO, and other colleagues who have a role in security spending, such as the CIO and the CRO.

"There is also spend coming from risk management \[and\] compliance on top of IT. I would engage those functions, as they have shared \[security\] responsibility and they may actually have dedicated resources," Wallance says. "I need this to _not_ be a one-on-one conversation. I want to make it a group."

These conversations with other security executives should happen before _and_ after the CFO meeting, but not during.

The CISO needs to meet with the other security players before meeting with the CFO to learn what overlaps and redundancies currently exist. The CISO also needs to know how much budget flexibility those other executives are willing to offer. That will be crucial information to have while working with the CFO. After meeting with the CFO, the CISO can go back to the other executives and see what they can negotiate as a group.

The actual CISO-CFO meeting should be just the two executives, to avoid making the CFO feel ganged up on. The discussion should be as friendly as possible to allow for reasonable compromises.

Involving the board's risk committee is critical, as it is ultimately the board's role — working with the CEO — to dictate the company's risk tolerance. If the CFO's requested budget reductions conflict with that risk tolerance, the board needs to know about it.

"The CISO should be meeting with the risk committee regularly," Wallance says. "The business may not understand the implications of the budget cut. The CFO is not the only person at issue here."

**Adapting to Market Conditions**

Larger trends in the economy also affect CISO budgetary needs.

There is a realistic existential threat to cyber insurance, the net that CFOs have relied on for more than 20 years. Lloyds of London said that it would stop covering the losses from state actor attacks, which is problematic given how difficult it is to prove an attack's origin and who funded it. Insurance giant Zurich warned it might abandon cyber insurance entirely. And an Ohio Supreme Court decision raised the prospect of other cyber insurance limitations. Those changes could sharply increase the pressure on the CFO to better fund security, given that the enterprise will now be on the hook for the full amount of damages.

A complicating factor is the much-ballyhooed cybersecurity talent shortage. Whether the gap is as big as some say, it's true that the cost of talent today is higher than what most budgets allow. So, yes, you will have difficulty finding qualified people, but increase the salary enough and, poof — no more talent shortage.

Richard Haag, the VP for compliance services at consulting firm Intersec Worldwide Inc., maintained that the difficulty in acquiring sufficiently experienced talent is a powerful argument in those CFO discussions.

"\[I\]n security, labor is about the only thing that can possibly be cut. You can't just swap out firewalls. These agreements are locked in," Haag says. "You need to say 'I can barely protect your top strategic areas now. With the cuts you want, I simply won't be able to defend your top targets and certainly not your not-so-top targets. I need more people, certainly not fewer people.'"

Alford also suggests the CISO point out how they negotiate lower vendor costs. Document it and share it with the CFO to demonstrate that the budget is being spent wisely.

"Demonstrate your efficiencies by driving vendor discounts as low as you can get them to go. CFOs want to know the money is being well spent, and 'we got a heck of a deal' does that well," Alford says.

Finally, the CISO can also make the case for better security delivering more revenue. Does higher security investment make prospective customers more comfortable? Is lack of security making some existing customers leave? For example, if a financial institution chooses to reimburse customers in all fraud situations — rather than what most FIs do, which is to only reimburse in some situations — it could boast that its customers are better protected against fraud, prompting customers to leave competitors. That move would justify higher cybersecurity spend because of the greater acceptance of fraud costs.

"If you can shorten that sales cycle and prove that security gained more sales, it can be highly persuasive to CFOs: 'Today, three customers walked away, but tomorrow none will,'" Alford says.

How CISOs Can Work With the CFO to Get the Best Security Budget

DDoS cyberattack campaigns from the pro-Russian group have spiked significantly.

The pro-Russian hacktivist group KillNet, which launches its campaigns against countries supporting Ukraine, is ramping up its daily distributed denial-of-service (DDoS) attacks against healthcare organizations.

Microsoft's Azure Network Security has released an overview of the group's attack patterns based off recent campaigns and found that the number of daily DDoS attacks, known as a type of cyberattack that can slow down systems by sending too many connection requests to a server, used against Azure healthcare organizations went up to 40-60 attacks in February, compared with 10-20 daily attacks last November. 

The victim organizations of the attacks ranged from pharmaceutical companies to hospitals to health insurance and health services, according to the brief, which included data on how organizations can protect themselves and customers moving forward: "Enable DDoS network protection, design your application with DDoS best practices in mind, ensure it's protected before an attack occurs, create a DDoS response plan, reach out for help during an attack, and learn and adapt after an attack."

Though KillNet's attacks haven't done much to significantly disrupt any of the organizations that have been targeted so far, there's potential for the group to become more dangerous. The group's focus on critical infrastructure makes it essential that organizations take the steps necessary to protect themselves from future DDoS campaigns, Azure warned.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Source

DARKReading