Blogs

Securing administrative access to the Netskope tenant is an important security control.  When Single Sign-On (SSO) is not an appropriate choice for some administrators, Multi-Factor Authentication (MFA) should be used.   Docs.netskope.com describes the process for enabling MFA for local Netskope admins who are not managed via SSO.  The default authenticator is Google Authenticator, but other ones can be used.   https://docs.netskope.com/en/multi-factor-authentication-for-netskope-admins.html   This article describes how to set up Microsoft Authenticator.   1) Enable MFA on tenant     2) Next time the tenant admin logs into Netskope tenant   3) Tenant admin presented with authenticator setup (note Google Authenticator default)   4) Admin opens Microsoft Authenticator app on device   5) Add Work or school account   6) Scan QR code from Microsoft Authenticator   7) Use Authenticator code when prompted to login to Netsk

This new “Notification portal” provides customers an early access, easy to consume view into product changes coming in the next Release and changes being released as part of dynamic updates that are not part of the regular release cycle. These changes can affect enforcement outcomes and an early access view gives customers sufficient time to plan for config optimisations.   The Portal provides a view of:-   -Future/Upcoming Release (For Example You can see changes coming in R100 on the portal now.)-Weekly Changes (These are changes pushed as part of dynamic updates on a weekly cadence.)-Current Release (For reference in case the user has missed changes in the current release.)-Previous Release (For historical reference.) Customer must use their Netskope Support account to access this portal.   In the current version notification portal provides the ability to view product updates/changes to App Connector, App Category and CCI. The portal also provides the abili

Solution Overview   Windows Autopilot Overview   Traditionally IT administrators spend a lot of time on building and customizing OS images, compatibility testing with various device makes and models etc. Every device typically goes through a re-imaging process with additional pre and post validation to make sure it is ready for use in the field. This process implies major cost and time effort. Windows Autopilot is a collection of Microsoft technologies working in concert that help to simplify and streamline the bulk deployment, setup, and configuration of Windows 10/11 devices in organization to ensure they are provisioned and locked down according to corporate standards. Autopilot also can be used for device reset, repurpose and recovery.    The following diagram shows a process overview of a typical device procurement and onboarding lifecycle:   Windows Autopilot enables customers to: Recognize company owned devices and associate them with appropriate enrol

What is attack surface management?    Attack surface management (ASM) is the continued discovery, classification, and monitoring of an organization's external assets. It is crucial that teams leverage the hacker mindset to look for attack vectors into the organization when performing ASM in order to prioritize the most risk prone assets for remediation. To get the most out of an ASM program, teams should leverage tactics techniques and procedures (TTP) in use by threat actors. Not only is this good practice to develop the hacker mindset but also determine the hygiene of the current security implemented by the organization. Risk in ASM typically comes from three common areas which are vulnerabilities, misconfigurations, and weak/default credentials. The goals of attack surface management are identifying and gauging the risk, and reducing the attack surface. Attack surface management aims to find what assets are being exposed by the applications, networks, and devices in your e

Introduction   I am super excited to announce that the Netskope security cloud can now be managed as code. "How is this possible?", you might ask. The answer is by using the newly released Terraform provider for Netskope. This has been in the works for some time now and is the first time our SSE platform has been integrated directly into an Infrastructure as Code tool. This will allow customers and partners to automate deployment of Netskope resources using Terraform. By taking a "Netskope as Code" strategy customers will be able to easily create, modify, and delete infrastructure inside of the platform. This first release has support for our ZTNA solution (Netskope Private Access or NPA) and includes resources and data sources for Private Access Publishers and Applications. Get ready to supercharge your NPA deployment by creating a simple, repeatable automated configuration.   What is "Infrastructure as Code" and why Terraform   Infrastructure as Code (IaC) is

  This article will cover how to configure Single-Sign-On (SSO) for the Netskope Cloud Exchange (CE) platform using Okta. This will allow you to manage administrator access to CE from purely within Okta, rather than configuring administrators on the platform manually. Cloud Exchange is different from the standard Netskope tenant you would have access to as a customer, and facilitates the exchange of information between your various security and operations platforms. For information on what Cloud Exchange is (including how to deploy it), please see here.   Create a new App Integration Log in to your Okta administrator console and from the left-side menubar, navigate to Applications > Applications.   Select Create App Integration. Select SAML 2.0 as the sign-in method and click Next. On the next screen, set the App name to be Netskope Cloud Exchange and provide an app logo if required. Click Next to proceed to the Configure SAML section.   Copy the Cloud Exc

  This article will cover how to configure Single-Sign-On (SSO) for the Netskope Cloud Exchange (CE) platform using Azure Active Directory (AAD). This will allow you to manage administrator access to CE from purely within AAD, rather than configuring administrators on the platform manually.   Cloud Exchange is different from the standard Netskope tenant you would have access to as a customer, and facilitates the exchange of information between your various security and operations platforms. For information on what Cloud Exchange is (including how to deploy it), please see here.   Create a new Enterprise Application Log into the Azure AD portal, and go to “Enterprise Applications”. You may need to search for this at the top of the portal. Click New application. Click Create your own application and name the application Netskope Cloud Exchange.   Select the 3rd option to create a non-gallery app: Integrate any other application you don’t find in the gallery.   Clic

To edit (tag) a single app, hover over the app on the main page and click the Edit tag icon. To tag multiple apps, select the checkbox in the top left corner for each app. Click the Edit tags icon in the top right corner of the page.   Tip: To select all apps shown on the page, click the Select All icon beside the Edit tags icon. In the Edit Tags dialog box, there are two dropdown lists for tagging the chosen apps. The left dropdown list allows you to specify whether the app is sanctioned or unsanctioned. The right dropdown list allows you to specify whether the app is consumer, departmental, or enterprise level. To create a custom tag or to remove a tag, use the field below the dropdown lists.

CVE-2021-44228 (Log4Shell or LogJam) is a recently discovered zero-day vulnerability in the ubiquitous Apache Log4j Java-based logging library. It was reported by the Alibaba Cloud Security team as an unauthenticated RCE vulnerability in Log4j 2.0-beta9 up to 2.14.1 and could allow a complete system takeover on vulnerable systems. The bug has received the maximum CVSS score of 10, reflecting its importance and ease of exploitation.    This logging library is widely used in enterprise applications from Apple, Twitter, Amazon, Tesla, CloudFlare, and products including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink for its rich feature set and ability to flexibly record log information. Even Ghidra, a popular reverse engineering tool from NSA, is vulnerable to this bug. Attackers can use the feature that is used to write error logs to construct special data request packets through this vulnerability and ultimately trigger the remote code execution.   Threat act

Check out our latest blog series on AWS Best Practices on Logging!   Although CloudTrail is a well-trodden subject for AWS Security, there were still a few interesting findings among a slice of our customer base:   Enable VPC flow logs: 81% of VPCs do not have VPC flow logging enabled, which will hinder incident response and investigations. Encrypt CloudTrail logs at rest: 91% of CloudTrail logs are not encrypted at rest. Encryption at rest supports data compliance controls and is easy to do. Ensure S3 bucket access logging is enabled for CloudTrail buckets: 41% of CloudTrail buckets do not have server access logging enabled. Logging should be enabled for all CloudTrail S3 buckets. Ensure CloudTrail logs are integrated with CloudWatch or a SIEM: 54% of CloudTrails are not integrated with CloudWatch. These should be reviewed to ensure they are integrated with a production log search service or SIEM.   If your AWS accounts fall into these c

Why create a brand new PPT meeting deck every time you host a User Group?! Check out our latest User Group PPT template attached below!       Every quarter our Community team will update this PPT to include the latest Netskope Community news & announcements, upcoming events, and product release information.   All you need to do is: Download the template Fill in your User Group information (leader head shots, updates, survey, etc.) Share at your next meeting   Last Updated: 9/15/2021

We just published another blog related to application risk from OAuth applications: Who Do You Trust? Challenges with OAuth Application Identity . This follows up on several other recent blogs related to OAuth: Who Do You Trust? OAuth Client Application Trends   New Phishing Attacks Exploiting OAuth Authorization Flows (Part 1)    In this blog, we discuss some of the challenges that aren't addressed by the OAuth protocol, specifically the challenges in identifying an OAuth application that a user is trusting with access to data or other resources.   The scenario is: A user or administrator or an organization is prompted whether to trust an application -- you see an application title (created by the developer) -- is it real or is it fake?    Unlike the more-established field of malware that utilize DNS, we have nothing akin to DNS registrars, passive DNS databases, certificate authorities, so it makes the task of identification and att

We just published A Real-World Look at AWS Best Practices: Networking, part 6 of our AWS Best Practices series, looking closer at networking configurations with NACLs and Security Groups with respect to inbound access from the Internet to RDP and SSH, as well as the use of Default Security Groups (not recommended).   In reviewing anonymized customer, we found opportunities to improve security: Use More Secure Remote Access: Replace security groups that allow inbound Internet access to remote admin ports with more secure methods to remotely administer EC2 instances. 4% of the security groups in use allow inbound Internet access for SSH or RDP.  Do Not Use Default Security Groups: Ensure that default security groups do not allow any traffic and are not used. 609 default security groups (1% of all security groups) are being used and allow traffic of some kind. Some additional, relevant material you may want to also read: It’s All About Access: Remote Access Statisti

The Ragnarok ransomware gang had been around since 2019, and suddenly ceased operations today, posting a universal decrypter and instructions on how do use it. What does this mean for the risk of ransomware? Not much. This week, we published a blog post about BlackMatter, a newcomer to the ransomware space. This is just the normal revolving door of ransomware operators, all following the same ransomware-as-a-service business model, using the same tactics, and trying to put controls in place so their affiliates don't target anyone that results in too much attention for the operators.   Netskope protects against ransomware using a multi-layered approach that includes signatures, machine learning, static heuristics, and sandbox analysis to prevent ransomware from making its way onto any of your endpoints. One of the most common ransomware delivery tactics we are actively blocking is ransomware delivered as next-stage payloads by malicious Microsoft Office Documents. Our Office Docum

In part 5 of our continuing series on AWS Best Practices, we cover real-world stats on storage, specifically public access on buckets and encryption of EBS volumes: https://www.netskope.com/blog/a-real-world-look-at-aws-best-practices-storage   One of the challenges is having a clean process to provision, secure, and continually monitor whether data storage such an S3 bucket should be public or private.   How does your organization manage this? - do you use tagging, resource groups, or accounts to identify whether buckets are expected to be private or public? - do you enforce that a bucket is completely public/private by using bucket level ACLs/policies rather than object-level? - do you have additional audit checks on the above?   Additionally, how do you look upon encryption at rest? Is it solely for compliance, so AWS keys are sufficient or do you use CMKs of your own for real data privacy?   Would love to hear comments on how customers are managing this crucial

We just published the first three parts of a multi-blog series on new phishing attacks that can exploit OAuth 2.0 authorization flows: https://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authorization-flows-part-1 https://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authentication-flows-part-2 https://www.netskope.com/blog/new-phishing-attacks-exploiting-oauth-authentication-flows-part-3   We believe there will be an increasing trend in phishing and other attacks that abuse the OAuth protocol itself in order to gain advantages such as: obtaining OAuth session tokens which bypass MFA and are practically permanent, as well as take advantage of quirks such as being able to spoof other applications easily.   This is based upon a Def Con 29 presentation given on August 7, 2021. Currently, there is more exposure for Microsoft O365/Azure users due to their implementation of the device authorization grant flow. However, much of the material applies to a

We recently published a blog, Operationalizing IP Allow Lists for Cloud Environments, talking about the process and phases for effective implementation of IP allow lists. IP allow lists have traditionally been difficult to maintain without getting quickly out of date. We'd love to hear about your experiences. Do you use IP allows lists? For what, in which contexts? What do you use to mitigate compromised credentials? MFA? IP allow lists? other? Does Netskope's proxy architecture help you implement more effective IP allow lists? Was the blog post helpful or too high-level? Would it be useful to have more prescriptive examples (code) ?

We recently published Who Do You Trust? OAuth Client Application Trends which looks at real-world trust of applications by users using Google Identity for authentication and approval. It highlights some of the common applications and permissions being requested.   Some questions for you: Are you aware of which OAuth client applications are being trusted by your users? Do you have good visibility into this data? Are you locking down your environment in any way e.g. not allowing users to grant consent or approve apps? What would help you understand and manage risk from oauth client applications?

Continuing our blog series on AWS Best Practices, we've published two additional blogs looking at real-world AWS environments and practices around IAM policies and password policies, along with easy steps you can take to reduce. Our findings include: - 4% of IAM policies grant full admin privileges - 47%-67% of IAM users are using inline or directly attached policies - 73% of account password policies have password length < 14 characters - 80% of IAM user accounts have a password reuse setting < 24 times   Here are some concrete steps that can be taken to reduce risk related to IAM Policies and Password Policies: Create IAM Policies and roles with only the minimum privileges necessary.  Inline policies should be replaced with managed roles that are centrally managed. IAM Policies should be attached to groups or roles, instead of users. Customize your AWS Password Policy and do not use the default. Increase the password length to at least 14, and set the pass

Our latest blog post shares stats that show the amount of malware delivered via cloud apps continues to increase. Cybercriminals are deliberately abusing popular cloud apps for malware delivery to exploit trust and blend in. https://www.netskope.com/blog/cloud-and-threat-report-cloudy-with-a-chance-of-malware   Netskope can scan downloads for malicious content whether they originate from a cloud app or traditional web infrastructure. To ensure that your users are protected, create a "Threat Protection Profile" policy that scans all categories and all activities and blocks malicious content.  This policy covers all cloud and web activities to ensure complete protection, no matter which delivery method an attacker targeting your users chooses.      Every malware alert will contain the field "traffic_type" which indicates whether the alert is from a "CloudApp" or the "Web".  You can search SkopeIT for all cloud malware alerts: traffic_type = 'CloudApp' and (

In our latest blog, we explore IAM best practices and AWS and highlight two findings:   The majority of organizations don't enforce access key rotation for their IAM users. The majority of organizations aren't deleting inactive IAM accounts. We access keys that were nearly a decade old and many IAM accounts that hadn't been used in over a year, exposing a lot of risk surface that can likely be locked down.  How can you identify these old access keys and inactive IAM accounts? We have two Security Assessment rules that can help:   Remove/disable inactive user accounts within 90 days   Remote access: Ensure access keys unused for 90 days or greater are disabled   Once the rules have run, you will see the results in your compliance report.   Oops, I have a couple of  users in this AWS account that require some cleanup! I'll just follow the remediation guidance to ensure those two rules are marked green next time around. 

The blog post shares the details of our analysis:  https://www.netskope.com/blog/a-real-world-look-at-aws-best-practices-root-accounts   The Netskope Security Cloud makes it easy for you to check if your users are following these best practices, following the CIS AWS Foundations Benchmark. You can find and enable the four rules by searching for "Root" under the CIS AWS Foundations Benchmark profile.    If you have already enabled the CIS AWS Foundations Benchmark profile, you can view the results across your company.  Search "root" under the "Rule Name" filter to identify the four rules and check your results.