schroeder

and I'm out - you are irrational and unhinged

only yours

I don't even need to justify it! But I'll tell you for the purposes of showing you how inappropriate you've been with no data. If violated 4 different guidelines: 1) it was AI-generated 2) it was not attributed to AI 3) it relied on links to provide the full answer, but the links were not explained, and 4) it never actually answered the question. I provided guidance for how their next post could be improved, which they have the opportunity to do. So, there is no "unprofessional" conduct here.

and no, it is not your "right" to see deleted posts

yes, I CAN expect you to be cool

you are making guesses ... without proper data

so, chill out. Get curious, not judgemental

t jump to conclusions and assume I was doing something wrong when you have no evidence.

you've jumped to the conclusion that I have been unprofessional and threatened escalation, when you have no idea why I did what I did. This is an open place, but there are standards. My job as a Mod is to uphold those standards. And I would appreciate it if you didn

I am not attacking at all. I'm explaining. I'm deleting the comments that violate our code of conduct. It's either that or a ban. Which would you prefer?

You are new here, so please read the code of conduct. Any attacks on people are not tolerated. At all. Your account would get banned. So, play nice. Be professional.

Uh, but that wasn't what your first question was. So, no, you have to take the actions taken in context and in order. And, as I have said a few times now, this answer that you have settled on is not the universal answer. So... it's not an answer to what you asked. I'm not sure what else to say.

You are seeing a conflict where there is none. I'm simply explaining why this can't be answered here. Also to note: it is not guaranteed that the web server runs as root. That's a general guess. But like we've been trying to explain, you can only know what affects a specific device by knowing the architecture.

"What is the authentication system architecture of this device?" is not on-topic here

... of course I'm not answering the question (that's why it is closed). So, let's talk about your assumptions in the question. You assume there there would be an RCE vulnerability in just the web service and no other vulnerability that the RCE could leverage, and you want to know what reach that vulnerability might have based on the architecture of the authentication system on this device. Cool. The answer will depend on the architecture of this one device. We cannot know that or it is in public docs. Which is what I said before.

So, to understand what is and is not exposed requires a deconstruction of the device code. And not only will we not do that for you, if that architecture was available publicly, then the answer would simply be a link to that document.

Again, this is a simplistic understanding of web security. If you have an RCE within the web service context, then you have to suspect that the entire device is compromised. So any notion of "you can pwn the web service but nothing else on the the device" is naive. If you can RCE, then you are in immediate danger of full perms elevation.

"the attacker cannot bypass the verification even if the web server is hacked" -- this is a strange opinion. Why do you believe this? If the device's web service is hacked, why isn't the entire device in jeopardy? And as stated before, different manufacturers might do different things. So, I'm not sure this is a security question. You would need to deconstruct this device's code to sort all that out.

@JeffFerland did you mean to mention this on the Mod channel? There are no active discussions.

Anyone know a QSA I can chat to? I have a question about a MSSP needing PCI-DSS compliance to manage a client's firewall logs. What level of compliance required, what questions to ask, etc.

The details do not need to persist here for a report somewhere else. Reddit is a common place for these types of investigations.

"Why would Microsoft allow malware in Github?" is not a security question. The suggestion to make this a blog post is a good one. It's just not an answerable question here.

If you have a specific, answerable question about that? then maybe. But as it stands, this is phrased as "this is a problem! they shouldn't do that! don't you agree?"

"Why did some company allow some non-optimal thing to happen?" is not something we can answer

@Ramhound I'm not saying authentication is happening. I'm saying the Google OAuth process gets pre-seeded with the account name using the google cookie already in browser. This becomes a "how do I manage a browser or how do I prevent cookies from being passed to websites" which is not a security question but a common tool use problem.

Right, so how does this happen? Cookies.

Please answer my questions above and I'll be able to explain more

... you don't understand how SSO works?

Use incognito to browse without this data being passed or don't log into the browser with an account. Or use a browser where you can't log into a profil

"I am currently logged in my Gmail account," ... and you are seeing your gmail address in the pre-filled part ... that's what's being filled in. How are you logged into gmail? What user account are you using to use Edge?

A CISO and similar departments are a "risk absorbing" function. And where they sit in an org tends to be where the "messy bits" are.

So, let's add that to the mix: you can't "fix" risk management until you "fix" digital technology and you "fix" people. Actual Risk Management is about responding to and accounting for that fear that so often gets used in decision-making.

And that's an element of Risk Management that you can't ignore; fear, uncertainty, doubt, the desire to take the safe but inefficient path in the name of "risk management" when they aren't doing risk management, but reacting to fear.

So, it becomes very convenient to use a CISO (or similar) as a 3rd party demanding that things be done. It means that blame can be avoided.

There is also a conflict of interest. If a risk mitigation requires the system to be shut down at an inconvenient time, all experience (and research done into these matters) show that they will delay that until the risk grows to a highly unacceptable state, well above the normal risk appetite. Why? Fear. Fear of being blamed if the patch doesn't work smoothly, fear of appearing incompetent.

Let's also look at your other example. Can't system owners also own the vulnerability management within those systems? Of course. The practical problem, as in the "hallway" example, is that they are responsible for the proper operation of the system, with most risk concerns being about operational availability. Do they have the requisite experience to understand the risks of SMS MFA? Not many do. So, it takes an outside expert to see that risk in context and work with the system owner

You can't "fix" digital risk management until you "fix" digital technology. And we've been trying to do that since the ENIAC, and things have only trended to become more complex, more layered, and more uncertain, with all evidence showing that we will only get more of that, not less.

So, in many orgs, the CISO is the "chief digital uncertainty officer" and "chief auditor wrangler". But not even that is universal.

But there are compliance issues, too, and more and more every year. So, someone who understands all these risks and how the org deals with them needs to lead that conversation too. Because even ISO 27001 has a ton of room for interpretation and nuance.

That's where a CISO comes in; someone who is charged with thinking about the new and wonderful ways things could all blow up. So, it makes sense for them to be in L1 to provide that influence, leadership, and vision.

Could the hallway owner be charged with all this? Of course. It's just not common. People have university degrees in "hallways" and are experts, but they still might not know how to even approach the idea of this kind of risk.

The person "in charge" of that hallway is charged with making sure it functions as a viable pathway. How people breathe as they walk is not a normal thing to expect a "hallway owner" to even think about. So, you need someone who DOES think about such things.

That means that someone has to waltz in and impose restrictions on how people and departments operate within their day-to-day. That hallway? Yes, you must hold your breath as you walk down it because the heat from your breath might inadvertently cause a hazard condition. Who should be responsible for such a seemingly arbitrary decision?

How do you manage that risk? You get very concerned about how people use the building, how much heat is used in normal operation, making building use as predictable as possible, and getting really good at detecting and extinguishing fires.

So, imagine trying to manage fire risks when every week, builders come in an replace parts of a building's interior AND exterior with untested materials. Yet those materials are crucial to the function and viability of the building as a whole; i.e. you can't refuse them.

You can't use the same risk management techniques for cyber as you do for fire. Because with every patch, every new technique, and every zero-day, the "nature of fire" changes and the "flammability of materials" fundamentally changes.

And cyber risk is exceedingly complex and ever-evolving. You made a comparison to fire risk. Let's talk about that. Fire is fire. Its nature doesn't change and the flammability of materials is set, knowable, and predictable. The uncertainty is simply when a hazard event might occur.

Risk isn't real.

"Can we not fix risk management?" and the bias emerges ... :)

For example, are you aware of the separation between a CISO, a CSO and a BISO? There are many, many ways to introduce the required separation to manage risk.