3 Replies Latest reply on Jun 15, 2012 3:20 AM by David Moule

    Vulnerability Mgt "policy"

    David Moule Level 1

      We are trying to wordsmith a document that sets out in simple terms what we do and don't scan. I confess I thought this would be relatively easy but this has not been the case!

       

      As you have deduced from the above we do not scan everything on our network and its actually more for this reason that I need to flush out some sort of list. I'm hoping that the once I have the list of what we don't scan, I can then clarify the reasons why we don't.

       

      I was wondering if anybody out there in the community has tried to do something similar or even suceeded, and would be willing to share their policy in some form or provide hints as to its structure and level of detail that it goes to.

       

      Maybe we could even try collaboratively developing a template !

       

      Thanks in advance

        • Vulnerability Mgt "policy"
          Robert Dell'Immagine Level 5

          Moving to VM area for better visibility.    - Robert (Community Admin)

          • Vulnerability Mgt "policy"
            Hywel Mallett Level 1

            We do VM for PCI-DSS compliance, and we scan everything that are in the network segments that are in scope for PCI-DSS.

              • Vulnerability Mgt "policy"
                David Moule Level 1

                Hywel, thanks for your response. Unfortunately PCI complinace is not an issue for us (at the moment). However your response got me thinking and I have crafted the following as a starter.

                 

                As always I'd be interested in anyones views, comments or suggestions.

                 

                 

                General Principle

                 

                All devices connected to the [organisation's]  infrastructure will be liable for automatic vulnerability scanning by QualysGuard unless:

                 

                1. It does not support the business objectives of [organisation]
                2. It increases the risk of service disruption
                3. It is not technically possible or viable
                4. It exposes [organisation] to unacceptable levels of residual risk
                5. It is prohibited by Contract, Legislation or Regulation
                6. It is not cost beneficial to do so
                7. There are adequate compensating controls

                 

                All such exceptions must be submiited in writing to, and approved by the Information Security Steering Group.