In the next couple posts we will break down our advice for adding security into Agile development. We will do this by considering the involved people, necessary processes, and technical integrations. Today’s post focuses on helping security professionals, first by outlining how Agile development works, and then by providing recommendation for how to work with development teams.

Why can’t we all get along?

There is no point ignoring the elephant in the room – it won’t shock anyone that there has historically been friction between security professionals and development teams. This isn’t because of inherent animosity but due to conflicting priorities. Development needs to ship functioning code on time and within budget. Security needs to manage risks to the organization, which includes risks introduced by new technologies including code. One needs to go as fast as possible: the other needs to keep from smashing through the guardrails and flying off the road.

Unfortunately sometimes this isn’t expressed in the most… professional… of ways. Development teams accuse the CISO of having no appreciation for the skill with which they balance competing priorities, and view security practitioners as noisy know-it-alls who periodically show up to say “All your stuff’s broken!” CISOs don’t understand how development teams work, accuse developers of having no clue how attackers will break their code, and think the only English phrase they learned in college was “We don’t have time to fix that!” This mutual lack of understanding makes even basic cooperation difficult.

We are here to help you understand development issues and how to communicate what needs to happen to development teams without putting them on the defensive. Following are several aspects of Agile development that create friction between the two groups. Avoid these pitfalls and your job will be much easier, but you need to do some work to understand how your development teams work and how best to work with them.

Agile 101 for CISOs

Before we make specific recommendations we need you to embrace Agile itself. Agile is fascinating because it isn’t a single development process, but instead a collection of methods under a common banner. That banner is incremental improvement. It promotes faster and shorter cycles, with a focus on personal interaction between developers, working software over documentation, more collaboration with customers, and responsiveness to change. But the key to all this is making small improvements, every sprint, to improve speed and effectiveness. This is all spelled out in the Agile Manifesto.

You will need to work with the people who control the Agile process. Agile teams have specific roles and events. A Product Owner is responsible for the overall product requirements and priorities. The Development Team builds the code. The Scrum Master facilitates frequent structured meetings (Scrums), typically held daily, for 15 minutes to communicate project status formally.

Projects break down into Sprints which are one to four week coding cycles, with specific tasks – not necessarily features – to be performed. The Sprint Planning Meeting defines those goals, which are placed into a Backlog of tasks that the Program Manager prioritizes as specific tasks, typically in a ticketing and task management tool. Developers then focus on the small tasks – 2-6 hours – they are assigned. Big-picture features are called Stories, which are broken down into tasks.

Each day a developer comes in, attends the scrum, loads up his or her task list, codes, and them commits the code when the assignment is complete… so it can run through testing. Typically code is committed near the end of the sprint – but some versions of Agile, including DevOps, might have developers commit code several times per day.

The key is that sprints move very fast – usually a matter of weeks. Requirements are set up front and then everyone is off to the races to knock out particular tasks. The goal is to completely deliver the feature or function at the end of the sprint, getting it into the hands of customers as quickly as possible. This is important to get customer feedback quickly and avoid working for 2 years to deliver a feature, only to find out it isn’t what is needed at all.

Security is fully compatible with Agile – it simply needs to be integrated.

Recommendations for the CISO

Here are a list of things to do, and to avoid, as you work with development. Mostly it comes down integrating security as seamlessly into their processes as possible, without sacrificing your security objectives.

• Learn: You learned to work with HR on privacy issues, Legal on breach disclosures, and IT for compliance reporting and controls. You know how to work with executive management to communicate risk and ask for budget. Now you need to take some time to learn how development works – our research is just your starting point. Focus on the basic development process and the tools they use to manage it. Once you understand the process the security integration points become clear. Once you understand the mechanics of the organization, the best way to introduce and manage security requirements will also become evident.
• Communicate: We strongly recommend joining the team directly to hash out issues, but only when you need to. Agile promotes individual interaction as a principal means of communication, but that does not mean you should attend every scrum. In today’s development suite tools like JIRA, Slack, and even Skype facilitate communication across development teams. Add yourself to the appropriate groups within these communication services to stay abreast of issues, and join meetings as needed.
• Grow your own support: Every development team has specialists. One member may know UI and one mobile platforms; one may be responsible for tools, another build management, and another for architecture. During our most recent interviews a handful of companies explained that they encourage each team to have a security specialist, responsible for security advocacy.
• Provide security training: Training is expensive so it is essential for development to leverage lower-cost knowledge sharing options. Most organizations do in-house training, which we call “lunch and learn”. Whenever a development team member learns something new or brings new ideas back from a conference, they present it over pizza (provided by the company to encourage attendance). This is a great way to get in front of developers, educate them on security topics and – most importantly – answer questions on how to address issues. You might even consider sharing some budget to get key people the education or tools they need.
• Tell your story: A story is Agile’s fundamental unit for communicating project requirements. You may need to get your hands dirty, write security ‘stories’, and help develop task cards to describe the security work to be done. Face it – product managers don’t know security all that well, and if you really want the development team to understand what you need built, you will need to help write the stories.
• Advise: One crucial area where you can help development is in understanding both company and external policy requirements. Just as a CVE entry tells you next to nothing about how to actually fix a security issue, internal security and privacy policy enforcement is often a complete mystery to the development team. Developers cannot Google those answers, so set yourself up as an advisor to development on these issues. You should understand compliance, privacy, software licensing, and security policies at least as well as anyone on the development team, so they will probably appreciate the help.

Our next post will shift focus from people to process, discussing how to adjust process to include security analysis and testing.