Information security is a field filled with concepts that are easy to say and very hard to do. I have never read your security policy, but I bet that it contains the principle of least privilege. Conceptually, its pretty hard to argue with the principle of least privilege. After all, why would you ever provision a user or a function with more privileges than it needs? But while its easy to say, the only logical next question for an engineer is - ok, how do I deliver that?
Try this sometime, when you say "principle of least privilege" watch all the heads nodding and knowing looks. Of course, of course, yes that is what must be done. Then ask "ok, how do we do that?" Mostly what you get next is umms, ahhs, long pauses, people staring at their hands.
People think security's biggest problem is attackers and that we need better defenses. That's probably true, but its been true for awhile and may take awhile longer. In the meantime, Infosec teams should consider how they can function better. I think the answers here are not coming from Silicon Valley whiz kids, they are more likely to found in Immanuel Kant:
"The action to which the "ought" applies must indeed be possible under natural conditions."
If our security policy says we "ought" to do something, principle of least privilege or strong auth or what have you, then its on the security architects and engineers to deliver capabilities that can do exactly that.
There is a critical link missing in most Infosec programs, that link is reconciling the security policy and architecture standards to architecture and runtime capabilities. Put simply if what is mentioned in policy and standards does not exist in your existing capabilities, either you need a project working to address or you should take it out of the policy and standards. Its wasting people's time.
People are exhausted being on the other end of security assessments. I do not have a solution for that. Security does need to be more involved in arch, design, and testing. But the nature of our involvement should be dramatically scaled back and focused whenever and wherever possible. Do not drag teams through 37 different policy requirements when there is way that they can address it. Much better to invest resources and time (yours and theirs) on capabilities that have a chance at seeing the light of day in production.
Then there is assurance:
Feynman integrity dictates that its on the asserter to first try and disprove their ideas. Too often security is a dictate, but not one where security teams have done the engineering work to check the capability to deploy much less the efficacy of the recommendation.
T.S. Eliot wrote "in my beginning is my end", Infosec regimes often begin with a list of policy and standard thou shalts. Instead, the beginning point should be a sober review of the existing capabilities. First make sure you know what can you do with those capabilities, take advantage of them, and then go onto filling the gaps that lay between current state of play and desiderata.
Comments