Organizations that have adopted agile methodologies place a premium on speed and efficiency. As such, they often get rid of processes (such as heavy documentation of steps, changes, and security measures) that don’t contribute directly to getting a software product to market quickly.
The thinking goes like this: With sprint cycles being a month, weeks, or even days, there’s not enough time to complete all the necessary security and governance requirements. And so developers may cut corners, with possibly damaging consequences if customer or internal data is compromised.
As the developer, you are accepting risk without full visibility into the likelihood and impact of a security incident. For organizations that are also incorporating DevOps tools, there is additional security risk. DevOps practices often increase access to the production and development environments. With more people touching both sides, there’s more opportunity for authorization creep, leading to insider attacks or inadvertent leaks.
While every area of software development, including security, is getting more automated, which reduces errors and time, security is still a process, not a tool or technology that can be automated. There’s no one thing you can do to ensure that your application is secure. It takes a comprehensive approach with layers of defense to mitigate risk to an acceptable level.
Your people are your most important asset. You need experienced technical personnel who understand application security risks, can accurately model the threat, and can implement appropriate security processes across the software development lifecycle.
Here's how to balance speed with security.
Security is a customer need
Moving to agile (and DevOps) doesn’t mean that security gets low billing. Security is a customer need and organizations should strive to cover all the bases for secure development as in waterfall days but break up the tasks so that they don’t have to do everything in one sprint. A good resource on security tasks and how to divide them into buckets is the Microsoft Security Development Lifecycle for Agile Development.
With the proper approach, agile organizations can develop more secure software because the team is incorporating security into every part of the process, not just as a final check before production. If security issues are found at later stages in the game, customers may demand that you go back and fix them, and this can be more costly than baking in security initially. That gets expensive and delays the release.
Another general rule of thumb if your code is already developed is to give more attention to high-risk code, especially if you have constraints on time and resources. Some examples of high-risk code include, but are not limited to:
- Old code—the older, the riskier
- Windows services and *nix daemons listening for network connections
- Windows services running as SYSTEM or *nix daemons running as root
- Code listening on unauthenticated network connections
- Risky application usage such as Flash, Java, ActiveX controls
- Code that processes data from untrusted/uploaded files
The most important first step for secure application development is to conduct a thorough risk assessment of the application. This will define its criticality and its impact to the business in the case of a breach or data loss event, and it will dictate the minimum level of security controls required.
Next, divide security tasks into three buckets: things that you do once before the project starts, things you do for every sprint, and things that you do regularly over the lifetime of a project but are not so critical that they should be performed for every sprint.
Here are some examples of the first two:
Security tasks completed once, at the beginning
Tasks that should be done before the project starts (after the risk assessment) include:
- Creating a baseline threat model, which helps development teams consider, document, and discuss the security implications of designs in the context of their planned operational environment and in a structured fashion
- Defining the attack surface, which will indicate what is exposed to a threat
- Creating quality gates/bug bars
- Establishing a security incident response plan
Things to do for every sprint
Developers should use multiple methods for discovering security flaws, including static code analysis early in the development process. Static code analysis tools examine the code when it’s not running and allows the developer to look for common strings of characters in the source code that can create security bugs. The benefit is that developers can write code securely from the beginning, versus finding issues much later on and needing to rewrite many layers of code. Other requirements for every sprint include:
- Performing input validation to filter incoming malicious attacks
- Updating threat models for all new features, which can determine potential security design flaws and identify at-risk components
- Depreciating unsafe functions
- Using approved tools
- Using strong encryption in new code (AES, RSA, and SHA-256 or better)
- Ensuring that all developers have had security training in the past year
- Doing regularly occurring security tasks
Periodic security tasks are those that can be rotated through between sprints, but not happen for every sprint. As you rotate through the periodic tasks, you should have completed all tasks over a certain number of releases. Just a few of these tasks include:
- Dynamic code analysis that examines the application in its running state—with this method, you can see how the application responds to certain input.
- Attack surface review to analyze what has changed.
- Review security quality gates/bug bars.
- Fuzz high-risk code that involves inputting massive amounts of unexpected random data into the application, attempting to make it do something unintended or crash and therefore identify vulnerabilities from both a security and performance standpoint.
Real rewards
The greatest myth of agile and DevOps is that due to automation and continuous integration, security can be automated. Nothing could be further from the truth, particularly in today’s connected environment of global, distributed attacks. Integrity, uptime and confidentiality must be equally important for teams. In some cases, education and awareness can help everybody get on the same page.
There’s no reason why you can’t do agile and incorporate strong security practices into development and testing. This requires planning, resources (possibly even a dedicated security testing group), automation, and commitment, but the payoff of releasing high-quality and highly secure software is priceless.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
