FreshRSS

🔒
❌ About FreshRSS
There are new available articles, click to refresh the page.
Before yesterdaySecurity – Cisco Blog

ESG’s Report on the Role of XDR in SOC Modernization

By Bob Stockwell

Extended Detection and Response, or XDR, the cybersecurity topic that dominated the RSA conference 2022 show floor with multiple vendors, has been getting a lot of attention lately, and for good reason. A connected, unified approach to detection and response promises to give security professionals all the tools and capabilities they need to address the ever-growing attack surface.

At Cisco, we wanted to get an independent view of what XDR means to a security operations audience, so we partnered with ESG on a survey conducted in April 2022 of 376 IT cybersecurity professionals in North America, which explored some key questions and trends for security operations centers as it relates to XDR. This new eBook, SOC Modernization and the Role of XDR, provides insights into the survey. Unsurprisingly, 52 percent of organizations surveyed believe that security operations are more challenging than just two years ago, and it’s clear cybersecurity professionals are looking for the next architecture to solve these challenges.

81% dealing with cybersecurity skills shortage: Source: ESG Research Study, SOC Modernization and the Role of XDR, June 2022

More Threats, More Data, More Action

The distributed nature of the network is resulting in more data from multiple control points. The survey showed that while 80 percent of organizations are already using more than 10 data sources as a part of their security operations, they want even more as they realize the value of being able to aggregate, normalize, correlate, and contextualize data so they can take better actions faster. At the same time, 81 percent say that they have been impacted by the cybersecurity skills shortage, and more data without the capabilities and skills in place to act will only diminish the ability to address threats.

To help fill those skills gaps, improved threat detection playbooks and incident prioritization will be critical aspects of the security operations strategy. Another key tool widely recognized as important in building a foundation is the MITRE ATT&CK framework that can help your teams focus and understand adversary tactics and techniques based on real-world observations.

While a common industry definition remains elusive, one thing is clear: XDR will play a critical role in the modernization of the security operations center. Determining how it will help your security operations team, and which partners to work with as you build out your XDR approach, will determine your level of success.

Redefining simplicity and efficiency with XDR

You need XDR to transform your infrastructure from a series of disjointed solutions into a fully integrated ecosystem that gets you to your outcome more effectively and efficiently. Cisco has built XDR capabilities into the broad portfolio of our security products and easily integrates with existing solutions in your environment using open APIs. After you’ve read the ESG SOC Modernization and the Role of XDR eBook, we invite you to take a look at the Cisco XDR Buyer’s Guide, which outlines five key elements of XDR done right and provides some questions to ask as you consider which vendors you want to work with in building out your security strategy. Don’t wait to start planning how XDR will help your security operations team.

Source: ESG Research Study, SOC Modernization and the Role of XDR, June 2022

See XDR done right:

Cisco XDR Buyer’s Guide

Cloud Security Resources and Guidance

By Ryan Morrow

This article was coauthored by Dan Maunz and Ryan Morrow, both Security Program Managers in the Security & Trust Organization at Cisco


The purpose of this document is to provide the reader with a high-level overview of cloud delivery models, introduce the different deployment scenarios in which cloud services can be operated in, and highlight the risks to an organization when deploying and operating a cloud environment. The final section of this document contains references to publicly available material on general security guidance for cloud environments, links to vendor-specific security guidance, and Cisco resources that can be leveraged to secure cloud environments.

Primary cloud delivery models include: 

  • Software as a Service (SaaS) – SaaS vendors deliver software applications over the internet.
  • Infrastructure as a Service (IaaS) – IaaS vendors deliver IT infrastructure services such as servers, data centers, storage, and networking over the internet.
  • Platform as a Service (PaaS) – PaaS vendors deliver the platform and tools to develop software applications.

Cloud deployment models include:

  • Public – Available to the public, data is created and/or stored on the service provider infrastructure who administers pool resources. These resources can be free or pay per use via the internet.
  • Private – As the name suggested, this option consists of cloud computing resources used exclusively by one business or organization. It can be hosted on premises or by a provider, but the services and infrastructure are always maintained on a private network. Private clouds are often used by financial institutions, government agencies and other organizations that require more control of their environment.
  • Hybrid – This deployment option combines private computing resources and public services.

These new cloud-based business models offer many of the benefits noted above, but they also come with potential risks:

  • Financial – cost overruns, impact on business return on investment (ROI)
  • Privacy – entrusting the organization’s sensitive data to a third party
  • Compliance – inability to meet contractual, legal, and regulatory obligations
  • Security – access, misconfiguration
  • Performance and quality – degradation
  • Technical – inability of the business to adapt to dynamic technologies, incompatibility, and limitations on what and how much can be customized

Below are some best practices to help manage and mitigate these risks:

  1. Plan. Develop a cloud computing strategy that is aligned with your business strategy. This will help to manage investments and to deliver on business objectives while leveraging the benefits of a cloud service.
  2. Choose your cloud service provider (CSP) wisely. Perform vendor risk assessments for contractual clarity, ethics, legal liability, viability, security, compliance, availability, business resiliency, etc. Leverage independent audit reports to assess soundness of the CSP’s controls. Determine if the CSP has service providers they rely on to provide their services/solutions and scope accordingly.
  3. Adopt the cloud service delivery and deployment model that will facilitate achieving business objectives, minimize risk, and optimize the value of the cloud investment.
  4. Understand the shared security responsibility model defined by the CSP. The shared security model divides responsibility between the organization and the CSP. The model differs by CSP, so it is imperative to agree to clearly defined boundaries. Regardless of deployment, the customer is responsible for their own data, endpoints, identity, and access management.
  5. Do not store your encryption keys where your data is located. There are several methods to consider: storing keys on premises while data is in the cloud, separating the keys from your data through the use of virtual private clouds (VPC), or even utilizing commercial key managers located separately from your cloud ecosystem.
  6. Strategize not only for scalability but for availability. Establish redundancy by regions and zones.
  7. Deploy technical safeguards such as a Cloud Access Security Broker (CASB). CASB can be on-prem or cloud-based security policy enforcement points, placed between cloud service users and cloud service providers. It serves as an enforcement point of the enterprise’s security policies as users access cloud-based resources. CASB provides visibility to all cloud services in use, identifies risks, monitors data flowing in and out of the enterprise to the cloud, blocks threats from malware and APT attacks, provides audit trails and facilitates compliance.
  8. Establish an end-to-end cyclical risk assessment of the cloud project throughout its lifecycle. Mitigate risks as described throughout this document. Monitor, test, and repeat. 

General Cloud Security Guidance

This section contains general, vendor agnostic resources and guidance on the implementation of secure cloud computing environments and on maintaining a secure operating environment.

Cloud Security Alliance (CSA) Security Guidance for Critical Areas of Focus in Cloud Computing v4.0

https://cloudsecurityalliance.org/artifacts/security-guidance-v4/

Federal Trade Commission (FTC) Six steps toward more secure cloud computing

https://www.ftc.gov/business-guidance/blog/2020/06/six-steps-toward-more-secure-cloud-computing

NIST Cloud Computing Reference Architecture

https://www.nist.gov/publications/nist-cloud-computing-reference-architecture

Center for Internet Security (CIS) Shared Responsibility for Cloud Security: What You Need to Know

https://www.cisecurity.org/insights/blog/shared-responsibility-cloud-security-what-you-need-to-know

Vendor Specific Cloud Security Guidance

This section contains specific resources and guidance for configuring and maintaining a secure cloud environment for Amazon Web Services, Google Cloud Platform, and Microsoft Azure cloud platforms.

AWS Cloud Security:  Shared Responsibility Model

https://aws.amazon.com/compliance/shared-responsibility-model/

Google Cloud Platform (GCP): Exploring container security: the shared responsibility model in GKE

https://cloud.google.com/blog/products/containers-kubernetes/exploring-container-security-the-shared-responsibility-model-in-gke-container-security-shared-responsibility-model-gke

Microsoft Azure Shared Responsibility for Cloud Computing

https://azure.microsoft.com/en-us/resources/shared-responsibility-for-cloud-computing/

Cisco Cloud Security Solutions

This section contains specific Cisco products and resources that can be leveraged in cloud environments to enable enhanced management and monitoring of cloud environments.

How does Cisco secure the cloud?

https://www.cisco.com/c/en/us/products/security/cloud-security/index.html


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Per Mar Security remains resilient as threats evolve

By Cristina Errico

As an early adopter of Cisco Secure Endpoint, Per Mar Security Services has seen the product evolve alongside the threat landscape. According to Dan Turner, CIO at Per Mar, the evolution of the Cisco security portfolio has helped the company remain cyber resilient during the pandemic and beyond.

We recently spoke with Turner to discuss how Per Mar uses Cisco technology to rapidly detect and mitigate threats, while still enabling employees to work from wherever they need to — whether it’s a conference, job site, or home office.

Safeguarding future success

Per Mar Security provides physical security services to both homes and businesses, protecting roughly 75,000 customers across 16 U.S. states. The company began using Cisco Secure Endpoint almost a decade ago to defend against attacks on its various devices. Today, it’s the main point of defense in making sure the company’s endpoints are safe. Cisco Secure Endpoint integrates with the other security products in Per Mar’s environment via Cisco SecureX.

SecureX brings together disparate security technologies from both Cisco and third parties to provide unified visibility and control. “This allows us peace of mind to know that we have the whole Cisco Secure solution being an extra set of eyes for us and making sure our customers and end users all stay safe and secure,” says Turner.

Per Mar has roughly 3,000 employees using a variety of devices on the company’s network — from Windows machines to iOS and Android devices. “We have become very mobile over the years, so working off tablets and mobile devices is how we get business done,” Turner explains. “Finding a tool like Cisco Secure Endpoint that can work across all those platforms and give my team one pane of glass to manage everything has been hugely important for us.”

This capability has enabled Per Mar to continue to operate smoothly in the midst of the pandemic. The company leveraged its existing infrastructure to spin up virtual workspaces for all of its employees within a week so they could work securely from home.

“Our Cisco systems and security frameworks allowed Per Mar to move
quickly and safely to support our employees when the pandemic hit.”

Dan Turner, CIO, Per Mar Security Services

Even before the pandemic, Cisco Secure Endpoint was able to swiftly remediate malware that found its way onto Per Mar’s network when employees worked remotely to attend conferences, for example, or to tend to other off-site obligations.

Protecting critical services

Per Mar Security provides critical protection from hazards such as burglary and fires for homes, manufacturing facilities, hospitals, college campuses, and more. It also secures special events such as high-profile football games and political conventions. Reliable IT and security systems are imperative for this work. “Without the infrastructure we have, we simply can’t provide services for our customers,” says Turner.

In addition to quickly detecting and blocking threats, the Cisco Secure portfolio integrated through SecureX has also dramatically improved Per Mar’s threat hunting and investigation capabilities. Being able to rapidly analyze data from multiple Cisco tools together in one place has enabled the company’s security team to efficiently identify the origin of a compromise down to the exact device and behavior that caused it. This ensures that the root cause can be addressed in a timely manner — often within a single day or even just a few hours.

“All those analytics allow my team to stay nimble, adapt as threats evolve, and capture any zero-day exploits that are sitting out there,” says Turner. “With Cisco Secure Endpoint, our mean time to detection is measured in hours, if not minutes, versus months or years. Because of how it ties back to the rest of the security stack that we use from Cisco, my team is able to go back through and pinpoint compromised systems in record speed.”

Maintaining security resilience

As the threat landscape and work environments continue to shift with the emergence of hybrid work, Per Mar remains secure. Its multi-layered defense provides robust protection against the full range of threat vectors. “Our Cisco technologies are just as critical today as they were when the world stopped spinning,” says Turner.

We are honored to play such a significant role in Per Mar’s continued success. Find out how your organization can maintain security resilience in the face of constant change.

Watch video: Per Mar Security gains threat visibility with Cisco Secure Endpoint


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

A compelling story

By Michal Svoboda

This article is part of a series in which we will explore several features, principles, and the building blocks of a security detection engine within an extended detection and response (XDR) solution.

In this second installment, we will look at ways of structuring the presentation of machine-generated alerts, so that each alert offers a cohesive and compelling narrative, as if written by a human analyst, at scale and in realtime.

The challenge

In cyber security, we are used to two types of stories.

The first story is common for reports written by humans. It contains sections such as “impact,” “reproduction,” and “remediation” to help us understand what is at stake and what we need to fix. For example:

IMPACT: An SSH server which supports password authentication is susceptible to brute-forcing attacks.

REPRODUCTION: Use the `ssh` command in verbose mode (`ssh -v`) to determine supported authentication methods. Look for “keyboard-interactive” and “password” methods.

REMEDIATION: Disable unneeded authentication methods.

The second story comes from machine detections. It is much terser in content and sometimes leaves us scratching our heads. “Malware,” the machine says with little explanation, followed by a horde of gibberish-looking data of network flows, executable traces, and so on.

 

The challenge is now to get the best of both worlds: to enhance machine-generated alerts with the richness of human-written reports. The following sections explain how this can be approached.

How was it detected?

In our example of a report written by a human, the “reproduction” section would help us understand, from a factual perspective, how exactly the conclusions were derived.

On the other hand, the machine-generated horde of data provides evidence in a very nondescript way. We would need to be smart enough to spot or reverse-engineer what algorithm the machine was following on said data. Most security analysts do not wish to do this. Instead, they attempt to seek the first story type. “Surely, someone must have written a blog or something more descriptive about this already,” they would say. Then, they would copy-paste anything that looks like a searchable term – an IP address, domain, SHA checksum – and start searching it, either on a threat intelligence search site or even a general-purpose search engine.

Having such cryptic machine-generated alerts is leading us to our first two issues: first, when the story is incomplete or misunderstood, it may lead the analyst astray. For example, the security event might involve requests to communicate with an IP address, and the analyst would say, “This IP address belongs to my DNS server, so the traffic is legitimate.” However, the detection engine was really saying, “I suspect there is DNS tunnelling activity happening through your DNS server—just look at the volume.”

Second, when an analyst seeks explanations from elsewhere, the main function of an advanced detection engine — finding novel, localized, and targeted attacks — cannot work. Information on attacks is generally available only after they have been discovered and analyzed, not when they happen initially.

A common approach to remedy this situation is to include a short description of the algorithm. “This detector works by maintaining a baseline of when during the day a user is active and then reports any deviations,” a help dialog would say. “Okay, that’s clever,” an analyst would reply. But this is not enough. “Wait, what is the baseline, and how was it violated in this particular security event?” To find the answer, we need to go back to the horde of data.

Annotated security events

To mimic the “reproduction” section of the human-written report, our security events are enriched with an annotation—a short summary of the behavior described by the event. Here are a few examples of such annotated events:

 

In the first and second cases, the story is relatively straightforward: in the horde of data, successful communication with said hostnames was observed. An inference through threat intelligence associates these hostnames to the Sality malware.

The third line informs us that, on a factual basis, only a communication with an IP address was observed. Further chain of inferences is that this IP address was associated by a passive DNS mechanism to a hostname which is in turn associated to the Sality malware.

In the fourth event, we have an observation of full HTTP URL requests, and inference through a pattern matcher associates this URL to the Sality malware. In this case, neither the hostname nor the IP address is important to the detector.

In all these annotated events, an analyst can easily grasp the factual circumstances and what the detection engine infers and thinks about the observations. Note that whether these events describe benign, malicious, relevant, or irrelevant behavior, or whether they lead to true or false positives, is not necessarily the concern. The concern is to be specific about the circumstances of the observed behavior and to be transparent about the inferences.

What was detected?

When we eventually succeed in explaining the security events, we might not be finished with the storytelling yet. The analyst would face another dilemma. They would ask: “What relevance does this event have in my environment? Is it part of an attack, an attack technique perhaps? What should I look for next?”

In the human-written report, the “impact” section provides a translation between the fact-based technical language of “how” and the business language of “what.” In this business language, we talk about threats, risks, attacker objectives, their progress, and so on.

This translation is an important part of the story. In our previous example about DNS tunnelling, we might want to express that “an anomaly in DNS traffic is a sign of an attacker communicating with their command-and-control infrastructure,” or that “it is a sign of exfiltration,” or perhaps both. The connotation is that both techniques are post-infection, and that there is probably already a foothold that the attacker has established. Perhaps other security events point to this, or perhaps it needs to be sought after by the analyst.

When it is not explicit, the analyst needs to mentally perform the translation. Again, an analyst might look up some intelligence in external sources and incorrectly interpret the detection engine’s message. Instead, they might conclude that “an anomaly in DNS traffic is a policy violation, user error, or reconnaissance activity,” leading them astray from pivoting and searching for the endpoint foothold that performs the command-and-control activity.

What versus How

We take special attention not to mix these two different dictionaries. Rather, we express separately the factual observations versus the conclusions in the form of threats and risks. Inbetween, there are the various chains of inferences. Based on the complexity, the depth of the story varies, but the beginning and the end will always be there: facts versus conclusions.

This is very similar to how an analyst would set up their investigation board to organize what they know about the case. Here is an elaborate example:

 

In this case, from top to bottom:

  • Use of a domain generation algorithms (DGA) technique was inferred by observing communication to hostnames with random names.
  • Malicious advertising (malvertising) was inferred by observing communication with hostnames and by observing communication with IP addresses that have passive DNS associations with (the same) hostnames.
  • Presence of an ad injector was inferred by observing communication to specific URLs and inferred by a pattern matcher, as well as communication to specific hostnames.

In all points, the “what” and “how” languages are distinguished from each other. Finally, the whole story is stitched together into one alert by using the alert fusion algorithm described in the Intelligent alert management blog post.

Wrap-up

Have we bridged the storytelling gap between machine-generated and human-generated reports?

Threat detections need to be narrated in sufficient detail, so that our users can understand them. Previously, we relied on the human aspect—we would need to document, provide support, and even reverse-engineer what the detection algorithms said.

The two solutions, distinguishing the “what/how” languages and the annotated events, provide the bandwidth to transmit the details and the expert knowledge directly from the detection algorithms. Our stories are now rich with detail and are built automatically in real time.

The result allows for quick orientation in complex detections and lowers the time to triage. It also helps to correctly convey the message, from our team, through the detection engine, and towards the analyst, lowering the possibility of misinterpretation.

This capability is part of Cisco Global Threat Alerts, currently available within Cisco Secure Network Analytics and Cisco Secure Endpoint, and has been continually improved based on customer feedback. In the future, it will also be available in Cisco SecureX XDR.

Follow the series on Security detection with XDR

 


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Boosting your XDR Potential with Device Insights and Kenna Integrations

By Manasa Agaram

It’s a busy month for cybersecurity, with the return of in-person RSAC in San Francisco, followed by Cisco Live in very lively Las Vegas! With so much happening, and so many announcements from every security vendor out there, it can be hard to keep track of everything going on. Let us help give you the highlights from a Cisco SecureX perspective!

We have been busy this past year, with our acquisition of Kenna Security and our recent innovations around device insights – all helping to expand and strengthen SecureX and our extended detection and response (XDR) capabilities.

Device Insights

Let’s start with device insights. We know that correlation of incidents and alerts is a vital capability for every good XDR offering, but what about correlating and aggregating information about the devices themselves? With the growing number of devices in many customer environments there is also a growing number of products with information about those devices. This can cause duplicate records and multiple alerts from the same device – which means more potentially false positive incidents to investigate, and more headaches trying to manually correlate and connect device information. With device insights organizations can discover, normalize, and consolidate information about all the devices in your environment – so you can avoid duplicate alerts, and discover devices that may be sneaking through gaps in your security. Device insights gives you a comprehensive view into each device’s security posture and management status.

Kenna Integration

Now, a more insightful view of all the devices across your infrastructure is a must-have, but so is the ability to view and manage vulnerabilities across these endpoints. With Cisco’s acquisition of Kenna Security last year, and our on-going integration of Kenna offerings into the Cisco Secure portfolio, we’re continuing to fortify SecureX and our XDR capabilities with industry leading risk-based vulnerability management. Kenna vulnerability management has already started integrations with Cisco Secure Endpoint, providing vulnerability scores on the OS version, as well as any available fixes. On the SecureX side, Kenna integrations are being leveraged to automatically enrich threat detections with vulnerability information, and automatically create ticketing workflows for Kenna.VM customers using ServiceNow.

With these integrations, and more innovations planned for the near future, risk-based vulnerability management will become a cornerstone for all endpoint and XDR deployments.

Check out our recent blog posts for more information about device insights and Kenna and SecureX orchestration!

Visit us at RSAC at booth 6045 for Cisco Secure, and booth 6362 for Kenna, and at Cisco Live in the World of Solutions to learn more.

Security Resilience for a Hybrid, Multi-Cloud Future

By Jeetu Patel

Eighty-one percent of organizations told Gartner they have a multi-cloud strategy. As more organizations subscribe to cloud offerings for everything from hosted data centers to enterprise applications, the topology of the typical IT environment grows increasingly complex.

Now add the proliferation of hybrid work environments, the rapid ascendance of Internet of Things (IoT) devices, and an increasingly sophisticated and malicious cyber threat landscape, and it becomes immediately clear that protecting the integrity of your IT ecosystem is now a next-level problem.

In an unpredictable world, organizations everywhere are investing in initiatives that will infuse resilience into every aspect of their business, from finance to supply chains. To protect those investments, we believe they also need to invest in security resilience — the ability to protect your business against threats and disruption, and to respond to changes confidently so you can emerge even stronger.

This requires a next-level solution.

That’s why we’re building the Cisco Security Cloud — a global, cloud-delivered, integrated platform that secures and connects organizations of any shape and size. This cloud-native service is aimed at helping you protect users, devices and applications across your entire ecosystem. It will be a comprehensive, integrated set of services designed to scale with your business.

An open security platform that eliminates vendor lock-in

The Cisco Security Cloud will directly address these challenges by bringing together the depth and breadth of the Cisco security portfolio, and is:

  • Cloud-native and multi-cloud – Securely connecting users, devices, and IoT to systems, apps, and data – across hybrid environments, optimizing performance and providing a frictionless experience by placing security closer to users, their data, and their applications. 
  • Unified – Bringing together core capabilities including policy management, management consoles, and dashboards for better end-to-end security efficacy. 
  • Simplified – Reducing friction for users and IT by consolidating endpoint agents and having a relentless focus on user experience.
  • AI/ML-driven – Leveraging massive volumes of telemetry across our portfolio, from the devices and networks we protect, enabling better detection, altering, and automation to improve the efficacy of the platform. 
  • Open and extensible – Providing APIs for integration and to support a rich developer ecosystem and marketplace.

Join our innovative security journey

We have been on this journey for years. We at Cisco Secure have been delivering key components of this security cloud, and those solutions already protect 840,000 networks, 67 million mailboxes and 87 million endpoints for customers the world over.

And today at the RSA Conference, we’re taking the next step by announcing our latest innovations addressing four key areas:

The move to hybrid, multi-cloud environments

Today we are announcing Cisco’s turnkey Secure Access Service Edge (SASE) offering, Cisco+ Secure Connect Now, to simplify how organizations connect and protect users, devices, data, and applications, anywhere. Built on the Meraki platform, and available as a subscription, it unifies security and networking operations, as well as client connectivity and visibility into a single cloud-native solution, that can be set up in minutes.

The move to hybrid work

Cisco is continuing to build out continuous trusted access solutions that that constantly verify user and device identity, device posture, vulnerabilities, and indicators of compromise.  To evaluate risk after authentication, location information is critical, but we think GPS data is too intrusive. So today we are introducing a new patent-pending Wi-Fi Fingerprint capability (available in Public Preview this summer) to understand user location without compromising location privacy. We are also announcing new Session Trust Analysis capabilities to evaluate risk after login by using open standards for shared signals and events. We will unveil the first integration of this technology with a demo of Duo MFA and Box this week. 

Addressing advanced threats

As organizations become more interconnected as ecosystems, and attacks become more sophisticated and personalized, it is no longer adequate to evaluate risk and threats generically across the industry. Organizations need deeper levels of advice and expertise.  We are excited to launch the new Talos Intelligence On-Demand service, available now, offering custom research on the threat landscape unique to each organization. Talos Intelligence on Demand can assist with custom research, and brief our customers on the unique risks, threats, and mitigation strategies for their organizations.

The need for simplification

Simplification is critical to driving better security efficacy. To that end, we are excited to announce the new Cisco Secure Client (available this summer), combining AnyConnect, Secure Endpoint, and Umbrella, to simplify how administrators and users manage endpoints. This follows the launch of the new cloud-delivered Secure Firewall Management Center, which unifies management for both cloud and on-premise firewalls.

There is more work to be done, of course, and today’s announcements at the RSA Conference are the latest advances in support of this vision. We will continue working on all aspects of the Security Cloud to improve our customers’ security resilience in the face of unprecedented change and increasing threats. Because next-level problems deserve next-level solutions. 

 


 

We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

SecureX and Secure Firewall: Integration and Automation to Simplify Security

By Aditya Sankar

Cisco Secure Firewall stops threats faster, empowers collaboration between teams, and enables consistency across your on-premises, hybrid, and multi-cloud environments. With an included entitlement for Cisco SecureX, our XDR and orchestration platform, you’ll experience efficiency at scale and maximize your productivity. New streamlined Secure Firewall integrations make it easier to use SecureX capabilities to increase threat detection, save time and provide the rapid and deeper investigations you require. These new features and workflows provide the integration and automation to simplify your security.

 

Move to the Cloud

The entire suite of Firewall Management Center APIs is now available in the cloud. This means that existing APIs can now be executed from the cloud. Cisco makes this even easier for you by delivering fully operational workflows as well as pre-built drag-n-drop code blocks that you can use to craft your own custom workflows. SecureX is able to proxy API calls from the cloud to the SSE connector embedded in the FMC codebase. This integration between Firewall 7.2 and SecureX provides your Firewall with modern cloud-based automation.

 

Expedited Integration

We’ve dramatically reduced the amount of time needed to fully integrate Firewall into Securex. Even existing Firewall customers who use on-premises Firewall Management Center will be able to upgrade to version 7.2 and start automating/orchestrating in under 15 minutes — a huge time savings! The 7.2 release makes the opportunities for automating your Firewall deployment limitless with our built-in low code orchestration engine.

Previously Firewall admins had to jump through hoops to link their smart licensing account with SecureX which resulted in a very complicated integration process. With the new one-click integration, simply click “Enable SecureX” in your Firewall Management Center and log into SecureX. That’s it! Your Firewalls will automatically be onboarded to SecureX.

 

Firewall Admins shouldn't have to jump through hoops to connect smart licensing accounts with SecureX. This screenshot of the Firewall Management Center shows the new, uber-simple process of integrating Secure Firewall Management Center with SecureX. Onboarding Firewalls to SecureX has never been easier!

 

Built In Orchestration

Cisco Secure Firewall users now get immense value from SecureX with the orchestration capability built natively into the Firewall. Previously Firewall admins would have to deploy an on-premises virtual machine in vCenter to take advantage of Firewall APIs in the cloud which was a major hurdle to overcome. With the 7.2 release, orchestration is built right into your existing Firewall Management Center. There is no on-premises connector required; SecureX orchestration is able to communicate directly with Firewall APIs highlighting the power of Cisco-on-Cisco integrations.

 

Customizable Workflows

PSIRT Impact monitoring  

The PSIRT impact monitoring workflows helps customers streamline their patch management process to ensure their network is always up to date and not vulnerable to CVE’s. This workflow will check for new PSIRTs, determine if device versions are impacted, and suggest a fixed version to upgrade to. By scheduling this workflow to run once a week customers can be notified via email if there is any potential impact from a PSIRT.

Firewall device health monitoring  

This workflow will run every 15 minutes to pull a health report from FMC and proactively notify customers via email if any devices are unhealthy. This means customers can rest assured that their fleet of devices is operating as expected or be notified of things like high CPU usage, low disk space, or interfaces going down.

Expiry notification for time-based objects 

This workflow highlights the power of automation and showcases what is possible by using the orchestration proxy to use FMC API’s. Managing policy is always an on-going effort but can be made easier by introducing automation. This workflow can be run once a week to search through Firewall policies and determine if any rules are going to expire soon. This makes managing policy much easier because customers will be notified before rules expire and can make changes accordingly.

Response Action: Block URL in access control policy 

This workflow is a one-click response action available from the threat response pivot menu. With the click of a button a URL is added to an object in a block rule of your access control policy. This action can be invoked during an investigation in SecureX or from any browser page using the SecureX browser extension. Reducing time to remediation is a critical aspect of keeping your business secure. This workflow turns a multi-step policy change into a single click by taking advantage of Secure Firewall’s integration with SecureX.

 

Proven Results

A recent Forrester Economic Impact Study of Secure Firewall show that deploying these types of workflows in SecureX with Secure Firewall increased operational efficiency.

In fact, SecureX in combination with Secure Firewall helped to dramatically reduce the risk of a material breach. It’s clear that the integration of the two meant a significant time savings for already overburdened teams.

Holy operational efficiency, Batman- talk about simplifying the security experience! This snazzy little SecureX-themed infographic displays a Forrester TEI quote which reads, "Using SecureX in conjunction with Secure Firewall and Firewall Management Center enabled organizations to save up to an additional 77% of time spent on investigation and response."

We continue to innovate new features and workflows that prioritize the efficacy of your teams and help drive the security resilience of your organization.

Ready to add SecureX capabilities to your Firewall environment? Start here.

 


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

 

Black Hat Asia 2022 Continued: Cisco Secure Integrations

By Jessica Bair

In part one of our Black Hat Asia 2022 NOC blog, we discussed building the network with Meraki: 

  • From attendee to press to volunteer – coming back to Black Hat as NOC volunteer by Humphrey Cheung 
  • Meraki MR, MS, MX and Systems Manager by Paul Fidler 
  • Meraki Scanning API Receiver by Christian Clasen 

In this part two, we will discuss:  

  • SecureX: Bringing Threat Intelligence Together by Ian Redden 
  • Device type spoofing event by Jonny Noble 
  • Self Service with SecureX Orchestration and Slack by Matt Vander Horst 
  • Using SecureX sign-on to streamline access to the Cisco Stack at Black Hat by Adi Sankar 
  • Future Threat Vectors to Consider – Cloud App Discovery by Alejo Calaoagan 
  • Malware Threat Intelligence made easy and available, with Cisco Secure Malware Analytics and SecureX by Ben Greenbaum 

SecureX: Bringing Threat Intelligence Together by Ian Redden 

In addition to the Meraki networking gear, Cisco Secure also shipped two Umbrella DNS virtual appliances to Black Hat Asia, for internal network visibility with redundancy, in addition to providing: 

Cisco Secure Threat Intelligence (correlated through SecureX)

Donated Partner Threat Intelligence (correlated through SecureX)

Open-Source Threat Intelligence (correlated through SecureX)

Continued Integrations from past Black Hat events

  • NetWitness PCAP file carving and submission to Cisco Secure Malware Analytics (formerly Threat Grid) for analysis

New Integrations Created at Black Hat Asia 2022

  • SecureX threat response and NetWitness SIEM: Sightings in investigations
  • SecureX orchestration workflows for Slack that enabled:
    • Administrators to block a device by MAC address for violating the conference Code of Conduct
    • NOC members to query Meraki for information about network devices and their clients
    • NOC members to update the VLAN on a Meraki switchport
    • NOC members to query Palo Alto Panorama for client information
    • Notification if an AP went down
  • NetWitness SIEM integration with Meraki syslogs
  • Palo Alto Panorama integration with Meraki syslogs
  • Palo Alto Cortex XSOAR integration with Meraki and Umbrella

Device type spoofing event by Jonny Noble

Overview

During the conference, a NOC Partner informed us that they received an alert from May 10 concerning an endpoint client that accessed two domains that they saw as malicious:

  • legendarytable[.]com
  • drakefollow[.]com

Client details from Partner:

  • Private IP: 10.XXX.XXX.XXX
  • Client name: LAPTOP-8MLGDXXXX
  • MAC: f4:XX:XX:XX:XX:XX
  • User agent for detected incidents: Mozilla/5.0 (iPhone; CPU iPhone OS 11_1_2 like Mac OS X) AppleWebKit/602.2.8 (KHTML, like Gecko) Version/11.0 Mobile/14B55c Safari/602.1

Based on the user agent, the partner derived that the device type was an Apple iPhone.

SecureX analysis

  • legendarytable[.]com à Judgement of Suspicious by alphaMountain.ai
  • drakefollow[.]com à Judgement of Malicious by alphaMountain.ai

Umbrella Investigate analysis

Umbrella Investigate positions both domains as low risk, both registered recently in Poland, and both hosted on the same IP:

Despite the low-risk score, the nameservers have high counts of malicious associated domains:

Targeting users in ASA, UK, and Nigeria:

Meraki analysis

Based on the time of the incident, we can trace the device’s location (based on its IP address). This is thanks to the effort we invested in mapping out the exact location of all Meraki APs, which we deployed across the convention center with an overlay of the event map covering the area of the event:

  • Access Point: APXX
  • Room: Orchid Ballroom XXX
  • Training course at time in location: “Web Hacking Black Belt Edition”

Further analysis and conclusions

The device name (LAPTOP-8MLGXXXXXX) and MAC address seen (f4:XX:XX:XX:XX:XX) both matched across the partner and Meraki, so there was no question that we were analyzing the same device.

Based on the useragent captured by the partner, the device type was an Apple iPhone. However, Meraki was reporting the Device and its OS as “Intel, Android”

A quick look up for the MAC address confirmed that the OUI (organizationally unique identifier) for f42679 was Intel Malaysia, making it unlikely that this was an Apple iPhone.

The description for the training “Web Hacking Black Belt Edition” can be seen here:

https://www.blackhat.com/asia-22/training/schedule/#web-hacking-black-belt-edition–day-25388

It is highly likely that the training content included the use of tools and techniques for spoofing the visibility of useragent or device type.

There is also a high probability that the two domains observed were used as part of the training activity, rather than this being part of a live attack.

It is clear that integrating the various Cisco technologies (Meraki wireless infrastructure, SecureX, Umbrella, Investigate) used in the investigation of this incident, together with the close partnership and collaboration of our NOC partners, positioned us where we needed to be and provided us with the tools we needed to swiftly collect the data, join the dots, make conclusions, and successfully bring the incident to closure.

Self Service with SecureX Orchestration and Slack by Matt Vander Horst

Overview

Since Meraki was a new platform for much of the NOC’s staff, we wanted to make information easier to gather and enable a certain amount of self-service. Since the Black Hat NOC uses Slack for messaging, we decided to create a Slack bot that NOC staff could use to interact with the Meraki infrastructure as well as Palo Alto Panorama using the SecureX Orchestration remote appliance. When users communicate with the bot, webhooks are sent to Cisco SecureX Orchestration to do the work on the back end and send the results back to the user.

Design

Here’s how this integration works:

  1. When a Slack user triggers a ‘/’ “slash command” or other type of interaction, a webhook is sent to SecureX Orchestration. Webhooks trigger orchestration workflows which can do any number of things. In this case, we have two different workflows: one to handle slash commands and another for interactive elements such as forms (more on the workflows later).
  2. Once the workflow is triggered, it makes the necessary API calls to Meraki or Palo Alto Panorama depending on the command issued.
  3. After the workflow is finished, the results are passed back to Slack using either an API request (for slash commands) or webhook (for interactive elements).
  4. The user is presented with the results of their inquiry or the action they requested.

Workflow #1: Handle Slash Commands

Slash commands are a special type of message built into Slack that allow users to interact with a bot. When a Slack user executes a slash command, the command and its arguments are sent to SecureX Orchestration where a workflow handles the command. The table below shows a summary of the slash commands our bot supported for Black Hat Asia 2022:

Here’s a sample of a portion of the SecureX Orchestration workflow that powers the above commands:

And here’s a sample of firewall logs as returned from the “/pan_traffic_history” command:

Workflow #2: Handle Interactivity

A more advanced form of user interaction comes in the form of Slack blocks. Instead of including a command’s arguments in the command itself, you can execute the command and Slack will present you with a form to complete, like this one for the “/update_vlan” command:

These forms are much more user friendly and allow information to be pre-populated for the user. In the example above, the user can simply select the switch to configure from a drop-down list instead of having to enter its name or serial number. When the user submits one of these forms, a webhook is sent to SecureX Orchestration to execute a workflow. The workflow takes the requested action and sends back a confirmation to the user:

Conclusion

While these two workflows only scratched the surface of what can be done with SecureX Orchestration webhooks and Slack, we now have a foundation that can be easily expanded upon going forward. We can add additional commands, new forms of interactivity, and continue to enable NOC staff to get the information they need and take necessary action. The goal of orchestration is to make life simpler, whether it is by automating our interactions with technology or making those interactions easier for the user. 

Future Threat Vectors to Consider – Cloud App Discovery by Alejo Calaoagan

Since 2017 (starting in Black Hat USA – Las Vegas), Cisco Umbrella has provided DNS security to the Black Hat attendee network, added layers of traffic visibility previously not seen. Our efforts have largely been successful, identifying thousands of threats over the years and mitigating them via Umbrella’s blocking capabilities when necessary. This was taken a step further at Black Hat London 2021, where we introduced our Virtual Appliances to provide source IP attribution to the devices making requests.

 

 

Here at Black Hat Asia 2022, we’ve been noodling on additional ways to provide advanced protection for future shows, and it starts with Umbrella’s Cloud Application Discovery’s feature, which identified 2,286 unique applications accessed by users on the attendee network across the four-day conference.  Looking at a snapshot from a single day of the show, Umbrella captured 572,282 DNS requests from all cloud apps, with over 42,000 posing either high or very high risk.

Digging deeper into the data, we see not only the types of apps being accessed…

…but also see the apps themselves…

…and we can flag apps that look suspicious.

We also include risk downs breaks by category…

…and drill downs on each.

While this data alone won’t provide enough information to take action, including this data in analysis, something we have been doing, may provide a window into new threat vectors that may have previously gone unseen. For example, if we identify a compromised device infected with malware or a device attempting to access things on the network that are restricted, we can dig deeper into the types of cloud apps those devices are using and correlate that data with suspicious request activity, potential uncovering tools we should be blocking in the future.

I can’t say for certain how much this extra data set will help us uncover new threats, but, with Black Hat USA just around the corner, we’ll find out soon.

Using SecureX sign-on to streamline access to the Cisco Stack at Black Hat by Adi Sankar

From five years ago to now, Cisco has tremendously expanded our presence at Black Hat to include a multitude of products. Of course, sign-on was simple when it was just one product (Secure Malware Analytics) and one user to log in. When it came time to add a new technology to the stack it was added separately as a standalone product with its own method of logging in. As the number of products increased, so did the number of Cisco staff at the conference to support these products. This means sharing usernames and passwords became tedious and not to mention insecure, especially with 15 Cisco staff, plus partners, accessing the platforms.

The Cisco Secure stack at Black Hat includes SecureX, Umbrella, Malware Analytics, Secure Endpoint (iOS clarity), and Meraki. All of these technologies support using SAML SSO natively with SecureX sign-on. This means that each of our Cisco staff members can have an individual SecureX sign-on account to log into the various consoles. This results in better role-based access control, better audit logging and an overall better login experience. With SecureX sign-on we can log into all the products only having to type a password one time and approve one Cisco DUO Multi-Factor Authentication (MFA) push.

How does this magic work behind the scenes? It’s actually rather simple to configure SSO for each of the Cisco technologies, since they all support SecureX sign-on natively. First and foremost, you must set up a new SecureX org by creating a SecureX sign-on account, creating a new organization and integrating at least one Cisco technology. In this case I created a new SecureX organization for Black Hat and added the Secure Endpoint module, Umbrella Module, Meraki Systems Manager module and the Secure Malware Analytics module. Then from Administration à Users in SecureX, I sent an invite to the Cisco staffers that would be attending the conference, which contained a link to create their account and join the Blackhat SecureX organization. Next let’s take a look at the individual product configurations.

Meraki:

In the Meraki organization settings enable SecureX sign-on. Then under Organization à Administrators add a new user and specify SecureX sign-on as the authentication method. Meraki even lets you limit users to particular networks and set permission levels for those networks. Accepting the email invitation is easy since the user should already be logged into their SecureX sign-on account. Now, logging into Meraki only requires an email address and no password or additional DUO push.

Umbrella:

Under Admin à Authentication configure SecureX sign-on which requires a test login to ensure you can still login before using SSO for authentication to Umbrella. There is no need to configure MFA in Umbrella since SecureX sign-on comes with built in DUO MFA. Existing users and any new users added in Umbrella under Admin à Accounts will now be using SecureX sign-on to login to Umbrella. Logging into Umbrella is now a seamless launch from the SecureX dashboard or from the SecureX ribbon in any of the other consoles.

Secure Malware Analytics:

A Secure Malware Analytics organization admin can create new users in their Threat Grid tenant. This username is unique to Malware Analytics, but it can be connected to a SecureX sign-on account to take advantage of the seamless login flow. From the email invitation the user will create a password for their Malware Analytics user and accept the EULA. Then in the top right under My Malware Analytics Account, the user has an option to connect their SecureX sign-on account which is a one click process if already signed in with SecureX sign-on. Now when a user navigates to Malware Analytics login page, simply clicking “Login with SecureX Sign-On” will grant them access to the console.

 

Secure Endpoint:

The Secure Endpoint deployment at Blackhat is limited to IOS clarity through Meraki Systems Manager for the conference IOS devices. Most of the asset information we need about the iPhones/iPads is brought in through the SecureX Device Insights inventory. However, for initial configuration and to view device trajectory it is required to log into Secure Endpoint. A new Secure Endpoint account can be created under Accounts à Users and an invite is sent to corresponding email address. Accepting the invite is a smooth process since the user is already signed in with SecureX sign-on. Privileges for the user in the Endpoint console can be granted from within the user account.

Conclusion:

To sum it all up, SecureX sign-on is the standard for the Cisco stack moving forward. With a new SecureX organization instantiated using SecureX sign-on any new users to the Cisco stack at Black Hat will be using SecureX sign-on. SecureX sign-on has helped our user management be much more secure as we have expanded our presence at Black Hat. SecureX sign-on provides a unified login mechanism for all the products and modernized our login experience at the conference.

Malware Threat Intelligence made easy and available, with Cisco Secure Malware Analytics and SecureX by Ben Greenbaum

I’d gotten used to people’s reactions upon seeing SecureX in use for the first time. A few times at Black Hat, a small audience gathered just to watch us effortlessly correlate data from multiple threat intelligence repositories and several security sensor networks in just a few clicks in a single interface for rapid sequencing of events and an intuitive understanding of security events, situations, causes, and consequences. You’ve already read about a few of these instances above. Here is just one example of SecureX automatically putting together a chronological history of observed network events detected by products from two vendors (Cisco Umbrella and NetWitness) . The participation of NetWitness in this and all of our other investigations was made possible by our open architecture, available APIs and API specifications, and the creation of the NetWitness module described above.

In addition to the traffic and online activities of hundreds of user devices on the network, we were responsible for monitoring a handful of Black Hat-owned devices as well. Secure X Device Insights made it easy to access information about these assets, either en masse or as required during an ongoing investigation. iOS Clarity for Secure Endpoint and Meraki System Manager both contributed to this useful tool which adds business intelligence and asset context to SecureX’s native event and threat intelligence, for more complete and more actionable security intelligence overall.

SecureX is made possible by dozens of integrations, each bringing their own unique information and capabilities. This time though, for me, the star of the SecureX show was our malware analysis engine, Cisco Secure Malware Analytics (CSMA). Shortly before Black Hat Asia, the CSMA team released a new version of their SecureX module. SecureX can now query CSMA’s database of malware behavior and activity, including all relevant indicators and observables, as an automated part of the regular process of any investigation performed in SecureX Threat Response.

This capability is most useful in two scenarios:

1: determining if suspicious domains, IPs and files reported by any other technology had been observed in the analysis of any of the millions of publicly submitted file samples, or our own.
2: rapidly gathering additional context about files submitted to the analysis engine by the integrated products in the Black Hat NOC.

The first was a significant time saver in several investigations. In the example below, we received an alert about connections to a suspicious domain. In that scenario, our first course of action is to investigate the domain and any other observables reported with it (typically the internal and public IPs included in the alert). Due to the new CSMA module, we immediately discovered that the domain had a history of being contacted by a variety of malware samples, from multiple families, and that information, corroborated by automatically gathered reputation information from multiple sources about each of those files, gave us an immediate next direction to investigate as we hunted for evidence of those files being present in network traffic or of any traffic to other C&C resources known to be used by those families. From the first alert to having a robust, data-driven set of related signals to look for, took only minutes, including from SecureX partner Recorded Future, who donated a full threat intelligence license for the Black Hat NOC.

The other scenario, investigating files submitted for analysis, came up less frequently but when it did, the CSMA/SecureX integration was equally impressive. We could rapidly, nearly immediately, look for evidence of any of our analyzed samples in the environment across all other deployed SecureX-compatible technologies. That evidence was no longer limited to searching for the hash itself, but included any of the network resources or dropped payloads associated with the sample as well, easily identifying local targets who had not perhaps seen the exact variant submitted, but who had nonetheless been in contact with that sample’s Command and Control infrastructure or other related artifacts.

And of course, thanks to the presence of the ribbon in the CSMA UI, we could be even more efficient and do this with multiple samples at once.

SecureX greatly increased the efficiency of our small volunteer team, and certainly made it possible for us to investigate more alerts and events, and hunt for more threats, all more thoroughly, than we would have been able to without it. SecureX truly took this team to the next level, by augmenting and operationalizing the tools and the staff that we had at our disposal.

We look forward to seeing you at Black Hat USA in Las Vegas, 6-11 August 2022!

Acknowledgements: Special thanks to the Cisco Meraki and Cisco Secure Black Hat NOC team: Aditya Sankar, Aldous Yeung, Alejo Calaoagan, Ben Greenbaum, Christian Clasen, Felix H Y Lam, George Dorsey, Humphrey Cheung, Ian Redden, Jeffrey Chua, Jeffry Handal, Jonny Noble, Matt Vander Horst, Paul Fidler and Steven Fan.

Also, to our NOC partners NetWitness (especially David Glover), Palo Alto Networks (especially James Holland), Gigamon, IronNet (especially Bill Swearington), and the entire Black Hat / Informa Tech staff (especially Grifter ‘Neil Wyler’, Bart Stump, James Pope, Steve Fink and Steve Oldenbourg).

About Black Hat

For more than 20 years, Black Hat has provided attendees with the very latest in information security research, development, and trends. These high-profile global events and trainings are driven by the needs of the security community, striving to bring together the best minds in the industry. Black Hat inspires professionals at all career levels, encouraging growth and collaboration among academia, world-class researchers, and leaders in the public and private sectors. Black Hat Briefings and Trainings are held annually in the United States, Europe and Asia. More information is available at: blackhat.com. Black Hat is brought to you by Informa Tech.

Black Hat Asia 2022: Building the Network

By Jessica Bair

In part one of this issue of our Black Hat Asia NOC blog, you will find: 

  • From attendee to press to volunteer – coming back to Black Hat as NOC volunteer by Humphrey Cheung 
  • Meraki MR, MS, MX and Systems Manager by Paul Fidler 
  • Meraki Scanning API Receiver by Christian Clasen 

Cisco Meraki was asked by Black Hat Events to be the Official Wired and Wireless Network Equipment, for Black Hat Asia 2022, in Singapore, 10-13 May 2022; in addition to providing the Mobile Device Management (since Black Hat USA 2021), Malware Analysis (since Black Hat USA 2016), & DNS (since Black Hat USA 2017) for the Network Operations Center. We were proud to collaborate with NOC partners Gigamon, IronNet, MyRepublic, NetWitness and Palo Alto Networks. 

To accomplish this undertaking in a few weeks’ time, after the conference had a green light with the new COVID protocols, Cisco Meraki and Cisco Secure leadership gave their full support to send the necessary hardware, software licenses and staff to Singapore. Thirteen Cisco engineers deployed to the Marina Bay Sands Convention Center, from Singapore, Australia, United States and United Kingdom; with two additional remote Cisco engineers from the United States.

From attendee to press to volunteer – coming back to Black Hat as NOC volunteer by Humphrey Cheung

Loops in the networking world are usually considered a bad thing. Spanning tree loops and routing loops happen in an instant and can ruin your whole day, but over the 2nd week in May, I made a different kind of loop. Twenty years ago, I first attended the Black Hat and Defcon conventions – yay Caesars Palace and Alexis Park – a wide-eyed tech newbie who barely knew what WEP hacking, Driftnet image stealing and session hijacking meant. The community was amazing and the friendships and knowledge I gained, springboarded my IT career.

In 2005, I was lucky enough to become a Senior Editor at Tom’s Hardware Guide and attended Black Hat as accredited press from 2005 to 2008. From writing about the latest hardware zero-days to learning how to steal cookies from the master himself, Robert Graham, I can say, without any doubt, Black Hat and Defcon were my favorite events of the year.

Since 2016, I have been a Technical Solutions Architect at Cisco Meraki and have worked on insanely large Meraki installations – some with twenty thousand branches and more than a hundred thousand access points, so setting up the Black Hat network should be a piece of cake right? Heck no, this is unlike any network you’ve experienced!

As an attendee and press, I took the Black Hat network for granted. To take a phrase that we often hear about Cisco Meraki equipment, “it just works”. Back then, while I did see access points and switches around the show, I never really dived into how everything was set up.

A serious challenge was to secure the needed hardware and ship it in time for the conference, given the global supply chain issues. Special recognition to Jeffry Handal for locating the hardware and obtaining the approvals to donate to Black Hat Events. For Black Hat Asia, Cisco Meraki shipped:

Let’s start with availability. iPads and iPhones are scanning QR codes to register attendees. Badge printers need access to the registration system. Training rooms all have their separate wireless networks – after all, Black Hat attendees get a baptism by fire on network defense and attack. To top it all off, hundreds of attendees gulped down terabytes of data through the main conference wireless network.

All this connectivity was provided by Cisco Meraki access points, switches, security appliances, along with integrations into SecureX, Umbrella and other products. We fielded a literal army of engineers to stand up the network in less than two days… just in time for the training sessions on May 10  to 13th and throughout the Black Hat Briefings and Business Hall on May 12 and 13.

Let’s talk security and visibility. For a few days, the Black Hat network is probably one of the most hostile in the world. Attendees learn new exploits, download new tools and are encouraged to test them out. Being able to drill down on attendee connection details and traffic was instrumental on ensuring attendees didn’t get too crazy.

On the wireless front, we made extensive use of our Radio Profiles to reduce interference by tuning power and channel settings. We enabled band steering to get more clients on the 5GHz bands versus 2.4GHz and watched the Location Heatmap like a hawk looking for hotspots and dead areas. Handling the barrage of wireless change requests – enable or disabling this SSID, moving VLANs (Virtual Local Area Networks), enabling tunneling or NAT mode, – was a snap with the Meraki Dashboard.

Shutting Down a Network Scanner

While the Cisco Meraki Dashboard is extremely powerful, we happily supported exporting of logs and integration in major event collectors, such as the NetWitness SIEM and even the Palo Alto firewall. On Thursday morning, the NOC team found a potentially malicious Macbook Pro performing vulnerability scans against the Black Hat management network. It is a balance, as we must allow trainings and demos connect to malicious websites, download malware and execute. However, there is a Code of Conduct to which all attendees are expected to follow and is posted at Registration with a QR code.

The Cisco Meraki network was exporting syslog and other information to the Palo Alto firewall, and after correlating the data between the Palo Alto Dashboard and Cisco Meraki client details page, we tracked down the laptop to the Business Hall.

We briefed the NOC management, who confirmed the scanning was violation of the Code of Conduct, and the device was blocked in the Meraki Dashboard, with the instruction to come to the NOC.

The device name and location made it very easy to determine to whom it belonged in the conference attendees.

A delegation from the NOC went to the Business Hall, politely waited for the demo to finish at the booth and had a thoughtful conversation with the person about scanning the network. 😊

Coming back to Black Hat as a NOC volunteer was an amazing experience.  While it made for long days with little sleep, I really can’t think of a better way to give back to the conference that helped jumpstart my professional career.

Meraki MR, MS, MX and Systems Manager by Paul Fidler

With the invitation extended to Cisco Meraki to provide network access, both from a wired and wireless perspective, there was an opportunity to show the value of the Meraki platform integration capabilities of Access Points (AP), switches, security appliances and mobile device management.

The first amongst this was the use of the Meraki API. We were able to import the list of MAC addresses of the Meraki MRs, to ensure that the APs were named appropriately and tagged, using a single source of truth document shared with the NOC management and partners, with the ability to update en masse at any time.

Floor Plan and Location Heatmap

On the first day of NOC setup, the Cisco team walked around the venue to discuss AP placements with the staff of the Marina Bay Sands. Whilst we had a simple Powerpoint showing approximate AP placements for the conference, it was noted that the venue team had an incredibly detailed floor plan of the venue. This was acquired in PDF and uploaded into the Meraki Dashboard; and with a little fine tuning, aligned perfectly with the Google Map.

Meraki APs were then placed physically in the venue meeting and training rooms, and very roughly on the floor plan. One of the team members then used a printout of the floor plan to mark accurately the placement of the APs. Having the APs named, as mentioned above, made this an easy task (walking around the venue notwithstanding!). This enabled accurate heatmap capability.

The Location Heatmap was a new capability for Black Hat NOC, and the client data visualized in NOC continued to be of great interest to the Black Hat management team, such as which training, briefing and sponsor booths drew the most interest.

SSID Availability

The ability to use SSID Availability was incredibly useful. It allowed ALL of the access points to be placed within a single Meraki Network. Not only that, because of the training events happening during the week, as well as TWO dedicated SSIDs for the Registration and lead tracking iOS devices (more of which later), one for initial provisioning (which was later turned off), and one for certificated based authentication, for a very secure connection.

Network Visibility

We were able to monitor the number of connected clients, network usage, the persons passing by the network and location analytics, throughout the conference days. We provided visibility access to the Black Hat NOC management and the technology partners (along with full API access), so they could integrate with the network platform.

Alerts

Meraki alerts are exactly that: the ability to be alerted to something that happens in the Dashboard. Default behavior is to be emailed when something happens. Obviously, emails got lost in the noise, so a web hook was created in SecureX orchestration to be able to consume Meraki alerts and send it to Slack (the messaging platform within the Black Hat NOC), using the native template in the Meraki Dashboard. The first alert to be created was to be alerted if an AP went down. We were to be alerted after five minutes of an AP going down, which is the smallest amount of time available before being alerted.

The bot was ready; however, the APs stayed up the entire time! 

Meraki Systems Manager

Applying the lessons learned at Black Hat Europe 2021, for the initial configuration of the conference iOS devices, we set up the Registration iPads and lead retrieval iPhones with Umbrella, Secure Endpoint and WiFi config. Devices were, as in London, initially configured using Apple Configurator, to both supervise and enroll the devices into a new Meraki Systems Manager instance in the Dashboard.

However, Black Hat Asia 2022 offered us a unique opportunity to show off some of the more integrated functionality.

System Apps were hidden and various restrictions (disallow joining of unknown networks, disallow tethering to computers, etc.) were applied, as well as a standard WPA2 SSID for the devices that the device vendor had set up (we gave them the name of the SSID and Password).

We also stood up a new SSID and turned-on Sentry, which allows you to provision managed devices with, not only the SSID information, but also a dynamically generated certificate. The certificate authority and radius server needed to do this 802.1x is included in the Meraki Dashboard automatically! When the device attempts to authenticate to the network, if it doesn’t have the certificate, it doesn’t get access. This SSID, using SSID availability, was only available to the access points in the Registration area.

Using the Sentry allowed us to easily identify devices in the client list.

One of the alerts generated with SysLog by Meraki, and then viewable and correlated in the NetWitness SIEM, was a ‘De Auth’ event that came from an access point. Whilst we had the IP address of the device, making it easy to find, because the event was a de auth, meaning 802.1x, it narrowed down the devices to JUST the iPads and iPhones used for registration (as all other access points were using WPA2). This was further enhanced by seeing the certificate name used in the de-auth:

Along with the certificate name was the name of the AP: R**

Device Location

One of the inherent problems with iOS device location is when devices are used indoors, as GPS signals just aren’t strong enough to penetrate modern buildings. However, because the accurate location of the Meraki access points was placed on the floor plan in the Dashboard, and because the Meraki Systems Manager iOS devices were in the same Dashboard organization as the access points, we got to see a much more accurate map of devices compared to Black Hat Europe 2021 in London.

When the conference Registration closed on the last day and the Business Hall Sponsors all returned their iPhones, we were able to remotely wipe all of the devices, removing all attendee data, prior to returning to the device contractor.

Meraki Scanning API Receiver by Christian Clasen

Leveraging the ubiquity of both WiFi and Bluetooth radios in mobile devices and laptops, Cisco Meraki’s wireless access points can detect and provide location analytics to report on user foot traffic behavior. This can be useful in retail scenarios where customers desire location and movement data to better understand the trends of engagement in their physical stores.

Meraki can aggregate real-time data of detected WiFi and Bluetooth devices and triangulate their location rather precisely when the floorplan and AP placement has been diligently designed and documented. At the Black Hat Asia conference, we made sure to properly map the AP locations carefully to ensure the highest accuracy possible.

This scanning data is available for clients whether they are associated with the access points or not. At the conference, we were able to get very detailed heatmaps and time-lapse animations representing the movement of attendees throughout the day. This data is valuable to conference organizers in determining the popularity of certain talks, and the attendance at things like keynote presentations and foot traffic at booths.

This was great for monitoring during the event, but the Dashboard would only provide 24-hours of scanning data, limiting what we could do when it came to long-term data analysis. Fortunately for us, Meraki offers an API service we can use to capture this treasure trove offline for further analysis. We only needed to build a receiver for it.

The Receiver Stack

The Scanning API requires that the customer stand up infrastructure to store the data, and then register with the Meraki cloud using a verification code and secret. It is composed of two endpoints:

  1. Validator

Returns the validator string in the response body

[GET] https://yourserver/

This endpoint is called by Meraki to validate the receiving server. It expects to receive a string that matches the validator defined in the Meraki Dashboard for the respective network.

  1. Receiver

Accepts an observation payload from the Meraki cloud

[POST] https://yourserver/

This endpoint is responsible for receiving the observation data provided by Meraki. The URL path should match that of the [GET] request, used for validation.

The response body will consist of an array of JSON objects containing the observations at an aggregate per network level. The JSON will be determined based on WiFi or BLE device observations as indicated in the type parameter.

What we needed was a simple technology stack that would contain (at minimum) a publicly accessible web server capable of TLS. In the end, the simplest implementation was a web server written using Python Flask, in a Docker container, deployed in AWS, connected through ngrok.

In fewer than 50 lines of Python, we could accept the inbound connection from Meraki and reply with the chosen verification code. We would then listen for the incoming POST data and dump it into a local data store for future analysis. Since this was to be a temporary solution (the duration of the four-day conference), the thought of registering a public domain and configuring TLS certificates wasn’t particularly appealing. An excellent solution for these types of API integrations is ngrok (https://ngrok.com/). And a handy Python wrapper was available for simple integration into the script (https://pyngrok.readthedocs.io/en/latest/index.html).

We wanted to easily re-use this stack next time around, so it only made sense to containerize it in Docker. This way, the whole thing could be stood up at the next conference, with one simple command. The image we ended up with would mount a local volume, so that the ingested data would remain persistent across container restarts.

Ngrok allowed us to create a secure tunnel from the container that could be connected in the cloud to a publicly resolvable domain with a trusted TLS certificate generated for us. Adding that URL to the Meraki Dashboard is all we needed to do start ingesting the massive treasure trove of location data from the Aps – nearly 1GB of JSON over 24 hours.

This “quick and dirty” solution illustrated the importance of interoperability and openness in the technology space when enabling security operations to gather and analyze the data they require to monitor and secure events like Black Hat, and their enterprise networks as well. It served us well during the conference and will certainly be used again going forward.

Check out part two of the blog, Black Hat Asia 2022 Continued: Cisco Secure Integrations, where we will discuss integrating NOC operations and making your Cisco Secure deployment more effective:

  • SecureX: Bringing Threat Intelligence Together by Ian Redden
  • Device type spoofing event by Jonny Noble
  • Self Service with SecureX Orchestration and Slack by Matt Vander Horst
  • Using SecureX sign-on to streamline access to the Cisco Stack at Black Hat by Adi Sankar
  • Future Threat Vectors to Consider – Cloud App Discovery by Alejo Calaoagan
  • Malware Threat Intelligence made easy and available, with Cisco Secure Malware Analytics and SecureX by Ben Greenbaum

Acknowledgements: Special thanks to the Cisco Meraki and Cisco Secure Black Hat NOC team: Aditya Sankar, Aldous Yeung, Alejo Calaoagan, Ben Greenbaum, Christian Clasen, Felix H Y Lam, George Dorsey, Humphrey Cheung, Ian Redden, Jeffrey Chua, Jeffry Handal, Jonny Noble, Matt Vander Horst, Paul Fidler and Steven Fan.

Also, to our NOC partners NetWitness (especially David Glover), Palo Alto Networks (especially James Holland), Gigamon, IronNet (especially Bill Swearington), and the entire Black Hat / Informa Tech staff (especially Grifter ‘Neil Wyler’, Bart Stump, James Pope, Steve Fink and Steve Oldenbourg).

About Black Hat

For more than 20 years, Black Hat has provided attendees with the very latest in information security research, development, and trends. These high-profile global events and trainings are driven by the needs of the security community, striving to bring together the best minds in the industry. Black Hat inspires professionals at all career levels, encouraging growth and collaboration among academia, world-class researchers, and leaders in the public and private sectors. Black Hat Briefings and Trainings are held annually in the United States, Europe and Asia. More information is available at: blackhat.com. Black Hat is brought to you by Informa Tech.


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

How Cisco Duo Is Simplifying Secure Access for Organizations Around the World

By Jackie Castelli

At Cisco Duo, we continually strive to enhance our products to make it easy for security practitioners to apply access policies based on the principles of zero trust. This blog highlights how Duo is achieving that goal by simplifying user and administrator experience and supporting data sovereignty requirements for customers around the world. Read on to get an overview of what we have been delivering to our customers in those areas in the past few months.

Simplifying Administrator and End-User Experience for Secure Access 

Duo strives to make secure access frictionless for employees while reducing the administrative burden on IT (Information Technology) and helpdesk teams. This is made possible thanks to the strong relationship between our customers and our user research team. The insights we gained helped us implement some exciting enhancements to Duo Single Sign-On (SSO) and Device Trust capabilities.

Duo SSO unifies identities across systems and reduces the number of credentials a user must remember and enter to gain access to resources. Active Directory (AD) is the most popular authentication source connected to Duo SSO, accounting for almost 80% of all setups. To make Duo’s integration with AD even easier to implement, we have introduced Duo SSO support for multiple Active Directory forests for organizations that have users in multiple domains. Additionally, we added the Expired Password Resets feature in Duo SSO. It provides an easy experience for users to quickly reset their expired Active Directory password, log into their application, and carry on with their day. Continuing the theme of self service, we introduced a hosted device management portal – a highly requested feature from customers. Now administrators no longer need to host and manage the portal, and end users can login with Duo SSO to manage their authentication devices (e.g.: TouchID, security keys, mobile phone etc.) without needing to open IT helpdesk tickets.

We are also simplifying the administrator experience. We have made it easy for administrators to configure Duo SSO with Microsoft 365 using an out of the box integration. Duo SSO layers Duo’s strong authentication and flexible policy engine on top of Microsoft 365 logins. Further, we have heard from many customers that they want to deliver a seamless on-brand login experience for their workforce. To support this, we have made custom branding so simple that administrators can quickly customize their end-user authentication experience from the settings page in the Duo Admin Panel.

Device Trust is a critical capability required to enable secure access for the modern workforce from any location. We have made it easy for organizations to adopt device trust and distinguish between managed and unmanaged devices. Organizations can enforce a Trusted Endpoint policy to allow access only from managed devices for critical applications. We have eliminated the requirement to deploy and manage device certificates to enforce this policy. Device Health application now checks the managed status of a device. This lowers administrative overhead while enabling organizations to achieve a better balance between security and usability. We have also added out-of-box integrations with unified endpoint management solutions such as Active Directory domain-joined devices, Microsoft Intune, Jamf Pro and VMware Workspace ONE. For organizations that have deployed a solution that is not listed above, Duo provides a Device API that works with any enterprise device management system.

 Supporting Global Data Sovereignty Requirements 

To support our growing customer base around the world, Duo expanded its data center presence to  Australia, Singapore, and Japan in September last year. And now Duo is thrilled to announce the launch of the two new data centers in the UK and India. Both the new and existing data centers will allow customers to meet all local requirements, all while maintaining ISO27001 and SOC2 compliance and a 99.999% service availability goal.

The launch of the new data centers is the backbone of Duo’s international expansion strategy. In the last two years, Duo has met key international growth milestones and completed the C5 attestation (Germany), AgID certification (Italy) and IRAP assessment (Australia) – all of which demonstrate that Duo meets the mandatory baseline standards for use by the public sector in the countries listed above. Check out this Privacy Data Sheet to learn more about Cisco Duo’s commitment to our customer’s data privacy and data sovereignty.

Cisco Duo Continues to Democratize Security 

That is a summary of what we have been up to here at Cisco Duo in the past few months. But we are not done yet! Stay tuned for more exciting announcements at RSA Conference 2022 next week. Visit us at our booth at RSAC 2022 and World of solutions at Cisco Live 2022.

In the meanwhile, check out this on-demand #CiscoChat panel discussion with real-world security practitioners on how they have implemented secure access best practices for hybrid work using Duo. And if you do not want to wait, sign-up for a 30 day trial and experience how Duo can simplify secure access for your workforce.

 


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Revisiting the Session: The Potential for Shared Signals

By Nancy Cam-Winget

Sometimes in order to move forward effectively, it’s good to take stock of where we’ve been. In this blog, we’ll review a concept that has been foundational to networking and cybersecurity from the beginning: the session. Why focus on the session? As the philosophy of Zero Trust is adopted more broadly in the security industry, it’s important to understand the building blocks of access. The session is a fundamental component of access to any resource.  

To get things started, let’s start with a definition. A simple definition of a session might be: “a period of time devoted to a particular activity.” Not so bad, but the complexity for internet and network security springs from scoping the “particular activity.”  

The internet exists on top of a standardized suite of protocols that govern how data can be transmitted or exchanged between different entities. This suite, now generally referred to as the TCP/IP stack, is comprised of four distinct layers that delineate how data flows between networked resources. This is where the scoping of a session becomes obscure. The “particular activity” could refer to the network layer, which is responsible for establishing communications between the actual physical networks. Or, perhaps the activity refers to the Internet layer, which ensures the packets of data reach their destinations across network boundaries. The activity could also be the transport layer, responsible for the reliability of end-to-end communication across the network. It could also be referencing the application layer, the highest layer of the TCP/IP stack, which is responsible for the interface and protocols used by applications and users. For the familiar, these layers were originally defined in the OSI model.  

TC/IP Stack

This layering framework works well for establishing the distinct session types and how we can begin to protect them.  However, the rise of cloud-based services means we must now also look at how sessions are defined in relation to the cloud — especially as we look to provide security and access controls.  At the application layer, we now have client devices with web browsers and applications that communicate to a cloud service.  Additionally, cloud services can be one or a combination of SaaS, PaaS and IaaS, each defining their own session and thus access.   

With all the different classes of sessions, there are different mechanisms and protocols by which authentication and authorization are employed to eventually provide that access.  All sessions use some type of account or credential to authenticate and evaluate a set of variables to determine authorization or access.  Some of these variables may also be similar across different sessions. For example, an enterprise may evaluate the device’s security posture (e.g. it is running the latest OS patches) as a variable to grant access at both the network and application layer. Similarly, the same username and password may be used across different session layers.   

However, each layer might also use distinct and specific variables to evaluate the appropriate access level.  For instance, the network interface layer may want to ensure cryptographic compliance of the network interfaces. A cloud service may evaluate geographical or regional compliance.  The common practice today is to have every session layer act alone to make its own access decision.  

Let’s take a step back and review.  

  • We’ve established that there are many types of sessions, and the definitions are only expanding as cloud services become more prominent.  
  • We’ve established that securing each type of session is important, yet in most cases each distinct session is evaluating a Venn diagram of variables, some common across session types, yet others specific to a particular session definition.  
  • Finally, each session layer typically makes its own access evaluation. 

Now, let’s explore something new: what if the variables and access evaluation outcomes were shared seamlessly across session layers? 

What if recent network context and activity were used to inform cloud access decisions? Or, recent user access decisions across the network layers be used to inform cloud application controls?  Think about the enhanced resilience provided if network-based risk signal like packet information could be appropriately mapped and shared with the cloud application layer. Sharing information across session boundaries provides more robust fulfillment of Zero Trust principles by striving to evaluate security context as holistically as possible at the time of access.  

In order to build a future where security decisions are informed by broader and continuous context, we’ll need tools and protocols that help us bridge tools and map data across them.  To provide improved access and security, both the bridge and the correct mapping must be in place.  It’s one thing to get the data transferred to another tool, it’s quite another to map that data into relevance for the new tool. For example, how do we map a privileged application credential to a device? And, then how do we map relevant context across systems?  

The good news is that work is starting to enable a future where regardless of session definition, security context can be mapped and shared. Protocols such as the Shared Signals and Events and the Open Policy Agent are evolving to enable timely and dynamic signal sharing between tools, but they are nascent and broader adoption is required.  Cisco has already contributed a technical reference architecture as a guide for Shared Signals and Events. We hope that by accelerating the adoption of these standards the industry gets one step closer to actively sharing relevant security context across OSI layers. While the road ahead won’t be easy, we think the sharing signals will make for a more resilient and robust security future.  


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

Get More from Your Cybersecurity Spend When Inflation Rates Climb

By Ankur Chadda

Find out how you can stretch your organization’s security budget amidst inflation and its economic impacts.

No one could have predicted the lasting effects of the pandemic on our economy. A strain has been put on the overall supply chain, causing the value of the dollar, or any other local currency, to not go as far as it once did. Consumers are experiencing skyrocketing energy, gas, and food prices, and businesses are facing delays in deliveries of goods and services to their customers.

According to the Consumer Price Index (CPI), the U.S. economy has seen an uptick as high as 8.5% over the past twelve months, which is the largest spike since the early 1980s. Ideally, the economy should be in a balance of about 2% inflation.

When inflation rates go up, there is a steady rise in costs, putting a heavy burden on individuals and businesses.

Price Protection for your Cybersecurity Spend

Even with the rise in inflation, the need for products and services are still there to keep organizations operational. Cybersecurity attacks do not fall under the radar with inflation. If anything, cost increases mean you might get less protection for the same amount of spend, making cyber threats against your organization riskier. Businesses are forced to make budget adjustments, but cybersecurity spend is crucial to maintain the integrity of customer data and finances. Many businesses will be forced to have to raise prices for goods and services, passing the higher cost on to their customers. The solutions needed to maintain security should be simple and flexible to buy in a complex world. Cisco believes in price protection, not passing on the burdens of inflation to our customer.

Instant Savings with Cisco Secure Choice Enterprise Agreement

Cisco can help you with instant savings, avoiding inflation hikes with our price protection guarantee when it comes to buying security solutions to meet the security needs of your organization. With the significant shift in the way we work – remote work, office only, or hybrid, there are more devices on and off the network, leading to an increase in cybersecurity risks. Threats are not slowing down any time soon. Security needs to work together in a simple way to help you stay ahead of these threats to protect users everywhere, working from anywhere. Cisco Secure takes an integrated platform approach to radically simplify your security, applying intelligence to anticipate the changing needs of your business and provide the robust protection you need.

Whatever your organizational security needs may be, buying through the Cisco Secure Choice Enterprise Agreement allows you the flexibility to access two or more security products. Choose from network security, user & endpoint protection, cloud edge, or app security line of products.

Secure Choice Enterprise Agreements lets budgets go further and offers predictable billing over time so you can move faster in responding to security needs. Get a built-in security platform, SecureX, at no extra cost!

Cisco Secure products have never been simpler to buy. Add products, based on your specific security business goals, and receive additional discounts, up to 20% savings off list price. Start saving now with a Cisco Secure Enterprise Agreement.


We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!

Cisco Secure Social Channels

Instagram
Facebook
Twitter
LinkedIn

❌