Comment by alexjplant | Hacker News Reader

Comment by alexjplant | Hacker News Reader

This is unfortunate, but not without precedent.

> 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_...

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.

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.

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.

The email is run as a service isn’t it?

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.

wow know. Not sure how I managed that one.

Reply on news.ycombinator.com