4 ms·

Securing the Supply Chain of Nothing

46 points by ahamez 4y ago

MattPalmer1086 4y ago
This article is just an extended developer moan about having to do security. Honestly, the recommendations in it are quite sane. I doubt anyone would do everything in it. Many of the items in it are not prescriptive, and are just examples of mitigations, but he seems to think that all of them are required. He bemoans that "non vendor tooling" isn't covered (whatever that is) and then talks about entire product categories like IDS, AV and DAST. Ummm... you dislike using commercial intrusion detection systems, anti virus and dynamic application scanning tools? You want to write your own? He attacks the report for wanting static analysis on code before it's checked in, and then immediately moans that there's no consideration for integrating static analysis into dev workflows and getting fast feedback. Hint: faster analysis that runs in the IDE solves both problems. He thinks 30 years of SCM systems mean the threat of modification of code has gone away. I got news for him... TL;DR straw man moan about security from someone who doesn't understand it.
- goodpoint 4y ago
  Nicely said.
- kiesia 4y ago
  This is written by a) a woman, and b) someone who works in information security.
  - MattPalmer1086 4y ago
    My bad, I didn't check who wrote it. I assumed it was written from a developer perspective, as the arguments seem poorly made from an infosec perspective.
    - MattPalmer1086 4y ago
      To give some context here, I currently work on SDLC and dev security. Supply chain attacks are high on the agenda right now. I don't have a problem with this set of recommended practices. And that's all they are. These are things to consider and only constitute guidance, which may be out of date. It says all this in the intro.
  - fedeb95 4y ago
    - MattPalmer1086 4y ago
      Hardly! I just didn't stop to check who the author was and made an unwarranted assumption. I'll make a mental note to do that from now on.
  - Spooky23 4y ago
    Weird perspective from an infosec person. Controls are like brakes - they let the car go faster. There’s a lack of context as well… while intelligence agencies have a perspective fueled by lots of cash, many companies are working over their heads and adopting a “hold my beer” attitude with customer data.
comex 4y ago
Nitpick to the footnote about Pokémon: Harden is not a no-op. It increases the user’s defense stat. What makes wild Metapod helpless is that they only know Harden, rather than also having attacking moves.
- ungawatkt 4y ago
  Nitpick squared (and for fun), once metapod runs out of PP for harden (i think it has 30pp), it falls back on the move all pokemon technically know when they're out of moves: struggle. Which _is_ an attack move, albiet one that isn't very good (since it hurts the attacker more than the opponent), and from a practical standpoint you rarely get to the point of using struggle (though I do have vauge memories of using struggle to beat the Rock Gym onyx, since it's Bide move doesn't do damage when you only use Harden against it). The nitpick here being that Metapod does kinda know an attack move *This is all pulled straight from memories of playing Blue Version
hef19898 4y ago
>> enterprises would likely be better off with no documentation at all and just reading the source code. That, from the article, is quite a statement. Unsurprisingly, no explanation is offered.
- paganel 4y ago
  Not the OP, but bad/not up-to-date documentation is worse than no documentation at all, as it might take you on the wrong paths while saying that that's the correct way to do it.
  - skybrian 4y ago
    Documentation that explains historical context is sometimes useful. The part that gets you is assuming it to be current. It might help to put dates on things?
  - MattPalmer1086 4y ago
    Documentation at a high level should exist as to what a system does and roughly how it works. Feature changes and so on need to be documented somewhere. The high level design aspects and change. Detailed documentation on software is a waste of time in my opinion. The software itself is indeed the best guide to how it actually works. Having no documentation at all is not good.
    - awinter-py 4y ago
      keep the space shuttle flying, do not simplify this code
      - MattPalmer1086 4y ago
        Safety critical systems is a whole discipline I'd love to know more about.
        awinter-py 4y ago
dlor 4y ago
I'm not going to argue that the NSA report is amazing or terribly well-written, but re-reading it with the principle of charity nullifys many of these rebuttals. For one example, from the rebuttal: > If there is concern that their user credentials will beget malefaction and mistakes, then why discourage service accounts2, which are inherently decoupled from specific user identities? But then looking at the text from the document itself: > Minimize and regularly audit service accounts, > The use of service accounts, like non-human privileged accounts used to run automated processes, should be minimized and carefully audited. Every service account login should be logged. These logs should include date and time and the origin of login. Service accounts should follow the “least privileged” policy. All service accounts should be regularly reviewed to assure they are still needed, and unnecessary accounts removed. I don't think the document is saying to avoid service accounts in favor of something silly like shared passwords. It's saying to use the fewest you can get away with, delete unused ones, and regularly audit access to them.
- MattPalmer1086 4y ago
  Yes, agreed. The report itself is not unreasonable. The article sets up a lot of straw men and demolishes them.
_wldu 4y ago
I agree 100% with this statement (and with the article in general): “Basic hygiene” is arguably better than any of these bolt-on option, including things like: * Knowing what dependencies are present * Being purposeful about what goes into your software * Choosing a tech stack you can understand and maintain * Choosing tools that are appropriate for the software you are building
- MattPalmer1086 4y ago
  It's true in security in general, that really sticking to basic hygiene would mitigate a lot of more advanced threats. We haven't had much success over the decades though in getting people to stick to it.
xg15 4y ago
A bit OT, but I find it somewhat counterproductive that the link that gets (close to) HN's front-page is not "NSA Releases New Security Guidelines" but instead "Random Developer X Thinks New Security Guidelines are Total Garbage". Like, I get how story submission and voting works on HN, but I think the effect that the first news about the guidelines arrive with immediate negative framing is not really helpful to evaluating them.

46 points by ahamez 4y ago

This article is just an extended developer moan about having to do security. Honestly, the recommendations in it are quite sane. I doubt anyone would do everything in it. Many of the items in it are not prescriptive, and are just examples of mitigations, but he seems to think that all of them are required. He bemoans that "non vendor tooling" isn't covered (whatever that is) and then talks about entire product categories like IDS, AV and DAST. Ummm... you dislike using commercial intrusion detection systems, anti virus and dynamic application scanning tools? You want to write your own? He attacks the report for wanting static analysis on code before it's checked in, and then immediately moans that there's no consideration for integrating static analysis into dev workflows and getting fast feedback. Hint: faster analysis that runs in the IDE solves both problems. He thinks 30 years of SCM systems mean the threat of modification of code has gone away. I got news for him... TL;DR straw man moan about security from someone who doesn't understand it.

goodpoint 4y ago
Nicely said.
kiesia 4y ago
This is written by a) a woman, and b) someone who works in information security.
- MattPalmer1086 4y ago
  My bad, I didn't check who wrote it. I assumed it was written from a developer perspective, as the arguments seem poorly made from an infosec perspective.
  - MattPalmer1086 4y ago
    To give some context here, I currently work on SDLC and dev security. Supply chain attacks are high on the agenda right now. I don't have a problem with this set of recommended practices. And that's all they are. These are things to consider and only constitute guidance, which may be out of date. It says all this in the intro.
- fedeb95 4y ago
  - MattPalmer1086 4y ago
    Hardly! I just didn't stop to check who the author was and made an unwarranted assumption. I'll make a mental note to do that from now on.
- Spooky23 4y ago
  Weird perspective from an infosec person. Controls are like brakes - they let the car go faster. There’s a lack of context as well… while intelligence agencies have a perspective fueled by lots of cash, many companies are working over their heads and adopting a “hold my beer” attitude with customer data.

comex 4y ago

Nitpick to the footnote about Pokémon: Harden is not a no-op. It increases the user’s defense stat. What makes wild Metapod helpless is that they only know Harden, rather than also having attacking moves.

ungawatkt 4y ago
Nitpick squared (and for fun), once metapod runs out of PP for harden (i think it has 30pp), it falls back on the move all pokemon technically know when they're out of moves: struggle. Which _is_ an attack move, albiet one that isn't very good (since it hurts the attacker more than the opponent), and from a practical standpoint you rarely get to the point of using struggle (though I do have vauge memories of using struggle to beat the Rock Gym onyx, since it's Bide move doesn't do damage when you only use Harden against it). The nitpick here being that Metapod does kinda know an attack move *This is all pulled straight from memories of playing Blue Version

hef19898 4y ago

>> enterprises would likely be better off with no documentation at all and just reading the source code. That, from the article, is quite a statement. Unsurprisingly, no explanation is offered.

paganel 4y ago
Not the OP, but bad/not up-to-date documentation is worse than no documentation at all, as it might take you on the wrong paths while saying that that's the correct way to do it.
- skybrian 4y ago
  Documentation that explains historical context is sometimes useful. The part that gets you is assuming it to be current. It might help to put dates on things?
- MattPalmer1086 4y ago
  Documentation at a high level should exist as to what a system does and roughly how it works. Feature changes and so on need to be documented somewhere. The high level design aspects and change. Detailed documentation on software is a waste of time in my opinion. The software itself is indeed the best guide to how it actually works. Having no documentation at all is not good.
  - awinter-py 4y ago
    keep the space shuttle flying, do not simplify this code
    - MattPalmer1086 4y ago
      Safety critical systems is a whole discipline I'd love to know more about.
      - awinter-py 4y ago

dlor 4y ago

I'm not going to argue that the NSA report is amazing or terribly well-written, but re-reading it with the principle of charity nullifys many of these rebuttals. For one example, from the rebuttal: > If there is concern that their user credentials will beget malefaction and mistakes, then why discourage service accounts2, which are inherently decoupled from specific user identities? But then looking at the text from the document itself: > Minimize and regularly audit service accounts, > The use of service accounts, like non-human privileged accounts used to run automated processes, should be minimized and carefully audited. Every service account login should be logged. These logs should include date and time and the origin of login. Service accounts should follow the “least privileged” policy. All service accounts should be regularly reviewed to assure they are still needed, and unnecessary accounts removed. I don't think the document is saying to avoid service accounts in favor of something silly like shared passwords. It's saying to use the fewest you can get away with, delete unused ones, and regularly audit access to them.

MattPalmer1086 4y ago
Yes, agreed. The report itself is not unreasonable. The article sets up a lot of straw men and demolishes them.

_wldu 4y ago

I agree 100% with this statement (and with the article in general): “Basic hygiene” is arguably better than any of these bolt-on option, including things like: * Knowing what dependencies are present * Being purposeful about what goes into your software * Choosing a tech stack you can understand and maintain * Choosing tools that are appropriate for the software you are building

MattPalmer1086 4y ago
It's true in security in general, that really sticking to basic hygiene would mitigate a lot of more advanced threats. We haven't had much success over the decades though in getting people to stick to it.

xg15 4y ago

A bit OT, but I find it somewhat counterproductive that the link that gets (close to) HN's front-page is not "NSA Releases New Security Guidelines" but instead "Random Developer X Thinks New Security Guidelines are Total Garbage". Like, I get how story submission and voting works on HN, but I think the effect that the first news about the guidelines arrive with immediate negative framing is not really helpful to evaluating them.