How to setup policy to NOT update definitions automatically

Hello jjudge8U,

compliance guidelines

can be a pain when they aren't aligned with reality :smileytongue:.

In the old mainframe days there were basically two schools of thought when it came to system maintenance: Proactive (Fix it before it breaks) vs. reactive (If it ain't broken, don't fix it) service. It soon turned out that for neither sticking to the pure concept was feasible. "Local" Test&QA has indisputably its merits in a bounded context but it falls short of solving the aforementioned dilemma simply because you don't even know all the factors involved. Thus while you can test how a change affects might affect your environment as far as normal operation is concerned you often can't (due to - amongst others - incomplete information, lack of knowledge, or lack of tools and procedures) test the factors driving the change in the first place. Still this is a valid and sensible approach as long as you consider its limits. There's a final step (often ignored by so-called compliance rules) which has to be taken, namely assessing not only the test results (and their impact) but also the change itself (and the impact of not applying it).    

Enough of this mumbo-jumbo, I'll try to write more understandably. Say a vulnerability has been detected in the OS and is already being exploited. There's a workaround but compliance dictates that it has to be tested before it's applied. After a day your AV vendor releases an update of which is claimed that it will prevent an exploit with high probability. Compliance doesn't permit to use it immediately. Eventually the OS vendor releases a patch - same problem. Now it's unlikely that you can meaningfully test any of them, let alone within a short time. But even if you'd then have to decide to either ditch your compliance or sit on pins and needles until the minimum-interval-required-for-compliance has passed or the required-testing-procedures have been completed. I know that sometimes non-compliance is seen as the far bigger threat and one elects to be struthious when it comes to considering the consequences of delaying a change ... :smileytongue:

Just my two cents 

Christian

Hello jjudge8U,

compliance guidelines

can be a pain when they aren't aligned with reality :smileytongue:.

In the old mainframe days there were basically two schools of thought when it came to system maintenance: Proactive (Fix it before it breaks) vs. reactive (If it ain't broken, don't fix it) service. It soon turned out that for neither sticking to the pure concept was feasible. "Local" Test&QA has indisputably its merits in a bounded context but it falls short of solving the aforementioned dilemma simply because you don't even know all the factors involved. Thus while you can test how a change affects might affect your environment as far as normal operation is concerned you often can't (due to - amongst others - incomplete information, lack of knowledge, or lack of tools and procedures) test the factors driving the change in the first place. Still this is a valid and sensible approach as long as you consider its limits. There's a final step (often ignored by so-called compliance rules) which has to be taken, namely assessing not only the test results (and their impact) but also the change itself (and the impact of not applying it).    

Enough of this mumbo-jumbo, I'll try to write more understandably. Say a vulnerability has been detected in the OS and is already being exploited. There's a workaround but compliance dictates that it has to be tested before it's applied. After a day your AV vendor releases an update of which is claimed that it will prevent an exploit with high probability. Compliance doesn't permit to use it immediately. Eventually the OS vendor releases a patch - same problem. Now it's unlikely that you can meaningfully test any of them, let alone within a short time. But even if you'd then have to decide to either ditch your compliance or sit on pins and needles until the minimum-interval-required-for-compliance has passed or the required-testing-procedures have been completed. I know that sometimes non-compliance is seen as the far bigger threat and one elects to be struthious when it comes to considering the consequences of delaying a change ... :smileytongue:

Just my two cents 

Christian