How to Avoid Kidnapping Children on Halloween

A useful guide.

from How to Avoid Kidnapping Children on Halloween

A High-End Card-Reading Device

An impressive Chinese device that automatically reads marked cards in order to cheat at poker and other card games.

from A High-End Card-Reading Device

How to Avoid Kidnapping Children on Halloween

A useful guide....

from How to Avoid Kidnapping Children on Halloween

Leadership Course Experience: What to Expect

I know leaders are busy. Faced with the opportunity to engage in a course to improve your leadership and communication creates a natural reaction: Leaders that invest in themselves set the standard for the people around them. But that means knowing you’re investing in an experience that gets results. That was the challenge I took […]

The post Leadership Course Experience: What to Expect appeared first on Security Catalyst.

from Leadership Course Experience: What to Expect

A High-End Card-Reading Device

An impressive Chinese device that automatically reads marked cards in order to cheat at poker and other card games....

from A High-End Card-Reading Device

Your Cloud Consultant Probably Sucks

There is a disturbing consistency in the kinds of project requests I’m seeing these days. Organizations call me because they are in the midst of their first transition to cloud, and they are spending many months planning out their exact AWS environment and all the security controls “before we move any workloads up”. More often than not some consulting firm advised them they need to spend 4-9 months building out 1-2 virtual networks in their cloud provider and implementing all the security controls before they can actually start in cloud.

This is exactly what you don’t want to do.

As I discussed [in an earlier post on blast radius you most definitely don’t want just one big cloud account/network with everything shoved in. This sets you up for major failures down the road, and will slow down your cloud initiatives to a degree that you lose many of the advantages of cloud. Here is why:

• One big account means a bigger blast radius (note that “account” us the AWS designation, Azure and Google use different structures but you can achieve the same goals). If something bad happens, like someone getting cloud admin credentials, the damage is massive.
• Speaking of admins, it becomes very hard to write identity management policies to restrict admins to only their needed scope, especially as you add more and more projects. With multiple accounts/networks you have a better ability to segregate them out and limit entitlements.
• It becomes harder to adopt immutable infrastructure (using templates like CloudFormation or Terraform to define the infrastructure and built it on demand) since developers and admins will end up stepping on each other more often.
• IP address space management and subnet segregation become really hard. Virtual networks aren’t physical networks. They are fundamentally managed and secured differently. What I end up seeing most organizations trying to do is shove in existing security tools and controls until it eventually falls down. In one recent case it became harder and slower to deploy things into the company’s AWS account than to spend months provisioning a new physical box on the existing network. That’s like paying for Netflix and trying to record Luke Cage on your TiVo so you can watch it when you want.

Those are just the highlights and the short version is that while you can start this way, it won’t last. Unfortunately, I’ve found that this is a surprisingly dominant recommendation from third-party “cloud consultants”, especially ones coming from the big firms. I’ve also seen Amazon Solution Architects (I haven’t worked with any from the other cloud providers) not recommend this practice, but go along with it if the organization is already moving that way. I don’t blame them, their job is to reduce friction and get customer workloads on AWS and changing this mindset is extremely difficult even in the best of circumstances.

Here is where you should start instead:

• Accept that any given project will have multiple cloud accounts to reduce the blast radius. 2-4 is average, with dev/test/prod being separated and a shared services account. This allows developers incredible latitude to work with the tools and configurations they need while still protecting production environments and data as you pare down the number of people with administrative level privileges.
  • I usually use “scope of admin” to define where you need to draw the account boundaries.
• If you need to connect back into the datacenter you still don’t need one big cloud account — use what I call a “bastion” account (Amazon calls these transit VPCs). This is the pipe back to your data center and then you peer your other accounts off of it.
• You still might want/need one shared account for some workloads and that’s okay. Just don’t make it the center of your strategy.
• A common issue, especially in financial services clients, is that outbound SSH is restricted from the corporate network. Thus the organization assumes they need to have a direct/VPN connection to the cloud network to enable remote access. You can get around this with jump boxes, software VPNs, and those bastion accounts/networks.
• Another common concern is that you need a direct connection to manage security and other enterprise controls. In reality I find this is rarely the case since you shouldn’t be using all the same exact tools and technologies anyway. This is more than I can squeeze in this post but you should be adopting more cloud-native architectures and technologies. it isn’t that you are reducing security, on the contrary you are often improving it, but you do need to adjust your existing policies and approaches.

I’ll be writing a lot more on these issues and architectures in the coming weeks. In short if someone tells you to build out a big virtual network that extends your existing network before you move anything to cloud, run away. Fast.

- Rich (0) Comments Subscribe to our daily email digest

from Your Cloud Consultant Probably Sucks

Ten Years of Securosis: Time for a Memory Dump

I started Securosis as a blog a little over 10 years ago. 9 years ago, it became my job. Soon after that Adrian Lane and Mike Rothman joined me as partners. Over that time we’ve published well over 10,000 posts, around 100 research papers, and given countless presentations. When I laid down that first post I was 35, childless, a Research VP at Gartner still, and recently married. In other words, I had a secure job, and the kind of free time no one with a kid ever sees again. Every morning I woke up energized to TELL THE INTERNET IMPORTANT THINGS!

In those 10 years I added three kids, my two partners, and grew what may be the only successful analyst firm to spin out of Gartner in decades. I finished my first triathlons, marathon, and century (plus) bike ride. I started programming again. We racked up a dream list of clients, presented at all the biggest events, and built a collection of research I’m truly proud of, especially my more-recent work on cloud and DevOps, including two training classes.

But it hasn’t all been rainbows and unicorns, especially the past couple of years. I stopped training in martial arts after nearly 20 years (kids), had two big health scares (totally fine), and slowly became encumbered with all the time-consuming overhead of being self employed. We went through 3 incredibly time consuming and emotional failed acquisitions where the offers didn’t meet our goals. We spent two years self funding, designing, and building a software platform that every iota of my experience and analysis says is desperately needed to manage security as we transition to cloud computing, but we couldn’t get it over the finish line. We weren’t willing to make the personal sacrifices you need to in order to get funding unless you are already wealthy, and we couldn’t find another path.

In other words, we lived life.

A side effect, especially after all the effort I put into Trinity (you can see a video of it here), is that I lost a lot of my time and motivation to write during a period where there is a hell of a lot to write about. We are in the midst of the most disruptive transition in how we build, operate, and manage technology. Around seven years ago I bet big on cloud (and then DevOps), with both research and hands-on work. Now there aren’t a lot of people out there with my experience, but I’ve done a crappy job of sharing it. In part I was holding back to give Trinity and our cloud engagements an edge. In bigger part because essentially (co) running two companies at the same time and seeing one of them not make it was emotionally crushing.

Why share all of this? Why not. I miss the days when I work up motivated to TELL THE INTERNET THOSE IMPORTANT THINGS. And the truth is, I no longer know what my future holds. Securosis is still extremely strong — we grew yet again this year and it was probably personally my biggest year yet. On the downside that growth is coming at a cost, where I spend most of my time traveling around performing cloud security assessments, building architectures, and running training classes. It’s very fulfilling work, but a bit of a step back in some ways. I don’t mind some travel, but most of my work now involves it and I don’t like spending that much time away from the family.

Did I mention I miss being motivated to write?

Over the next couple of months I’m going to brain dump everything I can, especially on cloud and DevOps. This isn’t for a paper. No one is licensing it, and I don’t have any motives other than to core dump everything I’ve learned over the past 7 years before I get bored and do something else. Clients have been asking me for a long time where to start in cloud security and I haven’t had anyplace to send them. So I’m putting up this page to collect all these posts in some relatively readable order. My intention is to follow the structure I use when assessing projects but odds are it will end up being a big hot mess. I’ll also be publishing most of the code and tools I’ve been building but was holding on to.

Yeah, this post is probably TMI, but we’ve always tried to be personal and honest around here. That is exactly what used to excite me so much I couldn’t wait to get out of bed and get to work. Perhaps those days are past. Or perhaps it’s just a matter of writing for the love of writing again instead of writing for projects, papers, or promotion.

- Rich (0) Comments Subscribe to our daily email digest

from Ten Years of Securosis: Time for a Memory Dump