Research

After a short review of the RSA Security Conference, Rich, Mike, and Adrian debate the value of using labels like “Rugged DevOps” or “SecDevOps”. Rich sees them as different, Mike wonders if we really need them, and Adrian has been tracking their reception on the developer side of the house. Okay, it’s pathetic as smackdowns go, but you wouldn’t have read this far if we didn’t give it an interesting title. Watch or listen: Share:

Don’t be distracted by the technical details. The model of phone, the method of encryption, the detailed description of the specific attack technique, and even feasibility are all irrelevant. Don’t be distracted by the legal wrangling. By the timing, the courts, or the laws in question. Nor by politicians, proposed legislation, Snowden, or speeches at think tanks or universities. Don’t be distracted by who is involved. Apple, the FBI, dead terrorists, or common drug dealers. Everything, all of it, boils down to a single question. Do we have a right to security? This isn’t the government vs. some technology companies. It’s the government vs. your right to fundamental security in the digital age. Vendors like Apple have hit the point where some of the products they make, for us, are so secure that it is nearly impossible, if not impossible, to crack them. As a lifetime security professional, this is what my entire industry has been dreaming of since the dawn of computers. Secure commerce, secure communications, secure data storage. A foundation to finally start reducing all those data breaches, to stop China, Russia, and others from wheedling their way into our critical infrastructure. To make phones so secure they almost aren’t worth stealing, since even the parts aren’t worth much. To build the secure foundation for the digital age that we so lack, and so desperately need. So an entire hospital isn’t held hostage because one person clicked on the wrong link. The FBI, DOJ, and others are debating whether secure products and services should be legal. They hide this in language around warrants and lawful access, and scream about terrorists and child pornographers. What they don’t say, what they never admit, is that it is impossible to build in back doors for law enforcement without creating security vulnerabilities. It simply can’t be done. If Apple, the government, or anyone else has master access to your device, to a service, or communications, that is a security flaw. It is impossible for them to guarantee that criminals or hostile governments won’t also gain such access. This isn’t paranoia, it’s a demonstrable fact. No company or government is completely secure. And this completely ignores the fact that if the US government makes security illegal here, that destroys any concept of security throughout the rest of the world, especially in repressive regimes. Say goodbye to any possibility of new democracies. Never mind the consequences here at home. Access to our phones and our communications these days isn’t like reading our mail or listening to our phone calls – it’s more like listening to whispers to our partners at home. Like tracking how we express our love to our children, or fight the demons in our own minds. The FBI wants this case to be about a single phone used by a single dead terrorist in San Bernadino to distract us from asking the real question. It will not stop at this one case – that isn’t how law works. They are also teaming with legislators to make encrypted, secure devices and services illegal. That isn’t conspiracy theory – it is the stated position of the Director of the FBI. Eventually they want systems to access any device or form of communications, at scale. As they already have with our phone system. Keep in mind that there is no way to limit this to consumer technologies, and it will have to apply to business systems as well, undermining corporate security. So ignore all of that and ask yourself, do we have a right to security? To secure devices, communications, and services? Devices secure from criminals, foreign governments, and yes, even our own? And by extension, do we have a right to privacy? Because privacy without security is impossible. Because that is what this fight is about, and there is no middle ground, mystery answer hiding in a research project, or compromise. I am a security expert. I have spent 25 years in public service and most definitely don’t consider myself a social activist. I am amused by conspiracy theories, but never take them seriously. But it would be unconscionable for me to remain silent when our fundamental rights are under assault by elements within our own government. Share:

While the big story this week was the FBI vs. Apple, I’d like to highlight something a little more relevant to our focus on the cloud. You probably know about the DOJ vs. Microsoft. This is a critically important case where the US government wants to assert access on the foreign branch of a US company, putting it in conflict with local privacy laws. I highly recommend you take a look, and we will post updates here. Beyond that, I’m sick and shivering with a fever, so enough small talk and time to get to the links. Posting is slow for us right now because we are all cramming for RSA, but you are probably used to that. BTW – it’s hard to find good sources for cloud and DevOps news and tutorials. If you have links, please email them to <mailto::info@securosis.com>. If you want to subscribe directly to the Friday Summary only list, just click here. And don’t forget: The EIGHTH Annual Disaster Recovery Breakfast: Clouds Ahead. Top Posts for the Week Huge HUGE vulnerability you need to start patching. Magnitude of glibc Vulnerability Coming to Light Cloud Security Alliance hackathon offers $10,000 prize This is for the Software Defined Perimeter project. Another great CloudAcademy post. This is something we work on in every single client engagement. Down the road we will detail our process and recommendations. Centralized Log Management with AWS CloudWatch: Part 1 of 3 We’ve posted a bit on this ourselves, and I talk about it a lot in presentations, but a very cogent view of some of the security advantages of the cloud. Bill Shinn and I will be going more in-depth in our RSA presentation. How the Cloud Simplifies Security Oops. VMware re-issues patch after vCenter fix fails to ‘completely’ fix bug Designed for mobile apps, but also has cloud implications: Tidas: a new service for building password-less apps Last week we talked about logging in our Tool of the Week. Here’s a slightly-older AWS post on building everything cloud-native. Personally, I’m still torn on which pattern I like better. I think it will largely come down to costs, because you can also build alerts based on Kinesis events. Tool of the Week This is a new section highlighting a cloud, DevOps, or security tool we think you should take a look at. We still struggle to keep track of all the interesting tools that can help us, and if you have submissions please email them to info@securosis.com. One issue that comes up a lot in client engagements is the best “unit of deployment” to push applications into production. That’s a term I might have made up, but I’m an analyst, so we do that. Conceptually there are three main ways to push application code into production: Update code on running infrastructure. Typically using configuration management tools (Chef/Puppet/Ansible/Salt), code-specific deployment tools like Capistrano, or a cloud-provider specific tool like AWS CodeDeploy. The key is that a running server is updated. Deploy custom images, and use them to replace running instances. This is the very definition of immutable because you never log into or change a running server, you replace it. This relies heavily on auto scaling. It is a more secure option, but it can take time for the new instances to deploy depending on complexity and boot time. Containers. Create a new container image and push that. It’s similar to custom images, but containers tend to launch much more quickly. As you can guess, I prefer the second two options because I like locking down my instances and disabling any changes. That can really take security to the next level. Which brings us to our tool this week, Packer by HashiCorp. Packer is one of the best tools to automate creation of those images. It integrates with nearly everything, works on multiple cloud and container platforms, and even includes its own lightweight engine to run deployment scripts. Packer is an essential tool in the DevOps / cloud quiver, and can really enhance security because it enables you to adopt immutable infrastructure. Securosis Blog Posts this Week Firestarter: RSA Conference – the Good, Bad, and the Ugly. Securing Hadoop: Technical Recommendations. Securing Hadoop: Enterprise Security For NoSQL. Other Securosis News and Quotes I posted a piece at Macworld on the FBI vs. Apple that has gotten a lot of attention. It got linked all over the place and I did a bunch of interviews, but I won’t spam you with them. We are posting all our RSA Conference Guide posts over at the RSA Conference blog – here are the latest: Securosis Guide: Training Security Jedi Securosis Guide: The Beginning of the End(point) for the Empire Securosis Guide: Escape from Cloud City Training and Events We are giving multiple presentations at the RSA Conference: Rich and Mike are giving Cloud Security Accountability Tour Rich is co-presenting with Bill Shinn of AWS: Aspirin as a Service: Using the Cloud to Cure Security Headaches David Mortman is presenting: Learning from Unicorns While Living with Legacy Docker: Containing the Security Excitement Docker: Containing the Security Excitement (Focus-On) Leveraging Analytics for Data Protection Decisions Rich is giving a presentation on Rugged DevOps at Scale at DevOps Connect the Monday of RSAC We are running two classes at Black Hat USA: Cloud Security Hands-On (CCSK-Plus) Advanced Cloud Security and Applied SecDevOps Share:

Every year we focus a lot on the RSA Conference. Love it or hate it, it is the biggest event in our industry. As we do every year, we break down some of the improvements and disappointments we expect to see. Plus, we spend a few minutes talking about some of the big changes coming here at Securosis. We cover a possibly-insulting keynote, the improvements in the sessions, and how we personally use the event to improve our knowledge. Watch or listen: Share:

As part of our changes at Securosis this year, it’s time to say goodbye to the old Friday Summary, and hello to the new one. Adrian and I started the Summary way back before Mike joined the company, as our own version of his weekly Security Incite. Our objective was to review the highlights of the week, both our work and things we found on the Internet, typically with an introduction based on events in our personal lives. As we look at growing and changing our focus this year, it’s time for a different format. Mike’s Incite (usually released on Wednesdays) does a great job highlighting important security stories, or whatever we find interesting. The Summary has always overlapped a bit. We also developed a tendency to overstuff it with links. Moving forward we are switching gears, and the Summary will now focus on our main coverage areas: cloud, DevOps, and automation security. The new sections will be more tightly curated and prioritized, to better fit a weekly newsletter format for folks who don’t have time to keep up on everything. We plan to keep the Incite our source for general security industry analysis, with the revised Summary targeting our new focus areas. We are also changing our email list provider from Aweber to MailChimp due to an ongoing technical issue. As part of that switch we will soon offer more email subscription options, which we used to have. You can pick the daily digest of all our posts, the weekly Incite, and/or the weekly Summary. If you want to subscribe directly to the Friday Summary only, just click here. If you have any feedback, as always please feel free to leave a comment or email us at //info@securosis.com. And don’t forget: The EIGHTH Annual Disaster Recovery Breakfast: Clouds Ahead. Top Posts for the Week We missed it when it was released, but Google now has limited management plane logging support. It still isn’t up to CloudTrail, and it’s still in beta, but this is one of the most critical security capabilities enterprises need from a cloud provider. Rumor is Microsoft also has it in beta. This is another good example of using AWS capabilities for security functionality. This is the sort of thing that is built into most WAFs (including cloud WAFs) but we like this post more for showing how you can automate and wire things together than for its particular use case. How to Configure Rate-Based Blacklisting with AWS WAF and AWS Lambda A good non-security perspective on Continuous Delivery. We see a lot of organizations throw the term (along with DevOps) around without focusing on some of the foundational things you need to make it work. Are you ready for Continuous Delivery? GitHub posted a good incident report. This can serve as a decent model for both security and non-security incidents: January 28th Incident Report Node is really popular, but still gives us the security willies at times. This good piece lays out some of the issues: The battle for Node.js security has only begun CloudFormation and other immutable infrastructure tools often have gaps, especially when new products are released. Here’s how to use Python to deal with them, using a security example: Customizing CloudFormation with Python Props to Amazon for this one: AWS’ exhaustive terms of service covers zombie outbreaks Tool of the Week This is a new section highlighting a cloud, DevOps, or security tool we think you should take a look at. We still struggle to keep track of all the interesting tools that can help us; if you have submissions please email them to //info@securosis.com. We are still looking at how we want to handle logging as we rearchitect securosis.com. Our friend Matt J. recommended I look at the fluentd open source log collector. It looks like a good replacement for Logstash, which is pretty heavy and can be hard to configure. You can pump everything into fluentd in an instance, container, or auto-scaled cluster if you need it. It can perform analysis right there, plus you can send them down the chain to things like ElasticSearch/Kibana, AWS Kinesis, or different kinds of storage. What I really like is how it normalizes data into JSON as much as possible, which is great because that’s how we are structuring all our Trinity application logs. Our plan is to use fluentd with some basic rules for securosis.com, pushing the logs into AWS hosted ElasticSearch (to reduce management overhead), and then Kibana to roll our own SIEM. We see a bunch of clients following a similar approach. This also fits well into cloud logging architectures where you collect the logs locally and only send alerts back to the SOC. Especially with S3 support, that can really reduce overall costs. Securosis Blog Posts this Week Securing Hadoop: Operational Security Issues. Other Securosis News and Quotes Cloud Security: Software Defined. Event Driven. Awesome. We are posting our RSA Conference Guide on the RSA Conference blog – here are the latest posts: The Securosis Guide to the RSA Conference 2016: The FUD Awakens! Securosis Guide: Threat Intelligence & Bothan Spies Securosis Guide: R2DevOps Securosis Guide: Escape from Cloud City Training and Events We are giving multiple presentations at the RSA Conference. Rich and Mike are presenting Cloud Security Accountability Tour. Rich is co-presenting with Bill Shinn of AWS: Aspirin as a Service: Using the Cloud to Cure Security Headaches. David Mortman is presenting: Learning from Unicorns While Living with Legacy Docker: Containing the Security Excitement Docker: Containing the Security Excitement (Focus-On) Leveraging Analytics for Data Protection Decisions Rich is presenting on Rugged DevOps at Scale at DevOps Connect the Monday of RSAC We are running two classes at Black Hat USA. Cloud Security Hands-On (CCSK-Plus) Advanced Cloud Security and Applied SecDevOps Share:

Rich here. I was a little burnt out when the start of this year rolled around. Not “security burnout” – just one of the regular downs that hit everyone in life from time to time. Some of it was due to our weird year with the company, a bunch of it was due to travel and impending deadlines, plus there was all the extra stress of trying to train for a marathon while injured (and working a ton). Oh yeah, and I have kids. Two of whom are in school. With homework. And I thought being a paramedic or infosec professional was stressful?!? Even finishing the marathon (did I mention that enough?) didn’t pull me out of my funk. Even starting the planning for Securosis 2.0 only mildly engaged my enthusiasm. I wasn’t depressed by any means – my life is too awesome for that – but I think many of you know what I mean. Just a… temporary lack of motivation. But last week it all faded away. All it took was a break from airplanes, putting some new tech skills into practice, and rebuilding the entire company. A break from work travel is kind of like the reverse of a vacation. The best vacations are a month long – a week to clear the head, two weeks to enjoy the vacation, a week to let the real world back in. A gap in work travel does the same thing, except instead of enjoying vacation you get to enjoy hitting deadlines. It’s kind of the same. Then I spent time on a pet technical project and built the code to show how event-driven security can work. I had to re-learn Python while learning two new Amazon services. It was a cool challenge, and rewarding to build something that worked like I hoped. At the same time I was picking up other new skills for my other RSA Conference demos. The best part was starting to rebuild the company itself. We’re pretty serious about calling this our “Securosis 2.0 pivot”. The past couple weeks we have been planning the structure and products, building out initial collateral, and redesigning the website (don’t worry – with our design firm). I’ve been working with our contractors to build new infrastructure, evaluating new products and platforms, and firming up some partnerships. Not alone – Mike and Adrian are also hard at work – but I think my pieces are a lot more fun because I get the technical parts. It’s one thing to build a demo or write a technical blog post, but it’s totally different to be building your future. And that was the final nail in the blah’s coffin. A month home. Learning new technical skills to build new things. Rebuilding the company to redefine my future. It turns out all that is a pretty motivating combination, especially with some good beer and workouts in the mix, and another trip to see Star Wars (3D IMAX with the kids this time). Now the real challenge: seeing if it can survive the homeowner’s association meeting I need to attend tonight. If I can make it through that, I can survive anything. Photo credit: Blah from pinterest And now on to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Adrian quoted in CSO Online: Credit card security has no silver bullet Mort quoted on container security: Containers: Security Minefield – or Channel Goldmine? Me on ridiculous travel security: Podcast 492: How to travel like an international superspy A piece I wrote over at TidBITS on government, encryption, and back doors. Also relevant to the Securosis audience: Why Apple Defends Encryption. Securosis Posts Incite 2/3/2016: Courage. Event-Driven AWS Security: A Practical Example. Securing Hadoop: Architectural Security Issues. Securing Hadoop: Architecture and Composition. Securing Hadoop: Security Recommendations for NoSQL platforms [New Series]. The EIGHTH Annual Disaster Recovery Breakfast: Clouds Ahead. Security is Changing. So is Securosis. Incite 1/20/2016 – Ch-ch-ch-ch-changes. Research Reports and Presentations Threat Detection Evolution. Pragmatic Security for Cloud and Hybrid Networks. EMV Migration and the Changing Payments Landscape. Network-based Threat Detection. Applied Threat Intelligence. Endpoint Defense: Essential Practices. Cracking the Confusion: Encryption and Tokenization for Data Centers, Servers, and Applications. Security and Privacy on the Encrypted Network. Monitoring the Hybrid Cloud: Evolving to the CloudSOC. Security Best Practices for Amazon Web Services. Top News and Posts Why lost phones keep pointing at this Atlanta couple’s house This is a really important case: Security firm sued for filing “woefully inadequate” forensics report Chromodo browser disables key web security. Note to security vendors: put your customers first, not marketing. Severe and unpatched eBay vulnerability allows attackers to distribute malware. Not going to be patched, seriously? Software Security Ideas Ahead of Their Time New Technologies Give Government Ample Means to Track Suspects, Study Finds Friendly Fire. This is a really great post on the role of red teams. Congress to investigate US involvement in Juniper’s backdoor. Blog Comment of the Week This week’s best comment goes to Andy, in response to Event-Driven AWS Security: A Practical Example. Cool post. We could consider the above as a solution to an out of band modification of a security group. If the creation and modification of all security groups is via Cloudformation scripts, a DevOps SDLC could be implemented to ensure only approved changes are pushed through in the first place. Another question is how does the above trigger know the modification is unwanted?! It’s a wee bugbear I have with AWS that there’s not currently a mechanism to reference rule functions or change controls. My response: I actually have some techniques to handle out of band approvals, but it gets more advanced pretty quickly (plan is to throw some of them into Trinity once we start letting anyone use it). One quick example… build a workflow that kicks off a notification for approval, then the approval modifies something in Dynamo or S3, then that is one of the conditionals to check. E.g. have your change management system save down a token in S3 in a different account, then the Lambda

Would you like the ability to revert unapproved security group (firewall) changes in Amazon Web Services in 10 seconds, without external tools? That’s about 10-20 minutes faster than is typically possible with a SIEM or other external tools. If that got your attention, then read on… If you follow me on Twitter, you might have noticed I went a bit nuts when Amazon Web Services announced their new CloudWatch events a couple weeks ago. I saw them as an incredibly powerful too for event driven security. I will post about the underlying concepts tomorrow, but right now I think it’s better to just show you how it works first. This entire thing took about 4 hours to put together, and it was my first time writing a Lambda function or using Python in 10 years. This example configures an AWS account to automatically revert any Security Group (firewall) changes without human interaction, using nothing but native AWS capabilities. No security tools, no servers, nada. Just wiring together things already built into AWS. In my limited testing it’s effective in 10 seconds or less, and it’s only 100 lines of code – including comments. Yes, this post is much longer than the code to make it all work. I will walk you through setting it up manually, but in production you would want to automate this configuration so you can manage it across multiple AWS accounts. That’s what we use Trinity for, and I’ll talk more about automating automation at the end of the post. Also, this is Amazon specific because no other providers yet expose the needed capabilities. For background it might help to read the AWS CloudWatch events launch post. The short version is that you can instrument a large portion of AWS, and trigger actions based on a wide set of very granular events. Yes, this is an example of the kind of research we are focusing on as part of our cloud pivot. This might look long, but if you follow my instructions you can set it all up in 10-15 minutes. Tops. Prep Work: Turn on CloudTrail If you use AWS you should have CloudTrail set up already; if not you need to activate it and feed the logs to CloudWatch using these instructions. This only takes a minute or two if you accept all the defaults. Step 1: Configure IAM To make life easier I put all my code up on the Securosis public GitHub repository. You don’t need to pull that code – you will copy and paste everything into your AWS console. Your first step is to configure an IAM policy for your workflow; then create a role that Lambda can assume when running the code. Lambda is an AWS service that allows you to store and run code based on triggers. Lambda code runs in a container, but doesn’t require you to manage containers or servers for it. You load the code, and then it executes when triggered. You can build entirely serverless architectures with Lambda, which is useful if you want to eliminate most of your attack surface, but that’s a discussion for another day. IAM in Amazon Web Services is how you manage who can do what in your account, including the capabilities of Amazon services themselves. It is ridiculously granular and powerful, and so the most critical security tool for protecting AWS accounts. Log into the AWS console. Got to the Identity and Access Management (IAM) dashboard. Click on Policies, then Create Policy. Choose Create Your Own Policy. Name it lambda_revert_security_group. Enter a description, then copy and paste my policy from GitHub. My policy allows the Lambda function to access CloudWatch logs, write to the log, view security group information, and revoke ingress or egress statements (but not create new ones). Damn, I love granular policies! Once the policy is set you need to Create New Role. This is the role which the Lambda function will assume when it runs. Name it lambda_revert_security_group, assign it an AWS Lambda role type, then attach the lambda_revert_security_group policy you just created. That’s it for the IAM changes. Next you need to set up the Lambda function and the CloudWatch event. Step 2: Create the Lambda function First make sure you know which AWS region you are working in. I prefer us-west-2 (Oregon) for lab work because it is up to date and tends to support new capabilities early. us-east-1 is the granddaddy of regions, but my lab account has so much cruft after 6+ years that things don’t always work right for me there. Go to Lambda (under Compute on the main services page) and Create a Lambda function. Don’t pick a blueprint – hit the Skip button to advance to the next page. Name your function revertSecurityGroup. Enter a description, and pick Python for the runtime. Then paste my code into the main window. After that pick the lambda_revert_security_group IAM role the function will use. Then click Next, then Create function. A few points on Lambda. You aren’t billed until the function triggers; then you are billed per request and runtime. Lambda is very good for quick tasks, but it does have a timeout (I think an hour these days), and the longer you run a function the less sense it makes compared to a dedicated server. I actually looked at migrating Trinity to Lambda because we could offload our workflows, but at that time it had a 5-minute timeout, and running hour-long workflows at scale would likely have killed us financially. Now some notes on my code. The main function handler includes a bunch of conditional statements you can use to only trigger reverting security group changes based on things like who requested the change, which security group was changed, whether the security group is in a specified VPC, and whehter the security group has a particular tag. None of those lines will work for you, because they refer to specific identifiers in my account – you need to change them to work in your account. By default, the function will revert any security group change in your account. You need to cut and paste the line “revert_security_group(event)” into a conditional block to run only on matching conditions. The function only works for inbound rule changes. It

Last week Rich sent around Cockroaches Versus Unicorns: The Golden Age Of Cybersecurity Startups, by Mahendra Ramsinghani over at TechCrunch, for us to read. It isn’t an article every security professional needs to read, but it is certainly mandatory reading for anyone who makes buying decisions, tracks the security market, or is on the investment or startup side. It also nearly perfectly describes what we are going through as a company. His premise is that ‘unicorns’ are rare in the security industry. There are very few billion-dollar market cap companies, relative to the overall size of the market. But security companies are better suited to survive downturns and other challenging times. We are basically ‘cockroaches’, which persist through every tech Armageddon, often due to our ability to fall back on services. Many security startups are not unicorns; rather, they are cockroaches – they rarely die, and  in tough times, they can switch into a frugal/consulting mode. Like cockroaches, they can survive long nuclear winters. Security companies can be capital-efficient, and typically consume ~$40 million to reach break-even. This gives them a survival edge – but VCs are looking for a “growth edge.” The security market also appears much smaller than it should be considering the market dynamics, although it is very possible that is changing thanks to the hostile world out there. The article also postulates that the entire environment is shifting, with carriers and managed services providers jumping into acquisitions while large established players struggle. Yet most of the startups VCs see are just more of the same, fail to differentiate, and rely far too much on really poor FUD-based sales dynamics. With increasing hacks, the CISO’s life has just become a lot messier. One CISO told me, “Between my HVAC vendor and my board of directors, I am stretched. And everyday I get a hundred LinkedIn requests from vendors. Their FUD approach to security sales is exhausting.” And “I have seen at least 40 FireEye killers in the past 12 months,” one Palo Alto-based VC told me. Clearly he was exhausted. Some sub-sectors are overheated and investors are treading cautiously. We certainly see the same thing. How many threat intel and security analytics startups does the industry need? We get a few briefing requests a week, from another new company doing exactly the same things. And all our CISO friends hate vendor sales techniques. These senior security folks get upwards of 500 emails and 100 phone calls a week from sales people trying to get meetings. All this security crap looks the same. This combination inevitably leads to a contraction of seed capital, and that is where our story starts. DisruptOPS Most of you have noticed that over the past few years our research has skewed strongly toward cloud security, automation, and DevOps. This started with our initial partnership with the Cloud Security Alliance to build out the CCSK training class around 6 years ago. Rich had to create all the hands-on labs, which augered him down the rabbit hole of Amazon Web Services, OpenStack, Azure, and all the supporting tools. As analysts we like to think it’s our job to have a good sense of what’s coming down the road. We made a bet on the cloud and it paid off, transitioning from a hobby to generate beer money to a major source of ongoing revenue. It also opened us up to a wider client base, especially among end-user organizations. Three years ago Rich realized that in all his cloud security engagements, and all the classes we taught, we heard the same problems over and over. The biggest unsolved problem seemed to be cloud security automation. The next year was spent writing some proof-of-concept code merely to support conference presentations because there were no vendor examples, but at every talk attendees kept asking for “more… faster”. This demand became too great to ignore, and nearly 2 years ago we decided to start building our own platform. And we did … we built our own cloud security platform. Don’t worry, we don’t have anything to sell you – this is where Ramsinghani’s article comes in.   Our initial plan was to self fund development (Securosis is an awesome business) until we had a solid demo/prototype. Then we assumed it would be easy to get seed cash from some of our successful friends and build a new company in parallel with Securosis to focus on the product. We didn’t just want to start up a software company and jettison Securosis because our research is an essential driver to maintain differentiation, and we wanted to build the company without going the traditional VC route. We also have some practical limitations on how we can do things. We are older, have families to support, and have deep roots where we live that preclude relocation. The analogy we use is that we can’t go back to eating ramen for dinner every night in a coding flophouse. The demo killed when we showed it to people, we are really smart, and people like us. Our future was bright. Then we got hit with the reality clue bat. Everything was looking awesome last year at RSA when we started showing people and talking to investors. By summer all our options fell apart. We didn’t fit the usual model. We weren’t going to move to the Bay Area. We couldn’t take pay cuts to ‘normal’ founder levels and still support our families. And to be honest, we still didn’t want to go the normal VC route. We just weren’t going to play that game, given the road rash both Mike and Adrian have from earlier in their careers. Just like the article said, we couldn’t find seed funding. At least not the way we wanted to build the company. We even had a near-miss on an acquisition, but we couldn’t line everything up to hit everyone’s goals and expectations. Yet while this all went on, the Securosis business you see every day continued to boom. We

Rich here. When I hurt my knee running right before Thanksgiving everyone glanced at my brace and felt absolutely compelled to tell me how much “getting old sucks”. Hell, even my doctor commiserated as he discussed his recent soccer injury. The only problem is I first hurt me knee around junior high, and in many way’s it’s been better since I hit my 40’s than any other time I can remember. As a kid my mom didn’t want me playing football because of my knees (I tried soccer for a year in 10th grade, hurt it worse, then swapped to football to finish up high school). I wore a soft brace for most of my martial arts career. I’ve been in physical therapy so many times over the past three decades that I could write a book on the changing treatment modalities of chondromalacia patellae. I had surgery once, but it didn’t help. As a lifetime competitive athlete, running has always been part of my training, but distance running was always a problem. For a long time I thought a 10K race was my physical limit. Training for more than that really stressed the knee. Then I swapped triathlon for martial arts, and realized the knee did much better when it wasn’t smashing into things nearly every day.   Around that time my girlfriend (now wife) signed us up for a half-marathon (13.1 miles). I nearly died, but I made it. Over the subsequent decade I’ve run more of them and shaved 45 minutes off my PR. The older I get, the better my times for anything over a couple miles, and the longer distances I can run. But there’s one goal that seemed impossible – the full marathon. 26.2 miles of knee pounding awesomesauce. Twice as far as the longest race I ever ran. My first attempt, last year, didn’t go so well. Deep into my training program I developed plantar fasciitis, which is a fancy way of saying “my foot was f-ed up”. So I pushed my plans back to a later race, rehabilitated my foot… and got stomach flu the week before the last race of the year before Phoenix weather went “face of the sun” hot. A seriously disheartening setback after 6 months training. I made up for it with beer. Easier on the foot. A few months later an email popped up in my inbox letting me know registration for the Walt Disney World Marathon opened the next day. My wife and I looked at it, looked at each other, and signed up before the realistic parts of our brains could stop us. Besides, the race was only a month after we would be there with the kids, so we felt justified leaving them at home for the long weekend. I built up a better base and then started a 15-week custom program. Halfway through, on a relatively modest 8-mile run in new shoes, I injured my achilles tendon and had to swap to the bike for a couple weeks. Near the peak of my program, on a short 2-mile run and stretch day, I angled my knee just the wrong way, and proceeded to enjoy the pleasure of reliving my childhood pain. Three weeks later the knee wasn’t better, but I could at least run again. But now I was training in full-on panic mode, trying to make up for missing some of the most important weeks of my program. My goal time went out the window, and I geared down into a survival mindset. Yes, by the time I lined up at the race start I had missed 5 of 15 weeks of my training program. Even my wife missed a few weeks thanks to strep throat (which I also caught). To add insult to injury, it was nearly 70F with 100% humidity. In December. At 5:35am. You know what happened next? We ran a friggin’ marathon. Yes, at times things hurt. I got one nasty blister I patched up at an aid station. My headphones crapped out. I stopped at every single water station thanks to the humidity, and probably should have worn a bathing suit instead of running shorts. But overall it wasn’t bad. Heck, I enjoyed most of the race. I didn’t really start hurting until mile 17, and my pace didn’t fully crack until mile 22. Disney puts on a hell of a race, with distracting entertainment along the entire course. Thanks to the humidity it was the slowest Disney marathon in the 23-year history of the event. Even then, my time wasn’t embarrassing, and I finished in the top 20% or so (at a time that isn’t even close to getting into Boston or New York). I didn’t feel terrible. My wife also finished up in the front third of the pack, and we spent the afternoon walking around Disney World (slowly). We felt really good the next day, other than my darn knee. The one that held up for all 26.2 miles. The one that will be better in a week or two. I checked off a bucket list item and completed something I thought was impossible. Something I told myself my entire life I couldn’t do. There is nothing more satisfying than proving yourself wrong. Except, perhaps, doing it again. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences It isn’t security related, but Rich participated in Apple in 2015: The Six Colors report card. Securosis Posts Incite 1/13/2016: Permitted. SIEM Kung Fu: Fundamentals [New Series]. Incite 1/6/2016 – Recharging. Incite 12/15/2015: Looking Forward. Building a TI Program: Success and Sharing. Threat Detection Evolution [New Paper]. Building Security Into DevOps [New Paper]. Favorite Outside Posts Rich: How Hackers Took Down a Power Grid. A well-balanced article that points to the Ukraine as another canary in a coal mine. Mike: Dave Barry’s 2015 Year in Review: Dave Barry has a pretty good gig. Write one column a year, and it better be funny. Good thing it always is, and the 2015 edition

Rich, Mike, and Adrian highlight the big trends from the year and where our expectations were right and wrong. We teeter on the brink of predictions, but manage to pull ourselves back from falling into that chasm of idiocy. Mostly. We cover a fair bit of ground, but the main trends are the weirdnesses on the investment and M&A side of the security industry, breaches, the faster than expected adoption of cloud computing, and the changing regulatory environment. This is likely our last Firestarter for the year, and our posting volume will be lower as we all cram in those last few projects. We sincerely want to thank everyone watching and reading for your continued support. It lets us try out best to “do good work” while feeding our families. We are a very lucky band over here. Watch or listen: Share: