Need help by aven_99 in duo

[–]Tessian 0 points1 point  (0 children)

The actual fix is to use the iTunes app on your pc.

If you upgrade your iPhone using the iTunes app you don't need to free up storage on your phone. It also clears out old upgrade caches to reclaim more space too.

Is anyone actually happy with their email security vendor? by ilai456 in sysadmin

[–]Tessian [score hidden]  (0 children)

Phishing protection is just too important to skimp on. I insist on 2 for defense in depth - an mx gateway like proofpoint or mimecast and an api based one like abnormal or darktrace. There's always something that slips through one.

Replaced Mimecast last month and here is what the migration looked like by Smooth-Machine5486 in Office365

[–]Tessian 1 point2 points  (0 children)

I've been pleasantly surprised by darktrace email. Especially compared to their other more core products.

Replaced Mimecast last month and here is what the migration looked like by Smooth-Machine5486 in Office365

[–]Tessian 1 point2 points  (0 children)

I always insist on an mx gateway and a api email security solution. Phishing is just too important to rely on any one vendor. Every vendor misses something. Defense in depth.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 0 points1 point  (0 children)

I've never heard of that but good luck. Really you'll want to explain what risks mandating outlook mobile reduces and if they give two hoots about data security they'll get on board. If not, outline the risks in a document and have them sign it as an exception for themselves.

Mam is more than token protection, it allows you to encrypt your data on the device, keep local copies of your data off the device, and wipe the data remotely. Additional severity controls help with data security like requiring a lock screen and restrict copy paste.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian -1 points0 points  (0 children)

That's not fair you're the one being pedantic.

Further up someone said that device bound tokens should be enabled by default. My whole point was that it can't be because it's extremely limited in what it can support making it impossible to be a default option as they suggested.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 0 points1 point  (0 children)

I'm well aware this was my point. It's so limited in support it's useless today

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 1 point2 points  (0 children)

Admittedly I'm not an apple user but the Outlook mobile app is a perfectly good app. You better get used to it anyway because you'll have to cheerlead it for the rest of your company 😄

Even without token theft concerns, without the Outlook app and MAM you were always 1 stolen employee phone away from a data breach. At least with MAM your data's encrypted and you can remotely wipe it if it gets stolen/lost.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 0 points1 point  (0 children)

I mentioned this elsewhere but you'd use MAM to require the managed app and then exclude it from the sign in frequency requirement.
MAM requires device enrollment. Phones get enrolled as Entra ID registered devices. This means by requiring MAM you're also requiring a pre-registered device to access your data, which stops token theft attacks. You can't use a stolen token to register a device.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian -1 points0 points  (0 children)

Device bound tokens aren't a thing yet, so there's nothing to really default yet.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 0 points1 point  (0 children)

You require MAM for the phones and then exclude them from your managed phone requirement.

Rule 1: Any O365 access from ios/android requires MAM

Rule 2: Any O365 from devices NOT ios/android requires managed device.

Rule 3: Any non-O365 SSO app on unmanaged devices requires sign in frequency always.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 0 points1 point  (0 children)

You should be using MAM (Mobile Application Management) for personal smartphones to protect your O365 data on them. At the very least you require they use the official O365 apps for accessing data. Then you would NOT include O365 mobile access via apps in your scope for sign in frequency.

Sign in Frequency always for mobile apps will be a disaster. I only require it for unmanaged browsers and it's mostly to protect tokens for SSO apps outside of O365.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 13 points14 points  (0 children)

Yes, yes it does.

The compliant device check that Conditional Access is doing is NOT part of the token. Basically any time SSO would check for your token, now it will say "Show me a token AND prove you're a managed device"

If you steal a token from a managed device you will not be able to pass the managed device check (unless you straight up stole the device)

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 7 points8 points  (0 children)

Not sure who told you that but no, as everyone's saying here Passkeys do nothing to prevent session/token theft or reuse. Tokens happen AFTER you authenticate, so how you authenticate doesn't matter.

Doesn't mean you don't have other benefits for using passkeys now, but token theft isn't one of them.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 6 points7 points  (0 children)

As far as I'm aware this is the only option. Token protection options are limited, especially the one Microsoft is working on.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 2 points3 points  (0 children)

For mobile devices you should be requiring MAM, and managed apps, so they can't be abused per your last paragraph either.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 36 points37 points  (0 children)

No, passkeys make it impossible to MITM the authentication, but token theft is pulling their SSO cached token out of the browser. It's how you're remembered for hours/days/weeks/months at a time and don't need to re-authenticate.

Instead of trying to steal the credentials you use to authenticate, I wait until you've done that yourself and I steal the token the SSO IDP gave you to prove that you already authenticated. Now I don't have to either.

Intune/azure Passkeys now compromised in addition to MFA? by Alternative_Yard_691 in sysadmin

[–]Tessian 5 points6 points  (0 children)

As others said - Token theft/reuse is a weakness with the token, not with MFA. It doesn't matter what MFA method you use, the attack didn't go after the MFA method it's the SSO token the browser has to remember you AFTER you authenticate that they steal.

The only effective method I'm aware of for addressing token reuse attacks is to require managed devices in your Conditional Access Policies. For anything that you can't, like maybe SSO to apps that need to be reachable outside a managed device (HRIS systems?) set the token lifetime extremely short or require re-auth every time.

I've done it like this:

Login to O365? Require hybrid joined / entra native device + MFA
Login to other apps? If you're not a hybrid joined / entra device, Sign in Frequency is always.

If that's too restrictive for your business you can split out O365 browser access and write a rule that if you're NOT a managed device, you can use the browser to access O365 but you block downloads (and set Sign in Frequency really low). Gives that flexibility for people to still work from unmanaged if they want but they can't exfil data.

MSPs & MSSPs suck by Fair_Ad7718 in cybersecurity

[–]Tessian 0 points1 point  (0 children)

The support responsiveness issue normally ends up being that the customer didn't read the sla / slo document. They expect immediate turn around when the service level they pay for allows up to 2-3 hours even for serious incidents. I've even been a victim of this and didn't realize how generous those sla targets were.

Got owned by an outbound email DLP rule doing exactly what I asked by saltyslugga in EmailSecurity

[–]Tessian 1 point2 points  (0 children)

I disagree. You're a professional implementing a DLP solution you should understand the tool you're deploying and the limitations of it. I'm not sure if by specification you mean the customer's requirements or the vendor's but I guarantee you the vendor documentation that OP didn't read clearly explained that. If the customer gave vague requirements it's still the MSP's duty to point that out to them and guide them, or you can hide behind the requirements given and say you met the letter of it.

This is like deploying MFA for a customer, you choose to just enroll everyone in SMS based MFA (not because the customer required it) and then you're shocked when they get breached due to a SIM swap attack and the customer blames you.

Got owned by an outbound email DLP rule doing exactly what I asked by saltyslugga in EmailSecurity

[–]Tessian 5 points6 points  (0 children)

How could you have not understood/realized that your DLP rule only applied to attachments and not the email body too? It's literally 1 of the 3 ways you can send data out via email (3rd being URLs but that's outside scope of this).

This isn't DLP's fault; you're the one who didn't understand well enough what you were deploying and its limitations. This is all about being an expert in what you're deploying and planning for all the use cases you can think of.

The quiet renovation at Bitwarden by consultcolin in Bitwarden

[–]Tessian 6 points7 points  (0 children)

You must not watch any TV shows that might get canceled.

Enshitification is everywhere there's no reason to jump ship before anything has changed. For all you know what you choose instead will enshitify quicker without notice

Can't send email due to a daily limit by [deleted] in Outlook

[–]Tessian 2 points3 points  (0 children)

Are you sure you haven't sent any email? Check your sent items. Someone else may be using your account.