Skip to Content

Turn your connections into holiday cash with our new Customer Referral Program! Learn more

Physical security of Jitterbit Harmony

Introduction

Jitterbit has strategically selected AWS and Azure as the cloud hosting providers for its Harmony platform. These industry-leading cloud platforms offer a robust infrastructure that not only supports the scalability and availability demands of Harmony but also fulfills a significant portion of its stringent security requirements.

By leveraging the capabilities of AWS and Azure, Jitterbit ensures that Harmony can dynamically scale its resources to accommodate varying workloads, ensuring consistent and reliable access to its services for users. Furthermore, these cloud environments have built-in security features and protocols that align with Harmony's security needs, providing a solid foundation for protecting sensitive data and transactions.

Infrastructure compliance

The design, management, and third-party audits of our IT infrastructure align with security best practices and various IT security standards.

See AWS Best Practices for Security, Identity & Compliance and Azure Security for a description of core security services.

Harmony practices comply with a wide range of industry-specific regulations and standards, including:

Physical and environmental security

There are parts of the Harmony platform that are deployed across AWS-managed data centers and Azure-managed data centers. Here are the security documents for both:

Business continuity management

The Harmony platform leverages cloud infrastructure to provide high availability. Its providers have designed systems to minimize the impact of system or hardware failures. Business continuity is a shared responsibility, so we've built extra redundancy into an already redundant service.

High availability and fault tolerance

Cloud data centers are built in clusters in various global regions. In case of failure, built-in processes reroute customer data traffic away from the affected area to avoid downtime affecting your data. Core applications are deployed in an N+1 configuration, so if a data center failure occurs, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites.

The majority of the Harmony platform is deployed across three independent and geographically-distinct clouds (each with a primary and secondary region): NA East and NA West; EMEA East and EMEA West; APAC East and APAC West, with three data centers (availability zones) in each region.

The Harmony EDI runtime engine is deployed in two independent clouds: NA East and Europe North.

Each availability zone is designed as an independent failure zone. This means that availability zones are physically separated within a typical metropolitan region and are located in lower risk floodplains; specific flood zone categorization varies by region. In addition to discrete UPS and onsite back-up generation facilities, they are each fed via different grids from independent utilities to further reduce single points of failure. Availability zones are all redundantly connected to multiple Tier-1 transit providers.

This provides high levels of resiliency for Harmony, as it can tolerate most failure modes, including natural disasters or system failures without shutdown.

Access to data centers and information is restricted to employees and contractors with a legitimate business need. Privileges are immediately revoked when an employee's business need no longer exists. All physical access to data centers by employees is logged and audited regularly.

Incident response

Jitterbit's Operations and Customer Support teams work to identify any issues that may impact Harmony users. They monitor Harmony's API usage, databases, services, messaging infrastructure, and Jitterbit cloud agent groups. The Jitterbit Support and Operations teams provide global coverage to detect any critical issues and manage the impact and resolution of those incidents.

Harmony's infrastructure is supported by the respective cloud hosting provider's Incident Management team, which employs industry-standard diagnostic procedures to drive resolution during business-impacting events. Staff operators provide 24/7/365 coverage to detect incidents and to manage the impact and resolution.

Communication

Jitterbit implements various methods of internal communication at a global level to coordinate all critical communication across Jitterbit's Operations, Customer Support, Engineering, QA, and Service teams. These teams have a presence across the Americas, Asia, Australia, Africa, and Europe. Our employees understand their individual roles and responsibilities and know when to communicate significant events in a timely manner.

Jitterbit has standard daily meetings among the various teams, which include team managers and company officers, to highlight any known issues and ensure that there are no bottlenecks within the organization preventing fast resolution.

Network security

Harmony resides within the cloud hosting provider's networks, which has been architected to provide the level of security and resiliency required for Harmony to support high trust and service levels.

Harmony is geographically dispersed, with a fault-tolerant architecture supported in all core services. Harmony relies on the cloud provider's world-class network infrastructure that is carefully monitored and managed. This includes:

Secure network architecture

Network devices, including firewall and other boundary devices, are in place to monitor and control communications at the external boundary of the network and at key internal boundaries within the network. These boundary devices employ rule sets, access control lists (ACL), and configurations to enforce the flow of information to specific information system services.

Specifically, they provide the following services to Jitterbit and Harmony:

  • Secure architecture
    Harmony infrastructure components run in separate virtual private networks. Each stack is an isolated network. Most services run in a private subnet. Only TLS endpoints terminated on load balancer are exposed to the Internet. Authorized operations personnel connect through the VPN to a bastion host, which restricts access to stack components and logs activity for security review.

  • Firewalls
    All stack hosts run mandatory inbound firewalls configured in deny-all mode. HTTP, HTTPS, and SSH ports are opened only as necessary.

  • Distributed Denial of Service (DDoS) protection and mitigation

    • Harmony's Virtual Private Cluster (VPC)-based approach means that no backend infrastructure is directly accessible from the Internet. As such, Harmony components cannot be targeted directly for a DDoS attack. Cloud hosting perimeter controls are in place (and tested) and are designed to prevent and detect DDoS attacks. Response teams and supporting processes are in place.
    • Harmony TLS endpoints include a load balancer, which only supports valid TCP requests, meaning DDoS attacks such as UDP and SYN floods do not reach the Harmony application layer.
    • We acknowledge that no control set is perfect. Should Jitterbit need extra capacity to deal with a potential DDoS attack, we can scale our technology stack.
  • Port scanning
    Tools and teams monitor and block unauthorized port scanning. Because Harmony's cloud infrastructure is private and all hosts are protected by robust firewalls, port scanning is generally ineffective.

  • Spoofing and sniffing
    Cloud hosting providers configure their networks and hosts to prohibit sending traffic with a source IP or MAC address other than its own. The hypervisor is configured to disallow the delivery of any traffic to a host the traffic is not addressed to. This means that any host trying to run in promiscuous mode will not be able to sniff traffic intended for other hosts.

  • Man-in-the-Middle (MITM) attacks
    All Harmony platform APIs are available via TLS protected endpoints, which provide server authentication.

  • Intrusion detection and prevention
    Cloud hosting providers offer security services that provide limited IPS and IDS controls for all hosted environments. Jitterbit has deployed its own IPS tool to prevent and detect anomalous and malicious activity.

  • Network and host vulnerability scanning
    Cloud hosting providers scan their Internet-facing physical network and Jitterbit scans Harmony's private network systems regularly. Cloud providers and Jitterbit are jointly responsible for host security. Jitterbit is responsible for remediating adverse findings without customer intervention or downtime.

  • Penetration testing
    Jitterbit annually engages a third-party security firm to do a penetration test of the Harmony infrastructure. Any penetration test findings are remediated immediately.

  • Secure Harmony hosts
    Cloud providers provide Jitterbit with secure hardware (server/hosts) and operating systems. AWS uses the Center for Internet Security (CIS) Configuration Benchmark for the operating systems and versions.

Host hardening

For all operating systems:

  • Automated configuration management tools install bare operating systems from "gold" images.
  • Password logins for hosts are disabled. SSH root keys are not permitted.
  • No unauthorized user SSH keys are permitted on hosts by default. Jitterbit internal workforce user access is configured only on a per-user basis, and only when necessary to provide developer or customer support.
  • Non-default SSH ports are used.
  • Host security updates are automated.
  • All host ports are opened only via allowlist.

Transmission protection

The only external communication possible with Harmony is via HTTPS using Transport Layer Security (TLS), a cryptographic protocol designed to protect against eavesdropping, tampering, and message forgery.

Network monitoring and protection

Harmony leverages the cloud provider's utilization of a wide variety of automated monitoring systems to provide a high level of service performance and availability. Their monitoring tools are designed to detect unusual or unauthorized activities and conditions at ingress and egress communication points. These tools monitor server and network usage, port scanning activities, application usage, and unauthorized intrusion attempts. The tools have the ability to set custom performance metrics thresholds for unusual activity.

Systems are extensively instrumented to monitor key operational metrics. Alarms automatically notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used so personnel are always available to respond to operational issues. This includes a pager system, so alarms are quickly and reliably communicated to operations personnel.

Jitterbit Operations and Support teams work with Engineering to handle any incidents or issues related to Jitterbit-developed software or infrastructure. All critical issues are identified and discussed during daily calls among the teams. Postmortems are documented after any significant operational issue, regardless of external impact, and root cause analysis (RCA) reports are drafted so the root cause is captured, and corrective and preventative actions are put in place.

Jitterbit leverages the cloud provider's security-monitoring tools to help identify and resolve DDoS attacks, including distributed, flooding, and software/logic attacks. In addition to this, Jitterbit employs its own tools, monitoring and detection system with the ability to reroute to another region if needed.

Harmony gains the benefits of the cloud provider's network, which provides significant protection against traditional network security issues as described in the Secure network architecture section.

Secure design principles

Harmony's development process follows secure software development best practices. Formal design reviews, code scans, and vulnerability scans validate that Jitterbit software is designed and developed to prevent error messages from transmitting sensitive information and ensure that software services reject unauthorized access and misuse.

Change management

Routine, emergency, and configuration changes to existing Harmony infrastructure are authorized, logged, tested, approved, and documented in accordance with industry norms for similar systems. Updates to Harmony's infrastructure are done to minimize any impact on the customer and their use of the services. The Jitterbit status site provides a public-facing dashboard that lists any outages and periods of system performance degradation, as well as scheduled maintenance and software releases.

Software

Jitterbit Engineering applies a systematic approach to managing change so that changes to customer-impacting services are thoroughly reviewed, tested, approved, and well-communicated. The change management process is designed to avoid unintended service disruptions and to maintain the integrity of service to the customer. Changes deployed to production environments are:

  • Reviewed: Peer reviews of the technical aspects of a change are required.
  • Tested: Changes being applied are tested by a separate QA team to ensure they will behave as expected and not adversely impact performance.
  • Approved: All changes must be authorized in order to be rolled out by Engineering, QA, and Customer Support.

When possible, changes are scheduled during regular change windows. Emergency changes to production systems that require deviations from standard change management procedures are associated with an incident and are logged and approved as appropriate.

Infrastructure

Harmony runs inside a Virtual Private Cluster (VPC) and includes the following services within each region:

  1. Elastic Load Balancer (ELB) that ensures requests to Harmony services and APIs scale and are highly available together with the Apache Tomcat Cluster where Harmony services run. The number of nodes per cluster scales dynamically as request volumes scale up and down.
  2. Caching Server Cluster for managing user sessions. This cluster is designed with built-in redundancy to ensure that a user's session is not affected, switching to another node when needed.
  3. MQ Broker Network that manages requests for agents. This ensures that there is a highly available redundant network among Harmony and all agents.
  4. Relational Database Server with near real-time asynchronous replication across regions. This ensures that all project designs and activity data are available across regions in the event that an entire region becomes unavailable.

Elastic Compute Cloud and container security

Harmony makes extensive use of virtual cloud instances and containers, which provides resizable computing capacity.

Multiple levels of security

Harmony leverages the security within the image provided via the virtual instance OS firewall. External API access is available only on the Harmony HTTPS servers. All other services are protected behind the firewall.

The hypervisor

Elastic Compute currently utilizes a highly customized version of the Xen hypervisor, taking advantage of paravirtualization (in the case of Linux guests). Because paravirtualized guests rely on the hypervisor to provide support for operations that normally require privileged access, the guest OS has no elevated access to the CPU. The CPU provides four separate privilege modes: 0 through 3, called rings. Ring 0 is the most privileged and 3 is the least. The host OS executes in Ring 0. However, rather than executing in Ring 0 as most operating systems do, the guest OS runs in a lesser-privileged Ring 1 and applications in the least-privileged Ring 3. This explicit virtualization of the physical resources leads to a clear separation between guest and hypervisor, resulting in additional security separation between the two.

Each Harmony Virtual instance is controlled by the Jitterbit Operations team. All Harmony instances are hardened and utilize certificate based SSHv3 to access the virtual instance. All key pairs are generated by Jitterbit Operations in order to guarantee that they are unique, and not shared outside Jitterbit Operations.

Containers

Container security involves implementing measures to safeguard containerized applications, their underlying infrastructure, and the data they process throughout the application lifecycle. It begins with securing container images by using trusted sources, scanning for vulnerabilities, and enforcing immutability. Ensuring that only verified and secure images are used helps mitigate the risk of introducing malicious or outdated software into the environment.

During development, Jitterbit incorporates secure coding practices and automated security testing helps identify and mitigate vulnerabilities early. Developers leverage tools and processes like static code analysis, dependency scanning, and configuration checks to ensure applications are secure before they reach production.

Runtime security strategy focuses on limiting container permissions, enforcing network isolation, and monitoring for anomalous behavior. Adhering to the principle of least privilege and isolating containers using namespaces or network policies reduces the potential attack surface. Real-time monitoring tools and alerting mechanisms are used to identify unauthorized access or suspicious activity.

Container orchestration platforms are configured securely, including restricting administrative access, using namespaces for isolation, and regularly patching the orchestrator and its dependencies.

Finally, our strong container security strategy includes a robust incident response plan, compliance with industry standards, and ongoing updates to address emerging vulnerabilities and threats. Continuous monitoring, regular audits, and adherence to best practices ensure that containerized environments remain resilient against evolving security challenges.

Load balancing security

Elastic Load Balancing (ELB) is used to manage traffic on a fleet of cloud instances. ELB has all the advantages of an on-premises load balancer, plus several security benefits:

  • Takes over the encryption and decryption work from the individual instances and manages it centrally on the load balancer.
  • Provides a single point of contact, and also serves as the first line of defense against attacks on your network.
  • Supports end-to-end traffic encryption using TLS (Transport Layer Security, previously SSL) on those networks that use Secure HTTP (HTTPS) connections. When TLS is used, the TLS server certificate used to terminate client connections can be managed centrally on the load balancer, rather than on every individual instance.
  • Supports creation and management of security groups associated with your Elastic Load Balancing to provide additional networking and security options.

Data storage

Harmony uses cloud provider object storage for file data storage. This data includes transformation schemas, database drivers, plugins, and in certain cases, temporary and log files.

Harmony uses the cloud provider's encryption client to encrypt data before uploading to the object store. Object storage services use one of the strongest block ciphers available: 256-bit Advanced Encryption Standard (AES-256). Every protected object is encrypted with a unique encryption key. This object key itself is then encrypted with a regularly rotated master key. Object storage services provide additional security by storing the encrypted data and encryption keys in different hosts.

Data durability and reliability

The cloud provider object stores are designed to provide 99.999999999% durability and 99.99% availability of objects over a given year. Objects are redundantly stored on multiple devices across multiple facilities in a region. To help provide durability, PUT and COPY operations synchronously store customer data across multiple facilities before returning SUCCESS. Once stored, the object stores help maintain the durability of the objects by quickly detecting and repairing any lost redundancy. These services also regularly verify the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, object store services calculate checksums on all network traffic to detect corruption of data packets when storing or retrieving data.