Login
Webinar The cloud is constantly in flux, and with its continual growth comes an equally rapid acceleration of threats and vulnerabilities direct towards it. You could say the cloud environment resembles the wild west where even hired guns carefully guarding your wagon train are not always enough to prevent an ambush by a gang of determined outlaws.…
Vernon has been our Manager of Technical Accounting for more than two years, but that doesn’t mean he’s busy with spreadsheets and numbers all day.
It’s been an amazing ride so far. My team touches on several areas of responsibility, including financial period closing, financial reporting, and accounting for complex transactions.
The most rewarding part of my role is definitely the variety and complexity – they really go hand-in-hand and I enjoy asking questions and figuring out the solutions, even when there is not always a textbook answer. I enjoy the challenge of working collectively with a team to find solutions by applying research and experience to a set of facts.
It’s also rewarding to be able to collaborate with auditors and other stakeholders who would be interested in the results.
My favorite thing about working at McAfee is the team. We have an amazing team. It’s full of really smart people. I’ve seen some companies try and find the best talent they can, but McAfee has just taken that to a whole different level. Everyone in their respective areas is really tuned in to the broader effort and we work well together. At McAfee, we enjoy both a high level of talent and collaborative effort. You don’t often find both in the same place.
I really believe that each person brings certain strengths to the table, and they should be able to exercise those strengths to develop and expand their capabilities. Once those natural roles are established, it’s best to trust them to determine how best to perform in their roles and collaborate with the team in achieving results that add value to the broader group.
First, expect the unexpected – consider each new experience an opportunity for personal growth.
Secondly, get involved in projects. If you have the opportunity to do something different or work with a cross-functional team, do it. It builds your own skill base, which opens the door for greater future opportunities and you get to meet people outside of your own department and develop relationships that may prove valuable over time.
The post For some, accounting is more than just spreadsheets! Vernon’s McAfee Journey appeared first on McAfee Blog.
The White House is adding the chemical sector to a program launched last year to improve cybersecurity capabilities within America's critical infrastructure industries.…
Sponsored Feature The inexorable pace of technological innovation in response to the unrelenting growth of cyber attacks has led to fragmentation within cyber security provision. Things generally follow a common pattern, starting with a new security requirement being identified, whether a response to a novel threat, or a compliance or regulation challenge. This leads buyers to specialized tools, usually from smaller vendors that do one thing well. But inevitably over time, buyers end up using a mishmash of systems and tools, each with its own job and management processes.…
With passwords and MFA out of the way, let’s next look at connected apps or services that are tied to our priority accounts. When you log into other sites on the web through Facebook, Google, or another social account, as well as when you install social media apps or games, you are sharing information about those accounts with those services. This may be as limited as the email address and username on file, or may include much more information like your friends list, contacts, likes/subscriptions, or more.
A well-known example of this data-harvesting method is the Cambridge Analytica story, where installing a social media app opened up access to much more information than users realized. (Note: as mentioned in the linked article, Facebook added protective measures to limit the amount of data available to app developers, but connected accounts can still present a liability if misused.)
With this in mind, look under the Security or Privacy section of each of your account’s settings, and review where you have either used this account to log into a third-party website or allowed access when installing an app. Here are some handy links to some of the most common services to check:
If you aren’t going to use the app again or don’t want to share any details, remove them. Once you’ve checked your accounts, repeat this process with all the apps installed on your phone.
Just like connecting a social account to a third-party game can share information like your contact info and friend’s list, installing an app on your mobile device can share information including your contacts, camera roll and more. Fortunately, mobile OSes have gotten much better at notifying users before installation on what information is shared, so you should be able to see which apps might be nosier than you’re comfortable with.
Finally — and this is really for the nerds and techies out there — check if you have any API (short for “application programming interface”) keys or browser extensions connected to your accounts. API keys are commonly used to let different apps or services “talk” between one another. They let you use services like Zapier or IFTTT to do things like have your Spotify favorites automatically saved to a Google Sheet, or check Weather Underground to send a daily email with the forecast.
Browser extensions let you customize a web browser and integrate services, like quickly clicking to save an article for review on a “read it later” service like Instapaper. Even if you trust the developer when installing these apps, they may pose a risk later on if they are recovered or taken over by an attacker. These “zombie extensions” rely on a broad install base from a legitimate service which can later be misused to gather information or launch attacks by a malicious developer.
We’ve made great progress already, and taken steps to help defend your accounts from prying eyes going forward – now it’s time to lock down your previous activities on social media. Rather than enumerate every option on every service, I’ll highlight some common tools and privacy settings you’ll want to check:
Before moving on to email, I’ll add another plug for the NYT Social Media Security and Privacy Checklists if you, like me, would rather have a series of boxes to mark off while going through each step above.
Security experts know that you can’t erase the possibility of risk, and it can be counterproductive to build a plan to that expectation. What is realistic and achievable is identifying risk so you know what you’re up against, mitigating risk by following security best practices, and isolating risk where possible so that in the event of an incident, one failure doesn’t have a domino effect affecting other resources. If that seems a bit abstract, let’s take a look at a practical example.
Tech journalist Mat Honan was the unlucky victim of a targeted hack, which resulted in a near-complete lockout from his digital life requiring a Herculean effort to recover. Fortunately for us, Mat documented his experience in the Wired story, “How Apple and Amazon Security Flaws Led to My Epic Hacking,” which offers an excellent summary of exactly the type of domino effect I described. I encourage you to read the full article, but for a CliffsNotes version sufficient for our needs here:
Honan’s article goes into much more detail, including some of the changes made by the services exploited to prevent similar incidents in the future. The key takeaway is that having a couple of emails without strong authentication tied to all his most important accounts, including the recovery of these email accounts themselves, meant that the compromise of his Amazon account quickly snowballed into something much bigger.
We’re going to learn from that painful lesson, and do some segmentation on our email channels based on the priority and how public we want that account to be. (“Segmentation” is an industry term that can be mostly boiled down to “don’t put all your eggs in one basket”, and keep critical or vulnerable resources separate from each other.) I would suggest setting up a few different emails, listed here from least- to most-public:
For all of the above, of course, we’ll create strong passwords and set up 2FA. And speaking of 2FA, you can use the same split-channel approach we followed for email to set up a dedicated verification number (using a VOIP service or something like Google Voice) when sending a passcode by SMS is the only option supported. Keeping these recovery numbers separate from your main phone number reduces the risk of them being leaked, sold, or captured in an unrelated breach.
Good news: We’re almost done with doxxing ourselves! In the next section, we’ll sweep out those unused accounts to avoid leaving data-filled loose ends and take a look at how data brokers profit off of your personal information and what you can do to opt-out.
You’ve made it this far so maybe you’re passionate like we are about developing innovative ways to make security accessible. We’d love for you to join our mission.
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
Just a few years ago when the topic of supporting offsite workers arose, some of the key conversation topics were related to purchase, logistics, deployment, maintenance and similar issues. The discussions back then were more like “special cases” vs. today’s environment where supporting workers offsite (now known as the hybrid workforce) has become a critical mainstream topic.
Now with the bulk of many organization’s workers off-premise, the topic of security and the ability of a security vendor to help support an organization’s hybrid workers has risen to the top of the selection criteria. In a soon to be released Cisco endpoint survey, it’s not surprising that the ability of a security vendor to make supporting the hybrid workforce easier and more efficient was the key motivating factor when organizations choose security solutions.
Today, when prospects and existing customers look at Cisco’s ability to support hybrid workers with our advanced security solution set and open platform, it’s quite clear that we can deliver on that promise. But, yes, good tools make it easier and more efficient, but the reality is that running a SOC or any security group, large or small, still takes a lot of work. Most organizations not only rely on advanced security tools but utilize a set of best practices to provide clarity of roles, efficiency of operation, and for the more prepared, have tested these best practices to prove to themselves that they are prepared for what’s next.
Knowing that not all organizations have this degree of security maturity and preparedness, we gathered a couple of subject matter experts together to discuss 5 areas of time-tested best practices that, besides the advanced tools offered by Cisco and others, can help your SOC (or small security team) yield actionable insights and guide you faster, and with more confidence, toward the outcomes you want.
In this webinar you will hear practical advice from Cisco technical marketing and a representative from our award winning Talos Threat Intelligence group, the same group who have created and are maintaining breach defense in partnership with Fortune 500 Security Operating Centers (SOC) around the globe.
You can expect to hear our 5 Best Practices recommendations on the following topics;
Check out our webinar to find out how you can become more security resilient and be better prepared for what’s next.
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
You probably don’t have to ditch your phone just yet – try these simple tips and tricks to make any Android device or iPhone run faster
The post Why your phone is slow – and how to speed it up appeared first on WeLiveSecurity
A stealthy cryptocurrency mining operation has been spotted using thousands of free accounts on GitHub, Heroku and other DevOps outfits to craft digital tokens. GitHub, for one, forbids the mining of coins using its cloud resources.…
Just over 3 years ago now, I sat down at a makeshift desk (ok, so it was a kitchen table) in an Airbnb in Olso and built the authenticated API for Have I Been Pwned (HIBP). As I explained at the time, the primary goal was to combat abuse of the service and by adding the need to supply a credit card, my theory was that the bad guys would be very reluctant to, well, be bad guys. The theory checked out, and now with the benefit of several years of data, I can confidently say abuse is near non-existent. I just don't see it. Which is awesome 😊
But there were other things I also didn't see, and it's taken a while for me to get around to addressing them. Some of them are fixed now (like right now, already in production), and some of them will be fixed very, very soon. I think it's all pretty cool, let me explain:
A little more background will help me explain this better: in the opening sentence of this blog post I mentioned building the original authenticated API out on a kitchen table at an Airbnb in Oslo. By that time, everyone knew I was going through an M&A process with HIBP I called Project Svalbard, which ultimately failed. What most people didn't know at the time was the other very stressful goings on in my life which combined, had me on a crazy rollercoaster ride I had little control over. It was in that environment that I created the authenticated API, complete with the Azure API Management (APIM) component and Stripe integration. It was rough, and I wish I'd done it better. Now, I have.
In the beginning, I pushed as much of the payment processing as possible to the HIBP website. This was due to a combination of me wanting to create a slick UX and frankly, not understanding Stripe's own UI paradigms. It looked like this:
Cards never ended up hitting HIBP directly, rather the site did a dance with Stripe that involved the card data going to them directly from the client side, a token coming back and then that being used for the processing. It worked, but it had numerous problems ranging from lack of support for things like 3D Secure payments, no support for other payments mechanisms such as Google Pay and Apple Pay and increasingly, large amounts of plumbing required to tie it all together. For example, there were hundreds of lines of code on my end to process payments, change the default card and show a list of previous receipts. The Stripe APIs are extraordinarily clever, but I couldn't escape writing large troves of my own code to make it work the way I originally designed it.
Two new things from Stripe since I originally wrote the code have opened up a whole new way of doing this:
Rolling to these services removed a huge amount of code from HIBP with the bulk of what's left being email address verification, API key management and handling callbacks from Stripe when a payment is successful. What all this means is that when you first create a subscription, after verifying your email address, you see these two screens:
That's the embeddable pricing table following by Stripe's own hosted payment page. I left the browser address bar in the latter to highlight that this is served by Stripe rather than HIBP. I love distancing myself from any sort of card processing and what's more, everything to do with actually taking the payment is now Stripe's problem 😊 If you're interested in the mechanics of this, a successful payment calls a webhook on HIBP with the customer's details which updates their account with a month of API key whilst the screen above redirects them over to the HIBP website where they can grab their key. Easy peasy.
I silently rolled this out a week ago, watched it being used, made a few little tweaks and then waited until now to write about it. The rollout coincided with a typical email I've received so many times before:
First of all I would like to thank you for the wonderful service that helps people to keep track of their email breaches. I was trying to build a product to provide your services via my website, something similar to Firefox, avast and 100's of other companies doing. We were trying to do it according to the guidelines mentioned in the website. However I am not able to renew my purchase due to payment gateway failures at stripe payment. Requesting you to kindly check the same and advise me on alternate methods for making the payment.
The old model often caused payments to be rejected, especially from subscribers in India. The painful thing for me when trying to help folks is that Stripe would simply report the failed payment as follows:
However, going back to the individual who raised the query above after rolling out this update, things changed very dramatically:
To the title of this section, I simply wasn't "Striping" right. I'm sure there's a way with enough plumbing that it's feasible, but why bother? I cut hundreds of lines of code out just by delegating more of the workload back to them. Further, with ever tightening PCI DSS standards (read Scott's piece, interesting stuff) the less I have to do with cards, the better.
This was a "penny drop" moment for me and it's already made a big difference in a positive way. But there's another penny that dropped for me at the same time: one-off keys were an unnecessary problem.
It was at the moment I was ripping out those hundreds of lines of code that I wondered: why do I have all the additional kludge to support the paradigm of a one-off key that only lasts a month? Why had I built (and was now maintaining) server side code to handle different types of purchases and UX paradigms to represent one-off versus recurring keys? My gut feel was that most payments formed part of an ongoing subscription but hey, who needs gut feels when you have real data?! So I pulled the numbers:
Only 7% of payments were one-offs, with 93% of payments forming part of ongoing subscriptions.
And so I killed the one-off keys. Kinda, because you can still have a key for only one month, you just purchase a monthly subscription then immediately cancel it via the Stripe Customer Portal:
That's linked into from the API key dashboard on HIBP and it'll take all of 5 seconds to do (also note the ability to change payment method directly on the Stripe site). I've added text to that effect on the HIBP website (you may have spotted that in the earlier screen cap) so in practice, the ability to purchase a one-off key is still there and the main upside of this is that I've just killed a trove of code I no longer have to worry about 🙂 Because this is the internet, I'm sure someone will still be upset, but if you only want a key for a month then that capability still well and truly exists.
All of this so far amounts to doing the same things that were always there but better. Now let's talk about the all new stuff!
The title is self-explanatory and "very soon" is in about 2 weeks from now 😎
Let me illustrate the first part of that title with a message I received recently:
Is there a way to procure a 10 year API key? Our client wants to use the Have I been Pwned plugin for [redacted service name]; however, the $3.50 monthly subscription is too small to go through procurement.
What's that saying about no good deed going unpunished? In my naivety, I made the pricing low with the thinking that was a good thing, yet here we are with that posing barriers! This was a recurring message over and over again with folks simply struggling to get their $3.50 reimbursed. I should have seen this coming after years of living the corporate life myself (I have vivid flashbacks of how hard it was to get small sums reimbursed), and filling out an untold number of expense reports. Speaking of which, this was another recurring theme:
Is there a way to pay yearly for HIBP API access vs monthly? Monthly adds overhead in paperwork.
And again, I get it, this is a painful process. It somehow feels even more painful due to the fact the sum is so low; how much time are people burning trying to justify $3.50 to their boss?! It's painful, and this likely explains why the request for annual payments is the second most requested idea on HIBP's UserVoice. The comments there speak for themselves, and I'm having corporate PTSD flashbacks just reading them again now!
Sticking with the UserVoice theme, the 5th most requested feature is for different pricing on different rate limits. This is mostly self-explanatory but what I wasn't aware of until I went and pulled the stats was just how many people were hacking around the rate limit problem. There are heaps of API accounts like this:
FreshRSS 
hibp+1@domain.com
hibp+2@domain.com
hibp+3@domain.com
...Because there can only be one key per email address, organisations are creating heaps of unique sub-addressed emails in order to buy multiple keys. This would have been a manual, laborious process; there's no automated way to do this, quite the contrary with anti-automation controls built into the process. Further, each key has it's own rate limit so I imagine they were also building a bunch of plumbing in the back end to then distribute requests across a collection of keys which, yeah, I get it, but man that seems like hard work! When I say "a collection of keys", I'm not just talking about a few of them either; the largest number of active in-use keys by a single organisation is 112. One hundred and twelve! The next largest is 110. I never expected that 🤯 (Incidentally, these orgs and the others obtaining multiple keys are all precisely the kinds I want using the API to do good things.)
Building the mechanics of annual billing and different rate limits is only part of the challenge and most of that is already done, the harder part is pricing it. I'm pulling troves of analytics from APIM at present to better understand the usage patterns, and it's quite interesting to see the data as it relates to requests for the API:
There's no persistent logging of the actual queries themselves, but APIM makes it easy to understand both the volume of queries and how many of them are successful versus failed, namely because they exceed the existing rate limit or were made with an invalid (likely expired) key. So, that's what I need to work out over the next couple of weeks when I'll launch everything and write it up, as always, in detail 🙂
The HIBP API has become an increasingly important part of all sorts of different tools and systems that use the data to help protect people impacted by data breaches. The changes I've pushed out over the last week help make the service more accessible and easier to manage, but it's the coming changes I'm most excited about. These are the ones that will make life so much easier on so many people integrating the service and, I sincerely hope, will enable them to do things that make a much more profound impact on all of us who've been pwned before.
Go and check out how the whole API key process works, I'd love to hear your feedback 😊
Japan's plan to phase out public health insurance cards in favor of linking the services to a digital ID card could compel those who oppose the digitization to sign up.…
The prolific pro-Beijing Dragonbridge crew has apparently stepped up its activity ahead of the US 2022 midterms by trying to discourage Americans from voting as well as pinning the Nord Stream pipeline explosion on Uncle Sam.…
Mark Sokolovsky, 26, a Ukrainian national, is being held in the Netherlands while he awaits extradition to America on cybercrime charges, the US Justice Department said on Tuesday.…
Cisco says miscreants are exploiting two vulnerabilities in its AnyConnect Secure Mobility Client for Windows, which is supposed to ensure safe VPN access for remote workers.…
Microsoft appears to have woken up and realized it may have left certain Windows Server and Windows 10 systems exposed to exploitable drivers for years.…
As package delivery scams that spoof DHL, USPS and other delivery companies soar, here’s how to stay safe not just this shopping season
The post Parcel delivery scams are on the rise: Do you know what to watch out for? appeared first on WeLiveSecurity
Today we’re examining some of the revelations in the Q3 Cisco Talos Incident Response Trends Report. This document is an anonymized look at of all the engagements that the Cisco Talos Incident Response team have been involved in over the previous three months. It also features threat intelligence from our team of researchers and analysts.
To start, take a watch of this episode of ThreatWise TV which explores how these trends have evolved since the previous quarter. Our guests also talk about incidents and cyber-attacks that they themselves have consulted on recently, including a particularly interesting insider threat case.
Ransomware returned as the top threat this quarter, after commodity trojans narrowly surpassed ransomware last quarter. Ransomware made up nearly 18 percent of all threats observed, up from 15 percent last quarter. Cisco Talos Incident Response (CTIR) observed high-profile families, such as Vice Society and Hive, as well as the newer family Blast Basta, which first emerged in April of this year.
Also noteworthy is the fact that CTIR saw an equal number in ransomware and pre- ransomware engagements this quarter, totalling nearly 40 percent of threats observed. Pre-ransomware is when we have observed a ransomware attack is about to happen, but the encryption of files has not yet taken place.
Pre-ransomware comprised 18 percent of threats this quarter, up from less than 5 percent previously. While it’s difficult to determine an adversary’s motivations if encryption does not take place, several behavioral characteristics bolster Talos’ confidence that ransomware may likely be the final objective. In these engagements adversaries were observed deploying frameworks such as Cobalt Strike and Mimikatz, alongside numerous enumeration and discovery techniques.
Commodity malware, such as the Qakbot banking trojan, was observed in multiple engagements this quarter. In one engagement, several compromised endpoints were seen communicating with IP addresses associated with Qakbot C2 traffic. This activity coincides with a general resurgence of Qakbot and its delivery of emerging ransomware families and offensive security frameworks that we have not previously observed Qakbot deploy. This comes at a time where competing email-based botnets like Emotet and Trickbot have suffered continued setbacks from law enforcement and tech companies.
Other threats this quarter include infostealers like Redline Stealer and Raccoon Stealer. Redline Stealer was observed across three engagements this quarter, two of which involved ransomware. The malware operators behind Raccoon introduced new functionality to the malware at the end of June, which likely contributed to its increased presence in engagements this quarter.
As infostealers have continued to rank highly in CTIR engagements, let’s explore them in a bit more detail.
Throughout the incidents discussed over the last few quarters, and CTIR engagements in general, information stealing plays a big part of the attackers’ TTPs.
From a high level, infostealers can be used to gain access a variety of sensitive information, such as contact information, financial details, and even intellectual property. The adversaries involved often proceed to exfiltrate this information and may then attempt to sell it in dark web forums, threaten to release it if a ransom isn’t paid, among other things.
While these instances can and do crop up in CTIR engagements, many of the infostealers seen in this space are used for accessing and collecting user credentials. Once an attacker has gained an initial foothold on a system, there are many places within an operating system that they can look for and collect credentials through the practice of credential dumping.
These stolen credentials may be offered up for sale on the dark web, alongside the stolen information mentioned above, but they can also prove to be a key weapon in an attacker’s arsenal. Their usefulness lies in one simple concept—why force your way into a system when you can just log in?
There are several advantages for bad actors that use this approach. Probably the most oblivious of these is that using pre-existing credentials is far more likely to go unnoticed than other more flagrant tactics an attacker can use. If part of the goal of an attack is to remain under the radar, activities carried out by “known users” are less likely to trigger security alerts when compared to tactics such as exploiting vulnerabilities or downloading malware binaries.
Adversaries tend to seek credentials with higher privileges, allowing them further control over the systems they compromise, with those including administrative access being the crown jewels.
User credentials can not only provide an attacker with means to elevate privileges and establish persistence on a system, but also to move laterally through a network. Some credentials, especially those with administrative privileges, can offer access to multiple systems throughout a network. By obtaining them, many more options become available to further an attack.
There are several threats involved in information stealing that appear repeatedly in CTIR engagements over the last few quarters.
Perhaps the most notorious is Mimikatz—a tool used to pull credentials from operating systems. Mimikatz is not malware per-se and can be useful for penetration testing and red team activities. But bad actors leverage it as well, and over the last few quarters CTIR has observed it being used in ransomware-as-a-service attacks, as well as pre-ransomware incidents.
CTIR has also observed Redline Stealer being utilized by adversaries in CTIR engagements across quarters. This infostealer has grown in popularity as a supplementary tool used alongside other malware. On more than one occasion, CTIR has identified stolen credentials on the dark web that claimed to have been obtained via Redline Stealer.
Other information stealers seen across the last few quarters include the Vidar information stealer, Raccoon Stealer, and SolarMaker, all of which have been used to further an adversary’s attacks.
Over the last several months, Talos has seen an increasing number of engagements involving insider threats. In one engagement this quarter, passwords were reset through a management console of a perimeter firewall that a disgruntled employee had access to.
The organization’s team changed all associated passwords but overlooked one administrative account. On the following day, someone logged in using that account, deleted all other accounts and firewall rules, and created one local account, likely to provide persistence.
You’ll hear Alexis Merritt, Incident Response Consultant for Cisco Talos, talk about this more in the ThreatWise TV episode.
To help protect against this threat when an individual leaves an organization, steps like disabling accounts and ensuring that connections to the enterprise remotely through VPN has been removed can be very valuable. Implementing a mechanism to wipe systems, especially for remote employees, is important as well.
For more on this topic, Cisco Secure recently put together a white paper on the Insider Threat Maturity FrameWork.
In several incidents over the last few quarters that involved information stealers, multi-factor authentication (MFA) was not properly implemented by the organizations impacted, providing adversaries an opportunity to infiltrate the networks. MFA tools like Cisco Secure Access by Duo can prevent attackers from successfully gaining access.
And finally, Cisco Advisory CISO Wolfgang Goerlich has created this storytelling video, to help people think about incident response in a new way:
Join the Cisco Talos Incident Response team for a live debrief of the Q3 report on 27th October.
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
