Research

Look, we don’t yet know what really happened at Sisense. Thanks to Brian Krebs and CISA, combined with the note sent out by the CISO (bottom of this post), it’s pretty obvious the attackers got a massive trove of secrets. Just look at that list of what you have to rotate. It’s every cred you ever had, every cred you ever thought of, and the creds of your unborn children and/or grandchildren. Brian’s article has basically one sentence that describes the breach: Sisense declined to comment when asked about the veracity of information shared by two trusted sources with close knowledge of the breach investigation. Those sources said the breach appears to have started when the attackers somehow gained access to the company’s code repository at Gitlab, and that in that repository was a token or credential that gave the bad guys access to Sisense’s Amazon S3 buckets in the cloud. And as to where the data ended up? Sure sounds like the dark web to me: On April 10, Sisense Chief Information Security Officer Sangram Dash told customers the company had been made aware of reports that “certain Sisense company information may have been made available on what we have been advised is a restricted access server (not generally available on the internet.)” So if (and that’s a very big if, this early) the first quote is correct, then here’s what probably happened: Someone at Sisense stored IAM user keys in GitLab. Probably in code, but that’s an open question. Could have been in the pipeline config. Sisense also stored a vast trove of user credentials that either were not encrypted before putting them in S3 (I’ll discuss that in a moment), or with the decryption key in the code. Bad guys got into GitLab. Bad guys (or girls, I’m not sexist) tested keys and discovered they can access S3. Maybe this was obvious because the keys were in the code to access S3, or maybe it was non-obvious and they tried good old ListBuckets. Attackers (is that better, people?) downloaded everything from S3 and put it on a private server or somewhere in the depths of Tor. We don’t know the chain of events that lead to the key/credential being in GitLab. There’s also the chance it was more-advanced and the attacker stole session credentials from a runner or something and a static key wasn’t a factor. I am not going to victim blame yet — let’s see what facts emerge. The odds are decent this is more complex than what’s emerged. HOWEVER Some of you will go to work tomorrow, and your CEO will ask, “how can we make sure this never happens to us?” None of this is necessarily easy at scale, but here’s where to start: Scan all your repositories for cloud credentials. This might be as simple as turning on a feature of your platform, or you might have to use a static analysis tool or credential-specific scanner. If you find any, get rid of them. If you can’t immediately get rid of them, hop on over to the associated IAM policy and restrict it to the necessary source IP address. Don’t think S3 encryption will save you. First, it’s always encrypted. The trick is to encrypt with a key that isn’t accessible from the same identity that has access to the data. So… that’s not something most people do. Encryption is almost always incorrectly implemented to stop any threat other than a stolen hard drive. If you manage customer credentials, that sh** needs to be locked down. Secrets managers, dedicated IAM platforms, whatever. It’s possible in this case all the credentials weren’t in an S3 bucket and there were other phases of the attack. But if they were in an S3 bucket, that is… not a good look. Sensitive S3 buckets should have an IP-based resource policy on them. All the IAM identities (users/roles) with access should also have IP restrictions. Read up on the AWS Data Perimeter. Get rid of access keys. Scan your code and repositories for credentials. Lock down where data can be accessed from. And repeat after me, Every cloud security failure is an IAM failure, and every IAM failure is a governance failure. I’m really sorry for any of you using Sisense. That list isn’t going to be easy to get through. Share:

Nearly everyone in the United States (and probably elsewhere) is infected with the Epstein-Barr virus at some point in their life. Most people will never develop symptoms, although a few end up with mono. Even without symptoms you carry this invasive genetic material for life. There’s no cure, and EBV causes some people to develop cancers and possibly Multiple Sclerosis, Chronic Fatigue Syndrome, and other problems. Those later diseases are likely caused by some other precipitating even or infection that “triggers” a reaction with EBV. Look, I have most of a molecular biology degree and I’m a paramedic and I won’t pretend to fully understand it all. The tl;dr is EBV is genetic material floating around your body for life and at some point it activates or interacts with something else and causes badness. (Me write good! Use words!) As I’ve been reading about the XZ Initiative (I’m using initiative deliberately due to the planning and premeditation) the same week that the CISA CSRB released their scathing report on Microsoft, it’s damn clear that our software supply chain issues are as deep as the emptiness of my cat’s soul. (I mean I love him, and I’m excited he’s coming back from the hospital this afternoon, but I couldn’t come up with a more-amusing analogy). If you aren’t up to date on all things XZ I suggest reading Matt Johansen’s rollup in his Vulnerable U newsletter. Here’s how EBV and XZ relate, at least in my twisted mind. XZ was clearly premeditated, well planned, sophisticated, and designed to slowly spread itself under the radar for many years before being triggered. There is absolutely no chance this approach hasn’t already been used by multiple threat actors. As much as I hate FUD and hyperbole, I am 100% confident that there is code in tools and services I use that has been similarly compromised. We didn’t miraculously catch the first ever attempt, because a Microsoft dev is anal-retentive about performance. XZ is the first such exploit which got caught. If I were a cybercriminal or government operative, I would already have several of these long-term attacks underway. You are welcome to believe our record is 1 for 1. I think it’s 1 catch of N attacks, and N scares me. I also do not believe we can eliminate this threat vector. I don’t think the best SAST/SCA tools and a signed SBOM have any chance at making this go away. Ever. That doesn’t mean we give up and lose hope — we just change our perspective and focus more on resilience to these attacks than pure prevention. I don’t have all the answers — not even close — but there are three aspects I think we should explore more. First, let’s make it harder on threat actors. Let’s increase their costs. How? Well, aside from all the improved security scanning over the past few years, I like the idea Daniel Miessler recently mentioned in a conversation and noted in his newsletter: use AI to automatically perform open source intel (OSINT) on OSS contributors. Do they have a history outside that code repo? Any real human interactions? This will be far from perfect, but will likely increase the cost of attack to build a persona which looks sufficiently real. We also have compromises in commercial software (hello Solar Winds). Vendors need to explore better internal code controls, sourcing, and human processes. E.g. require YubiKeys from all devs, side channel notifications and approvals of commits, and I suspect there are some new and innovative scanning approaches we can take as AI evolves (until it evolves past humanity and enslaves us all). E.g. “this may not be a known security defect, but it looks weird compared to this developer’s history, so maybe ping another future energy source human to review it”. I’m also a fan of making critical devs work on dedicated machines separate from the ones they use for email and web browsing, to reduce phishing/malware as a vector. No, I haven’t ever had anyplace I’ve worked approve that, but I *have* heard of some shops which pulled it off. The final part is preparing for the next XZ that slips through and is eventually triggered. Early detection, rapid remediation, and all the other hard expensive things. SBOM/SCA/DevSecOps are key here: you MUST be able to figure out where you are using any particular software package, and be able to implement compensating defenses (e.g., firewalls) and patch quickly. This is NOT SIMPLE AT SCALE, but it’s your best bet as the downstream customer for these things. None of what I suggested is easy. I think this is the next phase of the Assume Breach mindset. You can’t cure EBV. You can’t prevent all possible negative outcomes. But you can reduce some risks, detect others earlier, and react aggressively when those first cancer cells show up. Share:

Over 15 years ago (pre-Blip) I wanted to do something fun and casual for friends and Securosis readers at the annual RSA Conference… that I, as a budding entrepreneur, could actually afford. I started calling around and found a little place called Jillian’s right near the conference willing to open up early and serve breakfast for a reasonable rate. We ended up with around 50 people dropping in and out over those few hours, just mostly sitting around a table talking about whatever. Little did I know that our Disaster Recovery Breakfast would outlast Jillian’s, and, it seems, downtown San Francisco? I also never thought it would peak out at one point at around 300 people and inspire dozens of copycats. But one thing never changed — the casual atmosphere, the chance to talk without having to scream into someone’s ear, and the great conversations fueled by coffee (and the occasional Irish coffee). Once again, we’re back! Like last year we are hosting at the Pink Elephant which is just a few minutes walk and totally worth it if you want breakfast burritos or an omelette. This year we have two of our long-standing partners helping us out, plus a new (old) face. Here are the details: The 14th Annual Securosis Disaster Recovery Breakfast Thursday, May 9, 8-11 AM Pink Elephant 142 Minna St San Francisco, CA 94105 Come meet IANS Faculty and leadership, the LaunchTech team, members from the Vulnerable U community, the illustrious founder of Securosis (that’s me, duh), and whoever walks in the door for casual, no-marketing conversations. Drop in and out as you like, and you can even grab a coffee to go! RSVP at rsvp@securosis.com is appreciated but not required; feel free to just show up, but if you don’t RSVP we might run out of bacon. Share:

“All cloud security failures are IAM failures, and all IAM failures are governance failures.” — me on Twitter (too many years ago to find) CISA just released their report on the big Summer 2023 Microsoft Exchange Online Intrusion. You could call it blistering, but I call it more of a third degree plasma burn. It’s also the kind of validation I wish never had to happen. Like many other cloud security professionals, I have been concerned with the security of Microsoft’s cloud (Azure/Office). When I first started using Azure I noticed it tended towards more-open and less-secure defaults. For example, the default for running a VM in a VNet was… no Network Security Groups. The VM would be wide open to the Internet for both inbound and outbound traffic. In AWS and GCP you can’t even deploy anything without an SG attached. (The portal does now try to get you to deploy with an NSG). Other examples? The Azure activity log doesn’t record Read activity, so you can’t identify reconnaissance. Then there are the series of security flaws discovered by the teams and Wiz, Orca, and others. The report has great detail, but the structural issues and recommendations are the real highlights. Here are the ones I think stand out — which have implications (both good and bad) beyond Microsoft. It’s a governance failure: The Board concluded that Microsoft’s security culture was inadequate (page 17). Because features and innovation are prioritized over security: as written in stone by the first cave dwellers. Other CSPs have better security practices: Don’t blame me, it’s item 3 on page 17, and no surprise to those of us who do this for a living. Microsoft did not correct inaccurate information and still does not know what happened: This means multiple failures at multiple levels. Page 17, again. There has been more than one nation-state breach: We knew this, and they refer to Midnight Blizzard. The mistakes there are also… troubling. The Board believes Microsoft has deprioritized security and risk management: Bottom of page 18. The Board recommends Microsoft slow innovation until they fix security: It’s been done before, but I’m not sure how Copilot feels about that. The report then mentions the Microsoft Secure Future Initiative. I wrote on LinkedIn when that came out that it seemed inadequate. It’s like a Band-Aid when you need a tourniquet. The report goes into more detail on some specific security practices it recommends changing; but also seems to indicate they consider other cloud providers to be doing a better job with security around keys, tokens, and credentials. I can only assume they also know about SAS tokens. I mean, this report is rough, and anyone using Azure and Office needs to read it. And yes, I do use both myself for various things, but I’m not… a bank or the United States Government. Outside Microsoft specifically, there are some things in the report that make us cloud security types scream “I KNEW IT! I TOLD YOU SO!!!” at our screens: NIST needs to update 800-53 for cloud: Page 21, and if you know me you’ve heard me complaining about that for years. M&A is a security risk: Okay, Chris Farris and I are literally days from publishing a thing which might just call M&A a threat. CSPs need to stop charging for security-relevant logs: I’m screaming religious words right now. Which is weird, since I’m an atheist. CSPs should be transparent and report incidents and ALL vulnerabilities: Another one that’s an issue beyond Microsoft. CSPs and the government should have better victim notification: This is interesting and unexpected. They straight up call for non-spoofable mobile notifications. The government is watching and should use FedRAMP and its buying power to incentivize change: The original Trustworthy Computing Initiative was largely the result of serious government… threats?… to look at alternative operating systems. It’s time for a replay. It’s time for a Microsoft Trustworthy Cloud Initiative. Especially if they want us to trust them to be the leading AI provider. And FREE THE LOGS!!! Adding link to Joseph Menn’s Washington Post article. He’s banned in Russia so you know you can trust him. Share:

As any long-time readers know, I constantly abuse my past experiences and hobbies to try and make my current work sound WAY more interesting than it probably is. Or maybe it’s just an ego thing, I don’t want to think too hard about it. But, on occasion, lessons from my parallel lives actually inspire some original work. As a paramedic and a pilot I have had to memorize many dozens of mnemonics, and I’ve forgotten many more. Mnemonics are proven to be highly effective memory devices even in the midst of intense stress, like flying a plane or working a 9-1-1 call. For example, I learned “SAMPLE” for taking a patient’s history probably 30 years ago and I still use it today because in the insanity that is some calls it can be easy to lose track and forget a fundamental. This I always remember to ask about Signs and Symptoms, Allergies, Medications, Prior medical history, Last oral intake, and Event (why did they call us today?). Having issues ventilating an intubated patient? Use DOPE. Accidentally put your airplane into a spin? Use PARE (Power, Aileron, Rudder, Elevator). The more you drill these the better they work. I memorized RAKETS for my private pilot checkride but I definitely need to look that one up (it’s used to figure out if you can still fly a plane with a broken part). We don’t really use these in infosec, and I think it’s time to change that. Thus I present to you RECIPE PICKS for cloud incident response. This one hit me yesterday on an internal dev review call in one window while finishing my paramedic recertification in an open browser tab. For 4 years now here is how I’ve taught what to look for first in a cloud incident: I have the students leave that one up when we start the scenarios and live fire exercises. But standing in the shower I came up with a much better way to remember what to do. NOTE: the order doesn’t matter, as with SAMPLE it’s to make sure you don’t miss anything (the format breaks a little at the end due to this sites rendering, sorry):               Resource (current config/state)               Events (api call(s) on that resource)               Changes (diff plus associated API calls)               Identity (who made the triggering change or API call)               Permissions (of the identity; informs the blast radius)               Entitlements (of the resource: e.g. it’s IAM role or managed identity)               Public (is it public?)               IP (all API calls from that IP address)              Caller (all other API calls from the calling identity) tracK (look for indications of a pivot; e.g. role chaining) forenSics (on a resource, or digging into resource logs) These steps shouldn’t be done in order, except the last two probably need to be the last two (especially the forensics). This is all based on the process I’ve figured out over the years and I estimate you can probably close 90% of incidents relatively quickly by pulling this data. I’m definitely going to start trying to build more of these into my trainings, and I’ll do some more blog posts in the coming weeks on how to use RECIPE PICKS. I’d also be remiss if I didn’t link over to a work blog post on how our platform does most of this automatically on every incident. Let me know what you think and if I missed anything. Just email rmogull@securosis.com since I have comments turned off due to all the ridiculous spam. Share:

I’m pretty excited about this one. We are finally releasing version 2.0 of the Cloud Security Maturity Model. This is the culmination of nearly 9 months of research and analysis, a massive update from the original released in 2020. The tl;dr is that this version is not only updated to reflect current cloud security practices, but it includes around 100 cloud security control objectives to use as Key Performance Indicators — each matched 1:1 (where possible) with a technical control you can assess (AWS for now— we plan to expand to Azure and GCP next). You can download it here — no registration wall, and it includes the spreadsheet and PDFs. The CSMM 2.0 was developed by Securosis (that’s us!) and IANS Research in cooperation with the Cloud Security Alliance. Version 2.0 underwent a public peer review process at the CSA and internal review at IANS. We will keep updating it based on public feedback. The model includes nearly 100 control objectives and controls, organized into 12 Categories in 3 Domains. IANS released a free diagnostic self-assessment survey tool. You can quickly and easily generate a custom maturity report. FireMon added a free CSMM dashboard to Cloud Defense, which will automatically assess, rate, and track your cloud maturity using the CSMM! It’s really cool. But I’m biased because I pushed hard to build it. Okay, that’s what it is, but here’s why you should care. When Mike and I first built the CSMM we designed it more as a discussion tool to describe the cloud journey. Then we started using it with clients and realized it also worked well as a framework to organize a cloud security program. Two of the big issues with cloud governance we’ve seen in the decade-plus we’ve been doing this are: Existing security frameworks have been extended to cloud, but not designed for cloud, which creates confusion because they lack clear direction. Those don’t tell you “do this for cloud” — they tell you “add this cloud stuff”. We saw need for a cloud-centric view. Security teams quickly get tossed into cloud, and while tooling has improved immensely over time, those flood you with data and don’t tell you where to start. We don’t lack tools, but we do lack priorities. Version 2.0 of the CSMM was built directly to address these issues. We reworked the CSMM to work as a cloud security framework. What does that mean? The model focuses on the 12 main categories of cloud security activities, which you can use to organize your program. The maturity levels and KPIs then help define your goals and guide your program without the minutiae of handling individual misconfigurations. What’s the difference between the Diagnostic and the Dashboard? The IANS diagnostic is where you should start. It’s a survey tool anyone can fill out without technical access to their deployments. The objective of the diagnostic is to help you quickly self-assess your program and then, using that, determine your maturity objectives. Let’s be realistic — not all organizations can or should be at “Level 5”. The diagnostic helps set realistic goals and timelines, based on where you are now. The FireMon Cloud Defense CSMM Dashboard is a quantitative real-time assessment and tracking tool. Once you integrate it with your cloud accounts you’ll have a dashboard to track maturity for the entire organization, different business units, and even specific accounts. It’s the tool to track how you are meeting the goals established with the diagnostic. It’s self-service and covers as many AWS accounts as you have (Azure will be there once the CSMM adds Azure controls). You can also just use the CSMM spreadsheet. Options are good. Free options are better. Finally, please send me your feedback. These are living documents and tools, and we plan to keep them continuously updated. The usual disclosure: I’m an IANS faculty member and I manage the Cloud Defense product. But both of these are available absolutely free, no strings attached, as is the model itself. Share:

This post isn’t about some fancy new research. Consider it a friendly nudge to floss. I’m pretty Type A about backing up and have data going back 20+ years at this point. I’m especially particular about my family photos. Until yesterday (this is called foreshadowing) my strategy was: Time Machine running on a Drobo for my main Mac Drobo as a company is dead, but this is a direct attached 5D, which has worked well and has enough capacity that I can lose drives and recover (which has happened). The Drobo as mass storage for the large files I don’t store on my SSD. Archives, VMs, videos. A WD MyBook with 12 TB, also directly connected to my Mac. Data replicated from there using Carbon Copy Cloner. Backblaze for cloud backups. With a personal encryption key. iCloud (I’m on the 6TB plan) for all my photos and related iCloud stuff. iCloud is synced across multiple systems. Box for Securosis corporate documents. Some older S3/Glacier archives. Probably more. I’m old and forget things. My entire house could burn down and I shouldn’t lose anything. But I broke the 3-2-1 rule. The 3-2-1 rule of backups is 3 copies of everything, at least 2 of them local, and 1 offsite. My Drobo died. Completely and suddenly. Not a single drive, but the entire thing. And the moment it happened I couldn’t remember whether I was backing up ALL of the Drobo anywhere else. It was RAID — what were the odds of losing the entire device? I knew I needed to replace it soon because the drivers weren’t being updated, but I kept putting it off. Well okay, I should be fine with my CCC backups… except that wasn’t set as a scheduled job, and I was only replicating one of the Drobo partitions. The other partitions? Well, one of them had my in-progress CloudSLAW video for next week and a demo video for the new CSMM feature we are releasing at work (remember, foreshadowing). Two time-sensitive things I REALLY didn’t want to recreate. Cloud/Backblaze to the Rescue and My New Strategy It turns out I really was sending everything from every drive to the cloud, and keeping versions for a year. It cost me just over $100 (for a single machine). I’ve never thought much about it, but all the data was there. The clincher was fast, selective restore. I was able to directly what I needed, including the video files, and download a .zip in less than an hour. Then I ordered a Synology, and I’ll go through the longer restore process once that arrives. Does this mean I can skip keeping 2 local versions on separate devices? And doesn’t RAID count as 2 devices? Nope and nope. But here’s my strategy and reasoning: an evolution of the 3-2-1 rule: Family photos and things I never want to lose are stored on 2-4 local devices and at least 2 different cloud providers, with occasional archives to a third provider. My iCloud Photos sync to my Mac. That’s backed up to via Time Machine and to the (soon to arrive) Synology. It also goes to Backblaze, and a couple times a year I archive to S3. All critical business documents are in 2 cloud services. That’s Box, and since I sync the files locally, they also land in my cloud backups of my local drive. Code and other documents are in places like GitHub and OneDrive, depending on which hat I’m wearing. I just make sure there are 2 of everything at 2 different services. A bootable image of my working Mac. I use Carbon Copy Cloner for this. I’m not as religious about it because I can fully work off my laptop when needed. Archived and media files are single copies on the RAID, but the RAID is backed up to cloud, from where I can selectively restore. These are the things I am okay with not having right away. UPDATE: I will now keep my working video files on a second local drive. This will be directly attached to my Mac, and backed up to both the cloud and the new RAID (Synology), which will be network attached instead of directly connected. So, 3-5 copies of all files. 1-3 local based on priority, 1-3 in cloud, also based on priority. Baby pics are 3 local, 3 in different cloud services. Full system is 2 local, 1 bootable. Work documents at 2 cloud services, at least one with versioning. Large “working” (media) files are 2 local, one on fast storage and the other RAID. Mass storage is 1 local (RAID) and 1 versioned copy in cloud. All critical work applications should be on 2 systems (laptop/desktop, and for me I do a ton on iPad). I lucked out this time. I really did not remember sending the Drobo files to Backblaze, and had a brief panic attack. And I hadn’t used selective restore previously, which helped me rapidly find and download the working files I needed. I’m gonna go floss now. Share:

After 25 years in technology, mostly in security, I recently realized I’m regressing. No, not in terms of my mental acuity or health (although all of you would be better judges on my brain function), but more in terms of my career. And no, I don’t mean I’m going back to the Helpdesk… and according to my children and most of my family I never really left anyway. Not that I’m paid for it. Well, sometimes with some cookies. But never enough cookies. It’s just that the longer I do this the more I realize that it’s the fundamentals that really matter. That as much as I love all the fun advanced research, all that work really only addresses and helps a relatively small percentage of the world. The hard problems aren’t the hard problems; the hard problems are solving the easy problems consistently. We mostly suck at that. What’s fascinating is that this isn’t a problem limited to security. I really noticed it recently when I was working on my paramedic recertification. As a paramedic I can do all sorts of advanced things that involve drugs, electricity, and tubes. In some cases, especially cardiac arrest, the research now shows that you, the bystander, starting good quality CPR early is far more important than me injecting someone with epinephrine. In fact, studies seem to indicate that epi in cardiac arrest does not improve long term patient outcomes. CPR and electricity (AEDs) for the win. Advanced clinicians for myself? Useful and necessary, but useless without the fundamentals before we get there. Back to security. As a researcher (and a vendor) we are drawn to the hard problems. I’m not saying they don’t matter — they very much do. As much as AI is in the hype machine right now it’s there for a reason and we need experts engaged early, even if most of what they’ll do will fail because AI is a truly disruptive innovation. If you don’t believe me just re-read this sentence after the 2024 election. And some basic problems need new innovations instead of banging our heads against the wall. Passwordless is a great example of attacking an intractable problem with hard engineering that is invisible to users. As much as I’d like to be doing more leading-edge research, I keep finding myself focusing on the basics, and trying to help other people do the basics better. Let’s take cloud incident response, my current bread and butter. Will Bengtson and I keep coming up with all sorts of cool, advanced cloud attacks to include in our IR training at Black Hat. The reality is those are mostly there so people think we are smart and to keep the rare advanced students interested. Nearly all cloud attacks a student working on a real IR team will encounter are the same two or three “simple” things. Lost or stolen credentials used for crypto, ransomware, or data exfiltration, or hacking a vulnerable public-facing instance for… crypto,  ransomware, or data exfiltration. Instead of spending my time on leading-edge research I’m building training for people with zero experience. I’m working on simple models which hopefully help people focus better. On the product side I’m focusing more on basic problems that seem to slip through the gaps. Chris Farris and I are working on a new talk and threat modeling approach to focus consistently on the fundamentals which really matter, not all the crazy advanced stuff in your inbox every day. Researchers and research teams mostly publish on the fun, interesting and advanced things because that’s more intellectually interesting and gets the headlines. There’s nothing wrong with that — we need it — but never forget that the basics matter more. I still get FOMO from time to time, but in the end I can do a lot more good at a much larger scale focusing on helping with fundamentals. Simple isn’t sexy, but without plumbers we’re all covered in shit pretty damn quickly. As a paramedic the one thing we are exceptional at is facing utter chaos, identifying what will kill you, and keeping things from getting worse. Maybe I biased my career from the start. Chris says he objects to being called a simple problem. Please humor him. Will just asked that I spell his name correctly.   Share:

I started a blog in 2006. This blog, to be precise. I kinda just wanted a blog. Blogs were cool. Twitter wasn’t really a thing yet. YouTube was only like a year old. The iPhone was hiding in an engineering and design lab. I didn’t expect securosis.com to be around 18 years later. I certainly didn’t expect it would become my full time job for 15 of those years. I most definitely didn’t expect to take on partners, spin out a product startup, have kids, lose my hair, grow… other hair, lose a partner (to a bank, not the grave, if there’s a difference), and, as of last weekend, migrate the entire site to our fourth hosting provider and third new software stack without losing any significant content. And most embarrassing of all, I didn’t expect to not write on my own site for… 3 years. But that’s what happens when you build a startup that gets acquired (and I still work there full time), your consulting customers keep you super busy with hands-on technical projects, and you spend a chunk of the pandemic running around playing paramedic. Oh, and when your kids hit the age where you and your wife effectively become unpaid ride share drivers. Now it’s time to come home. I’m still working and writing at FireMon and other places, but thanks to the success of CloudSLAW (my lab a week newsletter/blog/YouTube channel) I have the itch to just start blogging about random non-day-job security stuff again. I also have some new research on the way, and maybe some friends will be dropping in. Securosis (the company) is just for side projects now, and weirdly I think that gives me a freedom in my writing I forgot about. We just moved the site and I’m slowly updating things. In the coming weeks I also plan to pull some old posts from the 18-year history of this site and rip them to shreds with my modern knowledge and sensibilities. I hope some of you stick around for the ride, but I plan to have fun no matter what. Share:

What a long, strange trip it’s been over the last 3 years. In fact, the last time I saw many of you was at the last Disaster Recovery Breakfast in 2020. Within two weeks of that event, the world shut down due to COVID. Well, a lot has changed since then. DisruptOps was acquired by Firemon in September 2021. In early 2022, Rich decided he wanted to see our cloud security vision through and dedicate his full-time efforts to the Cloud Defense product. In July of 2022, I decided to partner with Alan Shimel and Mitch Ashley and join Techstrong as head of the research business. We still do cloud security training and house our cloud security content in Securosis, but we’ve both moved on. Our long-time venue for the DRB, Jillian’s (then TableTop Tap House) in San Fransisco, didn’t survive the pandemic. They went out of business in early 2022 and took our deposit for the 2022 DRB with them. Ouch. But given the lack of venues and the rescheduling of the RSA Conference to June 2022, we couldn’t pull off the breakfast last year. But this year, we are back. But it’s different. We have a different venue, which is The Pink Elephant (142 Minna St). We have a different organizer, which is now Techstrong and our Security Boulevard site. We have mostly the same sponsors, so we need to thank our pals at IANS, LaunchTech, and AimPoint Group. Their support is critical. So yes, we’ve had a changing of the guard. But what isn’t different is breakfast. It’s still a place where you can grab some breakfast and see some friends without the pomp and circumstance of a major conference. We hope to see you there. Share: