§ service we would have to think of more

§  GOS

§  VIB

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

§  Web client plug-ins

 

Physically secure your server hosts.

§  This must be taken care by partners
for on-prem environment.

§  For off-prem partner must use secured
cloud platform.

Signing infrastructure.

§  As far as it’s inside the firewall,
it’s secured.

§  If in future we decide to host it
outside as a service we would have to think of more secured way (TBD)

 

Development kit mandates

 

§ 
Securing the WB platform

o  
Installation mandates for
platform.

o  
Operating system partition
mandates.

o  
Administration and
management

o  
Logging and auditing with network
security.

 

Installation mandates for platform.

 

ü 
Physical
access limits: Authorize only administrative
personnel to access the physical host system to prevent unauthorized changes.

ü 
Integrity
of the files must be verified prior to installation:
verify the checksum of system files, as provided by the cert team.

ü 
Install
and load only selected operating system components and services:
no unnecessary systems components and no unnecessary services should be enabled.

ü 
Passwords
protection: Parameterized passwords should be used for BIOS and boot
loaders 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 VM
so that no one VM can monopolize
resources on a system.

ü 
Ensure time synchronization

ü 
Minimize number of accounts

ü 
Use of strong
authentication

ü 
Unnecessary programs and
services

ü 
Configuration management

ü 
Patch management

ü 
Hardening guide

ü 
Administrator or root login

ü 
Partitioning and resource
allocation

ü 
Space restrictions

ü 
Disconnect unused physical
devices

 

Administration and management mandates

 

ü 
Strong authentication
should be used for host system access: two-factor authentication is recommended
for access to host system.

ü 
Do not enable file sharing
between host and guest OSs: while it might be convenient to enable the sharing
of system files between the host and guest OSs, allowing such introduces an
unacceptable risk of a guest OS possibly maliciously changing a host OS file.

ü 
Warning banners: warning
banners should be used for both hosts and guests. Warning banners are required
to successfully prosecute unauthorized users who improperly use a computer.
Banners should be displayed on all systems prior to access and warn users
about:

o  
What is considered the
proper use of the system;

o  
That the system is being
monitored to detect improper use and other illicit activity, and;

o  
That there is no
expectation of privacy while using this system.

ü 
Separation of duties

ü 
Management of hypervisors

ü 
Regularly make back-ups

ü 
Ensure that appropriate
access control lists (ACLs) restrict copying or mounting images to authorized
support personnel. If necessary, encrypt disk directories or partitions, as
well as the back-up media itself.

ü 
Use separate back-up
account

ü 
Follow disaster recovery
(DR) procedures for virtual environment

ü 
Prevent “VM sprawl”: there
is a tendency within organizations to allow the creation of more VMs than is
necessary, for various reasons. This tendency can create a serious problem with
the effective management of VMs. Require appropriate permission before VMs can
be created, and before they can be deployed.

ü 
Creation and deployment of
VMs should both be logged.

ü 
Control VM migration:
effective management of VMs also requires controls around, and proper authorizations
for the migration of VMs.

ü 
Migration of VMs should be
logged (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 from
test VMs

 

 

Logging and auditing mandates

 

ü 
Use centralized logging: centralize
logging of guest OSs, either on a separate logging system or in a repository.
Use of centralized logging aids administrators, security personnel, and
auditors in verifying configurations and practices in a virtualized environment.

ü 
Correlate logs: correlate
server and network logs across virtual and physical infrastructures to reveal
security vulnerabilities and risk.

ü 
Regularly audit virtualized
environments: it is important to audit configurations of all components of a
virtualized environment, management capabilities, virtual switches, virtual and
physical firewalls, and other security devices (e.g., intrusion detection
systems, anti-malware capabilities). Ensuring compliance with established
configuration management practices is particularly important.

ü 
Root and administrative
privileges: log and audit monthly root and administrative access and actions on
all systems in a virtualized infrastructure.

ü 
Invalid logical access
attempts: log and audit weekly all invalid logical access attempts on all systems
in a virtualized infrastructure.

ü 
Access to all audit trails:
log and audit monthly all access to audit trails on all systems in and supporting
a virtualized infrastructure (e.g., a centralized log repository).

ü 
Initialization of audit
logs: log and audit monthly initialization of all audit logs on all systems in and
supporting a virtualized infrastructure (e.g., a centralized log repository).

ü 
Creation and deployment of
VMs: log and audit monthly the creation and deployment of all VMs in a
virtualized environment.

ü 
Migration of VMs: log and
audit monthly the migration (e.g., source and target systems, time, and
authorization) of all VMs in a virtualized environment.

ü 
Creation and deletion of
system-level objects: log and audit quarterly the creation and deletion of all
system-level objects in a virtualized infrastructure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Certification kit mandates

 

§ 
Securing certification
workload tools

o  
Guest operating system
hardening

o  
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 system
hardening

Minimize
number of accounts: guests should have accounts necessary for running each VM
only with passwords that are strong, hard to guess, changed frequently, and
only provided to staff that must have access. Separate credentials should be
used for access to each guest OS; credentials should not shared across guest
OSs, and should not be the same as used for access to the host OS.

ü 
Unnecessary programs and
services: all unnecessary programs should be uninstalled, and all unnecessary
services should be disabled.

ü 
Configuration management:
configuration management of guest OSs should be centralized to ensure that
configurations are standardized. It is likely that multiple configurations will
be required to meet business needs.

ü 
Patch management: guest OSs
must be patched regularly and in a timely fashion to protect VMs. However,
timeliness includes procedures for testing patches on non-production systems
first to ensure that access to VMs is not disrupted.

ü 
Hardening guide: guest OSs
should be hardened following an organization’s approved hardening or build
standard.

ü 
Ensure most recent security updates on all
vSphere hosts.

ü 
Protect against unauthorized
administrators (remove default ones)

ü 
Enforce role separation to limit
administrative exposure tying with DC account.

ü 
Create and maintain secure baselines for all
systems. (May use secure boot or we can create custom images with certain
guidelines)

ü 
Strong passwords or pass phrases must be made
mandatory.

ü 
Isolate sites in high security environments.

ü 
Integrity

ü 
Accountability

ü 
FQDNs for all site systems and
senders  

ü 
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, if

necessary,
may have network access to storage (iSCSI).

ü 
Firewall: the guest OS
should be protected by a firewall running on the host OS, or at least running
locally (i.e., local to a small number of systems for protection purposes).
Firewall needs to discriminate against inappropriate and/or malicious traffic
using networking communications effective for the environment (e.g., if
bridging is used instead of routing).

 

ü 
Separate VLANs for guest
OSs: 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 of
separate VLAN IDs may require defining port groups for systems on the specific
VLAN and allowing administrators to define different settings concerning
network access and security policy for virtual machines connected to a single
virtual switch. As many port groups as necessary may be created for a single
virtual switch. Virtual network adapters associated with virtual machines may
then be configured to connect to these user-defined port groups. The virtual
adapters connected using a user defined port group inherit and abide by the
policies defined within the port group.

Network Configuration mandates

 

ü 
Session Management

ü 
Transport Security

ü 
Tiered system segregation at different level

ü 
Virtual
devices: ensure that virtual devices for guest OSs are associated
with the appropriate physical devices on the host system, such as the mapping
between virtual network interface cards (NICs) to the proper physical NICs.

ü 
Use
of virtual trunk ports: physical switch ports
connected to virtual trunk ports should always be configured as static trunk
links. A virtual switch cannot connect to another virtual switch or to more
than one external physical switch. For that reason, physical switch ports
connected to virtual switch trunk ports should always be configured as static
trunk links and spanning tree protocols should be disabled.

ü 
Use
Layer 2 security configurations: Layer
2 security policies provide enhanced network security for virtual networks by
restricting the ability of virtual adapters from entering promiscuous mode and
Examining all switch traffic, placing frames with a forged MAC on the network,
and changing of their own MAC address in order to intercept traffic destined
for a different virtual machine.

ü 
Restricted network access:
network access for the host OS should be restricted to management services
only, and, if necessary, network access to storage (iSCSI).

ü 
Use a firewall: a firewall
should ideally be placed on the host OS to protect the system, or a firewall
should at least be local to a small number of systems for protection purposes,
with access

ü 
Consider using
introspection capabilities (e.g., firewalls, security appliances, and network

ü 
IDS/IPS sensors) to monitor
the security of the server and guest OSs. If the server or guest OS is
compromised, its security controls may be disabled or reconfigured so as to
suppress any signs of compromise.

ü 
Static IP addresses: ensure
that host OS is assigned static and unique IP addresses.

ü 
Separate management
network: management of host OS should be on a separate network than that used
by guest OSs, using a separate NIC dedicated to management functions.
Management network should be dedicated to management of the virtual
infrastructure only, and not used for any other purpose – management of other
systems or other uses.

ü 
Use encrypted
communications: management of host OSs should only be done using encrypted
communications, such as HTTPS, TLS, or SSH protocols, or encrypted virtual
private networks (VPNs).

ü 
Restricted access through
firewall: the firewall should by default deny all access on the management
network to all systems and all ports other than those explicitly needed for
authorized management of host systems, allowing only those services required
and only with those authorized management IP addresses necessary.

 

Test APIs

 

ü 
APIs are exposed to external threats, check if
APIs are public or private and filter.

ü 
Inability to ensure all API’s are adhering to
common security policies

ü 
Lack of visibility into APIs, API usage and
performance of APIs connecting your apps must be verified and optimized.

ü 
API’s Built for distributed, Cloud environment

ü 
PaaS Gateways have limited capabilities and
can track only APIs in that PaaS, we need to ensure to verify with most
standard PaaS gateway definitions.

 

 

 

 

Test Database Server

 

ü 
Use a dedicated database eg..SQL Server for
each testbed.

ü 
Do not use the Configuration Manager site
database server to run other SQL Server applications

Test Web server, Securing IIS if used

 

ü 
Disable IIS functions that you do not require
as part of the test.

ü 
Use dedicated IIS servers for test manager.

 

Fault tolerant test systems and database

 

ü 
Deploy the fallback status point prior to test
VM’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 files
that have both the exec and sticky bit set.

ü 
Check vibauthor version.

ü 
Force install of VIB must not work.

ü 
Discovery – The purpose of this stage is
to identify systems within scope and the services in use. It is not intended to
discover vulnerabilities, but version detection may highlight deprecated
versions of software / firmware and thus indicate potential vulnerabilities.

ü 
Vulnerability Scan – Following the
discovery stage this looks for known security issues by using automated tools
to match conditions with known vulnerabilities.

ü 
Vulnerability Assessment – This uses
discovery and vulnerability scanning to identify security.

ü 
Security Assessment -Verification could
be in the form of authorized access to a system to confirm system settings and
involve 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 that
industry or internal security standards have been applied to system components
or 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 security
features

 

Physically secure your server hosts

 

ü 
This must be taken care by partners for
on-prem environment.

ü 
For off-prem partner must use secured cloud
platform.

 

vSphere host level mandates

 

ü 
Ensure most recent security updates on all
vSphere hosts.

ü 
Protect against unauthorized
administrators (remove default ones)

ü 
Enforce role separation to limit
administrative exposure tying with DC account.

ü 
Create and maintain secure baselines for all
systems. (May use secure boot or we can create custom images with certain
guidelines)

ü 
Strong passwords or pass phrases must be made
mandatory.

ü 
Leverage default secure gold builds, then
clone other virtual systems from this base. Manage the virtual machine’s
configuration lifecycle from cradle to grave with tools native to the virtual
machine, and use outside tools where required.

ü 
Monitoring tools should be
virtual-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 correlate
changes in VM and virtual network configuration, including on virtual systems
behind virtual firewalled switches (which can’t be done without working with
the Hypervisor/VMM).

ü 
Examine closely any virtualization platform
capabilities that enable communication between guest and host operating
systems, such as device drivers, copy/paste functions, leaks in memory, and so
on. Where possible, these should be identified and disabled.

ü 
System monitoring tools and virtualization-aware
monitoring tools should be tuned to locate and monitor these communications
paths.

ü 
In addition, keep an eye on virtualization
vendor security advisories for new vulnerabilities and patches.

 

Advantages

 

ü 
Single pane of glass for auditing

ü 
 Easy upgrade
of 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 practices
and information collected from different functions.

ü 
Easier control over policy and task
implementation.

ü 
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 new
security Standards, reducing the risk of threats.

ü 
Provides an architecture that has been through an
independent security review.

ü 
Provides easy option for regular patching and software
updates, reducing the repeated effort. 

ü 
In future, we can easily do security components as a
service for cert.

ü 
Provides a single content management system across certs
lifecycle.

ü 
May provide comprehensive legal contract, which can reduces
legal costs while distributing components to partners. .

Acknowledgment

 

I would like to thank David Kum for showing the
directions and guidance, providing suggestions on initial draft of the paper.