I Done This Security Features:
- SSL restricted traffic ensures secure data transfer between servers and browsers.
- Administrator access is provided according to stringent rules and enforced by two-factor authentication.
- Data at-rest encrypted on S3.
- Analytics provide reporting on content access and traffic flow for ensuring appropriate distribution.
At I Done This, we take the security of your data and content as our paramount concern. The proactive approach to security and stringent procedures described above protects the security of your I Done This data.
Security FAQ
Where do we host our services?
I Done This hosts its software-as-a-service at Amazon Web Services (AWS) for unparalleled security, reliability and availability. Utilizing AWS infrastructure, I Done This inherits AWS-network, ops and monitoring to satisfy stringent physical and network intrusion requirements. AWS is SAS70 Type II Certified, HIPAA compliant, and PCI compliant and has unrivaled scalability.
When was our hosting facility audited (SAS 70, ISO17799, etc.) and what were the detailed results?
The AWS SAS70 audit was completed within the last 18 months, and AWS received a favorable unbiased opinion from its independent auditors. The control objectives and control activities of AWS are focused on operational performance and security to protect customer data. A copy of the report is available from AWS upon request and with an executed NDA in place with Amazon. I Done This has reviewed the SAS70 audit in detail and is satisfied that AWS infrastructure meets or exceeds all critical SAS70 audit protocols.
What are the redundancy features for our hosting facility?
The server infrastructure of AWS is known as Elastic Compute Cloud, or EC2. This infrastructure is highly flexible and scalable, allowing business-critical web applications like I Done This to adjust capacity in minutes. Hundreds or thousands of server instances can be deployed instantly and simultaneously, across multiple geographic regions. I Done This is currently deployed in multiple Availability Zones with data stored in S3.
Availability Zones ensure failure-resilient operations with planned fault separation. Availability Zones are physically separated facilities engineered to remain insulated from any failure in other locations. Availability Zones in the same geographic region are located on different floodplains, in areas determined to be seismically stable, and maintain low- latency connectivity with each other. Server instances running in separate Availability Zones safeguard an application from the failure of a single location.
Data traffic between Availability Zones is transmitted across AWS-controlled private network infrastructure, which provides minimal latency, transmission consistency, and end-to-end security.
Each facility receives power from different grids, and from independent utilities to further protect against single points of failure. In addition, discrete uninterruptable power source (UPS) systems, batteries, and onsite diesel backup generators standby to regulate flow, prevent spikes and brownouts, and convey clean power in the event of utility failure.
Each Availability Zone maintains redundant connections to multiple tier-1 transit providers to guarantee unbroken network connectivity at all times.
The AWS data storage infrastructure, named S3, is 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 an Amazon S3 Region. To help provide durability, S3 Put and Copy operations synchronously store data across multiple facilities before returning Success. Once stored, S3 helps maintain the durability of objects by quickly detecting and repairing any lost redundancy. S3 also regularly verifies the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data.
When was the last time your servers/services were audited (security) and what were the results?
AWS is audited annually and I Done This conducts penetration testing on a defined schedule as described below.
What is your patch management process for your servers?
I Done This’s Patch Management Process relies on known, standard, AWS-provided machine images. These are long term supported releases with automatic patch (system upgrade) application. Additionally, the team monitors security bulletins and applies additional patches or updates, as needed. These are subject to rigorous analysis and testing prior to implementation.
How often do you run vulnerability scans against your servers (can you share the latest with us)?
The most recent penetration test was conducted within the last 180 days and identified no critical vulnerabilities. See below.
When was your last penetration test against your customer environment and what were the results?
Independent, third-party vulnerability testing probes the I Done This infrastructure and web application for unknown risks. This testing crawls the web application, searching for cross-site scripting and SQL injection vulnerabilities. In addition, testing scans for any sensitive content in HTML, pages without transit encryption, source disclosure, directory traversal, and session authentication. I Done This technical teams review every vulnerability scan report and submit written explanations to senior management regarding any vulnerability found, even if it is identified as a minimal or non-threatening risk. The most recent penetration test was conducted within the last 180 days and identified no critical vulnerabilities.
AWS’ development process follows secure software development best practices, which include formal design reviews by the AWS Security Team, threat modeling, and completion of a risk assessment. Static code analysis tools are run as a part of the standard build process, and all deployed software undergoes recurring penetration testing performed by carefully selected industry experts. The security risk assessment reviews begin during the design phase and the engagement lasts through launch to ongoing operations.
Do you have your servers hardened via any specific security standards (what is the OS, patch level, SR level)?
Host Operating System: Administrators with a business need to access the management plane are required to use multi-factor authentication to gain access to purpose-built administration hosts. These administrative hosts are systems that are specifically designed, built, configured, and hardened to protect the management plane of the cloud. All such access is logged and audited. When an employee no longer has a business need to access the management plane, the privileges and access to these hosts and relevant systems are revoked.
Firewall: A complete inbound firewall is set in a default deny mode, meaning that by default all inbound traffic is rebuffed. Administrators explicitly opens and configures a specific number of ports to enable inbound traffic. Traffic restrictions are imposed by a combination of protocol, service port, and source IP address.
With firewall configuration, various classes of instances possess different rules. While the web server group has an HTTP port and an HTTPS port open to the Internet, the application server group has a port open only to the web server group, and the database server group has a port open only to the application server group. This structure supports a highly secure cloud application.
The firewall cannot be controlled through the server instance operating system. Administrators utilizes a secure certificate and key to make configuration changes. Because the security value of any firewall is dependent on which ports are opened, for what purpose, and for what duration, Administrators maintains strict protocols for port configuration changes, as well as routine scans to detect any unintended vulnerabilities. Strategic security design and traffic management shield the server instance plane.
Who has admin/root access to your servers? Who will have administrative access and how will this access be maintained and tracked?
Only host administrators have root access and administrative control over server instances, services, and applications. AWS does not possess access rights to the operating system of I Done This server instances. This separation of power provides a necessary structure of checks-and-balances to protect the integrity of the application. Security best practices in place to safeguard server instances include, but are not limited to, the disabling of password-based access to hosts, certificate-based SSH Version 2 access protocols, multi-factor authentication, unique key pairs, and a privilege escalation system with per-user logging.
How are your servers and any other devices secured at this facility?
Amazon has many years of experience in designing, constructing, and operating large-scale datacenters. This experience has been applied to the AWS platform and infrastructure. AWS datacenters are housed in nondescript facilities. Physical access is strictly controlled both at the perimeter and at building ingress points by professional security staff utilizing video surveillance, intrusion detection systems, and other electronic means. Authorized staff must pass two-factor authentication a minimum of two times to access datacenter floors. All visitors and contractors are required to present identification and are signed in and continually escorted by authorized staff. AWS only provides datacenter access and information to employees and contractors who have a legitimate business need for such privileges. When an employee no longer has a business need for these privileges, his or her access is immediately revoked, even if they continue to be an employee of Amazon or Amazon Web Services. All physical access to datacenters by AWS employees is logged and audited routinely.
How do you handle security when someone on your staff who had admin type access is let go and/or resigns?
I Done This maintains a well-defined user account administration process to ensure that each employee has a system account with limited permissions, and no dormant accounts remain active. The account permissions policy defines the appropriate permissions necessary for each job function, including, if applicable, access to testing servers, production servers, customer account information, and network devices. User accounts are terminated immediately upon cessation of employment.
How is customer data stored on your servers?
I Done This user data and documents are stored in AWS S3 data centers. Every document and piece of data identified as sensitive is stored encrypted and automatically and immediately copied to multiple locations for redundancy. Therefore, there is no lag time in backup creation, ensuring data would be available instantly after an interruption in any one location.
In addition, AWS achieves object durability by not only creating redundant storage across multiple datacenters on the initial write, but also monitoring for device unavailability or bit-rot and automatically implementing further replication if necessary. By default, AWS has both bucket- and object-level access controls, permitting authenticated access by the creator only. To access data, users are authenticated using an HMAC-SHA1 signature with private key. Furthermore, even authenticated users are permitted to read objects only if they have Read permissions in an Access Control List (ACL) at the object level. This security logic is deeply integrated into the I Done This application to ensure appropriate user data access. To maintain maximum security for both development and production, AWS S3 is accessed via SSL-encrypted endpoints, confirming that data cannot be viewed or compromised in transit from an internet node to the AWS secured facility.
AWS allows for the placement of instances and data storage within multiple geographic Regions. Each Region is an independent collection of AWS resources in a defined geography. Within a given Region, I Done This deploys instances and stores data across multiple Availability Zones.
I Done This utilizes industry standard encryption algorithms and key strengths to encrypt data.
I Done This never permanently stores customer files or data on its servers. All files and data are transferred directly, from the client, to Amazon S3. Amazon S3 is the safest data storage infrastructure for storing and retrieving any amount of data. AWS offers a reliable platform for software services used by thousands of businesses worldwide, provides services in accordance with security best practices, and undergoes regular industry-recognized certifications and audits.
How is this data segmented from other customer data?
I Done This data stored on S3 includes strong tenant isolation security and control capabilities. As a virtualized, multi-tenant environment, S3 implements security management processes and other security controls designed to isolate each customer, such as I Done This, from other S3 customers.
The Hypervisor: AWS currently utilizes a highly customized version of the Xen hypervisor. 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. This explicit virtualization of the physical resources leads to a clear separation between guest and hypervisor, resulting in additional security separation between the two.
Instance Isolation: Different instances running on the same physical machine are isolated from each other via the Xen hypervisor. In addition, the AWS firewall resides within the hypervisor layer, between the physical network interface and the instance’s virtual interface. All packets must pass through this layer, thus an instance’s neighbors have no more access to that instance than any other host on the Internet and can be treated as if they are on separate physical hosts. The physical RAM is separated using similar mechanisms.
I Done This employs best practices in secure application development, including design and architecture reviews, threat forecasting, risk assessment, code analysis, and vulnerability testing. Personnel with significant experience in web application risk and security evaluate potential weaknesses during design, development, and post-deployment. Specifically, I Done This’s risk assessment protocol eliminates the following potential risks: a I Done This employee obtaining unauthorized access to customer data; a third party obtaining access to any post-login data in the I Done This system; and a I Done This customer accessing another customer’s restricted data.
Is the data stored on the server encrypted?
Yes, see above.
Who has access to the database on this server (admin level)?
Only I Done This’s CEO, CTO, and limited technical personnel have admin-level database access.
How often do you change passwords on the server and the database (what is your password length policy)?
All system passwords are changed on a confidential defined schedule, and passwords comply with best practices in length and complexity.
What level of encryption do you use in data transmission and what type (SSH, SSL, HTTPS, TLS, sFTP, PGP, Client-side certificates, VPN, IPSec (router to router), s/MIME, non-inclusively)?
I Done This utilizes DigiCert Certificates for 256-bit SSL encryption.
What type of customer data is stored on your servers and in your databases?
I Done This user data including hashed and one-way encrypted passwords, email address, client IP address, and third-party OAuth tokens. Links to assets stored within AWS S3.
Are there any remote connections to your servers for maintenance and if so, what is used for this remote access and who has the access?
When I Done This administrators make calls to AWS for the purposes of maintenance all calls are signed by a secure certificate and key. In addition, to maintain confidentiality, infrastructure API calls are encrypted with SSL.
Do you have any modems in any of your customer facing servers?
No.
What security framework do you follow? How do you follow this framework and ensure compliance with it?
I Done This employs a world-class SaaS security framework incorporating five pillars: Physical Security, Network Infrastructure Security, Operational Security, Application Security, and Transaction Security. This framework incorporates best practices in each area of security and is layered on top of the industry-leading security protocols of AWS.
Do you employ ITIL practices and if so to what extent?
I Done This incorporates best practices from ITIL protocols in Application Management, Problem Management, Availability Management, and Security Management. However, I Done This does not implement all ITIL practices and modifies certain ITIL protocols to fit its operational requirements.
Do you have well defined and practiced incident response procedures?
I Done This has defined threat response protocols. In addition, the AWS Incident Management team employs industry-standard diagnostic procedures to drive resolution during business-impacting events. Staff operators provide 24 x 7 x 365 coverage to detect incidents and to manage the impact and resolution
How often are they practiced?
Incident response protocols are reviewed bi-annually.
What triggers do you have that require informing partners (i.e., what criteria do you use to determine when to shutdown inbound and/or outbound Internet access, as an example)?
AWS utilizes the engineering expertise gained in building and defending the world’s largest e-commerce infrastructure to protect against traditional and new network security issues. Proprietary mitigation strategies guard against Distributed Denial Of Service (DDoS) attacks. In addition, AWS networks are multi-homed across multiple providers for internet access diversity. Man In the Middle (MITM) attacks are thwarted with AWS API access via only SSL-protected endpoints with server authentication, as well as new SSH host certificates on the first boot of instances. To eliminate the threat of IP spoofing, the AWS- controlled, host-based firewall prohibits instances from sending traffic with source IP’s or MAC addresses other than their own.
I Done This’s threat response protocols require systems access termination in the case of any unidentifiable or unmanageable threat.
Additionally, I Done This’s Terms of Service allow immediate termination of customer content that is deemed to be an inappropriate usage of the service. This includes exceeding reasonable use limits for access and distribution as well as automatic reporting and monitoring of content.
What are your root cause analysis (RCA) procedures and how do you handle working with multiple vendors and customers in a situation that requires all to participate?
I Done This’s monitoring service monitors our websites and servers from multiple locations on the Internet to ensure maximum uptime. The service keeps reports of all detected errors, duration and what kind of error triggered the event. Depending on the kind of error, error analysis may include several steps, including checking DNS lookups, traceroutes to locate network problems, the header response from the server, etc.
AWS utilizes automated monitoring systems to provide a high level of service performance and availability. Proactive monitoring is available through a variety of online tools both for internal and external use. Systems within AWS are extensively instrumented to monitor key operational metrics. Alarms are configured to notify operations and management personnel when early warning thresholds are crossed on key operational metrics. An on-call schedule is used such that personnel are always available to respond to operational issues. This includes a pager system so alarms are quickly and reliably communicated to operations personnel.
Documentation is maintained to aid and inform operations personnel in handling incidents or issues. If the resolution of an issue requires collaboration, a conferencing system is used which supports communication and logging capabilities. Trained call leaders facilitate communication and progress during the handling of operational issues that require collaboration. Post-mortems are convened after any significant operational issue, regardless of external impact, and Cause of Error (COE) documents are drafted so the root cause is captured and preventative actions are taken in the future. Implementation of the preventative measures is tracked during weekly operations meetings.
What type of reporting is provided to customers for trouble tickets (type, frequency)? Do customers have access into their tickets and the ability to generate their own reports?
Your dedicated I Done This support specialist will manage any trouble tickets and provide reporting if necessary.
How often are reviews for tickets and other potential issues held with your customers?
The I Done This support specialist reviews any outstanding tickets weekly. Service and performance review meetings are typically held quarterly, depending on carrier preference.
Can you share a sanitized version of your DR/BCP plans?
I Done This’s Business Continuity Management is an extension of AWS’s infrastructure, which is designed with the highest level of availability and a resilient IT architecture. AWS has designed its systems to tolerate system or hardware failures with minimal customer impact. Availability Zones ensure failure-resilient operations with planned fault separation. Availability Zones are physically separated facilities engineered to remain insulated from any failure in other locations. Availability Zones in the same geographic region are located on different floodplains, in areas determined to be seismically stable, and maintain low- latency connectivity with each other. Server instances running in separate Availability Zones safeguard an application from the failure of a single location. All data centers are online and serving customers; no data center is “cold.” In case of failure, automated processes move customer data traffic away from the affected area. Core applications are deployed in an N+1 configuration, so that in the event of a data center failure, there is sufficient capacity to enable traffic to be load-balanced to the remaining sites.
In addition, I Done This’s internal DR plan includes detailed protocols for re-establishing operations in the case of threat or damage to I Done This’s offices in San Francisco, California and Las Vegas, Nevada. Because AWS infrastructure supports systems and data, this type of incident is unlikely to cause interruption to the delivery of the I Done This software application. Procedures and goals of the DR plan are designed to establish a new office, acquire new computer and phone equipment if necessary, and return I Done This technical and business personnel to the pre-disaster state of operational performance.
How many CISSPs do you have on staff? What other certifications does your staff hold?
I Done This does not employ personnel with CISSP certification. However, I Done This technical and security personnel are highly experienced in the design and maintenance of high-security, business-critical SaaS systems.
What is your approach to perimeter security and please provide a sanitized diagram of this infrastructure?
See above.
Have there been any breaches (physical or virtual) in any of your hosted and/or customer facing environments? If not, please describe how you know there has not been any.
No. Internal reports indicate no breaches, and third-party vulnerability testing has identified no potential access points for breaches.
Will you indemnify Enterprise Customers against any breaches to your physical or virtual infrastructure?
The I Done This MSA includes an indemnification for any breach of confidential information or other liabilities incurred as a result of a breach.
How will you segment network traffic?
Each Availability Zone maintains redundant connections to multiple tier-1 transit providers to guarantee unbroken network connectivity at all times. I Done This has a horizontally-scalable systems architecture that is designed to handle any variations in network traffic.
Who will have physical access to the device and how do you track and maintain this?
See multiple answers above.
What regulations must you adhere to (GLBA, SOX, HIPAA, PCI, SB1386, non-inclusively)? How do you address compliance with the regulations that cover your business activities?
AWS has completed a Statement on Auditing Standards No. 70 (SAS70) Type II Audit and received a favorable unbiased opinion from its independent auditors. SAS70 certification indicates that a service organization has undergone a comprehensive audit of its controls. The control objectives and control activities of AWS are focused on operational performance and security to protect customer data.
Both I Done This and AWS have operational and system controls and procedures in place to conform with the Payment Card Industry Data Security Standard (PCI DSS). Developed by the Payment Card Industry Security Standards Council (PCI SSC), PCI DSS standards are designed to ensure a secure environment where credit card information is processed and stored. PCI DSS compliance is commonly extrapolated to infer security around financial data, personally identifiable information, and related sensitive data.
The Health Insurance Portability and Accountability Act (HIPAA) establishes rules and procedures around the collection, transmission, and retention of sensitive consumer health and medical data. I Done This and AWS fulfill the end-to-end security requirements necessary for HIPAA-compliant document transactions.