7 ms·

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

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

thinkmassive 6y ago
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 6y ago
  >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.
  - jcrites 6y ago
    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?
    - Jtsummers 6y ago
      Not all agencies, but the US gov't does use Cisco AnyConnect and pretty much everything they use for IT is COTS these days.
      - systematical 6y ago
        Federal contractors as well.
    - Bluecobra 6y ago
      Pulse Secure is pretty well regarded (or maybe was better regarded when it was a Juniper product). AnyConnect has had had will have its fair share of vulnerabilities as well. A few years ago I had to update the firmware our ASAs like four times in a year due to new vulnerabilities. Any commercial product you pick is going to have new vulnerabilities and you just need to stay on top of it.
joe_the_user 6y ago
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_of_secur.html https://www.schneier.com/essays/archives/2000/04/the_process...
- g_p 6y ago
  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.
- closeparen 6y ago
  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.
- TheOtherHobbes 6y ago
indymike 6y ago
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).
- systematical 6y ago
  Luckily not all federal contractors think like this. Some would report this behavior and some of us would be quite happy to report it. There are those that still believe in doing the right thing, value tax payer dollars, and want to deliver for the American people. If only more of us wanted to completely rip out the rot.
  - indymike 6y ago
    > If only more of us wanted to completely rip out the rot. Even if you report it, this kind of behavior is so normal, I'd be shocked if it does anything other than create more billable project management hours for the company you are protesting.
er4hn 6y ago
> 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-sbom/ 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.
uzakov 6y ago
If anyone is interested to read more about Software Bill of Materials and how you can implement it check out OWASP Dependency Track project - https://owasp.org/www-project-dependency-track/ https://owasp.org/www-project-dependency-track/

thinkmassive 6y ago

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 6y ago
>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.
- jcrites 6y ago
  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?
  - Jtsummers 6y ago
    Not all agencies, but the US gov't does use Cisco AnyConnect and pretty much everything they use for IT is COTS these days.
    - systematical 6y ago
      Federal contractors as well.
  - Bluecobra 6y ago
    Pulse Secure is pretty well regarded (or maybe was better regarded when it was a Juniper product). AnyConnect has had had will have its fair share of vulnerabilities as well. A few years ago I had to update the firmware our ASAs like four times in a year due to new vulnerabilities. Any commercial product you pick is going to have new vulnerabilities and you just need to stay on top of it.

joe_the_user 6y ago

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_of_secur.html https://www.schneier.com/essays/archives/2000/04/the_process...

g_p 6y ago
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.
closeparen 6y ago
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.
TheOtherHobbes 6y ago

indymike 6y ago

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

systematical 6y ago
Luckily not all federal contractors think like this. Some would report this behavior and some of us would be quite happy to report it. There are those that still believe in doing the right thing, value tax payer dollars, and want to deliver for the American people. If only more of us wanted to completely rip out the rot.
- indymike 6y ago
  > If only more of us wanted to completely rip out the rot. Even if you report it, this kind of behavior is so normal, I'd be shocked if it does anything other than create more billable project management hours for the company you are protesting.

er4hn 6y ago

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

uzakov 6y ago

If anyone is interested to read more about Software Bill of Materials and how you can implement it check out OWASP Dependency Track project - https://owasp.org/www-project-dependency-track/ https://owasp.org/www-project-dependency-track/