Live data from Hacker News

U.S. government probes VPN hack within federal agencies, races to find clues

reuters.com

11–20 of 61 posts

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#11
post #2

> 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 incentiviz…

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

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#12

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.

Here's a good discussion of that very same debate that is happening right now.

https://www.lawfareblog.com/lawfare-podcast-nicole-perlroth-...

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#13

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.

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.

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#14

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.

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

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#15
post #2

> 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 incentiviz…

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 in…

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.

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#16

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.

Some version of that debate has been going on since roman days.

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#17
post #2

> 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 incentiviz…

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 in…

Security is not a Boolean. It's on a continuum from "You must be fucking joking" (early versions of IE) to "Not perfect, but workable with training" (literal weapons-grade air gapping).

Perfectly secure software does not exist. More secure and less secure software certainly does exist.

Which is why software should be expected to provide some basic level of protection.

In any org there will be a proportion of idiots who cannot be trusted to do the right thing, and software should be designed to minimise the damage their idiocy can generate.

This isn't enough to make an org secure, but it's a good start on whack-a-mole with the most obvious attack vectors.

The real problem is that too much of the industry - both management and devs - lacks maturity and professionalism. There's too much casual hobby tinkering, too much "But that's too expensive", and too much "Get it out the door and worry about it later".

There isn't enough conscientious attention to detail and far, far too little understanding of the disastrous - literally potentially explosive - consequences of serious security failures.

And CS courses teach far too little of all of the above. Academic algo noodling is one thing. But the reality is that computers can literally be as dangerous as weapons - and should be treated as such.

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#18

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.

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 purs…

If only it was just one agency from one country plinking holes in things...

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#19

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.

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

For sure, my point was that the debate, instead of being between government figures who are in favor of keeping the right to listen in vs. non-government figures who want to keep them out, it will shift (has shifted?) to a within-government debate. In the days after 9/11, I don't get the impression there was much of an intra-government debate at all.

Re: U.S. government probes VPN hack within federal agencies, races to find clues

#20

Earlier quoted context omitted.

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 l…

>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 res…

They could build in a requirement that the software has undergone penetration testing by a security firm, and that a copy of the penetration testing report along with any mitigations applied to the software be provided.

I've never even heard of the software the government is using. Why aren't they using Cisco AnyConnect like literally every other company I've worked for who has a VPN?

Post reply on HN