§ GOS § VIB§ Web client plug-ins Physically secure your server hosts.§ This must be taken care by partnersfor on-prem environment.§ For off-prem partner must use securedcloud platform.
Signing infrastructure.§ As far as it’s inside the firewall,it’s secured.§ If in future we decide to host itoutside as a service we would have to think of more secured way (TBD) Development kit mandates § Securing the WB platformo Installation mandates forplatform.
o Operating system partitionmandates.o Administration andmanagemento Logging and auditing with networksecurity. Installation mandates for platform. ü Physicalaccess limits: Authorize only administrativepersonnel to access the physical host system to prevent unauthorized changes.
ü Integrityof the files must be verified prior to installation:verify the checksum of system files, as provided by the cert team.ü Installand load only selected operating system components and services:no unnecessary systems components and no unnecessary services should be enabled.ü Passwordsprotection: Parameterized passwords should be used for BIOS and bootloaders for both guests and hosts under the certification. Operating system partition mandates.
ü Limit WB resource use: set limits on the use of resources(e.g., processors, memory, disk space, virtual network interfaces) by each VMso that no one VM can monopolizeresources on a system.ü Ensure time synchronizationü Minimize number of accountsü Use of strongauthentication ü Unnecessary programs andservicesü Configuration managementü Patch managementü Hardening guide ü Administrator or root loginü Partitioning and resourceallocationü Space restrictionsü Disconnect unused physicaldevices Administration and management mandates ü Strong authenticationshould be used for host system access: two-factor authentication is recommendedfor access to host system.ü Do not enable file sharingbetween host and guest OSs: while it might be convenient to enable the sharingof system files between the host and guest OSs, allowing such introduces anunacceptable risk of a guest OS possibly maliciously changing a host OS file.ü Warning banners: warningbanners should be used for both hosts and guests.
Warning banners are requiredto successfully prosecute unauthorized users who improperly use a computer.Banners should be displayed on all systems prior to access and warn usersabout: o What is considered theproper use of the system; o That the system is beingmonitored to detect improper use and other illicit activity, and; o That there is noexpectation of privacy while using this system.ü Separation of dutiesü Management of hypervisorsü Regularly make back-upsü Ensure that appropriateaccess control lists (ACLs) restrict copying or mounting images to authorizedsupport personnel. If necessary, encrypt disk directories or partitions, aswell as the back-up media itself.ü Use separate back-upaccountü Follow disaster recovery(DR) procedures for virtual environmentü Prevent “VM sprawl”: thereis a tendency within organizations to allow the creation of more VMs than isnecessary, for various reasons. This tendency can create a serious problem withthe effective management of VMs. Require appropriate permission before VMs canbe created, and before they can be deployed.
ü Creation and deployment ofVMs should both be logged.ü Control VM migration:effective management of VMs also requires controls around, and proper authorizationsfor the migration of VMs.ü Migration of VMs should belogged (e.g., source and target systems, time, and authorization).ü Same risk level per host:all VMs on the same host should process the same level of data sensitivity,following an organization’s data classification policy. ü Separate production fromtest VMs Logging and auditing mandates ü Use centralized logging: centralizelogging of guest OSs, either on a separate logging system or in a repository.Use of centralized logging aids administrators, security personnel, andauditors in verifying configurations and practices in a virtualized environment.
ü Correlate logs: correlateserver and network logs across virtual and physical infrastructures to revealsecurity vulnerabilities and risk. ü Regularly audit virtualizedenvironments: it is important to audit configurations of all components of avirtualized environment, management capabilities, virtual switches, virtual andphysical firewalls, and other security devices (e.g.
, intrusion detectionsystems, anti-malware capabilities). Ensuring compliance with establishedconfiguration management practices is particularly important.ü Root and administrativeprivileges: log and audit monthly root and administrative access and actions onall systems in a virtualized infrastructure.ü Invalid logical accessattempts: log and audit weekly all invalid logical access attempts on all systemsin a virtualized infrastructure.ü Access to all audit trails:log and audit monthly all access to audit trails on all systems in and supportinga virtualized infrastructure (e.g., a centralized log repository).
ü Initialization of auditlogs: log and audit monthly initialization of all audit logs on all systems in andsupporting a virtualized infrastructure (e.g., a centralized log repository).ü Creation and deployment ofVMs: log and audit monthly the creation and deployment of all VMs in avirtualized environment.ü Migration of VMs: log andaudit monthly the migration (e.g., source and target systems, time, andauthorization) of all VMs in a virtualized environment.ü Creation and deletion ofsystem-level objects: log and audit quarterly the creation and deletion of allsystem-level objects in a virtualized infrastructure.
Certification kit mandates § Securing certificationworkload toolso Guest operating systemhardeningo Virtual network security Network configurations. Test API’s. Test Database Server configurations.
Test Web server configurations. Fault tolerant test systems and database. Workload GOS mandates ü Guest operating systemhardeningMinimizenumber of accounts: guests should have accounts necessary for running each VMonly with passwords that are strong, hard to guess, changed frequently, andonly provided to staff that must have access. Separate credentials should beused for access to each guest OS; credentials should not shared across guestOSs, and should not be the same as used for access to the host OS.ü Unnecessary programs andservices: all unnecessary programs should be uninstalled, and all unnecessaryservices should be disabled.
ü Configuration management:configuration management of guest OSs should be centralized to ensure thatconfigurations are standardized. It is likely that multiple configurations willbe required to meet business needs.ü Patch management: guest OSsmust be patched regularly and in a timely fashion to protect VMs. However,timeliness includes procedures for testing patches on non-production systemsfirst to ensure that access to VMs is not disrupted.ü Hardening guide: guest OSsshould be hardened following an organization’s approved hardening or buildstandard.ü Ensure most recent security updates on allvSphere hosts.
ü Protect against unauthorizedadministrators (remove default ones)ü Enforce role separation to limitadministrative exposure tying with DC account.ü Create and maintain secure baselines for allsystems. (May use secure boot or we can create custom images with certainguidelines)ü Strong passwords or pass phrases must be mademandatory.
ü Isolate sites in high security environments.ü Integrityü Accountabilityü FQDNs for all site systems andsenders ü Remove certificates prior to imaging clientsü Ensure to deploy critical software updates Workload network security mandates ü Restricted network access:guest OS should not have management network access, but, ifnecessary,may have network access to storage (iSCSI).ü Firewall: the guest OSshould be protected by a firewall running on the host OS, or at least runninglocally (i.e.
, local to a small number of systems for protection purposes).Firewall needs to discriminate against inappropriate and/or malicious trafficusing networking communications effective for the environment (e.g., ifbridging is used instead of routing). ü Separate VLANs for guestOSs: each guest OS should run on a separate virtual local area network (VLAN)from other guest OSs that it does not need to communicate with. Assignment ofseparate VLAN IDs may require defining port groups for systems on the specificVLAN and allowing administrators to define different settings concerningnetwork access and security policy for virtual machines connected to a singlevirtual switch. As many port groups as necessary may be created for a singlevirtual switch. Virtual network adapters associated with virtual machines maythen be configured to connect to these user-defined port groups.
The virtualadapters connected using a user defined port group inherit and abide by thepolicies defined within the port group.Network Configuration mandates ü Session Managementü Transport Securityü Tiered system segregation at different levelü Virtualdevices: ensure that virtual devices for guest OSs are associatedwith the appropriate physical devices on the host system, such as the mappingbetween virtual network interface cards (NICs) to the proper physical NICs.ü Useof virtual trunk ports: physical switch portsconnected to virtual trunk ports should always be configured as static trunklinks. A virtual switch cannot connect to another virtual switch or to morethan one external physical switch. For that reason, physical switch portsconnected to virtual switch trunk ports should always be configured as statictrunk links and spanning tree protocols should be disabled. ü UseLayer 2 security configurations: Layer2 security policies provide enhanced network security for virtual networks byrestricting the ability of virtual adapters from entering promiscuous mode andExamining all switch traffic, placing frames with a forged MAC on the network,and changing of their own MAC address in order to intercept traffic destinedfor a different virtual machine.ü Restricted network access:network access for the host OS should be restricted to management servicesonly, and, if necessary, network access to storage (iSCSI).
ü Use a firewall: a firewallshould ideally be placed on the host OS to protect the system, or a firewallshould at least be local to a small number of systems for protection purposes,with accessü Consider usingintrospection capabilities (e.g., firewalls, security appliances, and networkü IDS/IPS sensors) to monitorthe security of the server and guest OSs. If the server or guest OS iscompromised, its security controls may be disabled or reconfigured so as tosuppress any signs of compromise. ü Static IP addresses: ensurethat host OS is assigned static and unique IP addresses.ü Separate managementnetwork: management of host OS should be on a separate network than that usedby guest OSs, using a separate NIC dedicated to management functions.
Management network should be dedicated to management of the virtualinfrastructure only, and not used for any other purpose – management of othersystems or other uses.ü Use encryptedcommunications: management of host OSs should only be done using encryptedcommunications, such as HTTPS, TLS, or SSH protocols, or encrypted virtualprivate networks (VPNs).ü Restricted access throughfirewall: the firewall should by default deny all access on the managementnetwork to all systems and all ports other than those explicitly needed forauthorized management of host systems, allowing only those services requiredand only with those authorized management IP addresses necessary. Test APIs ü APIs are exposed to external threats, check ifAPIs are public or private and filter.ü Inability to ensure all API’s are adhering tocommon security policiesü Lack of visibility into APIs, API usage andperformance of APIs connecting your apps must be verified and optimized.
ü API’s Built for distributed, Cloud environmentü PaaS Gateways have limited capabilities andcan track only APIs in that PaaS, we need to ensure to verify with moststandard PaaS gateway definitions. Test Database Server ü Use a dedicated database eg..SQL Server foreach testbed.ü Do not use the Configuration Manager sitedatabase server to run other SQL Server applicationsTest Web server, Securing IIS if used ü Disable IIS functions that you do not requireas part of the test.ü Use dedicated IIS servers for test manager. Fault tolerant test systems and database ü Deploy the fallback status point prior to testVM’s ü Avoid using the fallback status point in the perimeter network Final certified component mandates § GOS – Like above section.
§ VIB§ Web client plug-ins VIB level ü VIB signature verification. ü Check that the VIB does not have any filesthat have both the exec and sticky bit set. ü Check vibauthor version.ü Force install of VIB must not work.ü Discovery – The purpose of this stage isto identify systems within scope and the services in use. It is not intended todiscover vulnerabilities, but version detection may highlight deprecatedversions of software / firmware and thus indicate potential vulnerabilities.ü Vulnerability Scan – Following thediscovery stage this looks for known security issues by using automated toolsto match conditions with known vulnerabilities. ü Vulnerability Assessment – This usesdiscovery and vulnerability scanning to identify security.
ü Security Assessment -Verification couldbe in the form of authorized access to a system to confirm system settings andinvolve examining logs, system responses, error messages, codes, etc. ü Penetration Test – Penetration test simulates an attack by a malicious party. ü Security Audit – Driven by an Audit /Risk function to look at a specific control or compliance issue. ü Security Review – Verification thatindustry or internal security standards have been applied to system componentsor product that we distribute after certifying. Web client plug-ins ü User User Registration Securityü User Login Securityü Database Securityü File System Securityü Blacklist Functionalityü Firewall Functionalityü Brute force login attack preventionü Regular updates and additions of new securityfeatures Physically secure your server hosts ü This must be taken care by partners foron-prem environment.ü For off-prem partner must use secured cloudplatform.
vSphere host level mandates ü Ensure most recent security updates on allvSphere hosts.ü Protect against unauthorizedadministrators (remove default ones)ü Enforce role separation to limitadministrative exposure tying with DC account.ü Create and maintain secure baselines for allsystems. (May use secure boot or we can create custom images with certainguidelines)ü Strong passwords or pass phrases must be mademandatory.
ü Leverage default secure gold builds, thenclone other virtual systems from this base. Manage the virtual machine’sconfiguration lifecycle from cradle to grave with tools native to the virtualmachine, and use outside tools where required.ü Monitoring tools should bevirtual-machine-aware and able to detect and take action (alert/block/sandbox/move to remediation) on assets that deviate from the gold build.
ü They should work with the VMM to correlatechanges in VM and virtual network configuration, including on virtual systemsbehind virtual firewalled switches (which can’t be done without working withthe Hypervisor/VMM).ü Examine closely any virtualization platformcapabilities that enable communication between guest and host operatingsystems, such as device drivers, copy/paste functions, leaks in memory, and soon. Where possible, these should be identified and disabled. ü System monitoring tools and virtualization-awaremonitoring tools should be tuned to locate and monitor these communicationspaths. ü In addition, keep an eye on virtualizationvendor security advisories for new vulnerabilities and patches. Advantages ü Single pane of glass for auditing ü Easy upgradeof your security solutionü Streamlined drilling and analysisü Executive reporting out of the boxü Simplified incident managementü Easier, faster report analysisü Easy to define and control permissionsü Cross-sharing of security management practicesand information collected from different functions.ü Easier control over policy and taskimplementation.
ü Streamlined policy and task changes. Practical Implementation and Future Work ü Would need exec approval.ü More refinement with feedback. Conclusion ü Provides generic tool across cert. ü Provides base template tested for compliance with the newsecurity Standards, reducing the risk of threats.
ü Provides an architecture that has been through anindependent security review.ü Provides easy option for regular patching and softwareupdates, reducing the repeated effort. ü In future, we can easily do security components as aservice for cert.
ü Provides a single content management system across certslifecycle.ü May provide comprehensive legal contract, which can reduceslegal costs while distributing components to partners. .Acknowledgment I would like to thank David Kum for showing thedirections and guidance, providing suggestions on initial draft of the paper.
