Security in your Agile Project (baby steps)
Written with Luiza Nunes (between 2014 and 2015)
When it comes to software security in agile projects, there are several approaches a developer needs to pay attention to when planning activities to implement security from the start and continuously.
Software security is key to ensure that no user data, in any case, is affected by malicious use. In the case of applications that involve electronic transactions, there are specific norms that aim at increasing the responsibility of service providers and preventing data leakage “accidents.”
Despite knowing how important security is, development teams often find the time and scope of a project are planned in such a way that security isn’t marked a high priority.
What can you do, as a developer, to fix this problem? How can your team ensure that the software you build is not vulnerable to malicious attacks and that sensitive customer information is not exposed or used by unauthorized persons?
Security requirements are not always properly prioritized. Deadline, scope and cost are usually variables that get in the way when security concerns come to the table.
As consultants of agile methodology, in this article we will share our ideas on how to ensure that the client understands the need of including cross-functional requirements in the scope of the project, and about how the team can work to mind security metrics from the beginning of software development.
Beyond functional requirements
Functional requirements are those which deliver business value to the client, while cross-functional requirements are characteristics of an application that do not correspond to the business functionalities but directly affect the way they are developed and used.
Flaws in cross-functional requirements can make a whole system inoperable. A flaw in the financial transaction in an e-commerce system, for instance, could cause tremendous financial loss to the client.
Quality and security, when the client’s priorities are time and cost
The image shows that smaller cost and speed are the top priorities for the client, while metrics such as quality and security are in the scale between “not important” and “desirable.”
The metrics defined as less of a priority are the ones getting less attention. Usually the clients are ambitious and want the product developed in the shortest amount of time. It is part of the strategy to minimize cost and increase profit.
We mentioned that there are norms that should be strictly followed if the system works with electronic transactions. In the case of e-commerce systems, how does one meet such standards if security has not been set as a priority from the start?
Your Team and Security
In agile projects, part of planning the project’s deadlines, time and scope involves the period of the first weeks of the project, in which the team concentrates their efforts in configuring the environment that will be used in the development of the application.
Part of configuring involves the minimum infrastructure (continuous integration environment, test environments, VPN configuration, for instance) which will enable the delivery of quality code.
Threat Modeling is an activity that helps the team to think and identify possible threats on software design. Then, these threats can be enumerated, analysed, prioritized and mitigated.
Besides that, there are many actions taken during this step that can determine the level of security that will be applied in the project. We have listed below a few actions that we think are important for mitigating the risk of security flaws:
Identify vulnerabilities using tools
These tools automatically scan the system searching for security flaws. It’s important to highlight that such tools don’t correct the vulnerabilities found — they just simulate known attacks on the system, as in a penetration test.
Attacks that are not known, on the other hand, can be mitigated through techniques such as continuous delivery and artifact repository. These approaches aim at ensuring greater reliability and minimizing risks in code applications and in possible dependencies. That way, any change considered not safe can be more easily identified.
Including frequent scanning in the continuous integration environment
The continuous integration environment is a tool commonly used in agile teams. This tool allows for monitoring the health of the system being built, running a test suite through each change the members of the team do to the code.
As with other kinds of tests, security tests should be integrated in the suite. Besides that, it’s possible to configure certain tools such as Burp to run in the continuous integration environment. Frequent runs can detect possible security problems more quickly.
If your system involves exchanging information over internet or a large network, then encrypting that information is a good security strategy. Manipulating encrypted data adds complexity to the system, and shifts the burden of keeping all data safe to keeping just the cryptographic keys safe.
In scenarios where these keys are compromised, a short-lived key approach could be used. This approach limits tokens lifetime. For example, tokens should be renewed every few days. If there is a security breach, tokens will stop to work soon and then no tokens would be reissued by any authority.
Learning from the past
Knowing the most common vulnerabilities of the application can help the team to efficiently protect the system. Every year, the OWASP, a community dedicated to the security of web applications, disseminates a list of the top vulnerabilities of software. It’s worth following.
Attention to the mandatory standards of certain kinds of systems
For every kind of system there are security standards which must be followed. In the example of the e-commerce system, which involves electronic transactions, the PCI-DSS standard should be implemented in the system.
Even more important than the list of actions above is the ability of negotiating and making sure that the client and the team are aware of the importance of implementing and taking care of security on the software.
During your negotiation of time and scope with the project’s stakeholders, make sure you discuss:
- Identifications of vulnerabilities and threats
- Risks assessments
- Possible fallbacks, outages and vulnerabilities from secondary systems
And along the development cycle, the team must be careful with:
- Security flaws in the application design
- Security bugs in the application implementation
- Security flaws in the integrated system, from end to end
- Security flaws on data transmission routes
- Outages and vulnerabilities on resources, frameworks and other secondary tools
Still in the context of security, these are some of the arguments we believe should be considered in the initial stages of a project:
- There are people who dedicate themselves to finding vulnerabilities in the system. And vulnerabilities in software are an open door for invasion attacks. Therefore, if your team doesn’t find the vulnerabilities in your system, someone will find them for you.
- Keeping the integrity of data is essential to avoid loss, be it to your business or to the final user of the system who wouldn’t like to have their data exposed and ill-used.
- Specific functionalities of your system, for instance electronic transactions, should follow security standards. Not conforming to some of those standards can mean loss to your business.
A good part of the credibility of your product is in the user experience. Such experience is definitely attached to the quality and security of the software.
It’s important to highlight that the security of a software is a requirement that should not be ignored in the negotiating of a project’s deadline and scope. This is key for the team to ensure that security is in fact attached to the product throughout the development cycle.
In addition, there are powerful tools that aid in the search for such vulnerabilities, and that can be used by the team throughout the project. Those tools are very important, and are aligned to the team’s constant care for quality. And, talking about agile projects, we associate that concern with software integration and continuous delivery.
How do you apply security in agile? Is your project really secure? We would love to hear more from you.