putting together a chain of gears teamwork coordination collaboration" width="1024" height="487" />putting together a chain of gears teamwork coordination collaboration" width="1024" height="487" />
Today’s hyper-competitive business environment requires organizations to move fast and stay innovative. As a result, 80% or more organizations have adopted an agile development approach. Unfortunately, this higher development velocity introduces several opportunities for exploitation by cyber criminals, especially if the software lifecycle processes are not secured.
So, how can organizations make agile development practices more security-enabled? Here are 10 principles that the ISF recommends:
Senior leaders responsible for directing agile projects must clearly define the roles and responsibilities of security activities. This includes establishing formal and informal lines of reporting, as well as project management actions such as escalation protocols, mandatory meetings, and reporting project status to security teams. This will help embed security into agile application development while fostering commitment, accountability and a constructive relationship between business IT and security reps.
Security is a team sport. Every developer needs to play their part in ensuring that code is free of security loopholes. Developers often lack the knowledge and understanding of security issues and they tend to prioritize software delivery over security matters. To empower developers, organizations must invest resources towards coaching, mentoring, and upskilling. This includes a combination of security training and awareness sessions, mentoring from senior developers, specialized agile security training events, and access to freely available resources such as OWASP, CWE, BSIMM (Building Security In Maturity Model), SAFECode, and CERT.
It’s less costly and more efficient to bake security in from the start, rather than trying to add it after the cake comes out of the oven. Leadership must establish processes that help manage information risk throughout the entire development lifecycle.
This includes agreeing on high-level application architecture from a security perspective, identifying a list of “security-critical” applications and features, performing a business impact assessment, conducting information risk and vulnerability assessments at early stages, and a process for reporting newly identified risks. Leadership should provide guidance on who owns information risk, define the process for reviewing risk, and determine how risk management decisions are made.
Use the developers’ format (user stories, software requirement specifications, story mapping, wireframes, personas, and use cases) to articulate security requirements so that developers can better understand, define, and implement security specifications.
This enables security requirements to be treated as functional requirements in the product backlog, transforming them into tasks (a.k.a. decomposition), incorporating them into requirements management tools and including them in the project’s productivity metrics (such as burndown and velocity).
Conduct regular threat modeling exercises to understand the security context of the application, to uncover aspects of the design that are not secure, to identify, analyze, and prioritize threats; to discover the most common techniques and methods used to attack the application (spoofing, tampering, denial of services, escalation of privilege), to identify which threats warrant additional security testing and most importantly, to produce strategies and solutions to mitigate each threat proactively.
Mandate developers to leverage established secure programming techniques such as pair programming, refactoring, continuous improvement/continuous development (CI/CD), peer review, security iterations and test-driven development.
This improves the non-functional qualities of the application code and helps remove programming defects that allow security vulnerabilities to be exploited. Secure programming techniques are also useful in directing developers who are inexperienced at secure methods, using new technologies like AI or low-code/no-code, developing an aspect of an application that is complex, integrating third-party applications, or meeting compliance requirements.
Get independent reviewers to perform static code analysis (review source code to analyze errors, bugs, and loopholes in the application code) and dynamic analysis (examine application behavior during execution to identify unusual or unexpected behavior). This provides assurance to stakeholders that the application meets security requirements and does not include any security vulnerabilities.
It’s usually not feasible for security teams to manually test and assess every agile iteration. This is why it is necessary to employ some type of automation that can continuously check the security of application code for defects and vulnerabilities, ensure that security-related tasks are completed consistently and methodically, analyze security events, and lessen the burden on security teams and developers. However, everything cannot be automated, and automation cannot completely replace manual testing. For example, one needs a manual review to identify logic flaws.
Create, communicate, and maintain a standard set of security acceptance criteria to confirm that an independent review of the application code has been performed; security testing has been completed; sections of code incorporated into the application are maintainable, tracked and originate from proven, reputable sources; requirements from the iteration backlog have been successfully met; all defects, including security vulnerabilities, have been addressed and any design changes that could affect security have been identified and approved.
This helps reduce technical debt, provide assurance to stakeholders and verify that security acceptance criteria have been fully met before the application code is delivered.
Agile projects typically include limited evaluation of security performance. This makes it challenging for organizations to determine whether the security of their applications meets business requirements. Therefore, it is important that organizations monitor and evaluate appropriate security metrics against an agreed set of KPIs.
Security metrics can include things like type, number, and severity of security vulnerabilities, results of independent testing, number of approved and unapproved deviations from security policy, length of time without a security breach, and other defect removal metrics.
If your development is agile, then information security must follow suit. This is why it is recommended that all organizations follow the above security principles and best practices. Security success depends on the level of collaboration and commitment between all parties (developers, project managers, executive teams, etc.). If security processes can make rapid iterations and improvements just like coding, only then can one deliver better application security and impactful changes on the ground.
