6 ms·

he'll probably spend a lot of time having the devs write software based on DoD standards. It's surprising how much of security is "make sure you've configured

he'll probably spend a lot of time having the devs write software based on DoD standards. It's surprising how much of security is "make sure you've configured everything correctly".

qb45 11y ago
It's surprising how much of security is "make sure you've configured everything correctly". Or "don't accept ' or 1=1 -- as a password", for that matter. Internet-facing web system with several thousand users, just a year ago or so. Made me feel like I'm back in the '90s.
- bqe 11y ago
  There's nothing inherently wrong with that password as long as your code isn't vulnerable to SQL injection, which is trivial to do nowadays.
  - qb45 11y ago
    Sure SQL injection is trivial to do nowadays; it's always been. I mean, of course I meant this was an SQL injection.
    - dragonwriter 11y ago
      I'm pretty sure GP was saying making sure your code isn't vulnerable to SQL injection is trivial to do nowadays, not that SQL injection is trivial to do.
    - rylee 11y ago
      It's trivial to not be vulnerable to SQL injection.
      - thephyber 11y ago
        That's not what "trivial" means. Trivial means the simplest possible example, which in almost every web framework involves passing input as received to the DB driver without knowing its contents and without escaping/sanitizing it. Only by using frameworks and DB drivers correctly (RTFM) is one able to accurately avoid SQLi. I would argue that "using software correctly" is by no means trivial and rarely happens in most systems that have less than NASA quality safeguards. I would agree that most modern frameworks which are adopted by at least a few hundred developers tend to use best practices and a "security by default" mindset, but that's far from saying that "avoiding SQLi is trivial".
    - pyre 11y ago
      This: > "don't accept ' or 1=1 -- as a password" (the way that it's stated) implies that one should be checking input for possible SQL injection attacks and dropping the request, rather than sanitizing input so that the attack doesn't work, but the password is valid.
nickpsecurity 11y ago
I'm guessing he'll just apply stuff they developed in NSA for NIDS, patch deployments, etc. Just a good HIPS (esp whitelisting) and patching knocks out 75% of so-called APT's per Australia's DSD. Good monitoring catches many of the rest eventually. Those by themselves, combined with NSA's improvements, would dramatically improve security for organizations that had little of it but lots of money. Probably sells them on an image and liability benefit, too: "bank shouldn't be liable because we even went so far as putting former director of NSA in charge of our security. What more could we have done!?" Trying to counter liability in courts or with lobbying is main security model for big business. So, something like this is undoubtedly a benefit.

he'll probably spend a lot of time having the devs write software based on DoD standards. It's surprising how much of security is "make sure you've configured everything correctly".

qb45 11y ago

It's surprising how much of security is "make sure you've configured everything correctly". Or "don't accept ' or 1=1 -- as a password", for that matter. Internet-facing web system with several thousand users, just a year ago or so. Made me feel like I'm back in the '90s.

bqe 11y ago
There's nothing inherently wrong with that password as long as your code isn't vulnerable to SQL injection, which is trivial to do nowadays.
- qb45 11y ago
  Sure SQL injection is trivial to do nowadays; it's always been. I mean, of course I meant this was an SQL injection.
  - dragonwriter 11y ago
    I'm pretty sure GP was saying making sure your code isn't vulnerable to SQL injection is trivial to do nowadays, not that SQL injection is trivial to do.
  - rylee 11y ago
    It's trivial to not be vulnerable to SQL injection.
    - thephyber 11y ago
      That's not what "trivial" means. Trivial means the simplest possible example, which in almost every web framework involves passing input as received to the DB driver without knowing its contents and without escaping/sanitizing it. Only by using frameworks and DB drivers correctly (RTFM) is one able to accurately avoid SQLi. I would argue that "using software correctly" is by no means trivial and rarely happens in most systems that have less than NASA quality safeguards. I would agree that most modern frameworks which are adopted by at least a few hundred developers tend to use best practices and a "security by default" mindset, but that's far from saying that "avoiding SQLi is trivial".
  - pyre 11y ago
    This: > "don't accept ' or 1=1 -- as a password" (the way that it's stated) implies that one should be checking input for possible SQL injection attacks and dropping the request, rather than sanitizing input so that the attack doesn't work, but the password is valid.

nickpsecurity 11y ago

I'm guessing he'll just apply stuff they developed in NSA for NIDS, patch deployments, etc. Just a good HIPS (esp whitelisting) and patching knocks out 75% of so-called APT's per Australia's DSD. Good monitoring catches many of the rest eventually. Those by themselves, combined with NSA's improvements, would dramatically improve security for organizations that had little of it but lots of money. Probably sells them on an image and liability benefit, too: "bank shouldn't be liable because we even went so far as putting former director of NSA in charge of our security. What more could we have done!?" Trying to counter liability in courts or with lobbying is main security model for big business. So, something like this is undoubtedly a benefit.