Research

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).