At first, the title of this blog sounds like an excuse. It’s that sentence that almost every company uses ‘after’ they got hacked. (Don’t worry, we didn’t!). According to me it’s a bad excuse if you present it after everything has fallen apart and only then start working on it. You need to work on it every day.
In this series of 3 blog posts we’d like to share a bit of the Serious work we’re doing at TOPdesk to Secure our customers’ data. We’re doing this not just to keep the data safe, but also because Security is an amazingly interesting and fun topic to work on.
In part 1 we talked about making all our colleagues aware of the risks. In this part we’d like to tell you how we’re helping our fellow Developers to actually build Secure software.
Secure Development
Secure Development is more than just being aware of risks. Developers should practice what they learned and stay on top of things. You might think that Security is a responsibility for the Security Guild, but that’s not how we think about it at TOPdesk. Only the development team can be responsible for what they deliver. This means that the team themselves needs to go look for knowledge on how to do this. What we from the Security Guild are doing, is helping them to make it as easy as possible. We’ll help in any way we can think of to give them the tools to delivery software that is as Secure as possible.
One of the ‘tools’ that we provide, are cheat sheets for their daily Development work. For this we could have used the standard OWASP cheat sheets. However, we feel that some cheat sheets can be much more effective if we make them more applicable to our specific needs. So, we created our own versions. They’re still based on the OWASP versions (we want them as effective as possible, but we’re not looking for work). The customized cheat sheets are aimed better at the types of mistakes or vulnerabilities we found in the past and at risks that are specific to TOPdesk.
For reviewing and testing their work, developers asked the Security Guild for a checklist, just to make sure they wouldn’t forget anything important. It’s always nice to hear colleagues ask about Security, so we immediately started working on getting them the perfect checklist. This time, we could have used the OWASP Proactive Controls, but we felt that a shorter, simpler list, more aligned with our situation, is more efficient for our Developers. So, we analyzed the types of vulnerabilities we found in the past. We categorized them according to impact and suggested solutions and distilled a new list. After a few feedback and review iterations, we now have our list. The perfect list may not exist, but our best effort is now being used by all teams.
Fixing vulnerabilities together
When vulnerabilities are found, we could ask the help of Developers in the Security Guild to fix it. This would mean that the issue gets fixed most quickly, but it also means that the Developers responsible may make the same mistake again. Therefore, where possible, we always try to fix the issues together. By helping colleagues in fixing a Security problem, they learn, which makes the risk of introducing new vulnerabilities smaller. An added benefit of doing this together, is that for them it’s also a natural moment to ask other Security questions. Besides that, they know to find you more easily in the future if the need arises.
Threat Modeling
Threat modeling is a very powerful technique to get insight in security risks and find vulnerabilities. For those who are not familiar with this: it’s a technique to model all Security threats to your application, and in recent years, it’s getting more and more attention. We are helping teams to get acquainted with this, so they can apply it themselves. See our previous blog for inspiration to start doing this yourself.
Already, applying threat modeling has given us much more insight in the potential risks we’re facing. Some potential vulnerabilities were fixed. The remaining risk scenarios are sometimes so farfetched that we don’t need to do a lot in those areas.
Security Audits
A consequence of better Security awareness, is that often teams are unsure whether they are doing ‘enough’ about Security. This is not necessarily a feeling of ‘insecurity’ (pun intended), but just the awareness that it’s good to have someone else double check their choices. Our Security Guild is helping teams to do this double check by doing Security audits.
Sometimes a team wants to double check a design decision in an early stage, and sometimes they want a final check after the work is done. We’re helping them by giving a critical look at whatever they show us.
Automation
Everything that can be automated, should be automated. Fortunately, a lot of vulnerabilities can be detected automatically by doing Static Application Security Testing (SAST). One of the techniques we’re using is the Security Analysis in SonarQube. It can recognize all kinds of bad practices for us, like insecure file handling or unsafe usage of regular expressions.
We’re also automatically monitoring our dependencies. We’re using both the OWASP Dependency Check and the NPM audit for this. These tools make a list of all dependencies you use, and check them against a CVE database with known vulnerabilities (e.g. https://cve.mitre.org/). This way we know exactly how vulnerable those tools and libraries are.
Penetration tests
Apart from our own efforts on finding vulnerabilities, we also ask an external Security company to continuously scan our software through so-called penetration tests (or pentests). They do so on a daily basis using automated tools. Also, they manually test the whole thing every 3 months. These pen-testers have more of a black-box approach on our software, so they may find different issues than we do ourselves. An extra pair of trained eyes doesn’t hurt. Especially if it’s a Security company full of extra pairs of eyes.
Sometimes our customers request to do pentests on their own. Often the bigger companies have rules that say they can only work with software vendors if their software has been tested thoroughly by an independent Security company. We always require customers to inform us upfront of these tests (to prevent our Operations staff from getting alerts about malicious traffic), and ask to afterwards share the results of the test with us. This way we also keep learning. Often there are findings that don’t indicate a vulnerability, but just require explanation. If this happens, it’s an opportunity for us to explain our vision to the customer, and show that we care about Security.
Next time we’ll talk about monitoring and incident response.
Want to learn more about security? Find all our security blogs here, or check out https://careers.topdesk.com/ for job vacancies and join our Security Guild.