|
that's a bummer, I had gotten the impression of BCP as being important but boring but was hoping there was some secret sauce I was missing. thanks for confirming my impression. sadly it seems to pay more as well  not too sad though, I have liked doing risk work with my current internship quite a bit, and definitely can see it helping me go a more technical route down the line like some kinda jackal said. I really want to find my way to DevSec one day and the compliance and risk work seems like a good starting point.  for the input
|
#
?
Aug 10, 2022 20:42
|
|
|
|
| # ? May 30, 2024 21:27 |
|
|
I mean they're both important in their own way. I wouldn't take my negativity to heart too much. I see people flourish in these types of roles, and just because I don't much care for the work definitely doesn't mean it isn't 100% up someone's alley.
|
|
#
?
Aug 10, 2022 20:47
|
|
|
Business continuity can be fun, but as I said, it's more of a talking, meeting, management, networking (social kind) type deal, which doesn't appeal much to traditional cyber security nerds who are also computer touchers.
|
|
#
?
Aug 10, 2022 20:58
|
|
|
I love exporting things from a website only for them to change the position of the formatting for older reports. I can already see myself being annoyed at that lol
|
|
#
?
Aug 10, 2022 22:47
|
|
|
BonHair posted:Business continuity can be fun, but as I said, it's more of a talking, meeting, management, networking (social kind) type deal, which doesn't appeal much to traditional cyber security nerds who are also computer touchers. I took on my major to get out of "networking as a job" so glad I asked. I had hoped there might be some aspects of the field that are more techy problem solving but that doesn't seem to be the case. The field focus is still interesting so maybe I'll find my way to a BCP vendor or something one day.
|
|
#
?
Aug 11, 2022 01:45
|
|
|
https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html
|
|
#
?
Aug 11, 2022 03:05
|
|
|
quote:it was determined that a Cisco employee’s credentials were compromised after an attacker gained control of a personal Google account where credentials saved in the victim’s browser were being synchronized. Lol. Lmao.
|
|
#
?
Aug 11, 2022 03:38
|
|
|
CLAM DOWN posted:Lol. Lmao. This has to be such an incredibly huge attack vector. No one bothers to turn that off via policy.
|
|
#
?
Aug 11, 2022 04:26
|
|
|
Internet Explorer posted:This has to be such an incredibly huge attack vector. No one bothers to turn that off via policy. It’s more than just that. Do any of your orgs use macs? Do you have total control of all installed apps to the point you can rule out all 3rd party password managers along side of it? Do you block google devices all together to prevent some rear end in a top hat from putting a text file of password in their google drive? Phones? Even if you remediate everything , unless you force a mass rotation of all credentials the already sync’d cred could get you owned. At the end of the rabbit hole you realize the best you can do is protect things with even more than mfa and a password but “convenience”. The moral of the story is the person who got social engineered to complete the push of mfa needs to be banned from technology.
|
|
#
?
Aug 11, 2022 04:34
|
|
|
The moral of the story is that if an attacker getting VPN creds for some unprivileged user gives them the access to compromise your entire environment, your environment is not secure. And it's not, ultimately, the fault of the one poor sap who's VPN credential is the one that actually gets stolen.
|
|
#
?
Aug 11, 2022 05:10
|
|
|
Famethrowa posted:I took on my major to get out of "networking as a job" so glad I asked. I had hoped there might be some aspects of the field that are more techy problem solving but that doesn't seem to be the case. In that case, you're probably qualified to do the networking, but GRC also involves a ton of networking in my experience. It's relatively easy to write a policy saying "use mfa", but actually getting it implemented requires you to convince system owners, users and management that it's necessary, and that can only happen if you can work with them or have the authority to fire them. Same goes for getting people to report on controls or follow up on their risks or anything really. You do get to understand what they're doing and challenge them on their "my poo poo is secure" bullshit though, which is a lot more technical and also a lot of fun. But again, you gotta have a good relation if you want good answers.
|
|
#
?
Aug 11, 2022 06:26
|
|
|
Jabor posted:The moral of the story is that if an attacker getting VPN creds for some unprivileged user gives them the access to compromise your entire environment, your environment is not secure. And it's not, ultimately, the fault of the one poor sap who's VPN credential is the one that actually gets stolen. If it's exfiltered thanks to browser keychain compromise, i would still give the responsibility to the user. With the looming "issue" of passkeys services integrated in windows and macOS/iOS, having your keychain popped will mean even fido1/2 mfa being at risk if you are not careful.
|
|
#
?
Aug 11, 2022 07:16
|
|
|
SlowBloke posted:If it's exfiltered thanks to browser keychain compromise, i would still give the responsibility to the user. With the looming "issue" of passkeys services integrated in windows and macOS/iOS, having your keychain popped will mean even fido1/2 mfa being at risk if you are not careful. If the attacker leverages VPN access to compromise your entire infrastructure then no, the primary failing is your IT security and a complete lack of any meaningful defense in depth, the individual user getting popped is a very very distant second. Even in a reduced scenario where the attacker is only able to access stuff that the victim routinely needs to access for their job, if the devices you're provisioning make it easy for people's corporate credentials to be inadvertently leaked to somewhere you don't control then you're loving up.
|
|
#
?
Aug 11, 2022 08:16
|
|
|
So something was gnawing at me all day yesterday after I made that post about GRC and I realize in the back of my mind I was extremely unfair in my characterization of how policy work is typically ignored by an organization. Even if it was a tongue-in-cheek remark, it has a kernel of truth inasmuch as writing policies can be very frustrating because your output is generally a point in time deliverable and the whole process has a few issues I've encountered in my 10+ years in my IS or IS-adjacent career: - It's a fat document or set of documents that is usually incredibly verbose for fear that being terse will make it vague to be meaningful, OR the opposite, so vague and full of high level statements that it ends up saying absolutely nothing. - It's signed off by executives, but often a very poor job is done to move this knowledge down to the people actually tasked with understanding how these new policies apply to their daily efforts. - There is often a very poor feedback loop, if any at all, where improvements can be solicited for consideration to address on-the-ground challenges All of these are challenges, but also opportunities to help evolve your organization. I got into GRC not because I love paperwork and auditing and compliance, but because when I got to my last company I looked at the policy documents and said "what the gently caress" and started to get to work to figure out a way to help people apply this thicc set of legal-looking documentation to plain and simple nuts and bolts things they need to consider for their respective areas. No one is going to take fifteen minutes, let alone an hour, to just go try to understand your high level policy document out of the blue when they have 500 JIRA tasks they have to action before lunch, so I tried to figure out a way to make it more digestible and to become a resource people could come to to help understand the policies (in my area). Same with the feedback loop. In my existing role I almost strongarmed myself onto the GRC corporate policy team because there was no useful feedback cycle and there were things in there that were contradictory, imcomprehensible, or just plain wrong. I've tried to formalize feedback into the annual policy review cycle to various degrees of success, but again I tried to make myself a conduit for common sense feedback to improve our policies to reflect the situation on the ground and our obligations as they exist year over year. I don't mean this in a "wowee look at me I'm so nice" kind of way, but in the end a job is what you make it. I decided I'd rather try to fix the problem rather than complain about it and contribute to the white noise. In a way that in and of itself is satisfying, so that's what was kind of gnawing at me. The end result is that everyone everywhere is still very busy so the fruits of my efforts aren't as effective as I'd like. Computer touchers still don't have time to read even my cheat-sheet policy documents so in an architecture role I find I still need to micromanage requirements and verify implementations, one example, but I don't want it to sound like it's a bottomless chasm of despair or anything. So yeah. Policy work isn't "ignored" by an organization, I think most organizations just don't have the proper flow to actually make use of policies effectively.
|
|
#
?
Aug 11, 2022 11:38
|
|
|
Has anybody done a study on how often people just click the "approve" on MFA push prompts without thinking if they actually are trying to log into something? I wouldn't be surprised if for the average office worker it makes MFA completely redundant.
|
|
#
?
Aug 11, 2022 13:10
|
|
|
Jabor posted:The moral of the story is that if an attacker getting VPN creds for some unprivileged user gives them the access to compromise your entire environment, your environment is not secure. And it's not, ultimately, the fault of the one poor sap who's VPN credential is the one that actually gets stolen. Most environments are not secure, because most companies refuse to fund the architecture design changes needed to do so. The vast majority of companies still have large flat networks with nary the concept of segmentation.
|
|
#
?
Aug 11, 2022 13:15
|
|
|
Thanks Ants posted:Has anybody done a study on how often people just click the "approve" on MFA push prompts without thinking if they actually are trying to log into something? I wouldn't be surprised if for the average office worker it makes MFA completely redundant. I would bet on an 80/20 not looking/looking ratio.
|
|
#
?
Aug 11, 2022 13:32
|
|
|
Thanks Ants posted:Has anybody done a study on how often people just click the "approve" on MFA push prompts without thinking if they actually are trying to log into something? I wouldn't be surprised if for the average office worker it makes MFA completely redundant. This is what drives me crazy about Microsoft's MFA. Two-fold: On prompting for a password for SAML/SSO It just pops up the credential input screen for no reason sometimes when policies expire the token and I have to guess which of my legit apps is asking for my password, hoping it's me. I'll be using my laptop at home and like halfway through the day I'll just see a Microsoft login screen. Well, which of my twelve Microsoft apps have timed out now? Is it outlook? Is it Office? is it Teams? And then when I'm being prompted on authenticator to confirm, give me some context. Which application login requested MFA? Which IP is it coming from? Is it in my geographic area? It's not 1:1 because I very rarely log into iCloud, and certainly never enough to wonder whether the MFA prompt is something I triggered or not, but (leaving aside the fact that the device that requested the login is also shown the MFA code  ) if I did use it on the reg, that login MFA prompt would give me enough contextual information to at least say "yeah it's something on my home network" and not have to hope.So yeah, I'm as guilty of that as ever, because of the glut of MFA login requests from Microsoft. That's actually the only one though, but this is severely skewed because it's also the one that I use most often. I've never actually run into a situation where I received an MFA SMS or email I wasn't expecting, but they're infrequent enough that I am very confident I would scrutinize anything I wasn't expecting.
|
|
#
?
Aug 11, 2022 13:33
|
|
|
Thanks Ants posted:Has anybody done a study on how often people just click the "approve" on MFA push prompts without thinking if they actually are trying to log into something? I wouldn't be surprised if for the average office worker it makes MFA completely redundant. I ran a forensics response a year ago or so where a c level clicked yes and allowed scammers into his email. Luckily it didn't get further than that, but yeah, I get the feeling now that 2fa is more common we're going to switch to more of this happening. If somebody wants to make some bucks they can create a 2fa best practices training that enterprises can adapt.
|
|
#
?
Aug 11, 2022 13:44
|
|
|
some kinda jackal posted:This is what drives me crazy about Microsoft's MFA. Two-fold: I remember Authenticator showing you the source of the request with a app name/logo on the block screen/toast in an old a-b testing but being quickly killed since it hindered accessibility.
|
|
#
?
Aug 11, 2022 13:52
|
|
|
some kinda jackal posted:This is what drives me crazy about Microsoft's MFA. Two-fold: I do not use Microsoft's MFA tool, precisely because the pushes are annoying and concerning. I just used any other MFA app that only does the 6 digit pin.
|
|
#
?
Aug 11, 2022 14:05
|
|
|
CommieGIR posted:I do not use Microsoft's MFA tool, precisely because the pushes are annoying and concerning. I just used any other MFA app that only does the 6 digit pin. MFA with manual user pin typing can be subject to MITM so it's as concerning if not more than push notification-based MFA.
|
|
#
?
Aug 11, 2022 14:09
|
|
|
SlowBloke posted:MFA with manual user pin typing can be subject to MITM so it's as concerning if not more than push notification-based MFA. Anything can be subject to MITM, that doesn't really change much. Its still up to the user to ensure they are putting their credentials into a secure portal. But half of the MFA attacks assume a user is using MFA pushes rather than pins themselves. You can of course phish an MFA token from a user.
|
|
#
?
Aug 11, 2022 14:38
|
|
|
Obviously any sort of "VPN Access == Trusted" flat network architecture is terrible, but it seems they should have at least started down the road of using Conditional Access Policies to evaluate the auth attempt against a device compliance status or IP location. It wouldn't be a catchall but would still be useful as a mitigation.
|
|
#
?
Aug 11, 2022 15:15
|
|
|
CommieGIR posted:Anything can be subject to MITM, that doesn't really change much. Its still up to the user to ensure they are putting their credentials into a secure portal. But half of the MFA attacks assume a user is using MFA pushes rather than pins themselves. Physical FIDO2 are kinda hard to MITM since the intermediate portal would require to use the same address/namespace of the IdP. Cloudflare just had a big attack that went bust due to the intermediate attacker relying on user input of the codes when all CF uses physical yubikeys.
|
|
#
?
Aug 11, 2022 15:24
|
|
|
SlowBloke posted:MFA with manual user pin typing can be subject to MITM so it's as concerning if not more than push notification-based MFA. this doesn't follow.
|
|
#
?
Aug 11, 2022 15:35
|
|
|
some kinda jackal posted:This is what drives me crazy about Microsoft's MFA. Two-fold: LOL our environment uses windows mfa exclusively. I was wondering why outlook did this for our users. I usually just tell them to sign out and back in to avoid it, since it's just passed with SSO or something anyway
|
|
#
?
Aug 11, 2022 15:50
|
|
|
Achmed Jones posted:this doesn't follow. I read some theoretical or non-theoretical description of a social engineering scenario where you’re dealing with a false customer service representative who is attempting to access your account and asks you to provide the MFA codes while they are logging in themselves. I mean I make no claims as to its likelihood or what form it takes, but theoretically plausible. I mean a lot of things have to go wrong in this example, but yeah. The weakest link will always be the user. Even in a pushbutton MFA scenario, the CS rep would still tell you they need you to just approve and if you were naive enough to give them your MFA code then you’ll probably just push “allow” anyway. E: Microsoft’s Authenticator “enter the following number” MFA challenge is actually pretty legit for reflex-clicking I think? some kinda jackal fucked around with this message at 16:22 on Aug 11, 2022 |
|
#
?
Aug 11, 2022 16:20
|
|
|
some kinda jackal posted:I read some theoretical or non-theoretical description of a social engineering scenario where you’re dealing with a false customer service representative who is attempting to access your account and asks you to provide the MFA codes while they are logging in themselves. I mean I make no claims as to its likelihood or what form it takes, but theoretically plausible. Thats the issue. I believe thats what happened with the recent Twilio and Cisco incidents as well. Basically the attackers have already gotten access to creds, and then call up the end users pretending to be "security" or whoever and social engineer their way into the code provided by the 2 factor app. It's happened enough times to be noteworthy now and is a good reason to move towards app based codeless 2 factor.
|
|
#
?
Aug 11, 2022 16:24
|
|
|
Diva Cupcake posted:Obviously any sort of "VPN Access == Trusted" flat network architecture is terrible, but it seems they should have at least started down the road of using Conditional Access Policies to evaluate the auth attempt against a device compliance status or IP location. It wouldn't be a catchall but would still be useful as a mitigation.
|
|
#
?
Aug 11, 2022 16:40
|
|
|
Achmed Jones posted:this doesn't follow. Whoever takes the time and effort to mimic the user/password webpage can easily automatize credential push to your real IdP so it will generate the SMS/TOTP code request and make it possible to complete the login sequence with the user inserting it on the fake website. No telco hacking required.
|
|
#
?
Aug 11, 2022 16:40
|
|
|
Pablo Bluth posted:There's been at least one high profile cyberattack, the Colonial Pipeline hack, that used forgotten legacy VPN that was churning away in the corner unused and forgotten, just waiting for someone to figure out how to abuse it. This was in IT or OT?
|
|
#
?
Aug 11, 2022 17:48
|
|
|
SlowBloke posted:Physical FIDO2 are kinda hard to MITM since the intermediate portal would require to use the same address/namespace of the IdP. Cloudflare just had a big attack that went bust due to the intermediate attacker relying on user input of the codes when all CF uses physical yubikeys. Yes, they are and FIDO2 should be the goal, but the reality is most companies are not willing to spring for it yet financially. Its not a small cost. Trust me, been trying to sell FIDO2 and Physical Tokens for ages for a lot of my clients and my current full time. BaseballPCHiker posted:Thats the issue. I believe thats what happened with the recent Twilio and Cisco incidents as well. Basically the attackers have already gotten access to creds, and then call up the end users pretending to be "security" or whoever and social engineer their way into the code provided by the 2 factor app. It's happened enough times to be noteworthy now and is a good reason to move towards app based codeless 2 factor. Yeah but realistically codeless doesn't stop impersonation attacks or social engineering either. Can do the same attack, just ask them to accept the prompt rather than provide the token. That's a user education problem, not a technology one. CommieGIR fucked around with this message at 18:29 on Aug 11, 2022 |
|
#
?
Aug 11, 2022 18:27
|
|
|
I like codeless MFA because I am lazy. This is why I have enabled Yubikey auth on everything that will let me.
|
|
#
?
Aug 11, 2022 19:18
|
|
|
CommieGIR posted:Yeah but realistically codeless doesn't stop impersonation attacks or social engineering either. Can do the same attack, just ask them to accept the prompt rather than provide the token. exactly this. for different user populations and different technology stacks, one might be more vulnerable than the other. eg the thing mentioned above where microsoft auto-auths makes push-based worse than code-based. but if you don't use microsoft's stuff (or things that behave similarly badly), then maybe code-based is worse. if the main thing you're worried about is myfakeloginportal.compañy.ru then maybe it's a wash and you use whichever one is easier to implement so you can go do some other pressing thing, and come back to play the "which is better" game when you've turned down your vpn or something. realistically user education only goes so far, too, and can't be relied upon. so now you need to make it so that when the account is taken over, damage is limited. this includes the obvious principle of least privilege stuff, network location signals (to force the attacker to route through a company-managed device or similar), client-side detection, etc. also, please do not get me started on the terrible (but unfortunately pervasive) idea that "mitigation X can be defeated, therefore mitigation X is useless/the same as mitigation Y/etc"
|
|
#
?
Aug 11, 2022 22:16
|
|
|
Cup Runneth Over posted:I like codeless MFA because I am lazy. This is why I have enabled Yubikey auth on everything that will let me. yeah same. unfortunately im too lazy to set up my yubikey on anything but my highest-value personal stuff because it's too much of a pain in the rear end to use on my phone _and_ work laptop _and_ personal workstation _and_ vms i use etc. even there, most stuff i use totp instead of the hardware key just 'cause it's so dang inconvenient for work stuff it's great, though. i have a couple mobile yubikeys and a nano that is bound to my laptop and since i only do work from my work machine (which routes its mfa to destination machines as appropriate) it works great
|
|
#
?
Aug 11, 2022 22:20
|
|
|
Pro tip, if you haven't looked at storing your otp seeds on your yubikey you should! This combined with the yubico authenticator copies the relevant otp code to your clipboard after touching the key. You can also NFC tap the key to your phone to access the stored seeds. It's glorious.
|
|
#
?
Aug 12, 2022 01:31
|
|
|
schizophrenic posted:Pro tip, if you haven't looked at storing your otp seeds on your yubikey you should! Sadly yubikeys are limited to 32 otp seeds so, if have lot of sites seeds, you will have to purchase multiple keys to cover them all(i have the core ones on the yubi and the rest on authy).
|
|
#
?
Aug 12, 2022 06:19
|
|
|
is there a reason not to use the bitwarden OTP, other than having both passwords in the same place?
|
|
#
?
Aug 12, 2022 06:40
|
|
|
|
| # ? May 30, 2024 21:27 |
|
|
RFC2324 posted:is there a reason not to use the bitwarden OTP, other than having both passwords in the same place? If they pop your bitwarden password they can both login and MFA, that's the core issue(i have a similar scheme on keepass so i shouldn't be preaching on this). If you have a strong enough key you should be fine.
|
|
#
?
Aug 12, 2022 07:02
|
|