Small Improvements IT and Security information
Our clients frequently ask us "is my data safe?" Here's an overview of our security practices, and how we keep your data safe, accessible and available. If you have further questions, don't hesitate to contact us.
Obviously, hackers read these pages too. We're not going to disclose all our security practices — only those that any smart hacker can figure out all by themselves anyway.
Article Quick Links
- Password and Cookies
- Data Encryption
- Security Policies
- Preventing unauthorized access from within
- Preventing social engineering and attacks against SI staff computers
- Access restrictions to our database
- Disaster Recovery
- Further Considerations
- Customer Support
- Overall Product Quality
- Data portability/deleting your data
- Reporting bugs
Found a security threat?
*If you feel you have found a security exploit, learned about a new threat model, or want to report a security incident, please contact us immediately. We will keep all your data confidential. You can send us an email at email@example.com, or call us any time at +49 157 3432 5347. We will deal with your reported issue immediately.
Our software runs on the Google Cloud Platform. This is a Platform-as-a-Service, which enables application developers to focus on creating their application, while Google takes care of hosting it, providing the database, doing automated backups, logging, auditing, physical access security, and so on. Load-balancers distribute the load, and start and stop additional virtual machines when needed.
App Engine uses Java 8, and Jetty as the application server. All static files are automatically hosted by the Google Content Delivery Network. Servers can be fired up at any Google data center location, which means even downtime in one data center doesn't affect the application, as it can continue to serve from another center.
Google is constantly auditing its services, and has approved to be:
compliant. Read more here.
The data is by default on US Google servers, but we can also host them on a EU Google server, please reach out to our team for help.
Passwords and cookies
Passwords Your passwords are never stored in plain text, instead they are encrypted using the BCrypt algorithm. In layman's terms, your password is garbled beyond recognition and then saved. It cannot be decrypted without huge effort. This also means we cannot recover passwords for you, you need to reset them, since decryption is basically impossible.
If you don't want to use our system to store passwords at all, you're free to integrate with OneLogin or Google Apps via SSO as well, then the passwords will be managed in their systems (or in your own LDAP or AD if you configure those systems accordingly)
Cookies Cookies may be used to authenticate, but the cookie-based authentication does not store your actual password in the cookie. All that gets saved is a randomly created token that allows you to log in and access basic functionality. But if you want to access security-relevant settings like password or email settings, or the administration features, you'll still be prompted to provide your actual password.
Remember Me If security is paramount, you can switch off the Remember Me functionality entirely for your company account, you'll find that option in the advanced settings dialog. Read more about our cookie-based security policies here.
2-Step Verification We're supporting 2-Step Verification using Authy, which support SMS tokens and a mobile app for token generation. 2-Step Verification can be enabled on a per-user basis for key users, and enforced for all admin/IT staff at once, and will thus force a user to verify each new device they want to connect to Small Improvements. Even if a password has been compromised (e.g. stolen from another service at which a user used the same password) an attacker would still not be able to log in into Small Improvements. Learn more on the documentation page.
All data is encrypted during transit using https/SSL. In addition, we're encrypting string-based content such as the written feedback, objectives, performance reviews in the database on a per-field basis, using symmetric AES-256 encryption. We're not adding extra encryption to short fields like names, email addresses or integer or boolean fields, since symmetric encryption of a boolean or integer just doesn't make sense (it's guessable within seconds) and we need to perform searches on fields such as names and email addresses, and that wouldn't work if that data was encrypted. But the data that's crucial and must not get exposed at any cost, for instance the content of objectives or of feedback, is of course encrypted.
The encryption/decryption process happens on the server, in the so-called service level, before and after accessing the database. Sometimes we get asked why it doesn't happen on the client already. In the case of symmetric encryption, it doesn't help to encrypt on the client, because other clients need to decrypt the data as well, and so the decryption key would have to get distributed to the clients too, which would actually be less secure. We're keeping the key on the server only.
In addition you (as the admin) can enforce further security mechanisms:
Password length enforcements By default we're enforcing passwords to be at least 8 characters. In addition, we're giving users an indication of how secure their password is. 8 characters is pretty short, so you can define a company-wide policy of minimum password length, for instance forcing passwords to be at least 10 characters long.
The setting can be found in User Settings portion of the app by visiting Administration -> Overview - > User Settings. Below is an example of where to find this option.
IP Range restrictions If you'd like to restrict access to your company account to a certain IP range (e.g. your office plus anyone who can log in via your VPN) then you can restrict those IP ranges as well. While some people argue that IP addresses can be tampered with, it's not trivial to achieve this for more than a single request (the response from the server will get sent to the IP address the attacker pretends to be at). So IP range filtering adds to security as well.
Preventing unauthorized access from within
Even an authenticated user (e.g. someone who rightfully logged in) may of course try to stage an attack. For instance, an attacker may sign up for a trial account, and try to hack their way into a different clients' account. In addition to using battle-tested coding libraries, lots of automated tests, code reviews and the like, there are additional levels of protections against this happening in the application code itself.
Each database object is internally associated with a company ID. Even if an attacker was able to steal another clients' objects' IDs (using social engineering on another company's employee), the attacker would not get access to these objects because our product always check if the viewer originates from the same company ID as the object they are trying to look at. Whenever our application notices a mismatch, it immediately throws an exception and notifies our administrators. The check is performed for each object access, and each SI page typically displays dozens of objects. A single mismatch out of a hundred object accesses will cancel the entire page operation.
Strong role-based model The other attack vector would be an unhappy employee from within the system. To prevent this, each individual screen of the application and even each single building block is protected by a role-based mechanism as well. Only administrators can access admin screens in the first place. Some screens (like the "data reset" screen) even require admins to get in touch with us, so that a disgruntled administrator cannot simply export or erase your data.
Preventing social engineering and attacks against SI staff computers
Many attacks these days are not targeting the server, but work by tricking staff into downloading and running infected software, or visiting sites that have been compromised and which install malware onto visitors' computers.
There are several ways how we reduce risks:
We're a small team, so it's impossible for someone to pretend you're someone important from another business division. A common social engineering technique is to place a call like this: "Hi, this is Joe from the IT department. We're seeing unusual activity on your computer, can you please visit the link I just sent you by mail, to install the latest anti-virus software". We're way too small for this to happen.
We're security-aware and inform all new staff to be cautious. Even if an attacker impersonated the CEO and sent an unrequested (and infected) file by email, claiming "open the file to check out our latest business stats" for instance, the recipient would ask for confirmation. We use internal systems to share documents, so an unsolicited file in a odd-sounding email will raise suspicion instantly.
- We're using only the most up to date browsers (Chrome, Firefox and Safari, to be specific), which are substantially more secure than older versions, let alone Internet Explorer version.
- We're keeping our operating systems up to date as well. We're mainly on Apple and Linux, which are are substantially harder to attack than Windows. Just to be trusting the OS would be foolish, so we're using further mechanisms to keep our computers protected.
- We use different passwords for every service we use, and the use of password keystores also helps against keyloggers. So even if some site like LinkedIn gets hacked again, it doesn't matter that much since we use different passwords all the time.
- Our development and deployment machine's hard-drives are encrypted, so even in the case of theft, an attacker wouldn't be able to reverse-engineer our sourcecode and upload a compromised version of Small Improvements either.
There are lots of other mechanisms which we won't discuss on our website. We're not claiming to have super-human abilities, but security is our biggest concern, since we'd be out of business if someone managed to hack us. So there are plenty of other items we're considering when developing our features, training our staff and deploying new versions.
Full disclosure policy: In the case anything should ever happen, we will fully disclose the incident to minimize damage. Our previous experience at companies such as Atlassian shows that even if a security breach happens transparency is the only way to deal with it, informing customers what has happened and how to take precautions.
Access restrictions to our database
Our database is hosted inside Google Data centers, and thereby in some of the most secure places possible.
Non-physical access to our production database is severely limited too. Only 6 lead developers can upload new software releases and only 4 can view the actual raw database. Access to the live database and to the servers is restricted to computers that have been authenticated by two-factor authentication. Even if someone managed to retrieve the master password, it would still be useless without that two-factor authentication access code.
Access to the administration website is equally restricted. Only the aforementioned administrators can access all global admin pages, while support staff can only see very restricted "general information" about a client (like how many users, who logged in when, what review cycles exist, etc). Regular support staff cannot analyze a customer's actual content (like actual performance reviews, messages, etc). This functionality is restricted to the people who can access the raw database.
It is our policy to not look into customer data, unless permission has been granted by the customer to help troubleshooting a bug. Most bugs we encounter can be fixed by reproducing the situation locally, and by analysing the logfiles and stacktraces, which do not display customer data beyond IDs and basics like employee names.
Taking security seriously is an important first step, but it doesn't end with preventive measures. It's crucial to have third parties double check the security model. We do this at two levels: Ongoing tests and dedicated security audits.
As an ongoing measure, we're using a service called HackerOne that connects white hat hackers with software vendors. We're running a bounty program that encourages hackers to break Small Improvements's security model, and we pay rewards in case someone finds issues. As an additional measure we've enlisted the services of Security Compass, a company that specialises in security audits. We find the combination of both approaches together has given us the best of two worlds, going both broad and deep, finding a very diverse set of security issues. No issue so far has been on the scale of "very severe", and we're happy to share the latest report from Security Compass. But yes, we have found and resolved dozens of smaller bugs and issues.
Google Cloud is hosted on a highly distributed network across Google Data centers. The data is constantly replicated as well, so even if an entire data center goes down, other still have all the data, and continue serving requests without any end user noticing.
We create daily backups as well of course. So in the event of catastrophic failure of all data centers, or in the case of a grave programming mistake that accidentally wipes data from within our application, we can resort to the backups. We store these backups on an entirely independent service inside the Google network.
We have never had to use these backups in the 7 years of our product's existence, but we frequently ensure the backups actually work, by restoring them onto a separate server and ensuring the data is all there.
Note that we are not able to restore just one single company's data. So if you delete some of your data by accident, it is actually getting deleted. Just because we could restore the entire database, it doesn't mean we can restore that one user you deleted.
Security is the most important aspect when choosing a cloud platform. But there are other related topics that deserve a mention. An application needs to be more than secure, it needs to be available and functional as well, you need to get support for issues that arise, and so on.
We picked Google Cloud for the very reason that it's optimized for availability. An application needs to meet quite a few criteria so it can run on App Engine, and this is mainly because downtime is unacceptable, and certain coding practices are just not possible on App Engine. In return your application is always available under normal conditions.
Our entire business model is geared to providing the best user experience possible. Availability is a key ingredient. We're typically achieving 99.95% according to our Pingdom tracker ( see the details here).
We will do whatever is possible to keep it this way, and fix any downtimes with the highest priority, in the middle of the night if necessary. Our own releases do not require downtime. We roll out small upgrades continuously a few times each week, and conduct larger upgrades on the weekend only. Downtime can not be ruled out entirely, but if for some reason we're offline for more than a few minutes, we'll write a post-mortem and reimburse customers who were affected, for instance by providing a free month of service.
App Engine scales transparently. If more users use the system, more server instances are automatically started, and join forces to handle the load. Typically, 2 server instances are sufficient to balance the load between them, but on certain deadlines the load goes up, and we see maybe 3 or 4 instances in operation. Startup of a new instance takes less than 15 seconds. Other applications running on App Engine have however been reported to use 800 instances under great load, so future growth will not be an issue. We won't get tied down with performance tuning or deadlock-fixing just because we're successful and more customers sign up.
We typically respond within 24 hours to "normal" questions that don't seem urgent to us. We try to reply within 2 hours to urgent questions, e.g. if an administrator is stuck and doesn't know how to proceed with performance reviews that are due within a day or two.
Our company is based in Berlin, Germany, but our support team is distributed across Berlin, Chicago and San Francisco, so we cover Europe and the US during all business hours. APAC support is limited to late evenings and early mornings local time.
Our normal support hours are Monday through Friday 8am - 6pm CST
Check our contact page for our phone and email addresses.
Overall product quality
Even if a system is up and running, program errors ("bugs") may occur that prevent certain features from working. We take this just as seriously, and are doing whatever we can do ensure the highest quality standards.
First of all, we have an very strict hiring process. Every applicant (developer or not) is vetted via phone screen, remote tasks, onsite-interviews, and most importantly by a two-day on-site trial task. Only those who pass our very high standards will join us, and we take onboarding and initial task selection just as seriously to ensure new staff don't introduce preventable problems.
We place a lot of emphasis on automated testing. Each important piece of our software is double-checked by a complementing piece of software, that ensures the original code works well under expected and unexpected conditions. We are using unit- and integration-tests both on the server and on the client side, runing thousands of automated tests continuously, thus preventing failures and errors every day.
Every feature we write will be code reviewed by another person, ideally from another team. Not every single line needs to be verified, but the feature and the bugfix as a whole will be revisited to ensure no unexpected side effects (and also to ensure we follow similar coding practices)
Once all automated tests pass and all code reviews have finished, we either deploy new features to our QA system or, if it's a smaller change only, directly to a staging system where we can test the change within our own live system. Only once we've tested diligently, we either make the feature available to clients as "opt-in" beta, or promote it into production, and monitor it for a while. If anything goes wrong, we can roll back to the previous release within a minute.
In addition, larger features are typically subjected to a lot of user-testing, and we keep improving features even after they have been shipped. We monitor the logfiles carefully, and every exception is automatically sent by email to 2 lead developers, keeping them on their toes as well. We don't claim our software has no bugs, but we're extra sensitive to any issues that may occur, and bugfixing always gets higher priority than feature development.
Google Cloud comes with a sophisticated admin console which includes monitoring and a logfile viewing system. This allows us to pinpoint issues within minutes or even seconds, even when there are dozens of parallel requests. We regularly scan the logfiles for unexpected errors too, and get in touch with end-users if anything went wrong, notifying them about the problem and about our plans on how to fix them. The system automatically sends email to the development team if a bug occurred, just to make sure no problem goes unnoticed.
We also use Pingdom to monitor latency and downtime from various locations across the globe. If you'd like to see our Pingdom statistics, we can give you access.
We keep an ever-growing internal audit log which helps SI staff get a good overview of what is happening in a client's system. The audit log doesn't contain confidential information, but we track all events like logins, logouts, edits to content, assignment of permissions, mails sent etc, and it includes data like IP address, browser version and so on. The audit log is currently very technical and low-level, so it's not accessible to SI customers yet. We have plans to make the audit logs available to SI customers too via the application, until then we're happy to provice an Excel export on a case by case basis. Just contact us.
Data portability, deleting your data
You are welcome to create your own exports.
This option needs to be enabled by SI staff. You can download an XML file that contains all your company data, or you can download data per review cycle. You could for instance download just the XML file for all performance reviews done in the Review Cycle 2018. The XML file can be used to populate another system if you decide to leave our service.
You will find the XML-download button for the cycle in the advanced menu on a cycle overview screen, the XML download for the entire system in the general settings -> Advanced tab. Since the XML export contains all data, the download button is off by default. Please contact SI support to enable the download button.
CSV, Excel, PDF
We also provide means of exporting data to CSV format, so you can further process it. This is available currently for performance review core data, 360 feedback, for objectives, and for your user database.
You may always decide to permanently delete your data. There's a button on the Advanced Settings page (Administration -> Overview -> Advanced Settings) that lets you wipe all content. If you've been using our service for more than 4 weeks, this feature is however protected by an additional master password.
- You will only get this password if one of your administrators asks for it by email. We will check if we've been in touch you before. If more than one administrator exists in the system, we may ask the other person for confirmation. We put this extra step in to prevent snap decisions. After all, the data would really be gone, and our backups do not allow for selective recovery on a per-company basis.
The easiest way to report a bug is to send a mail to firstname.lastname@example.org
Do you need further information?
We are happy to answer more specific questions if you have any, and we're happy to extend this document too. Please get in touch.