ref: Soc 2 Type II Facilities Compliance Report for Omegabit colocation' facilities managed by Digital West and alternate providers (available on request).

All omegabit facilities are audited by third-party compliance services for SOC-2 compliance are maintained to PCI compliance standards, by default. Omegabit hosted infrastructure is also frequently vetted and audited on a per-customer basis where specific compliance, e.g. PCI, FERPA, FEDRAMP, HIPAA, is required. These certifications must occur against the customer implementation and are typically performed in cooperation with the application sponsor and Client.

This technically falls under the auspice of control of our Client tenants with these requirements and their specific custom application design and implementation. However, we play a participating role in ensuring that issues relating to SOC 2/facilities compliance, data storage and transfer, managed operations and procedures, are performed in a manner that is commensurate with Client requirements. Actual secure data transmissions are accomplished via BOVPN, IPS, SSH, or HTTPS, LDAPS, or similarly secure means at the discretion of the customer and their custom application design. All popular means are supported and can be enabled and secured on request. Data storage encryption is also available on request.

This is performed on a per-client case-basis as required by Client in cooperation with the auditing service or agency of their choosing. Omegabit is able to self-certify and/or work with Client designated teams. Omegabit has established PCI, HIPAA, FERPA, and similar compliance with customers across various verticals and custom application designs. These assessments must be done on a per-Client case basis and be specific to the custom software implementation to be relevant. Compliance certifications, with the exception of Omegabit's SOC 2 facilities compliance, is not transferable across Client tenants, by definition.

The SOC-2 compliance audit is performed every 18-24 months.  

(assumes SSL site configuration)

Ref: Omegabit Employee Handbook, Guidelines and Operations Wiki procedures.

Yes.

Any secure communications are further tunneled and wrapped in either IPSec or SSH depending on the nature of connection. All wifi connections including LAN Wifi are hardened similarly as with public or unprotected network links.

Yes.

IPSec, SSL, SSH (256-bit)

Wireless Policy: This is documented in Part III, Section 6. Wireless Communication Standard, IT Security Handbook.

Physical items received into inventory are documented using conventional means including shipping log history and notations by Receiving. As it relates to facilities, equipment added to or removed from the racks is documented in the Omegabit Operations Wiki in a manner that is timestamped, auditable, and tracked for historical purposes.

Yes. Omegabit maintains an extensive operational wiki and profile/dossier of each Client infrastructure "stack" and all relevant configuration information. This same system provides detailed technical procedures based on regularly updated defaults, with added customer-specific annotations and adjustments, which helps to apply best practices out-of-the-box and also accommodate necessary changes required by the customer that are relevant and proprietary to their respective environments.

This is also a configurable feature of Liferay, which can be stipulated during the software configuration requirements phase of planning.

Yes

This is available as an advanced feature and requires additional software subscription to Omegabit Dynatrace environment monitoring and reporting suite.

Yes

● Base installation, configuration, and tuning 

● 24x7x365 monitoring and emergency response 

● Backups and disaster recovery management and execution 

● Comprehensive OS runtime container backups

● Disaster recovery and recovery rollback to point-in-time snapshots included

● Assistance with drop-in patches, upgrades and modifications to the runtime environments. 

● Regular OS patching and maintenance administration  

● Periodic log cleanups 

● Server restarts, time needed in the event of OS patches, incremental (minor release) upgrades including non Liferay automated-patching using OS auto-update facilities

● Server restarts in the event of unknown issues like unexplained high utilization, a typical behavior necessitating a restart 

● General Liferay support on feature behaviors and "out of the box" configuration settings 

● Troubleshooting and resolving runtime issues

Examples of work that will typically require additional labor outside the scope of the current Financial Summary include:

● Ongoing administrative support for sandboxing or custom configurations

● Advanced change management support

● Major release patching

● Environment customizations for proprietary operations and functionally

● Custom performance tuning and optimization, load testing, predictive analysis

● Developer logistics support

● Custom architecture and scale planning 

Omegabit's active firewalls are constantly thwarting typical (and sometimes, atypical) structured and automated attacks that are common to the Internet.  We keep up to date hourly against a database of published threats that are blocked before they ever reach the portal. That activity is logged and available for analysis by us for forensics and diagnostic purposes.  But, we typically do not report that information to the customer - that information is stored at our cloud and firewall infrastructure levels.  The exception being any logs that are on the servers themselves - customers do have direct access to (Apache, tomcat, db, etc.), and we do sometimes help provide tools like Splunk for analysis.  We also offer some exceptional monitoring and reporting options from Dynatrace, which the customer can use for deep visibility into application and runtime performance using a very rich and intuitive Web based interface and is capable of generating automated reports.   

Generally speaking, these threats are usually bots, they are numerous, and we have advanced dynamic protections in place at several levels to block theses sorts of exploits (most of which are further limited by Liferay security, anyway).  These can occur on the order of many-thousands-per-day and and are typically innocuous.  We do monitor for and react to pattern change as one indicator of potential vulnerability testing by external threat parties.  We are also able to provide advanced threat scanning and analysis for a given customer implementation.  We can accommodate specific logging and auditing requirements on a needs basis, as well as advanced features like Data Loss Protection, and Zero Day threat detection and quarantines, if desirable; these features have some practical disadvantages for typical consumer-facing apps.  But, we can enable them on demand.  

For in-Liferay workflow, which is arguably where the most risk might lie, we encourage implementing Liferay auditing, and also keeping current with fixes and patches.  We can host a central log server for a given infrastructure if the customer so desires.  And are able to assist with and accommodate those features.

Because of our Liferay optimized configurations and setup, our strong security and controls, and our experience operating Liferay's of all shapes and sizes, we are more well-equipped to maintain a secure Liferay environment and respond to threats in a way that is substantive, as compared to <any> other hosting option.  Notification is critical, but, we also take ownership of the problem:  the customer's security is our security.

Typically, what we offer OOTB is more than sufficient, except where special reporting or auditing requirements exists.  And, we are happy to understand and accommodate those requirements on a needs basis.  These are details we would typically work out during the discovery and budgeting phase of the engagement.

<more on logging facilities available>

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

Yes

Yes

Yes

Yes

Classification and handling varies by Client requirements. However, as it relates to the transmission of PII or other sensitive data, strong, modern cipher-based encryption is employed, and only using methods and under circumstances explicitly authorized by the Client. All physical media is labeled (except where intentionally obfuscated), serialized, and traceable. Electronic transmission is preferred.

Only when requested and approved by the Client and confirmed to be commensurate with operating restrictions and audit controls stipulated by the Client for specifically authorized individuals.

N/A; per Client requirements is supported.

ref: Omegabit IT Security document TOC, Part 1, Section 5 and 6

Yes, per NIST 800-88 r1 standards using certified commercial providers and documentation.

Yes. All mobile communications take place via secure channels and sensitive information is stored in encrypted format. Most sensitive information is intentionally centralized on secure servers. All mobile device data is encrypted. Devices are wiped or physically destroyed before retirement or change of ownership using industry-approved sanitization methods. Mobile devices with access to sensitive information can be remotely wiped.

Yes, Omegabit follows strict policies concerning the introduction of unauthorized hardware, and also operates using encryption and remote access standards and controls that pre-assume that every human-accessible node not protected by secure facilities controls (e.g., regular office and admin workstations), are at risk to all network entities, and are hardened by default as if operating on an uncontrolled public network; meaning, not even internal LAN network communications are considered "trusted" except under the cloak of encrypted channels, systemically. The exception is with cloud infrastructure that is intentionally configured for clear-channel communications between localized and otherwise hardened and protected nodes via dedicated isolated linkages, for performance (e.g. VMWare control and HA communications).