This new role of safeguarding cloud deployments requires an exceedingly rare set of technical and soft skills.

A team at a recent cloud-native industry event laughed out loud when they told us, "We just got out of a talk, and apparently we are now infrastructure security engineers." With the rampant layoffs in the tech industry, underlying the amusement of job titles is real uncertainty around expectations for thriving in that new role and associated ecosystem.

In the age of Kubernetes and cloud native application deployment, the infrastructure security engineer is a prize hire. But across dozens of job descriptions and practitioner interviews, we found that this role reflects an exceedingly difficult challenge: to be the best at both indirect influence and hard technical skills.

So what is infrastructure security engineering, anyway? The infrastructure or cloud security team sits at (no surprise) the infrastructure layer, versus the application layer. They are primarily concerned with deployment and the running cloud environment.

The first thing to understand about this role is how much the cloud security shared responsibility model requires of them. In the case of managed Kubernetes platforms, we can assume a general platform-as-a-service (PaaS) model. This implies a shared responsibility model that puts nearly the entire configuration of the cloud in the infrastructure security role's hands. In Google's own words, "For \[Google Kubernetes Engine\], you're responsible for protecting your worker nodes, including deploying patches to the OS, runtime and Kubernetes components, and of course securing your own workload."

But the shared responsibility model is just the start. No role exists in a vacuum, and the third most common requirement in this role, apart from vulnerability management and staying up to date on trends in the space, is imbuing best practices across other teams in the org. As one hiring manager put it, "Your primary responsibility will be to ensure that our engineering teams integrate security best practices into their workflows and deliver secure products and services."

There is an inherent friction in asking a development team to do anything that might slow down the flow of new features into production, even if it has been shown that teams baking security into their DevOps processes actually do deliver more quickly.

**What Infrastructure Security Engineers Need to Succeed**

What do hiring managers think will make candidates successful in the kind of role just described? Not surprisingly, the third most common requirement for this role — behind hands-on experience with cloud platforms and networking — is proficiency in scripting languages, combined with hands-on experience around any combination of infrastructure-as-code (IaC), HashiCorp's Terraform, and the continuous integration/continuous delivery (CI/CD) pipeline. Why? Because if you have never automated deployments with code, it will be impossible to share security best practices with the developers doing it on a daily basis.

The last common requirement in an infrastructure security role is an in-depth understanding of the end-to-end development pipeline. If a security engineer expects to keep up to speed on the latest in the cloud, influence development, and manage cloud vulnerabilities on a day-to-day basis, they need an understanding of efficiency, how it all works together, and how to prioritize.

Here are some more tips from our interviewees:

*   "If you are just looking at the cloud, don't forget Kubernetes. While it is deployed through managed cloud services more often than not these days, it cannot be addressed in the same way one would address vulnerabilities for cloud environments." — Director of cloud security
*   "Triage is critical. When my teams have failed in the past, it was usually because we kept chasing shiny things. By being disciplined and methodical about prioritization, we maintain confidence that we're working on the right problems at \[almost\] any given time." — Manager, infrastructure and IT security
*   "Don't underestimate engineering teams' interest in solving security problems. Empower them with data and context, and see how hungry they are to use it." — Manager, infrastructure and IT security

**Why This Could Be the Hardest Job**

Interestingly, in our research only one job description had a line item for "security reviews," where the role allowed the security team to say yes or no to development changes. This is telling in the context of other observations on the role of direct versus indirect influence over engineering and development; for example, the IaC knowledge is needed not for using it directly, but for being able to tell others how to use it.

Also, communication and mentoring were not listed among the most common job prerequisites, but half of the roles still had high expectations for this soft skill. This was especially true for the more senior positions.

Between the requirement to influence the development teams, the required knowledge of IaC tooling and automation, the need for communication and mentoring, and the near complete absence of formal security reviews, a view of the most successful infrastructure security professional begins to emerge. This person will have broad hands-on experience in the cloud ecosystem, as well as skills to influence and build credibility across skilled teams who are managing highly new, cutting-edge GitOps tools on a daily basis. That is a high bar, indeed!

The Infrastructure Security Engineer Is a Unicorn Among Thoroughbreds

The DDoS collective claims to be teaming up with ReVIL and Anonymous Sudan for destructive financial attacks in retaliation for US aid in Ukraine, but the partnerships (and danger) are far from verified.

The pro-Russian hacktivist collective known as Killnet claims to be working in concert with a resurgent form of the notorious ReVIL ransomware gang. The goal? To mount an attack on the Western financial system.

The group is warning that attacks are imminent, as in the next day or so; but it's unclear whether the threats amount to anything more than bluster and saber-rattling, particularly given Killnet's past track record of, at most, carrying out mildly disruptive distributed denial of service (DDoS) attacks.

Even so, in a video posted on a Russian Telegram channel on June 16, Killnet made ominous threats against the SWIFT banking system (famously targeted by Lazarus in 2018); the Wise international wire transfer system; the SEPA intra-Europe payments service; central banks in Europe and the US (i.e., the Federal Reserve); and other institutions.

"The post claims that threat actors from Killnet, REvil, and Anonymous Sudan will unite for the campaign," according to ZeroFox researchers, writing in a flash alert on the threat. "Killnet indicates that the attack is motivated by the US providing weapons to aid Ukraine, stating: 'repel the maniacs according to the formula, no money — no weapons — no Kiev regime.'"

**Killnet's New Besties: Real or Imaginary?**

When it comes to the claimed partnerships, Anonymous Sudan is an emergent DDoS player that targeted entities in France, Germany, the Netherlands, and Sweden earlier this year, ostensibly in retaliation for perceived anti-Islamic activity in each of these countries. However, despite this religious persona, Trustwave researchers in the past have tied Anonymous Sudan to Killnet, noting it could simply be a masked subsidiary.

As for ReVIL, which imploded in 2022 after a Russian takedown, evidence of a re-emergence is one day old: On June 15, a Telegram channel called, fittingly, "REvil," was created. It was used to circulate a shout-out ("Hello Killnet") that went on to be heavily re-posted in a Killnet-affiliated Telegram channel, according to ZeroFox.

"This is the only post in channel to date and no additional evidence substantiating the partnership has been observed," the researchers noted.

A previous whiff of ReVIL's resurrection came more than a year ago, when rumors surfaced that some members were regrouping — but nothing more came of it.

Killnet could be fabricating the ReVIL partnership to lend some heft and gravitas to its threats against some tough targets. While Killnet has successfully gone after big game before, such as the White House and SpaceX satellite comms in Ukraine, these had "limited impact, causing short service outages and disrupting access to information," ZeroFox researchers said. A ReVIL partnership that's more than a flight of fancy "would allow them greater access to vulnerability exploitation, network intrusion, and data exfiltration."

Absent that, "the \[threatened attacks\], if legitimate, are unlikely to result in mass or prolonged outages to Western banking infrastructure, despite the newly claimed relationships with REvil and Anonymous Sudan," they added.

Even so, the publicity push around a supposedly imminent financial catastrophe could be simply an effort to harry Western governments and financial institutions, ZeroFox concluded — or, given Killnet's penchant for shenanigans, just an attempt to garner attention and notoriety.

Killnet Threatens Imminent SWIFT, World Banking Attacks

MOVEit has created a patch to fix the issue and urges customers to take action to protect their environments, as Cl0p attacks continue to mount, including on government targets.

Yet another MOVEit Transfer vulnerability, CVE-2023-35708, was discovered this week by Progress Software, the third that the company has disclosed, alongside CVE-2023-34362 and CVE-2023-35036.

The issue itself, detailed in an advisory released June 15 by the company, is another SQL injection vulnerability that could potentially allow unauthenticated attackers to gain access into MOVEit's database. Should attackers present a payload into the MOVEit Transfer application endpoint, they could ultimately modify the database content. Progress Software is encouraging MOVEit Transfer customers to take immediate action to help harden their MOVEit Transfer environments, noting that it is "extremely important" that users act as quickly as possible. 

"As we continue to investigate the issue related to MOVEit Cloud and MOVEit Transfer that we previously reported, an independent source has disclosed a new vulnerability that could be exploited by a bad actor," according to a press statement.  

**Government Agencies Under Cl0P Attack**

The release of the advisory detailing the latest vulnerability comes on the heels of CISA disclosing that federal agencies were impacted by the transfer tool at the hands of the Cl0p ransomware gang — part of the ongoing glut of attacks using what was once a zero-day bug in the platform (the first issue patched). In a statement to CNN, Eric Goldstein, CISA’s executive assistant director for cybersecurity, said that CISA “is providing support to several federal agencies that have experienced intrusions affecting their MOVEit applications.”

Two Department of Energy victims have been named: 1) Oak Ridge Associated Universities, a not-for-profit research center, and 2) Waste Isolation Pilot Plant - a contractor which disposes atomic energy waste.

Cyberattacks involving the use of the MOVEit Transfer program have now affected several US government agencies, alongside many other companies and organizations, who are now dealing with the loss of stolen information, disrupted systems, and sometimes even the demands of ransom payments. The victim count could reach into the hundreds. 

Though there haven't been any indications that threat actors have yet exploited the new vulnerability, MOVEit has asserted that it is communicating with customers to protect and create safer environments. 

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

Third MOVEit Transfer Vulnerability Disclosed by Progress Software

Mobile users in the Middle East and Africa often download moneylending apps that ask for excessive permissions — an all too common issue in an area where mobile-only is the norm and cyber awareness is low.

Research emerged this week showing that mobile users in the Middle East and Africa are the third most-likely to install suspicious financial mobile apps — mainly in the form of apps purporting to offer microlending services, a popular practice in a region where many residents lack access to mainstream credit markets.

These "seemingly legitimate" financial mobile apps were found to request access to text messages, contacts and photos/videos before a loan can be provided. They then go on to collect personal data from users' smartphones as collateral in the case that the user delays a debt payment.

Unlike more legitimate microfinance options, these apps' operators ask permission to use the data collected from the smartphone in order to force the user to return the debt in various unscrupulous ways, according to Kaspersky's research. For instance, information can be dispatched to all the user's contacts informing them of the user's debt, accompanied by photos from the gallery.

"While users should certainly report any suspicious apps to Google, they also need to stay alert for apps that may ask for a little too much access to the device's resources. For example, why would a loan app need access to your camera, your photos, or other documents on your device? Always think carefully before giving permission to any app you've downloaded," says Chris Hauk, consumer privacy champion at Pixel Privacy.

**Cyber Maturity in Transition**

According to research by Kaspersky, throughout 2022 and the first quarter of 2023, 14% of installs of potentially unwanted mobile financial apps on Android phones were made by users in the Middle East, Turkey, Africa (META) region. Therefore, this region ranks third behind APAC and LATAM in terms of the number of installs of such apps.

There are several reasons that apps like these are making headway in the region. Paul Bischoff, consumer privacy advocate at Comparitech, points out that it's an emerging technology market, where mobile infrastructure an important and necessary tool that enables basic needs, and many users "are not prepared for the barrage of scams and malware on the Internet." For many, their mobile phone is their only computing device, their only banking outlet, their only communications link, and even their only TV.

In the case of the shady microlending apps, the fact that they're being used by people with few traditional financial options could translate to users more concerned with life goals than giving 100% attention to the apps' legitimacy and permissions. 

Another contributing factor is the lack of technology protections typically found elsewhere. For instance, even though Android holds a dominant market share of 78% in the Middle East and 80% in Africa, according to Kaspersky, Bischoff suspects some phones sold in the region may not come with access to standard Google services like the Play Store, leaving users to the vagaries of less-reputable app stores that are more likely to contain malware and other unwanted apps.

Meanwhile, Hauk says while Google does vet the apps it allows into the Google Play Store, the system is not specifically designed to check for apps like these over-permissioned lending apps, anyway.

**A Multifaceted Mobile Problem**

Tom Davison, senior director of engineering international at Lookout, notes that the challenge with mobile apps in the META region is multi-faceted, beyond just fully functioning apps being overzealous with the permissions they request, exposing user data. 

All the other mobile issues are present as well: Outdated versions of apps may contain known software vulnerabilities that can be exploited; and outright malicious versions of apps exist which may impersonate well-known brands, again putting users at risk. But the usual best practices, like only using trusted app stores, scrutinizing permissions requested by apps, and always applying software updates, are for now aspirational goals for many META users.

Davison notes, "The reality is, for most users, without some additional help, it can be very challenging to spot what is legitimate and what is not," especially if apps such as microlending offerings are potentially downloaded in a state of desperation, he adds.

To boot, awareness of bugs can be scattered, at best, especially given that in the Android ecosystem, it's up to every OEM to deploy its own patches, and the schedules can vary wildly between device-makers — it's a lot for a mobile-only, non-cyber-savvy person to keep up with. 

All of this underscores the need for a more institutional, private-sector, and security-company emphasis on boosting cyber fluency and maturity, awareness training, and vendor safety efforts in the region.

Dodgy Microlending Apps Stalk MEA Users, Highlighting Cyber Maturity Gaps

Threat groups created a fake security company, "High Sierra," with faux exploits and fake profiles for security researchers on GitHub and elsewhere, aiming to get targets to install their malware.

During the month of May, an unknown threat group created a malicious GitHub repository that claimed to contain a zero-day exploit for a vulnerability in the Signal messaging app. The attackers supported the credibility of the exploit by creating a fake security company — High Sierra Cyber Security — linked to a number of made-up profiles of security researchers.

That's according to research conducted by threat intelligence firm VulnCheck, which found that the level of effort that the attacker put into create a social presence around the fake security company and the fake exploits is on a whole other level compared to what researchers have seen in the past.

"They put in a decent amount of effort into building personas, if you will, for each of these characters — these actors that who would advertise the GitHub repositories with the actual malware," VulnCheck security researcher William Vu tells Dark Reading. "So they put a lot of time and effort into building, really, a fake security company, and that, to me, is kind of new."

Targeting security researchers is rare, but has a long history. In 2021, for example, Google's Threat Analysis Group (TAG) warned that North Korea-backed hackers had created a faux research blog and multiple fake Twitter profiles. Researchers would then be asked to collaborate on vulnerability research, and those who agreed would be sent a Visual Studio project file that would run custom malware to infect the target's system, according to Google TAG's analysis. Three months later, the Cybersecurity and Infrastructure Security Agency (CISA) issued an alert about the campaign.

A similar attack — also by North Korea — targeted security researchers by using LinkedIn accounts and acting as recruiters, according to research released in March by Mandiant.

The latest attack also uses social engineering to target the supply chain, says Mike Parkin, a senior technical engineer at Vulcan Cyber, a provider of enterprise cyber-risk remediation services.

"One of the core defenses against malicious packages is for developers to actually vet the package before they download and use it, and part of that vetting process is determining if the package was created by a trustworthy source, whether commercial or otherwise," he says. "If threat actors can do a good job of faking that, they have a better chance of getting a victim to download their package and then not give it as close of an inspection as they should."

**GitHub, WhatsApp, What's Next?**

VulnCheck contacted GitHub about the project hosting the fake exploit, and the page was taken down. A day later, however, the same group created a similar page advertising a WhatsApp zero-day exploit, VulnCheck's researchers stated in the advisory. That pattern continued, and each time the company notified GitHub of a new page, it was removed but a new project page would appear. Pages offering a purported Microsoft Exchange remote code execution (RCE) bug, a Discord zero-day RCE, and others continued the cat-and-mouse game, the company stated.

In each case, instead of an exploit, a Python file in the repository would — if run by the target — download an operating-system-specific binary. While most antivirus programs detected the Windows malware that the Python script loaded, only three of the 62 Linux host-based scanners detected that binary, VulnCheck stated.

The threat actor used a variety of social media profiles to push out links to the pages. While the technique has been used as a way to convince software developers to download vulnerable or malicious components as a way of infecting the supply chain, this attack seems more likely to gain access to security professionals' own research, Vu says.

"Security researchers and testers usually have their own research, and if I were going after security researchers this way, I would be looking to obtain their cache of real zero-day exploits, and any kind of corporate IP that they might have access to," he says.

**Not the Sharpest Tool in the Toolbox**

While companies should always educate their developers about the risks that come with online code and how to best vet projects and unknown developers to determine if they are legitimate, researchers need to learn to be wary too, says Erich Kron, security awareness advocate at KnowBe4.

"Running code that others have written, especially when available in free and open websites such as GitHub, always carries some risk," he said. "In this case, researchers looking at the code may even assume that the malicious parts are simply a piece of these zero days being disclosed, when in fact it's designed to infect their own systems."

For most security researchers, a little due diligence will go a long way. A little research would likely discover that the company behind the "security research" has no track record, and that the researchers have no history in the industry, says Vulcan Cyber's Parkin.

"If a package just appeared out of nowhere, and the developers all seem to be new on the scene? Red flags," he says. "The sad thing is that this will have some negative impact on newly active researchers who may not have any history yet, but it's also easy to tell the difference between someone who doesn't have a history because they're just getting started and someone who has no history because they don't exist."

Attackers Create Synthetic Security Researchers to Steal IP

Organizations need to prepare for security threats as summer holidays approach.

Summer is just around the corner, and every cybersecurity professional I know is braced for cybercriminals to take action. The Cybersecurity ad Infrastructure Security Agency (CISA), part of the Department of Homeland Security, warns that holidays are a period of heightened threat. That can be extrapolated to any time cybercriminals think IT security teams might be lean or preoccupied, such as the summer season, when workers typically take more time off and stay out of the office for longer.

Here are four top considerations to help IT security staff manage risks — even when they're short staffed with holidays and vacation schedules.

**1\. Beware of Taking Work and Hardware on Vacation**

From the malicious intentions of a thief to a well-intentioned passerby going through a device to reach its owner and seeing sensitive information, lost hardware can evolve from an inconvenience to a corporate reputation and compliance nightmare.

To avoid the risk of lost hardware, it's best practice for employees to leave company devices at home unless they need to work while traveling — especially when it comes to international travel. As a precaution in the event devices are lost or stolen, employees should keep any devices with company information locked. IT departments should mandate phishing-resistant multifactor authentication, require employees to change passwords at least every six months, implement stringent password requirements, or explore passwordless validation options.

**2\. Avoid Open Wi-fi and Public USB Ports**

While many employees are aware of the risks associated with using public Wi-Fi and charging ports, the convenience of sending a quick email from the airport or using public power outlets may be difficult to resist. It's essential to remain vigilant, because of the dangers of sneaky threat actors tapping into shared networks and infiltrating personal devices or corporate systems.

According to one survey, 40% of respondents had their information compromised while using public Wi-Fi. The Federal Communications Commission warns about "juice jacking," in which bad actors target travelers running low on battery power and load malware onto public USB charging stations to hack into electronic devices.

Work travel and quick check-ins while in transit make it difficult to completely avoid working in public. To avoid the security, compliance, and reputation risk of a hack, instruct employees on secure mobile working practices. Employees should use known, secure hotspots instead of connecting to public Wi-Fi. If Wi-Fi can't be avoided, they should use a virtual private network (VPN). Employees looking for a charge while on the go should only plug their chargers into AC power outlets, rather than public USB ports. This goes for company devices and personal devices that have access to company email or messaging applications, even if their primary use isn't for work.

**3\. Focus Security Training and Messaging About Holiday Cyber-Risks**

Many cyberattacks like ransomware happen on Friday afternoons, and if it's a holiday weekend, the risk is high. Threat actors rightly calculate that a distracted employee trying to wrap up their work week might inadvertently click a phishing link or a security team might be running with a skeleton crew because of vacation schedules. Due to this, organizations must especially fortify their defense posture and check crisis management/business continuity plans as we approach holiday weekends.

Companies should closely monitor networks and systems for suspicious activity by combining employee and AI-led strategies in order to maximize time and cost efficiency, allowing AI monitoring and data protection to fill in the gaps when IT teams are spread thin.

Security departments should also schedule security refresh trainings ahead of summer vacation season. Schedule thoughtfully to ensure employees have dedicated time to review security practices and absorb the information.

**4\. Now Is the Time for IT Security Teams to Mobilize**

It's necessary to develop plans to accomplish the preceding three steps and also ensure business can continue when an attack inevitably does occur. A business continuity plan will help you react appropriately and expeditiously in the event of an attack, thereby limiting the effects and scope of the crisis. Plans should include:

*   An outline of who needs to be involved and their responsibilities, with contingencies in place that account for staff vacation plans
*   Detection and initial analysis of the attack
*   Defining the scope of the attack
*   Determining the origination of the attack (who/what/where/when)
*   Determining if the attack has concluded or is ongoing
*   Determining how the attack occurred
*   Containing the impact and propagation of the attack
*   Eradicating the malware and vulnerabilities that may have permitted its ingress and propagation
*   Recovering data from hardened backups
*   Responding to regulatory and/or contractual obligations as a result of the breach

**Bad Actors Come Prepared, but So Can Companies**

Good security people prepare well. Relationships, training, awareness, technologies and incident response playbooks all help to manage and reduce risk. While long weekends and other time off are rarely true holidays for security professionals, there are steps we can take to prepare and protect our organizations, so employees can remain vigilant while also enjoying well-deserved time off.

Cybercrime Doesn't Take a Vacation

The new privileged access management and secrets management capabilities tackles access issues and secret sprawl across the cloud environment.

Hashi Corp expanded its identity-based security portfolio with new products for privileged access management and secrets management.

With organizations shifting more of their workloads to the cloud, they need to change how they handle privileged access management. Instead of relying on SSH keys and IP address-based security, HashiCorp Boundary enables secure user access across the cloud, the company said. A self-managed commercial offering of HashiCorp Boundary for secure remote user access, HashiCorp Boundary Enterprise relies on just-in-time credentials to provide lead-privileged access to users with single sign-on access to cloud infrastructure. The session recording capability provides an auditable record of all user and application actions so that security teams know what is happening within the environment.

Organizations are struggling with secret sprawl across different systems, tools, and environments. HashiCorp Cloud Platform (HCP) Vault Secrets provides simplified secrets management as a software-as-a-service offering. The new SaaS offering is designed for organizations that want to manage secrets with minimal overhead and cost, the company said. HCP Vault Secrets and secret syncing allow organizations to centrally manage secrets while allowing developers to use their existing cloud-native development workflows.

HCP Vault Secrets is currently in beta. There is a separate capability – Vault Secrets Operator for Kubernets – to synchronize Vault secrets to Kubernetes secrets and automatically rotate secrets without disrupting service. Vault Secrets Operator for Kubernetes is generally available for HCP Vault and Vault Enterprise.

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

HashiCorp Expands PAM, Secrets Management Capabilities

A few lines of code can help you prevent accidental exposure, manage sensitive information, and maintain different configurations for various environments.

**Question: How do I keep my API keys from becoming part of someone else's GitHub search?**

**Answer:** Storing API keys directly in your code is generally not recommended due to the potential security risks. If your code is ever shared or becomes publicly accessible, anyone who sees the API key can use it, potentially leading to abuse or a security breach.

Here are several ways to store API keys securely:

*   **Environment variables:** You can store API keys in environment variables on your machine and then access these variables from your code. This method has the advantage of keeping the keys out of your code. (They are in the environment where the code runs.) It also means that the keys can be different for different environments, such as your local machine, a development server, a production server, etc.
*   **Configuration files:** You can also store API keys in a separate configuration file that is not included in your code repository. This file should be added to your _.gitignore_ file to prevent it from being committed to your repository. Be sure to add appropriate file-level permissions to this configuration file to prevent unauthorized access. In your code, you would read the API keys from this file.
*   **Secrets management systems:** For larger applications or more sensitive data, you might consider using a secrets management system. These are specialized tools, such as AWS Secrets Manager, HashiCorp's Vault, and Google's Secret Manager, that help manage access to secrets like API keys.
*   **Environment-specific configuration services:** Platforms like Heroku and Netlify have specific features or services for setting environment variables, which can be used to store API keys.
*   **Encrypted storage:** If you need to store the API keys in a database or other storage system, you should encrypt them. This way, even if someone gains access to the storage system, they won't be able to use the keys without the encryption key.

Let's take a look at how to implement the first two, the lowest-overhead of these solutions, in secure coding. I've used Python as the example language for this, though any language will have similar concepts. The advantage of Python is its simplicity and ease of use, which together with its formidable data-handling capabilities make it ideal for most uses.

**To Use Environment Variables for Storing API Keys**

Environment variables allow you to store sensitive information, such as API keys, outside of your source code. They are accessible to the application during runtime and can be easily configured on different environments (e.g., development, staging, and production).

First, set the environment variable in your system or the platform where your application is running. In a Unix-based system, you can set an environment variable using the _export_ command:

% export API\_KEY=<your\_api\_key>

Next, access the environment variable in your application's code. For example, in Python, you can access the value of an environment variable using the _os_ module:

% python import os api\_key = os.environ\['API\_KEY'\]

**To Use External Configuration Files for Storing API Keys**

Another way for the beginning developer or data scientist to store API keys is via external configuration files. These can be very useful; however, you should exclude them from the repository using _.gitignore_ or the equivalent.

First, create a configuration file, such as _config.json_, and store the API key in it:

json { "api\_key": "<your\_api\_key>" }

Next, add the configuration file to your project's _.gitignore_ (or equivalent) to ensure it's not tracked by your version control system.

Finally, load the configuration file in your application's code to access the API key. For example, in Python, you can load a JSON configuration file and access the API key like this:

import json with open('config.json') as f

config = load(f) api\_key = config\['api\_key'\]

**Lock Up Your APIs**

By using either environment variables or external configuration files, you can better protect your API keys from accidental exposure, simplify management of sensitive information, and make it easier to maintain different configurations for various environments. You should enforce proper access controls on the environment variables and configuration files to prevent unauthorized access.

As your project grows in complexity (and importance), it may be advisable to move to platforms with innate capability, such as secrets management systems or environment-specific configuration services, for storing sensitive items. However, these quick solutions help you start off on a more secure footing.

How Do I Protect My API Keys From Appearing in Search Results?

Coalition ESS uses AI to generate dynamic risk scores to help organizations mitigate their most critical risks faster.

**SAN FRANCISCO** **— June 15, 2023** **—** Coalition, the world's first Active Insurance provider designed to prevent digital risk before it strikes, today announced the Coalition Exploit Scoring System (Coalition ESS), a unique vulnerability scoring system that helps risk managers mitigate potential cyber threats. Developed by Coalition Security Labs, the company's research and innovation center, Coalition ESS is a security risk prioritization scoring system that leverages real-time monitoring and dynamic scoring to enable businesses of all sizes to efficiently understand which vulnerabilities to patch first. 

"In cybersecurity, timing is everything. Thousands of new vulnerabilities are published monthly, and it’s nearly impossible for IT and security teams to quickly understand and address them all. Defenders need a more efficient way to sift through the noise and prioritize which vulnerabilities to remediate," said Tiago Henriques, Coalition's Head of Security Research. "With Coalition ESS, they have an early source of truth to evaluate which risks to prioritize mitigating _before_ an incident occurs."

Coalition ESS leverages artificial intelligence and large language modeling to scan the descriptions used within newly released CVEs (Common Vulnerabilities and Exposures) and compares them to previously published vulnerabilities to predict the likelihood of exploitability. The result is two probability scores: the Exploit Availability Probability, or the likelihood that code for an exploit will be publicly available, and the Exploit Usage Probability, or the likelihood that threat actors will use an exploit to execute an attack. These scores combined give security managers and IT professionals a prioritization list outlining which vulnerabilities pose the greatest threat, saving time and resources in an otherwise arduous decision-making process. 

Coalition ESS scores are dynamic, responding to changes in available exploit information, unlike the scores derived from the Common Vulnerability Scoring System (CVSS). Coalition ESS scores are available up to one week from the initial vulnerability announcement, unlike other systems where scoring a vulnerability can take anywhere from one week up to one month.

"We created Coalition ESS to prioritize our own vulnerability management efforts as we are often the first line of defense for hundreds of thousands of assets of our customers at scale. We use ESS to evaluate and notify our policyholders about which vulnerabilities have the highest potential to negatively affect them and, today, are releasing it to the broader community," continued Henriques. 

Coalition ESS is available today for public use at: ess.coalitioninc.com. To learn more about Coalition’s cybersecurity research and innovation center, Security Labs, visit: www.coalitioninc.com/security-labs.

Coalition Releases Security Vulnerability Exploit Scoring System

**BOSTON****,** **June 15, 2023** **/PRNewswire/ --** The vulnerability of subdomain takeover in Microsoft Azure continues to pose a threat, with researchers at Keytos discovering approximately 15,000 vulnerable subdomains each month using cryptographic certificates. This relatively common exploit allows cybercriminals to impersonate organizations, launch attacks, and display spam content through legitimate sites. Despite continuous attempts to contact and notify over 1,000 organizations about their domain issues, only 2% have taken action to address the problem.

Subdomain takeover occurs when a domain is left open after deleting an Azure website, providing cybercriminals with a backdoor to create fraudulent sites. These sites appear legitimate since they are hosted on forgotten domains, putting users at risk of credential theft through simple deception. To take preventative measures, Keytos has developed an automated tool called EZMonitor which scans and identifies vulnerable subdomains using certificate transparency logs and checking the availability of Azure-hosted websites. In its first month, EZMonitor identified over 30,000 vulnerable domains, most of which are relatively high-profile organizations that many would think have sophisticated cybersecurity teams within their organizations.

Hardly anyone is aware of the scale and magnitude of this vulnerability. 85% of Fortune 500 companies are currently utilizing Microsoft Azure and are objectively at risk. Microsoft's attempts to address the issue, their solutions like Defender for App Service Dangling DNS detection have not fully resolved the problem, leaving many organizations unknowing vulnerable. Unfortunately, most organizations have not taken the threat seriously, ignoring warnings or only removing the DNS entry without addressing the underlying vulnerability.

These takeovers have severe implications and potential consequences, including the theft of login credentials, legitimizing false information, and distributing malware. End-Users are mostly helpless against these attacks, but they can encourage their organizations to take the issue seriously. Site owners, on the other hand, can take measures to protect themselves. These include implementing certificate transparency monitoring, removing dangling DNS entries, and using Certificate Authority Authorization (CAA) records.

Urgent action is needed to address this critical issue and safeguard domains and users. Keytos' automated scanning tool, EZMonitor, provides an effective means of identifying vulnerable subdomains. It is crucial for organizations to prioritize security and take proactive measures to mitigate this threat.

Want to see if your sites are secure? Keytos offers a free domain scanning tool to examine your organizations' certificates https://portal.ezmonitor.io/

SOURCE Keytos LLC

Source

DARKReading