What if I told you... that you could run a website from behind Cloudflare and only have 385 daily requests miss their cache and go through to the origin service?
No biggy, unless... that was out of a total of more than 166M requests in the same period:
Yep, we just hit "five nines" of cache hit ratio on Pwned Passwords being 99.999%. Actually, it was 99.9998% but we're at the point now where that's just splitting hairs, let's talk about how we've managed to only have two requests in a million hit the origin, beginning with a bit of history:
Optimising Caching on Pwned Passwords (with Workers)- @troyhunt - https://t.co/KjBtCwmhmT pic.twitter.com/BSfJbWyxMy
— Cloudflare (@Cloudflare) August 9, 2018
Ah, memories 😊 Back then, Pwned Passwords was serving way fewer requests in a month than what we do in a day now and the cache hit ratio was somewhere around 92%. Put another way, instead of 2 in every million requests hitting the origin it was 85k. And we were happy with that! As the years progressed, the traffic grew and the caching model was optimised so our stats improved:
There it is - Pwned Passwords is now doing north of 2 *billion* requests a month, peaking at 91.59M in a day with a cache-hit ratio of 99.52%. All free, open source and out there for the community to do good with 😊 pic.twitter.com/DSJOjb2CxZ
— Troy Hunt (@troyhunt) May 24, 2022
And that's pretty much where we levelled out, at about the 99-and-a-bit percent mark. We were really happy with that as it was now only 5k requests per million hitting the origin. There was bound to be a number somewhere around that mark due to the transient nature of cache and eviction criteria inevitably meaning a Cloudflare edge node somewhere would need to reach back to the origin website and pull a new copy of the data. But what if Cloudflare never had to do that unless explicitly instructed to do so? I mean, what if it just stayed in their cache unless we actually changed the source file and told them to update their version? Welcome to Cloudflare Cache Reserve:
Ok, so I may have annotated the important bit but that's what it feels like - magic - because you just turn it on and... that's it. You still serve your content the same way, you still need the appropriate cache headers and you still have the same tiered caching as before, but now there's a "cache reserve" sitting between that and your origin. It's backed by R2 which is their persistent data store and you can keep your cached things there for as long as you want. However, per the earlier link, it's not free:
You pay based on how much you store for how long, how much you write and how much you read. Let's put that in real terms and just as a brief refresher (longer version here), remember that Pwned Passwords is essentially just 16^5 (just over 1 million) text files of about 30kb each for the SHA-1 hashes and a similar number for the NTLM ones (albeit slight smaller file sizes). Here are the Cache Reserve usage stats for the last 9 days:
We can now do some pretty simple maths with that and working on the assumption of 9 days, here's what we get:
2 bucks a day 😲 But this has taken nearly 16M requests off my origin service over this period of time so I haven't paid for the Azure Function execution (which is cheap) nor the egress bandwidth (which is not cheap). But why are there only 16M read operations over 9 days when earlier we saw 167M requests to the API in a single day? Because if you scroll back up to the "insert magic here" diagram, Cache Reserve is only a fallback position and most requests (i.e. 99.52% of them) are still served from the edge caches.
Note also that there are nearly 1M write operations and there are 2 reasons for this:
An untold number of businesses rely on Pwned Passwords as an integral part of their registration, login and password reset flows. Seriously, the number is "untold" because we have no idea who's actually using it, we just know the service got hit three and a quarter billion times in the last 30 days:
Giving consumers of the service confidence that not only is it highly resilient, but also massively fast is essential to adoption. In turn, more adoption helps drive better password practices, less account takeovers and more smiles all round 😊
As those remaining hash prefixes populate Cache Reserve, keep an eye on the "cf-cache-status" response header. If you ever see a value of "MISS" then congratulations, you're literally one in a million!
Full disclosure: Cloudflare provides services to HIBP for free and they helped in getting Cache Reserve up and running. However, they had no idea I was writing this blog post and reading it live in its entirety is the first anyone there has seen it. Surprise! 👋
I found myself going down a previously unexplored rabbit hole recently, or more specifically, what I thought was "a" rabbit hole but in actual fact was an ever-expanding series of them that led me to what I refer to in the title of this post as "6 rabbits deep". It's a tale of firewalls, APIs and sifting through layers and layers of different services to sniff out the root cause of something that seemed very benign, but actually turned out to be highly impactful. Let's go find the rabbits!
When you buy an API key on Have I Been Pwned (HIBP), Stripe handles all the payment magic. I love Stripe, it's such an awesome service that abstracts away so much pain and it's dead simple to integrate via their various APIs. It's also dead simple to configure Stripe to send notices back to your own service via webhooks. For example, when an invoice is paid or a customer is updated, Stripe sends information about that event to HIBP and then lists each call on the webhooks dashboard in their portal:
There are a whole range of different events that can be listened to and webhooks fired, here we're seeing just a couple of them that are self explanatory in name. When an invoice is paid, the callback looks something like this:
HIBP has received this call and updated it's own DB such that for a new customer, they can now retrieve an API key or for an existing customer whose subscription has renewed, the API key validity period has been extended. The same callback is also issued when someone upgrades an API key, for example when going from 10RPM (requests per minute) to 50RPM. It's super important that HIBP gets that callback so it can appropriately upgrade the customer's key and they can immediately begin making more requests. When that call doesn't happen, well, let's go down the first rabbit hole.
This should never happen:
This came in via HIBP's API key support portal and is pretty self-explanatory. I checked the customer's account on Stripe and it did indeed show an active 50RPM subscription, but when drilling down into the associated payment, I found the following:
Ok, so at least I know where things have started to go wrong, but why? Over to the webhooks dashboard and into the failed payments and things look... suboptimal:
Dammit! Fortunately this is only a small single-digit percentage of all callbacks, but every time this fails it's either stopping someone like the guy above from making the requests they've paid for or potentially, causing someone's API key to expire even though they've paid for it. The latter in particular I was really worried about as it would nuke their key and whatever they'd built on top of it would cease to function. Fortunately, because that's such an impactful action I'd built in heaps of buffer for just such an occurrence and I'd gotten onto this issue quickly, but it was disconcerting all the same.
So, what's happening? Well, the response is HTTP 403 "Forbidden" and the body is clearly a Cloudflare challenge page so something at their end is being triggered. Looks like it's time to go down the next rabbit hole.
Desperate just to quickly restore functionality, I dropped into Cloudflare's WAF and allowed all Stripe's outbound IPs used for webhooks to bypass their security controls:
This wasn't ideal, but it only created risk for requests originating from Stripe and it got things up and running again quickly. With time up my sleeve I could now delve deeper and work out precisely what was going on, starting with the logs. Cloudflare has a really extensive set of APIs that can control a heap of features of the service, including pulling back logs (note: this is a feature of their Enterprise plan). I queried out a slice of the logs corresponding to when some of the 403s from Stripe's dashboard occurred and found 2 entries similar to this one:
{"BotScore":1,"BotScoreSrc":"Verified Bot","CacheCacheStatus":"unknown","ClientASN":16509,"ClientCountry":"us","ClientIP":"54.187.205.235","ClientRequestHost":"haveibeenpwned.com","ClientRequestMethod":"POST","ClientRequestReferer":"","ClientRequestURI":"[redacted]","ClientRequestUserAgent":"Stripe/1.0 (+https://stripe.com/docs/webhooks)","EdgeRateLimitAction":"","EdgeResponseStatus":403,"EdgeStartTimestamp":1674073983931000000,"FirewallMatchesActions":["managedChallenge"],"FirewallMatchesRuleIDs":["6179ae15870a4bb7b2d480d4843b323c"],"FirewallMatchesSources":["firewallManaged"],"OriginResponseStatus":0,"WAFAction":"unknown","WorkerSubrequest":false}
That's one of Stripe's outbound IP's on 54.187.205.235 and the "FirewallMatchesRuleIDs" collection has a value in it. Ergo, something about this request triggered the firewall and caused it to be challenged. I'm sure many of us have gone through the following thought process before:
What did I change?
Did I change anything?
Did they change something?
Except "they" could have been either Cloudflare or Stripe; if it wasn't me (and I was fairly certain it wasn't), was it a Cloudflare change to the rules or a Stripe change to a webhook payload that was now triggering an existing rule? Time to dig deeper again so it's over to the Cloudflare dashboard and down into the WAF events for requests to the webhook callback path:
Yep, something proper broke! Let's drill deeper and look at recent events for that IP:
As you dig deeper through troubleshooting exercises like this, you gradually turn up more and more information that helps piece the entire puzzle together. In this case, it looks like the "Inbound Anomaly Score Exceeded" rule was being triggered. What's that? And why? Time to go down another rabbit hole.
So, deeper and deeper down the rabbit holes we go, this time into the depths of the requests that triggered the managed rule:
Well that's comprehensive 🙂
There's a lot to unpack here so let's begin with the ruleset that the previously identified "Inbound Anomaly Score Exceeded" rule belongs to, the Cloudflare OWASP Core Ruleset:
The Cloudflare OWASP Core Ruleset is Cloudflare’s implementation of the OWASP ModSecurity Core Rule SetOpen external link (CRS). Cloudflare routinely monitors for updates from OWASP based on the latest version available from the official code repository.
That link is yet another rabbit hole altogether so let me summarise succinctly here: Cloudflare uses OWASP's rules to identify anomalous traffic based on a customer-defined paranoia level (how strict you want to be) and then applies a score threshold (also customer-defined) at which an action will be taken, for example challenging the request. What I learned as this saga progressed is that the "Inbound Anomoly Score Exceeded" rule is actually a rollup of the rules beneath it. The OWASP score of "26" is the sum of the 6 rules listed beneath it and once it exceeds 25, the superset rule is triggered.
Further - and this is the really important bit - Cloudflare routinely updates the rules from OWASP which makes sense because these are ever-evolving in response to new threats. And when did they last upgrade the rules? It looks like they announced it right before I started having issues:
Whilst it's not entirely clear from above when this release was scheduled to occur, I did reach out to Cloudflare support and was advised it had already taken place:
Please note that we did bump the OWASP version, which we are integrating with to 3.3.4 as noted on our scheduled changes.
So maybe it's not Cloudflare's fault or Stripe's fault, but OWASP's fault? In fairness to all, I don't think it's anyone's fault per se and is instead just an unfortunate result of everyone doing their best to keep the bad guys out. Unless... it really is Stripe's fault because there's something in the request payload that was always fishy and is now being caught? But why for only some requests and not others? Next rabbit!
Sometimes, people on the internet lose their minds a bit over things they really shouldn't. One of those things, in my experience, is Cloudflare's interception of traffic and it's something I wrote about in detail nearly 7 years ago now in my piece on security absolutism. Cloudflare plays an enormously valuable role in the internet's ecosystem and a substantial part of the value comes from being able to inspect, cache, optimise, and yes, even reject traffic. When you use Cloudflare to protect your website, they're applying rulesets like the aforementioned OWASP ones and in order to do that, they must be able to inspect your traffic! But they don't log it, not all of it, rather just "metadata generated by our products" as they refer to it on their logs page. We saw an example of that earlier on with Stripe's request from their IP showing it triggered a firewall rule, but what we didn't see is the contents of that POST request, the actual payload that triggered the rule. Let's go grab that.
Because the contents of a POST request can contain sensitive information, Cloudflare doesn't log it. Obviously they see it in transit (that's how OWASP's rules can be applied to it), but it's not stored anywhere and even if you want to capture it, they don't want to be able to see it. That's where payload logging (another Enterprise plan feature) comes in and what's really neat about that is every payload must be encrypted with a public key retained by Cloudflare whilst only you retain the private key. The setup looks like this:
Pretty self-explanatory and once done, right under where we previously saw the additional logs we now have the ability to decrypt the payload:
As promised, this requires the private key from earlier:
And now, finally, we have the actual payload that triggered the rule, seen here with my own test data:
[ " },\n \"billing_reason\": \"subscription_update\",\n \"charge\": null,\n \"collection_method\": \"charge_automatically\",\n \"created\": 1674351619,\n \"currency\": \"usd\",\n \"custom_fields\": null,\n \"customer\": \"cus_MkA71FpZ7XXRlt\",\n \"customer_address\": ", " },\n \"customer_email\": \"troy-hunt+1@troyhunt.com\",\n \"customer_name\": \"Troy Hunt 1\",\n \"customer_phone\": null,\n \"customer_shipping\": null,\n \"customer_tax_exempt\": \"none\",\n \"customer_tax_ids\": [\n\n ],\n \"default_payment_method\": null,\n \"default_source\": null,\n \"default_tax_rates\": [\n\n ],\n \"description\": \"You can manage your subscription (i.e. cancel it or regenerate the API key) at any time by verifying your email address here: https://haveibeenpwned.com/API/Key\",\n \"discount\": null,\n \"discounts\": [\n\n ],\n \"due_date\": null,\n \"ending_balance\": -11804,\n \"footer\": null,\n \"from_invoice\": null,\n \"hosted_invoice_url\": \"https://invoice.stripe.com/i/acct_1EdQYpEF14jWlYDw/test_YWNjdF8xRWRRWXBFRjE0aldsWUR3LF9OREo5SlpqUFFvVnFtQnBVcE91YUFXemtkRHFpQWNWLDY0ODkyNDIw02004bEyljdC?s=ap\",\n \"invoice_pdf\": \"https://pay.stripe.com/invoice/acct_1EdQYpEF14jWlYDw/test_YWNjdF8xRWRRWXBFRjE0aldsWUR3LF9OREo5SlpqUFFvVnFtQnBVcE91YUFXemtkRHFpQWNWLDY0ODkyNDIw02004bEyljdC/pdf?s=ap\",\n \"last_finalization_error\": null,\n \"latest_revision\": null,\n \"lines\": ", " ", " ],\n \"discountable\": false,\n \"discounts\": [\n\n ],\n \"invoice_item\": \"ii_1MSsXfEF14jWlYDwB1nfZvFm\",\n \"livemode\": false,\n \"metadata\": ", " },\n \"period\": ", " },\n \"plan\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4eLcJ7JYF02f\",\n \"tiers_mode\": null,\n \"transform_usage\": null,\n \"trial_period_days\": null,\n \"usage_type\": \"licensed\"\n },\n \"price\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4eLcJ7JYF02f\",\n \"recurring\": ", " },\n \"tax_behavior\": \"unspecified\",\n \"tiers_mode\": null,\n \"transform_quantity\": null,\n \"type\": \"recurring\",\n \"unit_amount\": 15000,\n \"unit_amount_decimal\": \"15000\"\n },\n \"proration\": true,\n \"proration_details\": ", " \"il_1MMjfcEF14jWlYDwoe7uhDPF\"\n ]\n }\n },\n \"quantity\": 1,\n \"subscription\": \"sub_1MMjfcEF14jWlYDwi8JWFcxw\",\n \"subscription_item\": \"si_N6xapJ8gSXdp7W\",\n \"tax_amounts\": [\n\n ],\n \"tax_rates\": [\n\n ],\n \"type\": \"invoiceitem\",\n \"unit_amount_excluding_tax\": \"-14304\"\n },\n ", " ],\n \"discountable\": true,\n \"discounts\": [\n\n ],\n \"livemode\": false,\n \"metadata\": ", " },\n \"period\": ", " },\n \"plan\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4lTSl4axd9mt\",\n \"tiers_mode\": null,\n \"transform_usage\": null,\n \"trial_period_days\": null,\n \"usage_type\": \"licensed\"\n },\n \"price\": ", " },\n \"nickname\": null,\n \"product\": \"prod_Mk4lTSl4axd9mt\",\n \"recurring\": ", " },\n \"tax_behavior\": \"unspecified\",\n \"tiers_mode\": null,\n \"transform_quantity\": null,\n \"type\": \"recurring\",\n \"unit_amount\": 2500,\n \"unit_amount_decimal\": \"2500\"\n },\n \"proration\": false,\n \"proration_details\": ", " },\n \"quantity\": 1,\n \"subscription\": \"sub_1MMjfcEF14jWlYDwi8JWFcxw\",\n \"subscription_item\": \"si_NDJ98tQrCcviJf\",\n \"tax_amounts\": [\n\n ],\n \"tax_rates\": [\n\n ],\n \"type\": \"subscription\",\n \"unit_amount_excluding_tax\": \"2500\"\n }\n ],\n \"has_more\": false,\n \"total_count\": 2,\n \"url\": \"/v1/invoices/in_1MSsXfEF14jWlYDwxHKk4ASA/lines\"\n },\n \"livemode\": false,\n \"metadata\": ", " },\n \"next_payment_attempt\": null,\n \"number\": \"04FC1917-0008\",\n \"on_behalf_of\": null,\n \"paid\": true,\n \"paid_out_of_band\": false,\n \"payment_intent\": null,\n \"payment_settings\": ", " },\n \"period_end\": 1674351619,\n \"period_start\": 1674351619,\n \"post_payment_credit_notes_amount\": 0,\n \"pre_payment_credit_notes_amount\": 0,\n \"quote\": null,\n \"receipt_number\": null,\n \"rendering_options\": null,\n \"starting_balance\": 0,\n \"statement_descriptor\": null,\n \"status\": \"paid\",\n \"status_transitions\": ", " },\n \"subscription\": \"sub_1MMjfcEF14jWlYDwi8JWFcxw\",\n \"subtotal\": -11804,\n \"subtotal_excluding_tax\": -11804,\n \"tax\": null,\n \"test_clock\": null,\n \"total\": -11804,\n \"total_discount_amounts\": [\n\n ],\n \"total_excluding_tax\": -11804,\n \"total_tax_amounts\": [\n\n ],\n \"transfer_data\": null,\n \"webhooks_delivered_at\": 1674351619\n }\n },\n \"livemode\": false,\n \"pending_webhooks\": 1,\n \"request\": ", " },\n \"type\": \"invoice.paid\"\n}" ]
But enough of what's present in the payload, it's what's absent that especially struck me. No obvious XSS patterns, nor SQL injection or any other suspicious looking strings. The request looked totally benign, so why did it trigger the rule?
I wanted to compare the payload of a blocked request with a similar request that wasn't blocked, but they're only logged at Cloudflare when they trigger a rule. No problem, it's easy to grab the full request from Stripe's webhook history so I found one that passed and one that failed and diff'd them both:
This clearly isn't the full 200 lines, but it's a very similar story over the remainder of the files; tiny differences largely down to dates, IDs, and of course, the customers themselves. No suspicious patterns, no funky characters, nothing visibly abnormal. It's a bit pointless to even mention it because they're near identical, but the payload on the left is the one that passed the firewall whilst the payload on the right was blocked.
Next rabbit hole!
Completely running out of ideas and options, focus moved to the folks inside Cloudflare who were already aware there was an issue:
We are actively looking into this and will likely release an update to the Cloudflare OWASP ruleset soon
— Michael Tremante (@MichaelTremante) January 20, 2023
What followed was a period of back and forth initially with Cloudflare, then Stripe as well with everyone trying to nut out exactly where things were going wrong. Essentially, the process went like this:
Is Cloudflare inadvertently blocking the requests?
Is the OWASP ruleset raising false positives?
Is Stripe issuing requests that are deemed to be malicious?
And round and round we went. At one time, Cloudflare identified a change in the OWASP ruleset which appeared to have resulted in their implementation inadvertently triggering the WAF. They rolled it back and... the same thing happened. We deferred back to Stripe on the assumption that something must have changed on their end, but they couldn't identify any change that would have any sort of material impact. We were stumped, but we also had an easy fix just one last rabbit hole away...
The joy of a managed firewall is that someone else takes all the rigmarole of looking after it away. I'm going to talk more about that in the summary shortly but clearly, that also creates risk as you're delegating control of traffic flow to someone else. Fortunately, Cloudflare gives you a load of configurability with their managed rules which makes it easy to add custom exceptions:
This meant I could create a simple exception that was much more intelligent than the previous "just let all outbound Stripe IPs in" by filtering down to the specific path those webhooks were flowing in to:
And finally, because sequence matters, I dragged that rule right up to the top of the pile so it would cause matching inbound requests to skip all the other rules:
And finally, there were no more rabbits 😊
I know what you're thinking - "what was the actual root cause?" - and to be honest, I still don't know. I don't know if it was Cloudflare or OWASP or Stripe or if it even impacted other customers of these services and to be honest, yes, that's a little frustrating. But I learned a bunch of stuff and for that alone, this was a worthwhile exercise I took three big lessons away from:
Firstly, understanding the plumbing of how all these bits work together is super important. I was lucky this wasn't a time critical issue and I had the luxury of learning without being under duress; how rules, payload inspection and exception management all work together is really valuable stuff to understand. And just like that, as if to underscore my first point, I found this right before hitting the publish button on the blog post:
I added a couple more OWASP rules to the exception in Cloudflare (things like a MySQL rule that was adding 5 points), and we were back in business.
Secondly, I look at the managed WAF Cloudflare provides more favourably than I did before simply because I have a better understanding of how comprehensive it is. I want to write code and run apps on the web, that's my focus, and I want someone else to provide that additional layer on top that continuously adapts to block new and emerging threats. I want to understand it (and I now do, at least certainly better than before), but I don't want managing it day in and day out to be my job.
And finally, IMHO, Stripe needs a better mechanism to report on webhook failures:
In live mode you are notified after 3 days of trying. You can also query the events (https://t.co/0mujOPssV0) to create a running list of statuses on web hooks that have been sent and alert on that via your own app.
— Blake Krone (@blakekrone) January 19, 2023
Waiting until stuff breaks really isn't ideal and whilst I'm sure you could plug into the (very extensive) API ecosystem Stripe has, this feels like an easy feature for them to build in. So, Stripe friends, when you read this that's a big "yes" vote from me for some form of anomalous webhook response alerting.
This experience was equal parts frustration and fun and whilst the former is probably obvious, the latter is simply due to having an opportunity to learn something new that's a pretty important part of the service I run. May my frustrated fun story here make your life easier in the future if you face the same problems 😊
Cisco Live is the premier destination for Cisco customers and partners to gain knowledge and build community. Our teams work hard to deliver education and inspiration, ignite creativity, deliver practical know-how, and accelerate the connections that fuel your digital future.
The Cisco Secure team is excited to share our expertise to help power the strategies – and safety – of your organization.
In 2023, the threat landscape will evolve to one that sees attacks on every surface, from criminals who are opportunistic, yet laser-focused on their goal. The attacks themselves could be email-borne, directly targeted, socially based, or a mix of all three.
Criminals will target vulnerabilities, operational deficiencies, suppliers, and business partners, as a means of accomplishing their goals. They will use the target’s own environment and take advantage of existing people and technology problems, including alert fatigue and staffing shortages.
To face this reality and address the needs of organizations both large and small, Cisco will continue to focus on education and innovation in the areas of preventing insider threats, providing consistent and informed alerts, enabling actionable intelligence, and delivering solutions to implement a zero-trust security framework.
As the organization that pioneered networking, we are driven to secure every connection, providing end-to-end protection for users and devices across multiple clouds and networks with a seamless experience.
As our vision for the integrated Cisco Security Cloud evolves, we’re continuing to challenge existing models and unify security and networking, with foundational elements that execute on this vision. From verified push – which protects organizations from MFA-focused phishing attacks – to Wi-Fi Fingerprint, and Remembered Devices, the performance enhancements with Enterprise Single Sign-on and Cisco+ Secure Connect, we continue to meet our customers where they are, offering true zero trust, with frictionless experiences for the hybrid workforce.
We’re excited to celebrate the following innovations and updates announced at Cisco Live EMEA:
Finding the balance between usability and security is now easier than ever. With Risk-Based Authentication, users have the access they need, secured by real-time contextual signals. Organizations can increase security efficacy by dynamically adjusting authentication requirements based on risk levels and by enabling safer end-user behavior. Risk-based authentication now includes wi-fi fingerprint, remembered device, and verified push features, which work together to reduce risk while preserving user experience by only requesting additional interaction for suspicious logins or a change in risk.
Our Enterprise Ready Single Sign-on expands Duo SSO with three new capabilities to easily connect single sign-on to modern apps and empower end users. By adding major protocol support, improved admin tooling, and SSO on demand password resets, organizations enable easier and more secure access from anywhere.
Cisco SD-WAN customers can now enjoy all the benefits of a turnkey, single-vendor SASE solution that brings together industry-leading networking with security: Cisco+ Secure Connect. This new integration gives Cisco SD-WAN (powered by Viptela) customers fast, secure private application and internet access, enabling them to deliver a secure experience, anywhere work happens.
We are also announcing the introduction of industry-first Business Risk Observability, an enhancement of our Full-Stack Observability application security solution. Available through Cisco Secure Application, which is integrated into Cisco AppDynamics, it provides a business risk scoring solution which brings together Kenna Risk Meter score distribution and Business Transactions from Cisco AppDynamics and integrates with Panoptica for API security and Talos for threat intelligence.
The initial findings from our first Cybersecurity Readiness Index reveal that while technology to devices is widely adopted, more progress is needed to protect identity, networks and applications. The report assessed the preparedness of companies around the world to safeguard against cyber threats in the current environment. See our key findings and security readiness trends, with the full report launching in the coming weeks.
As we navigate 2023, we will continue to face uncertainties and challenges. We are fully committed to our customers and partners in the journey to provide security resilience, supporting a frictionless user experience, and solutions threat intelligence that work to continually minimize risk.
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
The use of unmanaged and IoT devices in enterprises is growing exponentially, and will account for 55.7 billion connected devices by the end of 2025. A critical concern is deploying IoT devices without requisite security controls.
While these numbers are numbing, their reality is undeniable. 90% of customers believe digitization has accelerated the importance placed upon security. The World Economic Forum now lists cybersecurity failure as a critical threat, and estimates a gap of more than 3 million security experts worldwide, hindering secure deployments at scale. Furthermore, 83% of IoT-based transactions happen over plaintext channels and not SSL, making them especially risky.
Securing an IoT device can be achieved either through securing the IoT device itself, or hardening the network it accesses. Securing devices can be cumbersome, requiring complex manufacturing partnerships and increasing unit prices, thereby reducing adoption. On the other hand, securing the network is always desirable as it helps secure access, encrypt traffic, and ease management.
Being a leader in both security and networking, Cisco continues to bring security closer to networking, providing the network with built-in security, and enabling the network to act both as sensor and as an enforcer. The convergence of security and networking leverages the network’s intelligence and visibility to enable more-informed decisions on policy and threats.
Cisco uniquely integrates security and networking, for instance we recently integrated Cisco Secure Firewall to operate on Cisco Catalyst 9000 Series switches. Additionally, Secure Firewall can be deployed in a containerized form, on-premises and in clouds. Cisco Secure Firewall classifies traffic and protects applications while stopping exploitation of vulnerable systems. Additionally, we offer Identity Services Engine with AI Endpoint Analytics to passively identify IoT devices and apply segmentation policies. Furthermore, Cisco offers management flexibility by integrating with Cisco Defense Orchestrator and DNA Center and with existing customer tools like SIEMs and XDRs.
Let’s look at three use cases where the addition of Secure Firewall capability on Catalyst 9000 Series switches solves real world problems:
Use case 1: Securing the Smart Building: This solution is ideal to secure smart buildings, converging various IoT systems into a single IT-managed network infrastructure. Smart buildings lower the operational and energy costs. Smarter building systems, however, pose serious security risks as these include so many unmanaged devices such as window shades, lighting, tailored HVAC, and more. One of the methods to secure smart buildings is to control access to avoid manipulation of sensors. Such control is attained with a networking switch with enhanced firewall capability. The firewall ensures granular segmentation, directing policies for traffic generated out of IoT devices, providing access to the right users. This integration also brings security closer to endpoints, making policy orchestration simpler.
Use Case 2: Centrally manage isolated IoT network clusters: IoT devices which communicate with each other in the same subnet typically cannot be routed, which is a challenge. By default, most IoT networks are configured in the same subnet, making it difficult to manage them centrally. Administrators are forced to physically connect to the IoT network to manage and collect telemetry. Furthermore, IoT vendors often charge hefty amounts to update IP addresses of devices. Cisco Secure Firewall, hosted on the Catalyst switch, solves this problem and not only inspects traffic from the IoT network but also translates duplicate IoT IP addresses to unique global IP addresses using NAT for centralized management of isolated IoT networks.
Use Case 3: Securely encrypt IoT traffic passing through a shared IT network: At airports, for example, multiple vendors manage unique systems such as baggage, air quality, biometric access control, etc, which share a common network. IoT traffic is usually in plain text, making it susceptible to packet sniffing, eavesdropping, man-in-the-middle attacks, and other such exploits. The IPSec capability on Cisco Secure Firewall encrypts IoT traffic, securing data transfer and reducing risk.
Cisco’s IoT initiatives join the once disconnected worlds of IT and IoT, unifying networking and security. For further details refer to the At-A Glance and see how and an Australian oil company, Ampol, fortified its retail IoT with Cisco Secure!
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
In today’s security climate, NetOps and SecOps teams are witnessing increased attack surface area as applications and workloads move far beyond the boundaries of their data center. These applications/workloads move to, and reside in multi-cloud architecture, adding complexity to connectivity, visibility, and control. In the multi-cloud world, the SecOps teams use a distributed security model that is expensive, difficult to deploy, and complex to manage.
Cisco has partnered with Alkira to help secure your multi-cloud environment. Combining Alkira’s simplified cloud connection through their cloud network-as-a-service platform (SaaS-like model) with Cisco’s industry-leading security controls, we can deliver a centralized security model for multi-cloud architecture that is easy to deploy, manage, and increases visibility and control.
Cisco Secure Firewall Threat Defense Virtual provides unmatched security controls such as stateful firewalling, Snort3 IPS, URL filtering, malware defense, application visibility and control, and more. Additionally, with the purchase of Secure Firewall Threat Defense Virtual, you will receive license entitlement to Cisco SecureX, our open XDR and orchestration platform, helping you accelerate threat detection, investigation, and remediation.
Cisco Secure Firewall Management Center (FMC) is required for managing Secure Firewall Threat Defense Virtual, helping administrators enforce consistent access policies, rapidly troubleshoot security events, and view summarized reports across the deployment.
Secure Firewall Threat Defense Virtual is available on Alkira’s service marketplace through Bring-Your-Own-License (BYOL) and Pay-As-You-Go licensing options. Customers can seamlessly deploy and insert Secure Firewall in their Alkira Cloud Exchange Points (CXP).
Benefits of this integrated architecture include:
The Cisco Secure Firewall Threat Defense brings the following capabilities to the environment:
Figure 1 shows a multi-cloud environment inter-connected using Alkira Cloud Exhange Platform (CXP). In the above architecture, Cisco provides seamless insertion of security controls and enables the following use cases for firewall insertion:
Using Alkira’s customer portal, Cisco Secure Firewall Threat Defense Virtual can be easily inserted in the traffic path within minutes. Figure 2 shows how automation & orchestration eliminates additional configuration required in the legacy insertion model.
Cisco Secure Firewall Threat Defense Virtual is managed using Cisco Secure Firewall Management Center (FMC). Customers can use on-premises FMC or build a virtual FMC instance in the cloud. Cisco and Alkira support both models of deployment.
Cisco Secure Firewall Threat Defense Virtual protects the following traffic flows in Alkira CXP:
Alkira and Cisco’s partnership simplifies the deployment of enterprise-grade security in the cloud while enabling multi-cloud visibility and end-to-end threat defense for customers.
Additional Resources:
Cisco Secure Firewall Threat Defense
Cisco Secure Firewall Data Sheet
Cisco Secure Firewall Management Center
Alkira blog on Cisco Secure Firewall Threat Defense
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
Nowadays, “cybersecurity” is the buzzword du jour, infiltrating every organization, invited or not. Furthermore, this is the case around the world, where an increasing proportion of all services now have an online presence, prompting businesses to reconsider the security of their systems. This, however, is not news to Cisco, as we anticipated it and were prepared to serve and assist clients worldwide.
Secure Cloud Analytics, part of the Cisco Threat, Detection, and Response (TD&R) portfolio, is an industry-leading tool for tackling core Network Detection and Response (NDR) use cases. These workflows focus primarily on threat detection and how security teams may recognize the most critical issues around hunting and forensic investigations to improve their mean-time-to-respond.
Over the last year, the product team worked tirelessly to strengthen the NDR offering. New telemetry sources, more advanced detections, and observations supplement the context of essential infrastructure aspects as well as usability and interoperability improvements. Additionally, the long-awaited solution Cisco Telemetry Broker is now available, providing a richer SecOps experience across the product.
As part of our innovation story on alerting capabilities, Secure Cloud Analytics now features new detections tied to the MITRE ATT&CK framework such as Worm Propagation, Suspicious User Agent, and Azure OAuth Bypass.
Additionally, various new roles and observations were added to the Secure Cloud Analytics to improve and change user alerts, that are foundational pieces of our detections. Alerts now include a direct link to AWS’ assets and their VPC, as well as direct access to Azure Security Groups, enabling further investigation capabilities through simplified workflows. In addition, the Public Cloud Providers are now included in coverage reports that provide a gap analysis to determine which accounts are covered. Alert Details offers new device information, such as host names, subnets, and role metrics that emphasize detection techniques. To better configure alerts, we are adding telemetry to gain contextual reference on their priority. Furthermore, the ingest process has grown more robust due to data from the Talos intelligence feed and ISE.
The highly anticipated SecureX integration is now available in a single click, with no API credentials required and smooth interaction between the two platforms. Most importantly, Secure Cloud Analytics alerts may now be configured to automatically publish as incidents to the SecureX Incident Manager. The Talos Intelligence Watchlist Hits Alert is on by default due to its prominence among the many alert types.
Among other enhancements to graphs and visualizations, the Encrypted Traffic widget allows for an hourly breakdown of data. Simultaneously, the Device Report contains traffic data for a specific timestamp, which may be downloaded as a CSV. Furthermore, the Event Viewer now displays bi-directional session traffic to provide even more context to Secure Cloud Analytics flows, as well as additional columns to help with telemetry log comprehension: Cloud Account, Cloud Region, Cloud VPC, Sensor and Exporter.
On-premises sensors now provide additional telemetry on the overview page and a dedicated page where users can look further into the telemetry flowing through them in Sensor Health. To optimize the Secure Cloud Analytics deployment and improve the user experience, sensors may now be deleted from the interface.
Regarding telemetry, Cisco Telemetry Broker can now serve as a sensor in Secure Cloud Analytics, so users can identify and respond to threats faster with additional context sent to Secure Cloud Analytics. In addition, there will soon be support for other telemetry types besides IPFIX and NetFlow.
As we can see from the vast number of new additions to Secure Cloud Analytics, the product team has been working hard to understand the latest market trends, listen to the customers’ requests, and build one of the finest SaaS products in the NDR industry segment. The efforts strongly underline how Secure Cloud Analytics can solve some of the most important challenges in the NDR space around visibility, fidelity of alerts and deployment complexity by providing a cloud hosted platform that can offer insights on-premise and on cloud environments simultaneously from the same dashboard. Learn more about new features that allow Secure Cloud Analytics to detect, analyze, and respond to the most critical dangers to their company much more quickly.
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
Organizations embrace the public cloud for the agility, scalability, and reliability it offers when running applications. But just as organizations need these capabilities to ensure their applications operate where needed and as needed, they also require their security does the same. Organizations may introduce multiple individual firewalls into their AWS infrastructure to produce this outcome. In theory, this may be a good decision, but in practice—this could lead to asymmetric routing issues. Complex SNAT configuration can mitigate asymmetric routing issues, but this isn’t practical for sustaining public cloud operations. Organizations are looking out for their long-term cloud strategies by ruling out SNAT and are calling for a more reliable and scalable solution for connecting their applications and security for always-on protection.
To solve these challenges, Cisco created stateful firewall clustering with Secure Firewall in AWS.
Firewall clustering for Secure Firewall Threat Defense Virtual provides a highly resilient and reliable architecture for securing your AWS cloud environment. This capability lets you group multiple Secure Firewall Threat Defense Virtual appliances together as a single logical device, known as a “cluster.”
A cluster provides all the conveniences of a single device (management and integration into a network) while taking advantage of the increased throughput and redundancy you would expect from deploying multiple devices individually. Cisco uses Cluster Control Link (CCL) for forwarding asymmetric traffic across devices in the cluster. Clusters can go up to 16 members, and we use VxLAN for CCL.
In this case, clustering has the following roles:
The above diagram explains traffic flow between the client and the server with the insertion of the firewall cluster in the network. Below defines the roles of clustering and how packet flow interacts at each step.
Owner: The Owner is the node in the cluster that initially receives the connection.
Backup Owner: The node that stores TCP/UDP state information received from the Owner so that the connection can be seamlessly transferred to a new owner in case of failure.
Director: The Director is the node in the cluster that handles owner lookup requests from the Forwarder(s).
Forwarder: The Forwarder is a node in the cluster that redirects packets to the Owner.
Fragment Owner: For fragmented packets, cluster nodes that receive a fragment determine a Fragment Owner using a hash of the fragment source IP address, destination IP address, and the packet ID. All fragments are then redirected to the Fragment Owner over Cluster Control Link.
Cisco brought support for AWS Gateway Load Balancer (Figure 2). This feature enables organizations to scale their firewall presence as needed to meet demand (see details here).
Building off the previous figure, organizations can take advantage of the AWS Gateway Load Balancer with Secure Firewall’s clustering capability to evenly distribute traffic at the Secure Firewall cluster. This enables organizations to maximize the benefits of clustering capabilities including increased throughput and redundancy. Figure 3 shows how positioning a Secure Firewall cluster behind the AWS Gateway Load Balancer creates a resilient architecture. Let’s take a closer look at what is going on in the diagram.
Figure 3 shows an Internet user looking to access a workload. Before the user can access the workload, the user’s traffic is routed to Firewall Node 2 for inspection. The traffic flow for this example includes:
User -> IGW -> GWLBe -> GWLB -> Secure Firewall (2) -> GLWB -> GWLBe -> Workload
In the event of failure, the AWS Gateway Load Balancer cuts off existing connections to the failed node, making the above solution non-stateful.
Recently, AWS announced a new feature for their load balancers known as Target Failover for Existing Flows. This feature enables forwarding of existing connections to another target in the event of failure.
Cisco is an early adaptor of this feature and has combined Target Failover for Existing Flows with Secure Firewall clustering capabilities to create the industry’s first stateful cluster in AWS.
Figure 4 shows a firewall failure event and how the AWS Gateway Load Balancer uses the Target Failover for Existing Flows feature to switch the traffic flow from Firewall Node 2 to Firewall Node 3. The traffic flow for this example includes:
User -> IGW -> GWLBe -> GWLB -> Secure Firewall (3) -> GLWB -> GWLBe -> Workload
Organizations need reliable and scalable security to protect always-on applications in their AWS cloud environment. With stateful firewall clustering capabilities from Cisco, organizations can protect their applications while maintaining cloud benefits such as agility, scalability, and reliability.
Cisco Secure Firewall Threat Defense Virtual is available in the AWS marketplace, providing features like firewalling, application visibility & control, IPS, URL filtering, and malware defense. Cisco offers flexible options for firewall licensing, such as pay-as-you-go (PAYG) and bring-your-own-license (BYOL). To learn more about how Cisco Secure Firewall clustering capabilities can help protect your AWS applications, see our additional resources, check out our 30-day free trial, or speak to your Cisco sales representative.
Cisco Secure Firewall Clustering in the Cloud
Introducing AWS Gateway Load Balancer Target Failover for Existing Flows
Secure Firewall for Public Cloud webpage
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
It’s Partner Summit week and, for me, it’s an important reminder that no one company, not even Cisco, can do it alone. Our partners provide diverse perspectives, expertise, and solutions offerings. Each partner plays a key part in delivering the outcomes and experiences our customers need, want, and expect. So, when we say, “Let’s Own It”, it’s a rally cry for Cisco and our partners alike to do our parts to seize the massive opportunity that we have in front of us and turn it into mutual success.
Together, I know we can achieve amazing things. Foremost on my mind right now is both the opportunity and necessity to empower customers with security resilience. Resilience means customers can protect the integrity of every aspect of their business so that they can withstand unpredictable threats or changes and emerge stronger. It’s about providing controlled, trusted access to applications and services, at any time, from any place.
Resilience can also help customers deal with issues the moment they arise. If changes are needed, they will have the visibility to determine priorities, thanks to actionable intelligence and insight in the face of some major security realities that they are dealing with every day.
One, businesses are more interconnected, meaning that a breach on anyone in the value chain has dramatic ripple effects on the others.
Two, security attacks are becoming more personalized. Individuals remain one of the easiest targets for cybercriminals and their attacks are becoming more sophisticated and customized for the individual.
Three, hybrid work is here to stay. People around the world will continue to work from anywhere, on managed and unmanaged devices, over secured and unsecured networks, to applications spread across multiple clouds and data centers.
Our vision for enabling a more resilient organization is the Cisco Security Cloud. It’s an open, integrated security platform that will protect the integrity of entire IT ecosystems by safeguarding users, devices and applications across public clouds and private data centers, without public cloud lock-in. Delivering on the Security Cloud is part of our long-term product strategy; but the innovations we are announcing at Partner Summit this week are foundational elements that execute on this vision.
Specifically, we are announcing new solutions and technologies across our portfolio in Secure Connectivity, Network Security, and Zero Trust. I encourage all partners to drill down on each announcement in the accompanying blogs and news announcements. But here are the highlights of the announcements.
Helping increase resistance to phishing attacks and improve user experience through frictionless access using Duo Passwordless, which is now generally available with support for Duo Mobile as a passwordless authenticator.
Expanding the Cisco Secure Firewall 3100 series, the first firewall purpose-built for hybrid work, with the Secure Firewall 3105, ideal for branch office and similar use cases focused on performance at a competitive price point.
Strengthening Umbrella’s data loss prevention (DLP) capabilities by adding API-based enforcement and unified reporting to protect sensitive data, e.g., intellectual property and financial and healthcare information. This complements Umbrella’s current inline-DLP functionality and collectively forms multi-mode DLP.
New Secure Workload capabilities delivering policy-as-code workload security for cloud-native and public-cloud application development. Common use cases for policy-as-code include access control to infrastructure and simplifying enterprise compliance and controls.
Our strategy and our innovation roadmap are all designed to set you up, our partners, for long-term success. In addition, we are committed to several partner enablement programs to help you deliver more value to customers and to help you become more profitable. Examples include:
Partner Summit is for you. So, my call-to-action is for you to maximize the value you get out of this week by attending as many of the informative, high-impact security sessions many teams worked hard to create. I am really looking forward to meeting as many of you as possible – on the expo floor, at the sessions, or in our 1-on-1 meetings.
Security has never been more critical and the need for resiliency is a requirement for virtually every business. The time for us to own it and innovate to win this future together has never been better.
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
The release of Microsoft Azure Gateway Load Balancer is great news for customers, empowering them to simply and easily add Cisco Secure Firewall capabilities to their Azure cloud infrastructure. By combining Azure Gateway Load Balancer with Cisco Secure Firewall, organizations can quickly scale their firewall presence across their Azure cloud environment, providing protection for infrastructure and applications exactly where and when they need it.
With applications and resources hyper-distributed across hybrid-multicloud environments, organizations require agile security to protect their environment at each control point. This integration empowers organizations to dynamically insert Cisco’s security controls and threat defense capabilities in their Azure environment, removing the clunkiness of provisioning and deploying firewalls, as well as the need to rearchitect the network. Organizations can now enjoy highly available threat defense on the fly, protecting their infrastructure and applications from known and unknown threats.
Combining Secure Firewall with Azure Gateway Load Balancer offers a significant reduction in operational complexity when securing cloud infrastructure. Azure Gateway Load Balancer provides bump-in-the-wire functionality ensuring Internet traffic to and from an Azure VM, such as an application server, is inspected by Secure Firewall without requiring any routing changes. It also offers a single entry and exit point at the firewall and allows organizations to maintain visibility of the source IP address. Complementing these features, organizations can take advantage of our new Cloud-delivered Firewall Management Center. It enables organizations to manage their firewall presence 100% through the cloud with the same look and feel as they’ve grown accustomed to with Firewall Management Center. With Cloud-delivered Firewall Management Center, organizations will achieve faster time-to-value with simplified firewall deployment and management.
Azure Gateway Load Balancer support for Cisco Secure Firewall Threat Defense Virtual is available now. To learn more about how Cisco Secure Firewall drives security resilience across your hybrid-multicloud environment, see the additional resources below and reach out to your Cisco sales representative.
Microsoft Blog: Gateway Load Balancer now generally available in all regions
Azure Marketplace listing: Cisco Secure Firewall Threat Defense Virtual
Cisco Secure Firewall At-a-Glance
Cisco Secure Firewall for Public Cloud
Cloud-delivered Firewall Management Center
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
Phishers are enjoying remarkable success using text messages to steal remote access credentials and one-time passcodes from employees at some of the world’s largest technology companies and customer support firms. A recent spate of SMS phishing attacks from one cybercriminal group has spawned a flurry of breach disclosures from affected companies, which are all struggling to combat the same lingering security threat: The ability of scammers to interact directly with employees through their mobile devices.
In mid-June 2022, a flood of SMS phishing messages began targeting employees at commercial staffing firms that provide customer support and outsourcing to thousands of companies. The missives asked users to click a link and log in at a phishing page that mimicked their employer’s Okta authentication page. Those who submitted credentials were then prompted to provide the one-time password needed for multi-factor authentication.
The phishers behind this scheme used newly-registered domains that often included the name of the target company, and sent text messages urging employees to click on links to these domains to view information about a pending change in their work schedule.
The phishing sites leveraged a Telegram instant message bot to forward any submitted credentials in real-time, allowing the attackers to use the phished username, password and one-time code to log in as that employee at the real employer website. But because of the way the bot was configured, it was possible for security researchers to capture the information being sent by victims to the public Telegram server.
This data trove was first reported by security researchers at Singapore-based Group-IB, which dubbed the campaign “0ktapus” for the attackers targeting organizations using identity management tools from Okta.com.
“This case is of interest because despite using low-skill methods it was able to compromise a large number of well-known organizations,” Group-IB wrote. “Furthermore, once the attackers compromised an organization they were quickly able to pivot and launch subsequent supply chain attacks, indicating that the attack was planned carefully in advance.”
It’s not clear how many of these phishing text messages were sent out, but the Telegram bot data reviewed by KrebsOnSecurity shows they generated nearly 10,000 replies over approximately two months of sporadic SMS phishing attacks targeting more than a hundred companies.
A great many responses came from those who were apparently wise to the scheme, as evidenced by the hundreds of hostile replies that included profanity or insults aimed at the phishers: The very first reply recorded in the Telegram bot data came from one such employee, who responded with the username “havefuninjail.”
Still, thousands replied with what appear to be legitimate credentials — many of them including one-time codes needed for multi-factor authentication. On July 20, the attackers turned their sights on internet infrastructure giant Cloudflare.com, and the intercepted credentials show at least three employees fell for the scam.
Image: Cloudflare.com
In a blog post earlier this month, Cloudflare said it detected the account takeovers and that no Cloudflare systems were compromised. Cloudflare said it does not rely on one-time passcodes as a second factor, so there was nothing to provide to the attackers. But Cloudflare said it wanted to call attention to the phishing attacks because they would probably work against most other companies.
“This was a sophisticated attack targeting employees and systems in such a way that we believe most organizations would be likely to be breached,” Cloudflare CEO Matthew Prince wrote. “On July 20, 2022, the Cloudflare Security team received reports of employees receiving legitimate-looking text messages pointing to what appeared to be a Cloudflare Okta login page. The messages began at 2022-07-20 22:50 UTC. Over the course of less than 1 minute, at least 76 employees received text messages on their personal and work phones. Some messages were also sent to the employees family members.”
On three separate occasions, the phishers targeted employees at Twilio.com, a San Francisco based company that provides services for making and receiving text messages and phone calls. It’s unclear how many Twilio employees received the SMS phishes, but the data suggest at least four Twilio employees responded to a spate of SMS phishing attempts on July 27, Aug. 2, and Aug. 7.
On that last date, Twilio disclosed that on Aug. 4 it became aware of unauthorized access to information related to a limited number of Twilio customer accounts through a sophisticated social engineering attack designed to steal employee credentials.
“This broad based attack against our employee base succeeded in fooling some employees into providing their credentials,” Twilio said. “The attackers then used the stolen credentials to gain access to some of our internal systems, where they were able to access certain customer data.”
That “certain customer data” included information on roughly 1,900 users of the secure messaging app Signal, which relied on Twilio to provide phone number verification services. In its disclosure on the incident, Signal said that with their access to Twilio’s internal tools the attackers were able to re-register those users’ phone numbers to another device.
On Aug. 25, food delivery service DoorDash disclosed that a “sophisticated phishing attack” on a third-party vendor allowed attackers to gain access to some of DoorDash’s internal company tools. DoorDash said intruders stole information on a “small percentage” of users that have since been notified. TechCrunch reported last week that the incident was linked to the same phishing campaign that targeted Twilio.
This phishing gang apparently had great success targeting employees of all the major mobile wireless providers, but most especially T-Mobile. Between July 10 and July 16, dozens of T-Mobile employees fell for the phishing messages and provided their remote access credentials.
“Credential theft continues to be an ongoing issue in our industry as wireless providers are constantly battling bad actors that are focused on finding new ways to pursue illegal activities like this,” T-Mobile said in a statement. “Our tools and teams worked as designed to quickly identify and respond to this large-scale smishing attack earlier this year that targeted many companies. We continue to work to prevent these types of attacks and will continue to evolve and improve our approach.”
This same group saw hundreds of responses from employees at some of the largest customer support and staffing firms, including Teleperformanceusa.com, Sitel.com and Sykes.com. Teleperformance did not respond to requests for comment. KrebsOnSecurity did hear from Christopher Knauer, global chief security officer at Sitel Group, the customer support giant that recently acquired Sykes. Knauer said the attacks leveraged newly-registered domains and asked employees to approve upcoming changes to their work schedules.
Knauer said the attackers set up the phishing domains just minutes in advance of spamming links to those domains in phony SMS alerts to targeted employees. He said such tactics largely sidestep automated alerts generated by companies that monitor brand names for signs of new phishing domains being registered.
“They were using the domains as soon as they became available,” Knauer said. “The alerting services don’t often let you know until 24 hours after a domain has been registered.”
On July 28 and again on Aug. 7, several employees at email delivery firm Mailchimp provided their remote access credentials to this phishing group. According to an Aug. 12 blog post, the attackers used their access to Mailchimp employee accounts to steal data from 214 customers involved in cryptocurrency and finance.
On Aug. 15, the hosting company DigitalOcean published a blog post saying it had severed ties with MailChimp after its Mailchimp account was compromised. DigitalOcean said the MailChimp incident resulted in a “very small number” of DigitalOcean customers experiencing attempted compromises of their accounts through password resets.
According to interviews with multiple companies hit by the group, the attackers are mostly interested in stealing access to cryptocurrency, and to companies that manage communications with people interested in cryptocurrency investing. In an Aug. 3 blog post from email and SMS marketing firm Klaviyo.com, the company’s CEO recounted how the phishers gained access to the company’s internal tools, and used that to download information on 38 crypto-related accounts.
A flow chart of the attacks by the SMS phishing group known as 0ktapus and ScatterSwine. Image: Amitai Cohen for Wiz.io. twitter.com/amitaico.
The ubiquity of mobile phones became a lifeline for many companies trying to manage their remote employees throughout the Coronavirus pandemic. But these same mobile devices are fast becoming a liability for organizations that use them for phishable forms of multi-factor authentication, such as one-time codes generated by a mobile app or delivered via SMS.
Because as we can see from the success of this phishing group, this type of data extraction is now being massively automated, and employee authentication compromises can quickly lead to security and privacy risks for the employer’s partners or for anyone in their supply chain.
Unfortunately, a great many companies still rely on SMS for employee multi-factor authentication. According to a report this year from Okta, 47 percent of workforce customers deploy SMS and voice factors for multi-factor authentication. That’s down from 53 percent that did so in 2018, Okta found.
Some companies (like Knauer’s Sitel) have taken to requiring that all remote access to internal networks be managed through work-issued laptops and/or mobile devices, which are loaded with custom profiles that can’t be accessed through other devices.
Others are moving away from SMS and one-time code apps and toward requiring employees to use physical FIDO multi-factor authentication devices such as security keys, which can neutralize phishing attacks because any stolen credentials can’t be used unless the phishers also have physical access to the user’s security key or mobile device.
This came in handy for Twitter, which announced last year that it was moving all of its employees to using security keys, and/or biometric authentication via their mobile device. The phishers’ Telegram bot reported that on June 16, 2022, five employees at Twitter gave away their work credentials. In response to questions from KrebsOnSecurity, Twitter confirmed several employees were relieved of their employee usernames and passwords, but that its security key requirement prevented the phishers from abusing that information.
Twitter accelerated its plans to improve employee authentication following the July 2020 security incident, wherein several employees were phished and relieved of credentials for Twitter’s internal tools. In that intrusion, the attackers used Twitter’s tools to hijack accounts for some of the world’s most recognizable public figures, executives and celebrities — forcing those accounts to tweet out links to bitcoin scams.
“Security keys can differentiate legitimate sites from malicious ones and block phishing attempts that SMS 2FA or one-time password (OTP) verification codes would not,” Twitter said in an Oct. 2021 post about the change. “To deploy security keys internally at Twitter, we migrated from a variety of phishable 2FA methods to using security keys as our only supported 2FA method on internal systems.”
Update, 6:02 p.m. ET: Clarified that Cloudflare does not rely on TOTP (one-time multi-factor authentication codes) as a second factor for employee authentication.
Earlier this month, the administrator of the cybercrime forum Breached received a cease-and-desist letter from a cybersecurity firm. The missive alleged that an auction on the site for data stolen from 10 million customers of Mexico’s second-largest bank was fake news and harming the bank’s reputation. The administrator responded to this empty threat by purchasing the stolen banking data and leaking it on the forum for everyone to download.
On August 3, 2022, someone using the alias “Holistic-K1ller” posted on Breached a thread selling data allegedly stolen from Grupo Financiero Banorte, Mexico’s second-biggest financial institution by total loans. Holistic-K1ller said the database included the full names, addresses, phone numbers, Mexican tax IDs (RFC), email addresses and balances on more than 10 million citizens.
There was no reason to believe Holistic-K1ller had fabricated their breach claim. This identity has been highly active on Breached and its predecessor RaidForums for more than two years, mostly selling databases from hacked Mexican entities. Last month, they sold customer information on 36 million customers of the Mexican phone company Telcel; in March, they sold 33,000 images of Mexican IDs — with the front picture and a selfie of each citizen. That same month, they also sold data on 1.4 million customers of Mexican lending platform Yotepresto.
But this history was either overlooked or ignored by Group-IB, the Singapore-based cybersecurity firm apparently hired by Banorte to help respond to the data breach.
“The Group-IB team has discovered a resource containing a fraudulent post offering to buy Grupo Financiero Banorte’s leaked databases,” reads a letter the Breach administrator said they received from Group-IB. “We ask you to remove this post containing Banorte data. Thank you for your cooperation and prompt attention to this urgent matter.”
The administrator of Breached is “Pompompurin,” the same individual who alerted this author in November 2021 to a glaring security hole in a U.S. Justice Department website that was used to spoof security alerts from the FBI. In a post to Breached on Aug. 8, Pompompurin said they bought the Banorte database from Holistic-K1ller’s sales thread because Group-IB was sending emails complaining about it.
“They also attempted to submit DMCA’s against the website,” Pompompurin wrote, referring to legal takedown requests under the Digital Millennium Copyright Act. “Make sure to tell Banorte that now they need to worry about the data being leaked instead of just being sold.”
Group-IB CEO Dmitriy Volkov said the company has seen some success in the past asking hackers to remove or take down certain information, but that making such requests is not a typical response for the security firm.
“It is not a common practice to send takedown notifications to such forums demanding that such content be removed,” Volkov said. “But these abuse letters are legally binding, which helps build a foundation for further steps taken by law enforcement agencies. Actions contrary to international rules in the regulated space of the Internet only lead to more severe crimes, which — as we know from the case of Raidforums — are successfully investigated and stopped by law enforcement.”
Banorte did not respond to requests for comment. But in a brief written statement picked up on Twitter, Banorte said there was no breach involving their infrastructure, and the data being sold is old.
“There has been no violation of our platforms and technological infrastructure,” Banorte said. “The set of information referred to is inaccurate and outdated, and does not put our users and customers at risk.”
That statement may be 100 percent true. Still, it is difficult to think of a better example of how not to do breach response. Banorte shrugging off this incident as a nothingburger is baffling: While it is almost certainly true that the bank balance information in the Banorte leak is now out of date, the rest of the information (tax IDs, phone numbers, email addresses) is harder to change.
“Is there one person from our community that think sending cease and desist letter to a hackers forum operator is a good idea?,” asked Ohad Zaidenberg, founder of CTI League, a volunteer emergency response community that emerged in 2020 to help fight COVID-19 related scams. “Who does it? Instead of helping, they pushed the organization from the hill.”
Kurt Seifried, director of IT for the CloudSecurityAlliance, was similarly perplexed by the response to the Banorte breach.
“If the data wasn’t real….did the bank think a cease and desist would result in the listing being removed?” Seifried wondered on Twitter. “I mean, isn’t selling breach data a worse crime usually than slander or libel? What was their thought process?”
A more typical response when a large bank suspects a breach is to approach the seller privately through an intermediary to ascertain if the information is valid and what it might cost to take it off the market. While it may seem odd to expect cybercriminals to make good on their claims to sell stolen data to only one party, removing sold stolen items from inventory is a fairly basic function of virtually all cybercriminal markets today (apart from perhaps sites that traffic in stolen identity data).
At a minimum, negotiating or simply engaging with a data seller can buy the victim organization additional time and clues with which to investigate the claim and ideally notify affected parties of a breach before the stolen data winds up online.
It is true that a large number of hacked databases put up for sale on the cybercrime underground are sold only after a small subset of in-the-know thieves have harvested all of the low-hanging fruit in the data — e.g., access to cryptocurrency accounts or user credentials that are recycled across multiple websites. And it’s certainly not unheard of for cybercriminals to go back on their word and re-sell or leak information that they have sold previously.
But companies in the throes of responding to a data security incident do themselves and customers no favors when they underestimate their adversaries, or try to intimidate cybercrooks with legal threats. Such responses generally accomplish nothing, except unnecessarily upping the stakes for everyone involved while displaying a dangerous naiveté about how the cybercrime underground works.
Update, Aug. 17, 10:32 a.m.: Thanks to a typo by this author, a request for comment sent to Group-IB was not delivered in advance of this story. The copy above has been updated to include a comment from Group-IB’s CEO.
How best to punish spammers? I give this topic a lot of thought because I spend a lot of time sifting through the endless rubbish they send me. And that's when it dawned on me: the punishment should fit the crime - robbing me of my time - which means that I, in turn, need to rob them of their time. With the smallest possible overhead on my time, of course. So, earlier this year I created Password Purgatory with the singular goal of putting spammers through the hellscape that is attempting to satisfy really nasty password complexity criteria. And I mean really nasty criteria, like much worse than you've ever seen before. I opened-sourced it, took a bunch of PRs, built out the API to present increasingly inane password complexity criteria then left it at that. Until now because finally, it's live, working and devilishly beautiful 😈
This is the easy bit - I didn't have to do anything for this step! But let me put it into context and give you a real world sample:
Ugh. Nasty stuff, off to hell for them it is, and it all begins with filing the spam into a special folder called "Send Spammer to Password Purgatory":
That's the extent of work involved on a spam-by-spam basis, but let's peel back the covers and look at what happens next.
Microsoft Power Automate (previously "Microsoft Flow") is a really neat way of triggering a series of actions based on an event, and there's a whole lot of connectors built in to make life super easy. Easy on us as the devs, that is, less easy on the spammers because here's what happens as soon as I file an email in the aforementioned folder:
Using the built in connector to my Microsoft 365 email account, the presence of a new email in that folder triggers a brand new instance of a flow. Following, I've added the "HTTP" connector which enables me to make an outbound request:
All this request does is makes a POST to an API on Password Purgatory called "create-hell". It passes an API key because I don't want just anyone making these requests as it will create data that will persist at Cloudflare. Speaking of which, let's look at what happens over there.
Let's start with some history: Back in the not too distant past, Cloudflare wasn't a host and instead would just reverse proxy requests through to origin services and do cool stuff with them along the way. This made adding HTTPS to any website easy (and free), added heaps of really neat WAF functionality and empowered us to do cool things with caching. But this was all in-transit coolness whilst the app logic, data and vast bulk of the codebase sat at that origin site. Cloudflare Workers started to change that and suddenly we had code on the edge running in hundreds of nodes around the world, nice and close to our visitors. Did that start to make Cloudflare a "host"? Hmm... but the data itself was still on the origin service (transient caching aside). Fast forward to now and there are multiple options to store data on Cloudflare's edges including their (presently beta) R2 service, Durable Objects, the (forthcoming) D1 SQL database and of most importance to this blogpost, Workers KV. Does this make them a host if you can now build entire apps within their environment? Maybe so, but let's skip the titles for now and focus on the code.
All the code I'm going to refer to here is open source and available in the public Password Purgatory Logger Github repo. Very early on in the index.js file that does all the work, you'll see a function called "createHell" which is called when the flow step above runs. That code creates a GUID then stores it in KV after which I can easily view it in the Cloudflare dashboard:
There's no value yet, just a key and it's returned via a JSON response in a property called "kvKey". To read that back in the flow, I need a "Parse JSON" step with a schema I generated from a sample:
At this point I now have a unique ID in persistent storage and it's available in the flow, which means it's time to send the spammer an email.
Because it would be rude not to respond, I'd like to send the spammer back an email and invite them to my very special registration form. To do this, I've grabbed the "Reply to email" connector and fed the kvKey through to a hyperlink:
It's an HTML email with the key hidden within the hyperlink tag so it doesn't look overtly weird. Using this connector means that when the email sends, it looks precisely like I've lovingly crafted it myself:
With the entire flow now executed, we can view the history of each step and see how the data moves between them:
Now, we play the waiting game 😊
Wasting spammer time in and of itself is good. Causing them pain by having them attempt to pass increasingly obtuse password complexity criteria is better. But the best thing - the pièce de résistance - is to log that pain and share it publicly for our collective entertainment 🤣
So, by following the link the spammer ends up here (you're welcome to follow that link and have a play with it):
The kvKey is passed via the query string and the page invites the spammer to begin the process of becoming a partner. All they need to leave is an email address... and a password. That page then embeds 2 scripts from the Password Purgatory website, both of which you can find in the open source and public Github repository I created in the original blog post. Each attempt at creating an account sends off the password only to the original Password Purgatory API I created months ago, after which it responds with the next set of criteria. But each attempt also sends off both the criteria that was presented (none on the first go, then something increasingly bizarre on each subsequent go), the password they tried to use to satisfy the criteria and the kvKey so it can all be tied together. What that means is that the Cloudflare Workers KV entry created earlier gradually builds up as follows:
There are a couple of little conditions built into the code:
That's everything needed to lure the spammer in and record their pain, now for the really fun bit 😊
The very first time the spammer's password attempt is logged, the Cloudflare Worker sends me an email to let me know I have a new spammer hooked (this capability using MailChannels only launched this year):
It was so exciting getting this email yesterday, I swear it's the same sensation as literally getting a fish on your line! That link is one I can share to put the spammer's pain on display for the world to see. This is achieved with another Cloudflare Workers route that simply pulls out the logs for the given kvKey and formats it neatly in an HTML response:
Ah, satisfaction 😊 I listed the amount of time the spammer burned with a goal to further refining the complexity criteria in the future to attempt to keep them "hooked" for longer. Is the requirement for a US post code in the password a bit too geographically specific, for example? Time will tell and I wholeheartedly welcome PRs to that effect in the original Password Purgatory API repo.
Oh - and just to ensure traction and exposure are maximised, there's a neatly formatted Twitter card that includes the last criteria and password used, you know, the ones that finally broke the spammer's spirit and caused them to give up:
Spammer burned a total of 80 seconds in Password Purgatory 😈 #PasswordPurgatory https://t.co/VwSCHNZ2AW
— Troy Hunt (@troyhunt) August 3, 2022
Clearly, I've taken a great deal of pleasure in messing with spammers and I hope you do too. I've gotta be honest - I've never been so excited to go through my junk mail! But I also thoroughly enjoyed putting this together with Power Automate and Workers KV, I think it's super cool that you can pull an app together like this with a combination of browser-based config plus code and storage that runs directly in hundreds of globally distributed edge nodes around the world. I hope the spammers appreciate just how elegant this all is 🤣
Cisco and AWS demonstrate shared responsibility that identifies Security “of” the Cloud versus Security “in” the Cloud.
Shared responsibility remains central to every cloud initiative and defines how cloud providers and customers work together to achieve maximum security across all aspects of the cloud. While shared responsibility is a common term, surprisingly few people understand the model and fewer still have implemented it correctly. The lack of consistent security controls across cloud services does not go unnoticed by attackers, as they probe for vulnerabilities and slip undetected through unsecured cracks.
Security teams should start by understanding the security controls provided by their cloud service providers to help them highlight areas that are susceptible to threats and attacks. Matrices, such as the following from Amazon Web Services (AWS), give a clear view of the shared responsibility model to guide an organization’s approach:
Once Security teams understand the areas they’re responsible for securing, they can begin to construct a security model that includes the right set solutions to serve their needs.
The most effective security model is built around centralized policy and distributed enforcement, allowing security policy to be applied consistently across operating systems, applications and data using multiple security solutions. Security teams should look for ideal solutions that seamlessly integrate into their unified policy. A good first step is to ask the cloud provider for their recommendations and visit cloud marketplaces, such as the AWS Marketplace, to find and try solutions. Customers can also utilize relationships with their security vendors to obtain best practices.
As Mark Twain once said, “History doesn’t repeat itself, but it often rhymes.” There are fundamental differences between on-premise and cloud security practices and controls. However, the way in which security teams discover best practices has not changed. New playbooks from trusted vendors and cloud providers are available to help security teams implement layered approaches to securing their organizations. Security teams should examine these concepts and build on them to protect their specific cloud services without needing to reinvent new models on their own. A good place to start is Cisco’s Cloud Security page.
Watch the recent AWS and Cisco webinar to hear industry analysts, head CISO advisors, and AWS experts discuss shared responsibility, industry challenges and the ways in which other security teams are addressing the problem, and then visit the AWS Marketplace to see the latest Cisco Secure offerings. Purchasing Cisco Secure on AWS Marketplace has the additional benefit of meeting the AWS Enterprise Discount Program commitments.
What is your experience with shared responsibility? We invite you to share your thoughts.
More Cisco and AWS blogs:
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
We’ve all seen the headlines like “race to the cloud” and “cloud-first.” These articles and publications are true, more and more customers have adopted cloud strategies, but there is more to the story. In these customer conversations, cloud security and network security are often discussed in unison. Why is that?
Customers desire freedom and choice when establishing resilience across every aspect of their business, and this requires both the ability to remain agile, and maintain control of their organization’s most sensitive data. Neither of these can be achieved with just the cloud, or private data center. Organizations are investing in hybrid-multicloud environments to ensure continuity amidst unpredictable threats and change. But these investments will fall short if they do not include security.
The modern enterprise relies on the network more than ever before, and it looks a lot different than it did 10 years ago. According to our 2022 Global Hybrid Cloud Trends Report, where 2,500 global IT leaders were interviewed across 13 countries, 82% said they have adopted hybrid cloud architectures, and 47% of organizations use between two and three public IaaS clouds1. As organizations have grown more dependent on the network, the more complex it has become, making firewall capabilities the most critical element of the hybrid-multicloud security strategy. And Cisco has a firewall capability for every strategy, protecting your most important assets no matter where you choose to deploy it.
In May, Cisco brought offerings from Umbrella and Duo to the AWS Marketplace. Today at AWS Re:Inforce, Cisco Secure announced furthering its partnership with AWS to drive innovation with the goal to protect the integrity of your business. Validating our commitment to hybrid-multicloud security, Cisco has received the AWS Security Competency Partner designation for Network and Infrastructure Security. This designation was awarded through our demonstrated success with customer engagements and rigorous technical validations of Secure Firewall.
This week at AWS Re:Inforce, customers can stop by our booth to see our latest firewall innovation. Cisco Secure Firewall as-a-service on AWS builds on our existing portfolio, giving organizations greater flexibility and choice with a radically simplified SaaS offering. If organizations are truly to embrace security across the multi-environment IT, customers demand simplification without compromising security. With a SaaS-based form factor, management and deployment complexity is reduced. NetOps and SecOps teams will enjoy a simplified security architecture where provisioning of firewalls and control plane infrastructure are managed by Cisco. This will save your teams time by removing the need to rearchitect the network, freeing them to focus on protecting the integrity of your business.
As organizations continue to move more of their day-to-day operations to the cloud, Cisco and AWS are committed to ensure that security is an integral part of their hybrid multi-cloud strategy. We all have seen the impact of security that is bolted on, or too complex. If we are truly to find that balance between agility and protection to ensure business continuity, we need to ensure the same protections we have in the private infrastructure are easily consumed no matter where your data may roam.
Product page: Cisco Secure Firewall for Public Cloud
Partner page: Cisco solutions on AWS
Blog: Securing cloud is everyone’s responsibility
Quick Start page: Cisco solutions on AWS
Amazon Partner Network page: Cisco solutions on AWS
2022 Global Hybrid Cloud Trends Report
1 Henderson, N. & Hanselman, E. (2022, May 25). 2022 Global Hybrid Cloud Trends Report.
S&P Global Market Intelligence, commissioned by Cisco Systems.
https://www.cisco.com/c/en/us/solutions/hybrid-cloud/2022-trends.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
Managed services are an essential and fast-growing part of the security market, growing 14% annually. This opportunity presents new challenges MSPs must juggle day to day, including onboarding vendors and driving customer acquisition, all while making sure to provide robust IT solutions for your diverse set of clients. Clients are demanding more security and capabilities for a hybrid workforce, which provides a great opportunity for MSPs like you to grow your business.
We love our MSP community and want to help you deliver great security solutions to your clients. After speaking with many of you to understand how Cisco can help unlock growth for your businesses today, we developed a simplified buying model that delivers faster time to value. Cisco Secure MSP was born.
Secure MSP center was launched in the US market in November 2021 and MSPs across America have been rapidly transacting their business on MSP Center. We are excited to announce we are expanding this direct buying experience to Canadian MSPs in local Canadian Dollars for faster time to value and better ROI for your business.
It is a lightning fast and direct buying experience of SaaS security- No invoicing. Straightforward market pricing. And easy click-to-accept agreements. Cisco Umbrella’s market-leading DNS security is currently available with more SaaS security products coming soon.
It’s a simple three-step process that takes just minutes, from signup to deployment.
Step 1 – You can sign up here and login with your Cisco ID (or create one)
Step 2 – Provide billing and credit card information and sign a click-to-accept agreement
Step 3 – Get access to our world class Cisco Umbrella DNS security offer
From here, you can onboard your clients and start providing the first line of defense through Umbrella DNS Security product instantly. Sign up to deployment takes minutes – not hours or days.
From here, you can onboard your clients and start providing the first line of defense through Umbrella DNS Security product instantly. Sign up to deployment takes minutes – not hours or days.
There are no minimums or upfront fees. Your credit card will be charged on the first of the month and you’ll receive a detailed invoice. This is a simple, no hassle, and post-paid consumption-based model.
Other perks include a dedicated partner account manager alongside our sales engineer, who will help you not only with product deployments but also work with you to grow your business. We also have an MSP specialist team to answer your questions.
Partners currently using Secure MSP Center have had great things to say –
“Wow, this was a much easier process than I thought it would be”
“I’m glad Cisco created a program and process that was this simple”
“I thought this would be more complicated”
“That’s all there is to it?”
So, what are you waiting for? Come and take the first step in simplifying security offers for your clients. Sign up here: cisco.com/go/securemsp.
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
What is it that customers truly want from their security? Is it simplicity? Robust protection? Agility and flexibility? Yes! In today’s uncertain world where new challenges are being thrown at IT teams each day, security must meet many diverse needs. At the end of the day, it’s about keeping the entire business resilient despite the chaos of the cyber world.
As hybrid work, the move to the cloud, and increasingly insidious threats all converge to create layers of complexity, security teams must be extra vigilant and ready for what’s next. They need a comprehensive, integrated security system whose various components share information and work together to pinpoint attacks and minimize organizational impact — without introducing undue friction.
With businesses, networks, clouds and devices becoming so interconnected, delivering next-level security to match the future of work is a formidable undertaking — one that few vendors are positioned to tackle. But thanks to our nearly 40-year heritage of providing and protecting a vast amount of the world’s networking infrastructure, Cisco is up for the challenge.
“At a moment’s notice, we were able to transition 80 percent of our workforce to be remote — and our company was never remote before. Because of our Cisco solutions, we were able to deploy everything and have people work well remotely with very minimal issues.”
— Joseph Rodriguez, Assistant Director of IT, Allied Beverage Group
Delivering security that is simple, powerful and resilient is something we’ve been executing on for years, yet it’s never been more critical than it is at this very moment. The month of June has afforded us the perfect opportunity to showcase exactly how we plan to keep our customers cyber resilient both now and in the future.
Read about the five dimensions of security resilience.
During the RSA Conference and Cisco Live, we announced our strategic plan for the Cisco Security Cloud, a global, cloud-delivered, integrated platform that secures and connects organizations of any shape and size. As we continue to move towards the Cisco Security Cloud vision, we recently unveiled several advancements in our portfolio across SASE, XDR and zero trust.
You can read our news announcement to learn more about security resilience and how we’re delivering it. But more important than the ‘how’ is the ‘why.’ Why Cisco? What makes us uniquely positioned to secure your resilience?
As I mentioned, our customers have trusted us with their networks for nearly four decades. Currently, 80 percent of the world’s internet traffic travels through Cisco infrastructure — so we have a pretty good handle on what’s going on out there. From a security standpoint alone, we have over 300,000 customers around the globe, including 100% of the Fortune 100.
As a leader in both networking and security, the breadth and depth of our solutions is unmatched. While other vendors are just beginning to join networking with security, we’ve been doing it for years. And yet, we’re continually finding ways to simplify our robust solutions for a streamlined user experience — no matter the size of your organization, where your employees work, or whether your applications are on-premises, in the cloud, or both.
Learn more about security resilience for the hybrid work era.
In addition to unparalleled infrastructure and expertise, our open, cloud-native architecture allows you to integrate with a wide range of third-party security and technology solutions for more seamless threat defense. This includes the major cloud vendors, enabling you to secure a multi-cloud environment without getting locked in with just one public cloud provider.
Additionally, all of our solutions are backed by Cisco Talos, one of the largest commercial threat intelligence teams in the world. Combined with in-depth visibility from our Cisco Secure technologies, Talos’ extensive insight into the threat landscape leads to rapid, highly effective detection and response.
Even more crucial than what we have to say is what we have heard from our customers surrounding the “new normal” for security. “I think what the security industry could use right now is a real business outcome-oriented viewpoint,” said Tom Doughty, vice president and CISO at Prudential Financial. “Meaning, what are the strategic business outcomes you’re trying to enable? Cisco can help security teams be more aligned to our business and more resilient by allowing us to see at a granular level what’s happening in our environment, especially in an extended network.”
For the law firm of George Sink, P.A., the demands of supporting hybrid work accelerated the company’s move to the cloud. The firm is now using Cisco’s new, turnkey SASE solution to securely serve its clients under any circumstance — be it a pandemic or a hurricane. According to the firm’s CIO, Timothy Mullen, “The ability to…re-establish connectivity in another region almost immediately, with my small IT team, is unheard of and a game-changing experience.”
From financial to legal transactions, and much more, we can secure it all with our open, integrated protection platform and unwavering focus on resilience. We even had the honor of securing the Super Bowl earlier this year, helping to safeguard mission-critical gameday operations.
“The Super Bowl and events of that magnitude require a humongous orchestration of interconnectedness, not only from a technology perspective but also a people standpoint,” said NFL Chief Information Security Officer, Tomás Maldonado. “What we’re trying to do is slow down the bad actors and make it more difficult for them to attack us and impact what’s happening on the field. But at the same time, we also have to look beyond the field and think about all the various parts of our business that could be affected by an attack — recognizing that our risk factors are always changing.”
To learn more about how to keep your business strong in the face of adversity, visit our resilience web page and check out the blog from Cisco’s Jeetu Patel, “Security Resilience for a Hybrid, Multi-Cloud 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
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.
These new cloud-based business models offer many of the benefits noted above, but they also come with potential risks:
Below are some best practices to help manage and mitigate these risks:
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
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
Microsoft Azure Shared Responsibility for Cloud Computing
https://azure.microsoft.com/en-us/resources/shared-responsibility-for-cloud-computing/
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