[174726] in North American Network Operators' Group
RE: update
daemon@ATHENA.MIT.EDU (Keith Medcalf)
Sun Sep 28 02:58:05 2014
X-Original-To: nanog@nanog.org
Date: Sun, 28 Sep 2014 00:57:48 -0600
In-Reply-To: <CAFS5k-i6Cw=HhEUbYL8Oy=B9OQuFXKmoRio79f59vAW63qVZAg@mail.gmail.com>
From: "Keith Medcalf" <kmedcalf@dessus.com>
To: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Saturday, 27 September, 2014 23:29, Kenneth Finnegan <kennethfinnegan200=
7@gmail.com> said:
>> My original proposition still holds perfectly:
>>
>> (1) The vulnerability profile of a system is fixed at system
>> commissioning.
>> (2) Vulnerabilities do not get created nor destroyed except through
>> implementation of change.
>> (3) If there is no change to a system, then there can be no change in
>> its vulnerabilities.
>Your original proposition is pointlessly academic. Yes, given
>absolutely no changes to the system, it's vulnerability profile does
>not change.
>Does your "correct" system boundary include the file system?
>So you're definition of an unchanging system only uses
>read-only file systems.
Now that would depend, would it not. If you mean as in storing "data" or p=
rocessing "data", then obviously not. If you mean the "executable contents=
" as in "the contents of the filesystem which are executed as part of the s=
ystem" then obviously yes. Changing the "data" content of the filesystem i=
s, in general, why one would implement a system in the first place. Howeve=
r, changing "executable contents" which are then executed implies a change =
which must be assessed.
>Does it include the system's load average?
>Can't ever change the number of clients connected to it... Does it
>include the system's uptime? Etc.
These are only relevant if they are vulnerabilities. If these things are v=
ulnerabilities I should hope that mitigations are in place to prevent them =
from being exploited, and that these mitigations were put in place from the=
get-go rather than when they appeared on CNN.
>So yes, you're right. The number of existing vulnerabilities in a
>system never changes. It's just that you've also ruled out every
>system I can imagine being even remotely useful in life, so your
>argument seems to apply to _nothing_.
No, it applies to everything. It applies to routers and switches and it ap=
plies to Mail Servers, and to everything else. When a network device is im=
plemented everyone makes the assumption that it is, other than its designed=
function (switching packets), a zero-security device. This is why there i=
s control-plane policing. This is why you segregate the management network=
. This is why you create isolated management access. This is why you do n=
ot open up telnet, ssh, ftp, tftp, http, and whatever else to "anyone" on t=
he internet.
If you do this properly, you do not care much about vulnerabilities in teln=
et, ssh, ftp, tftp, or http because they cannot be exploited (or rather, an=
y such issues can only be exploited by a known set of actors). You have pu=
t mitigations in place to address the risks and any possible vulnerabilitie=
s. Just because no one has yet demonstrated a vulnerability does not mean =
that it does not exist.
If you have done this properly (ie, you acted prudently), you no longer car=
e whether there are vulnerabilities or not, because you already have mitiga=
tions in place that would prevent them from being exploited (whether they e=
xist or not).
Then everytime you see on CNN that there is a new major flaw in the swashbu=
ckle that can be taken advantage of by a bottle of whiskey, you pat yoursel=
f on the back and congratulate yourself having already assessed that there =
might be a problem in the swashbuckle when whiskey was present, so you alre=
ady put in mitigations to prevent that. Or maybe you decided that you don'=
t need to swashbuckle at all so you disabled that feature, in which case yo=
u don't really care about the supply of whiskey either.
>What does change for a system is the threat profile as exploits become
>better known. Arguing that it is better to blissful march onward with
>what is *known* to be a vulnerable system instead of rolling out
>stable branch security updates that *generally* contain less bugs
>demonstrates a lack of pragmatism.
No, blindly rolling out patches which fix things that do not need fixing is=
foolhardy. It may very well be that the particular version of IOS runnin=
g has a vulnerability in the http server portion of the software. However,=
that service is disabled because after rational evaluation it was decided =
(when the system was implemented) that the http feature was not required an=
d as part of prudent policy, things which are not required were disabled. =
Therefore, implementation of the change to fix the vulnerability provides z=
ero benefit. In fact, implementation of the change may have other detrimen=
tal effects which I will not know until after implementing the change. The=
refore, the cost/benefit and risk analysis clearly indicates that the chang=
e should not be made.
However, if the change fixes an issue with regards to packet switching/forw=
arding, and if I am experiencing the issue or might experience the issue, t=
hen I should consider applying the change sooner or later, as warranted by =
the circumstances. On the other hand, if it is impossible for the circumst=
ance to arise which will lead to the manifestation of the issue that is the=
subject of the change, then I should not implement the change.
The same can be applied to "upgrading" to an x64 system from an x86 system.=
If there is no need driving the upgrade, then why do it? Doing so change=
s the "vulnerability profile" to something different from what it was, and =
you may fail to account for all the vulnerabilities in the new profile (for=
example buffer overflows and arithmetic overflows due to the increased siz=
e of the process address space). If the current system is working perfectl=
y and has all the appropriate mitigations in place to keep it safe and secu=
re (in the operational sense), then the cost/benefit and risk analysis clea=
rly indicates that the change should not be made.
>I'm sorry that someone on the Internet hasn't precisely used your
>made-up distinction between a "vulnerability profile" and the actual
>threat level given the current state of the rest of the universe.
Operations folks make decisions based on the "vulnerability profile" all th=
e time, whether they realize it or not, and generally could care less about=
the "threat profile". If an operational concern comes about because of a =
change in the "threat level" then there has been a failure to properly asse=
ss the "vulnerability profile" and apply appropriate mitigations; and, that=
failure happened long before the news hit the mainstream media. It is onl=
y if the change in the "threat profile" in light of the existing mitigation=
s already in place as a result of assessing the "vulnerability profile" ind=
icates that a change must be implemented, should a change be implemented. =
This would also require a re-assessment of the "vulnerability profile" of a=
ll existing systems as a result of the new information.
>We >really don't need to be splitting hairs about this on the NANOG
>list...
This may or may not be true. I suspect the density of real Operations folk=
s is greater here than just about anywhere else. (and by that I mean the n=
umber of list subscribers that have actual operational responsibilities for=
keeping things running safely and securely).
