[HN Gopher] U.S. government probes VPN hack within federal agenc...
___________________________________________________________________
U.S. government probes VPN hack within federal agencies, races to
find clues
Author : c1c2c3
Score : 63 points
Date : 2021-04-29 19:43 UTC (3 hours ago)
(HTM) web link (www.reuters.com)
(TXT) w3m dump (www.reuters.com)
| waihtis wrote:
| > The U.S. plans to address some of these systemic issues with an
| upcoming executive order that will require agencies to identify
| their most critical software and promote a "bill of materials"
| that demands a certain level of digital security across products
| sold to the government.
|
| Interesting, no mention of any requirements towards software
| manufacturers themselves.
|
| If you think about it, this will further incentivize poor-quality
| software as responsibility of vulnerability response is now being
| laid on the product owner.
| indymike wrote:
| If I were a federal contractor, wanting to make more from my
| cost plus contraction, what better way than generating text
| files full of dependencies that will cause billable meetings to
| discuss why we should be ok with some old insecure library
| being used... that will always end with even more billable work
| to update the old, insecure library. Even better would be if I
| had to incur some billable time and cost on certifications.
| Cost plus FTW (unless you are a taxpayer).
| thinkmassive wrote:
| The government has no authority to demand a software bill of
| materials (SBOM) from everyone who publishes software.
|
| Imposing this requirement on their own agencies is enforceable
| because there's software that can generate an SBOM, at least
| from container images.
|
| Then the agencies will have to choose software that meets
| compliance requirements, so they're the ones putting pressure
| on their chosen vendors. It follows logically that a vendor who
| wants a better chance of being chosen for more government
| contracts will make it easy to obtain SBOMs for their software.
| WaitWaitWha wrote:
| >The government has no authority to demand a software bill of
| materials (SBOM) from everyone who publishes software.
|
| Speaking from US Gov perspective - if the company is part of
| a contract (and ~40% of the Gov are contractors), Gov
| certainly can.
|
| They can put nearly anything (legal) into the RFP/Q. Even if
| they do not say "give us your BoM", they can wrap it in
| requirements that in essence delivers the same exact result.
|
| That said, it is Gov mistake to ask for the BoM. They will do
| little with it in a timely fashion, and lack the expertise to
| identify risks, and lack the resources to go after it. The
| best contracts are the ones where the rules and parameters
| are set for the contractor, (i.e. no untested software, no
| foreign influence, no this, no that, must have this and
| that), and auditing of the compliance.
| er4hn wrote:
| > If you think about it, this will further incentivize poor-
| quality software as responsibility of vulnerability response is
| now being laid on the product owner.
|
| Not really, this is more about transparency of all components
| and letting people downstream be aware that there is an issue
| and either fix it, mitigate it, or raise the issue upstream. My
| guess is that this is related to Allan Friedman's SBOM work at
| NTIA (sorry - this is not the most up to date link:
| https://www.csiac.org/podcast/software-bill-of-materials-sbo...
| )
|
| The problem that keeps on getting hit time and time again is
| that both end users and product manufacturers do not know
| everything that is in their system. Consider the case of say,
| an MRI machine. What OS is it running and how up to date is it?
| If the end user has an SBOM they can better evaluate that and
| demand fixes if there are known issues. Likewise if the MRI
| manufacturer is good at making MRIs, but not so much at knowing
| if their version of Windows on the MRI is out of date, the SBOM
| for the MRI can be analyzed to automatically flag problems.
|
| You can regulate all you want about "There must be no open
| issues" and plenty of certifications for the Fed government do
| have that language. The problem this answers is forcing a
| listing of every component so that "Sorry I didn't know OpenSSH
| v.1.2.3 is out of date" or "I had no idea we were running
| Windows 95 on this hardware" are no longer valid excuses.
| joe_the_user wrote:
| This theme keeps coming up. Some cohort of HN is upset that
| software manufacturers aren't directly required to produce
| "secure software" [1]
|
| I would suggest people look at a very foundational essay on
| this [2]. Key quote: " _Security is a process, not a product.
| Products provide some protection, but the only way to
| effectively do business in an insecure world is to put
| processes in place that recognize the inherent insecurity in
| the products._ "
|
| How many times do we have to learn this?
|
| [1] In quotes 'cause "secure software" does not exist. In two
| different ways; software always has bugs and using a piece of
| software incorrectly makes a secure system insecure.
|
| [2]
| https://www.schneier.com/essays/archives/2000/04/the_process...
| closeparen wrote:
| Part of the process of security is to design and code with
| consideration towards potential vulnerabilities.
| Organizations that ought to care care about security, and
| even spend a lot of money on security, also buy a lot of bug-
| riddled crap to run on their "secure" networks. Firewall
| rules and Group Policies can't fix everything.
| g_p wrote:
| I think there's a couple of issues at play here.
|
| Firstly there's the information asymmetry for non-technical
| users - they don't think of themselves as buying security,
| they think of themselves as buying a remote access solution.
| They therefore don't see this as a process, but instead as a
| product or solution. That means they're surprised and caught
| unaware when something goes wrong.
|
| The second issue is that people creating the software aren't
| themselves thinking about security, because the customer
| isn't buying security, or comparing security. And how do you
| measure or quantify or observe security? There's no
| commercial incentive to invest a month in hardening a product
| against attack, unless that month of engineering effort sees
| more sales and revenues. And since the people who buy are
| satisfied by slideware and specification sheets for security,
| nothing changes.
|
| I think we need a whole change to how we buy software,
| hardware, and solutions in general, to see this change. The
| underlying economics don't incentivise secure products, in
| fact they actively discourage them.
| olyjohn wrote:
| Wasn't Pulse Secure VPN the one that required an ActiveX control
| and IE in order to "secure" your system on Windows? I mean, when
| I see that kind of shit, I kind of assume the vendor sells some
| shit software.
| reaperducer wrote:
| Just yesterday I was on a federal government web site (FWS,
| BLM, or some similar agency), and it popped up a window saying
| that the web site doesn't work in Safari, and I should use
| IE10.
| rossdavidh wrote:
| Prediction: at some point (if it isn't already happening as we
| speak), the government insistence on "we need to be able to hack
| into any software if it's important" will collide with "we need
| to be able to keep foreign powers out of our software", and there
| will be bitter internal fights about it, both sides claiming
| national security interests.
| legutierr wrote:
| Here's a good discussion of that very same debate that is
| happening right now.
|
| https://www.lawfareblog.com/lawfare-podcast-nicole-perlroth-...
| sbierwagen wrote:
| Bruce Schneier has been complaining about this tradeoff for
| more than a decade:
| https://www.schneier.com/blog/archives/2014/05/disclosing_vs...
|
| >The NSA can play either defense or offense. It can either
| alert the vendor and get a still-secret vulnerability fixed, or
| it can hold on to it and use it to eavesdrop on foreign
| computer systems. Both are important US policy goals, but the
| NSA has to choose which one to pursue. By fixing the
| vulnerability, it strengthens the security of the Internet
| against all attackers: other countries, criminals, hackers. By
| leaving the vulnerability open, it is better able to attack
| others on the Internet. But each use runs the risk of the
| target government learning of, and using for itself, the
| vulnerability -- or of the vulnerability becoming public and
| criminals starting to use it.
|
| Unsurprisingly, the NSA often chooses to keep zerodays for
| their own use.
| godelski wrote:
| > at some point
|
| Hasn't this been the debate since encryption came around? I
| thought we've been having this debate for at least 50 years.
___________________________________________________________________
(page generated 2021-04-29 23:00 UTC)