Note: This posting is my own and doesn’t necessarily represent IBM’s positions, strategies or opinions.
For over a decade I have been involved in deploying security controls across many hundreds of thousands of devices. When deploying any security controls, across a server or workstation environment, the first question I ask is – what is the baseline list of devices for deployment? Unfortunately, the answer can be – “This is the list of devices we think we have”.
If this is the answer, the coverage of the security controls is likely to be incomplete leaving a potential gap in the controls that will leave an organisation open to exploitation of vulnerabilities. Having a trusted baseline list of devices is the foundation requirement for all systems and security management.
Over the past 18 months I have been providing technical leadership for a programme to deliver a closed life-cycle approach to managing a baseline list of devices for 10’s of customers. I wanted to share my experiences on the approach that has been used.
An Untrusted Baseline
A baseline list of devices for deployment of security controls may have been created based on reconciling different data sources including listings from tools and directories but also physical wall-to-wall inventory checks in a data centre. This can be incomplete as people miss devices such as a device hidden in the ceiling or the workstation configured as a server under a desk. The list then becomes more untrustworthy over time as it it maintained manually. The device activation process to register and de-register a device should maintain the baseline list but it is devices that fall outside the main process that pose the biggest risk.
Manual Controls Do Not Work
Manual controls will not detect rogue devices. At one customer, a small department purchased their own servers to connect to the Internet that were unpatched with the result that they were very quickly wiped out by a worm and put the rest of the network at risk. Other devices such as contractor laptops bring their own risks and the security controls are unknown on these devices. My experience over the past twenty years has repeatedly shown that manual maintenance of a baseline list of devices does not work.
Incomplete Asset Discovery
Asset discovery tools, including nmap, can be used to scan a network for devices but this creates its down issues:
- The results need to be manually sorted and reconciled regularly outside the asset discovery tool but experience shows that any manual process is open to errors or a failure to perform the process when things get hectic.
- The asset discovery tool also does not validate the configuration of a device as the scan does not provide a 100% confidence level in the configuration of the device. Only by installing software on a device can the configuration be fully determined.
- The devices may be on many hundreds of different network segments connected across WANs that are low bandwidth and across which asset discovery scans cannot be performed.
- Sometimes virtual devices are turned off which means the device cannot be detected using asset discovery. These devices may be missed and there could be many hundreds of virtual devices not in the baseline.
The Baseline Life-cycle
This has always been a big problem until I worked with BigFix – which IBM purchased and re-branded the software as IBM Endpoint Manager. At the core of the product is its ability to provide a continuously maintained view of both managed and unmanaged devices. Each device will go through a cycle of being activated, maintained and then deactivated.
Devices should have an IEM agent installed at initial build but if not, unmanaged devices are identified using asset discovery. No dedicated scan points are needed as the scan points can be installed and run locally on any Windows device (either servers, desktops or laptops) at a regularly scheduled interval. This list of devices is then automatically reconciled against the list of known managed devices which removes the need to filter which devices are of interest. This replaces a previously manual step with regularly scheduled automated asset discovery and reconciliation.
A virtual image manager has recently been added to IEM which can interrogate software managing virtual images to obtain an inventory of all virtual images whether they are turned on or not. Of course, the virtual image managers can be discovered through asset discovery on a network.
The IEM agent can be installed automatically on hundreds of unmanaged devices in minutes by using the remote install tool and the devices now become managed with a validated view of the configuration for each device. The managed device within the IEM provides continuously updated data on the configuration of an end point which is available directly to service and project management staff through a web reporting tool. The data can also feed whatever configuration management system is being used. This removes the need to request the configuration data from technical teams and makes a current view of device configurations available to the staff that need accurate data.
The same IEM tool can be used for systems and security management for processes such as security patch management and anti-virus software. Have you seen anti-virus software reporting near 100% coverage but when you dig deeper the device list does not match the baseline list of devices? In this case, the baseline is trusted because it is continuously validated and the reporting for security controls is trusted because it uses the validated baseline within IEM. No reconciliation is needed between data sources as the trusted baseline is in the same database table as the systems and security management tooling.
Devices should be formally deactivated at the end of their life and removed from the IEM tooling. If not, IEM detects a device that is not connecting within minutes. A process can be put in place to follow-up on the inactive devices to ensure a complete device deactivation takes place including wiping of confidential data from disks.
If a formally deactivated device is turned back on, the asset discovery function in IEM will detect the device reappearing and the cycle can start again.
A Miracle Worker?
IEM is not a miracle worker; so if a server is behind a firewall it may not find it. A wall-to-wall inventory will always be needed to find some of those devices and as the agent install software can ‘walk’ an Active Directory it is possible to find devices behind firewalls that way as well.
The ongoing active scanning of network segments, even in remote offices from a workstation on the other side of the world, will maintain a baseline list of devices. The same tool is used for systems and security management tasks providing a vast improvement over any manual reconciliation method.
Process and Organisation
Key to making this all work is the implementation two processes:
- Management of the unmanaged devices list
- Management of the inactive devices list
The ownership and accountability of these processes is also key; which may mean a change of organisation and responsibilities should be considered.
Is This Reality?
Experience shows from leading the deployment and ongoing running of a service that the process to maintain a validated baseline works very effectively. So when you look for a systems and security management solution – does it maintain a single database of managed and unmanaged devices with asset discovery, continuous compliance reporting and management tooling at the core? Without it, how do you know you have a complete set of security controls.