STE WILLIAMS

Image Source: Adobe Stock: penguiiin

Whether landline or mobile, for work purposes or personal use, phones are part of our everyday lives. Criminals know this, too, so it’s little wonder why voice fraud has been running at an all-time high.

According to Pindrop, 90 voice fraud attacks occur every minute. Last year, the fraud rate was one out of 685 calls, remaining at the top of a five-year peak.

Exacerbating the problem, knowledge-based authentication (KBA) information, such as date of birth and street address info, has become readily available to fraudsters, says Chris Halaschek, vice president of product at Pindrop. “We have found that in roughly 60% of the cases, fraudsters can answer the KBAs,” Halaschek says.

How can you ensure a fraudster doesn’t ruin your next call? The following tips can help consumers and businesses stay safe.

Steve Zurier has more than 30 years of journalism and publishing experience, most of the last 24 of which were spent covering networking and security technology. Steve is based in Columbia, Md. View Full Bio

Article source: https://www.darkreading.com/application-security/7-ways-to-hang-up-on-voice-fraud---/d/d-id/1336427?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Source: StaySafeOnline.org

What security-related videos have made you laugh? Let us know! Send them to [email protected].

Beyond the Edge content is curated by Dark Reading editors and created by external sources, credited for their work. View Full Bio

Article source: https://www.darkreading.com/edge/theedge/how-to-be-a-more-thoughtful-and-safe-digital-citizen/b/d-id/1336476?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

There are several key market forces affecting the cyber landscape that regularly make the headlines: a shortage of security personnel, a huge rise in the number of security tools, and a growing attack surface due to the move to bring-your-own-device policies and the cloud. However, another market force is changing the nature of the industry: increasing pressure to adhere to numerous regulations such as the General Data Protection Regulation, the SHIELD Act, the California Consumer Privacy Act, and the more-recent MAS cyber hygiene notices.

Auditors and regulators expect us to show that reasonable security measures are in place to protect customers’ personal data and business-critical applications, at any point in time. And this is where we struggle — to demonstrate that due care was taken. The trend we see is that organizations are investing in a lot of tools to manage risks. This is shown by a recent study, conducted by Forrester Research, which surveyed more than 250 senior security decision-makers in North America and Europe.

The report outlined that organizations are using multiple technologies to identify and mitigate risk, including security analytics platforms; vulnerability management; governance, risk, and compliance platforms; and vendor risk management platforms. But multiple tools can compound the issues around reporting — reports must be collated and organized manually, taking the team away from “doing security” and reducing the likely frequency of report updates, which means stakeholders do not have one version of the truth.

To alleviate the disconnect, as a sector we recognize that we need to move to continuous and accurate cyber-risk reporting, which is by fueled automated data collection and collation. The starting point for this is an agreement on what security metrics should be measured and how. There are several practical principles that we can use to make metrics more business-focused, accurate, and measurable as we move into an era where accuracy and relevance are king.  

The starting point is an agreement on which questions need to be answered to make the business more secure and what data is available to help inform the answers. The metrics must be able to stand up to scrutiny. We also need to make sure we know what to do with an answer to the original question. I liken it to The Hitchhiker’s Guide to the Galaxy — if I told you the answer to the meaning of life, the universe, and everything was 42, what would you do with that information? If we don’t know what to do with any given metric, then we need to go back to the beginning.

The next practical principle is to always aim for simplicity. A complex metric, one that is hard to interpret, may be less effective than a couple of simple ones! If the audience for a metric doesn’t get the message it’s intended to convey, the metric has failed no matter how “smart” it might be. Simple stats that are well-executed and easy to explain win over black-box analyses every day of the week. And don’t forget we need to add business context — business-focused metrics resonate with the board and business stakeholders as they enable them to drive action.

How many metrics do we need? An effective approach is to align metrics to industry-accepted security frameworks. Aligning to a framework gives an indication of how well a metrics program covers the breadth of security areas and if there’s any gaps that need filling. Frameworks can help provide a familiar structure for a metrics program and naturally provide higher levels at which we can summarize analysis and provide an effective overview for business stakeholders.

Now it’s time to collect data and build metrics. A high-quality inventory is the foundation for trusted metrics. Try to combine multiple datasets to get the most complete and accurate picture of assets possible and classify them as accurately as possible, asking questions such as: Is this server Internet-facing? Does this database support a critical app? Which business line owns this? This enables metrics to have that all-important business context and helps with prioritization. Being able to show metrics for the infrastructure supporting business critical applications is invaluable to get buy-in from the business.

Also, it’s key to verify rather than trust. We don’t want to add inaccuracies into metrics by assuming we know some of the facts already — e.g., “they told me antivirus was deployed on all my devices.” And if we can’t measure something, it shouldn’t be in our metrics program! Bear in mind, of course, there are more or less accurate ways to measure — an approximate measurement is fine as a starting point, but a guess is not.

Once we have verified, we need to verify again. Use the type of metric to assess an ideal frequency and then measure as close to that as is feasible for the organization — for example, if the vulnerability scanner is run once a week, we don’t need to update/verify data and create metrics on these daily.

Finally, never forget that whether the metrics are for the board, a business line, regulator, or auditor, the key is also knowing the accuracy, timeliness, and the limitations of the measurements. A good illustration is patching time on our servers. We need to make sure we know the percentage of servers that aren’t covered by our scanner. After all, “90% server vulnerabilities fixed within service-level agreement” becomes decidedly less impressive if we know that only 50% of servers are being scanned.

The key takeaway here is that a proactive approach to cybersecurity requires the right tools, not more tools — just as a metrics program is much more effective with simple, accurate metrics rather than a host of numbers that may be wrong, as well as out of date.

Related Content:

• The 20 Worst Metrics in Cybersecurity
• 7 Considerations Before Adopting Security Standards
• Why Organizations Must Quantify Cyber-Risk in Business Terms
• Which Security Metrics Should I Use?

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Gamification Is Adding a Spoonful of Sugar to Security Training.”

Nik Whitfield is the founder and CEO at Panaseer. He founded the company with the mission to make organizations cybersecurity risk-intelligent. His  team created the Panaseer Platform to automate the breadth and depth of visibility required to take control of … View Full Bio

Article source: https://www.darkreading.com/risk/practical-principles-for-security-metrics/a/d-id/1336428?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

On January 1, 2020, California will step on the world stage of privacy when the California Consumer Privacy Act (CCPA) takes effect. It follows the European Union’s General Data Protection Regulation (GDPR) and other regional legislative controls that are designed to protect the personal data of consumers.

The CCPA legislation may apply to your business if it’s a for-profit entity and collects or processes the personal information of Californian residents. And one of the following needs to apply: the business has an annual gross revenue in excess of $25 million; the business annually trades the personal information of 50,000 or more consumers, households, or devices; or the business derives 50% or more of its revenue from selling consumers’ personal information.

There may be requirements to update privacy policies, third-party, and service provider contracts and any other terms that cover the collection, retention, and protection of personal data held by the company. It’s important that all businesses review their status and establish if they need to comply with the legislation.

As with other privacy legislation, the fines for noncompliance could be significant. Under GDPR, we have recently witnessed British Airways being fined $230 million and Marriott Hotel Group $123 million for data breaches. The CCPA legislation allows for fines by the attorney general of up to $7,500 per incident and gives individual consumers the right to file a lawsuit for up to $700 each. I expect once the legislation takes effect that we will see some considerable legal action with class action lawsuits filed against companies that suffer data breaches

Complying with the legislation requires companies to adopt policies for the collection and retention of the data. It also requires companies to provide “reasonable security” to protect the personal data. The word “reasonable” can be interpreted in many different ways and the extent of what is deemed reasonable will not be clear until we see the legal cases being brought once the legislation takes effect.

To assist companies in taking proactive steps to address the requirement for reasonable security, companies could leverage the requirements of other legislation such as GDPR. The following are starting points for companies that need to comply; note, however, that these are just starting points, and I recommend seeking professional and legal advice to ensure compliance.

Privacy Basics: Single Point of Responsibility
Appoint a data protection officer (DPO). This is a requirement under GDPR and is an essential position for any company holding personal data. A DPO’s main tasks should include understanding where the data is, the business purpose of why it was collected and is being retained, controlling access to the data, and deleting data no longer required. Consumers may request a copy of their data or require it to be deleted, and a dedicated DPO facilitates a single point of contact to deal with such requests.

Having this single point of responsibility is essential so that businesses can operate in a professional and compliant environment. The DPO can organize regular risk assessments, penetration tests, and security policies. While these do not provide a 100% guarantee that no breach will happen, they are steps that provide evidence that the issues have been taken seriously in the organization, providing a defensible defense should the need occur.   

Limiting access to the data will reduce the risk of an inadvertent breach and reduce the number of employees that will need specialized training in the management and handling of personal data. It does not, however, reduce the need for all employees to be subjected to cybersecurity awareness training.

The data should be considered the crown jewels of the organization. Without customer data, or with a lost reputation due to a data breach, the company is likely to suffer financially. Treating the personal data of consumers like the crown jewels and placing it in its own protected segment of the network will create barriers and layers that can thwart the attempts of cybercriminals to gain access. We deal with layers in everyday life: The important possessions we own personally may be in a home safe or a safety deposit box. We then secure our homes with alarms and several locks on doors. With every layer, we add more complexity for the burglar.

Securing personal information should include, at a minimum, encryption and multifactor authentication. When asked, “What should I encrypt?” the answer is everything. Encryption is no longer the resource overhead it once was and by having whole-device encryption on devices, the risk of data being breached due to a stolen or lost device is reduced. Encryption of the personal data being held, including the hashing of customer passwords, will also demonstrate that significant steps have been taken to secure the data.

It would seem unprofessional not to include the following recommendations:

• Make sure all devices connected have been patched and updated.
• All devices should be protected with an up-to-date endpoint anti-malware product.
• All devices and data should have a backup and recovery policy that is tested from time to time.

The need to have privacy legislation is just another step in the evolution of the digital and connected revolution that is transforming humanity. As consumers, we need to engage in understanding the value of our data, who we allow to collect it, and what we allow them to do with it. Without this engagement or legislation to protect us, we allow companies wishing to monetize by using our personal information to have free rein.

Related Content:

• 6 Actions That Made GDPR Real in 2019
• Employee Privacy in a Mobile Workplace
• Social Media: Corporate Cyber Espionage’s Channel of Choice
• I ‘Hacked’ My Accounts Using My Mobile Number: Here’s What I Learned

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Gamification Is Adding a Spoonful of Sugar to Security Training.”

Tony Anscombe is the Global Security Evangelist for ESET. With over 20 years of security industry experience, Anscombe is an established author, blogger, and speaker on the current threat landscape, security technologies, and products, data protection, privacy and trust, and … View Full Bio

Article source: https://www.darkreading.com/endpoint/privacy/how-to-get-prepared-for-privacy-legislation/a/d-id/1336418?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A security researcher at Black Hat Europe in London next week plans to release an open source low-level emulator that can run a version of Apple’s mobile operating system.

The project, based on the open-source machine emulator QEMU, will allow security researchers to have more access to iOS processes and operations, an advantage when searching for vulnerabilities and systems weaknesses, says Jonathan Afek, the leader of the emulation project and a security team research manager at dynamic-testing provider HCL AppScan.

Afek plans to demonstrate the iOS kernel running on a QEMU virtual machine as well as show ways of using the setup to search for vulnerabilities.

“Apple iPhones are quite secure, but all platforms have a lot of vulnerabilities in them,” he says. “I think this platform, quote-unquote, in its current stage, it will make life easier for researchers and make the iPhone more secure by allowing security researchers to investigate vulnerabilities before they are exposed by others.”

Apple is unlikely to agree. The project is the latest attempt to provide interested researchers with a platform that could be used by reverse engineers to look for vulnerabilities as well as those aiming to jailbreak their phones.

Yet, like most aspects of its iOS ecosystem, Apple keeps tight control of who can run its operating system and in what ways. Apple considers any non-approved use of its iOS operating system to be an infringement of its intellectual property. 

An Apple Lawsuit

In August, Apple sued mobile device virtualization company Corellium for offering a service based on a similar platform it had developed — albeit, one that is far more mature than Afek’s open-source version.

“Although Corellium paints itself as providing a research tool for those trying to discover security vulnerabilities and other flaws in Apple’s software, Corellium’s true goal is profiting off its blatant infringement,” Apple stated in its lawsuit. “Far from assisting in fixing vulnerabilities, Corellium encourages its users to sell any discovered information on the open market to the highest bidder.”

Since January 2018, Corelliuim has offered the tool as a service to bug hunters an security researchers to emulate an iPhone running any version of the operating system. The company argues that allowing researchers to work on an emulated iOS is helpful for the entire community of users.

“We founded Corellium to equip the mobile community with the scalable, efficient, and innovative tools they need to push the mobile ecosystem forward,” Amanda Gorton, CEO of Corellium, wrote in a statement regarding the lawsuit by Apple. “By combining the fidelity of native architecture with the advantages of a virtual resource, our pioneering platform empowers security experts, software developers, and mobile testers to do their work better than they could before — whether that’s testing an app, conducting training, or working for our national defense.”

Findig vulnerabilities in Apple devices can be lucrative. In January 2019, for example, exploit and surveillance software firm Zerodium doubled the bounty — to $2 million — that the company pays to researchers that privately offers a previously unknown exploit that can compromise an iPhone with no interaction. The company provides such exploits to its clients to test their own systems and attack targeted devices.

Increasing interest in the security of its devices prompted Apple to increase what it pays to researchers as part of its bug bounty program. Finding a vulnerability that allows a program to get around the secure boot firmware can earn a bounty of $200,000 as of May 2019, according to the company’s iOS Security whitepaper. In the past, only vetted researchers could participate in the bounty program, but the company has reportedly since opened up the process to anyone.

Meanwhile, the iOS emulator that HCL AppScan’s Afek developed is still very much a work in progress. The platform cannot run the latest version of iOS nor emulate the latest hardware, he says.

“It is in the very early stages — it only runs iOS 12.1 for iPhone 6,” Afek says. “I’m currently working on additional features and support for newer iOS versions. It will be a challenge, but not a really big challenge — just a little bit of work to support the newer features.”

Afek’s Black Hat Europe presentation will be on Dec. 4. Apple did not return an e-mail request seeking comment on the new platform.

Related Content

• Apple Boots 17 Trojan-Laden Apps From Mobile Store
• Apple Misstep Leaves iPhones Open to Jailbreak
• Bug Bounty Awards Climb as Software Security Improves
• Researchers Finds Thousands of iOS Apps Ignoring Security

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Home Safe: 20 Cybersecurity Tips for Your Remote Workers.”

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT’s Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline … View Full Bio

Article source: https://www.darkreading.com/mobile/new-free-emulator-challenges-apples-control-of-ios/d/d-id/1336478?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

In the second quarter of 2019, Google sent more than 12,000 warnings to users targeted by state-sponsored phishing campaigns. That number is similar to the third quarter phishing numbers of the previous two years. The information on phishing is part of a new blog post on protecting users from government-backed hacking and disinformation from Google’s Threat Analysis Group.

In the post, Google described threats previously detailed as originating with the Russian “Sandworm” group, and steps the company has taken to defend users from the attacks. Those attacks are part of larger campaigns Google has found combining disinformation tactics with active phishing and malware attacks seeking account credentials from high-value users including journalists, human rights activists, and political campaigns.

For more, read here.

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Home Safe: 20 Cybersecurity Tips for Your Remote Workers.”

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/google-details-its-responses-to-cyber-attacks-disinformation-/d/d-id/1336480?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Thousands of Jira instances remain vulnerable to server-side request forgery (SSRF), a Web application vulnerability that redirects malicious requests to resources restricted to a server. The extent of this exposure underscores the impact of SSRF on applications in the public cloud.

SSRF poses a threat to cloud services due to the use of metadata API, which allows applications to access configurations, logs, credentials, and other information in the underlying cloud infrastructure. While the metadata API can only be accessed locally, an SSRF flaw makes it accessible from the Internet and could enable lateral movement and network reconnaissance.

The root cause of SSRF is a Web application needs to get resources from another domain to fulfill the request, but the input URL isn’t properly sanitized and could let attackers manipulate the destination. One of the reasons attackers like to find SSRF vulnerabilities is because they can pivot and see what’s behind the firewall. The implications of this bug vary depending on the environment, though SSRF could have potentially far-reaching effects for many companies: This is the same type of vulnerability that enabled this summer’s Capital One data breach.

To understand the effects of SSRF in the public cloud, researchers with Palo Alto Networks’ Unit 42 investigated known Jira SSRF flaw CVE-2019-8451 and analyzed its impact on six public cloud service providers (CSPs). This vulnerability, which can be exploited without authentication, was disclosed back in August. NVD shows CVE-2019-8451 was introduced in Jira v7.6, which was released in November 2017. Unit 42 found it affects versions back to v4.3, released in March 2011.

“What was especially significant was what the attackers had access to and how long the vulnerability had been out there,” says Jen Miller-Osborn, deputy director of threat intelligence at Unit 42. The fact an exploit would have worked as far back as 2011 “was concerning.”

A patch was immediately released for the vulnerability in August. However, software like Jira, which is closely integrated with business processes, is rarely the first to receive an update.

“Sometimes, with things like this, it’s in part just because you can’t have downtime,” Miller-Osborn explains. System administrators would often rather delay the patch than disrupt business operations, putting critical systems at risk. “This highlights the danger the organization is accepting if they’re making the decision not to patch,” she says.

Calculating Exposure: Who Is Most at Risk?
Researchers started with a Shodan search, which revealed 25,000 Jira instances are currently exposed to the Internet. They chose six CSPs with the highest number of Jira deployments. The goal was to determine how many Jira instances were vulnerable to CVE-2019-8451 in the public cloud, the exploitability of those instances, and the number of hosts leaking metadata, they say.

The researchers’ vulnerability scanner found 7,002 Jira instances exposed to the Internet in these six selected public clouds. Forty-five percent of the 7,002 instances (3,152) are vulnerable to this CVE because they haven’t been patched or updated. More than half (56%) of these vulnerable hosts (1,779) leak cloud infrastructure metadata, the Unit 42 team explains in a blog post.

This leaked metadata ranges from source code and credentials to internal network configuration, and vulnerable firms include technology, media, and industrial companies. DigitalOcean customers have the highest rate of metadata leak (93%), followed by customers of Google Cloud (80%), Alibaba (71%), AWS (68%), and Hetzner (21%).

Microsoft Azure is the only CSP with zero metadata leak, researchers report, because its strict header requirement in metadata API effectively blocks all SSRF requests. It’s worth noting GCP also enforces header requirements in its latest metadata API (v1); however, attackers can still access metadata using legacy APIs if legacy API endpoints (v0.1 and v1beta1) aren’t disabled.

What Admins Can Do
To fix the problem of SSRF, developers should validate the format and pattern of user input before passing it to the application logic. For admins who only install and manage Web apps, there are a few preventive measures to take to lessen the damage of an SSRF flaw.

One of these is domain whitelisting. Most apps only need to communicate with a select few domains, including database and API gateways. Creating a whitelist for approved domains that an application is allowed to communicate with can cut down on services an attacker can hit.

Metadata API can be protected by CSPs, but if this kind of protection is not available, there are additional steps businesses can take to reduce the risk of metadata leak. One of these is enabling CSP metadata API security. Some CSPs have configurable options to secure metadata API. Companies can also create firewall rules inside VMs to block the IP of metadata API.

Related Content:

• Practical Principles for Security Metrics
• An Alarming Number of Software Teams Are Missing Cybersecurity Expertise
• Tushu, Take Twoshu: Malicious SDK Reappears in Google Play
• 13 Security Pros Share Their Most Valuable Experiences

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Home Safe: 20 Cybersecurity Tips for Your Remote Workers.”

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/cloud/analysis-of-jira-bug-stresses-impact-of-ssrf-in-public-cloud-/d/d-id/1336479?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

SQL injection errors are no longer considered the most severe or prevalent software security issue.

Replacing it at the top of the Common Weakness Enumeration (CWE) list of most dangerous software errors is “Improper Restriction of Operations within the Bounds of a Memory Buffer.” Cross-site scripting (XSS) errors rank second on the list, followed by improper input validation, information exposure, and out-of-bounds read errors. SQL injection flaws are now ranked sixth on the list of most severe security vulnerabilities.

The Department of Homeland Security’s Systems Engineering and Development Institute, operated by The MITRE Corp., this week released an updated top 25 CWE listing of software errors. The update is the first in eight years and ranks security vulnerabilities based on prevalence and severity.

The CWE team looked at a dataset of some 25,000 Common Vulnerabilities and Exposures (CVE) entries over the past two years and focused on security weaknesses in software that are both common and have the potential to cause significant harm. Issues that have a low impact or are rarely excluded were filtered out.

In the past, the compilers of the CWE list used a more subjective approach based on personal interviews and surveys of industry experts.

“We shifted to a data-driven approach because it enables a more consistent and repeatable analysis that reflects the issues we are seeing in the real world,” Chris Levendis, CWE project leader, said in a statement Wednesday. “We will continue to mature the methodology as we move forward.”

Lists like the CWE and the Open Web Application Security Project (OWASP)’s top software security vulnerabilities are designed to raise awareness of common security missteps among developers. The goal is to help developers improve software quality and to assist them and testers in verifying security issues in their code. But over the years, the entries in these lists have changed little, suggesting that developers are repeatedly making the same mistakes.

“This highlights the unfortunate reality that despite many efforts, security is not being embedded effectively enough within the developer community, or in enterprise assurance frameworks,” says Javvad Malik, security awareness advocate at KnowBe4. “It’s not that we are unaware of how to identify and remedy the issues or prevent them from occurring in the first place; there appears to be a culture where getting software shipped outweighs the security requirements,” he notes.

According to Ilia Kolochenko, founder and CEO of web security company ImmuniWeb, the new list and risk-ranking approaches make a lot of sense overall. However, some of the entries in the list are likely to cause some controversy, Kolochenko says.

Cross-site scripting errors, for example, while common are not particularly easy to exploit. “Successful exploitation of an XSS, unless it’s a stored one, always requires at least a modicum of social engineering and interaction with a victim,” he says.

One could potentially make similar comments about all other entries, arguing about the prevalence of the vulnerabilities in business-critical systems, ease of detection and exploitation, costs of prevention, and remediation time. “We will unlikely have a unanimous opinion on all of them,” Kolochenko says. “This is why it’s good to have different classifications and ratings that, once consolidated, provide a comprehensive overview of the modern-day vulnerability landscape.”

Related Content:

• Most Organizations Have Incomplete Vulnerability Information
• GitHub Becomes CVE Numbering Authority, Acquires Semmle
• Predicting Vulnerability Weaponization
• 8 Trends in Vulnerability and Patch Management

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Home Safe: 20 Cybersecurity Tips for Your Remote Workers.”

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/sql-injection-errors-no-longer-the-top-software-security-issue/d/d-id/1336481?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple