Acceptable Risk (What's it going to take for security to be important?)

It was an interesting weekend in the cyber-security world to say the least. Some guy who goes by"srblche srblchez" began selling .gov, .edu, and .mil websites or more accurately control to those sites. For attribution I am pulling information from multiple sources such as:
Rafal Los' interview with the dude:

Brian Krebs blog:

Martin Bos (purehate_) found the real site here:

Some of the , excellent, points from information security pros are the hair-pullingingly frustrating "I told you so when I tested your environment." I think every pen tester and blue teamer out there has felt this at one point or another. Several talks I saw online last year focused on the fact that we haven't adequately communicated to the decision makers how security impacts their mission or their bottom line. This is completely true. I have seen pen-testing reports that are purely technical and not readable by management executives. Rafal asked "What will it take?" Based on the way we teach economics, and the gazillions of people getting their MBA, it will take a direct tie to putting dollars into the company's pocket. CFO/CEOs want you to be able to answer this question:
"If I invest dollars how much will I earn?" or "If I don't address vulnerability how many dollars will I lose?"

These are not easy questions to answer and a penetration test only brings part of the answer. The larger answer comes from business case analysis and understanding a failure scenario surrounding the vulnerabilities discovered. Until security equals dollars in a pocket then it will be tough. We will continue to fight the "acceptable risk"

This line of thinking comes from my experiences attempting to align security with business mission. I once wrote a five year strategic plan for an organization aligning the mission of security with the mission of the organization and it was completely disregarded. The point is not that my work was not used, the point is that it didn't even generate discussion. No talk, no action. In fact they put someone in charge of security that clearly stated there were almost no problems with their current mode of operations despite test results to the contrary. Even moving beyond that, the group had little funding despite security being "important" to this organization. Sadly, this was not a unique situation. The companies I have seen do security the best were those that know their reputation is on the line and understand that a breach would lose them customers(dollars). Sadly, this would exclude the types of sites that were compromised.

Here are the points for people in charge:

  1. Hire the right people - People who are seeking to learn perpetually and understand that security yesterday is being pwned tomorrow. A project manager or policy maker should not be making technical decisions they do not understand.
  2. Fund these people - Security should be 15-20 % of your IT budget every year. If you haven't seen an equipment upgrade or product requisition for a few years, something is wrong.
  3. Yesterday's technology (firewalling, IPS, DMZ, A/V) needs help - Anti-virus programs are necessary but don't rely on them If you think updated definitions protect you, look up Shikata Ga Nai.
  4. The "help" is your people - Talented infosec people are your only defense. No device you buy is a silver bullet and salespeople will say anything to get a sale. If you don't believe me get a DLP solution and winzip and see for yourself
  5. Test your environment with real scenarios - Don't prescribe the environment to the testing entity. Make it as real as possible or you will never know where you actually stand and be lulled into a false sense of security.
  6. Policy without a technical control is faith - Don't just tell people what not to do, actually prevent it. "We don't allow portable media." is a lot different than "We really hope people aren't using portable media and we will fire them if they do."
  7. Policies and controls must line up - Don't tell your people to have and 8 character password with mixed case and special characters then make them have a password with six characters, single case, and no special characters. (yeah, I have seen this)
  8. Security policies should be written by security people, not HR - If you don't understand the policy, more specifically how to break it, you probably shouldn't write it.
  9. There are more but I 'm tired.

No comments:

Post a Comment