Best Known method for creating a Zero Day AV update policy

Version 4

    Verified Product Versions

    LANDESK Management Suite 9.5

    Zero Day AV Update

     

    Versions effected: LDMS 9.5 and newer

     

    Problem:

    Your security compliance states you are required to ensure the AV definitions on each machine in your environment are updated as close as possible to the current date. In other words you require a 'Zero' Day AV update' policy.

     

    Solution:

    Unfortunately due to the complexity of the problem there is not one easy solution to achieve this but there are a variety of methods that you can utilise on the Core and the client to make sure that you get on or close to the 'Zero' day AV update target.  In addition to this you will have reports to reflect this.

     

    More specifically any machine activity or report created from the 'Security activity' centre will show this information in a more accurate way that you can rely on because this document will guide you through the entire process and set of methods.

    1.png

    Pre-requisites to 'Zero day AV'

    The first thing you need to have is an understanding of the AV component of LDMS and how it works. Here is a great community article on the AV client in LDMS and how it can be used:

     

    LANDesk Antivirus 9 Advanced Training

    http://community.landesk.com/support/docs/DOC-7479

    E-Learning - LANDesk Antivirus - Video

    http://community.landesk.com/support/docs/DOC-22200

     

    Once you have read this and understand the information within the training itself, we can start on configuring the Core with the AV settings as needed.

     

    Initial Setup and planning

    Before you go any further you need to think about the following in your environment so you can plan out the settings before you go on to apply them to the different regions/offices so that the information that you collect is consistent and you don’t have a few machines on different schedules making the 'Zero Day AV update' task harder to achieve.

     

    What you need to consider, when creating the AV settings:

     

    • How many regions are there (going to be) attached to the Core? E.g. EMEA, APAC, Africa, USA, North /South America etc.
    • How many offices in each region? 1, 2 more?
    • What are the time zones for each office /Region? 1, 2?
    • How do they differ from the Core? e.g.  +/- a few hours or more?
    • How many workstations/servers are in each office and what is there function?
    • And finally the distance from the Core? This will help determine if you need to update via the Core, from a preferred server or directly from the internet?

     

    All this will determine how you manage your update procedure. Do you need your servers to have a zero day AV update policy or just your workstations? Bear in mind that when you initially install the AV product that a restart to the machine will be needed for the AV to be fully installed. This maybe something you do not want to do on servers that are mission critical such as a DC or file servers in certain regions. So some downtime will be needed to be planned for these machines to fully protect them with AV.


    Another thing to bear in mind is the number of nodes that you have attached to the Core. These methods are quite intensive on the Core and the nodes will send and receive a lot of information from the Core. You can end up with a situation where the Core is saturated with information preventing machines from downloading updates correctly, in a sense getting blocked.

     

    Following these hardware specifications as a rough guide, make sure that you hardware is up to the task in hand.

    Nodes

    Processor

    RAM

    Disk

    1-2000

    Single server

    Intel Xeon Process or faster

    4GB+

    10GB free on 10K RPM+ drives

    2000-6000

    Multi-server

    Dual Intel Xeon Process or faster

    8GB+

    20GB free on 15K RPM

    1 full duplex 1000mbps NIC

    6000+

    Core server

    Dual Intel Xeon Process or faster

    4GB+

    20GB free on 15K RPM

    1 full duplex 1000MB NIC

    6000+

    DBMS server

    Quad Intel Xeon Process or faster

    8GB+

    20GB free Raid 5 SCSI

    2 full duplex 1000MB NIC

    Start separating out services, this will help alleviate pressure from the Core and let it focus on computer management rather than for example, hosting the SQL DB, patching or software distribution. All these can be placed on other servers to spread the load and bandwidth of distribution that comes with these services. For example, hosting the DB on a separate SQL server, placing the software distribution share on a separate file server, and storing the patch share on another server.

     

    To create a software distribution share on another server follow these steps:

    1. On your chosen file server create a share with you name of your choice, in this example we are going to use 'SWDist'
    2. Once the folder is created, share it with these security settings as a minimum:

    Everyone: Read & Execute, List Folder Contents, Read

    NETWORK SERVICE: Full Control

    Administrators: Full Control

     

    Share settings:

    Everyone: Read

    Administrator or Domain Admin: Read & Write

     

    Add any additional shares as needed.

    1. Once created, place the installation packages required for software distribution from the Core
    2. Remember that your package share has now moved from the Core to the remote file server, adjust the paths of any pre-existing packages to follow suite

     

    If you require the share to be able to be accessed over http refer to this article from the community:

    HTTP repository for SWD/Preferred Server in IIS 7.5

    http://community.landesk.com/support/docs/DOC-22861

     

    The same method above can used to create a share for the patch and compliance component. The only difference is that for this service the HTTP protocol must be set up for the patching to work in the most effective way.

     

    Further to this you can create preferred servers which can host the patch files and software distribution files locally on a remote site. This will increase the speed of package installations from the Core, and patching.

     

    This article will take you through the process of creating the preferred servers and then how to set up the syncing with the content replication tool on the Core:

     

    Using LANDesk Content Replication

    http://community.landesk.com/support/docs/DOC-20779

     

    Then using the above article, http://community.landesk.com/support/docs/DOC-22861, you can add the functionality of sharing packages through HTTP

     

    Initial set up 'Zero Day AV'

    Once you have separate out the services and increased the compatibility of your Core you can move onto the next task of setting up the Core and creating the required agent settings so we can achieve the 'Zero Day AV update'

     

    Working from the Core to the client, the first thing we need to look at is the AV updates themselves on the Core.

     

    Please read this article to get a better idea of the different download options for the updates and what to consider in different locations:

    Configuring regular LANDesk Antivirus pattern file updates

    http://community.landesk.com/support/docs/DOC-6842

     

    Focus on the first part of the article and the video that talks about 'Configuring scheduled pattern file updates on the LANDesk Core Server'

    Now that you have a good idea of the download options for the updates themselves it’s time to consider what languages you need and when to set up the schedule to download them.

    2.png

    As mentioned above this will be individual to your environment and what regions you manage and support.

    Now you need to consider the schedule, when do you want to download these updates? Due to different time regions and pattern syncing between preferred servers (see below) what's the best time to download the latest patterns so every machine under your purview will be updated in a 'Zero day Manner'?

     

    For example:

    For UK based sites:

    You can set the AV pattern download for 01:00 AM in the morning, as you may have backups and maintenance tasks performing at 12:00 midnight. This would allow enough time for syncing of the pattern between sites and the preferred servers. To be performed between 2-5 AM. This would then allow enough time for the AV administrators to be notified of any issues so that they can repair them before everyone gets in the office. So when end users start to come in between 8-9 in the morning, the updates will be ready and start deploying to end users machines when they switch their machine on.

     

    With the preferred servers in mind, here is a great article on how to set them up for the AV updates:

    How to Configure a Preferred Server for LANDesk Antivirus pattern file content

    http://community.landesk.com/support/docs/DOC-24890

     

    Now that you have set up the downloads for the AV updates on the Core, we can start looking at the agent settings and see what we need to consider.

     

    For the 'Zero Day Av update' task to be achievable you will need to focus on three schedules and processes. This will also have beneficial effects for other components on the LDMS Core as well as the AV component.

    The three components/processes are:

    -The inventory scanner

    -The Security scan

    -The AV update process itself

     

    These all need to be processed in a specific order. This will depend on how your network is setup and how these will work best in that environment. The reason for this is that each component updates AV in differently and reports information to the Core on the status of the updates in different ways. By designing a process which utilises the advantages of each process you can be sure that the information you gather from the Core reflects the true status of AV on the end clients.

     

    Here is a brief explanation of how you can use each one specifically for this situation:

    -Inventory scanner - This will update the inventory of the specific node on the Core, checking the date on the AV to see if it has been updated or not, in turn letting the Core know whether or not the client has the most up to date AV definitions.

    This can vary, if the inventory scan is a full scan then this will update all the information on the Core, if its performs a mini scan this is not always the case.

    -Security scan - The security scan can be used to detect existence of AV and if its definitions are up to date.  It will also implement an AV update if needed. This will always update the AV update progress on the Core, but if a restart is required then this will not be recorded on the Core in every case if the updates are not applied until a restart has been performed.

    -AV update- If scheduled the AV will update itself

     

    With all this information in mind you can start to create an agent that will keep the information of the computer up to date and relevant on the Core.

     

    The next thing you need to do is to create some AV settings on the Core itself ready for the AV deployment. Following the above guidance create some AV settings that are appropriate for your environment.

    3.png

    Using the advance training above, create some agent settings for the different environments that you mange in your environment. For example, are they remote users, are they in the office in another country, or are they the computer next to you? This will have to be considered differently for each region /location.

     

    Referring to this article again:

    Configuring regular LANDesk Antivirus pattern file updates

    http://community.landesk.com/support/docs/DOC-6842

     

    Please read and watch the video in the section tilted: Configuring scheduled pattern file updates on the LANDesk Client

    As mentioned in the article, you first have to consider what location you are going to use as the download source for the AV updates.

    4.png

    'Core Only ': This is designed to be used in a controlled environment when you want only the updates that you approve to be distributed to the clients. This is not advised for this scenario because for whatever reason the client cannot contact the Core then the machine will not download any updates.

    I recommended only using this for machines on site as they are more likely to always have a connection to the Core.

     

    'Core First . Fall Back to internet if Core is not available ': As described. This will contact the Core and download updates from that location first then revert to the internet if no connection is made.

    This is great for clients in the office and clients that work from home. This is because the AV will always be updated as long as the machine has a connection to the Core or the internet.

     

    'Internet only': As described this will only get AV updates from the web.

    This is ideal if you don’t want to store updates on the Core server or using the preferred server. But this option relies on the machine having a connection to the internet, which in some environments is not possible.

     

    'Internet First. Fall back to Core if internet is not available’: As described.

    This can be ideal for home workers who come into the office LAN environment on a rare basis. Or if the office LAN is very secure, such as bank, and does not allow internet access in the office but allows access to internal servers.

     

    You do not have to use the same download source for every office. You can create a number of AV settings that have a variety of download locations.

    It is recommended that when you first implement this process that you try a few options and see which option works best in your environment.

     

    When to update:

    As we have mentioned above with the three different schedules to be processed, when to perform the AV update is just as important as the rest of the processes and the 'Zero day AV'. If the machine is not on during the update window then it may miss its update window and try again the next day. This will affect your 'Zero AV Update' reports.

    To prevent this plan, an update window that is very generous and has a random start up time of, for example 3 hours. This will give the users enough time for the machine to log in and for the AV update process to run.

    5.png

    In this example, I have set the update process to run at 10:00, to allow for lateness or late starters, and have given a random delay of 3 hours. This will make the update window available between 11:00- 14:00.

    This is ideal. This process will not interfere with my inventory scan which I have running in the morning between 8:00- 10:00 and does not run into my patch process which runs toward the end of the day between 15:00-20:00

     

    Other client settings to consider:

    Now we have set up the Core and the clients for the AV we will now see how we can use the other process to create backup process for the AV and the reporting of the AV to the Core.

    The AV process will work 9 times out of 10, but there will always be times when, for whatever reason the client cannot connect to the Core or the internet. So using the security patch part of LDMS we can create a backup process for the AV update so the client machine can be updated by either process. As the issue which may have been blocking the AV update before may now be resolved or gone away.

     

    You can set this up by adding the 'Antivirus' patch definition AV-107 to your scan folder in the 'Patch and Compliance' component and configuring it to autofix on scan. You can specify which scope to apply this to. So if you’re using the same scan options for your servers then the AV will not updated until you are ready in case a restart is needed.

    It also suggested that you override the severity in the properties for the definition AV-107 so that you can let all the administrators that use LANDesk know that this definition is important or critical. In the 'Zero Day AV Update' scenario it is.

    6.png

    Further to having this backup for the actual update for the AV, the security scan process will also update the Core with up to date information as to whether or not the AV is up to date for reporting purposes.

     

    The final process to setup is the inventory scanner. This is another tool we can use to back up the actual reporting process as to whether or not the actual AV on the client is up to date and that the Core reflects the most up to date information.

     

    The security scan process can run the update and update the Core with the relevant date of the update, but if a restart is required then this will not be reported to the Core. So by using the inventory scanner in the morning you can scan the machine after each reboot and update the AV pattern date on the Core.

     

     

    Finalised agent:

    Now that you have setup the Core with the schedule for the download for the AV updates, the preferred servers needed in each office, the patch and compliance component for AV updates and the required AV settings for the agents for each scenario your end users are in. You can now create the agent to send to them so you can start the actual process of the 'Zero day AV update' policy.

     

    Things to consider:

    When do you want the agent inventory to run?

    When do you want the agent AV updates to run?

    When do you want the agent security scan to run?

     

    In my example above I have recommended the following:

    Core:

    Download of pattern files to Core: 01:00

    Scheduled sync of pattern files to preferred servers: 2:00- 5:00

     

    Client:

    Inventory scan: 8:00-10:00

    AV Update: 11:00-14:00

    Security scan: 15:00 - 20:00

     

    Once you have set these up on the agent, please ensure you test, and then deploy.

    The testing is for your confidence in the process that you have setup and to make sure that the settings and timings you use are as close to perfect as possible.

     

    Useful tools to help with the implementation of the 'Zero Day AV update' Goal

     

    You can setup alerts so that you are informed by email for any machines that are out of date, to help you keep an eye of the roll out of the process and maintaining it afterwards. This article will help to do this:

    How to configure Alerting for out of date virus definitions

    http://community.landesk.com/support/docs/DOC-24102