It sounds simple, but it’s not. A lot of people speak of holistic security but rarely do they bring risk into the equation.

To be direct, password strength is a moot point to me in itself. Set your standard and measure compliance to it. Know that AD versus 2factor auth has different security strength and apply where needed and account for the risk in the application.

The whole view is more important. If passwords are the only threat vector that exists, fine, but doubt that addresses the whole picture.

Sorry for the delayed reply. I luckily ran back into this post. There is no alert system here. If you want to chat, find me via LinkedIn.

It took many iterations to figure out and it’s still not perfect, but my premise was to first not give up (come up with something useful), set deadlines for each iteration, figure out what numerical values we had and mix these quantitative measures and with guessed qualitative numbers to calculate risk scores, stack them up to rank priorities, and go from there. When the teams had time, I asked them to spot check and engage on Medium-to-Low risk requests, and use that as a feedback loop to assess how/if the calculations were off and adapt the numbers and/or the algorithm.

For the overall application/process risk register, we cycled through reviews semi-annually and mainly used qualitative measures to adjust.

Before I left my last post, we were plugging operational risk, brand risk, and security risk into the corporate GRC movement to add to their scoring system and getting out of the one-off risk business.

My teams needed this at the time to stack rate and rank security requests coming in and a way to identify what was most important to security and why we were spending time in certain areas. It also helped demonstrate team effectiveness and resource utilization by risk. I more than doubled my headcount in my time, got people promoted by demonstrating success, and achieved a lot in the short time I was there at a very large, global company affecting almost 8,000 developers that were not use to taking leadership from the security team, having standards (let alone security standards), and were use to working in a very siloed manner. The heart of my SDL program was based on these risk assessments and establishing a risk register that accounted for our application and process inventory and risk rating and stack ranking ALL of this company’s apps. No small feat but done in under a couple of years, moving a lot of earth, and helping people [understand that they needed to] march in the same direction for the sake of security [and privacy and compliance based on risk].

Hope this helped.

/Phil

Hope this helps.

To understand what I mean by tangential controls, let’s look at Windows platforms as an example where there are several password-related controls: length, history, complexity, and so on. This set of controls is directly related to the conversation presented in the original post.

But, in the conversation, there were at least two other sets of controls hinted at. At one point, the argument in favor of changing passwords required adding a machine into the domain (it could have been implied that this is someone authorized to do so). Furthermore, there is an overall assumption that everything sent between servers is encrypted where it ought to be, which may not be the case. Windows has several SMB-related encryption/signature controls, and encryption won’t necessarily be enabled, which may lead to grabbing hashes on an improperly secured network. Windows provides another set of controls aimed at the prevention of passive network attacks, and there’s another set of controls seeking to ensure that smart switches, VLANs, and other mitigating factors are considered or in place.

This is the long way around to the point that assessing the risk for any single control or set of related controls (i.e. password controls) might require looking at the risk of certain tangential controls. To properly assess the risk involved in password cracking, it’s important not just to look at what controls related directly to the task, but also to those that enable the task.

If I have no controls over who could add machines to my domain, then that affects my password lifetime. If I have no controls over who can sniff my network and I do not have encryption enabled for SMB traffic, then that also affects my password lifetime.

But, are there controls affecting passive network attacks? Are there controls affecting the controls governing adding machines to the domain?

Changing the passwords invalidates those hashes. So, how often do you want to make that attacker work to get back in?

Yes, someone on that machine already has access to that data. However, in some scenarios, you need to worry about someone establishing a foothold and holding it for later use. That’s the time that you have to worry about cached credentials and password cracking.

On the flip side, the more often you make your users change passwords, the harder time they’ll have remembering complex passwords. At some point they’ll either dial down their complexity (everyone loses here) or start writing them down. Ouch.

The real answer is one time passwords generated by some token. Best of both worlds

I ask because a knee-jerk reaction I get is “We don’t have time/resources to do all this analysis”.