How weak passwords and other failings led to catastrophic breach of Ascension
- Thread starter JournalBot
- Start date
I haven't worked as a Windows sysadmin in 15 or so years, as my first "real" job, and I knew even then that NTLM was insecure. There was plenty of guidance from Microsoft on how to secure AD properly and avoid all of these problems. Any competent, properly-resourced IT department would have been able to do this, which strongly implies senior leadership didn't consider it to be a priority (let me guess, offshored IT handed out to either the lowest bidder or the CIO's nephew...).
Maybe jail time for CEOs whose companies fuck up this badly would prevent some of these issues, but somehow I doubt it.
Maybe jail time for CEOs whose companies fuck up this badly would prevent some of these issues, but somehow I doubt it.
Upvote
53
(55
/
-2)
What's the first thing that happens when there is a new CEO?
They cut the IT budget...
I think this also rings true to the story from yesterday about Boar's Head meat plants being filthy. Is it really worth the money you saved to have a disaster in the end? SMH
They cut the IT budget...
I think this also rings true to the story from yesterday about Boar's Head meat plants being filthy. Is it really worth the money you saved to have a disaster in the end? SMH
Upvote
45
(45
/
0)
Microsoft's defense is obvious and already discussed in the article: "we issued guidance telling people what to do, so it's not our fault that people don't listen."
The issue is that, as a provider of a massive infrastructure product, Microsoft needs to contend with the reality that most people simply don't read. Of those who do, only a small portion will have the time, inclination, or resources to harden a(n often legacy) network according to constantly-updating advice, especially when you factor in the pain point of retraining users.
Governments face a similar problem when designing laws. If everyone simply behaved, then we'd have no need for them. The presumption that enough people won't behave (maliciously or due to incompetence) as to cause aggregate dangers/harms is enough justification to introduce and enforce rules.
Big companies want the benefits of being "big" without taking responsibility for being the referee. And while in a narrow sense you can make an argument for that, you'll never see any executives admitting "our product is good unless you don't follow x, y, z recommendations published regularly unless there's a zero-day".
The issue is that, as a provider of a massive infrastructure product, Microsoft needs to contend with the reality that most people simply don't read. Of those who do, only a small portion will have the time, inclination, or resources to harden a(n often legacy) network according to constantly-updating advice, especially when you factor in the pain point of retraining users.
Governments face a similar problem when designing laws. If everyone simply behaved, then we'd have no need for them. The presumption that enough people won't behave (maliciously or due to incompetence) as to cause aggregate dangers/harms is enough justification to introduce and enforce rules.
Big companies want the benefits of being "big" without taking responsibility for being the referee. And while in a narrow sense you can make an argument for that, you'll never see any executives admitting "our product is good unless you don't follow x, y, z recommendations published regularly unless there's a zero-day".
Upvote
9
(15
/
-6)
Edit: I was wrong.
Doesn’t NTLM use the LAN Manager hashing algorithm that splits a 14 character password into two half 7 character passwords that are then hashed?
And that’s why Medin’s maths is wrong? Possibly leaving a 10 character password as two 5 character ones?
I had my 14 random character password cracked by a malicious, power-tripping sysadmin in 2008.
And that’s why Medin’s maths is wrong? Possibly leaving a 10 character password as two 5 character ones?
I had my 14 random character password cracked by a malicious, power-tripping sysadmin in 2008.
Last edited:
Upvote
0
(2
/
-2)
Politicians are trashcans, and companies cheap out on good sysad. News at 11.
Microsoft supports the legacy protocols still because we still have legacy networks, even in healthcare shock that need to use the old jank to function.
Microsoft supports the legacy protocols still because we still have legacy networks, even in healthcare shock that need to use the old jank to function.
Upvote
-2
(8
/
-10)
- Add bookmark
- Featured
- #8
Having done ESAE and hardened AD Deployments, you're definitely making a choice between availability and security. Between the PAW system, the tiered isolation, and everything that goes with it... the burden of overhead is brutally high.
Part of Microsoft's responsibility is not making some of the insecure options enabled by default, but part of it is investing in the AD product itself.
AD2025 is clearly just a heartbeat update, AD hasn't had serious work done on it in years as Microsoft tries to drag everyone kicking and screaming into the cloud
(And then they promptly prove every few months, why you shouldn't trust Microsoft with anything)
Everyone shares responsibility on this, Ascension was cheap and stupid. Microsoft has decided that one of the cornerstones of corporate identity is not worth investing in, since they can make more money in the cloud.
Upvote
39
(41
/
-2)
Microsoft needs to have backward compatibility off as a default if they want to blame the end user.
Upvote
3
(7
/
-4)
I'm intimately familiar with a financial services company with billions in AUM that patched this earlier this year, almost certainly in response to this breach. They at least enforce strong password requirements on service accounts by policy, hopefully in practice, so it sounds like they were likely safe. Does not inspire confidence though.
That company is such a mixed bag, software allow listing, strict segregation of AD accounts with admin rights from regular accounts, heavy network filtering, but misses basic stuff like this, doesn't enforce MFA, implicitly trusts anything within the corporate network, and clings to old security through obscurity practices.
That company is such a mixed bag, software allow listing, strict segregation of AD accounts with admin rights from regular accounts, heavy network filtering, but misses basic stuff like this, doesn't enforce MFA, implicitly trusts anything within the corporate network, and clings to old security through obscurity practices.
Upvote
4
(4
/
0)
Microsoft makes tiny non-backward compatible change: "The new version breaks us so our hospital is still using Windows XP and is insecure"
Microsoft keeps in backward capability features: "Windows is insecure and it's Microsoft's fault"
(I'm actually MSFT employee in an unrelated part of the company with no insider knowledge of this situation, but this sort of drama is so repetitive and there doesn't seem to be a winning move here).
Microsoft keeps in backward capability features: "Windows is insecure and it's Microsoft's fault"
(I'm actually MSFT employee in an unrelated part of the company with no insider knowledge of this situation, but this sort of drama is so repetitive and there doesn't seem to be a winning move here).
Upvote
82
(82
/
0)
Endlessly "cutting costs" without any understanding of fundamentals on where you're asking for costs to be cut leads to this, especially where there's an aspect of "it's built, so why should we keep paying so much?" Asking understaffed and underhired teams to perform like twice the number at twice the competence leads to corner cutting, inevitably. And/or worse, constant turnover of firing "underperformers" for not performing miracles, and suddenly you find out just how much institutional knowledge DID matter for things getting done right.
And no responsibility for disasters leads to CEOs recklessly calling for cost cutting and profit maximizing with no real care beyond the numbers for next quarter. And of course they didn't tell anyone that those are the specific things to cut when it comes to cause analysis, so "why should they be responsible?" But what else was going to happen with middle management and team leads when there's that pressure? And when one department or team sees how another is operating with apparent sanction, first it spreads as "well that works I guess" and then it spreads more as "that's the norm here, it's how we do things and came down from above, don't question it if you want to keep your job".
Not every single CEO. Not every time. But much like security, it only takes once if things are poorly structured and poorly isolated.
Upvote
17
(17
/
0)
One wonders what would have happened had Microsoft simply shipped the product with the options that allow kerberoasting turned off by default, requiring the receiving company to deliberately turn them on to get back their obsolete functionality, instead of the other way around.
Not that Ascension gets any slack cut for their failing to properly secure their network, of course. After all, they bought a lock that the lock-maker said, "This isn't completely secure unless you twist this gizmo, pull that doohicky and push these six buttons all at the same time to make it lock properly", and didn't follow the steps that made the lock actually lock. But having to do that in the first place to get the network locked down shouldn't be on the end user.
If their needs are to have a LESS secure network, then they should be responsible for opening their barn door. Microsoft should always ship the barns with the doors locked.
Upvote
3
(5
/
-2)
The article quotes somebody as saying a 10 character random password is uncrackable. I don’t think that math is correct in modern times. A cheap gamer GPU can do 100 billion guesses per second on RC4 with hashcat. You can rent three of these for a dollar an hour in many places. With a just one of these you could crack a 10 digit alphanumeric password in 4 days. Get 10 or a 100 running in parallel and you could even crack random passwords with symbols in them at a reasonable time for under $10k attack budget. Hashcat is very very fast at this.
Upvote
24
(24
/
0)
Yes, NTLM is not secure, but for most organizations there is not a way to totally disable NTLMv2. Microsoft has been working towards this, and there was a lot of information posted in 2023, but it has been silent since then. Even some Microsoft provided services like the print spooler are dependent on NTLM.
Don't confuse properly mitigating kerberosting with NTLM as a whole.
https://syfuhs.net/deprecating-ntlm-is-easy-and-other-lies-we-tell-ourselves
https://techcommunity.microsoft.com...e-evolution-of-windows-authentication/3926848
Upvote
4
(4
/
0)
I would buy that except I know just enough about validated systems (e.g. equipment the FDA has signed off on) to know that the hospital has fucked up if it requires network connectivity to AD for actual medical equipment.
There should be like 1 box that has network connectivity to the host running the MRI machine. The box that's part of the MRI machine should be using local creds because literally anything else invalidates the validated design.
Now when you're doing upgrades of your hospital network, you can upgrade everything, because the MRI's XP box doesn't need to act as a client. It's an insecure server, but is segmented such that it only talks to the one box on your network used to pull images or w/e. Windows' backward compatibility makes this easier b/c you can still run 32-bit apps from the 90's in W11 on the single AD joined box that communicates with the XP box embedded in the MRI machine (at least I assume so... I migrated off Windows completely a few years back and interact with it only sparingly today).
Upvote
21
(22
/
-1)
You're not totally wrong. If you haven't configured the right mitigations, the easiest way to prevent this is having a 15 character password.
https://learn.microsoft.com/en-us/t...curity/prevent-windows-store-lm-hash-password
Upvote
0
(0
/
0)
If Microsoft disabled this, they could easily break critical applications for organizations. They could break older medical device equipment, manufacturing/production line equipment, and ERP systems that could bring organizations to a halt. It is the 3rd party products or applications that companies haven't updated in years or decades that are the primary issue here. I'm sure Microsoft has the telemetry behind this to understand how it could break certain organizations.
Your view if this particular issue is way too narrow.
Upvote
4
(10
/
-6)
My experience is that no password scheme permits close to all printable ASCII characters - those I’ve encountered allow maybe 72 (upper/lower alphas, numbers, and perhaps 10 “specials”). Even if all were permitted, there is no way a human could memorize that, so a password manager would be required, and I’ve never encountered that being mandated (or likely even allowed) in a corporate setting. I’m surprised that a security expert would call for such passwords - I guess the following XKCD needs to be dragged out again:
Upvote
28
(29
/
-1)
This is the paradox of scale that four decades of consolidation, and regulatory encouragement of consolidation, have left us: one big company whose software is supposed to work at every level from single users at home to organizations with hundreds of thousands of employees and millions of user profiles.
Great news, everything from the 80s and after works together! Terrible news, everything from the 80s and after works together!
This is an old hobbyhorse of mine, but if DoJ had broken Microsoft into Windows and Office (as it was in the process of doing when the 2000 election brought that to a halt), we would live in a very different world. It wouldn't be one without data breeches, but it would probably be one without these kinds of data breeches where the One Company has no hope of even documenting all the things its software does, much less having capable and well funded IT support at every vulnerable customer.
Upvote
-3
(6
/
-9)
I mean.. why would you want regular AD updates? There really aren't that many new features and every update is an incredible risk that has to be tested very carefully and contains the chance for unknown bugs or exploits.
The last really useful AD update I can think of were MSAs - which really made a big difference. But apart from that?
And changing defaults on existing infrastructure particularly with AD seems incredibly dangerous. AD is installed on so many different configurations in so many critical environments that probably still include ancient systems that haven't been updated in years. Just doesn't seem like a practical approach.
Much better to provide explicit guidance and best practices for how to secure your system, which means you can test and configure things separately and in your own time.
And Microsoft has a ton of information available there and it would've been totally possible to configure the system in such a way that the attack couldn't have worked.
No, I'd say the real problem is that large companies are starving their IT departments to death and are trying to be cheap as possible when it comes to security, because even now I doubt any of the responsible C-suite people will have to fear dire consequences.
Upvote
21
(21
/
0)
I assume you're talking about user level password managers?
Virtually all Financial sector entities (and plenty in Healthcare that I've seen) that have any level of mandated audits will have an ERPM absolutely required for accounts that have any level of elevated access. I personally use a password manager for all my work related accounts - yes it's a hassle to input 16-24 character random passwords but I'd rather fat finger it occasionally than be the weakest link.
The policies that permit weak passwords are almost always related to complaints from or fears about users high up in the Org Chart being inconvenienced or having their "time wasted". Only once did I actually encounter a medical device that was horribly incapable of a secure password (It was max 8 characters, only alpha). We restricted every possible thing we could for that device until it was retired.
Without external pressure of mandated audits, it takes a CIO being willing to spend political capital or a publicly reported breach to get big organizations to accept that it's not 1990 anymore. If it's not public enough then the heads will firmly be stuck back into the sand.
Audits suck but no audit ever is far worse.
Upvote
24
(24
/
0)
Thank you for this article. It does a great job pointing out all of the things my brain was screaming when reading through the last one featuring Wyden's very one-sided account of the situation.
One extra thing to point out, is that based on my (and packages like Bloodhound's) understanding of Kerberoasting, it only works for accounts that have a SPN, which are accounts used to run services. So a domain-level service account with a weak password had administrative access on all machines, or at least enough access to gain tier-0 to the rest of the network.
There are (free) tools that will take a dump of your AD environment and spit back all kinds of attack path information. One of the pre-built Cypher queries in Bloodhound CE is an inventory of all Kerberoastable accounts along with those that have tier-0 access.
Microsoft bears some culpability, but at some point, organizations need to take some responsibility for their own security. Active Directory is not some consumer product that you're supposed to set and forget.
One extra thing to point out, is that based on my (and packages like Bloodhound's) understanding of Kerberoasting, it only works for accounts that have a SPN, which are accounts used to run services. So a domain-level service account with a weak password had administrative access on all machines, or at least enough access to gain tier-0 to the rest of the network.
There are (free) tools that will take a dump of your AD environment and spit back all kinds of attack path information. One of the pre-built Cypher queries in Bloodhound CE is an inventory of all Kerberoastable accounts along with those that have tier-0 access.
Microsoft bears some culpability, but at some point, organizations need to take some responsibility for their own security. Active Directory is not some consumer product that you're supposed to set and forget.
Upvote
10
(10
/
0)
I worked at Ascension some 5-7 years ago. We were migrating their network core from within several hospitals to a pair of standalone data centers. Tons of work. We stood up segmentation, new firewalls and VPN access. I accepted a position with a different company much closer to home, better pay and benefits (gee, tough call there), but negotiated to stay on at Ascension pending the project completion (since I didn't hate my overworked colleagues there).
I left when the second new data center went live. Within two months, Ascension completely abandoned the new network by selling one of the DC sites and terminating lease on the other. Also terminated all but the most junior IT staff and got some Indian outsourcing for systems and networking (they'd already got involved in some of the hospital LAN projects before I left, and after forming my opinion of them and through-the-grapevine murmurs this also figured into leaving).
All this is a long way of saying I am very disappointed, but not in the least shocked. Those guys did practically nothing except stick meaningless lines in open tickets, repeating the original subject for the next shift, who then did exactly the same.
I wouldn't trust those dipshits with an Etch a Sketch.
I left when the second new data center went live. Within two months, Ascension completely abandoned the new network by selling one of the DC sites and terminating lease on the other. Also terminated all but the most junior IT staff and got some Indian outsourcing for systems and networking (they'd already got involved in some of the hospital LAN projects before I left, and after forming my opinion of them and through-the-grapevine murmurs this also figured into leaving).
All this is a long way of saying I am very disappointed, but not in the least shocked. Those guys did practically nothing except stick meaningless lines in open tickets, repeating the original subject for the next shift, who then did exactly the same.
I wouldn't trust those dipshits with an Etch a Sketch.
Upvote
32
(32
/
0)
Because the world evolves and I expect products to evolve with it? Best practices evolve with time and its possible to follow guidance from Microsoft and then lock yourself into a path that prevents you from being able to meet the challenges of a modern threat landscape.
As an example:
Let's take a look at the "State of the art" design in 2003 - 2006 when most companies stood up their AD envs or did a major rebuild coming off of NT Domain Services.
"Empty root" was recommended heavily. there was a schism in MCS where some folks recommended Empty root and some recommended SFSD.
If Microsoft couldn't come to a consensus... well, that says something doesn't it? So you build a system following the recommendations and documentation that is available to you on TechNet/MSDN.
(Empty root for those unfamiliar is where you have an empty root domain and then put everything in a child domain, this was designed to mitigate a specific kind of attack and some issues that are no longer applicable. It made some sense in the NT days, but its no longer relevant)
Now it's a millstone around organizations who are told "You need to stand up a new domain and migrate all your objects to it" which would be great if it wasn't a miserable process that can destroy productivity and access if done even slightly wrong.
That's the only way out of a recommended decision from 2003. New domain. No way to fix that.
Features that would be nice:
Why is the only MFA option in On-Prem AD out of the box "Smart Card" instead of the myriad of options we have available to us today?
(Because it's a major selling point to moving to AAD)
Why can't I officially rotate my DPAPI key in 2025?
Why is Microsoft's answer "New Domain!" to a key rotation that's necessary after a TA has taken the ntds.dit file or compromised a DC?
Last edited:
Upvote
4
(6
/
-2)
Ascension seem to me to be 90% to blame here.
MS and AD security issues are well publicised and benchmarks give good advice to follow regarding RC4 removal and so on, e.g. NIST / CIS Level 1 or 2. And all the security tools like Nexpose etc. etc. know what to look for.
Kali is free and regularly updated for goodness sake.
Not in US so not sure what HIPAA mandates but the book needs to be thrown at their c-suite not the poor IT guys who will no doubt have pointed out the defects many times, been given a pat on the head and told to stop annoying the adults while they project what their bonuses might be.
Even if they aren’t using MSA no reason they couldn’t be using highly complex very long passwords for any service account, which presumably they won’t be changing very often, AD allows up to 127 characters via the GUI. If I recall correctly MS SQL doesn’t like some special characters but there are plenty of generators out there to take account of that.
And of course no reason for every account to have full SA rights and so on.
I will criticise MS for not supporting MSA against certain apops like Exchange though. Exchange itself doesn’t need service accounts to run but JML tools, monitoring etc. obviously do aren’tsupported to use MSA with Exchange. Poor show.
MS and AD security issues are well publicised and benchmarks give good advice to follow regarding RC4 removal and so on, e.g. NIST / CIS Level 1 or 2. And all the security tools like Nexpose etc. etc. know what to look for.
Kali is free and regularly updated for goodness sake.
Not in US so not sure what HIPAA mandates but the book needs to be thrown at their c-suite not the poor IT guys who will no doubt have pointed out the defects many times, been given a pat on the head and told to stop annoying the adults while they project what their bonuses might be.
Even if they aren’t using MSA no reason they couldn’t be using highly complex very long passwords for any service account, which presumably they won’t be changing very often, AD allows up to 127 characters via the GUI. If I recall correctly MS SQL doesn’t like some special characters but there are plenty of generators out there to take account of that.
And of course no reason for every account to have full SA rights and so on.
I will criticise MS for not supporting MSA against certain apops like Exchange though. Exchange itself doesn’t need service accounts to run but JML tools, monitoring etc. obviously do aren’tsupported to use MSA with Exchange. Poor show.
Upvote
7
(7
/
0)
Fair enough, after writing the post I remembered the rather sorry state of 2FA too.
The remaining issues aren't something I have experience with, but having to set up a new domain is definitely anything but fun.
Upvote
1
(1
/
0)
I had the misfortune of signing up with Ascension just as they were hacked. They took my money readily enough but then couldn't even confirm that we had any kind of coverage for weeks. Eventually I ended up switching to a (non-Acscension) COBRA policy and telling Amex to back out the Ascension policy, which they did. To this date I've never heard one word from these guys and that's just fine with me.
Upvote
7
(7
/
0)
I think we are missing the big picture. The whole problem started with a user clicking on a poisoned link which downloaded malware to his laptop. We are missing some context here - was the link on a well known site and why did he/she go there - but what I can tell you is that link was specifically setup to attract and attack corporate users with access to AD. Which leads to my next point, namely, if an effective user training program to detect, identify and avoid phishing emails and sites would we be having this discussion?
Every study I have seen indicates a well designed user training program with followups is the most cost effective means for preventing breaches to the corporate network. I agree with everyone's comments about Microsoft's default implementation of AD/Kerberos and I agree Ascension failure to implement Microsoft's recommendations. My question: would any of this been necessary if that user hadn't clicked on that link.
Every study I have seen indicates a well designed user training program with followups is the most cost effective means for preventing breaches to the corporate network. I agree with everyone's comments about Microsoft's default implementation of AD/Kerberos and I agree Ascension failure to implement Microsoft's recommendations. My question: would any of this been necessary if that user hadn't clicked on that link.
Upvote
0
(4
/
-4)
Ascension’s IT services and support went to shit when they offshored almost all IT jobs to an incompetent company based out of India.
I was a sysadmin for ascension from 2015 to 2020 when they fired everyone and even asked some of us to train our overseas replacements.
I came back as a contractor for a couple years after layoffs with 3 times the workload and a fraction the number of IT department members here in the states.
I sure hope ascension realizes their mistakes and re-shores the jobs in the US. I wonder if this ransomware incident could have been avoided if ascension hadn’t laid off nearly every competent IT employee.
I was a sysadmin for ascension from 2015 to 2020 when they fired everyone and even asked some of us to train our overseas replacements.
I came back as a contractor for a couple years after layoffs with 3 times the workload and a fraction the number of IT department members here in the states.
I sure hope ascension realizes their mistakes and re-shores the jobs in the US. I wonder if this ransomware incident could have been avoided if ascension hadn’t laid off nearly every competent IT employee.
Upvote
19
(19
/
0)
That's true for maintenance of existing systems, however what I understoood (possibly incorrectly) is that these insecure cyphers were and are still today enabled by default for new AD installations and deployments.
If that's the case, that's negligence from Microsoft and really don't see a valid justification for that.
People who need these cyphers for specific compatibility reasons can enable them manually.
Last edited:
Upvote
3
(3
/
0)
I'm going to be charitable here and say that it's because Smart Card is standardized and good security. It's better than a phishable TOTP, and don't get me started on SMS codes!
Smart Card is cheap, whether it's a real Smart Card on a lanyard, a Yubikey, or the TPM-protected virtual Smart Card on a laptop or desktop. The "Windows Hello for Business" stuff is really Smart Card in disguise, too.
Making AD users implement Smart Card rather than a less secure option is a net positive.
Upvote
4
(4
/
0)
This was a cheap shot leveled at a group of people that may or may not have had the responsibility or the approval from senior IT management to solve this problem. I guarantee you that the internal team asked to do this kind of project, and IT leaders said no. Flat networks are a sign of a political leadership class that doesn't understand the need to resolve this, and thus, never does.
Upvote
4
(4
/
0)
In any sane world Active Directory is a truly ancient bit of software that defines what technical debt looks like. It must be close to 30 years old from when development started in an almost pre-Internet culture. It is incredible we're still depending on this for our identities and authentication when as far as I can see its development has atrophied since Windows Server 2003.
Upvote
-10
(0
/
-10)
Uh... does this mean that my multiple passwords that's literally 10 random characters and numbers and symbols (it only makes a single 2 letter word in it) is actually good enough? And I string multiple of the 10 character passwords together for something that needs more security....
Upvote
-2
(0
/
-2)
People, people! You've GOT to stop using "password" as your password. You HAVE to add "123" on the end to make it 100% safe!
/s
/s
Upvote
7
(7
/
0)
So this whole article comes down to some IDIOT USER that allowed their laptop to get compromised by clicking on stupid shit online.
Upvote
-8
(1
/
-9)
These days even joke websites require 8+ characters, a capital, a lower case, and a special character. Yet somehow major corps are still using 1234.
Upvote
2
(2
/
0)
<Waves> We overlapped there at some point then. Same experience I had, and shared above. Praying to God is not a security strategy.
Upvote
4
(4
/
0)
I appreciate the challenge of dealing with ancient products and a customer base that refuses to move on, but in this, the issue is over 10 years old and Microsoft is slow walking it because it's on-premise and doesn't care about it.
Let's put it into perspective:
Windows 10 & Windows 11 with all it's Updates as well as Windows 2016 & 2019 Server fall into that time frame.
IETF formally recommended deprecating TLS 1.0 and 1.1 through RFC 8996 in June 2018 and this was removed from the M365 service in 2022 and turned off in Windows 11 in 2023.
They could have easily upgraded the protocol and deprecated it, had there been the managerial will at Microsoft. In this instance they aren't even dependent on anyone else if they had wanted to. They could have even offered special patches for customers with older systems had that been a possible compromise. To quote Microsoft
I'd say the failure to a) recognize the relevance of a weak protocol and b) leaving it up to customers to take care of it instead of taking action where it could does not speak for Microsoft's SDL process. It's clear Microsoft has chosen to prioritize business goals here and they have to be faulted for it.
Upvote
2
(2
/
0)