Briefly on Architecture, Extreme Programming and Security Testing
Agile has become more and more well known in today’s software development world. And this has happened because it offers more benefits to the businesses that are considering becoming agile.
But some topics are not discussed as often as they should. One of them is how to handle security in the new agile context. Of course, the consultant’s answer would be: “The team will decide the best solution possible”. We want to offer our view on this topic based on experience. We will introduce the concept of security testing, then we will talk a bit about Agile and how it can deal with security testing, then we will offer some tooling and a conclusion for best practice.
First of all, let us understand what security testing is. A quick definition would be: “Security testing is a process to determine that an information system protects data and maintains functionality as intended.” [Source]. This is quite a generic definition, so, going more into detail, the same resource tells us that when we speak about security testing we are dealing with: confidentiality, integrity, authentication, authorization, and non-repudiation. These are the areas that need to be covered when performing security testing for a software product. But how do they relate to Agile? The answer to this question would be how to put these theoretical concerns into practice as early and often as possible.
Thinking up front as risk management
Agile software development is based on the concepts of iterative and incremental development. This is often interpreted as starting building a software product without any actions beforehand. This view is incomplete, as we often need some thinking and planning before we write the first line of code. We should think about defining a minimal architecture and communicating it well to all the stakeholders, including the non-technical ones. A very important part of architecture is security. We should think about our product, how sensitive the data is, and how the security risks can be minimized. This analysis is very difficult because each application has its own needs and concerns. This is why we need to take the time to find the best approaches for our situation.
Some agilists will think at this point: “So you want to do big design/ architecture up-front in Agile?” Nobody ever said that you should not define architecture in an agile environment; just that it should be minimized to avoid Big Design Up Front. We should not choose to stay in the dark because it will increase the development risks.
The creation of this initial architecture is the very first time we should think about security. A good approach is to gather security experts, testers, programmers, and architects together and decide on the best approaches and tools to use. We have found it very useful to follow a simple process for identifying security risks:
- Present the STRIDE model.
- Brainstorm the risks for each of the STRIDE categories (Spoofing, Tampering, Repudiation, Disclosure, Elevation of Privilege).
- Set a score for impact and probability for each risk identified
- Define an action plan for each risk. Typical plans are: add new guideline (e.g. all personal data should be encrypted), modify architecture, use legal measures (e.g. special clauses in contracts with hosting provider) or do nothing (e.g. if the probability is very low).
- Define a contingency plan to deal with the risk if it happens. This needs to be done with the operations team. The risks and guidelines are then communicated to developers who include them in their “Definition of Done”.
Back to security testing
An agile team is a learning machine that continuously improves the skills of its members. If security is not a core competence of the team, this is the moment to find out and take measures. We could find a good security testing workshop, find a coach, or make sure we take the time to learn from each other if the knowledge exists in the team. From this initial meeting we already have an idea of the learning activities we need to perform during the first iteration. Starting to perform security testing involves making decisions. The first one is: do we test outside-in or inside-out? The answer is: yes.
When you test inside-out you have access to the source code and you can understand the attack surface of the application by using static analysis tools on the source code. The tester should try to have a destructive approach, having all these information to hand. If you try outside-in testing you need to understand how an attacker’s mind works. The tester should try to find exploits and vulnerabilities by reading the news and all the latest updates from the platform or frameworks the application is using. Again, we should take the time and energy to learn a lot about this topic as it is a very fast-changing area.
A flavour of extreme programming
One of the most well known agile methodologies is extreme programming or XP. XP gave to the programming world concepts used today even in non-agile contexts. One of the lessons, and my recommendation, is to implement automated tests and a form of continuous integration system that allows checking of specific security issues.
This is the only sustainable way we know to make sure that changes to an ever increasing code base do not affect security in the areas already tested.
Communities of practice
As we said before, Agile is a learning machine. Knowledge about security and security testing should be spread inside all the teams working on security-sensitive products. A good way of doing this is by creating internal communities of practice on security and security testing.
In addition, external communities are beneficial to your knowledge. Find out if there are people in your city or area that know more about security and meet up with them. If a group already exists on this topic then it is very easy to find interested people. If not, create one and start learning from each other.
Security testing is easier in Agile
An agile environment brings benefits to your product from the security and security testing point of view. Architects and testers meet before the development starts in order to understand, document, and communicate the security risks. Developers understand the risks and include them in the “definition of done” to make sure that their code stays secure. They also implement automated security tests that validate known vulnerabilities. The testers have the freedom to continuously learn about the subject and they check for security issues. All these aspects come together to create a healthier product and a more profitable organization.