We hear about new data breaches and other cybercrimes nearly every day. Hackers attack the weakest point and the attack is very often initiated by exploiting vulnerabilities in applications. The devil is indeed often in the software.
We live in an age of digital transformation, where more or less everything is connected to the Internet. This happens at such a speed that security is a mere afterthought, if that. All industries are affected by this trend and consumers expect that everything can be accessed via an app. Legacy systems that were never designed to be connected are now being wired directly into the Internet. Development teams who have never had to face secure development before are now developing Internet of Things (IoT) applications. Refrigerators, loud speakers, doorbells… you can even get sex toys that are connected to the internet, and they can be hacked or exploited to collect personal information about their use.
My refrigerator decided to DDOS Liberia!
So how do we move from the current state, where a fast time-to-market and adding more features is always prioritized higher by business stakeholders, rather than ensuring that their products are secure? As long as the costs of a security breach (fines, brand reputation etc.) are low, then there is no incentive for adding appropriate security controls to products. Legislation such as the EU General Data Protection Regulation will introduce larger fines when personally identifiable information is involved. However, there are still many applications, and especially IoT devices, which do not handle confidential or personal data. So why should they care about security? The problem with this is that if these applications are left unsecured, they can be used as an enabler for attacking other and more important targets. For example, an attacker can get access to your home WIFI via your Internet connected loudspeakers or your connected refrigerator can be a zombie in a botnet and used in DDOS attacks. Therefore, security should be a concern and priority for all software development to have a “healthy” IT ecosystem.
Introducing the minimum security baseline
The best solution to secure an application is to follow a secure development process and build security into every phase of the development cycle and use automated tools to check the application for vulnerabilities daily. This is however still found by many to be too costly and unsexy, compared to adding new features to the product before the deadline. However, doing little is better than doing nothing. Hence, I present here a subset of the secure development activities, which I believe is the minimum that every responsible software vendor should follow.
Software development minimum security baseline:
1. Training
Development teams must get regular training in application security. Awareness about security is the first and most important step towards more secure software.
2. Data classification
Classifying data and making the development teams aware of the classification will undoubtedly influence the daily design decisions in a more secure direction.
3. Threat modelling
Create an application threat model [2] to identify threats. The outcome of this is a list of threats ranked according to risk. All high-risk threats must be mitigated by implementing the necessary security controls. The threat model can also provide input to the coding guidelines and code review checklists that are (should be) followed during development.
4. Security testing
A security test must be made to verify that the chosen mitigations in step 3 were implemented correctly before the software is released. It does not need to be a big, costly penetration test (at least not every time). It is better to approach this in a pragmatic way, rather than leave the security test out altogether due to cost or deadlines. Less is better than nothing. I recommend using an independent security consultant in your organization or an external consultant to facilitate the security test, if possible. This can provide a fresh pair of eyes and a second opinion of the control implemented.
5. Revisit data classification and threat model
As new versions of the application are developed, please do not forget to revisit the data classification and threat model. I often see projects, which were off to a good start, but where the security awareness slowly disappeared, because the team did not revisit the data classification and threat model made several years ago.
