ZINFI Security Design Document

www.zinfi.
com
Security Design Overview

Int.prc.002.01 | 02.05.2019
UCM 10.x
ZINFI Confidential & Proprietary

Shared Under NDA
1 | © 2019 ZINFI Technologies Inc. All Rights Reserved. ZINFI Confidential & Proprietary Document - Shared under NDA.
www.zinfi.com
Contents
Section 1: Introduction ...................................................................................... 3
Section 2: Core Security Layers ....................................................................... 4
2.1 Hardware Infrastructure ......................................................................................... 5
2.1.1 Security of Physical Premises ......................................................................................................... 5
2.1.2 Secure Boot Stack and Machine Identity ......................................................................................... 5
2.2 Secure Service Deployment ................................................................................... 6
2.2.1 Service Identity, Integrity and Isolation ............................................................................................ 6
2.2.2 Inter-Service Access Management .................................................................................................. 6
2.2.3 Encryption of Inter-Service Communication..................................................................................... 7
2.2.4 Access Management of End User Data ........................................................................................... 7
2.3 Secure Data Storage ............................................................................................. 8
2.3.1 Encryption at Rest ........................................................................................................................... 8
2.3.2 Data Center Security ....................................................................................................................... 8
2.3.3 Third-Party Tools to Secure the Data Center ................................................................................... 9
2.3.4 Cryptographic Key Management ..................................................................................................... 9
2.3.5 Deletion of Data ............................................................................................................................... 9
2.4 Secure Internet Communication ........................................................................... 10
2.4.1 Network Security ........................................................................................................................... 10
2.4.2 Denial of Service (DoS) Protection ................................................................................................ 11
2.4.3 User Authentication ....................................................................................................................... 12
2.5 Operational Security ............................................................................................ 12
2.5.1 Safe Software Development .......................................................................................................... 12
2.5.2 Keeping Employee Devices and Credentials Safe ........................................................................ 12
2.5.3 Reducing Insider Risk .................................................................................................................... 12
2.5.4 Intrusion Detection ......................................................................................................................... 13
Section 3: Conclusion...................................................................................... 13
www.zinfi.com
Section 1: Introduction
This document provides an overview of how security is designed into ZINFI’s Unified Channel Management
(UCM) technical infrastructure. This global-scale infrastructure is designed to provide security through the
entire information processing lifecycle at ZINFI. The infrastructure provides secure deployment of services,
secure storage of data with end user privacy safeguards, secure communications between services, secure
and private communication with customers over the Internet, and safe operation by administrators.
The security of the infrastructure is designed in progressive layers starting from the physical security of data
centers, continuing to the security of the hardware and software that underlie the infrastructure, and finally,
the technical constraints and processes in place to support operational security.
ZINFI invests heavily in securing its infrastructure with hundreds of engineers, including many who are
recognized industry authorities, dedicated to security and privacy distributed across the organization.
www.zinfi.com
Section 2: Core Security Layers

The security features listed in this document are designed to be technology neutral. The policy requirements
focus on the fundamental objectives and the controls used to protect information during processing, while in
storage and during transmission. The security stack is represented in the diagram below (Fig. 1.0):
Operational Security
• Intrusion Detection
• Reducing Insider Risk
• Safe Employee Devices & Credentials
• Safe Software Development
Internet Communication
• Network Security
• DoS Protection
• User Authentication
Storage Services
• Encryption
• Deletion
• User
User Identity
• Authentication
• Login Abuse Protection
Service Deployment
• Access Management of End User Data
• Encryption of Inter-Service Communication
• Inter-Service Access Management
• Service Identity,Integrity, Isolation
Hardware Infrastructure
• Secure Boot Stack and Machine Identity
• Security of Physical Premises
Figure 1.0
www.zinfi.com
2.1 Hardware Infrastructure

In this section we describe how we secure the lowest layers of our infrastructure, ranging from the physical
premises to the purpose-built hardware in our system to the low-level software stack running on every machine.
2.1.1 Security of Physical Premises

ZINFI designs and builds its own data centers, which incorporate multiple layers of physical security protections.
Access to these data centers is limited to only a very small fraction of ZINFI employees. We use multiple
physical security layers (see Fig. 2.0) at our premises to protect our data center floors and use technologies like
biometric identification, metal detection, cameras and intrusion detection systems.
Figure 2.0
2.1.2 Secure Boot Stack and Machine Identity

ZINFI server machines use a variety of technologies as displayed in Fig. 3.0 to ensure that they are booting the
correct software stack. We use cryptographic signatures over low-level components like the BIOS, bootloader,
kernel and base operating system image. These signatures can be validated during each boot or update. The
components are all ZINFI-controlled.
ZINFI has authored automated systems to ensure servers run up-to-date versions of their software stacks
(including security patches), to detect and diagnose hardware and software problems, and to remove machines
from service if necessary.
• Identity Key &

• Identity Key & Certificate
Device
Secure Boot Signed Image Identity
Certificate Authentication • Network
• TPM Authentication
system
Figure 3.0
www.zinfi.com
2.2 Secure Service Deployment

As we will see in this section, our infrastructure does not assume any trust between services running on the
infrastructure. In other words, our infrastructure is fundamentally designed to be multi-tenant.
2.2.1 Service Identity, Integrity and Isolation

Cryptographic authentication and authorization for inter-service communication is integrated providing strong
access control and simplicity that administrators and services can naturally understand. This approach is
illustrated in Fig. 4.0. Each service that runs on the infrastructure has an associated service account identity. A
service is provided cryptographic credentials that it uses to prove its identity when making or receiving remote
procedure calls (RPCs) to other services. These identities are validated by clients to ensure that they are talking
to the correct intended server, and by servers to limit access to methods and data to clients.
ZINFI’s source code is stored in a central repository where current and previous versions are auditable. The
infrastructure can be configured such that it requires that a service be built from a reviewed specification and
tested source code. These requirements limit the ability of an insider or adversary to make malicious
modifications to source code and provide a forensic trail from a service back to its source.
Figure 4.0
2.2.2 Inter-Service Access Management

The owner of a service can use access management features provided by our infrastructure to specify exactly
which other services can communicate with it. For example, a service may want to offer some APIs; that service
can be configured with the allowed service account identities, and this access restriction is automatically
enforced by our infrastructure.
www.zinfi.com
2.2.3 Encryption of Inter-Service Communication

In parallel to the RPC capabilities discussed earlier, our system infrastructure provides cryptographic privacy and
integrity for RPC data on the network (see Fig. 5.0). To provide these security benefits, we encapsulate them
inside our infrastructure RPC mechanisms, giving the application layer isolation and removing any dependency
on the security of the network path. Encrypted inter-service communication remains secure even if the network is
tapped or a network device is hacked.
Figure 5.0
2.2.4 Access Management of End User Data

ZINFI’s infrastructure (Fig. 6.0) provides a central user identity service which issues “end user permission
tickets.” An end user login is verified by the central identity service provided by our state-of-the-art Identity
Server, which then issues a user credential, such as an OAuth token, to the user’s client device. Every
subsequent request from the client device into the ZINFI UCM platform must present that user credential.
Figure 6.0
www.zinfi.com
2.3 Secure Data Storage

Up to this point in the discussion, we have described how we deploy services securely. We now turn to
discussing how we implement secure data storage on the infrastructure.
2.3.1 Encryption at Rest

The storage services can be configured to use encryption keys from the key management service to encrypt
data. This key management service, defined briefly in Fig. 7.0, supports automatic key rotation and provides
extensive audit logs.
Figure 7.0
Performing encryption at system layers allows the system to isolate itself from potential threats at the lower
levels of storage. That said, the infrastructure also implements additional layers of protection. We enable
hardware encryption support in our hard drives and SSDs and meticulously track each drive through its lifecycle.
2.3.2 Data Center Security

Our data center is self-certified with the U.S. Department of Commerce’s U.S. European Union (EU) Safe Harbor
framework, verifying that the data center meets the EU’s adequacy standard for data and privacy protection.
Figure 8.0 shows our data center infrastructure design pattern:
Figure 8.0
www.zinfi.com
Data center security at a glance:
compliant data center infrastructure.

data centers and network operations centers.
hardware and software both mechanism.
-system virus scanning and systems patching.
2.3.3 Third-Party Tools to Secure the Data Center

McAfee® Virus Scan and Host Intrusion Servers: These systems combine anti-virus, antispyware, firewall and
intrusion prevention technologies to stop and remove malicious software from your infrastructure.
RescueLayer®: Boot failed servers into a RAM-disk recovery kernel with the failed server’s regular IP addresses,
giving it full access to private and public networks, NAS and backend service network servers, a wide range of
tools and disk recovery utilities, on-board file systems, and locally attached storage.
Network IDS/IPS Protection: Through partnerships with leading hardware and software vendors, a complete
array of intrusion protection and assessment options at both the network and host level.
Nessus® Vulnerability Assessment and Reporting: The world leader in active scanners, featuring high-speed
discovery, configuration auditing, asset profiling, sensitive data discovery and vulnerability analysis of security
posture.
2.3.4 Cryptographic Key Management

For information classified as CONFIDENTIAL or above, the symmetric encryption key length shall be at least
128-bit for the AES encryption or equivalent, whereas the asymmetric encryption key length shall be at least
2048-bit for the RSA encryption. Alternatively, the requirement can be met by Elliptic Curve Cryptography (ECC)
encryption with key length of at least 224-bit or equivalent. For RESTRICTED information, the above key length
is also adopted.
2.3.5 Deletion of Data

Deletion of data at ZINFI most often starts with marking specific data as “scheduled for deletion” rather than
removing the data entirely. This allows us to recover from unintentional deletions, whether customer-initiated or
due to a bug or process error internally. After having been marked as “scheduled for deletion,” the data is
deleted in accordance with service-specific policies. When an end user deletes their entire account, the
infrastructure notifies services handling end user data that the account has been deleted. The services can then
schedule data associated with the deleted end user account for deletion.
www.zinfi.com
2.4 Secure Internet Communication

As discussed earlier, ZINFI’s infrastructure consists of a large set of physical machines which are interconnected
over the LAN and WAN and the security of inter-service communication is dependent on the security of the
network. However, we do isolate our infrastructure from the Internet into a private IP space so that we can more
easily implement additional protections, such as defenses against denial of service (DoS) attacks, by exposing
only a subset of the machines directly to external Internet traffic.
2.4.1 Network Security

IPsec - Internet Protocol Security
IPsec solves an important problem (see Fig. 9.0) that arises when embedded systems are connected to the
Internet. Since the Internet protocol has no data security built in, both application and user data is sent in clear
text. This enables a third party to inspect or even modify data from the embedded system as it traverses the
Internet. For example, passwords are sent in the open and can be seen and used to compromise a system.
Figure 9.0
IPsec is designed for both IPv4 and IPv6 operation and is optimized for deployment in embedded systems.
www.zinfi.com
HTTPS - Secure Embedded Web Server
Integrating an Embedded Web Server in a dedicated device presents special requirements on the server in
terms of memory consumption, performance, security and functional requirements. The Secure Embedded Web
Server is a versatile, configurable, high-performance HTTP server (Fig. 10.0) that has low ROM and RAM
footprint. It is specifically designed for operating in an embedded environment.
Figure 7.0
The HTTPS protocol was developed to address the inadequate security features of the HTTP protocol. HTTPS
introduces Secure Socket Layer (SSL) functionality in the communication between the web server and the
browser. This eliminates the risk of most security breaches, and has now become the de facto standard for
secure web communication.
The Secure Embedded Web Server has built-in support for SSL which is configurable and can be removed to get
minimum footprint. Features of Secure Embedded Web Server include:
» Supports HTTP/1.0 (RFC1945) and HTTP/1.1 (RFC2616)

» Supports HTTP methods GET, HEAD and POST
» Supports incoming entities
» Implements persistent connections (HTTP/1.1)
2.4.2 Denial of Service (DoS) Protection

The sheer scale of our infrastructure enables absorption of many DoS attacks. That said, we have multi-tier,
multi-layer DoS protections that further reduce the risk of any DoS impact on a service running.
After our backbone delivers an external connection to one of our data centers, it passes through several layers of
hardware and software load-balancing. These load balancers report information about incoming traffic to a
central DoS service running on the infrastructure. When the central DoS service detects that a DoS attack is
taking place, it can configure the load balancers to drop or throttle traffic associated with the attack.
www.zinfi.com
2.4.3 User Authentication

After DoS protection, the next layer of defense comes from our central identity service. This service usually
manifests to end users as the ZINFI UCM login page. After authenticating the user, the identity service issues
credentials such as cookies and OAuth tokens that can be used for subsequent calls.
2.5 Operational Security

Up to this point, we have described how security is designed into our infrastructure and have also described
some of the mechanisms for secure operation such as access controls on RPCs.
We now turn to describing how we operate the infrastructure securely: We create infrastructure software
securely, we protect our employees’ machines and credentials, and we defend against threats to the
infrastructure from both insiders and external actors.
2.5.1 Safe Software Development

Beyond the central source control and two-party review features described earlier, we also provide libraries that
prevent developers from introducing certain classes of security bugs. For example, we have libraries and
frameworks that eliminate XSS vulnerabilities in web apps. We also have tools for automatically detecting
security bugs, including static analysis tools and web security scanners.
The sheer scale of our infrastructure enables ZINFI to simply absorb many DoS attacks. As a final check, we use
manual security reviews that range from quick triages for less risky features to in-depth design and
implementation reviews for the riskiest features. These reviews are conducted by a team that includes experts in
web security, cryptography and operating system security. The reviews can also result in new security library
features that can then be applied to other future products.
2.5.2 Keeping Employee Devices and Credentials Safe

We make a heavy investment in protecting our employees’ devices and credentials from compromise and in
monitoring activity to discover potential compromises or illicit insider activity. This is a critical part of our
investment in ensuring that our infrastructure is operated safely.
We also make a large investment in monitoring the client devices that our employees use to operate our
infrastructure. We ensure that the operating system images for these client devices are up to date with security
patches and we control the applications that can be installed. In addition, we have systems for scanning user-
installed apps, downloads, browser extensions and content browsed from the web.
2.5.3 Reducing Insider Risk

We limit and actively monitor the activities of employees who have been granted administrative access to the
infrastructure and continually work to eliminate the need for privileged access for particular tasks by providing
automation that can accomplish the same tasks in a safe and controlled way.
This includes requiring two-party approvals for some actions and introducing limited APIs that allow debugging
without exposing sensitive information. ZINFI employee access to end user information can be logged through
www.zinfi.com
low-level infrastructure hooks. ZINFI’s security team actively monitors access patterns and investigates unusual
events.
2.5.4 Intrusion Detection

ZINFI has sophisticated data processing pipelines which integrate host-based signals on individual devices,
network-based signals from various monitoring points in the infrastructure, and signals from infrastructure
services. Rules and machine intelligence built on top of these pipelines give operational security engineers
warnings of possible incidents. Our investigation and incident response teams triage, investigate and respond to
these potential incidents 24 hours a day, 365 days a year.
Section 3: Conclusion
We invest heavily in securing our infrastructure. We have many hundreds of engineers dedicated to security and
privacy distributed across ZINFI.
As we have seen, the security in the infrastructure is designed in layers starting from the physical components
and data center, moving on to hardware provenance, and then on to secure boot, secure inter-service
communication, secured data at rest, protected access to services from the Internet and, finally, the
technologies, people and processes we deploy for operational security.

ZINFI Security Design Document

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

ZINFI Security Design Document

Hochgeladen von

Copyright:

Verfügbare Formate

www.zinfi.

Security Design Overview

ZINFI Confidential & Proprietary

Section 2: Core Security Layers

2.1 Hardware Infrastructure

2.1.1 Security of Physical Premises

2.1.2 Secure Boot Stack and Machine Identity

• Identity Key &

2.2 Secure Service Deployment

2.2.1 Service Identity, Integrity and Isolation

2.2.2 Inter-Service Access Management

2.2.3 Encryption of Inter-Service Communication

2.2.4 Access Management of End User Data

2.3 Secure Data Storage

2.3.1 Encryption at Rest

2.3.2 Data Center Security

Data center security at a glance:

compliant data center infrastructure.

2.3.3 Third-Party Tools to Secure the Data Center

2.3.4 Cryptographic Key Management

2.3.5 Deletion of Data

2.4 Secure Internet Communication

2.4.1 Network Security

HTTPS - Secure Embedded Web Server

» Supports HTTP/1.0 (RFC1945) and HTTP/1.1 (RFC2616)

2.4.2 Denial of Service (DoS) Protection

2.4.3 User Authentication

2.5 Operational Security

2.5.1 Safe Software Development

2.5.2 Keeping Employee Devices and Credentials Safe

2.5.3 Reducing Insider Risk

2.5.4 Intrusion Detection

Das könnte Ihnen auch gefallen