Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 1028 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

How to setup policy to NOT update definitions automatically

jjudge8U

Hey everyone,

I have a Sophos environment deployed that is pretty much being used primarily for just a few Windows servers.

These servers are comprosed of tes/QA systems and thier Production counterparts.

Due to compliance guidelines, I have to have it set up so that the definition updates are tested before they are applied to production.

Now I know that testing virus definitions is not really feasable, but I still have to show I comply some how.

Right now the servers jsut get the updates automatically.

Is there a way to have the Procution servers get updates say a week after they have been applied to the test systems?

Or some other solution that does not involve manually having to apply definitions every so often????

:44199


This thread was automatically locked due to age.
  • 0
    Check out this thread: /search?q= 44171 Similar question, and I posted something at the bottom that may give you some ideas
    :44201
  • 0

    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

    :44219
Cookie Information Banner