Endor Labs came out of stealth on Monday and launched its Dependency Lifecycle Management Platform, designed to ensure end-to-end security for open source software (OSS). The software addresses three key things—helping engineers select better dependencies, helping organizations optimize their engineering, and helping them reduce vulnerability noise.

The platform scans the source code and offers feedback to developers and security teams on what is potentially good and bad about the libraries. Based on this, developers can make better decisions on which dependencies or libraries to use, where to use them, and who should use them.

To read this article in full, please click here

Read More

For large deployments of Tenable, where Tenable.io is shared across geographical or business boundaries, you can leverage role-based access control (RBAC) to logically segment scan data or, where required, restrict access to its scan data. In this blog, we’ll explain the configuration required to implement RBAC successfully.

When Tenable.io is used by multiple users to build your vulnerability management program, there are two schools of thought.

Option 1: Let all users see every vulnerability, while allowing them to narrow their focus on a subset of assets using custom dashboards in conjunction with Tenable.io tag filters.

Option 2: Align closer to a zero trust model by leveraging role-based access control (RBAC) within Tenable.io to logically segment and restrict visibility to a subset of assets and/or resources. 

The first option is very simple to achieve so we won’t focus on it in this article. Instead we will focus on the second option and the configuration of RBAC best practices. All actions outlined below will need to be configured using a Tenable.io administrator account.

Full Tenable.io RBAC segmentation is controlled in multiple locations in the Tenable.io interface. These locations include segmentation based on the sensor network, user access control permissions and scan policy permissions. In each section we will outline why and how to implement these features.

We will use the following scenario to explain how to configure Tenable.io with RBAC. We will assume four regions/business units. Each region will manage their own scans, but will have no access to any other regions’ results or their associated scanners. Full administrators will have access across all regions for central reporting, visibility and configuration. Full access will be authorized to an API user to enable integration with third-party solutions.

Before configuring RBAC, we need to build the foundation it will be applied to. This includes network segmentation and tagging.

Sensor network segmentation

When leveraging a single Tenable.io container across multiple regions/divisions, a key issue you can face is overlapping IP addressing. To disambiguate between assets that have the same IP addresses across environments, use sensor networks in Tenable.io.

Tenable.io sensor networks allow you to segment regions/divisions for each environment, and assign scanners and/or scanner groups to each network. When an asset is scanned, the associated network is added to the asset’s details. You can filter assets by network or create dynamic tags based on a defined network. A scanner or scanner group can only belong to one network at a time.

In this scenario, we will be creating four sensor networks – one for each region – then we will deploy Nessus Scanners into each region/organization. 

Do this by following these steps:

     Menu > Settings > Sensors > Network > Add Network

In each region/organization you can then deploy one or more Nessus Scanners and/or Nessus Agents to their relevant sites. Scanners should always be deployed as close as is practical to the targets you want to scan. Once a Nessus Scanner is bound to a sensor network, any asset discovered or scanned by that scanner will be bound to that sensor network.

To ensure only the appropriate regions’ staff can see and schedule scans on their Nessus Scanner(s) it is important that the scanner permissions be updated to meet this requirement. You also need to make sure the correct role is assigned against the user, a topic we cover later.

As administrator, select the Nessus Scanner from the “Linked Scanner” page, go to the “Permissions” tab and ensure “Default” is set to “No Access” and assign the appropriate access required.

For a scanner deployed in Region One we would recommend: 

     Default=No Access, R1Users=Can Use, Administrators=Can Manage. 

Applying automatic tags based on sensor network

To leverage RBAC, filter dashboards and so on, we leverage tags within Tenable.io. Tags can be automatically assigned based on the sensor network.

In this scenario I have created a tag category called “Region” and then a value for each of the regions. The regional tags will be automatically applied based on the sensor network that the asset belongs to. Tags could be used to group targets associated with different business units, locations, remediation teams, and so on.

For example: 

     Tag Category “Region” with Values “One, Two, Three, and Four”

You can configure tag rules to automatically apply the relevant tags. For example, tag “Region:One” is to be applied to any asset where the sensor network is equal to “R1”.

This logic would be applied to each sensor network region (R1, R2, R3, R4.) Any asset discovered or scanned using a Nessus Scanner or a Nessus Agent would then automatically have the relevant tag assigned. (Note: The tag is applied to Nessus Agents after their next scheduled scan is processed – not when they are first linked to Tenable.io.)

RBAC configuration

RBAC is implemented as a combination of roles and permissions.

Roles:

Tenable RBAC is configured in multiple locations. RBAC will be heavily bound to the tagging model defined above. 

The recommendations in this section will cover settings for:

Settings > Access Control > Roles
Settings > Access Control > Permissions
Settings > Access Control > Groups
Settings > Sensors > Cloud Scanners > Permissions
Settings > Sensors > Linked Scanners > Permissions
Scans > Manage Scan Templates > {template} > User Permissions

In Tenable.io, roles allow you to manage privileges for major functions and control which resources users can access. When you create users, you must assign them roles that broadly determine the actions they can perform.

For this example, we want regions/business units to create their own scans so we will leverage the “Standard” role. If you want to lock that down further so only defined scan templates can be used, then “Scan Operator” is the better fit.

The recommended settings are based on the following persona matrix within a large organization:

Tenable.io built-in Roles :

Tenable RBAC is implemented as a combination of Roles and Permissions. To restrict visibility of assets and results, we will create four User Groups (R1Users, R2Users, R3Users and R4Users). Once the Role and Group(s) are defined you can create a Permission set for the users. 

In our scenario we will restrict the assets based on the tags we configured earlier.
Here’s an example: 

     “R1User” permissions are assigned to the ‘R1Users Group’

     Added Permissions: Can View, Can Scan, Can Use

     Assigned Objects: Region:One

Lastly we will create the user profiles and add them to their relevant User Group.
For example User “R1User” is created and added to the “R1Users” Group

(Note: For existing customers who are using access groups for their access management, Tenable.io is replacing access groups with permissions.)

It is important to remove the “All Assets” permission set, and remove any reference to “All Users” from any of the permission sets. This ensures that only administrators have visibility into all assets and that users will only be able to see their tags and relevant assets.

Based on the Persona Matrix, the following would be recommended:

Additional Permission changes:

To ensure all users can only access authorized data you will need to find the permission entry listed against “All Assets” objects and remove the “All Users” group. For the permission set, only users or groups who are authorized to view all assets should be listed.

Additional Role configuration options:

Tenable.io Roles can be further customized to control access to other capabilities. These include the ability to:

manage recast/accept rules for a vulnerability
view recast/accept rules
view capabilities in Tenable.one
create Exposure Cards in Tenable.one
manage Tags in Tenable.one

Note: The Tenable.io RBAC policies continue to be updated with further user controls.

Scan policy permissions

Outside of RBAC policies, a user/group can be given access to see scan results from within the scan policy permissions. To ensure that access to scan results is not exposed to unauthorized users, configure scan policies with the “Default:No Access” policy. If this is not in place and a scan policy is shared, then a restricted user can still click on the scan and see all the scan results. This is true for both vulnerability and web app scans.

How these RBAC controls will effect dashboards

When you log in with a restricted user, for example “R1User”:

Assets will be restricted to only those with the “Region:One” tag.
Vulnerabilities will be restricted to the assets with the “Region:One” tag.
When building dashboards or applying filters based on tags, you can only select the tags that have “Can Use” permissions on them.
Web application dashboards do not populate for restricted users. If they need to see scan results you can edit “Scan Permissions” to provide visibility.
In Lumin, the “Organizational CES” score and metrics are displayed. The “Business Context” section can then be configured with the tags the user has access to. “Business Context/Tag” can be used to focus any of the Lumin metrics onto the relevant regions/tags assets.

Lumin (top view shows organizational metrics)

Tags can be leveraged to show regional metric breakdown

Conclusion

Tenable.io has a robust RBAC capability that can enable you to apply restrictions on everything from the targets and associated weaknesses that a user can see, to the ability to create/schedule scans and what Nessus Scanners are available to them.

Tenable.io RBAC heavily leverages tagging to logically define boundaries that restrictions can be placed around. Make sure to use the automation logic in Tenable.io tags as much as possible to easily maintain the tags assigned against each target asset.

You can find more information here:

Tenable.io key enhancements : RBAC

Tenable.io key enhancements : Tagging

Read More

One of the oldest tricks in the cybercrime playbook is phishing. It first hit the digital scene in 1995, at a time when millions flocked to America Online (AOL) every day. And if we know one thing about cybercriminals, it’s that they tend to follow the masses. In earlier iterations, phishing attempts were easy to spot due to link misspellings, odd link redirects, and other giveaways. However, today’s phishing tricks have become personalized, advanced, and shrouded in new disguises. So, let’s take a look at some of the different types, real-world examples and how you can recognize a phishing lure.

Be Wary of Suspicious Emails

Every day, users get sent thousands of emails. Some are important, but most are just plain junk. These emails often get filtered to a spam folder, where phishing emails are often trapped. But sometimes they slip through the digital cracks, into a main inbox. These messages typically have urgent requests that require the user to input sensitive information or fill out a form through an external link. These phishing emails can take on many personas, such as banking institutions, popular services, and universities. As such, always remember to stay vigilant and double-check the source before giving away any information.

Link Look-A-Likes

A sort of sibling to email phishing, link manipulation is when a cybercriminal sends users a link to malicious website under the ruse of an urgent request or deadline. After clicking on the deceptive link, the user is brought to the cybercriminal’s fake website rather than a real or verified link and asked to input or verify personal details. This exact scenario happened last year when several universities and businesses fell for a campaign disguised as a package delivery issue from FedEx. This scheme is a reminder that anyone can fall for a cybercriminals trap, which is why users always have to careful when clicking, as well as ensure the validity of the claim and source of the link. To check the validity, it’s always a good idea to contact the source directly to see if the notice or request is legitimate.

Gone Whaling

Corporate executives have always been high-level targets for cybercriminals. That’s why C-suite members have a special name for when cybercriminals try to phish them – whaling. What sounds like a silly name is anything but. In this sophisticated, as well as personalized attack, a cybercriminal attempts to manipulate the target to obtain money, trade secrets, or employee information. In recent years, organizations have become smarter and in turn, whaling has slowed down. Before the slowdown, however, many companies were hit with data breaches due to cybercriminals impersonating C-suite members and asking lower-level employees for company information. To avoid this pesky phishing attempt, train C-suite members to be able to identify phishing, as well as encourage unique, strong passwords on all devices and accounts.

Spear Target Acquired

 Just as email spam and link manipulation are phishing siblings, so too are whaling and spear-phishing. While whaling attacks target the C-suite of a specific organization, spear-phishing rather targets lower-level employees of a specific organization. Just as selective and sophisticated as whaling, spear-phishing targets members of a specific organization to gain access to critical information, like staff credentials, intellectual property, customer data, and more. Spear-phishing attacks tend to be more lucrative than a run-of-the-mill phishing attack, which is why cybercriminals will often spend more time crafting and obtaining personal information from these specific targets. To avoid falling for this phishing scheme, employees must have proper security training so they know how to spot a phishing lure when they see one.

Spoofed Content

With so many things to click on a website, it’s easy to see why cybercriminals would take advantage of that fact. Content spoofing is based on exactly that notion – a cybercriminal alters a section of content on a page of a reliable website to redirect an unsuspecting user to an illegitimate website where they are then asked to enter personal details. The best way to steer clear of this phishing scheme is to check that the URL matches the primary domain name.

Phishing in a Search Engine Pond

 When users search for something online, they expect reliable resources. But sometimes, phishing sites can sneak their way into legitimate results. This tactic is called search engine phishing and involves search engines being manipulated into showing malicious results. Users are attracted to these sites by discount offers for products or services. However, when the user goes to buy said product or service, their personal details are collected by the deceptive site. To stay secure, watch out for potentially sketchy ads in particular and when in doubt always navigate to the official site first.

Who’s That Caller?

With new technologies come new avenues for cybercriminals to try and obtain personal data. Vishing, or voice phishing, is one of those new avenues. In a vishing attempt, cybercriminals contact users by phone and ask the user to dial a number to receive identifiable bank account or personal information through the phone by using a fake caller ID. For example, just last year, a security researcher received a call from their financial institution saying that their card had been compromised. Instead of offering a replacement card, the bank suggested simply blocking any future geographic-specific transactions. Sensing something was up, the researcher hung up and dialed his bank – they had no record of the call or the fraudulent card transactions. This scenario, as sophisticated as it sounds, reminds users to always double-check directly with businesses before sharing any personal information.

As you can see, phishing comes in all shapes and sizes. This blog only scratches the surface of all the ways cybercriminals lure unsuspecting users into phishing traps. The best way to stay protected is to invest in comprehensive security and stay updated on new phishing scams.

The post The Seven Main Phishing Lures of Cybercriminals appeared first on McAfee Blog.

Read More

This is a story of one piece of what is probably a complex employment scam. Basically, real programmers are having their resumes copied and co-opted by scammers, who apply for jobs (or, I suppose, get recruited from various job sites), then hire other people with Western looks and language skills are to impersonate those first people on Zoom job interviews. Presumably, sometimes the scammers get hired and…I suppose…collect paychecks for a while until they get found out and fired. But that requires a bunch of banking fraud as well, so I don’t know.

Read More

Schoenbohm accused of having maintained contacts with people involved with Russian security services

Read More

This blog was written by an independent guest blogger.

Welcome to the final episode in our blog series focused on Mobile Endpoint Security.  The first two episodes detailed the protections necessary to secure data accessed by remote workers (Endpoint security and remote work) and best practices for combating the threat of ransomware 5 ways to prevent Ransomware attacks). In this installment, we will highlight the need to extend your company’s Endpoint Detection and Response capabilities beyond traditional endpoints (servers, laptops, desktops) to include mobile devices to proactively prevent advanced threats and improve your company’s incidence response.    

The two previous blogs provided detail on the types of threats that target businesses across all verticals and presented evidence to establish the mobile device as the entry point for the significant percentage of these attacks.  As an example, Twilio recently published a blog detailing an attack that compromised their internal systems and customer data via a series of SMS messages to employees.  The bad actors mimicked login requests for SSO and Okta to socially engineer those employees that resulted in the need to engage a forensics firm to lead the ongoing investigation.  Logically, any efforts by that forensics firm specific to EDR, threat hunting and incident response should therefore also include the ability to research and respond to attacks that originate via mobile devices with similar capabilities to that of traditional EDR solutions.    

Therefore, we must examine the gap that exists in current EDR solutions as it relates to mobile devices along with the reasons why the traditional solutions in this space are so ill-equipped to operate in the mobile device ecosystem.  It stands to reason that the dominant players in this space such as Crowdstrike, SentinelOne, and CarbonBlack have addressed mobile with their solutions given the dependence on mobile devices by workers across all verticals. 

However, there are challenges that exist for their solutions due to the inherent architectures of the operating systems of traditional endpoints (Windows, MacOS) versus mobile (Android, iOS).  Primarily, the core difference is the lack of kernel access available to mobile devices which limits the efficacy of incident response, kill chain reconstruction, and proactive threat hunting for traditional EDR solutions.  

Without access to the kernel, a different strategy must be employed to effectively detect threats that exist across the mobile ecosystem of both your managed and unmanaged devices.  Specifically, the need exists for an agent tailored specifically for the challenges presented by mobile platforms, a streaming detection engine capable of analyzing mobile-specific telemetry, and ways of identifying anomalous mobile-unique behavior across thousands of data points collected from millions of mobile devices. 

These capabilities enable you to leverage your mobile fleet telemetry to build proactive protection policies, improve your threat hunting workflow, and quickly identify how attackers leverage sophisticated campaigns to target your organization.  The variable in this equation, that most directly influences your company’s ability to detect and respond to these threats, becomes the ability to provide domain-specific context via a comprehensive mobile ecosystem dataset.

To further explain the gap that exists in almost all companies’ incident response capabilities and make the need for mobile EDR more tangible, it is a useful exercise to detail a real-world threat.

SourMint

First things first, this example dispels the myth that the iOS App Store is completely safe.  SourMint, discovered by the security firm Snyk, is an advertising SDK that was found to be active in over 1,200 iOS apps that totaled roughly 300 million downloads per month.  The SDK contains malicious code that allows for access to PII on the affected device and sends that data to third-party servers.  Even more concerning is the SDK’s ability to obfuscate itself with its ability to detect debugging or proxy tools which likely enabled it to bypass Apple’s app review process. 

Now the part about how mobile EDR is necessary to secure your data from mobile apps that exhibit potentially malicious behavior.  In this example, traditional EDR solutions may not have visibility to the behaviors and capabilities of the SourMint threat.  Only an EDR solution capable of analyzing the SDK and querying the results of that analysis against a global dataset specific to mobile would allow for an organization to correlate the potentially malicious hosts that the SDK is using to exfiltrate data. 

And only a mobile EDR solution would then allow that incident response team to proactively hunt for the existence of other affected mobile apps that also connect to the same host(s) to determine whether a policy action needs to be taken.  And because the connections to those hosts are not exclusive to mobile, this intel is also needed to examine if other endpoints are connecting to the suspected hosts via their traditional EDR toolset.  

Without a mobile EDR solution, organizations have limited resources to evaluate the impact of a detected mobile threat and its potential ability to compromise laptops or desktops.  In the case of SourMint, a mobile EDR solution provides the ability to alert or denylist on any type of device that connects with the hosts used by the bad actors.       

Mobile EDR solutions are still in their beginning stages and feature parity with traditional EDR solution will continue to be a maturation process.  However, the importance of applying the methodology for EDR to mobile will only continue to increase as the world continues to go more and more mobile.  Delays in adoption not only present inherent risk to a company’s existing security posture but also introduce the concept of innovation debt that could be costly to overcome. 

To learn more about how AT&T and Lookout can help your organization with mobile EDR reach out to your assigned account team or click here to learn more.

Read More

Some of the malicious apps are able to evade detection and continue to make it onto legitimate app stores

Read More

Factors contributing to mental health challenges included poor culture and the stressful nature of the work

Read More