> Some of the exposed information included sensitive personnel information and questionnaires by prospective federal employees seeking security clearances.
This already happened almost a decade ago [4] but in a different department.
> The cloud email server, hosted on Microsoft’s cloud for government customers, was accessible from the internet without a password, likely due to a misconfiguration.
The government has security guidelines ("STIGs") and provides instructions as to how to manually implement them [1]. Based on their "Automations" page [2] it would seem as though they have a tool called the "Security Content Automations Protocol Compliance Checker" that _checks_ for misconfigurations but doesn't remedy them. Based on (an admittedly cursory) reading of their literature they don't have any way to automatically _implement_ these measures besides maybe some downloadable GPOs. They do, however, have step-by-step instructions for fixing things using Powershell (example [5]). The fact that they can tell you to run a script manually in a set of instructions but don't seem to provide a Powershell script to automatically do this (that I can find - happy to be wrong) is curious.
> It’s not clear for what reason the DOD took a year to investigate the incident or notify those affected.
They take six to twelve months [3] to certify bespoke applications built by contractors to the Navy's spec to run on their networks... a one-year disclosure timeline seems appropriate.
Publicly-available sources for everything in my post are as follows:
STIGs are just references for implementations. The actual security standards are CMMC, made up of various DFARs, and FedRAMP for the cloud. Like you say, it does take on average 6-12 months to certify a new vendor.
The big problem is it's all self-attestation. I've worked for one of these vendors, and it was a lot of jackass business people who didn't actually care if anything was secure, they just wanted to "pass" their certification as quickly as possible and cut as many corners as they could. Didn't want to spend money on a contractor who knew how to actually pass these certifications, so instead they'd just lean on the IT dude and demand he complete things he didn't know anything about on impossible timeframes, asking him to do things which they might be legally liable for, and basically trying to avoid doing any actual security work if at all possible. Lowers cost, gets their project going faster which helps them land more contracts and get a promotion.
There are many projects to automate remediations. One in use by the DoD in this area is OpenSCAP (scanner) and Compliance as Code (benchmark content + automated remediations), lead by Red Hat and contributed to by other Linux vendors.
But, despite having a nice three letter acronym, the DoD is not a homogenous unit and so you're bound to get groups doing different things. :-)
> Compliance as Code (benchmark content + automated remediations), lead by Red Hat and contributed to by other Linux vendors.
Do they also develop these for Microsoft products? Why is none of this automation linked on their official site? I would think that if you wanted a good security culture you'd share these tools as far and wide as possible. I vaguely recall seeing some tools like this in random GitHub repos but it'd be great to see them promulgated by an authority as they might have been able to mitigate the attack vector that the article was talking about.
I don't believe Microsoft contributes to this project. There are STIGs available for Windows but presumably any automated hardening by Microsoft is proprietary. Likely a new Powershell automation backend would be necessary. The scanner might work, though.
I think part of the dichotomy comes from the general acceptance of these recommendations. STIGs are only really applicable to the US Govt and perhaps a few select groups that do business with them. Even major banks haven't typically adopted them wholesale (like they have with higher FIPS levels for instance).
The broader security community has largely written it off as security theater. For the most part the amount of data generated by these recommendations (which is hard to prove and identify concrete threats in real time -- at best for postmortem understanding) and the impact to usability is substantial enough that I agree. Though, having met with many authors of STIG and other benchmarks, their intentions are well-meaning.
STIGs apply to DoD systems administered by DoD staff or contractors. SCAP scans have similar scope. Commercial cloud is covered by CCSRGs. This is Microsoft's problem.
The system owner is responsible for security of systems they have deployed on Fedramp services. Microsoft is responsible for securing the service but they don't make sure every vm you spun up on Azure meets your own security baselines. Those vary not just between agency but even specific site. Expecting the vendor to do all of that is an impossible task.
Yes and know. The implication of it being an "unsecured email server" to me sounds like they spun up a VM for some reason instead of using Exchange online.
I think this is the real story right here!! If you can't slice thru the red tape in security-breach situations.. When the hell can you, When the nukes are in the air???
> It’s not clear for what reason the DOD took a year to investigate the incident or notify those affected.
They take six to twelve months [3] to certify bespoke applications built by contractors to the Navy's spec to run on their networks...
a one-year disclosure timeline seems appropriate.
During a nuclear attack? Don’t be so cynical. I’d be shocked if military leadership failed to anticipate and preemptively address that problem. I’ve never served, but based on my experience working in other parts of the US government, I’ll bet they implemented a stringent, painstakingly documented, metric-focused, multi-step nuclear attack response protocol ensuring all relevant senior officials approve the command structure’s adherence to their in-depth red-tape reduction guidelines defined at some point in the early 80s.
“The cloud email server, hosted on Microsoft’s cloud for government customers, was accessible from the internet without a password, likely due to a misconfiguration.”
Does FedRAMP have any teeth (penalties for misconfigurationbreaches/etc)?
If it's just a box-checking exercise, then this outcome isn't unexpected. Some of the box-checking will lead to better practices by vendors, but they won't go the extra mile into ensuring their policies are followed all the time.
Why would no password for an email server ever be an acceptable configuration (why would the software allow it)? Even internal test setups require one.
It might happen if it were intentional. Internal security sabotage for the benefit of an enemy nation for example.
Given the scale of what's going on in the world right now, with huge powers conflicting, it would be far more surprising with the gigantic size of the US Government if there weren't internal actors (on the payroll of foreign enemies) aggressively attempting to do this. It was common in the past, for example during the Cold War (Soviet infiltration of the US Government, and persistent attempts at), you can pretty well bet it's still a common problem.
There has been a push across the DOD for a few years to move more and more infrastructure to the cloud. I hope events like this convince them that this isn't a great idea.
27 comments
[ 5.1 ms ] story [ 69.5 ms ] thread> Some of the exposed information included sensitive personnel information and questionnaires by prospective federal employees seeking security clearances.
This already happened almost a decade ago [4] but in a different department.
> The cloud email server, hosted on Microsoft’s cloud for government customers, was accessible from the internet without a password, likely due to a misconfiguration.
The government has security guidelines ("STIGs") and provides instructions as to how to manually implement them [1]. Based on their "Automations" page [2] it would seem as though they have a tool called the "Security Content Automations Protocol Compliance Checker" that _checks_ for misconfigurations but doesn't remedy them. Based on (an admittedly cursory) reading of their literature they don't have any way to automatically _implement_ these measures besides maybe some downloadable GPOs. They do, however, have step-by-step instructions for fixing things using Powershell (example [5]). The fact that they can tell you to run a script manually in a set of instructions but don't seem to provide a Powershell script to automatically do this (that I can find - happy to be wrong) is curious.
> It’s not clear for what reason the DOD took a year to investigate the incident or notify those affected.
They take six to twelve months [3] to certify bespoke applications built by contractors to the Navy's spec to run on their networks... a one-year disclosure timeline seems appropriate.
Publicly-available sources for everything in my post are as follows:
[1] https://public.cyber.mil/stigs/
[2] https://public.cyber.mil/stigs/scap/
[3] https://www.navy.mil/Press-Office/News-Stories/Article/25200...
[4] https://en.wikipedia.org/wiki/Office_of_Personnel_Management...
[5] https://stigviewer.com/stig/microsoft_exchange_2016_mailbox_...
The big problem is it's all self-attestation. I've worked for one of these vendors, and it was a lot of jackass business people who didn't actually care if anything was secure, they just wanted to "pass" their certification as quickly as possible and cut as many corners as they could. Didn't want to spend money on a contractor who knew how to actually pass these certifications, so instead they'd just lean on the IT dude and demand he complete things he didn't know anything about on impossible timeframes, asking him to do things which they might be legally liable for, and basically trying to avoid doing any actual security work if at all possible. Lowers cost, gets their project going faster which helps them land more contracts and get a promotion.
But, despite having a nice three letter acronym, the DoD is not a homogenous unit and so you're bound to get groups doing different things. :-)
Do they also develop these for Microsoft products? Why is none of this automation linked on their official site? I would think that if you wanted a good security culture you'd share these tools as far and wide as possible. I vaguely recall seeing some tools like this in random GitHub repos but it'd be great to see them promulgated by an authority as they might have been able to mitigate the attack vector that the article was talking about.
I think part of the dichotomy comes from the general acceptance of these recommendations. STIGs are only really applicable to the US Govt and perhaps a few select groups that do business with them. Even major banks haven't typically adopted them wholesale (like they have with higher FIPS levels for instance).
The broader security community has largely written it off as security theater. For the most part the amount of data generated by these recommendations (which is hard to prove and identify concrete threats in real time -- at best for postmortem understanding) and the impact to usability is substantial enough that I agree. Though, having met with many authors of STIG and other benchmarks, their intentions are well-meaning.
> It’s not clear for what reason the DOD took a year to investigate the incident or notify those affected.
They take six to twelve months [3] to certify bespoke applications built by contractors to the Navy's spec to run on their networks... a one-year disclosure timeline seems appropriate.
If it's just a box-checking exercise, then this outcome isn't unexpected. Some of the box-checking will lead to better practices by vendors, but they won't go the extra mile into ensuring their policies are followed all the time.
Given the scale of what's going on in the world right now, with huge powers conflicting, it would be far more surprising with the gigantic size of the US Government if there weren't internal actors (on the payroll of foreign enemies) aggressively attempting to do this. It was common in the past, for example during the Cold War (Soviet infiltration of the US Government, and persistent attempts at), you can pretty well bet it's still a common problem.
Because Microsoft said that we will all go passwordless now. /s