This is a series of blog posts on QBO Technology. We start with taking a look at QBO security practices. In next few we will discuss Performance, Scalability, and SaaS architecture for QuickBooks Online.
“Security is a smile from a headwaiter” – Russell Baker
SaaS (Software as a Service) applications are often referred to as “rented apps.” However, we believe that analogy needs work. Using a SaaS app should not be like renting an apartment where the landlord could bring in a mechanic without even notifying the renter ahead. Our users deserve much better. We believe that SaaS/Cloud apps should be more like renting a Lock Box at a bank. As a bank provides top notch security and is accountable for a fully exclusive private access only to the lock box user and no one else – QuickBooks Online’s job is to provide our users with accounting logic and compute capacity. User’s data is not only exclusively owned by him/her, but we strive to make the system as secure as most secure banks’ lock boxes, if not more. As a user, you and only you have the key (login) to access the data – when you want, using a device of your choice, for however long you want and manage that data with the accounting logic we provide. So, please be assured that your data and business assets are in safe hands.
QuickBooks Online security/privacy model is a three-legged stool. Each of the three buckets gets re-visited and re-calibrated at least once a year, and in reality a few times a year.
1) Physical and Access Security
Tier-4 Data Center: QBO is hosted on two Premier Tier-4 data centers. Tier-4 is the highest category in the data center tiers. There’s no tier-5!
Stringent Background Check: Intuit is in business of Consumer and Small Business Finance for decades. It has robust established practices of recruiting that involves several rounds of background and reference checks.
Site Security: All our key sites are guarded by Intuit Security, follow Access Card-based entry to each building and 24*7 perimeter vigil and control. Data center security is several orders of magnitude stricter and without special privilege pass even an Intuit employee cannot get inside our Data Centers. Maintaining a regime of “Compensating Control,” we have strict separation of roles between Development & Production, and Production access requires multiple levels of authorization. E.g., Operations function is vertically separated in Dev-Ops and Prod-Ops to enable highest degree of control on access of Intuit production assets.
Throttle and other limit put in every tier to prevent DDOS: From Firewall to web to app to storage tier to prevent malicious intent at each tier. Inappropriate accesses are audited from logs periodically. Access logs are audited typically at least a year to revisit past issues.
Password Policy: We follow a strong password policy and password duration for all environments.
2) Code and Infrastructure Security
Release process tied with strong security metrics with stringent exit criteria: We log thousands of hours of security Code Reviews every year by our senior most Staff, Principal and Distinguished Engineers for anti-patterns focusing on SQL injections; Cross-site scripting; Encryption Usage and Correct usage of application APIs. “Code Collaborator” tool is used to track the reviews and it is integrated with our source-code control system for review audits. We also use Static Code Analysis tools like Coverity, Fortify regularly to scan the code for presence of any existing anti-patterns. Consider this coarse-grained protection to complement the fine grained protections applied in Code Reviews.
- Capture essential forensic data, capturing data for critical events or exceptions, and stringent protection of logging data itself.
- Encode Output and Validate Input to make sure browser never displays an executable code or to-be-stored data is of a certain type and is not an executable code itself.
- Internal Wiki created by developers with each functional and technical area for on-boarding new internal developers.
Test Cases: Our developers also are required to write Unit tests to assure that code behaves properly in the face of common forms of attack. Some examples of security unit tests are given in the references.
Security patch update
Regular Update: We have quarterly/bi-yearly/yearly cycles to update software patches, including security patches for our hardware and software stacks.
Ad-hoc Security Patching: As needed. We listen to various security distribution from our vendors and communities (like JSR). e.g., the following recent security updates from Java and Tomcat were carefully discussed the same day and proper actions were rapidly taken to ensure security of QBO users where applicable.
‘Corporate Information Security’ (CIS) is a separate internal unit that deals with Security of application and corporate assets. This team has a great talent pool including some ex-law enforcers; highly experienced security domain experts; anti-phishing /anti-malware strategists etc. Also, there is an Intuit-wide “Security X-Team” with representations from all Business Units/Apps to enable shared learning from recent events.
3) Independent / External Validation of assets and practices
Regular (Independent) Penetration Testing: Despite our best practices and stringent processes, we know that humans make mistakes. To eliminate any vulnerability, we follow a daily/monthly/yearly regime of security tests.
- Daily: Static Automated Analysis with Tools.
- Monthly: Trustwave PCI Compliance Tests
- Yearly: Negative Penetration Tests by external independent security experts. Here we assume “everything is suspect” and simulate BOT attacks to test whether our Firewall, Web and App servers hold against most stringent denial of service and other malicious attacks. We have strategic partnerships with some of the most revered names in the security practices domain and we regularly bring those experts inhouse to “audit and break” our code. Some of the series tests we perform against ourselves are -
- Denial of Service attack using large number of attackers trying to overwhelm servers, or to use large payloads to break our application.
- Mass mining for Information attack to try to get sensitive data, with or without valid credentials.
- CSRF Attack to try hijack an (internal!) user session and forcing the browser to send request to malicious sites.
- Cross Site Scripting attacks to reflect attacker’s content back to the user to execute and pass on sensitive information to attacker
- SQL Injection attacks to inject SQL in the application with malicious intent
- Cookie Management
- Try to break Weak Passwords
- Packet Sniffing Attacks to intercept sensitive or private information in flight etc
Quarterly Review of “Application Security Dashboard” with our CTO and CIO: Every quarter, we review our “Application Security Dashboard” – an established set of questions that bring wide and deep data about QuickBooks Online’s security practices – with many of our executives.
QBO Security Disclaimer
How to write security test cases
- Cross site scripting Cheat sheet
- SQL injection Cheat sheet
- XML Parser DOS Attacks
CERT Secure Coding Standards for C and Java
Java Access Manager