(Yes to all)

Change management is documented with visibility by the customer and application sponsors via security ticketing system supplied by Omegabit for the purposes of approval workflow, audit, and historical record. Customer specific Wikis are also maintained to help document information that is proprietary to the Client implementation and that is important to all parties. 

Configuration management is documented with visibility by the customer and application sponsors via security ticketing system supplied by Omegabit for the purposes of approval workflow, audit, and historical record. Customer specific Wikis are also maintained to help document information that is proprietary to the Client implementation and that is important to all parties.

All relevant acquisitions undergo scrupulous review by senior security team members and, where relevant, senior management and are measured based on a number of risk criteria varying from cost impact, to security risk, liability, long-term sustainability, interoperability with other methods and systems, etc.

Yes. All relevant acquisitions undergo scrupulous review by senior security teams and Executive management, where relevant, and are vetted for impact relating to all facets of risk (modeled on DR and Risk Assessment considerations).

An aggressive off before on strategy is employed by default for all levels of access and configuration.

Yes, Semi-automated

Per customer application specification and configuration requirements establish in close collaboration with Client and application development team.

Yes

Patch management is documented with visibility by the customer and application sponsors via security ticketing system supplied by Omegabit for the purposes of approval workflow, audit, and historical record. Customer specific Wikis are also maintained to help document information that is proprietary to the Client implementation and that is important to all parties. Schedules and approvals are managed in direct coordination with Client teams to ensure changes are controlled and do not cause breakage. Actions are scheduled according to policies defined in the Omegabit SOW/SLA, except where explicitly overridden by special policy or Client requirement.

Yes, to the limits deemed appropriate by the customer.  Omegabit manages Liferay installations that vary from completely managed environments, to mixed managed environments where Omegabit assumes control of production but not development environment, to a more traditional turnkey approach.  In all cases, Omegabit will work with the Customer to ensure that best practices are followed, and is able to provide recommendations on methods and procedures that will help ensure the smooth rollout, operation and maintenance of the application and runtime environments.

Patches relating to security or access control will be prioritized over other non-critical tasks and expedited wherever possible.  Software patches requiring special personnel or procedures, an extended outage, or client-side testing and coordination will be applied at best possible speed, and typically take a minimum of 48 hours and up to 5 business days to coordinate and execute.  All outages are coordinated with Client, except where necessitated by emergency repair.

Infrastructure patching of our cloud occurs transparently and is typically no impact to you thanks to the redundant nature.  If impactful maintenance must occur, we provide a week or more notice in advance and will coordinate with you to ensure it occurs during a planned window and is clearly communicated (this is rare, and we understand the potential impact to your operations and will coordinate, accordingly).

For your hosted infrastructure, patch cycles are always coordinated with your team to avoid interruptions to production services and "surprises" with compatibility (both OS and Liferay/application layer).  We help remind of this schedule but it is ultimately up to your team to approve the updates and allow the opportunity for the work to occur.  ]]

We recommend a cycle of no longer than 3mos, except where there is a specific need (e.g. for urgent security fix or, function).  Generally speaking, OS same-release patches occur without incident, but may require a service restart.  For Liferay, your engineering team will typically need to integrate the patches with any custom builds and test extensively.  So we consider that part of the custom development/maintenance lifecycle.

For any patching or configuration changes, we do strongly recommend a prerelease strategy to prove out the change before it is promoted to production.

We are here to help support that lifecycle, and are able to help the engineering team identify potential conflicts with patches and fixpacks vs. custom code using the Liferay patching tools.

Infrastructure hardening is extensive, and occurs at many levels of the hardware/software/network stack. This is documented in the Omegabit Internal Operations Wiki, and Client Wikis, where applicable and is private to each specific Client. Details are typically summarized in a policy statement supplied by Omegabit. compliant tennant.

All layers of the infrastructure are continuously hardened against evolving threats (Firewalls, VMWare, Storage, etc.).  Firewalls are updated hourly against an live DB of known threats.  We can optionally enable zero-day quarantine and Data Loss Protection filtering (they have some performance tradeoffs but are available to you if desirable).  Your provisioned infrastructure operates in a private VLAN "bubble" that is completely locked down.  Only SSH and HTTP/S are exposed to the Internet by default and we can restrict access to any service at the firewall on request.  

The OS VM containers that are provided are also pre-hardened and patched to the latest OS release on delivery.  Only necessary services are installed/activated.  All passwords are set (strong), and admin access is limited where applicable (e.g., root can only connect to MySQL from localhost by default).  We do not run OS level firewall services by default, except where applicable for special configuration.  However, they can be enabled if desirable (we recommend not, for best performance and given the nature of the isolated infrastructure and the hardware firewalls in-front; the VLAN is trusted).  All servers also actively watch/respond to intrusions using fail2ban to watch all connected services for brute-force and DDOS attacks.  Strong passwords are enabled and configured by default.  We do expect your team to maintain their own passwords.  However, we can enable password change restrictions to the OS on request.  We typically defer to you to set the security in Liferay as you require, but can certainly advise on best practices and how to use the Liferay password controls.  Because manning the systems is a joint responsibility, and both teams have access, we are continuously looking for changes that may imply risk and will advise.  E.g., perms changes, or, if the dev team decides to install new services, etc.  Our expectation is that you keep us informed of changes that occur outside of our control, so that we don't step on the efforts and can advise on any potential impact (security, or otherwise).  If you would like a more formal and automated means of documenting this, we strongly recommend considering a subscription to Dynatrace SaaS, which provides audible recording of environment changes as well as a fantastic set of performance analysis tools for your custom application.  Let me know if this is of interest and we can discuss in more detail.