AI can help companies more effectively identify and respond to threats, as well as harden applications.

Much has been made of the use of artificial intelligence in security. Some experts will tell you it is the single biggest key to success, while others will tell you that AI is little more than marketing jargon without any real-world value. I think the truth is somewhere in the middle. AI absolutely has a place in security, but it is not a silver bullet. With that said, there are three primary ways that organizations should be using AI to act as a force multiplier for security teams.

**1\. Attack Prevention**

The use of AI in security should be very focused on multiplying the efforts of security teams, especially considering the current shortage of security skills.

A recent report from JupiterOne found that security teams are responsible for more than 165,000 cyber assets across cloud workloads, devices, network assets, applications, data assets, and users. Trying to defend that many assets is a daunting task. In fact, according to a report by Capgemini Research Institute, 61% of organizations said they would not be able to identify critical threats without AI.

AI and machine learning can reduce the workload for analysts by automatically sifting through data logs and identifying relevant threats. When used effectively, artificial intelligence will not only alert security professionals to threats but also will classify types of attack, allowing security teams to prepare appropriate responses. With this type of ongoing, comprehensive analysis of behavior patterns, analysts can manage even complex threats with far less manual effort, reducing mistakes made due to burnout and exhaustion.

**2\. Intrusion Detection**

Prevention and detection go hand in hand because, as all security professionals know, a determined and skilled attacker will get in eventually. Identifying such a breach is highly dependent on anomaly detection, and this is another security area where AI shines. AI doesn’t get bored and tired like humans do while scanning through the never-ending tedium of operations logs looking for odd behavior.

AI can be even more help when it comes to alert fatigue, a boogeyman of our own creation. Our efforts to identify every possible threat has resulted in an overwhelming number of security alerts. However, most of the alerts that hit the security operations center are false positives that security teams have to wade through to find actual threats. AI can be used to help security teams spend their time and energy wisely by identifying which alerts need immediate attention, which can wait, and which can be ignored entirely.

**3\. Application Security and Developer Productivity**

One of the often-overlooked use cases for AI is application security. In today's competitive climate, companies are constantly launching new apps and updates. It's easy for AppSec teams to fall behind, and these challenges only snowball when vulnerabilities within code are discovered and both AppSec and development teams must divert their time and attention to remediating the issue.

As with attack prevention and intrusion detection, the key value proposition for AI in AppSec is acting as a force multiplier by taking on repetitive and menial tasks. Ensuring the delivery of a secure application involves going through hundreds or thousands of security findings to uncover relationships and gain insight into the risk a vulnerability represents. AI can significantly reduce the time AppSec teams sit with each new application launch or update so that they can focus on more intensive and important tasks.

**Conclusion**

There may be a day when AI is a security savior, but, for the time being, it can be incredibly valuable in helping security teams make sense of the mountains of data an enterprise generates and in ensuring that applications are launched securely.

AI Is Not a Security Silver Bullet

Only about half of firms have an open source software security policy in place to guide developers in the use of components and frameworks, but those that do exhibit better security.

Companies that have an open source software (OSS) security policy in place tend to perform much better in self-assessed measures of readiness. They also tend to have dedicated teams in charge of driving software security, according to a survey published on June 21.

The survey — published by software-security firm Snyk and the Linux Foundation on Tuesday — found that seven out of 10 companies that have an OSS security policy in place consider their application development to be highly or somewhat secure. Comparatively, just 45% of companies that failed to institute such a policy consider themselves at least somewhat secure.

Open source software has significant benefits for application development, but companies also have to recognize and prepare for the downsides, says Matt Jarvis, director of developer relations for Snyk.

"While open source is a proven mechanism for innovation and building high-quality software, it's becoming somewhat a victim of its own success in that its ubiquity has made it a target for supply-chain attacks," he says. "Companies need to build a stronger understanding of both the mechanisms by which open source works, and this includes governance as well as code, and strengthen their approach to supply chain management through adopting developer-first security tooling and methodologies."

**Smaller Firms Lag in OSS Policies**

Overall, only about half of firms have an open source security policy in place to guide developers in the use of components and frameworks, with a greater number of small companies, 60%, either having no policies or not knowing whether they have one, according to the report.

The economics of security tends to reduce the priority of creating a formal policy for startups and smaller firms, the report states.

"Small organizations have small IT staffs and budgets, and the functional needs of the business often take precedence so that the business can remain competitive," the report states. "Lack of resources and time were the leading reasons why organizations were not addressing OSS security best practices."

    

Source: "Addressing Cybersecurity Challenges in Open Source Software" report

Different programming languages also brought different security considerations, according to the study. Applications written in .NET, for example, had the longest average time to fix flaws at 148 days, followed by JavaScript, Meanwhile, those written in Go had the speediest time-to-patch, and were typically fixed in a third of that time, or 49 days.

**JavaScript Dependencies Abound**

JavaScript application have the most dependencies — an average of 174 per project, according to Snyk — or about seven times the language with the fewest dependencies, Python, which averages 25 per project.

While large transitive dependency trees can result in circuitous paths to fix vulnerabilities, having a large number of dependencies is not necessarily a disadvantage, if an organization has ways to track the relationships between projects, says Jarvis.

"JavaScript packages tend to have a smaller scope than other ecosystems, so whilst there are more of them, there may be less code to audit for potential weaknesses," he says. "The most important issue is to understand the dependencies which you are using, particularly the transitive ones brought in as dependencies of dependencies, and that comes down to using the appropriate security tooling to scan things."  

However, the data also shows that different languages tended to have different severities of flaws. The average project written in Java, for example, had more than 47 high-severity vulnerabilities and 28 medium-severity vulnerabilities, much higher than the second-ranked JavaScript, which had an average of 18 and 21 vulnerabilities, respectively. However, Python had the most low-severity vulnerabilities, an average of 20 per project.

"There are a lot of factors at play in the data — the complexity of projects, the number of developers, and the popularity will all have an impact on the number and types of vulnerabilities," Jarvis says. "Many developer eyes on projects that are extremely popular are likely to surface more bugs."

**Automation = Security Maturity**

Despite the importance of identifying vulnerabilities in dependencies, most security-mature companies — those with OSS security policies — rely on industry vulnerability advisories (60%), automated monitoring of packages for bugs (60%), and notifications from package maintainers (49%), according to the survey.

Automated monitoring represents the most significant gap between security-mature firms and those firms without a policy, with only 38% of companies that do not have a policy using some sort of automated monitoring, compared with the 60% of mature firms.

Companies should add an OSS security policy if they don't have one, as a way to harden their development security, says Snyk's Jarvis. Even a lightweight policy is a good start, he says.

"There is a correlation between having a policy and the sentiment of stating that development is somewhat secure," he says. "We think having a policy in place is a reasonable starting point for security maturity, as it indicates the organization is aware of the potential issues and has started that journey."

Open Source Software Security Begins to Mature

After bragging in underground forums, the woman who stole 100 million credit applications from Capital One has been found guilty.

The 36-year-old Seattle tech worker behind the infamous 2019 Capital One data breach has been convicted on seven charges related to the data theft — which are punishable by up to 20 years in jail.

In the incident, Paige Thompson, who operated under the hacker handle "erratic," made off with more than 100 million credit applications that were held in a misconfigured Amazon Web Services storage bucket in the cloud. She was arrested shortly thereafter, after the banking giant traced the malicious activity back to her and alerted the FBI.

"Ms. Thompson used her hacking skills to steal the personal information of more than 100 million people, and hijacked computer servers to mine cryptocurrency," said US Attorney Nick Brown, in a statement. "Far from being an ethical hacker trying to help companies with their computer security, she exploited mistakes to steal valuable data and sought to enrich herself."

Prosecutors noted that Thompson specifically used a scanner to look for AWS misconfigurations, in which databases are left open to the Internet without authentication required for access. In all, she managed to infiltrate the databases of 30 entities, including Capital One — stealing data and in some cases planting cryptocurrency miners.

According to a Department of Justice statement, Thompson "spent hundreds of hours advancing her scheme, and bragged about her illegal conduct to others via text or online forums."

After a seven-day trial and 10 hours of deliberation, a jury in US District Court in Seattle found Thompson guilty of wire fraud, five counts of unauthorized access to a protected computer, and damaging a protected computer. The jury found her not guilty of access-device fraud and aggravated identity theft.

Thompson is scheduled for sentencing by US District Judge Robert S. Lasnik on Sept. 15.

"She wanted data, she wanted money, and she wanted to brag," Assistant US Attorney Andrew Friedman said in closing arguments.

"We are pleased with the outcome of the trial and remain thankful for the tireless work of the US Attorney's Office in Seattle and the FBI's Seattle Field Office in prosecuting this important case," Capital One said in a media statement.

**Cloud Misconfigurations Remain Rampant**

While Thompson was bent on malicious activity, the incident also brought cloud-security responsibility and the issue of misconfigurations to the fore. Capital One was found to be negligent for leaving sensitive financial data open to the public, resulting in an $80 million fine. It also settled customer lawsuits for $190 million — not an inexpensive result.

"The Capital One breach really put cloud security at the forefront of many enterprises," says John Bambenek, principal threat hunter at Netenrich. "Prior to that, there was a misconception that the cloud companies would handle security and that default settings were 'secure enough.' The reality is, the shared-security model requires users to make sure that their cloud environments are secure and that data does not accidentally leak."

In its recent report on cloud misconfigurations, security firm Rapid7 noted that breaches stemming from cloud misconfigurations continue to happen with "distressing frequency."

"First and foremost, you should now be keenly aware that there are individuals actively seeking out cloud service misconfigurations on a daily basis," researchers warned in the report. "Given the right tooling, it's almost trivial for any moderately clever person to hunt for these cracks in the cloud at scale, and they don't even need to be targeting your organization specifically to come across that unintended misconfiguration which ends up exposing sensitive data in your care."

As an example, earlier this month researchers from Secureworks Counter Threat Unit (CTU) found that cyberattackers are targeting misconfigured Elasticsearch cloud buckets for extortion purposes. After finding data exposed on the public Internet, the attackers then steal the wide-open data and replace it with a ransom note. At the time, nearly 1,200 instances had been affected.

Thus, enterprises should dedicate resources to cloud security, including planning for safe and resilient configurations and automated processes to monitor for mistakes and oversights, researchers noted.

Bambenek says there's evidence that things are getting better.

"It's taken a few years, however we are making real strides in not only having default-secure settings, but for security tools to start detecting misconfigurations and malicious behavior in cloud environments," he tells Dark Reading.

Capital One Attacker Exploited Misconfigured AWS Databases

RSOCKS commandeered millions of devices in order to offer proxy services used to mask malicious traffic.

A Russian botnet known as RSOCKS has been dismantled – but not before infecting millions of devices globally.

Like many botnets, RSOCKS initially targeted Internet of Things (IoT) devices, but it soon expanded to industrial control systems, Android devices, and PCs, according to the US Department of Justice (DoJ). Its specialty was providing cover for large-scale credential-stuffing attacks and other malicious activity by offering clients access to the IP addresses of these nodes for proxy purposes, according to the DoJ.

Via a Web-based “storefront,” users could rent access to a pool of proxies for a specified daily, weekly, or monthly time period, at prices ranging from $30 per day for access to 2,000 proxies to $200 per day for access to 90,000 proxies.

"The customer could then route malicious internet traffic through the compromised victim devices to mask or hide the true source of the traffic," according to the DoJ's statement on the RSOCKS takedown. "It is believed that the users of this type of proxy service were conducting large scale attacks against authentication services, also known as credential stuffing, and anonymizing themselves when accessing compromised social media accounts, or sending malicious email, such as phishing messages."

The DoJ worked with law enforcement in Germany, the Netherlands, and the United Kingdom to disrupt the botnet.

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

Feds Take Down Russian 'RSOCKS' Botnet

Feeling creative? Submit your caption and our panel of experts will reward the winner with a $25 Amazon gift card.

Summer is here, the beaches are filling up, and even our multilegged friends are ready for some R&R. Or maybe, just maybe, they're hoping to catch us with our guards down. What do you think? Send us your caption ideas for the cartoon, above, and you could win a $25 Amazon gift card. Here are four convenient ways to submit your idea:  

*   Email _\[email protected\]_ with the subject line "Dark Reading June Toon."
*   Via social media: Twitter, Facebook, and LinkedIn.

The contest ends Wednesday, July 13, 2022. We look forward to your submissions.

**Last Month's Winner  
**Congratulations (and a $25 Amazon gift card) go to David Eisenhower, deputy IT officer for Joint Computer Technologies and Training Management (JCTM LLC). His clever caption charged ahead of our submissions to win first place. 

    

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

Name That Toon: Cuter Than a June Bug

A Kremlin spokesman said that the St. Petersburg International Economic Forum accreditation and admissions systems were shut down by a DDoS attack.

Billed as the "Russian Davos," the St. Petersburg Economic Forum was stalled on Friday by a distributed denial-of-service (DDoS) attack, delaying a speech from Russian President Vladimir Putin for more than an hour.

The attack was confirmed by Kremlin spokesman Dmitry Peskov, who told Reuters that the admissions and accreditation systems were shut down by the DDoS attack. He did not place blame on any specific individual or group, but as Reuters reported, the "situation in Ukraine loomed large."

About 100 minutes after its scheduled start time, Reuters reported that Putin gave his remarks and lashed out at the West's sanctions put in place following the Russian invasion of Ukraine, which he called a "blitzkrieg" on his country's economy.

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

DDoS Attacks Delay Putin Speech at Russian Economic Forum

Low-code/no-code platforms allow users to embed their existing user identities within an application, increasing the risk of credentials leakage.

According to the "2022 Verizon Data Breach Investigations Report," stolen credentials were the top path leading to data breaches. More often than phishing or exploiting vulnerabilities, attackers gain direct access to credentials, letting them virtually walk into victim organizations using the front door.

Low-code/no-code platforms make it extremely easy for users to share their credentials and embed their credentials into applications, thus drastically increasing the risk that employee mistakes will result in credentials leakage. Unintentionally, low-code/no-code development makes the No. 1 resource for attackers easier to obtain.

**How Low-Code/No-Code Platforms Sacrifice Security For Productivity**

Getting the required permissions to do your job in an enterprise can be very frustrating. It's not uncommon for new employees to wait more than a month before they have the full scope of permissions they need to access business data, review KPI dashboards, or join an internal communication channel.

The same thing is true, maybe even worse, for setting up a new application in the enterprise. Permissions requests typically need to be approved by your direct manager, their manager, and the team who owns the data/service. Some of the approvers might be in another continent with a time zone difference. It's next to impossible to start building an application without the required access to data/services, and so you end up waiting.

After you manage to get the right access for your application, you are finally ready to start building. A few months go by. Suddenly, you get a notification that your application has failed. A quick analysis shows that its permissions have been revoked. Enterprises typically set up an automated process that revokes access every few months, unless permissions are explicitly asked for by the application maker. This process is necessary to comply with regulations and reduce over-permissions, but it has its downsides — namely a periodic manual process that could hinder productivity.

Low-code/no-code is an attempt to empower every employee, especially business professionals, to address their own issues with custom-built applications and automations. Vendors do this by systematically identifying and removing roadblocks for building applications. Is learning to code challenging or scary? A drag-and-drop interface can help lower the barrier to entry. Is integration difficult? A wide range of managed connectors will remove the need to know what an application programming interface (API) is or how to interact with it. Is asking for permissions slowing you down? Sharing identities and leveraging existing user access can provide a quick alternative.

To boost innovation, low-code/no-code platforms allow their users to leverage their existing user identity, embed it within an application, and by doing so circumvent the enterprise permissions model entirely. For an outside viewer in security or IT, the application doesn't exist, and everyone using it is actually running it on its maker's account.

**Wait, But How?**

If you're thinking that there are better solutions out there than letting the application impersonate its maker, you are partially right.

In recent years, OAuth has been the de-facto standard for granting application access. Any time you go to a software-as-a-service (SaaS) marketplace, pick up a third-party integration, and get prompted with a small login and consent pop-up, you're most likely using OAuth. OAuth has many different consent flows, all resulting in the familiar pop-up experience. A key distinction is whether consent is granted to the application directly or on behalf of its currently signed-in user. Although this might sound like a minor detail, it is actually the root cause of the low-code/no-code identity problem.

When an application is granted consent directly, it is issued its own identity, separate from that of the user who granted the consent. The application identity can be monitored for suspicious authentication or access patterns, and its permissions can be revoked at any time by a security or IT admin. Controls like IP restriction can be put in place to take advantage of the static nature of the infrastructure that the application runs on. Every application can have a separate identity, with separate access restrictions, and can be monitored and acted up--on separately. Another useful implication of application identity is admin control.

Granting consent on behalf of the currently signed-in application user, however, has very different implications. The application gains access to resources using its user's identity for the limited time when the user uses the app. On-behalf access means that the application is actually using its user's identity directly when querying external resources. Moreover, using multiple applications will result in all of them using the same identity: the user's identity. IT or security admins looking at logs will not be able to easily distinguish between the user or any application used by the user. Granting application access on behalf of users was originally designed to allow temporary access only while a user is actively using the application.

In many cases, services allow applications to gain access on behalf of users but deny applications direct access to service APIs. This raises an interesting question: If an application can only gain access to data on behalf of a user, how can it access data when no user is interacting with it? Creative engineers have come up with a solution. The application logs in as a user once, then records its authentication token and keeps on using it even after the user has logged off the application. In the case of low-code/no-code applications, that user is typically the application's creator. User authentication tokens are supposed to be short-lived in order to prevent this workaround. In practice, however, most services issue tokens that are valid for 12 months.

Let's say a business professional creates an application. Instead of having to wait for approval of an application identity or permissions, they use access on behalf of a user — in this case, their own. The application requires them to log in once (say to Salesforce or SharePoint), records their own private authentication token, and reuses it at will. Even if another user is using the application, it will still use its maker's identity.

There are ways to build low-code/no-code applications with dedicated identities — for example, by using service accounts. However, the methods are not very widely used.

Recall the positive properties of application identity stated above: The application can be monitored, its access to data can be controlled, and its privileges can be revoked. None of this is true when low-code/no-code platforms are embedded with their creator's identity. Every application a business professional makes might have their user identity built into it. Security and IT teams analyzing access logs will have no way to know that these applications even exist.

**Impersonation-as-a-Service**

Recording and replaying user authentication tokens as a way to grant applications access to resources has another implication: They open the door to simple and easy identity sharing among users. This manifests in a common low-code/no-code feature typically referred to as connections. Connections are how low-code/no-code applications gain access to resources like Slack, NetSuite, or BambooHR. They allow read operations, like reading employee HR data; write operations, like the ERP on recent sales; and delete operations, like permanently deleting a Slack channel. Connections are first-class objects, which means they can be created by one user and shared with another user, an entire team, or even an entire organization. Technically speaking, these are wrappers around user authentication tokens or hard-coded credentials.

When a user creates and shares a connection to Microsoft Office, for example, it is akin to them sharing their password. However, if a team of developers is collaborating on a project, they often need to be able to share an application identity with each other. Connection sharing enables working together in a team on a shared project, but unfortunately it can also enable users to share their identities with each other. Since many low-code/no-code applications are built with the creator's identity embedded within, identity sharing is a common risk low-code/no-code platforms introduce.

To make matters worse, credential sharing is just way too easy on many platforms. A single checkbox stands between you and sharing your identity — for example, your ServiceNow or Salesforce account — with your entire organization. In some cases, sharing an application with other users implicitly shares its underlying connections too.

This is a crucial point. Under certain circumstances, users who gain access to a business application will gain direct access to its underlying database implicitly, without direct consent or knowledge. Take an expense management application, for example. There's a big difference between letting people use the application to submit their expense reports and giving them access to the underlying database with everyone's expense reports within it.

Unintentionally, low-code/no-code applications make credentials — the No. 1 resource that attackers are after — easier to obtain.

**Where Do We Go From Here?**

As we've seen, low-code/no-code platforms had to overcome many challenges in making enterprise applications easy to build for everyone from professional to business developers. Sometimes, the solutions come at a cost. In the case of credentials, the ability to move fast is unfortunately coupled with the ability to break things — namely, the enterprise identity model.

It is important to mention here the immense value that low-code/no-code platforms create for the enterprise: reducing the time between idea and execution, lowering the bar for application development, and increasing business velocity.

Platforms cannot be expected to resolve security concerns on their own; it is a responsibility shared between the platform and its customers. To reduce the risk, security teams should familiarize themselves with the ways identities are treated as part of the low-code/no-code platforms their organizations use. Most platforms can be configured to reduce the level of credential sharing and turn off implicit sharing.

More importantly, security teams must realize that low-code/no-code platforms introduce an inherent new risk into the enterprise that cannot be mitigated by traditional monitoring approaches because of the confusion between application and user identities. Therefore, security teams should invest in guiding business developers, reviewing potentially risky applications, and taking action to mitigate risk.

Credential Sharing as a Service: The Hidden Risk of Low-Code/No-Code

Security defenders working for large venues and international events need to be able to move at machine speed because they have a limited time to detect and recover from attacks. The show must go on, always.

Live events such as concerts and sports games are generally chock-full of action, both on the field and behind the scenes. IT and security teams managing these venues navigate a complex environment that includes a traditional corporate infrastructure, special equipment required for the event, a large army of suppliers and contractors, and all of the devices brought in by spectators. And the prospect of a cyberattack during the actual event always looms large.  

Securing live events can be the most complicated and most complex to protect, says Karim Benslimane, director of cyber intelligence at Darktrace. Running a stadium can be split into a “business perspective,” which is akin to managing the technology infrastructure for a very large enterprise, and the “event perspective,” which includes all the people and equipment involved with setting up and hosting the event itself.

“When there is no event doesn’t mean the IT guys don’t have anything to do,” Benslimane says. “They are already busy running the business.” He speaks from experience. Prior to joining Darktrace, he was head of information and communications technology and cybersecurity for various international venues and events.

**Understanding the Cyber Paradox**

The business infrastructure depends on much of the same technologies and enterprise applications – Active Directory, telephony, wired and wireless networking, ERP, CRM, databases, and e-commerce applications, to name just a few – as a large organization  requires to manage the day-to-day operations. Payroll needs to make sure people are paid, employees need to be able to communicate internally and with clients and customers, and tickets have to be printed and sold.

The event has its own infrastructure, and managing the event requires a completely different mindset because of what Benslimane refers to as the “cyber paradox.” The traditional security mindset is to deploy technology and control to add layers to make it harder for attackers to access systems and restrict what is added to the network. Setting up an event, by definition, involves hiring suppliers and contractors (along with their sub-suppliers and subcontractors) who bring their own assets and need access to the venue’s infrastructure, such as VoIP and Wi-Fi. For example, the venue may own the jumbo screens, but the immersive elements and special effects that make the event come alive are pushed onto the screens from third-party systems.

“From a cybersecurity point of view, it’s obviously a paradox where you are trying to secure your assets on the left, but on the right, you are forced to allow external people and external devices to come physically into your venue and use your infrastructure,” Benslimane says. It doesn’t make sense to talk about securing the perimeter when people are already inside, he notes.

On top of that is the live event itself, or “D-Day,” which requires letting even more people physically enter the venue with their own devices and access services such as Wi-Fi.

“It was a big challenge. You have nothing to control and protect you,” Benslimane says.

**Limited Time to Respond**

As the saying goes, the show must go on. Security teams in the events industry have to “rush and run” to mitigate security incidents as they occur so that the event can go off as scheduled and associated services (such as broadcasts and streaming contracts) are not impacted.

“If something happened during the 100-meter men’s final \[at the Olympics\] or the \[FIFA\] World Cup final, think about the brand impact,” Benslimane says. Interrupting the broadcast would mean millions of TV and screens will see a black screen, which would result in immense financial losses for the brand. There will be penalties from lost advertising. This would also affect the host country’s reputation.

Those were the same challenges Wired reporter Andy Greenberg wrote about in his book about Olympic Destroyer, the malware that knocked out the domain resolvers during the opening ceremonies. As a result of the attack, some attendees couldn’t print tickets to enter the stadium, the Wi-Fi network was offline, TVs around the stadium and other facilities could not show the ceremony, the RFID-based security gates for Olympic facilities were not working, and the official Olympic app was broken. If the systems remained offline after the opening ceremony ended, athletes, visiting dignitaries, and spectators would find they had no access to the Olympics app full of schedules, hotel information, and maps. 

“The result would be a humiliating confusion,” Andy Greenberg wrote for Wired.

Attackers realize that events can’t be delayed and take advantage of that time constraint to cause the most damage, Benslimane says. There is no time to recover when the match ends in a few minutes.

**Holding the Event Hostage**

Ransomware attacks encrypt documents and make it hard for organizations to function. A ransomware attack on a live event cripples the technology and interrupts the show. Cybercriminals clearly understand that the venue cannot postpone, or replay, D-Day. Imagine if a cyberattack disrupted the systems to the point that the game cannot continue, and the venue asks the crowd to leave and come back next week. 

“Just imagine the fights,” Benslimane says.

Organizations rely on the metrics MTTK (mean time to know) and MTTR (mean time to repair) to identify, investigate, and mitigate the incidents. Those metrics highlight the challenges facing live events because the clock is already ticking. If the security team takes more than 10 or 15 minutes to detect and investigate an incident, that is already halfway through the first half of the game and the halftime show is coming up, Benslimane says. This is the biggest advertising window, and not being able to broadcast the ads would be a significant blow to the organization, which makes it even more likely that these venues would pay the ransom.

“The cybercriminals clearly understand that if something happens during D-Day, there won’t be enough time to respond,” Benslimane says.

**Moving Faster than the Attackers**

Attackers move faster than defenders, which makes it difficult for security teams to respond during an event. For defenders to be able to respond effectively, they need to be operating at machine speed, which means using artificial intelligence (AI) as part of the security response, Benslimane says, noting that he deployed Darktrace’s technology in his past roles. The AI can look at all of the events happening in the network and correlate them quickly to identify which issues are problematic. If the investigation finds that the issue is actually not a problem, then the AI doesn’t take any action. And if there is an issue, the AI already has the information it needs from the investigation to neutralize the threat and remediate, such as by blocking a particular connection or isolating the affected system.

The AI is like a “sponge” for knowledge. 

“As long as you put in water, the sponge will absorb it. The AI brain will absorb everything you give it,” Benslimane says.

Speed is paramount for detection, investigation, and making the decision on how to respond, especially when the environment is complex and constantly evolving. The infrastructure for a live events venue is not static, so the AI is constantly learning, analyzing, and making decisions.

The AI is “much faster than 1000 cybersecurity guys in a SOC – even if it’s the best SOC in the world,” Benslimane says.

Security Lessons From Protecting Live Events

Companies need to fill some of the 3.5 million empty cybersecurity seats with workers who bring different experiences, perspectives, and cultures to the table. Cut a few doors and windows into the security hiring box.

In the past year, we've had to grapple with the impact of a quickly growing threat landscape. Debilitating cyberattacks against our critical infrastructure, threats against our already weak supply chains, and the continued ripple effect of the Log4j incident have fueled the need for more intentional investment in security tools and services.

With cybercrime growing, it's no secret that there is a dire need for cybersecurity talent globally, so let's break down what the industry looks like for a moment. For security spots already filled, only 4% are Hispanic, 9% are Black, and 24% identify as women, according to the Aspen Institute. There is a clear picture painted for us: Not only do we need to fill the empty seats, but we need to fill them with workers who are bringing different experiences, perspectives, and cultures to the table.

**Unlocking Innovation with Diversity**

So, why does this matter? Diversity and inclusion have become notorious for being buzzwords within organizations, with companies increasingly touting their respective campaigns, and programs around diversity efforts.

In every industry — but particularly in an industry like cybersecurity that is changing by the minute — we need the brightest ideas, the most well-rounded teams, and the most creative practitioners. Having diverse thoughts, backgrounds, and experiences leads to better and more informed decision-making. At SPHERE, the diversity of our team has improved our ability to overcome business challenges. Our array of talent has also enhanced our culture, reduced turnover, and led to a greater sense of satisfaction throughout the organization.

Another key reason diversity should be a vital thread in the fabric of your cybersecurity business is that it's exactly what the new wave of job seekers is looking for.

Millennials now make up more than one of every three people employed in the United States. And data shows that this powerful group is no longer satisfied with the way workplace benefits and culture have traditionally been measured. According to Weber Shandwick, 47% of millennials consider diversity and inclusion an important factor in considering a new job, 14% more than Gen-Xers. Cybersecurity organizations and teams are the backbone of our infrastructure and daily activities, and thus should be communicating their values, beliefs, and missions so that they are attracting the most ambitious, creative professionals.

**A Tool Set for Progress**

We must take this information and run with it, strategizing ways to nurture a healthy pipeline of diverse talent. The first and most important step to doing this is being confident that there is a problem but that your organization is more than capable of solving it. To begin, recognize that there are many technical and nontechnical roles available in security. The points of entry into this industry are vast and go beyond engineering — from governance, risk, compliance, and IT to business development, product marketing, and communications.

Secondly, partner with local colleges and universities, tapping into educational programs outside of engineering or software development, as well. Organizations such as Cyversity, Women in Cybersecurity (WiCyS), and Women in Security and Privacy (WISP) are doing phenomenal work opening the door of opportunity to populations historically locked out.

Last, and in my opinion one of the most important strategies, is to leverage your networks to initiate open conversations about the work you are doing. As a woman founder and CEO of a cybersecurity company, I am committed to using the platform and resources I have to nurture the next generation of diverse cybersecurity professionals.

We can't sit back and watch as the talent and skills gap within our industry widens. At SPHERE, we've set out to empower young women to achieve greatness in the cybersecurity industry. As such, we're launching a program, SP(HER)E, that partners established women leaders with younger women who are new or are looking to break into the industry.

**The Way Forward — Perspectives From a Woman Leader**

I've faced a fair share of challenges being a woman leader in this space. When I started my business, I was a young woman launching a niche company in a male-dominated industry, and there was doubt around my ability due to inexperience combined with the unfortunate reality that some folks tend to consider women less capable than men. I understand that this is an issue and a gap we can't fill overnight. But we _can_ commit to daily, small steps that will compound into meaningful results in the next few years.

The cybercriminal landscape is only getting more sophisticated, cunning, and large. Hiring diverse talent – and sustaining this progress with investments into professional development and retention – are the first steps toward a well-equipped and thriving cybersecurity team!

The Cybersecurity Diversity Gap: Advice for Organizations Looking to Thrive

Security teams —  who are already fighting off malware challenges — are also facing renewed attacks on cloud assets and remote systems.

Big picture, security professionals worry about how to defend their organizations against increasingly sophisticated attacks exploiting zero-day vulnerabilities or nation-state attackers, but their day-to-day security concerns appear to be far more prosaic. According to Dark Reading's "The State of Malware Threats" report, ransomware and phishing attacks are top-of-mind for security professionals.

When asked which type of attacks worried them most, 61% of IT security professionals cited ransomware, followed by 54% for phishing attacks. These statistics are significantly higher than last year's survey, where 41% said they were concerned about ransomware and 31% about phishing attacks.

Ransomware attacks are on the rise, and they are increasingly expensive. Even if an organization doesn't paying the ransom, the recovery cost is high, and there is the risk that the attackers might dump sensitive data online. Phishing is also another big concern, as that tactic is used in pretty much every kind of attack to download malware onto user machines or to steal information and credentials.

Even as more employees return to the office in the wake of the COVID-19 pandemic, the changes that two years of remote work wrought on business operations remain intact. Cloud implementation, which was already rising back in 2019, accelerated even more than predicted.

The increased reliance on the cloud may be why 27% of IT security professionals cited attacks on cloud systems and services as most worrisome.

Some threats may be of heightened concern due to highly publicized breaches. The 2019 SolarWinds attack, for one, kicked off what the report calls "a new wave of breach-once-compromise-many attacks via the software supply chain." Add in the July 2021 Kaseya ransomware kerfuffle, and it's easy to see why concern about malware and other compromises triggered by suppliers or other trading partners hit 20% in 2022, compared with 14% in 2021. Incidents such as the Microsoft Exchange Server exploit in March 2021 truly unnerved security professionals: Concerns and vulnerabilities in applications and operating systems more than doubled, from 11% in 2021 to 29% in 2022.

Polymorphic fileless malware was cited as another area of concern for 24% of respondents, up from 14% last year. This type of malware modifies functions and processes without needing to be a standalone file, which makes it difficult to detect. Cross-platform malware such as Hajime (a new category in the survey, which 7% of respondents cited) often targets Internet of Things (IoT) devices, an attack vector whose profile doubled, from 12% in the 2021 survey to 24% in 2022.

Surprisingly, concern about malware that uses artificial intelligence stayed nearly flat, rising only 1% to 18% this year. That's still a well-recognized threat, but it's interesting that fear around it has cooled.

Source

DARKReading