So the other day I wrote a bit about looking for things in the wrong place simply because it is easier. It's a pretty common problem in a variety of human endeavours. But it's not just laziness that causes people to look where the light shines. Often there simply is no perfect means of examining a problem. In some cases we have to rely on proxy metrics because we can't directly measure the goal. It might be a quality we're trying to determine rather than quantity, so we choose something that seems to track along with our desired outcome, and measure that.
Another reason we might do something like this is because we don't have a good understanding of the underlying mechanisms that produce a given result. We don't understand, but we desire a particular outcome, so we try to screw the inscrutable by going through the forms that we've seen other people doing, but without understanding why they did. It's as though, controlling something that looks like something else will influence it (sympathetic magic). It's like a cargo cult ritual where the form is the only thing happening; there's no technical substance to the action.
A long time ago in a galaxy not so far away, a paradigm was born; of a hardened perimeter that would keep attackers out of our networks. As security techniques go, it was primitive but had some significant positive effect. Indeed perimeter or boundary defense is still part of a solid security strategy. But it's only a part. Although we've long since passed the point where a simple OSI model layer 3-4 access control list based upon source IP, destination IP, and TCP port is sufficient for security, people are still doing it "The Way We've Always Done It™". Attacks are far more sophisticated now than when the "hard crunchy shell" first surrounded the "soft gooey center" of a network. (Now I want a candy bar!)
We need a layered defense that includes controls internal to our network. We also need security mechanisms that are not based on integrity of the function they are trying to protect. This means that not all security mechanisms can or should be all-in-one. While NERC CIP uses "systems" language at the Requirements level, many of the Measures, the RSAWs and the VRF/VSLs implicitly require a given device to provide the control. This is yet another example of wanting the auditing approach to be simple and easy (looking only where the light is shining).
Unfortunately that sort of simple-to-audit approach precludes, or at least discourages, layered defense mechanisms where components of the security mechanism are provided by network-based functions that integrate multiple types of devices. For example, AAA or Authentication, Authorization, and Accounting functions (which in the NERC CIP world for some bizarre reason is called "Electronic Access Control & Monitoring System or EACMS) generally should not reside entirely upon the single device being accessed, if for no other reason than users requiring access to this device means that attacks on the security mechanisms embedded in it are possible. Far better to have this device act as a AAA client and receive Authentication and Authorization from that network-based function, while sending Accounting information to it. This isolates the code base of the security appliance(s) from the code base of the device that users require access to, and limits opportunity for privilege escalation.
When your auditor insists upon a simple and clean way to measure compliance at the device level, they may be doing us all a disservice.
Another reason we might do something like this is because we don't have a good understanding of the underlying mechanisms that produce a given result. We don't understand, but we desire a particular outcome, so we try to screw the inscrutable by going through the forms that we've seen other people doing, but without understanding why they did. It's as though, controlling something that looks like something else will influence it (sympathetic magic). It's like a cargo cult ritual where the form is the only thing happening; there's no technical substance to the action.
A long time ago in a galaxy not so far away, a paradigm was born; of a hardened perimeter that would keep attackers out of our networks. As security techniques go, it was primitive but had some significant positive effect. Indeed perimeter or boundary defense is still part of a solid security strategy. But it's only a part. Although we've long since passed the point where a simple OSI model layer 3-4 access control list based upon source IP, destination IP, and TCP port is sufficient for security, people are still doing it "The Way We've Always Done It™". Attacks are far more sophisticated now than when the "hard crunchy shell" first surrounded the "soft gooey center" of a network. (Now I want a candy bar!)
We need a layered defense that includes controls internal to our network. We also need security mechanisms that are not based on integrity of the function they are trying to protect. This means that not all security mechanisms can or should be all-in-one. While NERC CIP uses "systems" language at the Requirements level, many of the Measures, the RSAWs and the VRF/VSLs implicitly require a given device to provide the control. This is yet another example of wanting the auditing approach to be simple and easy (looking only where the light is shining).
Unfortunately that sort of simple-to-audit approach precludes, or at least discourages, layered defense mechanisms where components of the security mechanism are provided by network-based functions that integrate multiple types of devices. For example, AAA or Authentication, Authorization, and Accounting functions (which in the NERC CIP world for some bizarre reason is called "Electronic Access Control & Monitoring System or EACMS) generally should not reside entirely upon the single device being accessed, if for no other reason than users requiring access to this device means that attacks on the security mechanisms embedded in it are possible. Far better to have this device act as a AAA client and receive Authentication and Authorization from that network-based function, while sending Accounting information to it. This isolates the code base of the security appliance(s) from the code base of the device that users require access to, and limits opportunity for privilege escalation.
When your auditor insists upon a simple and clean way to measure compliance at the device level, they may be doing us all a disservice.
No comments:
Post a Comment