3 ms·

Well, for starters those standards don't seem to be targeted to individuals, and often the goal seems to be to just allow someone to say "I'm compliant with XXX

by devit 11y ago

Well, for starters those standards don't seem to be targeted to individuals, and often the goal seems to be to just allow someone to say "I'm compliant with XXX" rather than telling them how to be secure. The practical advice they give is in the form of obvious generalities ("setup your firewalls", "update your OS") without any concrete details on how to best do that or even a discussion on which attacks are prevented and which aren't Threat model discussions, advice on choosing which threats you can realistically defend against, theoretical principles and talk about possible attacks also seem to be non-existent.

akshatpradhan 11y ago
>The practical advice they give is in the form of obvious generalities ("setup your firewalls", "update your OS") without any concrete details on how to best do that I hope you're not suggesting that security compliance isn't necessary because of the time-consuming external research involved. Sure its a usability problem but does that mean we should throw it out and just stick with Penetration Testing, Intrusion Detection Systems, and Risk Assessments? A security guy actually told me that just doing Pentesting, Risk Assessments, and IDS was good enough. Personally, I believe the rest of the world doesn't have a reasonable alternative except for going through a thorough cleansing process of security compliance. That's why its been my mission to take out the guesswork from security compliance frameworks like DFARS 252.204-7012, COBIT, PCI-DSS, HIPAA, FEDRAMP/FISMA, ISO 27001/2. However, I understand that these Compliance Frameworks might not be for you. It seems like you're already self-compliant with your security processes and you're so security-competent that you're doing things right the first time around.
- superuser2 11y ago
  It seems that organizations where security is a compliance-driven process are barely concerned or not concerned at all about security breaches, only regulators. Some of those processes are a fucking joke. The HIPAA technical safeguards include nothing particularly interesting; the hard part is the paperwork and legal ass-covering. Some PCI-DSS "auditors" are nothing more than salespeople who bought Nessus or similar and charge $10k/pop to run it, slap a logo on its report, and email it to you. Security regulations that businesses at large actually seem to care about have nothing at all to do with secure software engineering, just checking boxes like "have a firewall" and "have a password policy" and "have a network security policy" as if producing an endless trail of Word documents will make you less vulnerable.
  - akshatpradhan 11y ago
    >Some of those processes are a fucking joke. superuser2: you're telling me that having a process for firewall changes or rotating your keys is a joke? What other process is a fucking joke? System Hardening? Log review? Source code analysis? Updating your network diagrams? Physical access monitoring? These are all processes (and more) that compliance says you should do. You bitch about word documents when I bet you've never even gone through a thorough compliance process.

by devit 11y ago

akshatpradhan 11y ago

>The practical advice they give is in the form of obvious generalities ("setup your firewalls", "update your OS") without any concrete details on how to best do that I hope you're not suggesting that security compliance isn't necessary because of the time-consuming external research involved. Sure its a usability problem but does that mean we should throw it out and just stick with Penetration Testing, Intrusion Detection Systems, and Risk Assessments? A security guy actually told me that just doing Pentesting, Risk Assessments, and IDS was good enough. Personally, I believe the rest of the world doesn't have a reasonable alternative except for going through a thorough cleansing process of security compliance. That's why its been my mission to take out the guesswork from security compliance frameworks like DFARS 252.204-7012, COBIT, PCI-DSS, HIPAA, FEDRAMP/FISMA, ISO 27001/2. However, I understand that these Compliance Frameworks might not be for you. It seems like you're already self-compliant with your security processes and you're so security-competent that you're doing things right the first time around.

superuser2 11y ago
It seems that organizations where security is a compliance-driven process are barely concerned or not concerned at all about security breaches, only regulators. Some of those processes are a fucking joke. The HIPAA technical safeguards include nothing particularly interesting; the hard part is the paperwork and legal ass-covering. Some PCI-DSS "auditors" are nothing more than salespeople who bought Nessus or similar and charge $10k/pop to run it, slap a logo on its report, and email it to you. Security regulations that businesses at large actually seem to care about have nothing at all to do with secure software engineering, just checking boxes like "have a firewall" and "have a password policy" and "have a network security policy" as if producing an endless trail of Word documents will make you less vulnerable.
- akshatpradhan 11y ago
  >Some of those processes are a fucking joke. superuser2: you're telling me that having a process for firewall changes or rotating your keys is a joke? What other process is a fucking joke? System Hardening? Log review? Source code analysis? Updating your network diagrams? Physical access monitoring? These are all processes (and more) that compliance says you should do. You bitch about word documents when I bet you've never even gone through a thorough compliance process.