Our Partners close more business.
Use these powerful resources to win more business, faster, with less effort.
Call 877-411-2220 x121 for personal support with any opportunity.
RESET SEARCH
Hosting Quote Estimator
GET a FREE Sandbox or Trial Environment NOW
How To Use This Tool:
To find answers to common RFP and RFI questions, select a tag, or, search for terms like "security", "performance", etc. You will find common questions and answers grouped together in one record. Follow the tag links to refine your search. Supporting downloads and documentation are available, below.
Please login to obtain download access to additional supporting documentation. Registered users can also contribute to the database. You can request access by Contacting Us.
Supporting Documents
Please note that assets with generic thumbnail require login for access. If you require access please Contact Us.
© Omegabit LLC, 2023
Enter a Search Phrase or Select a Tag
Content with tag incident response .
Disaster Recovery
Q:
Is there a plan for Incident Response?
Do you have a Disaster Recovery Document?
Do you have policy and procedures which document your business continuity (BC) and disaster recovery (DR)?
Do you have BC/DR plans that assure the continuity of service and products provided to meet client's RTO and/or RPO?
Are roles and responsibilities documented in the contingency plans?
Do you conduct business impact analysis at least annually?
Do you provide contingency training to your staffs according to assigned roles and responsibilities at least annually?
Have you conducted BC/DR tests/exercises on this system with all appropriate parties in the last 12 months and revise the plans to address changes and problems encountered during implementation and testing?
Is the system included in your organization's business continuity and disaster recovery (BC/DR) plan?
In terms of crash and DR Omegabit offers multiple redundant layers of protection including but not limited to:
In terms of crash and DR recovery Omegabit offers multiple redundant layers of protection including but not limited to:
What type of business continuity and disaster recovery options are included as part of this solution? Is this part of the standard services?
How are the backup data stored?
A:
This is documented in Omegabit Internal Operations Wiki.
This is documented in Omegabit Disaster Recovery Handbook, Section 1.1 to 1.4 and Section 2.3
ref: Omegabit Disaster Recovery Plan TOC
Yes. Per agreed upon SLA.
Yes. ref: Omegabit Disaster Recovery Plan TOC
Yes. ref: Omegabit Disaster Recovery Plan TOC
Yes. ref: Omegabit Disaster Recovery Plan TOC, Omegabit Operations Portal, and Training curriculums
Yes. The DR plan was recently exercised and updated in Q2 of 2017. A certified statement can be provided by executive management certifying this, provided the vetting proceeds to the next round.
ref: Omegabit Disaster Recovery Plan TOC
● Logical and physical redundancy at the VMWare, JVM, repository and other critical layers of the runtime environment stack
● Warm-spare redundant Liferay architecture (proposed)
● Server failover capability
● Rapid nearline backup recovery
● Comprehensive off site DR for catastrophic failure
In the event that a high-availability portal configuration is required, redundant nodes of the HA configuration will be purposefully isolated to discrete server and backend infrastructure as a complement to that logical HA configuration, to the benefit of higher reliability and faster recovery under various logical/physical architecture failure scenarios.
Omegabit operates comprehensive SNMP and service level monitoring of all configured hosts and services. Triggers are adjustable and set by default to detect failures as well as symptoms of imminent failure. Monitor alerts are responded to by live personnel, 24x7x365, and acted upon according to severity, per the terms of our SLA.
The core physical host infrastructure is inherently HA in terms of disk arrays, storage and network paths, physical servers, switching, etc. Omegabit operates a modern VMWare based infrastructure. In the case of most physical failures services are designed to continue transparently with no observable interruption to operations. In the case of logical failures, the VM, JVM, and Liferay backend service configuration is proposed as an HA setup, to practical limits. If a higher level of resilience is required than is proposed, we are able to accommodate that as additional scope. Disaster Recovery (DR) is an inherent component of the regular day-to-day operations performed by Omegabit, as a core function of the hosting operations is supplied for all tenants.
Omegabit offers multiple redundant layers of protection including but not limited to:
● Logical and physical redundancy at the VMWare, JVM, repository and other critical layers of the runtime environment stack
● Warm-spare redundant Liferay architecture (proposed)
● Server failover capability
● Rapid nearline backup recovery
● Comprehensive off-site DR for catastrophic failure
Backups snapshots of the entire VM stack are performed every 2hrs, and the offsite archives of those backups are continuous to a second physical location. Retention for 2hr snaps for 48hrs, dailys for 30 days, and weeklys for 16 weeks. We can accommodate longer retention if necessary. Some of these retention policies impact RPO.
For PCI, you may want logs to last up to 1yr but, that can be accomplished through application design or by depending on our backups. We recommend using both strategies depending on your reporting needs.
Backups should be considered for disaster recovery purposes only. Our retention policy is variable and based upon data volume. Depending upon the environment, rollbacks to the previous day, several days, weeks are available, but with sporadic snapshots between periods. Therefore, a specific point-in-time recovery may not be possible. We are typically able to restore backward up to several weeks depending upon the total size of your store.
Omegabit can provide additional backup and archival services to meet specific requirements on a needs basis. Please contact your sales representative for more information.
Omegabit features a comprehensive alternate-site DR recovery plan that includes regular off-site archives using Omegabit owned and managed equipment. Backup to the public cloud (e.g. Amazon), is optional but requires special arrangement and may not be compatible with some PII/HIPAA requirements. Specific features for disaster recovery vary by tier of service; please see the SOW for complete details on RTO/RPO times and obligations.
Event and Incidence Response
Q:
Is there a plan for Incident Response?
Do you employ an automated mechanism to integrate audit review, analysis, and reporting process to support incident response, continuous monitoring, contingency planning, and audit?
A:
This is documented in Omegabit Disaster Recovery Handbook, Section 1.1 to 1.4 and Section 2.3 ref: Omegabit Disaster Recovery Plan TOC
We consider any intrusion to be a "Severity I" class event. Which, per our SLA requires a response time of <2hrs. In reality, our 24x7 operations staff will respond to any Severity I event the instant it is detected. I've attached boiler-plate/generic copy of our SLA and am happy to produce a named/completed version for a given stack if of benefit (this one calls out "sticker" and a la carte pricing and is OK to share as-is).
In the event of any detected incident, including known breach or ongoing security intrusion, performance degradation, major change in performance profile, etc., notice is provided to the customer as soon as practical. Typically, within minutes provided we are not actively triaging and providing emergency responding to the issue. We consider the ownership of security related issues to be a joint-responsibility along with the application sponsor. Because, in many cases the risk may be specific to the customer's implementation of the portal, and we must be in communication with the owner to permanently resolve the issue if not to triage and block it, temporarily. A 24hr point of contact with the customer is preferred for emergency incident notification, which can include email and telephone contact depending on severity and customer preference.
Yes, for specific audit log event analysis we use a combination of tools including but not limited to Splunk and Dynatrace SaaS; additional software subscription and fees apply for a dedicated implementation of reporting facilities for Client use and self-reporting.
Security Incident Handling
Q:
Do you have documented incident response policy and procedures?
Are personnel defined with roles and responsibilities in incident response plan and trained at least annually?
Do you have an automated mechanism to increase the availability of incident response-related information and support?
Do you conduct incident response tests/exercises with all appropriate parties at least annually and revise the plans to address changes and problems encountered?
Do your incident response tests include other related plans (e.g. BC or DR Plans, Crisis Communication Plans, Critical Infrastructure Plans and etc.)?
Do your incident response tests include other related plans (e.g. BC or DR Plans, Crisis Communication Plans, Critical Infrastructure Plans and etc.)?
Do you employ automated mechanisms to support incident handling processes that include preparation detection, analysis, containment, eradication, and recovery?
Are incident handling processes incorporated into contingency planning activities?
Do you incorporate lessons learned from ongoing incident handling activities into incident response procedures, training, and testing/exercises, and implement the resulting changes accordingly?
A:
ref: Omegabit IT Security TOC
Yes
This question is vague; however, we do provide means of escalation and the dissemination of information with backup strategies in case of critical failure.
Yes
Yes
Yes
Yes
Yes
Security Incident - reporting and notification
Q:
Do you track, analyze and report on all security incidents?
Yes; varies by method of detection but, is typically automated by email and status dashboard notification. Severe or high-risk conditions engage a human chain of response protocol. Critical systems are monitored redundancy by multiple means and pathways. Escalations are programmed to trigger alerts via alternate channels if not acknowledged. These methods and alerts are similar regardless of trigger source (typical instability or application issue vs. targeted security incident or malicous attack); any source of instabilty or threat is responded to with high priority. Depending on incident type and level of escalation, it may be flagged for investigation and a trouble ticket opened for further investigation. Any incident of substance is documented with visibilty by the Client; proactive notifications are sent for incidents of immediate concern or requiring action or where a breach has occured.
A:
Omegabit maintains a comprehensive and proprietary database for the purposes of troubleshooting and documenting known incidents and actions, which is utilized to inform resolution path options and document outcomes for all parties.
As it relates to customer communications, Omegabit notifies Client designated contacts of urgent incidences by email, and telephone wherever practical, as well as a shared ticketing system to track the incident response.
Severe or high-risk conditions trigger a human-managed chain of response protocol. Critical systems are monitored automatically by multiple. Escalations are programmed to trigger alerts via alternate channels if not acknowledged. Depending on incident type and level of escalation, it may be flagged for more investigation and a trouble ticket opened for further analysis. Any incident of substance is documented with visibility by the Client; proactive notifications are sent for incidents of immediate concern or requiring action or where a breach has occurred.
Notification follows the SLA terms and conventional practice.
Please refer to the Omegabit IT Security TOC for more information.