Research

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

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

In the next couple posts we will break down our advice for adding security into Agile development. We will do this by considering the involved people, necessary processes, and technical integrations. Today’s post focuses on helping security professionals, first by outlining how Agile development works, and then by providing recommendation for how to work with development teams. Why can’t we all get along? There is no point ignoring the elephant in the room – it won’t shock anyone that there has historically been friction between security professionals and development teams. This isn’t because of inherent animosity but due to conflicting priorities. Development needs to ship functioning code on time and within budget. Security needs to manage risks to the organization, which includes risks introduced by new technologies including code. One needs to go as fast as possible: the other needs to keep from smashing through the guardrails and flying off the road. Unfortunately sometimes this isn’t expressed in the most… professional… of ways. Development teams accuse the CISO of having no appreciation for the skill with which they balance competing priorities, and view security practitioners as noisy know-it-alls who periodically show up to say “All your stuff’s broken!” CISOs don’t understand how development teams work, accuse developers of having no clue how attackers will break their code, and think the only English phrase they learned in college was “We don’t have time to fix that!” This mutual lack of understanding makes even basic cooperation difficult. We are here to help you understand development issues and how to communicate what needs to happen to development teams without putting them on the defensive. Following are several aspects of Agile development that create friction between the two groups. Avoid these pitfalls and your job will be much easier, but you need to do some work to understand how your development teams work and how best to work with them. Agile 101 for CISOs Before we make specific recommendations we need you to embrace Agile itself. Agile is fascinating because it isn’t a single development process, but instead a collection of methods under a common banner. That banner is incremental improvement. It promotes faster and shorter cycles, with a focus on personal interaction between developers, working software over documentation, more collaboration with customers, and responsiveness to change. But the key to all this is making small improvements, every sprint, to improve speed and effectiveness. This is all spelled out in the Agile Manifesto. You will need to work with the people who control the Agile process. Agile teams have specific roles and events. A Product Owner is responsible for the overall product requirements and priorities. The Development Team builds the code. The Scrum Master facilitates frequent structured meetings (Scrums), typically held daily, for 15 minutes to communicate project status formally. Projects break down into Sprints which are one to four week coding cycles, with specific tasks – not necessarily features – to be performed. The Sprint Planning Meeting defines those goals, which are placed into a Backlog of tasks that the Program Manager prioritizes as specific tasks, typically in a ticketing and task management tool. Developers then focus on the small tasks – 2-6 hours – they are assigned. Big-picture features are called Stories, which are broken down into tasks. Each day a developer comes in, attends the scrum, loads up his or her task list, codes, and them commits the code when the assignment is complete… so it can run through testing. Typically code is committed near the end of the sprint – but some versions of Agile, including DevOps, might have developers commit code several times per day. The key is that sprints move very fast – usually a matter of weeks. Requirements are set up front and then everyone is off to the races to knock out particular tasks. The goal is to completely deliver the feature or function at the end of the sprint, getting it into the hands of customers as quickly as possible. This is important to get customer feedback quickly and avoid working for 2 years to deliver a feature, only to find out it isn’t what is needed at all. Security is fully compatible with Agile – it simply needs to be integrated. Recommendations for the CISO Here are a list of things to do, and to avoid, as you work with development. Mostly it comes down integrating security as seamlessly into their processes as possible, without sacrificing your security objectives. Learn: You learned to work with HR on privacy issues, Legal on breach disclosures, and IT for compliance reporting and controls. You know how to work with executive management to communicate risk and ask for budget. Now you need to take some time to learn how development works – our research is just your starting point. Focus on the basic development process and the tools they use to manage it. Once you understand the process the security integration points become clear. Once you understand the mechanics of the organization, the best way to introduce and manage security requirements will also become evident. Communicate: We strongly recommend joining the team directly to hash out issues, but only when you need to. Agile promotes individual interaction as a principal means of communication, but that does not mean you should attend every scrum. In today’s development suite tools like JIRA, Slack, and even Skype facilitate communication across development teams. Add yourself to the appropriate groups within these communication services to stay abreast of issues, and join meetings as needed. Grow your own support: Every development team has specialists. One member may know UI and one mobile platforms; one may be responsible for tools, another build management, and another for architecture. During our most recent interviews a handful of companies explained that they encourage each team to have a security specialist, responsible for security advocacy. Provide security training: Training is expensive so it is essential for development to leverage lower-cost knowledge sharing options. Most organizations do in-house training, which

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

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

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

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

They say when industries go nutty with consolidation and high-dollar M&A deals, the only folks who really make money are the bankers and the lawyers. Shareholders end up holding the bag, but these folks have moved on to the next deal. Given all the recent retail sector breaches (there are too many to even link), let’s take a look at who is going to profit. Mostly because we can. The forensicators are first in line. They are running the investigations and figuring out how many millions of identities and credit cards have been stolen. The next group feeding at the breach trough are the credit monitoring folks, who get a bulk purchase agreement each time to cover consumers who were compromised this time. The crisis communication PR folks also generate hefty bills. Customers are pissed and the retailer is on the evening news – not for the new store design. The company needs to start driving the message, which means they need PR heavies to start spinning like a top. Ka-ching. Of course security vendors win as well. There is no time to grab security budget like right after a breach. Senior management doesn’t ask why – they ask whether it is enough. Every security salesperson tells tall tales about how their products and services would have stopped the breach. Who cares if the offering wouldn’t have made a difference? Don’t let the truth get in the way of the new BMW payment! It’s a feeding frenzy for a few quarters after the breach. Sell, sell, sell! But it doesn’t end there – lawyers always get their piece of the action by launching a variety of class-action suits against the retailer. We haven’t yet (to my knowledge) seen a successful judgement against a company for crappy security resulting in lost identities, but it’s coming. Although it is usually just easier to settle the class action rather than fight it. The lucky winners in the class action might each get a $5 gift card. The lawyers walk away with 20-30% of the judgement. Yes, that’s a lot of gift cards. Internally the company needs to make sure this kind of thing doesn’t happen again. So they fire the existing CISO and look for another one. Then the security recruiters spring into action. The breached retailer is looking, but many others will either try to fill their own positions, or perhaps decide to make a change before they find themselves in the same unhappy place. Of course the new CISO had better take advantage of the first few quarters during the honeymoon, with a mandate to fix things. Lord knows that doesn’t last long. Soon enough retailers always realize they are still in a low-margin business, and spending on security technology like a drunken sailor hasn’t helped sell more widgets. But that flyer in the Sunday paper offering a 35% discount sure did. Finally, let’s not forget the shareholders. You’d think they’d be losers in this situation, but not so much. Wall Street seems to be numb to breaches by now. The analysts just build the inevitable write-down into the model and move on. If anything it forces companies to button down some leaky operational issues and might even improve performance. Of course the loser is the existing CISO and maybe the CIO, who get thrown under the bus. But don’t feel too bad for them. They will probably write a book and do some consulting while they collect the severance package and the road rash heals. Then they’ll get back in the game by being candid about what they learned and how they will do it differently next time. We have all seen this movie before. And we’ll see it again. And again. And again. Photo credit: “Pigs at trough, 1927” originally uploaded by King County, WA Share:

Sometimes life sneaks up on you. Often when I am introduced to new clients and professional contacts, it is as “Analyst and CEO of Securosis; he used to be at Gartner”. I am fully cognizant of the fact that not only is Gartner where I started my analyst career, but also that my time and title there are the reason I was able to start Securosis. Not only did I learn how to be an analyst, but the Gartner name (as much as it pains some people) still carries a lot of weight. Leaving as a VP carries even more (a gift from my former boss, who knew he could never get my pay where it needed to be). It still carries weight to this day. We have a hell of a good brand in Securosis, but large swaths of the world have never heard of us. “Former Gartner” still helps open those doors. Even though the kind of work we do today carries very little resemblance to what I did back at the G. To be honest, I’m not even sure we are analysts anymore. It’s still part of what we do, but only one facet. Recently I have run into more of my former colleagues at various events. Black Hat, Boxworks, and other random analyst days and conferences. Most of them still work there, and all are shocked when I mention that I have now been running Securosis longer than I was at Gartner. This summer we passed the 7-year mark as a company. That’s exactly as long as I was at Gartner, and I wasn’t even an analyst for my first year. It’s longer than any other professional job I have held, and almost as long as I spent at the University of Colorado (8 years for my undergrad – it’s a Boulder thing). I still remember the first few months of the company. How I could barely sleep at night because I was so excited about what the next day would hold. Waking up early and jumping on my computer to blog, research, and spend entirely too much time on Twitter. Seven years is a long to maintain that enthusiasm. Since then I have added three children to my family, been through two major medical challenges, and built up the stress and overhead that comes from moving from a one-person shop with no clients… to one with partners, contributors, software platforms, and dozens of active clients (not counting all the one-off projects). I now literally lose entire days purely to dealing travel plans, invoices, and expenses. And really, no one with three kids under the age of five ever wakes up, on their own, with enthusiasm. But despite the overhead, chronic sleep deprivation, and stress of deadlines and commitments, this is the single most exciting time of my career. I may wake up a little rough around the edges, and feel like there is never enough time in the day, but I am engaged in my most compelling and challenging work since I first entered the workforce as an underweight security guard. About four or five years ago I placed a bet on cloud computing, and later on what is now known as DevOps. Those bets are paying off bigtime as those entangled disruptive forces trigger massive changes in how we deliver and consume technology. Aside from paying off financially (apparently there still aren’t that many people who really understand cloud and DevOps security out there), the work is… exciting. It’s a hell of a lot of fun. Every day I wake up not only with something new to learn, but with the confidence that I can use it to support my family as I gain and expand that knowledge. It is really hard to imagine a better job (without zero gravity or secret lairs). Although being interviewed by the Wall Street Journal on celebrity nudes was still kind of a surprise. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in the Wall Street Journal on the celebrity hacks. Rich’s article on the same issue at TidBITS. And a zillion other articles on the story. Mike quoted on context-aware security in SearchNetworking. Mike quoted on Wendy Nather being named a “Power Player” in Security. Wendy is awesome and one of our favorite people in the industry. Mike couldn’t be happier to be quoted in the piece. Mike’s “Change Agent” – Trusted Information Systems. Mike did a blog post/video for Digital Guardian naming a “change agent” that had an impact on how security has evolved… Check it out. Mortman Quoted about DevOps by the Hulminator. Chasing consistency across the wild seas of enterprise IT Favorite Securosis Posts Let’s be honest: we only had three posts by Mike this week, so we’ll call them all favorites. Other Securosis Posts Feeding at the Data Breach Trough. Incite 9/3/2014: Potential. PR Fiascos for Dummies. Favorite Outside Posts Mike Rothman: Infosec is a strange industry. Gunnar is right. There are many parallels between security and finance (another ‘strange’ industry). I’d add another to the list. Success in security is when nothing happens. If that’s not strange, I don’t know what is… Adrian Lane: 11 Reasons Email Is the Worst. This is fascinating – not for the insights into the limitations of email, but for its astute examination of human behavior. Worth the read! Rich: Not Safe for Not Working On by Dan Kaminsky. Dan really addresses the root issue here, at both psychological and practical levels. Must read. Gunnar: Hacker Breached HealthCare.gov Insurance Site. “If this happened anywhere other than HealthCare.gov, it wouldn’t be news,” a senior DHS official said.” Not the best excuse. Mortman: Bringing new security features to Docker. 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

It starts with a blank slate. Not entirely blank because some stuff has happened over the past few months, which offers hints to where things will go. But you largely ignore that data because you want to believe. Maybe this time will be different. Or maybe it will be the same. All you can see is potential. Yet soon enough the delusions of grandeur will be shown to be exactly that – delusions. No, I’m not talking about self-help or resetting your personal or professional lives. I’m talking about the NFL season. It starts on Thursday night and I’m pumped. I’m always pumped for football. Sure, there were some college games over the weekend, and I enjoyed watching those. But for me nothing compares to the pro game. Will my teams (the Giants and Falcons) recover this year? Will their off-season efforts be enough? Will the other teams, who have been similarly busy, be even better this year? Can I look forward to being excited about the NFL playoffs in January because my teams are in, or will I be paying attention to the bowl games to look for high draft picks for next year? Like I did this past January/February. So many questions, but all I have now is optimism. Why not? I’ve been following the beat reporters covering my teams every day. They tweet and file reports about practices and injuries and dissect meaningless pre-season games. It’s fun for me and certainly better than chasing down malware-laden sites claiming to have celebrity nudie pictures. My teams have holes, but that’s OK. You forget about those in the build-up to the first week. There is plenty of time over the next four months to grind my teeth and wonder why they cut this guy or call that play. No second-guessing yet – there isn’t much to second guess. Until next Tuesday morning anyway. Soon enough we’ll know whether the teams are real. It’s always fun to see which teams will surprise and which will disappoint. Soon the suspense will be over. It’s time. And I’m fired up. I’ll be in the GA Dome on Sunday. You know, that guy losing his voice as the Falcons take on the Saints. Same as it ever was. –Mike Photo credit: “NFL Logo” originally uploaded by Matt McGee 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 Leveraging Threat Intelligence in Incident Response/Management Quick Wins The (New) Incident Response & Management Process Model Threat Intelligence + Data Collect = Responding Better Really Responding Faster 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 Foole and Boobage: As alluded above, the Intertubes exploded over the weekend – not with news of things that matter, like global unrest, tentative ceasefires, NASCAR, college football, or even more ice-bucketry. Everyone was aflutter about seeing some celebrity boobies. Everyone now has an opinion about how the hack happened, even your general mass media sites chock full of security expertise. Yes, that was sarcasm folks. As usual, don’t believe everything you read on the Internet – a lot of speculation is wrong. I have no inside information and neither does our resident Apple Fan Boi, the Rich Mogull. Which means those folks probably don’t either, so they are coming up with plausible threat models that could have resulted in an attacker (or group of attackers) gaining access to the Photostreams of these celebrities, who evidently like to take pictures of themselves without shirts on. I’m certainly not judging that, despite the fact that folks get pretty uptight about seeing breasts in the US. I am judging the baseless speculation. At some point we may find out how it happened. Or we may not. At the end of the day, if you take nudie pictures and store them in a cloud service, other people may see them. Not that it’s right, but it’s reality. (PS: Dog yummy to anyone who gets the reference in the title.) – MR Customer centric: Owen Thomas discusses the gaps Apple needs to address before they can enter the payments market, but his arguments assume Apple wants to go all in. If their goal is to provide mobile payments Apple