Why We’re Here

I wanted to add some back story to Caffeinated Risk. We’ve been part of the security profession (both physical and logical) for the past few decades, worked together for some of that time and had a chance to learn about each other and our strengths. Over the past couple of years we’ve gotten together for coffee or lunch and, as two grumpy old security professionals do, started talking about our careers in security.

Both of us realized we have a similar goal – to give back to the profession that’s been so good to us. We thought a book would be a great way to help others…but that’s a lot of work! And we have real jobs we spend time at during the day. And I have a couple of dogs that are pretty needy…

So Doug came up with the idea of producing a monthly podcast for security professionals – by security professionals. We’d focus on the principles of Enterprise Security Risk Management (ESRM) and delve into technical and managerial topics regarding information security risk. The podcasts would be 20 to 30 minutes long and we’d interview other security risk professionals to learn how they worked through a project, a program, or their careers using a risk based approach to security.

It’s an opportunity for us both to talk about what we’re passionate about, how we struggled through the early parts of our careers and the lessons we picked up along the way. We’re not representing any company – the views posted here at Caffeinated Risk are solely our own personal narratives. We’re relying on all the mis-steps and successes we experienced to help others. We’ve got lots of stories so I’m not worried about finding material.

If you’ve made it this far, let me leave you with this final comment. Both Doug and I are doing something we’ve always wanted to do – give back to a profession that is in transition. We’ve seen how the security profession has grown from being the “department of no”, to becoming trusted advisors to organization executives.

Caffeinated Risk is our opportunity to talk about that journey.

And to let folks know how we learned that, in security, we don’t sign shit. Don’t worry, we’ll talk about that too.

Is the cure worse than the disease?

While I personally consider packet captures and memory dumps more interesting than policy and standards documents, I have been on many professional engagements over the years where the root contributor to the chaos was a lack of clear direction, either because solid governance was missing for one reason or another. Decades into my career now, I view these as important parts of a sustainable information security program.

Unfortunately, policies and standards are not something one can download from the SANS or ISACA website, make a few changes and call it a day. I often joke, the only thing worse than having to read policies and standards is writing them. The operating constraints of the organization are can never be fully understood by the policy writers and these documents are meant to provide long standing direction many years past the date of authoring. In all fairness to those authors, (myself included on some occasions), there is an assumption those responsible for implementing the controls understand the intent and make intelligent adjustments when needed because thing can change quickly in unpredictable ways.

When the world turned upside down overnight with the pandemic quarantine most companies found their remote access solutions were running at full capacity yet usability was not there. My first office VPN solution was PCAnywhere over a dial up modem, when I compiled the PPTP patch into my RedHat kernel and connected via cable modem 300kbs felt like a rocket. This memory lane visit shows remote access is old and so is the security guidance around it. It has been well entrenched in the remote access policies of many companies that while connected to the organization’s VPN all traffic from the remote computer needs to be contained within that encrypted tunnel. This of course includes all traffic to the internet because the common believe was the company needs to monitor what it’s people are doing when connected to the internet.

Back in 2000 something, when most company services were internal and internet access was not even granted to every worker, avoiding split tunneling made sense. That road warrior connection from the hotel room should not be exposing the internal corporate network in anyway. Fast forward to SaaS based email and CRM being the norm, the mass migration to home offices meant most companies suddenly found themselves burning double the bandwidth overnight. Once to bring the worker in, then direct their request out to Office 365 or SAP in the cloud, bring all that data back, then send it out once more to the home office. In addition the the double tax on the bandwidth, the requirement for monitoring the user activity isn’t being fully realized either because the traffic is encrypted from the worker’s desktop right to the SaaS service. The state of the art firewall knows it’s TLS traffic and the source IP is assigned to someone inside the company but that is about it. Conversely, the SaaS provider knows exactly who it is because they authenticated both the worker and are decrypting the TLS communications.

Those that clung tightly to a policy statement like “VPN connections shall not permit split tunneling”, likely found themselves trying to block high bandwidth content requests at perimeter firewalls. Those that realized a service like Office 365 is secured at the transport layer and the authentication layer, ( just like a VPN connection), may have found a policy change that permitted trusted connections to take the least expensive route allowed work to get done and the firewall whack-a-mole game never even got started.

If there is a call to action here, it would be review the policies that are in place and consider what threat or threats were intended to be mitigated? Does the current language make that abundantly clear to the reader five years from now dealing with a situation no one would have predicted?