Leading up to the AWS Santa Clara Summit, we’re sharing our conversation with Nathan Case, who will be presenting at the event, so you can learn more about him and some of the interesting work that he’s doing.
How long have you been at AWS, and what do you do in your current role?
I’ve been with AWS for three years, and I’m a Senior Security Specialist, Solutions Architect. I started out working on our Commercial Sector team, but I moved fairly quickly to Public Sector, where I was the tech lead for our work with the U.S. Department of Defense (DOD) and the first consultant in our U.S. DOD practice. I was offered a position back on the commercial side of the company, which entailed building out how we, as AWS, think about incident response and threat detection. I took that job because it was way too interesting to pass up, and it gave me an opportunity to have more impact for our customers. I love doing incident response and threat detection, so I had that moment where I thought, “Really? You’re going to pay me to do this?” I couldn’t turn it down. It did break my heart a little to step away from the public sector, but it’s great getting to work more intimately with some of our commercial customers.
What do you wish more people understood about incident response?
Because of my role, I generally talk with customers after one of their applications has been breached or something has been broken into. The thing I wish more people knew is that it will be okay. This happens to a lot of people, and it’s not the end of the world. Life will go on.
That said, the process does work much better if you call me before an incident happens. Prevention is so much better than the cure. I’m happy to help during an incident, but there are lots of ways we can proactively make things better.
What’s your favorite part of your job?
I think people like myself, who enjoy incident response, have a slight hero complex: You get to jump in, get involved, and make a difference for somebody. I love walking away from an engagement where something bad has happened, knowing that I’ve made a difference for that person and they’re now a happy customer again.
I also enjoy getting to do the pre-work sessions. While I have to make sure that customers understand that security is something they have to do, I help them reach the point where they’re happy about that fact. I get to help them realize that it’s something they’re capable of doing and it’s not as scary as they thought.
What’s the most challenging part of your job?
It’s that moment when I get the call—maybe in the middle of the night—and somebody says this thing has just happened, and can I help them?
The hardest aspect of that conversation is working through the event with the CISO or the individual who’s in charge of the response and convincing them that all the steps they’ll need to take will still be there tomorrow and that there’s nothing else they can do in the moment. It’s difficult to watch the pain that accompanies that realization. There’s eventually a certain catharsis at the end of the conversation, as the customer starts to see the light at the end of the tunnel and to understand that everything is going to be all right. But that first moment, when the pit has dropped out of someone’s stomach and I have to watch it on their face—that’s hard.
What’s the most common misperception about cloud security that you encounter?
I used to work in data centers, so I have a background that’s steeped in building out networking switches, and stacks, and points of presence, and so on. I spent a lot of time protecting and securing these things, and doing some impressive data center implementations. But now that I work in the cloud, I look back at that whole experience and ask, “Why?”
I think the misconception still exists that it’s easier to protect a data center than the cloud. But frankly, I wouldn’t be doing this job if I thought data centers were more secure. They’re not. There are so many more things that you can see and take care of in a cloud environment. You’re able to detect more threats than you could in a data center, and there’s so much more instrumentation to enable you to keep track of all of those threats.
What does cloud security mean to you, personally?
I view my current role as a statement of my belief in cloud security; it’s a way for me to offer help to a large number of people.
When I worked for the U.S. Department of Defense, through AWS, it was really important to me to help protect the country and to make sure that we were safe. That’s still really important to me—and I believe the cloud can help achieve that. If you look at the world as a whole, I think there’s evidence of a nefarious substructure that operates in a manner similar to organized crime: It exists, but it’s hopefully not something that most people have to see or interact with. I feel a certain calling to be one of the individuals that helps shield others from these influences that they generally wouldn’t have the knowledge to protect themselves against. For example, I’ve done work that helps protect people from attacks by nation states. It’s very satisfying to be able to help defend and protect customers from things like that.
Five years from now, what changes do you think we’ll see across the cloud security landscape?
I think that cloud security will begin shifting toward the question, “How did you implement? Is your architecture correct?” Right now, I hear this statement a lot: “We built this application like we have for the last [X] years. It’s fine!” And I believe that attitude will disappear as it becomes painfully obvious that it’s not fine, and it wasn’t fine. The way we architect and build and secure applications will change dramatically. Security will be included to begin with, and designing for failure will become the norm. We’ll see more people building security and detection in layers so that attackers’ actions can be seen and responded to automatically. With the services that are coming into being now, the options for new applications are just so different. It’s very exciting to see what they are and how we can secure applications and infrastructure.
You’re hosting a session at the Santa Clara summit titled “Threat detection and mitigation at AWS.” Where did the idea for this topic come from?
There’s no incident response without the ability to detect the threat. As AWS (and, frankly, as technology professionals), we need to teach people how to detect threats. That includes teaching them appropriate habits and appropriate architectures that allow for detecting, rather than simply accepting the attitude that “whatever happens, happens.”
My talk focuses on describing how you need to architect your environment so that you’re able to see a threat when it’s present. This enables you to know that there’s an issue in advance, rather than finding out two and half years later that a threat has been present all along and you just didn’t know about it. That’s an untenable scenario to me. If we begin to follow appropriate cloud hygiene, then that risk goes way down.
What are some of the most common challenges customers face when it comes to threat detection in the cloud?
I often see customers struggling to let go of the idea that a human has to touch production to make it work correctly. I think you can trace this back to the fact that people are used to having a rack down in the basement that they can go play with. As humans, we get locked in this “we’re used to it” concept. Change is scary! Technology is evolving and people need to change with it and move forward along the technical path. There are so many opportunities out there for someone who takes the time to learn about new technologies.
What are you hoping your audience will do differently as a result of your session?
Let me use sailing a boat as an example: If you don’t have a complex navigation system and you can’t tell exactly which course you’re on, there are times when you pick something off in the distance and steer toward that. You’ll probably have to correct course as you go. If the wind blows heavily, you might have to swing left or right before making your way back to your original course. But you have something to steer toward.
I hope that my topic gives people that end-point, that place in the distance to travel toward. I don’t think the talk will make everyone suddenly jump up and take action—although it would be great if that happens! But I’d settle for the realization that, “Gee, wouldn’t it be nice if we could get to the place Nathan is talking about?” Simply figuring out what to steer toward is the obstacle standing in the way of a lot of people.
You’re known for your excellent BBQ. Can you give us some tips on cooking a great brisket?
I generally cook brisket for about 18 hours, between 180 – 190 degrees Fahrenheit, using a homemade dry rub, heavy on salt, sugar, and paprika. I learned this technique (indirectly: https://rudysbbq.com/) from a guy named Rudy, who lived in San Antonio and opened a restaurant called Rudy’s Bar-B-Q (the “worst BBQ in Texas”) that I used to visit every summer. If you’re using a charcoal grill, maintaining 180 – 190 degrees for eighteen hours is a real pain in the butt—so I cheat and use an electric smoker. But if you do this a fair bit, you’ll notice that 180 – 190 isn’t hot enough to generate enough smoke, and you generally want brisket to be smoky. I add some smoldering embers to the smoke tray to keep it smoking. (I know that an electric smoker is cheating. I’m sure Rudy would be horribly offended.)
Want more AWS Security how-to content, news, and feature announcements? Follow us on Twitter.
The AWS Security team is hiring! Want to find out more? Check out our career page.