Virtualization is here and like it or not, your organization is implementing (regardless of your security practice model or current maturity level). Perhaps its just cool technology; but then again consider the business advantages related to server consolidation, disaster recovery or high availability, cost containment, and perhaps efficiency too. A (centralized) server-set that acts like any other configured for on the fly fault tolerant while possibly reducing network traffic switching; and finally some studies/implementation report nearly 600% ROI in just a year (sounds a bit high but anything’s possible).
So leverage your existing information security policies, include a couple other key control considerations and let it ride.
First, lock down the O/S like any critical system from physical environment to patching and IDS/anti-malware to start protecting the physical and virtual asset. Disable any unused services (e.g. rely on SSH instead of native IV Console) and provide extra safeguard around system files including .vmx files and appropriate logging of access, etc. And, disable unnecessary server functions, prevent unauthorized devices not connected as well as removal of connected. Beginning with these safeguards will limit security exposures including “hyperjacking” or the ability for attackers to compromise the entire virtualized environment.
Access privileges levels should always be reviewed in any implementation, limiting Guest and other account or operating system functionality to achieve the least privileges model. Appropriate file permissions and proper integration of LDAP or NIS directory services is essential in narrowing the attack surface. If all this sounds familiar…it should. The fundamental core of these practices relate to the information security protection of any mission critical company computing resources.
The next layer of defense is at the networking-side component. The system firewall should be enabled to limit TCP/UDP ports and services; and network segmentation/isolation should be configured (hopefully more than simply Layer 2 VLAN). MAC address spoofing or the option to accept request from another destination MAC address other than the effective should be disabled. Additionally, ensuring forged transmission setting is configured such that comparison of MAC address matches the effective sourced. And, if SAN (Storage Area Network) is used, ensure LUN masking or zoning in exercised, reducing zone visibility and selectively presentation only necessary storage information. Other consideration include: not using nonpersistent disk so offline access/vulnerability is not feasible, disable virtual disk modification preventing elevated privilege exposures, not allowing promiscuous mode on network interfaces so that packets are not read across the network among other virtual network.
Lastly, when it comes to logging, implement what you would normally require of critical assets including activity tracking particularly for web access to VMWare, connection/authentication records, console and error messages, availability of agent and interrupts; and secure storage of log files (e.g. in ESXi 3.5 files hosd.log, message, and vpxalog). When combined with file integrity (e.g. TripWire) monitoring, you’re starting to build onto your SIM/SEM platform.
For additional security controls, enable certificate-based encryption when legitimacy of the root certificate authority and client/certs are required. And, weigh the risk with compliance strategy.
So I ask you, who owns virtual security in your organization? And, given your existing technology integration and existing change management effectiveness, how do you best monitor your ESX environment and how is it audited?
No comments:
Post a Comment