In an effort to enhance our awareness and effectiveness in the realm of security, we sought help from true professionals. A team from cyber security company Zerocopter, composed of Edwin van Andel (CEO), Chantal Stekelenburg, and Riccardo ten Cate kindly agreed to give us training based on the following premise: teach Media Distillery developers to use hacking tools and let them try to break into their own system!
The training we received and the practice that followed were full of valuable insights. As a developer myself, I’d like to give a short summary of the lessons learned from the experience.
I recently learned that with security, a sharp focus is not necessarily the best plan. A funny story told by Edwin van Andel was about how the management of a hotel wanted strong security for the access to their rooms, and committed to the development of an electronic lock operated through a fancy phone app. On the day the solution was presented to the public, a hacker invited for the occasion (none other than the CEO of Zerocopter, himself) managed to open the door of a room by wriggling a powerful magnet close to the locking mechanism; thus spoiling the party, of course!
The message was clear: Don’t get sucked into the details of a particular security technology/gadget; rather, focus on the scenario. The scenario of that story consists of an unauthorized user entering a hotel room. In how many ways can that scenario happen? Did you make sure that all of them are covered?
A side lesson from the story above is about the importance of being open to input about our (or your company’s) vulnerabilities. It can be troublesome to face security problems, especially if they are exposed by an external organization. If we, however, avoid these kinds of uncomfortable situations, we might end up designing security in the abstract; mechanically applying rules without any actual improvement.
One of the most important organizations active in improving software security, the OWASP foundation, maintains a document called the Application Security Verification Standard (ASVS.) This is a reference checklist, or rubric, to keep a system secure, and is exhaustive and regularly updated. The downside? It’s 60 pages long, with hundreds of items – each a potential security issue to check. Most organizations cannot find the time to manually scan the document on a regular basis to make sure that their system is up to date.
A project called the Security Knowledge Framework (SKF) addresses this problem. The authors of the project digested all the information from the ASVS and distilled it into a website which is built as a training camp for developers.
The project requires more of our attention. I’m sure the problem SKF is trying to solve is familiar to many: security is a specialization and not all software companies have in-house specialists.
I had to learn a variety of security tools, each one with plenty of configuration options. After grasping the theory, I still had to get started with finding a viable security gap in our system that I could use for an attack. There are many tools to help with your security checks – even too many – all continuously evolving over time. This is a very convenient situation for a security specialist, but not so much for a normal developer, as our end-game is building features, not exposing their security flaws. My personal advice: Try to acquire sound security principles first, and then a working knowledge of the tools. Tools change, while high level principles tend to be stable over time.
December 11, 2020
