Research

Now that we have laid out the Agile process it’s time to discuss where different types of security testing fits within it. Your challenge is not just to figure out what testing you need to identify code issues, but also to smoothly fit tests into the framework to help speed testing. You will incorporate multiple testing techniques into the the process, with each tool or technique focused on finding slightly different issues. Developers are clever, so development teams find ways to circumvent security testing if it interferes with efficient coding. And you will need to accept that some tests simply cannot be performed in certain parts of the process, while others can be incorporated in multiple places. To help you evaluate both which tools to consider and how to incorporate them, we offer several recommendations for designing a security “tool chain”. Pre-Sprint Tests and Analysis Threat modeling: Threat modeling is the act of looking for design-level security problems from the perspective of an attacker, and then designing countermeasures. The process enables designers and developers to think about the big picture security of an application or function, then build in defenses, rather than merely focusing on bugs. The classic vectors include unwanted escalation of user credentials, information disclosure, repudiation (i.e.: injecting false data into logs), tampering, spoofing, and denial of service. For each new feature, all these subversion techniques are evaluated against every place a user or code module communicates with another. If issue are identified, the design is augmented to address the problem. In Agile these changes are incorporated into user stories before task cards are doled out. Security defect list: Security defect tracking covers both collecting security defect data and getting the subset of information developers need to address problems. Most organizations funnel all discovered defects into a bug tracking system. These defects may be found in normal testing or through any of the security tests described below. Security testing tools feed defect tracking systems so issues can be tracked, but that does not mean they provide consistent levels of information. Nor do they set the bar for criticality the same. How you integrate and tailor defect feeds from test tools, and normalize those results, is important for effective Agile integration. You need to reach an agreement with the Product Owner on which defects will be addressed in each sprint, and which will be allowed to slide (and for how long). The security defect backlog should be reviewed each sprint. Patching and configuration management: Most software uses a combination of open source and/or commercial code to supplement what the in-house development team builds. For example Apache supports most current web services. Keeping these supplementary components patched is just as necessary as fixing issues in your own code. Agile offers a convenient way to integrate patching and configuration changes at the beginning of each sprint: catalog security patches in supporting commercial and open source platforms, and incorporate the changes into the sprint as tasks. This pre-supposes IT and its production systems are as Agile as development systems, which is regrettably not always the case. Daily Tests Unit testing: Development teams use unit tests to prove that delivered code functions as designed. These tests are typically created during the development process; teams using test-driven or behavior-driven development write them before the code. Unit tests are run after each successful build, and help catch any defects that pop up due to recent changes. Unit tests often include attacks and garbage input to verify that the application is resilient to potential issues outlined during threat modeling. The formal requirement for this type of testing needs to be included in the Agile user stories or tasks – they do not magically appear if you fail to specify them as a requirement. Security regression tests: Regression tests verify that a code change actually fixes a defect. Like unit testing they run after each successful build. Unlike unit test, regression tests each target a known defect, either in the code or a supporting code module. It is common for development teams to break previous security fixes – usually when merging code branches – so security regression tests are a failsafe. With each security tasks to fix a defect, include a simple test to ensure it stays fixed. Manual code inspection: Code reviews, also called peer review, are where a member of the development team examines another developer’s code. They check to ensure that code complies with general standards, but also look for specific implementation flaws such as unfiltered input variables, insufficient user authentication, and unhandled errors. Despite wide adoption of automated testing, about 50% of development shops still leverage manual code review for code quality assessment. Manual efforts may appear inefficient, but manual testing is as Agile as it needs to be. For example, the team chooses whether to perform these tests as part of development, QA, predeployment, or any combination of the above. The task can be assigned to any developer, on any branch of code, and as focused or random as the team decides. We recommend manual testing against critical code modules, supplemented with automated code scanning because manual scanning is repetitive and prone to errors. Manual testing can serve a very valuable security function when properly integrated, by focusing on critical functions (including authentication and encryption), using domain experts to keep an eye on that code and subsequent changes. Every-Sprint (Commit) Tests Static analysis: Static analysis examines the source code of a web application for common vulnerabilities, errors, and omissions within the constructs of the language itself. This provides an automated counterpart to peer review. Among other things these tools generally scan for unhandled error conditions, unfiltered input variables, object availability and/or scoping, and potential buffer overflows. The technique is called “static analysis” because it examines source code rather than execution flow of a running program. Like manual reviews, static analysis is effective at discovering ‘wetware’ problems: issues in code that are directly attributable to programmer error. Better tools integrate well with various

Last night I spent four hours without my iPhone. Four conscious hours, to be specific. It was wonderful. I realize that may sound strange, but I bet the majority of you reading this nearly always have a phone within hearing range, if not actively grasped in your hand or stuffed in a pocket where you obsessively check it every now and then, when the slightest breeze triggers the vibration nerves in your upper thigh. Maybe the Apple Watch will fix that last one. Unlike most of you I have been living with pagers, radios, and other on-call devices since around 1991. Due to my involvement in emergency services, I was effectively on-call continuously for years at a time. No, I was not required to show up, but between paid and volunteer gigs you just get used to always being in touch. It was also an amazing way to get out of crappy dates. But somehow my public service commitment slowly transitioned to having my phone on or near me at nearly all times. Part of this is due to my inherent geekiness, some an effect of running my own business, a smidge from being a parent, and plenty from a developed habit that isn’t necessarily the most positive psychological development. Practically speaking I do need to have my phone near me quite a bit, especially during working hours. Even when I am blocking out distractions, the folks I work with need to be able to get a hold of me if something important comes up – especially since I manage all our IT. And with a family of 5 there is a lot to coordinate. I even need it on longer workouts for safety – I run in the desert, ride my bike far from home (sometimes an hour away by car) and go on excursions in new cities. Is my phone a necessity? No, I did all that before having a phone, but I also got into some dicey situations. But that doesn’t mean it needs to be all the time. I used to catch a break when I was on mountain rescues or ski patrol. But not only do I not participate in those any more, cell coverage is far better than you would expect unless you go really deep into the backcountry. Or need to make a call on AT&T in New York City. Last night I was in San Jose for the Cloud Security Alliance conference. After teaching a developer class I met up with a friend who is also a runner (better than me). We went out for a nice four miles, and decided to grab some beer and burritos without swinging back for our stuff (she had cash). Between the run, slow service, and finding food, it was nearly four hours before we re-attached our digital leashes. This wasn’t some sort of existential event. But it was nice to be out of touch for a while, and not worry about it. And even better that it didn’t involve some massive excursion to evade cell towers. A run, two beers, a burrito, and then back home. No Yelp to check reviews, Siri to find the closest burrito, email interruptions, or text messages. We survived, as did our children and businesses. Go figure. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in USA Today on payments. Rich also quoted in The Guardian on Apple Pay. Adrian quoted on Sentrix. Not that the rest of us know who that is. Adrian quoted on Apple Pay at TechTarget. Rich on the ThreatPost podcast with Dennis Fisher. I always love talking with him. He lets me use bad words. Favorite Securosis Posts Mike Rothman: Secure Agile Development: Process Adjustments. Adapting to the situation is always challenging. Adrian and Rich go into how to adapt Agile development when things need to be tuned a bit. Adrian Lane: Firestarter: Apple Pay. Rich: Fix Something. No matter how good you are at poking holes and pointing fingers, I respect those who try to fix things more. Other Securosis Posts Incite 9/17/2014: Break the Cycle. New Paper! The Security Pro’s Guide to Cloud File Storage and Collaboration. Favorite Outside Posts Mike Rothman: And so there must come an end. Really inspiring post on handling the end of life with grace. Charley documented her battle against cancer and wrapped up the story in a way that reminds us of the impermanence of everything. Adrian Lane: OWASP Top 10 is Overrated. The author is clear that this is flame bait, but correct that the focus has shifted to the top 10, without understanding reaching beyond that simple list. The point of OWASP was community awareness, but they stumbled across what everyone in the press knows: people want distilled information. Rich: I’m picking my own post on Apple Privacy at Macworld from back in June. Why? Well, Tim Cook’s statement on privacy might be one reason. Research Reports and Presentations The Security Pro’s Guide to Cloud File Storage and Collaboration. The 2015 Endpoint and Mobile Security Buyer’s Guide. Analysis of the 2014 Open Source Development and Application Security Survey. Defending Against Network-based Distributed Denial of Service Attacks. Reducing Attack Surface with Application Control. Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7. Top News and Posts Home Depot hack may have exposed 56 million credit card numbers. I think we have our inflection point now. Ping Identity Scoops $35M To Authenticate Everywhere. The NSA Spied on German Telecoms. Chinese Penetrate TRANSCOM Amid Lack of Data Sharing. Long term penetration of US military logistics chain. Nice. Critical updates for Adobe Reader and Acrobat. Share:

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