Research

This is the fourth installment of our Secure Agile Development research. Today’s post discusses one of the toughest parts of bringing security into an Agile program; process modification. The common waterfall development process has cleanly delineated phases, each of which provides an opportunity for security integration, and each security activity must be completed before moving on to the next phase. Agile includes whatever work gets done in the sprint – it does not bend to security so you need to bend security to fit Agile. Before we get started we want to note that Veracode has asked to license this content when we have finished with the series. As with all our research, our posts and papers are written independently and reflect our what we see at customer sites. That said, we’re very happy when people like what we write enough to want to use it, so we would like to thank Veracode for their support! The easiest way to grasp the process changes is to contrast a waterfall process against Agile methods. This diagram shows a typical waterfall sequence. Each waterfall step typically includes one or more security tasks. For example, the design phase includes threat modeling to see which relationships are subject to which types of threat. During development we perform static analysis or regression testing for specific vulnerabilities, Quality Assurance includes fuzzing and exception testing, and release management sets firewall policy and patches the deployment environment. Each of these security tasks must be completed before the next step in the waterfall can begin. Here is a simple Agile with scrum process diagram. The scrum period is 24 hours, and a sprint is typically 2-4 weeks. At the end of the sprint the code ‘milestone’ is demonstrated, and the next highest priority tasks on the Backlog are assigned to developers. Following are several recommendations for how to integrate specific security tasks into Agile. Agile cycles are short, and there is no direct mapping from one process to the other. We recommend the common integration points for security controls and testing. We encourage you to think about what works for you, keeping in mind that companies often have multiple development teams, and each may implement Agile differently. Architecture and Design The architecture and design phases specify intended behavior: which pieces of code are responsible for which tasks (functions), and the handoffs between different modules (communication and trust). This is where you set security policies, define intended and insecure behaviors, and model threats. Agile has no direct equivalent to waterfall’s architecture and design phases, so you need to determine the best fit based on your team’s skills. Many include threat modeling as a task within user stories, so it is just another development operation for a development team member. Others choose to model threats as the stories are written, by product managers or senior developers, baking the results into design changes that affect task cards. Both methods have pros and cons, but the key is to communicate the desired behavior. Stories describe how a product should work, so story development is a common place to include security functional requirements. The challenge is more how to communicate requirements than when in the process the communication should take place. It must be simple so developers understand what they are being asked to do. Rather than a long list of requirements try a simple state machine diagram to get the idea across. Clear examples of what you want and what to avoid are best. Simpler is usually better. Product Management and Task Prioritization The Product Manager or Product Owner assigns tasks. Their responsibility is to manage incoming features or Stories, break work down into manageable tasks, and prioritize them. They often have the least security knowledge on the team. The issue is less which security tasks to put into the backlog and prioritization phase, and more getting the Product Owner to track security issues and get the tasks onto the queue despite competing priorities. We recommend working with Product Management to assign tags/labels to security tasks and vulnerabilities so they can be tracked like any other feature or bug. Balance security against other development tasks. Product management has a tendency to starve security tasks off the queue in favor of new features, while security people must resist labeling all their work as critical. If you integrate security into user stories, agree on reasonable priorities for different types of security bugs, and have tools to track security work, your working relationships with product owners will improve. Development and Debugging Development teams have not always been tasked with debugging their own code. In the waterfall days Quality Assurance teams were often handed completely untested code. One key area Agile helps address is developers ‘dumping’ code, by requiring verification that code performs its basic function before QA accepts it. Many organizations now require developers to write test cases to verify that submitted code accomplishes its required functions. Some Agile teams take this seriously, giving developers a task card to write tests before a task to code a new feature. Speed and efficiency are key requirements, so these tests become part of the automated build process – which automatically rejects code if it does not pass acceptance tests. Our recommendations are to make security requirements and tests part of the story, but to select small items that quickly help identify whether code passes or fails to meet requirements. You will not get complete testing in this phase, so don’t bother asking. For new features you want the developer to understand the core security requirement, so have them construct acceptance tests to get an early idea of whether they are on track. For vulnerabilities and flaws ask for security regression tests to be included with the fix to ensure the mistake is not repeated. Stick to one or two simple tests to validate the specific need and leave the rest for later. If your organization automates static testing during the development phase you will need to integrate results

The NFL has had a tough week. The Ray Rice stuff I mentioned last week. And uber-running-back Adrian Peterson deactivated on Sunday, due to a child abuse indictment. The stories are terrible, especially given that NFL players are explosive athletes and trained in violence. No kid or spouse has a chance in the face of an angry NFL player. And no, I’m not going to anywhere near Floyd Mayweather on this topic. Peterson’s excuse was that he was just disciplining his 4 year old, just as he was disciplined as a child. With a switch, which is evidently a thin tree branch. Of course we are hearing about switches and abusers because these high-profile athletes make millions a year. They are human. They make mistakes, regardless of their bankrolls. And like everyone else (including you and m), they are defined by their experiences. I’m not making excuses – what they have done is not really excusable. But the real point isn’t about suspending or pushing Adrian Peterson, Ray Rice, Greg Hardy, or Ray McDonald out of the league. It is about trying to figure out how to break the cycle. Many of these people grew up in abusive environments. That is all they know, and they think it is the way to get results. Peterson’s public statement indicates he has worked with a counselor to learn other techniques for disciplining children. That’s good to hear. It doesn’t heal the scars on his son’s legs or psyche, but it’s a start. No one teaches you how to be a parent. There is no curriculum. There are no training courses, besides child CPR and maybe changing a diaper. You figure things out. You do what you think is right. If you don’t like how you grew up, maybe you decide to do things differently. Or maybe you do the same because that’s all you know. Abuse of any kind is terrible and exacts a toll over generations. Yes, we should punish those responsible, but we also need to address the root causes if we want to change anything. That requires education and support for parents at risk of abuse. Given the prevalence of online education and training, there is a better way to do this, and the Internet is a part of the answer. At some point someone will figure it out, and we’ll all be better for it. Until then you can only feel bad for the people (especially kids) on the other end of the switch. –Mike Photo credit: “Little 500 Wreck 2005” originally uploaded by Lambda Chi Alpha Fraternity The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. September 16 – Apple Pay August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling May 5 – There Is No SecDevOps April 28 – The Verizon DBIR Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Secure Agile Development Working with Development Agile and Agile Trends Introduction Trends in Data Centric Security Deployment Models Tools Introduction Use Cases Newly Published Papers The Security Pro’s Guide to Cloud File Storage and Collaboration The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Incite 4 U Living to fight another day: Given the inevitability of breaches, as a security professional you will come into contact with PR/media spin doctors at some point. Probably sooner rather than later. They may be external folks with fancy cards which say crisis communications, but odds are they don’t know much more than you about dealing with a security breach. Kellie Cummings has a great primer of things to remember, highlighting issues like slow response, lack of candor, missing transparency, mismanaged expectations, and imprecise statements that undermine trust… and trust is critical for crisis communications. So don’t be afraid to share your opinion when you know the spinsters are screwing up. Not to be melodramatic, but your job might depend on it. – MR Radicals: Most people, if presented with a plate of common food additives would not willing put any of them in their mouths. You might even think you were being poisoned. But invisibly embedded in food, you have no idea any nasty stuff is there, and you consume willingly. Browsers are the same way – if you looked closely at how many ways a browser can scrape user, machine, and session data you would be appalled. Likely you would ban these things from your firm. But personal data silently and invisibly exploited by marketing and analytics firms gets a pass, and since we cannot detect attackers leveraging them nobody is willing to rock the boat. Enterprise IT folks spend tons on anti-fraud, malware, and phishing detection products – and millions more to control BYOD – but on browser security settings and plug-ins? Not so much. Which is why I was shocked to see

After a short break, the boys are back and here to talk about Apple. No, not the new wrist-mounted toy, but the first mobile payment system you might actually use. Or so says Rich’s Macworld editor, based on his article title. The audio-only version is up too. Share:

Once again Wendy kills it with How to Help, saying things many of us probably think. Daily. It can get frustrating when all you hear is one person after another bitching about what’s wrong with security. And as she correctly points out, there are tools aplenty to tell you exactly how much work you have to do. But that doesn’t really help. None of this is actually fixing anything. It’s simply pointing out to someone else, who bears the brunt of the responsibility, “Hey, there’s something bad there, you really should do something about it. Good luck. Oh yeah, here, I got you a shovel.” Her message is complain less, do more. And I agree. Wendy then runs through a list of things you could do. All of them require work, and most of us don’t have a lot of time for side projects. Of course she has an answer for that as well. And if you’re just about to say, “But that takes time and effort, and it’s not my problem,” then at least stop pretending that you really want to help. Because actually fixing security is hard, tedious, thankless work, and it doesn’t get you a speaker slot at a conference, because you probably won’t be allowed to talk about it. Yes, I know you don’t have time to help those organizations secure themselves. Neither do they. Naming, shaming and blaming are the easy parts of security – and they’re more about self-indulgence than altruism. Go do something that really fixes something. Amen. Really great post. One of those I wished I’d written myself. Photo credit: “The Fix Is In” originally uploaded by JD Hancock Share:

You read the series, now it’s time to download the collected works. Okay, maybe you read the series of blog posts. And by “collected works” I mean “white paper”, but you get the idea. This is one I wanted to do a year or two ago, but the market wasn’t ready. Fortunately the services have advanced significantly and enterprise adoption is rapidly increasing. Before I link to the paper, an important note. I call these Cloud File Storage and Collaboration services, but Enterprise File Sync and Share is more commonly used. Sync and Share is limiting as a term, and includes non-cloud options I don’t consider in this paper. So I broke my usual rule and used a not-quite-universally-accepted term – hopefully I won’t regret it later. This paper covers all the basics: how they work, core security features, and advanced security features. You can download the paper here: The Security Pro’s Guide to Cloud File Storage and Collaboration (PDF) Landing Page Thanks to Box for licensing the content. Share:

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

One day will be a business school case study how NFC went from handset (started with Nokia) to telcos to banks (HCE) and then to platforms Tweet by Dave Birch @dgwbirch, who I think nailed it. Apple Pay is a big deal. Most people were more interested in the new iPhone, and the not-really-surprise announcement of an iWatch Apple Watch (see this if you don’t know why that’s funny). But as a payments geek, all I wanted to know about was the rumored Apple Pay capabilities from the iPhone and Apple Watch. What I found funny – both before and after the event – was hearing negative comments that secure mobile payment and mobile wallets are not new, they’ve been around for years, and Apple is a bunch of dorks for hyping old technology. All of which is true, but it completely misses the point! The basic technologies for secure mobile wallets and NFC payment systems have been around for years. There have been fully functional service from major firms for at least four years. There have been mobile wallets, leveraging secure element/NFC technology, outside the US for several years. One of the people who runs Google Wallet tweeted Dear iPhone 6 users: Welcome to 2012! That’s not just sour grapes – there is fact behind it. Here’s the thing: A behind-the-scenes turf war has prevented most major players from supporting earlier solutions, so nothing achieved critical mass. The major cellular carriers saw the NFC/secure element bundle, which does the heavy lifting for secure payments, as their own domain. To access ‘their’ secure element they wanted their pound of flesh: payment each time an application on the mobile phone accessed the secure element. That pushed the financial players (including banks, card brands, and payment networks) to look for more open alternatives. Their hopes hinged on HCE, Host Card Emulation – essentially a virtual secure element. I won’t dive into the technical issues around some deploying these solutions, but there are drawbacks. And the people who build HCE’s and wallets wanted their own piece of the pie. Google, for example, wanted user data and purchase history to feed their big data machine. For security and privacy reasons this was a non-starter for many banks. As a result, great pieces of technology have been waiting on the sidelines while the players bickered over who got what. My point is that only Apple could carry this off. Most firms can’t do what Apple can: dictate a single consistent secure element architecture for all devices, and consistently deploy the right bits onto the elements. And only Apple appeared willing to provide enough benefits for the major players in the payment space – without injecting unacceptable customer data requirements – to reach critical mass. Fanboi or hater of all things “Crapple”, you must give them credit for putting together a very well-conceived solution. From the video of the event it looks like the Apple Watch and the iPhone 6/6+ will each have a ‘secure element’ bundled with the NFC antenna – not a new technology, already deployed in parts of Europe, but not really mass market previously. The Apple Watch will leverage skin contact to support identification, and the Touch ID fingerprint scanner on the iPhone – again, the technologies are not new, but have never been mass-market. They will abstract the credit card/PAN with a surrogate identifier – we call that tokenization here at Securosis, and it is not new technology either. What I think is new – as least this is the first time I’m aware of – is a major firm is respecting the privacy and security of users. No, Apple is not doing this for free either. The banks and payment networks are willing to pay Apple for the reduction in payment fraud, as it has been announced that they will receive transaction fees from some partners. During the next two years the majority of Apple devices will not include secure element capabilities, but within 5 to 10 years will be a very big deal, as the majority of the Apple ecosystem offers secure and private payment. Mobile payments are not really that much easier to use than their plastic counterparts, so it can be hard to see why banks see mobile payments as such a financial lubricant, but I expect it to enable new kinds of commerce. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Dave Lewis on Apple Pay. Mike quoted on context-aware security in SearchNetworking. Favorite Securosis Posts David Mortman: Secure Agile Development: Agile and Agile Trends. Adrian Lane: Shipping Decent Breach Notification. Mike Rothman: Suing Gartner. I’m surprised I didn’t get more comments on this post. Kind of counter-intuitive. Unless maybe it’s not and everyone else figured out NetScout’s grandstanding before me… Other Securosis Posts Incite 9/10/2014: Smile and Breathe. Summary: Seven Year Scratch. Feeding at the Data Breach Trough. PR Fiascos for Dummies. Secure Agile Development: Working with Development. Secure Agile Development: Agile and Agile Trends. Secure Agile Development: New Series. Favorite Outside Posts David Mortman: J-Law Nudie Pics, Jeremiah, Privacy and Dropbox – An Epic FAIL of Mutual Distraction. Gunnar: Why Isn’t Apple a Leader in Security? Chris Mims’ question question is fair but deserves some context. On devices, Apple already is a leader in security, they are light years beyond Android and competitors in most security capabilities and have a way better track record in the field to show for their efforts on devices. But what about the Cloud? We haven’t the same kind of technical leadership here from Apple, and with so much user data being stored and used there, the time has come for Apple to be a security leader on the server side, too. Gunnar: “Innovation is alive and well at Apple. You can scream it from the rooftops.” That from Tim Cook, who later went on to announce three products that are iterations of products widely available in the market for many years (payments, watch, large screen phone).

Last week I mentioned how excited I was for the NFL season to be starting. I took the Boy to the Falcons’ home opener and it was awesome. It was a great game, and coming away with a victory in overtime was icing on the cake. As predicted, my voice was a bit rough on Monday from screaming all day Sunday, but it was worth it. I don’t think my son will ever forget that game, and neither will I. Of course, I was expecting Monday to be all about the big victories. Who would have expected Buffalo to beat the Bears at home? Not me – I picked Chicago in my knockout pool, and was promptly knocked out. I’m like Glass Joe I get knocked out so early and often. At least that game happened during the Falcons game, so I wasn’t bothered to be setting $20 on fire. Again. And the Dolphins beating the Pats? Another surprise. But the Monday news cycle was hijacked and dominated by the Ray Rice video. I will not link to it because it’s disgusting. The Ravens cut ties with the guy and now he’s suspended by the NFL. All of which is deserved. Can he rehabilitate himself? Maybe. Can he and his (now) wife work it out? Maybe. Was this an isolated incident, totally shocking and surprising to the people who claim to know him? No one knows that. All we know is that at that moment in time, Ray Rice was a wife-beater. And he’ll suffer the consequences of that action for the rest of his days. But let’s take a more constructive view of the situation. How did he get so angry as to strike the person he claims to love the most? What could he have done differently to avoid finding himself in that situation or role? I don’t have any experience with domestic violence. I don’t let the Boy hit his sisters, no matter what they do. But I do know a thing or two about anger. Anger (and my inability to manage it) was my catalyst to start moving down the mindfulness path, as I described in my RSA talk with JJ (link below). I am not going to preach the benefits of a daily hour of meditation. I won’t push anything except a little tactic I have learned, to both help me be aware of my increasing frustration, and to stop the process before it turns to anger and then rage. When I feel my fight or flight instincts kicking in, I smile and then take a deep breath. That brings my awareness out of the current stressful situation and lets me take a step back before I do something stupid. It allows me to sit with my frustration and not allow it to become anger. If it sounds easy, that’s because it is. It takes discipline to not take the bait, but it’s easy to do. Of course this is not the right approach if you are being chased by a lion or an angry mob. At that point your fight or flight instincts are right on the money. But as long as your life is in no danger, a smile and then a deep breath work. At least they do for me. You will get strange looks when you break into a smile during a tense situation. Folks may think you are crazy, and may get more fired up that you aren’t taking them seriously. I don’t worry about what other people think – I figure they prefer a smile to a felonious assault. We all need tactics to handle the stress in our lives. Figure out what works for you, and make it a point to practice. The unfortunate truth is that if you do security you will have plenty of opportunities for practice. –Mike Photo credit: “[077/365] Remember to Smile” originally uploaded by Leland Francisco The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the conference this year. You can check it out on YouTube. Take an hour and check it out. Your emails, alerts and Twitter timeline will be there when you get back. Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and.. hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail. August 18 – You Can’t Handle the Gartner July 22 – Hacker Summer Camp July 14 – China and Career Advancement June 30 – G Who Shall Not Be Named June 17 – Apple and Privacy May 19 – Wanted Posters and SleepyCon May 12 – Another 3 for 5: McAfee/OSVDB, XP Not Dead, CEO head rolling May 5 – There Is No SecDevOps April 28 – The Verizon DBIR April 14 – Three for Five Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. The Security Pro’s Guide to Cloud File Storage and Collaboration Additional Security Features Core Security Features Overview and Baseline Security Introduction Trends in Data Centric Security Deployment Models Tools Introduction Use Cases Understanding Role-based Access Control Advanced Concepts Introduction NoSQL Security 2.0 Understanding NoSQL Platforms Introduction Newly Published Papers The 2015 Endpoint and Mobile Security Buyer’s Guide Open Source Development and Application Security Analysis Advanced Endpoint and Server Protection Defending Against Network-based DDoS Attacks Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Incite 4 U Pay Apple: With Apple’s announcement today of Apple Pay, they have now released some details of how their payment architecture will work. Yes, it’s a

If you are a developer reading this series, you probably have a feel for what Agile development means. For those of you who don’t live it every day, or have read the exceedingly poor Wikipedia page on Agile software development, you are probably wondering what this is all about. In the simplest terms, Agile software development is a set of techniques for building the intended software with fewer errors and better predictability. Each technique is intended to address common failures in ‘waterfall’ development: complexity, poor communication, and infrequent code validation. So Agile approaches embrace simplicity of task, fast turnaround for smaller pieces of working code, and a preference for human interaction over email/document/process oriented interaction. Simpler tasks make it harder for developers to misunderstand what the code is meant to do. Faster iteration produces working code more often, with three distinct benefits: early confirmation that you are building the correct solution, quicker detection of breakage, and more accurate project completion estimates. Face-to-face human interaction helps clarify what everyone on the team is building, and greatly reduces communication errors – which are far too common with ambiguous documentation and code specifications. Smaller, simpler, and faster. The most popular flavor of Agile today, by a large margin, is Agile with Scrum. Each characteristic of this approach has been selected to support agility. For example short development ‘sprints’, typically 1-4 weeks, are used rather than the 18-month cycles common to traditional waterfall development. Agile with Scrum relies on daily ‘scrum’ meetings, where all the developers meet face-to-face to discuss what they will be working on that day. Developers receive their tasks on 3×5 cards, which quite effectively limits task complexity. Each sprint focuses on iterative improvements rather than complete feature delivery. This ensures that only functional code modules are checked in – unlike waterfall where every feature is typically crammed in on deadline. If you need more information, Ken Schwaber’s book Agile Project Management with Scrum is the best reference we have found, so pick up a copy if you want detailed information. So why do security professionals care? Because development has shifted focus to smaller, simpler, and faster – effectively excluding slow, indeterminate, and complex security tasks. Over the past 15 years development processes have evolved from waterfall, to rapid development, to extreme programing, to Agile, to Agile with Scrum, to the current darling: DevOps. Each evolutionary step was taken to build better software by improving the process of building software. And each step embraced changes in tools, languages, and systems to encourage Agile processes while discouraging slower and cumbersome processes. The fast flux of development evolution deprecated everything that did not mesh well with the new Agile model – including security. Agile got a bad rap with security because the aspects that promoted better software development (in most ways) broke conventional approaches to building security into code. There are several areas of conflict. Tests that do not fit the Agile process: The classic example is development teams moving to a 2-week Agile ‘sprint’, when security relied on 2 months of automated fuzz testing. Security data that does not integrate with development systems: The classic example is external penetration testers who identify thousands of instances of hundreds of vulnerabilities, then dump unexplained findings onto development teams, who have no idea what to do with the results. Security tools that do not integrate with development realities: The classic illustration is testing tools which required 100% of code, with all supporting libraries, to be fully built before tests can be conducted. This prerequisite breaks small iterative code changes, delivered weekly or daily. Insufficient knowledge: Just a few years ago most developers did not understand XSS or CSRF, and when they did, it was unclear how these issues should be addressed across the code base. Understanding threats and remediation were not common skills. Getting security into the work queue: The move from waterfall to Agile meant the removal of specific security testing phases, or ‘gates’ in the waterfall process. For security features or fixes to be integrated, they must now be documented as tasks, and then prioritized over other features – otherwise security gets ‘starved’ off the development queue. Policies: A big book of security policies, vulnerabilities, and requirements is extremely un-Agile. One of waterfall development’s most serious issues is large complex specifications that confuse developers. Agile development is an effort to protect developers from such confusing and unwieldy presentation of essential information. During this amazing period of advancement in software development, we have seen an equally amazing evolution among hackers and attacks against applications of all sorts. Security has largely remained static, but there are plenty of ways to integrate security into software development, provided you are willing to make the necessary adjustments. Our next post will help you do so. Share:

Back in 2009 Rich and I wrote a series on Building a Web Application Security program. That monstrous research paper discussed the new security challenges of building web applications, outlining how to incorporate security testing for specific types of web development programs. That research remains relevant today but issues of how to incorporate security into software development organizations – and most acutely into Agile development – remains a constant problem for clients. Knowing what tool to use and where does not address the fundamental issues of culture, goals, and process that make secure code development such a challenge. We have discussed many of the pitfalls of integrating security into Agile processes in the past, but never gone so far as to help security practitioners and CISOs learn to work with development teams. And that is about to change. Today we start a new research series on Secure Agile Development. Embedding security into development processes is hard. Not because developers don’t care about security – the majority of developers we speak with are both interested in security and would like to address security issues. But developers are focused on delivery of code, and spend a good deal of time trying to get better at that core goal. Development processes have undergone several radical evolutionary steps over the last 15 years, with tremendous efforts to deliver code faster and more efficiently. Agile frameworks are the new foundation for code development, with an internal focus on ruthlessly rooting out tools and techniques that don’t fit in Agile development. That means secure development practices, just like every other facet of development, must fit within the Agile framework – not the other way around. Our goal for this research is to help security professionals understand Agile development and the issues developers face, so they can work together better. We will discuss rapid development process evolution, feature prioritization, and how cultural differences create friction between security and development. Speed and agility are essential to both sides; tools and processes that allow security issues to be detected earlier, with faster recovery, are beneficial to both. We will offer advice and approaches on bypassing some of the sticking points, and increasing the effectiveness of security testing. The structure of this series will be as follows: Agile and Agile Trends: We will start by highlighting several key trends in development today, including the evolution of fast-flux development processes. We will offer a very basic definition of Agile development. We will use it to show both why security and development teams don’t easily mesh, and how Agile development gets a bad reputation for security. We will also shed some light on how the cloud and mobile devices add new wrinkles to application security, offering suggestions for how to “skate to where the puck is going”. Working with Development: Next we will discuss how security can work well with development, and how best to insert security into the development process to work more closely with development teams. We will list many of the core friction areas and how to avoid common pitfalls. We will discuss how to share information and expertise – with a particular focus on how external stakeholders can best support development teams within their process, including discussion of information sharing, metrics, and security training. Integrating Security into Agile: After considering how best to work with development, we will take a more process-oriented look at integrating security into Agile development. Agile may lack the neatly delineated architecture, design, QA, and implementation phases of waterfall development; but each of these remains a core development task, and an opportunity to promote secure software development. We will discuss functional security requirements, security in the context of different development phases, use of security stories, threat modeling, and prioritization of security among the sea of development tasks. Tools and Testing in Detail: We have covered the people and process aspects of Agile, so here we will consider some that automate security efforts. Every development team relies heavily on tools to make their job easier. Security testing tools are even more critical because they both make identification of defects easier; and also automate discovery, reporting, and tracking. Few developers are security experts, so we discuss which tools and testing methodologies fit within the various phases of the development process. We will cover unit tests, security regression tests, static and dynamic analysis, pen testing, and vulnerability analysis. We will discuss how these efforts are integrated with Agile management and bug tracking tools to help define what a legitimate security toolchain looks like to cover relevant threats. The New Agile – DevOps in Action: We will close out this series with a glimpse of where development trends are headed. We will offer our perspective on what DevOps is, why it helps, and how automation and software defined security weave security practices tightly into software delivery. We will discuss usage of APIs, as well as policies and scripts to automate continuous integration and continuous testing efforts. Next up: trends in Agile development. Share: