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

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

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

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:

As you are likely out of the office much of today, preparing for a long weekend, I will keep this week’s summary short and to the point. Another three-star set of nits to pick. *** With Apple’s new product announcements just a couple weeks away, Wired’s Will Apple Kill Off the Credit Card Like It Did the Compact Disc? asks the wrong question. I don’t claim any specific knowledge of what Apple is thinking when it comes to payments, but I am willing to bet they would not describe their strategy as replacement of credit cards. In fact, just asking whether Apple is looking to kill off credit cards is myopic. It’s like asking if smartphones were out to kill land lines – ultimately they did, but powerful mobile handheld computers transformed many facets of daily life, including basic things like our definition of ‘computer’ and how we use information. The move to mobile payments by Apple and other platform providers is more about fundamental long-term transformation of payments to something more convenient, more ubiquitous and…probably…more secure. *** The Opportunity Cost of Automating Database Auditing should have a big NOT in the title. Not in that Borat ‘NOT!’ way, but better to consider the opportunity cost of not auditing databases as an information source. As a former vendor of database monitoring and auditing products, I always felt it would have been prudent for some of the compliance mandates to include database infrastructure in their lists of required controls. The database offers more accurate information than most other sources, and can help bypass a lot of manual work if done correctly. And certainly the repository that holds the bulk of enterprise data – relational databases have been king of the data management platforms for a couple decades – warrants some special mention. But they don’t get it. PCI? Nope. CA-1386? Nope. Basel II? Nada. Not even Sarbanes-Oxley, which is a special case given that Worldcom – one of the law’s poster children – was convicted based on analysis of database transaction records. But database auditing is not part of the requirement. The key ROI cost discrepancy is not between different kinds of database auditing – it is between database auditing and other types of auditing which require more effort for lower-quality results. *** Tim Raines wrote recently on the Microsoft blog about Major Rights Management Update to Office on Azure. This is less about user entitlements than enforcement. Look at the provided examples: it is app-layer Digital Rights Management. Yes, platform providers (such as Apple and Google) have a unique advantage as they control the cloud servers and the mobile applications that use them. In essence this offers control over who can view/use data under what circumstances, but it is more interesting when the data owner can control rights in the data management solution context. Most existing DRM options require learning third-party products, and disassociate where you set policy from where the data is managed. This is essentially what many firms are attempting to accomplish with MDM solutions and various mobile containers. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences James Arlen quoted in Cybersecurity’s hiring crisis: A troubling trajectory. Favorite Securosis Posts Adrian Lane: Shipping Decent Breach Notification. David Mortman: Respect the Hierarchy. Mike Rothman: The Data Breach Triangle. This is a classic from back in 2009. And a concept I still use in almost every meeting, so it has aged pretty well. Other Securosis Posts Incite 8/27/2014: It takes a village. Friday Summary: STEM. Favorite Outside Posts Adrian Lane: Point-of-sale malware has now infected over 1,000 companies in US. A thousand that they know about. We could reach an inflection point with mobile devices where we simply move financial transactions out of retail establishments… Which should have happened a long time ago. Rich: Trolls drive Anita Sarkeesian out of her house to prove misogyny doesn’t exist. This upsets and depresses me beyond belief. Tech overall has a problem with how we treat women, and security is no exception. I’m not saying we are any better or worse, but this is an important read to see how extreme the problem is, and to remember we are far from immune. Gunnar: Sabermetrics vs. second-hand knowledge. Mike Rothman: Netflix releases home-grown DDoS detectors. I’m digging how Netflix continues to contribute their security tools to the community. This is great for everyone. Research Reports and Presentations 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. Eliminate Surprises with Security Assurance and Testing. Top News and Posts Update on reviewing our data practices and Bugzilla development database disclosure. Did Arizona turn over its counterterrorism database to a Chinese spy? It is difficult to tell whether this is political poop-flinging or there is real evidence of crime, but an interesting discussion. Cyber attack reveals data on at least 25,000 workers at the US Department of Homeland Security. FBI investigating Russian links to JPMorgan hacking. Don’t waste time on Code Reviews. Compromised Facebook accounts create scam events. Masscan does STARTTLS. Creators of New Fed-Proof Bitcoin Marketplace. DQ Breach? HQ Says No, But Would it Know? White House Going With ‘Security By Obscurity’ As Excuse For Refusing To Release Healthcare.gov Security Details. End to End. Espionage programs linked to spying on former Soviet targets. Share:

Oddly enough my big takeaway from the Black Hat security conference was not about security – it was about innovation. It seems many of the disruptive trends we have been talking about are finally taking hold, finding mainstream acceptance and recognition. We have been talking about cloud computing for a long time – Rich has been teaching cloud security for four years now – but people seem to be really ‘getting’ it. It takes time for the mainstream to fully embrace new technologies, and only then do we see disruption fully take effect. It is as if you need to step fully into the new environment before what’s really possible takes shape and starts to manifest itself. Fo example, when the Internet hit big in 1996 or so, we talked about how this would hurt “brick and mortar” retail, but it was a good 7 to 10 years before that reality fully manifested. Only then did the change take full effect, and few industries were left untouched. We are just now reaching that point with the cloud, mobile, and NoSQL databases, and getting here has been exciting! When I talk about security analytics it is nearly impossible for me to do so without first talking about NoSQL and the value of “big data”. NoSQL enables me to inexpensively scale up to collect all the data I need. NoSQL allows me to easily pull new and complex data types for analysis. NoSQL facilitates more programmatic use of stored data, and my choice of NoSQL architecture lets me tailor a solution to analytics or real-time response. Security analytics is the goal, and you don’t need to have NoSQL, but the disruptive innovation of NoSQL makes it better and cost-effective. NoSQL has been around for a long time, but the possibilities for security analytics are only being widely considered now that most firms have taken their first steps into the new world. The same is true for DevOps, which is the culmination of several technology advancements reinforcing each other. The API economy is making the cloud, mobile, and various other services accessible. It is being driven by development teams who need to be more agile and efficient. DevOps offers virtual on-demand resources. DevOps does not depend on the cloud, but the cloud makes it better. This evolution of several pieces has suddenly created something bigger than the sum of its parts. Even better, all these new technologies build in security components. I was more amazed to see disruptive innovation manifest, but there were significant efforts to build security into each of these trends. Life will be very interesting over the next 4-5 years. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Mike quoted on context-aware security in SearchNetworking. Mike quoted in coverage of Wendy Nather as a “Power Player” in IT Security. Wendy is awesome and one of our favorite people in the industry. Mike couldn’t be happier to be quoted. Mike’s “Change Agent”: Trusted Information Systems. Mike did a blog post/video for Digital Guardian naming a “change agent” with an impact on how security has evolved… Check it out. Adrian and Mort talk Big Data with George Hulme. Mort quoted in “Communicating at the speed of DevOps”. Favorite Securosis Posts 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 that NetScout is grandstanding before I did… Adrian Lane: Butterflies. Morphing. It’s this week’s theme. Dave Lewis: Trolling Mass Media. Other Securosis Posts It’s not a problem until someone dies…. Cloud File Storage and Collaboration: Additional Security Features. Friday Summary, August 1, 2014: Productivity Metrics edition. Favorite Outside Posts Mike Rothman: Mark Twain’s Top 9 Tips for Living a Kick-Ass Life. Adrian Lane: Military Companies Brace for Rules on Monitoring Hackers. It’s one thing to disclose a breach to a partner – it’s another to let the partner conduct the forensic analysis. Most firms don’t trust their business partners enough to give them unfettered access to their systems. And the government has many interests outside supplier agreements. We will see how this shakes out. James Arlen: SEC failed to guard sensitive information. Dave Lewis: Weak Passwords: Mel Brooks Warned Us. David Mortman: Multipath TCP speeds up the internet so much that security breaks. <– Ooops. AKA stateful firewalls break multi-homed BGP if you don’t architect correctly…. Research Reports and Presentations 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. Eliminate Surprises with Security Assurance and Testing. Top News and Posts Espionage programs linked to spying on former Soviet targets. Dan Geer’s Blackhat Keynote. The Lie Behind 1.2 Billion Stolen Passwords. Is Amazon Web Services Really Down and Out? Facebook Buys Security Firm PrivateCore. 8 Patterns For Continuous Code Security. Safari for OS X gets “click-to-own” security holes patched. Tenn. Firm Sues Bank Over $327K Cyberheist via Krebs. Last Hacker Standing, Episode IV – The Last Hope. Martin’s new podcast. Snowden says NSA was responsible for 2012 Syrian internet blackout. Dead Simple Encryption. Forget encryption: Why won’t anyone build an open-source key manager? Security Kahuna Podcast: Las Vegas Edition. ERP: Protecting the pipeline by focusing on business-critical platforms. Improving Malware Detection in Firefox. Share:

I read Jim Bird’s blog consistently because he talks about stuff that interests me. He has a ton of experience and his posts are thought-provoking. And every couple months I totally disagree with him, which makes reading his stuff all the more fun. This week is one of those times, with Devops isn’t killing developers – but it is killing development and developer productivity. I think Jim flat-out misses the mark on this one. The metrics we use to measure productivity are broken. Always have been – stuff like number of lines of code and velocity. Software development metrics have always been crap. Do you really believe more code is better? Isn’t the goal to deliver quality products which include robustness, satisfaction of requirements, security, and so on? Measurements like velocity are made-up and irrelevant to our real needs. They don’t actually tell us what productivity is – all they do provide a trending indicator which sometimes tells us a change we made to the process is having an effect. If we had something better we would use it, but most development metrics are surrogates for real measures because we don’t have any good yardsticks for producing quality code. Which leads to the second point: DevOps spotlights just how broken these metrics are. It is specious to consider developer productivity as going down when the focus of developers and IT has changed to include test orchestration, deployment, and systems management. Developers scripting Chef, Puppet, Bamboo, or whatever are still working productively. Orchestration scripts are code – they are not wasting time handling operations. Writing tests scripts is still work (which developers typically don’t like) and part of the job. The goal is to automate tasks so you don’t need to manually repeat them over and over. DevOps is not the same thing Continuous Deployment. Continuous Deployment is part of it, but not the whole enchilada. DevOps allows developers to be more responsive to customer requests – not because they are chained to a pager answering support calls, but because automation and the infrastructure-first approach enables them to be. Sure, you can screw up priorities and clog the swim lanes with the wrong tasks, but that is a management issue – not a DevOps problem. I agree that not all developers like having to assume more programmatic orchestration of IT operations, and they aren’t necessarily good at it. But the key shift to take note of is that IT staff had better learn to program, or they will have a tough time finding work. The key to DevOps is automation, which means code and scripts… which is why IT needs more developer-centric skills. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian and Mort talk Big Data with George Hulme. Mort quoted in Communicating at the speed of DevOps. Dave Lewis: Digital Supply Chain (In)Security. Favorite Securosis Posts Gunnar: The Identity Cheese Shop. Direct from the ivory tower of identity architecture. David Mortman: Big Brother’s Price Tag. Adrian Lane: The DevOps-y Future of Security Engineering. Mike Rothman: Recruiting Across the Spectrum. Yup, this is mine. But I wanted to highlight it again because I think it’s an important discussion to have. We will need to start thinking unconventionally if security is going to scale to meet demand. Other Securosis Posts Incite 7/30/2014: Free Fall. All Good Things. The 2015 Endpoint and Mobile Security Buyer’s Guide [Updated Paper]. Favorite Outside Posts David Mortman: Multipath TCP speeds up the internet so much that security breaks. <– Ooops. Stateful firewalls break multi-homed BGP if you don’t architect correctly…. Dave Lewis: Canadian intelligence sweeps often intercept private data, spy document reveals. Adrian Lane: Banks Gain Scale with Cloud Issuance & Host Card Emulation. Kaushik Roy clearly articulates some of the issues around HCE and secure elements that have slowed mobile payments and mobile identity for the last few years. And I agree with his thrust that HCE will win out as banks adopt it to reduce fraud and have a viable roadmap for coming EMV standards. Mike Rothman: Symantec Endpoint Protection 0day. The guys at Offensive Security found a little issue with SYMC’s endpoint agent, allowing for privilege escalation. Though we shouldn’t beat up on Symantec too badly – it could have been anyone’s agent. These tools are supposed to reduce attack surface, right? Research Reports and Presentations 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. Eliminate Surprises with Security Assurance and Testing. Top News and Posts 0-days found in Symantec Endpoint Protection. Android “FakeID” security hole causes a pre-BlackHat stir. Google’s Android Has a Fake-ID Problem. CIA Admits Guilt, Apologizes for Accessing Senate Computers. Improving Malware Detection in Firefox. Vormetric And Rackspace Partner To Offer Encryption Services On Rackspace Cloud. Hackers Plundered Israeli Defense Firms that Built ‘Iron Dome’ Missile Defense System via Krebs. Digital Supply Chain Security: Partner Networks. Russia wants Apple and SAP’s source code over spying concerns. Incident Response Metrics. Breach index: Encryption used in 23 percent of Q2 incidents. Share:

Gunnar and I frequently comment on the fragmented nature off-premise identity solutions. For example there is no Active Directory for mobile. Cloud IAM solutions commonly use bulk replication to propagate identity, while more elegant options are seldom considered. We pointed out how fragmented the market was a few months back when I wrote about the Identity Mosaic. When discussing the problem we wondered what vendors must say to customers looking for cloud or mobile identity solutions. It struck us that we’ve seen this act before: Monty Python’s Cheese Shop! Gunnar came up with his own take on the skit and we filmed it last week. It’s corny, and we couldn’t find a bouzouki player, but it was fun! So here it is: The Identity Management Cheese Shop. Share: