Tag Archives: AWS Security Profile

AWS Security Profiles: Eric Brandwine, VP and Distinguished Engineer

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-eric-brandwine-vp-and-distinguished-engineer/

Amazon Spheres and author info
In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.


How long you have been at AWS, and what you do in your current role?

I’ve been at AWS for 11 years, and I report to Steve Schmidt, who’s our Chief Information Security Officer. I’m his Chief Engineer. I engage across the entire AWS Security Org to help keep the bar high. What we do all day, every day, is help AWS employees and customers figure out how to securely build what they need to build.

What part of your job do you enjoy the most?

It’s a trite answer, but it’s true: delivery. I enjoy impacting the customer experience. Often, the way security impacts the customer experience is by not impacting it, but we’re starting to launch a suite of really exciting security services for customers.

What’s the most challenging part of your job?

It’s a combination of two things. One is Amazon’s culture. I love the culture and would not change it, but it poses particular challenges for the Security team. The second challenge is people: I thought I had a computer job, but it turns out that like pretty much all of the Senior Engineers I know, I have a people job as much as or more than I have a computer job. Amazon has a culture of distributed ownership and empowerment. It’s what allows the company to move fast and deliver as much as it does, and it’s magnificent. I wouldn’t change it. But as the Security team, we’re often in a position where we have to say that X is no longer a best practice. Whatever the X is—there’s been a new research paper, there’s a patch that’s been published—everyone needs to stop doing X and start doing Y. But there’s no central lever we can pull to get every team and every individual to stop doing X and start doing Y. I can’t go to senior leaders and say, “Please inform your generals that Y needs to be done,” and have that message move down through the ranks in an orderly fashion. Instead, we spend a lot of our time trying to establish conditions, whether it’s by building tools, reporting on the right metrics, or offering the right incentives that drive the organization towards our desired state. It’s hacking people and groups of people at enormous scale and trying to influence the organization. It’s a tremendous amount of fun, and it can also be maddening.

Do you have any advice for people early in their careers about how to meet the challenge of influencing people?

I’ve got two lessons. The first is to take a structured approach to professional interactions such as meetings and email strings. Before you start, think through what your objective is. On what can you compromise? Where are you unwilling to compromise? What does success look like? Think through the engagement from the perspective of the other parties involved. This isn’t to say that you shouldn’t treat people like people. Much of my success is due to the amount of coffee and beer that I’ve bought. However, once you’re in the meeting or whatever, keep it on topic, drive towards that outcome, and hopefully end early so there’s time for coffee.

The other is to shift the discussion towards customers. As a security professional, it’s my job to tell you that you’ve done your job poorly. That thing that you sweated over for months? The one that you poured yourself into? Yeah, that one. It’s not good enough, it’s not ready to launch. This is always a hard discussion to have. By shifting the focus from my opinion versus yours to trying to delight customers, it becomes a much easier discussion. What should we do for customers? What is right for customers? How do we protect customers? If you take this approach, then you can have difficult conversations with peers and make tough decisions about product features and releases because the focus is always on the customer and not on social cohesion, peer pressure, or other concerns that aren’t customer-focused.

Tell us about your 2018 re:Invent topic. How did you choose it?

My talk is called 0x32 Shades of #7f7f7f: The Tension Between Absolutes and Ambiguity in Security. I chose the topic because a lot of security issues come down to judgment calls that result in very finely graduated shades of gray. I’ve seen a lot of people struggle with that ambiguity—but that ambiguity is actually central to security. And the ability to deal with the ambiguity is one of the things that enables a security team to be effective. At AWS, we don’t have a checklist that we go down when we engage with a product team. That lack of a checklist makes the teams more likely to talk to us and to bring us their problems, because they know we’re going to dig into the problem with them and come up with a reasoned recommendation based on our experience, not based on the rule book. This approach is excellent and absolutely necessary. But on the flipside, there are times when absolutes apply. There are times when you draw a bright line that none shall pass. One of the biggest things that can enable a security team to scale is knowing where to draw those bright lines and how to keep those lines immaculately clean. So my talk is about that tension: the dichotomy between absolute black and white and the pervading shades of gray.

What are some of the common misperceptions you encounter about cloud security?

I’ve got a couple. The first is that choosing a cloud provider is a long-term relationship. Make sure that your provider has a track record of security improvements and flexibility. The Internet, your applications, and your customers are not static. They’re going to change over time, sometimes quite quickly. Making it perfect now doesn’t mean that it will be perfect forever, or even for very long. At Amazon, we talk about one-way doors versus two-way doors. When going through a one-way door you have to be very sure that you’re making a good decision. We’ve not found a way to reliably and quickly make these decisions at scale, but we have found that you can often avoid the one-way door entirely. Make sure that as you’re moving your applications to the cloud, your provider gives you the flexibility to change your mind about configurations, policies, and other security mechanisms in the future.

The second is that you cannot allow the perfect to be the enemy of the good. Both within Amazon and with our customers, I’ve seen people use the migration to the cloud as an opportunity to fix all of the issues that their application has accreted over years or perhaps even decades. These projects very rarely succeed. The bar is so high, the project is so complex, that it’s basically impossible to successfully deliver. You have to be realistic about the security and availability that you have now, and you have to make sure that you get both better security when you launch in the cloud, and that you have the runway to incrementally improve over time. In 2016, Rob Joyce of the NSA gave a great talk about how the NSA thinks about zero-day vulnerabilities and gaining access to systems. It’s a good, clear articulation of a well-known security lesson, that adversaries are going to take the shortest easiest path to their objective. The news has been full of low-level side channel attacks like Spectre and Meltdown. While you absolutely have to address these, you also have to adopt MFA, minimize IAM policies, and the like. Customers should absolutely make sure that their cloud provider is someone they can trust, someone who takes security very seriously and with whom they can have a long-term relationship. But they also have to make sure that their own fundamentals are in order.

If you had to pick a different job, what would it be?

I would do something dealing with outer space. I’ve always read a lot of science fiction, so I’ve always had an interest, and it’s getting to the point where space is no longer the domain of large government agencies. There are these private companies that are doing amazing things in space, and the idea of one of my systems in orbit or further out is appealing.

The AWS Security team is hiring! Want to find out more? Check out our career page.

Want more AWS Security news? Follow us on Twitter.

Author

Eric Brandwine

By day, Eric helps teams figure out how to cloud. By night, Eric stalks the streets of Gotham, keeping it safe for customers. He is marginally competent at: AWS, Networking, Distributed Systems, Security, Photography, and Sarcasm. He is also an amateur parent and husband.

AWS Security Profiles: Ben Potter, Security Lead, Well-Architected

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-ben-potter-security-lead-well-architected/

Amazon Spheres with author info

In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.


How long have you been at AWS, and what do you do in your current role?

I’ve been with AWS for four and a half years. I started as a one of the first mid-market territory Solution Architects in Sydney, then I moved to professional services doing security, risk, and compliance. For the last year, I’ve been the security lead for Well-Architected, which is a global role.

What is Well-Architected?

It’s a framework that contains best practices, allowing you to measure your architecture and implement continuous improvements against those measurements. It’s designed to help your architecture evolve in alignment with five pillars: Operational Excellence, Security, Reliability, Performance Efficiency, and Cost Optimization. The framework is based on customer data that we’ve gathered, and learnings that our customers have shared. We want to share these learnings with everyone else.

How do you explain your job to non-tech friends?

Basically, I listen to customers a lot. I work with specialists and service teams around the world to help create security best practices for AWS that drive the Well-Architected framework. My work helps customers make better cloud security decisions.

What are you currently working on that you’re excited about?

I’ve been developing some in-depth, hands-on training material for Well-Architected, which you can find on GitHub. It’s all open-source, and the community is welcome to contribute. We’re just getting started with this sort of hands-on content, but we’ve run AWS-led sessions around the globe using this particular content, including at our AWS Security Lofts throughout the USA — plus Sydney, London, and Singapore — and we’ve gotten very positive feedback.

What’s the most challenging part of your job?

Everyone has different priorities and opinions on security. What a Singapore financial startup thinks is a priority is completely different from what an established bank in London thinks — which is completely different from the entertainment industry. The priorities of startups often center around short time-to-market and low cost, with less focus on security.

I’m trying to make it easy for everyone to be what we call Well-Architected in security from the start, so that the only way to do something is via automated, repeatable, secure mechanisms. AWS is great at providing building blocks, but if we can combine those building blocks into different solution sets and guidance, then we can help every customer be Well-Architected from the beginning. Most of the time, it doesn’t cost anything additional. People like me just need to spend the time developing examples, solutions, and labs, and getting them out there.

What does cloud security mean to you, personally?

Cloud security is an opportunity to rethink cybersecurity — to rethink the boundaries of what’s possible. It’s not just a security guard in front of a data center, with a big, old-fashioned firewall protecting the network. It’s a lot deeper than that. The cloud lets you influence security at every layer, from developers all the way to end users. Everyone needs to be thinking about it. I had a big presentation earlier this year, and I asked the audience, “Put your hand up if you’re responsible for your organization’s security.” Only about a quarter of the audience put their hands up. But that’s not true — it’s everyone’s responsibility. The cloud provides opportunities for businesses to innovate, improve their agility and ability to drive business value, but security needs to go hand-in-hand with all of that.

What’s the biggest issue that you see customers struggling with when it comes to cloud security?

A lot of customers don’t think about the need for incident response. They think: I don’t want to think about it. It’s never gonna happen to me. No, my access keys will never be lost. It’s fine. We’ve got processes in place, and our developers know what they’re doing. We’re never gonna lose any access keys or credentials. But it happens, people make mistakes. And it’s very important for anyone, regardless of whether or not they’re in the cloud, to be prepared for an incident, by investing in the tools that they need, by actually practicing responding to an incident, and by having run books. If X does happen, then where do I start? What do I need to do? Who do I need to communicate with? AWS can help with that, but it’s all very reactive. Incident response needs to be proactive because your organization’s reputation and business could be on the line.

In your opinion, what’s the biggest challenge facing the cloud security industry right now?

I think the biggest challenge is just staying up to date with what’s happening in the industry. Any company that develops software or tools or services is going to have a predefined plan of work. But often, security is forgotten about in that development process. Say you’re developing a mobile game: you’d probably have daily agile-style stand-ups, and you’d develop the game until you’ve got a minimum viable product. Then you’d put it out there for testing. But what if the underlying software libraries that you used to develop the game had vulnerabilities in them, and you didn’t realize this because you didn’t build in a process for hourly or daily checking of vulnerabilities in the external libraries you pulled in?

Keeping up-to-date is always a challenge, and this is where the cloud actually has a lot of power, because the cloud can drive the automated infrastructure combined with the actual code. It’s part of the whole dev ops thing — combining infrastructure code with the actual application code. You can take it all and run automated tools across it to verify your security posture and provide more granular control. In the old days, nearly everyone had keys to the data center to go in and reboot stuff. Now, you can isolate different application teams to different portions of their cloud environment. If something bad does happen, it’s much easier to contain the issue through the segmentation and micro-segmentation of services.

Five years from now, what changes do you think we’ll see across the security landscape?

I think we’re going to see a lot of change for the better. If you look at ransomware statistics that McAfee has published, new infection rates have actually gone down. More people are becoming aware of security, including end users and the general public. Cyber criminals go where the money is. This means organizations are under increasing pressure to do the right thing in terms of public safety and security.

For ransomware specifically, there’s also nomoreransom.org, a global project for which I was the “Chief Architect” — I worked with Europol, McAfee, and Kaspersky to create this website. It’s been around for a couple years now, and I think it’s already helping drive awareness of security and best practices for the public, like, don’t click on this phishing email. I co-presented a re:Invent presentation on this project few years ago, if you want more info about it.

Tell us about the chalk talk you’re giving at re:Invent this year.

The Well-Architected for Security chalk talk is meant to help customers get started by helping them identify which best practices they should follow. It’s an open QA. I’ll start by giving an overview of the Well-Architected framework, some best practices, and some design principles, and then I’ll do a live Q&A with whiteboarding. It’ll be really interactive. I like to question the audience about what they think their challenges are. Last year, I ran a session on advanced web application security that was really awesome because I actually got a lot of feedback, and I had some service team members in the room who were also able to use a lot of feedback from that session. So it’s not just about sharing, it’s also listening to customers’ challenges, which helps drive our content road map on what we need to do for customer enablement in the coming months.

Your second re:Invent session, the Security Framework Shakedown, says it will walk you through a complete security journey. What does that mean?

This session that Steve Laino and I are delivering is about where you should start in terms of design: How to know you’re designing a secure architecture, and how the Cloud Adoption and Well-Architected frameworks can help. As your company evolves, you’re going to have priorities, and you can’t do everything right the first time. So you’ll need to think about what your priorities are and create your own roadmap for an evolving architecture that becomes continually more secure. We’ve got National Australia Bank co-presenting with us. They’ll share their journey, including how they used the Cloud Adoption Framework to get started, and how they use Well-Architected daily to drive improvement across their platform.

Broadly, what are you hoping that your audience will take away from your sessions? What do you want them to do differently?

I want people to start prioritizing security in their day-to-day job roles. That prioritization means asking questions like, “What are some principles that I should include in my day to day work life? Are we using tools and automation to make security effective?” And if you’re not using automation and tools, then what’s out there that you can start using?

Any tips for first-time conference attendees?

Get out there and socialize. Talk to your peers, and try to find some mentors in the community. You’ll find that many people in the industry, both in AWS and among our customers and partners, are very willing to help you on a personal basis to develop your career.

Any tips for returning attendees?

Think about your goals, and go after that. You should be willing to give your honest feedback, too, and seek out service team members and individuals that have influenced you in the past.

You’re from Adelaide. If somebody is visiting your hometown, what would you advise them to do?

The “Mad March” festivities should not be missed. If you like red wine, you should visit the wine regions of Barossa Valley or McLaren Vale — or both. My favorite is definitely Barossa Valley.

The AWS Security team is hiring! Want to find out more? Check out our career page.

Want more AWS Security news? Follow us on Twitter.

Author

Ben Potter

Ben is the global security leader for the AWS Well-Architected Framework and is responsible for sharing best practices in security with customers and partners. Ben is also an ambassador for the No More Ransom initiative helping fight cyber crime with Europol, McAfee and law enforcement across the globe.

AWS Security Profiles: Don “Beetle” Bailey, Senior Principal Security Engineer; Brian Wagner, FSI Compliance Specialist

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-don-beetle-bailey-senior-principal-security-engineer-brian-wagner-fsi-compliance-specialist/

Amazon Spheres and author info

In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.


How long have you been at AWS, and what do you do in your current role?

Beetle: I’ve been at Amazon for eight and a half years, and I’m a Senior Principal Security Engineer. I helped build the AWS Security team from scratch, and for a while I wrangled security operations, threat intelligence, application security, and security engineering for all of AWS; reporting to our CISO Steve Schmidt. I’m still fairly involved with all that, while focused on proactive outreach to independent and academic security research communities. I also represent AWS for the Linux Foundation’s Core Infrastructure Initiative. When I get the time and can put my head down, I geek out on fun things for re:Invent that I think will benefit our customers. Before Amazon, I was a Principal Engineer for the Mitre Corporation for eleven years, and before that, I was in the US Army. I’ve always felt that being a “security geek” is a calling. Whether I’m helping people tackle emergent issues in the moment, or figuring out how new customer experiences that can be delivered in a secure manner, it’s all very rewarding.

Brian: I’ve been at AWS just over five years. I joined AWS as a Solutions Architect in Berlin, Germany, in 2013 where I worked in the enterprise space. I wasn’t a security guy by title, but it came up a lot in my day-to-day work — the cloud was pretty new back then and there was a lot of discussion about the security of it. In 2016, I moved to London and joined Professional Services as a full-time Security Consultant, which allowed me to work with customers in-depth and for very long periods of time, primarily in the financial services industry. Recently, I took on a new role as a Compliance Specialist in financial services. I’ve basically taken the in-depth experience I gained from my time in Professional Services and turned it into a position that lets me help multiple customers. I should note that when I was in Professional Services, I owned the incident response messaging activities for Professional Services and Security globally, which is relevant because our session at re:Invent this year is about incident response. My new job title of Compliance Specialist might make attendees wonder, “What’s he doing up there talking about incident response?

How do you explain your job to non-technical friends?

Brian: I just tell people that I sell dictionaries door-to-door. It’s much simpler than the truth.

Beetle: For the longest time, my kids thought I filled the Amazon boxes that show up on people’s doorsteps. Again, it’s a lot simpler than the truth. But I usually just ask folks if they’ve heard of “the cloud,” then explain that if you do things online like shopping, or storing data, or completing a banking transaction, a lot of those experiences are actually happening on the AWS cloud — and I’m one of the security geeks that helps make sure those activities happen in a secure manner.

Brian: Yes, that’s how I’d also describe it. For my particular role, I’d add that my focus is on helping AWS customers be secure.

What’s your favorite part of your job?

Beetle: My favorite part is interacting with customers. The opportunities that I get to talk to customers during re:Invent, the Summits, and the pop-up Lofts are super important to me. That interaction is absolutely my favorite part of the job.

Brian: What I love the best is getting to watch customers have that “ah-ha” moment. I’ve been living and breathing the cloud every day for over five years, but plenty of people are just getting started and figuring out how to make it all work. It’s very satisfying to see that lightbulb moment, when they go from “trial-and-error” to “this is working out…” and then, “Hey, now it all makes sense!” There’s always that moment with customers and it’s absolutely my favorite.

Beetle: Sometimes we see those lightbulbs go off in the audience when we’re presenting, and it’s great!

Speaking of the crowd, tell us about your re:Invent topic.

Beetle: So the title of our talk is AWS Security in your Sleep, and it builds on a number of talks that we’ve given in the past that demonstrate how to achieve security goals through automation. When you start doing things at scale, or if you want to be able to scale with a certain amount of consistency, you’re going to need automation. But often when we say “security automation” — whether that’s wrangling security events, incident response, or even forensics — customers will shy away, because it sounds intimidating. What we demonstrate is that there’s a lot you can achieve with security automation, and it can actually be fun!

Brian: There will be three demos this year. The first is what we’re calling a “low judgment” incident. This is a “security in your sleep” incident, where no human being has to think about what to do because you’ve automated the response. The second and third demos move on to increasingly complex scenarios based on real-world experiences. In our short hour together, we want to show people that they can automate even these more complex scenarios in a way that elevates their security.

Beetle: That’s right: achieving security goals with automation is not just a necessary thing, but it’s absolutely a possible thing for any of our customers to achieve. There’s this notion that only well-funded enterprises with large security teams and massive developer resources can achieve security goals through automation — particularly in security operations and incident response — and that’s actually not true. We want our demonstrations to show that all of our customers have these capabilities, right now. Our presentation is largely about democratizing security. We’re showing people that everyone can achieve their security goals through automation on AWS. We also throw in a few humorous tidbits to keep it interesting.

What are some of the most common misperceptions about cloud security that you encounter?

Beetle: One of the focal points of our presentation is the transition from traditional on-premise incident response workflows to the cloud. Traditional incident response requires you to put your hands on physical resources, whether you’re connecting and disconnecting cables, or plugging in forensic dongles to clone drives, etc. We want our presentation to dispel the myth that you can’t achieve security incident response goals in the cloud. In fact, you can have some of the most intricate, customized incident response workflows and run books, and you can still translate and map those responses onto capabilities that reside on our platform, with automation to execute at scale and speed. Sometimes, the terminology is different. Sometimes, the timing is different. But generally, you can accomplish more and faster within the cloud than from an on-premise environment.

Brian: Like Beetle said, you really can achieve those same goals, as long as you understand that the cloud might look a little different. But the goals themselves are the same. In fact, I like to think that they can be improved — that you can have more goals from within the cloud, and that you can achieve them with less effort.

If you had to distill your talk down to a single takeaway for your audience, what would it be?

Brian: Demos. Cats. And comedy. You’ll laugh, you’ll cry.

Beetle: Awkward comedy.

Five years from now, what changes do you hope to see across the security landscape?

Beetle. Five years is a long way out in this business! But I think we’ll see even more involvement from partners who flesh out holistic security capabilities that empower our customers to leverage AWS for all sorts of security-related purposes. Most notably, I think we’ll see much more capable solutions in incident response and incident management — decision support and services that help people quickly address concerns and get back to a known good state. I think we’ll continue to see more security-related products and services catering to our customers’ environments, whether it’s microservices, or containers, or whatever the next whiz-bang language or execution environment is.

Brian: When customers do something with AWS in the name of security, they do it because they perceive a risk of something bad happening. The whole point is to reduce risk. And the thing about risk is that it will always exist, whether in five years, or ten years, or fifty years. But if security is done correctly, we can reduce that risk to as close to zero as possible. Reaching zero will always be impossible — we don’t know what we don’t know, and so we can never mitigate all risk. But as time goes on and new threats emerge, AWS is able to offer customers the ability to continue to sleep well at night because we’ve helped them, or we’ve given them tools, or there’s a partner, or we’ve simply taken care of it for them per the Shared Responsibility Model. In five years, I’d like to be up on a re:Invent stage talking about something totally mundane because that’s all that’s left to mitigate — the big risks have been taken care of. I would love for re:Invent five years from now to be the most boring re:Invent ever.

Beetle: It’s interesting — we’re getting to have conversations now about security capabilities that generally reside at the top of the Maslow’s hierarchy of InfoSec needs. At the bottom are basics like inventory and patching, and it turns out that the inventory and patching story in an AWS environment is pretty boring these days: There’s an API call to make, and agents you can deploy on instances at boot that inventory any vulnerabilities and ensure they’re reported, and you can have AWS Lambda function automatically deploy patches. Configuration management isn’t quite there yet, but it’s also becoming a boring story. But as you move further up, toward the top of the Maslow’s hierarchy of InfoSec needs, you get to things like anomaly-based intrusion detection, user behavioral analytics, and even deceptive infrastructure like honeypots. These are like the bonus levels of security engineering. You only get the luxury of indulging in these things if you’ve eaten all your vegetables beforehand. Currently, these things are bleeding edge, but in five years, maybe intrusion detection will be boring and incident response will be boring, because that will all just get done by a capability innate to the platform or from a one-click-deployable partner solution, and then we’ll be eyeing some other type of cherry on top of the security sundae.

Do you have any tips for first time conference attendees?

Beetle: Beyond general health tips, like wearing comfortable shoes and drinking enough water, I think the mobile app is super helpful, particularly when you customize it and choose which talks you’re interested in. Also, people may not realize this, but AWS has always made a significant investment in re:Invent’s wireless infrastructure. (It’s been a privilege of mine to help plan and deliver some of that infrastructure in years past.) It’s fast, and likely better than any hot spot or overloaded cell tower. There are Wi-Fi access points every twenty yards or so, nearly everywhere you go at re:Invent.

Brian: If you have questions or need help with something, look for the Security booth signs and the people with AWS shirts — everybody is super-helpful and our approach is basically, “if I don’t know the answer to your question, I’m going to find someone who does!” The other thing I’d recommend is networking: Bring your business cards and try to step outside of your comfort zone. If you don’t know anything about security, come to a security session. If you’ve always wanted to learn about IoT, this is a really great place to do it. Rarely will you see a higher quality bar for presentations, so mix in stuff that might feel tangential to you personally or to your business. Diversify your schedule and take advantage of as many of the opportunities as you can.

Beetle: One final recommendation: there’s a charity fun run that we hold at re:Invent that benefits Girls Who Code. They close off streets in Las Vegas for thousands of runners, and there are different distances to choose from. It’s a fantastic and fun event. Sign up and run!

If you had to pick any other job to do, what would it be?

Beetle: QA for Comixology.

Brian: You had that answer in your back pocket! Wow.

Beetle: Amazon acquired Comixology, I’m a big comic book geek, and I love Comixology — it’s great for reading digital comics. I’m angling to convince them that they need a security engineer dedicated to them full time, making sure their comic books render correctly.

Brian: I cannot top that.

The AWS Security team is hiring! Want to find out more? Check out our career page.

Want more AWS Security news? Follow us on Twitter.

Author

Don “Beetle” Bailey

Beetle made the transition from Army supply guy to security geek in the mid-90s, inspired by dial-up access to a BBS, Trumpet Winsock, and the L0pht. Today, he’s a Senior Principal Security Engineer at AWS and is passionate about his day job: protecting customers, their data, and AWS itself. He founded the “ShmooCon” hacker conference, and he’s presented on wireless security and cloud security at a variety of conferences. Beetle has a BS in Computer Science from James Madison University.

Author

Brian Wagner

Brian worked as a software developer for 15 years, and then as a network engineer, until AWS hired him in 2013 in Berlin where he helped customers get comfortable with the cloud (even before the Frankfurt region was launched). He’s since made security a full-time job and moved to the AWS Professional Services team in London where he’s led efforts such as GDPR, Incident Response, and the AWS Security Workshop. These days, you can find Brian in his natural habitat at the gym or on a rugby pitch.

AWS Security Profiles: Becky Weiss, Senior Principal Engineer

Post Syndicated from Becca Crockett original https://aws.amazon.com/blogs/security/aws-security-profiles-becky-weiss-senior-principal-engineer/

Amazon Spheres and author info

In the weeks leading up to re:Invent, we’ll share conversations we’ve had with people at AWS who will be presenting at the event so you can learn more about them and some of the interesting work that they’re doing.


How long have you been at AWS, and what do you do in your current role?

My title is Senior Principal Engineer, and most of my work is with the AWS Identity team. That’s the team that does AWS Identity and Access Management, AWS Organizations, AWS Directory Service, AWS Single Sign-On, and a bunch of other things. We build the infrastructure for security, compliance, and manageability across all of AWS. It’s a large swath of services, and it’s a very interesting place to be. My team is at the crossroads of everything that’s going on, so we get an up-close view of trends and patterns around the controls customers demand as they move workloads to the cloud, as well as what they do to secure those workloads and put guardrails around them once they’re here.

How do you explain your job to non-tech friends?

Most people, even outside of the tech space, have heard about the cloud. And they’ve likely heard about companies in almost every imaginable industry choosing to move their core infrastructure — computing, and networking — from their own data centers to the cloud, as well as taking advantage of data services and higher-level application and AI services, of which there are increasingly many options. So to these people, I’d say that my job is to make sure that the security controls these enterprise customers will need are present, and that we’re constantly improving them by making them more comprehensive and simpler to get right.

What’s your favorite part of your job?

My job is very rewarding because, as customers move into the cloud, one of the things that I deeply and truly believe is that they’ll be able to improve their security posture. They’re going to gain visibility into and get control over things they didn’t have visibility into or control over before, and they’ll have it in a way that scales much better than the processing power of human gatekeepers. It’s really rewarding to see those transformations happen and to be able to give customers something that I believe will serve them so well.

Another privilege of this aspect of my job, in which I get to work with customers, is seeing how much these customers value AWS’s institutional experience, not just in security but in building for resilience and scalability. They ask, “How would Amazon architect this? What would you do if you were building our stuff?” It’s an incredible honor to be asked a question like that.

What are you currently working on that you’re excited about?

In the last couple of months, my team has done a lot of deep dives and close listening with some of our customers on what “governance in the cloud” means to them and what their needs are. We have this process at Amazon called “working backwards from the customer,” where we start with the very real challenges, concerns, and problems that customers lay out for us as they describe their own workloads and approaches. We take those insights and we use them to work backward toward what we need to build. That peculiar Amazonian focus on mapping customer needs and using them to drive what we’ll provide is one of the things that keeps me looking forward to coming into work. It’s special.

What’s the most challenging part of your job?

I mentioned before that my team sits at the crossroads of AWS, and the number of new services and new features that show up every re:Invent and throughout the year is mind-boggling. The reason we’re able to maintain this pace as a company is a consequence of the Amazon DNA: Each service is managed as its own business, and its owners engages directly with its own customers. Working from those specific customer needs is what allows us to iterate quickly and address customer-needs head-on. But the flip side is that you do have certain features that need to be constant, consistent, and effective across all services, and this is sometimes at loggerheads with what makes us makes us fast. One of our biggest strengths is also one of the things that can pose challenges when you’re sitting in the middle of “downtown AWS” like my team does.

What does cloud security mean to you, personally?

When it comes to security, complexity is the enemy. So you’re looking for security controls and mechanisms that are as simple as possible while still doing the job. When you’re answering the question, “Why is this thing secure?” having a long answer can be a sign that you have the wrong answer. If you can figure out a simple expression of the controls that you want to put on your infrastructure, it means you’re doing something right.

One of your 2018 re:Invent sessions is A Practitioner’s Guide to Securing Your Cloud (Like an Expert). What’s that session about?

One of the reasons why I wanted to give this talk is because you might look at this incredible landscape of AWS services and, especially if you’re new to the cloud, you might think, “Wow, there’s so much stuff here.” If you’re a security- or governance-minded professional and it’s your job to make sure things are secure and properly controlled, you might ask yourself, “How is my job even possible over this kind of surface area?” But the truth of the matter is it’s easier than you might think if you’re new here. We’ve worked hard to make sure that’s the case. In fact, there are just a couple of patterns: You’re securing your infrastructure with IAM permission controls and with VPC network security controls. (There are also encryption controls, which I won’t have time to cover in the session, but that follows simple patterns too.) But really, these two or three patterns repeat everywhere. If you learn them once, it doesn’t matter what new AWS service your team is going to adopt—you’re already going to know how to secure it. That even includes features and services we haven’t yet launched or even dreamed up yet—you’re already going to know how to secure it. The patterns are repeatable and very learnable.

You’re also co-presenting a session with David Yanacek that talks about Failing Successfully in the Cloud. How did you choose that topic?

That one’s a chalk talk—basically an open-ended Q&A with folks in the audience. Here’s where I got the topic idea: One of the tremendous privileges of being an engineer at Amazon is that AWS has been running at such a scale, and for long enough, that we’ve built up this institutional experience that I believe you can’t find anywhere else. There’s no compression algorithm for experience, and people like David and me have been lucky enough to have a front-row seat. The various services we’ve worked on—between us, Amazon Elastic Compute Cloud (Amazon EC2), Amazon DynamoDB, IoT, AWS Lambda, and AWS IAM—have given us a first-class education in resilience. It’s the law of large numbers: Anything can happen and eventually does. So we’ve learned a number of lessons that we’ve now baked into the design of what we do.

One of the things we’re going talk about is how, when we run a service, we break it down between the data plane (the “day job” of the service, the part that runs at high volume and is critical to the business), and the control plane (the part that’s used to configure the rest of the service). At AWS, we think about these planes very separately because of the resiliency benefits. We’re also going to talk about some approaches to handling high levels of load, and how to think about dependency failures. I’m expecting some really interesting discussion.

And finally, you’ll be co-presenting a session and chalk talk with Alan Halachmi on Securing Your Virtual Data Center in the Cloud. Tell us about those.

These two are an outgrowth of a re:Invent session I used to lead called NET201: Creating Your Virtual Data Center in the Cloud (this was back when I used to work on Amazon Virtual Private Cloud). It continues to be one of our most popular sessions, and it’s now led by my colleague Gina Morris. Based on the feedback I received when I hosted these talks, I realized that our customers were hungry for simple explanations of networking in AWS. And it really is possible to explain this topic simply, which I think is why the talk remains so popular.

But I realized there’s also a security angle on this topic. So we created the breakout session NET202: Securing Your Virtual Data Center in the Cloud as a primer on how to use Amazon VPC to secure your resources and as a way to educate people about the ways in which Amazon VPC intersects with other security controls in AWS. Because the NET201 session always generated incredible Q&A after the talk, we’re also pairing the new session with a chalk talk of the same name, and we’re looking forward to an active discussion. We’re bringing a number of examples to walk through, but based on the past experiences Alan and I have had talking to our customers about networking in AWS, we’re expecting great Q&A.

What are you hoping that your audience will do differently after your session?

For the “Practitioner’s Guide” and “Securing your Virtual Data Center” sessions, I want my customers to go back and look at the workloads their teams are standing up, and the workloads they’re standing up themselves, and recognize the patterns we’ve pointed out—and then apply these patterns and feel confident that they’re securing things correctly because, again, there are only really a couple of things you need to know to get the network right, and to get the access controls right. And I think these things are eminently teachable in a fifty-minute session.

For the “Failing Successfully” chalk talk, I want the folks to go back home, take a look at the workloads they’re running and ask themselves questions that they may not have thought to ask before. For example: “Does this system have a control plane and a data plane?” Most systems do; you just have to know where to apply the analogies. “Have I separated them?” Maybe start thinking about separating those if you want to get more resilient. “Am I taking dependencies on things that are going to fail more than I want my own service to fail, and what I could do about that? If my system is under load, what do I want to have happen?

The AWS Security team is hiring! Want to find out more? Check out our career page.

Want more AWS Security news? Follow us on Twitter.

Becky Weiss

Becky is a Senior Principal Engineer at Amazon Web Services. She currently works on AWS IAM and has worked on Amazon EC2 and AWS Lambda in the past. In addition to being a proud service owner at AWS, Becky is also an enthusiastic user of AWS services herself.