Toreon Office | Grotehondstraat 44 1/1 - 2018 Antwerpen | +32 3 369 33 96
01/06/2023
Everything that is IT infrastructure has now become a commodity, so every company does this more or less in the same way. As an end customer, especially in a B2B context, you can no longer make a difference in this respect.
However, an application is different. It’s a unique experience that every company can offer to its end customers in order to create a unique bond. That’s why it is important to have the organisation build it itself. But on the security side, we see that those applications are often hacked.
According to the MITRE ATT&CK Framework, which is the leading framework in terms of threat intelligence, poorly secured applications are the most common openings for cybercriminals. While applications are perfect for gaining a competitive advantage, we see that the security of those applications often leaves much to be desired.
But how exactly should you proceed?
Security testing is a first key point. Many companies use penetration tests – or pen tests for short – to that end, during which they allow external parties to penetrate the applications.
Scoping
You can test the application very broadly or focus on specific aspects of your security.
Budgeting
You can also allocate a fixed budget to the testing and discuss outcomes with the pen tester if they find something during the testing phase. This enables you to remedy possible vulnerabilities extremely fast.
Timing
It is also possible to extend the test period or to carry out more targeted tests.
As a result, it is often the first method companies use to test software security. Pen testing is therefore considered the first defence mechanism. But it’s not enough
In the past, software projects were approached like construction projects, based on a client’s initial brief on what the end result should be. An architect then started designing, after which the construction workers would begin to build the whole thing.
Everything happened in stages, in line with the so-called waterfall model.
This is still common in the pharmaceutical industry because development must comply with regulations in the different stages. There is a design phase with a design freeze. Afterwards, the application’s code is written, and all the code is then tested. At the end of this process, a security test is performed. If vulnerabilities are revealed at that stage, a decision to launch the app anyway is often made because of the tight deadlines.
It is therefore prudent to include a few checks in advance, to ensure that the release date will not be compromised.
Nowadays, software development is agile to improve user experience, but a pen test won’t be sufficient in such cases. Especially if it’s only done once a year.
Penetration testing is therefore paramount. The objective of such a pen test is to find the weak spots in the system. Various methods and frameworks have been developed to measure and analyse software security.
Starting the implementation of security measures in the development process is recommended as early as the design phase. This makes it possible to draw up a budget at an early stage and to conduct various security tests in the development phase. This means that the security of the software can be measured, analysed and guaranteed at every stage.
The framework we use is an Open-Source framework from OWASP: the Software Assurance Maturity Model – SAMM – which is one of the two frameworks used worldwide.
Within this framework, it is also possible to work on different levels of maturity. Not every application has to reach the same maturity. You have to take the business risks into account to determine how much security there should be. Hopefully, as a company, you already know that before you start developing your app.
The functional requirements – what the software must be able to do – are decided during the design phase. These will be visible to your end-users. But non-functional requirements, such as IT security, should not be underestimated either.
It is essential to take these non-functional requirements into account at the design stage because the user takes for granted that security is built-in and only notices that this is not the case when a problem arises. That is why developers have to draw up reversed scenarios and, for example, focus on abuser stories instead of user stories.
The analogy of a house can be used to illustrate the importance of non-functional requirements. Even if you cannot actually see them, you have a problem if they have not been included. Take the example of drainpipes hidden in the wall. While it’s great to have a water supply in your shower, you obviously expect the water to be drained properly.
Is there some sort of methodology to address that?
Especially in commercial companies where there is an IT security office or someone who is responsible for cybersecurity, determining what is essential for your company is paramount. What is the minimum standard you want to meet when it comes to cybersecurity? Those are just policies laid down on paper. Having all data connections encrypted can be a requirement of an IT security office.
Based on that, software developers know, through implementation, what they are and are not allowed to do. Just think of transport encryption.
For example, if you want to add an extra layer of security because you are dealing with sensitive data that falls under the GDPR, it is important that the software developers also know how to handle and store that data and how to further encrypt it in the database.
When it comes to IT security, many developers don’t know what to do exactly.
Designing a strong architecture and defining non-functional requirements won’t cut it here.
Developers simply need to learn more about IT security. If they are pressured by the application client to deliver something quickly and they are not instructed to focus on IT security, they will do their job as efficiently as possible and deliver functional software as quickly as possible. That is why those non-functional requirements are important, because they are requirements that need to be tested afterwards to check that they are met.
The healthiest way to do this is to assess the risk level using some kind of traffic light system, in which low risks can be handled at team level, while higher or critical risks must be approved by the national or international Chief Information Security Officer (CISO).
Governance is one of the key pillars of the OWASP SAMM framework to manage and mitigate risks.
SAMM stands for Software Assurance Maturity Model and was developed to help organisations assess and improve their software security.
The healthiest way to do this is to assess the risk level using some kind of traffic light system, in which low risks can be handled at team level, while higher or critical risks must be approved by the national or international Chief Information Security Officer (CISO).
Governance is one of the key pillars of the OWASP SAMM framework to manage and mitigate risks.
SAMM stands for Software Assurance Maturity Model and was developed to help organisations assess and improve their software security.
The use of security champions is emphasised as a weighty element of SAMM governance. These are individuals on the development team who are well aware of security risks and take the lead in ensuring that all security-related activities run smoothly. Besides developers, people working in the business also need to be aware of the risks within the organisation and for web applications in general.
Privacy regulations are also important, as non-functional requirements may need to be met as a result. In the design phase, threat modeling is a good technique to identify and recommend the risks and solutions. The threat models must provide enough correct information to enable managers to decide which solutions are suitable to improve IT security.
If you are head of development in an organisation that is not yet doing threat modeling, it can be difficult to start the process. Ideally, a few security champions who already understand IT security and have enough time to focus on it within the company would attend training.
During such training, they get practical exercises, and in a perfect world a training like this would enable them to start modeling threats in their application during these exercises. This would be an ideal scenario because they would then be able to maintain the threat models.
However, setting up a threat model is not an easy process, and it is similar to learning a new programming language. Developers who program during a two-day course are not able to write complete programs independently right away. This is why they need guidance from someone who has experience with threat modeling.
Again: testing. A requirement that cannot be tested is not a requirement. We can test using various testing methods and there are different types of automated tests. Anything that can be automated can be quickly implemented in a compilation or deployment process of a software element.
There are several trends, including static analysis that looks at the source code of first-party code or self-written code.
It is also possible to examine the material of external libraries, which is the third-party code. Although this code is not written by the programmer, it also has vulnerabilities. This is what we call software composition analysis. The source code of both the first party and the third party needs to be analysed to ensure the quality and security of the software.
Dynamic testing is another option. For example, dynamic testing looks at how the software handles unexpected input, such as incorrect details in fields where specific information is expected, like data. This type of testing can help uncover vulnerabilities in the software. This is where a bit of human logic is useful and justifies the involvement of those pen testers.
Unfortunately, the above testing options are not comprehensive, because cybersecurity and cybercrime are constantly evolving and new vulnerabilities are emerging.
It is therefore essential to continuously monitor the security of the application and regularly perform a software composition analysis. The software components used in the app can become vulnerable to new threats at any time.
So, it is important not to view the security of the software as a project, but as an ongoing maintenance process, similar to the maintenance of a car. You should therefore make sure to run that analysis every two weeks.
There is no quality label for software that meets specific security requirements.
When you have software developed externally, you must assess the various parties beforehand on a cybersecurity level and carefully check how they deal with cybersecurity.
For example, ask them how they plan to secure the products they develop. How would they respond to a cyber incident and who takes responsibility when conducting penetration tests? All this should be clearly defined in advance and carefully documented in contracts, detailing both the customer’s and the supplier’s responsibilities.
When you are dealing with a party that offers both software development and cybersecurity, it is essential that the cybersecurity specialists don’t test the software themselves, as this would be like checking their own homework. Many large consultancy firms therefore collaborate with other parties to guarantee independent quality. A software supplier must be open to this. If they refuse, you should ask yourself if you really want to work with them.
Written by Laurent DupontThe CRA promotes innovation and cybersecurity in European digital products. Learn how your company can comply with applicable standards.
Written by Laurent DupontIn the fifth episode of The Wide Open, we welcome two experts, Jasper Hooft and Thomas Dejagere, who delve deeper into the…
Written by Süleyman YilmazA CISO is the last line of defence to protect your assets. What’s the CISO’s role? And what makes a good CISO?
Written by Süleyman YilmazTech companies go through 3 stages. Which cybersecurity issues do they face at each stage? We cover it all on this edition…
Written by Süleyman YilmazPlanning to develop your own application? You might want to consider the many possible pitfalls. We explain them in this article.
Written by Süleyman YilmazWant to integrate a cloud solution without a strategy? That’s risky. Check out what you need to do to grow your business…
Contact us, our software experts would be happy to assist you.
Contact us, our software experts would be happy to assist you.
