Security in Agile Methodology – Shaheen N Abdul Jabbar

Many large organizations are moving towards the Agile software development lifecycle (SDLC) methodology. Agile methodology is a combination of iterative and incremental process models with a focus on process adaptability and customer satisfaction by rapid delivery of working software product.

The general characteristics of any Agile methodology are:

Prioritizing feedback. Agile teams rely heavily on the feedback they get on the products they deliver.
Speedy delivery of small batches. Agile teams prefer to present their product in small iterative chunks instead of a single large one.
Team ownership. Most of the decisions are made at the team level, making the Agile team responsible and accountable for the work they complete.
Familiarity with Repetition. Agile methodologies encourage the team to repeat the process as much as possible to be familiar with it and, eventually to automate it if possible.
Inspect and Adapt. Iteration is an integral part of any Agile methodology can be seen in the development of a product as well as in the methods and processes that the teams follow. It encourages the team to adapt to new changes and challenges in an enterprise by facilitating a continuous learning culture and openness.

There are several agile methods and approaches that software development teams pick and choose for the type of products they build. Scrum, Extreme Programming (XP), Kanban, and Lean Development are some of the popular ones. Most organizations choose Scrum and Kanban as the base for its Agile methodology.

A security team should always look for ways to make the Agile team’s job easier by helping them to develop and deliver software securely. They will be an enabler for an Agile team if they follow the recommendations listed below.

The security team should be part of the agile team and be engaged as much as possible in the delivery of their product. They should be Agile to keep up with the Agile teams by thinking and acting quickly and iteratively. They should respond fast and keep learning and improving along with the development team.
A Cybersecurity Architect (CSA) should be engaged in the review of a user story before it becomes part of the product backlog of the agile team. They are encouraged to participate in the product planning sessions.
An Information Risk Manager (IRM) aligned to the line of business (LoB) should be engaged at the beginning and towards the end of each sprint.
An Application Security Champion (ASC) should be part of a sprint team guiding the developers and helping them find solutions to fix security defects in the code.
The security checks and tests must be automated so that they can be efficiently and transparently plugged into developer workflows and build pipelines
The security team should develop a Reference Architecture as a tool that enables agile teams to deliver products that are compliant with the firm’s policies and standards. The Reference Architecture would help the agile teams move fast and continuously learn and improve.

Introduction

A Software Development Life Cycle (SDLC) is a framework that defines the process used by organizations to build an application from its inception to its decommission. (Mougoue, 2016) Historically almost all organization has been using the waterfall SDLC methodology to deliver products to its customers. However, recently, enterprises are moving towards a new method called Agile that helps to deliver products to the market rapidly. This paper discusses Agile methodology and how an information security team can enable the Agile teams at various touchpoints in the method.
The paper discusses:

Agile SDLC methodology and its characteristics.
Scrum and Kanban methods in Agile.
Integration of security in Agile methods.
Security team engagements in Agile methodology
The need for a security reference architecture in Agile methodology
Selected recommendations for the information security team to enable Agile teams.

Agile SDLC

Agile Software Development Lifecycle (SDLC) model is a combination of iterative and incremental process models with a focus on process adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break a product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts from about one to three weeks and involves cross-functional teams working simultaneously on various areas like planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration, the customer and critical stakeholders are presented with a working product. (Tutorial Point, 2017)

According to the Agile Manifesto (Beck, et al., 2001), there are four primary values to be considered when considering Agile Methodology:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The signatories of the manifesto also state that “while there is value in the items on the right, we value the items on the left more.” (Beck, et al., 2001) They believe both parts of each value statement are necessary. However, they appreciate the first part more than the second. Behind the value statements are 12 principles (Beck, et al., Principles behind the Agile Manifesto, 2001) which form the backbone of most agile methodologies.

Characteristics of Agile Methods

Though there are many Agile methods, most teams that start with a well-known method end up with a hybrid one that combines two or more well-known methods.

Most of the Agile team have the following characteristics:

Prioritizing Feedback. Agile teams rely heavily on the feedback they get on the products they deliver. They look for it as soon as possible to help increase the speed at which the software is in a demonstrable state. Feedbacks also contributes to reducing barriers to communication that prevent real decision-makers from seeing the results of their decisions.

Feedback loops, where part of the output of each Agile iteration is used as input for another iteration, is also a valuable tool that the Agile team relies on. It encourages retrospectives on each iteration or continuous improvement capabilities, ensuring the process itself is adaptive and delivering value.

Practices such as continuous integration, rapid deployment, and production testing facilities are mechanisms that could speed up feedback. Such mechanisms that minimize the pathways to production and increases the chances of getting feedback as soon as possible are the hallmark of an agile methodology.

Speedy Delivery Of Small Batches. Agile teams prefer to deliver their product in small iterative chunks instead of a single large one. The delivery could be into a pre-production or staging environment rather than directly into production, allowing them to test the delivered workload with other workloads of the product. Small workloads also enable them to concentrate on a few features at a time while also working on the feedback received on a previously completed workload.

The effectiveness of an Agile team is measured in terms of velocity, which is the number of features delivered to production or a staging area. As such, an Agile team must invest time in automating their systems as much as possible to improve the team’s velocity.

Iterative Development. Because feedbacks and feedback loops are critical for Agile teams, all Agile methods are iterative. Iterative development facilitates reducing the impact of rework while giving active feedback to the decision-makers regarding the cost of the rework. For example, a Scrum team needs to estimate and prioritize any rework of a completed workload against the workloads in an existing scrum backlog.

Team Ownership. Most of the decisions are made at the team level, making the Agile team responsible and accountable for the work they complete. They are also free to find ways to improve and automate their processes and practices. It is a common practice within an Agile team to rely on an Agile coach to help them with such improvements.

Familiarity with Repetition. Agile is a new SDLC methodology and could unfamiliar to many who are still in the traditional waterfall methodology. Delivering a product almost every two or three weeks is entirely new to such teams and could be painful or awkward. To avoid such situations, Agile methodologies encourage the team to repeat the process as much as possible to be familiar with it and eventually, if possible, to automate it.

Inspect and Adapt. Iteration is an integral part of any Agile methodology can be seen in the development of a product as well as in the methods and processes that the teams follow. The iterative process requires monitoring the effectiveness of the iteration and inspecting the value delivered in each process and product. Value stream mapping, time logs, velocity, and retrospectives are some of the tools to examine and adjust each process. Though it is a change in culture from the traditional waterfall methodology, it encourages the team to adapt to new changes and challenges in an enterprise because it facilitates continuous learning culture and openness.

Agile Methodologies

There are several agile methods and approaches that software development teams pick and choose for the type of products they build. Scrum, Extreme Programming (XP), Kanban, and Lean Development are some of the popular ones. The firm where the author works have chosen Scrum and Kanban as the base for its Agile methodology.

Scrum

Scrum is by far the most popular agile methodology and is conceptually simple, and can integrate into many existing project and program management frameworks. It is prevalent among managers and senior executives as they feel they can understand more easily what a team is doing, and when they will be finished with a scrum. (Brunton-Spall, Smith, Bird, & Bell, 2017)

Each scrum project is delivered by a small multidisciplinary product development team that shares a requirements backlog. The size of the group is generally between five and 11 people, and the team usually contains developers, testers, and designers, a product manager or Product Owner, and someone playing the Scrum Master role. The Scrum Master is a team member who leads and coaches the team for a particular scrum.

Sprints and Backlogs. The product backlog or Scrum backlog is a collection of stories. Each story is a very high-level requirement for the product. The product manager continuously prioritizes work in the backlog and verifies that stories are still relevant and usable. This prioritization and verification process is called “backlog grooming.”

Each scrum team works in increments called sprints. Though traditionally a sprint is one-month long, the collective Scrum teams can decide how long each sprint should. It varies from team to team. For some, it is three weeks, and for others, it is three months. At the end of each sprint, the team stops its work, assesses the work that they have completed and how well they did it, and then resets for the next sprint.

At the beginning of a sprint, each scrum team, which includes the product manager, would look through the product backlog to prioritize the stories before selecting each story for delivery. For each chosen story, the team would provide an estimate to complete it. The stories are then prioritized before adding them to the backlog.

The estimates for each story are provided as real units of time or in relative but abstract sizing. Examples of real units of time could be two working days or 16 working hours, while examples of abstract sizing could be in t-shirt sizes as small, medium, and large. Using abstract sizing allows the team to say a story is bigger than the other, helping them to provide a much looser estimate for the Scrum Master to monitor the team’s ability to deliver on the stories.

While reviewing and prioritizing the stories for a sprint backlog, the Scrum team may decide to take out some stories and may select to add some extra ones depending on their estimate to complete each story. Sometimes there could be large stories that may need to be split into smaller ones or need to be swapped for other smaller ones instead. A finalized sprint backlog is an agreement from the sprint to complete them on time.

Each sprint agreement is reached when the product manager has completed the story prioritization for the sprint backlog, and the Scrum team accepts the prioritized sprint backlog. No stories are added to a sprint backlog while the sprint is being worked on by the Scrum team. Any new stories that occur during a sprint need to be added to the broader product backlog for prioritization and cannot be added to an active sprint. This prevents the product manager from changing the backlog in the middle of a sprint allowing the Scrum team to deliver reliably from sprint to sprint. The product manager has the flexibility to update the product backlog whenever needed and before a sprint begins. However, there is no flexibility when a sprint starts. Any feedback coming out of a sprint must be added to a product backlog and then prioritized to a new sprint.

Team cohesion is necessary for a Scrum team. For that, the team needs to be co-located if possible or should be able to collaborate virtually using tools such as group instant messaging, discussion forums, and conference calls enabling them to discuss or engage during the day. Security team members working with an Agile team should be able to participate in such collaborations. It is essential to remove barriers and encourage sharing security knowledge as much as possible to build the trust relationship between the security team member and the rest of the Scrum team.

Stand-Up Meetings. Each day of the Scrum team starts with a stand up with a short meeting called a Stand-Up. That’s where everyone in the group addresses a whiteboard or other record for the sprint stories and discusses the day’s work. For a team that is collocated, a physical whiteboard is more than enough to track their stories. The stories are represented as individual cards that move through swimlanes of state change. However, a team that is geographically dispersed should use an electronic system such as that of IssueTracker in JIRA from Atlassian to present and track stories on a virtual card wall.

The swimlanes should be organized in such a way that there should be swimlanes for Ready-to-play, In-Development, and Done. They could add extra swimlanes such as Design and Testing that represent the state of the story as needed.

All members of the Scrum team must attend the stand-up. While most of the participants are observers in the meeting, there could be a few team members who are responsible for delivering a story at the meeting. The security team member, who is a contributor to the team, participates as an observer.

Each presenter in the team answers the following questions in the stand-up:

What did you do yesterday?
What are you going to do today?
What is blocking you?

While the presenters are answering these questions, the observers are expected to be silent and not interrupt the presenter. The presenter who completed a story moves the story card to the next swimlanes and gets credit for delivering the stories as agreed. Anything that prevents the agreed delivery of a story is called a blocker.

The primary day-to-day job of a Scrum Master is to remove blockers from the team. The Scrum Master could block a story because it is ready to play or to be worked on. It is usually because of a dependency on a third-party resource or delivery from a resource outside the team. The team relies on the Scrum Master to remove blockers in the sprint.

Scrum Feedback Loops. As mentioned earlier, feedbacks are very critical for a Scrum team. At the end of each Scrum, the team gets together to spend time holding a retrospection on the completed sprint and find out what they can do better in the next sprint. Such feedback loops are a valuable source of information for security teams. The security team can learn directly from the development teams about a project and provide continuous support during the product development instead of only participating in a particular gate or review sessions.

For a product that has a significant number of security stories in the backlog, the security team member should be an active participant in the sprint instead of being an observer or just a participant in the feedback look sessions.

Kanban

Unlike Scrum, which is a methodology for building a software product, a Kanban is a method for running a high functioning team. Edward Deming developed Kanban while he worked at Toyota and Toyota Production System. He wanted to improve efficiency on the manufacturing floor, where a workstation processed from an in-queue and placed the results into an out-queue. He found that sometimes the results waited for long to be picked up from the out-queue by the next workstation and proposed a solution to avoid that. Deming proposed a system based on a just-in approach to each station, enabling each station to request (or pull) work from the previous station when it was ready for the next piece of work. (Brunton-Spall, Smith, Bird, & Bell, 2017)

The Kanban system helps to prioritize how fast a piece of work or workload would travel from the beginning of a system to the end, and the number of touchpoints it should go through. The speed of the workload is called a “flow” or the “cycle time.”

There are many touchpoints in an Information Technology (IT) environment through which a concept should go through as a workload before it gets materialized in production. Some of the touchpoints have queues where the workload has to wait for its turn to be worked on. An example is a change control board to review and approve changes to production systems. A workload may have to wait until the next change control board meeting for it to get reviewed and approved regardless of whether the workload was completed a week or a month back. Kanban systems help to solve such issues based on three essential practices – (1) Kanban Board, (2) Constant Feedback, and (3) Continuous Improvement.

Kanban Board. The Kanban Board makes the flow of workload visible. Each station in a Kanban Board has a column for in-queue workloads, in-process workloads, and out-queue workloads. These stations could be Business Concept, High-Level Design, Security Architecture Review, Detailed Level Design, Development, Quality Assurance (QA), and Deployment in a software development environment. It helps to quickly visualize the flow of workload and determine where the workloads are clustered and the bottlenecks in the system.

According to the Kanban method, a predetermined capacity of a station strictly limits the amount of workload a station can work at a time. If the capacity of a station is to work on only five workloads at a time, then the station cannot take a new workload until an existing workload is complete. The method also allows a station to pull more workload from another station if it has the capacity for a new workload.

Constant Feedback. A workload cannot move any faster than the slowest station in the system, and any occurrence of trying to push a workload to move quicker than that station would create waste or delays elsewhere in the system. By providing a tool that shows the status of all workloads to everyone in the team, Kanban is providing constant feedback on their flow and the team’s capabilities. It encourages Kanban teams to rely on each other to give feedback helping the product sponsors and stakeholders to see the current state of the systems and how long it would take a new workload to complete. The team can prioritize the workloads appropriately based on such constant feedback.

Continuous Improvement. Kanban encourages everyone in the line of production at each station to identify opportunities for improvement to speed up the process flow. Since it is easy to find the bottleneck in a Kanban process, each improvement should give an immediate boost to the throughput of the entire system. That doesn’t mean there could be a continuous change in estimated time for delivery for a well-defined mature process with a predetermined service level agreements (SLA) at each station. Such processes would not see any noticeable changes enabling the product managers to prioritize their backlog based on customer needs.

As mentioned earlier, Kanban is more about team and activity management than an SDLC process. It is most suitable for teams that look after multiple products, and where the incoming work is not predictable. Such teams include IT support teams, operational teams, and security architecture teams where the kind of workloads that come could vary in nature.

In Kanban, smaller workloads tend to move faster with increased throughput making it an ideal method for DevOps teams. Security Architecture teams could leverage Kanban by breaking down large workloads into smaller chunks to be processed.

DevOps

While Agile teams are measured on their “velocity,” which is the capability to deliver working software as much as possible, the development and operations (DevOps) teams are valued and rewarded based on system stability. As such, developers tend to think of short term goal of delivering their products as soon as possible and may cut corners. They may not think about the operational aspects of the products. However, the operations team is focused on the long term stability of the environment where the products would reside. Cutting corners could destabilize the environment and is at odds with the goals of DevOps team.

To remediate the conflicting priorities situation, the Agile team may have to maintain and operate their services themselves on the infrastructure provided by the DevOps team. If anything goes wrong in their services, the Agile team takes some responsibility for the failure. The DevOps team would be primarily seen as enablers for the Agile team.

The DevOps team could be divided into three high-level categories:

Infrastructure teams that buy and manages infrastructure
Tooling teams that build automated tooling for self-provisioning and management of said infrastructure
Support teams that respond to incidents

DevOps team is responsible for standing up services such as logging, monitoring, alerting, and patching with an Application Program Interface (API) that the Agile team can use for the products they deliver. It would be up to the Agile team to use the API the right way for their services. The increasing shift towards tooling and automation in DevOps creates significant challenges for security. While the DevOps is engaged more into tooling and automation scripts than before, the security team who were previously focused on the infrastructure side has to now think about code and software design vulnerabilities in the tooling and automation scripts.

Agile and Security

Historically, the security practices and processes were built around the traditional waterfall methodology. The requirements are defined upfront, instead of for small teams who work quickly and iteratively. However, the requirements could change every few weeks with very minimal to no documentation in Agile. The Agile team creates the design and risk management decisions just in time during each iteration. The traditional manual testing and compliance checking cannot possibly keep up with the velocity of the Agile team.

Like the DevOps, the Security team needs to evolve into an Agile enabler by finding solutions to minimize any barriers in the delivery path of a workload helping the Agile team to realize their ideas. The security team can no longer reduce risk by minimizing change. Change is inevitable in an Agile environment, and the Security team needs to adapt to it. Otherwise, the Security team will be ignored and bypassed.

To have a smooth functioning of an Agile methodology, the Agile team needs to understand and adopt security practices. They need to take more responsibility for the security of their systems, similar to how they take ownership of the operations of their services. The product owners need to understand and prioritize security and compliance requirements while giving ample time for the Agile team to adopt security practices.

A security professional should be enablers for the Agile team by managing security risks in incremental terms in an environment that keeps on changing with faster iterative processes.

The idea behind having sequential phases such as design or requirement reviews, architecture reviews, code reviews, and security testing in the traditional waterfall model is to catch security defects early on the SDLC. Though the Agile practitioners agree to this concept, they believe the focus should be on reducing the cost of fixing defects by making changes safer and easier instead of trying to catch all defects early on to fix them.

Because each Agile iteration by itself is prioritized and then worked on either sequentially or in parallel, the defects could be detected early on in each sprint, but not all at once. Each sprint would have its own code reviews and security testing to detect defects. The detected defects would be fed back to the backlog to be prioritized and fixed by the Agile team in another sprint. That doesn’t mean all security decisions should be made at the sprint level.

Some security decisions should be made before the sprint iterations start. Determining the first, second, and third layer of protection for a product should be made after performing a threat model in the design or requirements phase for the product backlog. So is the decision to pick the right platform for the product. Such decisions cannot wait for a sprint to start.

Security Team

An understanding of the various groups in the security team is helpful before discussing how a security team can engage with an Agile team. There are three types of groups in the security team that could be leveraged by an Agile Team:

Cybersecurity Architects (CSA). These are a highly-experienced group of trusted advisors on cybersecurity. Each CSA is specialized in domains such as infrastructure, platform, web applications, cloud, mobile, and IoT. The CSAs perform threat models to determine the three layers of protection required for a product. Some CSAs are individually aligned to a line of business (LoB) so that they are up to speed on some of the emerging technologies in the LoB.

Information Risk Managers (IRM). These are security risk managers who have a fair understanding of the technology with a strong risk management background. Since each IRM is aligned to an LoB, they understand the risk appetite of the business and can provide informed advice to the business on whether to accept a risk or not.

Application Security Champions (ASC). These are software engineers trained in application security. They are trained to review reports on static code scans and dynamic scans and are capable of advising the Agile teams on how to remediate the findings in the report.

Security Team Engagement in Agile Methodology

Security Engagement in Sprint

There are many touchpoints in a sprint or iteration where the security team needs to be engaged.

Daily Stand-Up. As mentioned earlier, the daily stand-up is where the current state of stories are reviewed. Since the IRM group is closer to the LoB, it is the IRM who should be listening to any issues raised that may affect security and privacy. The IRM should monitor any stories that have security importance until completion.

Coding. During the coding of a story, it would be worthwhile to have someone with a strong security background in application security available for the team to understand the reports from the static scan and dynamic scan reports. An ASC is the best resource for the team to have at this level. They can advise the team on strategies to remediate any finding in the code or application. Each sprint should have its own ASC.

Beginning of a Sprint. At the start of a sprint, during the kick-off or planning meeting, most teams walk through all of the potential stories for the iteration together. The IRM should participate in the meeting, along with the ASC to ensure security requirements are understood and applicable to each story. IRM should make sure that the team owns and understand the security implications of each story.

End of a Sprint. Towards the end of a sprint, the IRM should be in the reviews and retrospective meetings to help understand what the team has done and any challenges that they faced. The IRM may engage a CSA if necessary.

Communications. As a member of the Agile team, the ASC needs to be in constant communication with other team members to lower any barriers to interacting with the security team. ASC should be the primary liaison for the Agile team from the security team. The ASC needs to be available to provide quick and informal guidance and answers to questions through instant messenger or chat platforms, email, and wherever possible in person so that the security team is not seen as a blocker.

Tools. The best way to assure that a product is secure for productions is to perform an exhaustive set of checks. Tools like Gauntlt, BDD-Security, Snyk, InSpec, Brakeman, ZAP, OSQuery, TruffleHog, Dependency-Check, and Error Prone helps to automate such tests that were traditionally manual. Though they don’t negate the need for manual testing, most of the tests could be reliably automated and repeated with these tools. The security team should own these tools, while the Agile team should own the implementation of the tools in their pipeline. The security team is responsible for determining the appropriate tools to be used in each phase, and the Agile team should be responsible for configuring them correctly.

Security Engagement Before a Sprint

Most of the Agile teams have a product design team working in advance of the development team, working on design problems, prototypes, architectural discussions. The output of this team feeds directly into the product backlog, ensuring that the development team is primed with stories ready for the forthcoming iteration.

Security Architecture Review. A CSA should be part of this team to address secure service design, trust modeling, and secure architecture patterns for the product. Each story that goes into the product backlog should be reviewed and approved by a CSA. The CSA needs to ensure that the service the team designed enables security through the user experience. Examples of such review should include analysis of how or whether to obfuscate user details when displayed, how changes to the information are gathered, and what identification requirements are needed for specific actions. Threat modeling should be leveraged to perform such reviews. Sometimes a CSA may need to become the solution architect for a story that has security significance.

Tools. To provide security-related guidance and patterns, the CSA should leverage tools such as a wiki for documentation. Having such documentation helps for future reference and other teams as well for reference.

Security Engagement After a Sprint

When a sprint has delivered a product and is ready for production, the security team should:

Assure that the developed product is secure.
Ensure that the product would be built and deployed securely every time.

Repeatable Automated Security Checks. Any security check that would be performed before a product goes into production should be automatable, reliable, repeatable, and understandable for an Agile team to adopt them. As much as possible, the tools used for a dynamic scan should be automated and be available for repeated use. The IRM should have a way to know what features have been released in the last iteration and ensure that those new features are added to the logging, fraud detection, analysis, and other security systems.

Risk Management. Any high-risk issue found before production should be monitored closely. It won’t hurt to accept a risk temporarily if the likelihood of the risk happening before a control can be put in place in a few iterations time is very low. The IRM needs to monitor the issue until it is mitigated.

Tools. The security team should always look for ways to make the development team’s job easier by helping them to develop and deliver software securely. Examples of such help include helping the team to create effective build and deployment pipelines, helping them to come up with a simple process and tools to compile, build, test and automatically deploy the system in ways that also include security checks all along the path.

They may also provide tools for internal training, such as OWASP’s WebGoat Project, the Damn Vulnerable Web Services project or other intentionally vulnerable applications that developers can explore and test so that they can learn about how to find and remediate security issues safely.

The security team may also provide teams with hardened run-time configuration recipes and playbooks, and vetted third-party libraries and images that are free from vulnerabilities which the Agile teams can grab and use right away.

Compliance and Audit. The Agile team would appreciate it if the security team automate the tools and processes used for compliance and audit and make it available using APIs. The Agile team could leverage the APIs to integrate with their tools to perform similar tests to find issues before the audit team does.

Secure Baselines

For the Agile team to have confidence that their product meets a security baseline, the security team should provide baselines and patterns as references. The Agile team should be able to reference such baselines or patterns at each security touchpoint in the Agile lifecycle. They should be able to use the same tools and templates that the security team uses. Such references help the Agile team assert that the build meets the required level of assurance and that every new build in the future would also continue to achieve the same level.

Agile Security Team

For a large enterprise with each LoB having more than 1500 applications in production, it would be challenging to maintain a CSA or an IRM for each application iteration or sprint. To meet the demand of the Agile team, the security team should enable them with tools, baselines, guidance, and patterns. A true agile security team should measure themselves on what they can enable to happen, rather than the security issues they have blocked from getting into production. (Brunton-Spall, Smith, Bird, & Bell, 2017)

Security Tools. The security team should develop security tools that can be used by development teams to assure themselves of the security of their products. The task could be achieved by looking at the risk management tools, attack tree analysis, and Agile story tracking tools. Automated testing tools that fit into the build pipeline, and automatic dependency inspection tools would also help. The tools could also be security libraries or microservices that teams can take advantage of to solve specific problems such as encryption, multi-factor authentication, and auditing. The security team may also develop tools that can safely configure or audit the use of third-party services, such as verifying the correct use of Public Cloud Service features or validating firewall configurations.

The development team should be able to freely pick and choose the tools that fit their build pipeline. In that way, the security team can avoid the culture of compliance where the tool is never understood, and the use of it is forced upon the team. The tools should enable the development team to detect a security defect and find a solution to fix it. It should not be just for detection purpose, making the team to spend more hours finding a fix. The tool should provide guidance to fix the defect, reducing the development team’s research time finding a fix. According to a study at the University of Cambridge, developers spent 50% of their time fixing defects. (Britton, Jeng, Carver, Cheak, & Katzenellenbogen, 2012)

Documenting Security Techniques. The security team needs to teach developers good techniques that are appropriate for the firm. It should cover steps to safely configure a base web application or usage guidance for working with a cloud service provider efficiently and securely. Secure coding guidelines and code review checklists for the languages and frameworks being used would also help. Documenting standard risk lists for the kind of application that the Agile teams are working on would assist them in understanding what controls should be applied in the design and development phase. It is critical that these techniques need to be applicable, timely, and relevant.

Reference Architecture

One of the tools that would significantly help the Agile team is a security reference architecture. It should have a consistent set of architectural best practices for security architecture that is comprehensive and efficient. It should be developed by Cybersecurity Architects and be a guide to the Agile team while being compliant with the firm’s Information Technology policies and standards. The security reference architecture on technology should be a reference for development teams with proven approaches to security risks that utilize best-of-breed products and should be aligned to strategic controls development. It should reduce the team’s excessive amount of time spent on research and increase productivity while reducing the total SDLC cost.

The reference architecture should be a material that is vetted out with all Subject Matter Experts (SMEs) at the enterprise allowing architects to understand what went wrong in previous projects and how to improve them tomorrow. It should enable the firm to socialize and eventually use a common architectural vocabulary across the enterprise.

Conclusion

The combination of iterative and incremental process models with a focus on process adaptability and customer satisfaction by rapid delivery of working software helps Agile methodology to be adopted by large enterprises quickly. There are several agile methods and approaches that software development teams could choose from for the type of products they build. Scrum is by far the most popular agile methodology and is conceptually simple, and can integrate into many existing project and program management frameworks. It is prevalent among managers and senior executives as they feel they can understand more easily what a team is doing, and when they will be finished with a scrum. Kanban is a method for running a high functioning team efficiently. It helps to prioritize how fast a piece of work or workload would travel from the beginning of a system to the end, and the number of touchpoints it should go through.

The security team should always look for ways to make the Agile team’s job easier by helping them to develop and deliver software securely.

References

Agil8. (2017). Scrum. Retrieved from agil8.com: https://www.agil8.com/consulting/scrum/
Atlassian. (2017). JIRA Software. Retrieved from atlassian.com: https://www.atlassian.com/software/jira
Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Grenning, J., . . . Thomas, D. (2001). Manifesto for Agile Software Development. Retrieved August 14, 2017, from Manifesto for Agile Software Development: http://agilemanifesto.org/
Beck, K., Beedle, M., Bennekum, A. v., Cockburn, A., Cunningham, W., Grenning, J., . . . Thomas, D. (2001). Principles behind the Agile Manifesto. Retrieved August 14, 2017, from agilemanifesto.org: http://agilemanifesto.org/principles.html
Britton, T., Jeng, L., Carver, G., Cheak, P., & Katzenellenbogen, T. (2012). Reversible Debugging Software. Retrieved August 16, 2017, from citeseerx.ist.psu.edu: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.444.9094&rep=rep1&type=pdf
Brunton-Spall, M., Smith, R., Bird, J., & Bell, L. (2017). Agile Application Security. Sebastopol, CA, USA: O’Reilly Media, Inc.
Cornutt, C. (2013, March 20). DREADing your security. Retrieved from websec.io: https://websec.io/2013/03/20/DREADing-Your-Security.html
Gibson. (n.d.). Risk management. Retrieved May 5, 2017, from gibsonins.com: http://www.gibsonins.com/risk-management-solutions
Howard, P. D. (2006). Assessing Risk. Taylor & Francis Group.
Jackson, C., & Carey, M. (2005). The Role of Information Security in the Enterprise Risk Management Structure. In H. Tipton, & M. Krause, Information Security Management Handbook 2005. Taylor & Francis.
Microsoft. (2005). The STRIDE threat model. Retrieved from msdn.microsoft.com: https://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
Mougoue, E. (2016, January 21). SSDLC 101: What is the secure software development life cycle? Retrieved from synopsys.com: https://www.synopsys.com/blogs/software-security/secure-sdlc/
Peltier, T. R. (2001). Information Security Risk Analysis. Boca Raton: Auerbach Publications.
Peltier, T. R., & Peltier, J. (2004). Complete Guide to CISM Certification. Boca Raton: Taylor & Francis Group.
Rouse, M., & Cole, B. (n.d.). Risk management. Retrieved May 5, 2017, from searchcompliance.techtarget.com: http://searchcompliance.techtarget.com/definition/risk-management
Stallings, W., & Brown, L. (2015). Computer Security Principles and Practice. Boston: Pearson.
Stallings, W., & Brown, L. (2015). Computer Security Principles And Practice. Boston: Pearson.
Stephenson, P. (2009). Information Security Essentials. Auerbach Publishing.
Stewart, J. M., Tittel, E., & Chapple, M. (2011). CISSP®: Certified Information Systems Security Professional Study Guide, Fifth Edition. Indianapolis: Wiley Publishing, Inc.
Stewart, J. M., Tittel, E., & Chapple, M. (n.d.). CISSP®: Certified Information Systems Security Professional Study Guide, Fifth Edition. Indianapolis: Wiley Publishing, Inc.
TechBeacon. (2017, August 17). Scrum vs. Kanban: How to combine the best of both methods. Retrieved from techbeacon.com: https://techbeacon.com/scrum-vs-kanban-how-combine-best-both-methods
Tipton, H., & Krause, M. (2005). Information Security Management Handbook. CRC Press.
Tutorial Point. (2017). SDLC- Agile Model. Retrieved August 14, 2017, from tutorialspoint.com: https://www.tutorialspoint.com/sdlc/sdlc_agile_model.htm