Database, search and other ancillary services operating within the Client private infrastructure are exclusive to the use of the Client and are not shared with any other user, Client, or application except where explicitly intended by the Client application design. All databse services access is restricted by firewall, connecting client IP, unique users id, view restrictions, and strong passwords. Omegabit will implement the most secure (off before on) style of access control by default, and coordinate with the Client to make informed, security-aware changes where required for the operation of the hosted application.

Access of this nature is always chaperoned.

All administration links require two-token VPN linked authentication (pass+comlex trust key), or SSH tunnel, plus single factor authentication for console access, and additional secondary authentication for privileged access, by default. All restrictions and controls are configurable per Client requirements. Strong (15-char, complex), and unique passwords are employed, always. Optional Google two-token public authentication, digital certificates and personal keys are also supported on request. Hardware based two-token authentigtation integration for Client systems is also supported as a customization.

Omegabit facilities and operations are SOC-2 certified in direct cooperation with its facilities partner, Digital West Networks, Inc.  A copy of the primary facilities SOC-2 certification is included with this submission and supplemental references for secondary operations are available on request.  Omegabit also features secondary Disaster Recovery and Point of Presence operations at facilities managed in partnership with Digital West and industry leading suppliers Equinix, and CoreSite featuring the most modern and compliant plant and core operations available in support of application specific certifications.  Omegabit directly owns and controls all infrastructure extending from the Internet drops: servers, firewalls, edge switching, storage, etc., and relies on its partner facilities for high-availability cooling, power, and physical plant security as well as emergency hands-on operations.

Omegabit follows extensive security protocols following best practices for PCI, FERPA, FEDRAMP and similar compliance modeled on industry standards and best practices. This includes emphasis on traditional IT and host infrastructure security for Internet providers, as well as specialized training relating to custom application designs and the implementation of Liferay, specifically. Many practices are modeled after requirements established from its broad base of customers operating sensitive applications for finance, healthcare, government, education and similar purposes. Omegabit is able to support most any compliance requirement and typically will establish operational policies that are considerate of best practices and the specific requirements of the Customer.

A Table of Contents (TOC), outlining procedural content has been provided for reference; full content is obfuscated due to its proprietary and sensitive nature. The following outlines are provided: "Omegabit Disaster Recovery PlanTOC", "Omegabit IT Security TOC", and the "Omegabit Employee HandbookTOC". Collectively, these documents cover many of the issues identified in this list. Other items are covered by our Operational Wikis. A supplemental document titled "Omegabit Information Security Questionnaire" is also included, which addresses the most common questions concerning overall security practices, capabilities, and options.  Omegabit is also able to maintain a custom policy and procedures for customers with special needs, e.g. PCI or similar compliance. A sample policy statement titled "Omegabit Operations Policy Guidelines and Recommendations - Redacted Generic" has been provided of an example maintained with a PCI compliant tennant.

This is inherent to our regular mode of operations and procedures; see previous answers concerning change management and control, documentation and procedure; the same answers apply. ref: Omegabit Operations Wiki

Yes

Yes

Yes

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.